|
Documentação
Marcar uma demonstraçãoPlataforma
PlataformaMCPCLIAPI
Workflows
GuiasChangelog

Boas-vindas

  • Visão geral
  • Autenticação
  • Erros e códigos de estado
  • Assinaturas de webhook

Localização

  • Visão geral
  • Criar jobs
  • Bloquear chaves não traduzíveis
  • Acompanhar um grupo de jobs
  • Obter um trabalho
  • Listar tarefas
  • Entrega de webhooks
  • Progresso em tempo real (WebSocket)

Pipeline

  • Visão geral
  • Edição por IA pré-localização
  • Revisão humana
  • avaliação por IA (post-edit)
  • Reformular para soar natural
  • Verificação por retrotradução
  • Configurar o pipeline
  • Observar execuções do pipeline

Provisionamento

  • Visão geral
  • Criar uma tarefa de aprovisionamento
  • Tipos de fonte
  • O que a IA extrai
  • Entrega de webhook
  • Progresso em tempo real (WebSocket)

Síncrono

  • Localize
  • Recognize

Gestão do motor

  • Sugestões do motor

O que a IA extrai

Já submeteu as suas fontes e o job está em execução. O ID do motor foi devolvido no 202 e a configuração está a ser preenchida. Esta página responde à pergunta que determina se confia no resultado: o que, exatamente, está a ser preenchido?

"A IA configurou o meu motor" é daquelas frases que deixam qualquer engenheiro de pé atrás — e com razão. Pode significar uma caixa-preta impossível de inspecionar. Pode significar registos espalhados por vários idiomas sem que consiga perceber onde estão. Pode significar que o agente leu uma fonte fraca, não encontrou nada e criou discretamente quase nada. Por isso, esta página é concreta nos três pontos: o agente produz três tipos de configuração, cada um é mapeado para os seus idiomas segundo uma regra previsível, e o job devolve um resumo que identifica todos os registos que criou. O resultado são registos normais que pode ler e editar — não um veredito que tenha de aceitar por fé.

É novo no provisioning assíncrono? Comece pela Visão geral da API de Provisioning Assíncrono para ficar com o modelo mental certo e por Tipos de fonte para perceber o que faz com que uma fonte valha a pena ser submetida. Esta página foca-se no que sai do outro lado.

Nesta página

  • Os três componentes
  • Como cada um é mapeado para um idioma
  • O resumo do resultado
  • Como ler um resumo reduzido
  • Próximos passos

Os três componentes#

O agente lê tudo — tanto páginas rastreadas como conteúdo em bruto — e cria três tipos de configuração do motor. Não se trata de um formato novo, exclusivo do provisioning. São exatamente os mesmos elementos base que, de outra forma, criaria manualmente num motor, razão pela qual tudo o que o agente cria pode ser editado mais tarde no dashboard, da mesma forma que editaria qualquer coisa criada por si.

ComponenteO que procuraExemplo
Vozes da marcaTom, estilo, nível de formalidade, convenções de escrita"Use alemão formal (forma Sie). Mantenha as frases concisas e diretas."
Itens de glossárioNomes de produtos, termos técnicos, traduções específicas da marca, termos não traduzíveis"Acme" → não traduzível, "workspace" → "Arbeitsbereich" (de)
InstruçõesRegras de formatação, convenções culturais, diretrizes específicas do domínio"Formate sempre as datas como DD.MM.YYYY nas traduções em alemão."

Estas são as três coisas que fazem uma tradução soar ao seu produto, em vez de parecer uma formulação genérica — a formalidade que escolheu, os nomes que nunca traduz, o formato de data que usa sempre. O trabalho do agente é encontrar essas decisões onde quer que estejam declaradas nas suas fontes e registá-las como registos.

Há uma consequência que vale a pena dizer sem rodeios, porque define o limite do que deve esperar receber: o agente extrai aquilo que é declarado, não aquilo que está implícito. Uma fonte que enuncia uma regra de forma explícita gera um registo; uma fonte que apenas demonstra um bom tom sem nomear uma regra gera pouco. Isso é uma característica das fontes, não do motor — Tipos de fonte explica como escolher fontes que digam as regras de forma explícita.

Como cada um é mapeado para um idioma#

A configuração de um motor de localização é indexada por idioma de destino, por isso um registo não é apenas o que é uma regra — é onde a regra se aplica. O agente atribui a cada registo um idioma segundo uma regra previsível, e o caráter universal * é a parte que vale a pena compreender antes de ler o resultado.

  • As vozes da marca e as instruções usam * quando se aplicam a todas as línguas. Uma regra de tom como "mantenha as frases concisas e diretas" não é específica do alemão; é a forma como o seu produto escreve em qualquer língua. O agente atribui-lhe o idioma de destino *, e ela aplica-se a todos os idiomas para os quais o motor traduz. Uma regra que seja verdadeiramente específica de uma língua ("use a forma Sie em alemão") é atribuída a esse idioma.
  • Os itens de glossário são criados por par de idiomas, porque uma tradução é sempre feita de uma língua para outra específica — "workspace" → "Arbeitsbereich" é um facto sobre o alemão, e apenas sobre o alemão.
  • Os termos não traduzíveis são a exceção, e usam *. Um nome de marca que nunca traduz — "Acme" — é não traduzível em qualquer língua, por isso é armazenado uma vez com * em vez de ser introduzido novamente para cada par de idiomas.

Por isso, quando vê * num registo criado pelo job, isso não é um marcador de posição nem uma lacuna. Significa "isto aplica-se em todo o lado" — uma regra global de tom, uma instrução global ou um termo que nunca é traduzido em nenhuma língua. Um código de idioma específico significa o contrário: esta regra está limitada exatamente a essa língua.

Porque o caráter universal é uma funcionalidade, não uma predefinição a substituir

Uma leitura cética de * seria: "o agente nem se deu ao trabalho de perceber a que idioma isto pertence". É precisamente o contrário. Uma voz da marca ou um termo não traduzível que esteja correto em qualquer língua deve ser global — associá-lo a um único idioma significaria que deixaria silenciosamente de se aplicar aos restantes. O caráter universal é a forma como a configuração diz "isto é verdade independentemente da língua", que é exatamente o que uma regra de tom ou um nome de marca costuma ser.

O resumo do resultado#

Quando o job termina, devolve um resumo que identifica tudo o que o agente criou. Este é o recibo: todos os registos, contados e identificados, mais uma lista de tudo o que falhou.

json
{
  "brandVoices": {
    "count": 3,
    "ids": ["bv_A1b2C3d4", "bv_B2c3D4e5", "bv_C3d4E5f6"]
  },
  "glossaryItems": {
    "count": 12,
    "ids": ["gi_A1b2C3d4", "gi_B2c3D4e5", "..."]
  },
  "instructions": {
    "count": 5,
    "ids": ["ins_A1b2C3d4", "ins_B2c3D4e5", "..."]
  },
  "errors": []
}

Cada componente apresenta um count e os ids dos registos criados — bv_ para vozes da marca, gi_ para itens de glossário, ins_ para instruções. Não são confirmações opacas; são os IDs de registos reais no motor. Pode pegar em qualquer gi_ desta lista, abri-lo no dashboard e ler ou alterar exatamente aquilo que o agente extraiu. O resumo é a forma de passar de "a IA fez qualquer coisa" para "aqui estão as vinte coisas específicas que ela fez", que é toda a diferença entre uma caixa-preta e registos normais que pode ler e editar.

O resumo chega-lhe pelo canal que configurou quando criou o job: no payload do webhook que o seu URL de callback recebe quando termina, onde surge como o campo summary. Se estiver a acompanhar o job através de WebSocket, isso é um feed de atividade — transmite o progresso do rastreio e da configuração, não este objeto de resumo. O resumo segue no webhook de conclusão; o WebSocket diz-lhe quando ir consultá-lo.

Um item falhado não faz falhar o job.

Se não for possível criar um único registo, isso não compromete os restantes. A falha é registada no array errors, os registos que tiveram êxito continuam a ser aplicados ao motor e o job continua até à conclusão. Obtém um motor parcialmente configurado, mais uma lista precisa do que deve rever — não um motor vazio e um stack trace. O job falha como um todo quando a execução não produz nada com que trabalhar — por exemplo, quando todas as fontes falham no rastreio; esse caso de falha, e o respetivo payload provisioning.failed, está descrito em Entrega de webhook.

Como ler um resumo reduzido#

O resumo diz-lhe não só o que foi criado mas também, pelos seus totais, se a execução valeu a pena. Um count de 0 para um componente não é um erro — o resumo está bem formado e o motor existe — mas é informação. Três vozes da marca e doze itens de glossário já configuram um motor. Zero em tudo e um array errors vazio correspondem a um motor que regressou quase em branco, e o agente está a dizer-lhe que encontrou poucas regras para extrair.

Quando isso acontece, a causa está quase sempre a montante: as fontes enunciavam poucas regras concretas que o agente pudesse extrair. O resumo é onde dá por isso; Tipos de fonte é onde resolve o problema. A expectativa certa para a sua primeira execução é esta: o recibo reflete apenas aquilo que as suas fontes realmente disseram — um resumo rico significa fontes ricas, e um resumo reduzido significa que havia pouco para encontrar.

É por isso que o resumo é tão importante quanto o motor: permite-lhe verificar a configuração em vez de a presumir. Leia os totais, abra alguns registos pelos seus IDs, confirme que o agente captou o que esperava — registos normais que pode ler e editar, com um recibo que lhe diz exatamente o que deve verificar.

Próximos passos#

Tipos de fonte
O que faz com que uma fonte valha a pena ser submetida — e porque um resumo reduzido normalmente começa aqui.
Entrega de webhook
Receba o resumo no seu URL de callback quando a execução termina, e o payload de erro em caso de falha.
Progresso em direto (WebSocket)
Acompanhe em direto os passos de rastreio e configuração à medida que o motor é preenchido — e depois leia o resumo no webhook de conclusão.
Traduza com o seu novo motor
Quando os registos estiverem no lugar, distribua conteúdo por todos os idiomas através da API de Localization assíncrona.

Esta página foi útil?

Max PrilutskiyMax Prilutskiy·Atualizado há 4 dias·7 min de leitura