Toda pipeline de localização baseada em RAG tem o mesmo ponto cego

Se uma pipeline de localização usa retrieval augmented generation para injetar termos de glossário na janela de contexto do modelo, ela tem um problema de recall de recuperação que nunca foi medido.

O padrão é universal: gerar embeddings do texto de entrada, fazer uma busca por similaridade de cosseno em um banco de termos e injetar os resultados top-k no prompt. A saída fica gramaticalmente correta. A terminologia fica errada. O erro é invisível, a menos que alguém fale os dois idiomas e conheça o glossário.

Nós também começamos com essa versão ingênua. Depois, medimos o recall de recuperação em relação aos glossários de produção — e descobrimos que o sistema estava deixando passar a maioria dos termos aplicáveis em payloads reais.

Por que embeddings de sentença não encontram termos de glossário?#

Um termo de glossário tem de 1 a 3 palavras. "engine de localização." "Token de acesso." "Pipeline de deploy."

O texto de entrada é um objeto JSON com valores que vão de duas palavras (o rótulo de um botão) a duzentas palavras (uma descrição de produto). Quando a string completa "Configure the localization engine for production deployment" recebe embedding, o vetor resultante captura o significado semântico da frase — algo sobre configuração e sistemas de produção. A expressão relevante para o glossário, "localization engine", se dilui na representação em nível de sentença.

A similaridade de cosseno entre esse vetor de sentença e a entrada de glossário "localization engine" fica na faixa de 0,6–0,7. Abaixo do limiar de recuperação. O termo está na entrada. O sistema de recuperação não o encontra.

O problema é de granularidade: representações em nível de sentença consultando alvos em nível de frase. O modelo de embedding representa com fidelidade o significado da frase como um todo. A terminologia que a compõe não ocupa nenhuma região independente no espaço vetorial.

Descobrimos isso da pior forma. Em payloads de produção — objetos JSON aninhados com 20 a 50 chaves e valores de comprimentos variados — a recuperação em nível de sentença estava deixando passar a maioria dos termos de glossário aplicáveis. A solicitação de localização era concluída sem problemas. A saída soava fluida. Mas "localization engine" estava virando "translation tool" — gramaticalmente válido, semanticamente próximo, terminologicamente errado. E a pipeline reportava sucesso.

Como a decomposição em n-gramas corrige a recuperação de glossário?#

A solução acabou sendo decompor a entrada em unidades no nível de frase antes de gerar embeddings. Cada valor de string se torna um conjunto de janelas sobrepostas de n-gramas:

Input: "Configure the localization engine for production"

1-grams: [configure, the, localization, engine, for, production]
2-grams: [configure the, the localization, localization engine,
          engine for, for production]
3-grams: [configure the localization, the localization engine,
          localization engine for, engine for production]

Cada n-grama se torna uma consulta independente de recuperação. "Localization engine" consulta o glossário como uma frase autônoma — e encontra sua correspondência com alta similaridade.

A pipeline de decomposição:

1. Extrair recursivamente todos os valores de string de estruturas JSON aninhadas
2. Dividir em sentenças, remover HTML e anotações de marcação
3. Normalizar espaços em branco, remover aspas externas e desfazer escapes de formatação
4. Gerar frases sobrepostas de 1 grama, 2 gramas e 3 gramas a partir de cada sentença

Um parágrafo de 50 palavras gera aproximadamente 150 n-gramas. Um payload típico de API com 20 chaves gera de 1.000 a 3.000 frases pesquisáveis. Cada frase recebe embedding de forma independente, e cada embedding executa uma consulta de vizinho mais próximo no índice vetorial do glossário.

Medimos a diferença nos mesmos payloads de produção que expuseram o problema original. Agora, os termos do glossário são encontrados independentemente do contexto ao redor — um termo de 2 palavras escondido em uma descrição de produto com 200 palavras é recuperado com o mesmo recall que um rótulo isolado.

Como a recuperação adaptativa funciona para diferentes tamanhos de glossário?#

A decomposição em n-gramas e o embedding em lote são a abordagem correta para glossários grandes. Para glossários pequenos, isso se mostrou um desperdício computacional.

Um engine de localização configurado com 8 termos de glossário responde mais rápido com injeção direta — uma consulta ao banco de dados, determinística, em menos de um milissegundo. Um engine de localização com 2.000 termos exige vector search — os limites da janela de contexto e a diluição de relevância tornam a injeção completa inviável.

Há três modos de recuperação por solicitação, selecionados com base na cardinalidade do glossário para o par de idiomas:

O limiar de cardinalidade que separa preload de search é derivado do profiling de latência no tráfego de produção e ajustado conforme mudam o desempenho do modelo de embedding, a distribuição de tamanho dos glossários e as características da infraestrutura. O valor inicial que colocamos em produção durou aproximadamente três semanas, até a telemetria indicar que precisava ser ajustado. Desde então, ele já mudou várias vezes — descobrimos que o limiar ideal se desloca à medida que os engines acumulam termos de glossário e as características dos modelos de embedding evoluem entre atualizações dos provedores.

A latência de recuperação escala com a complexidade do glossário, não com o tamanho do payload. Um engine de localização com 10 termos responde em poucos milissegundos, independentemente do tamanho da entrada. Um engine de localização com 500 termos usa a pipeline completa de decomposição, mas ainda fica dentro do orçamento de latência de uma etapa durável de workflow em segundo plano.

Como o limiar de similaridade é calibrado para a recuperação de glossário?#

Cada embedding de n-grama consulta o índice vetorial em busca dos vizinhos mais próximos acima de um limiar de similaridade. Correspondências abaixo desse limiar são descartadas como ruído.

O limiar determina, ao mesmo tempo, a precisão e o recall da recuperação:

• Permissivo demais: termos não relacionados vazam para o prompt. O modelo vê contexto de glossário que não se aplica à entrada e, ocasionalmente, o segue — produzindo uma saída que usa terminologia de um domínio não relacionado.
• Rígido demais: variantes legítimas de redação e formas morfológicas ficam de fora. "Deploying" deixa de corresponder à entrada de glossário para "deploy". O recall cai.

Descobrimos que o limiar certo varia por par de idiomas. A recuperação de inglês→alemão tem distribuições de similaridade diferentes de inglês→japonês, em que a distância morfológica entre n-gramas de origem e entradas de glossário difere estruturalmente. Um único limiar global estava produzindo recall inconsistente entre os pares de idiomas que medimos.

Agora, o limiar é calibrado continuamente com base em pontuações de qualidade por par de idiomas vindas de uma pipeline independente de pontuação. Quando o sistema de pontuação detecta um aumento na não conformidade com o glossário (termos presentes na entrada, mas ausentes na saída), o recall da recuperação se degradou e o limiar é afrouxado. Quando a pontuação detecta que o modelo está aplicando terminologia irrelevante, a injeção de falsos positivos aumentou e o limiar é apertado.

Essa calibração roda semanalmente. E precisa rodar — o comportamento dos modelos de embedding muda entre atualizações dos provedores, a distribuição dos glossários muda à medida que as equipes adicionam termos, e as características do texto de entrada evoluem conforme os produtos crescem.

Como os termos de glossário recuperados são injetados no modelo de localização?#

Os itens de glossário recuperados se dividem em duas classes de restrição, com comportamentos de aplicação diferentes no prompt de sistema do modelo:

Termos não traduzíveis – strings no idioma de origem que devem aparecer inalteradas na saída no idioma de destino. Nomes de marca, identificadores técnicos, nomes de produto. O modelo preserva esses elementos literalmente.

Traduções personalizadas – mapeamentos origem→destino que se sobrepõem ao próprio julgamento do modelo. "Localization engine" deve se tornar "moteur de localisation". O modelo trata isso como restrições lexicais inegociáveis.

As duas classes são injetadas no prompt de sistema como regras com precedência explícita sobre o comportamento padrão do modelo. A hierarquia do prompt impõe conformidade com o glossário acima das preferências linguísticas do modelo.

Essa distinção importa na hora da pontuação: o modelo independente de avaliação verifica se os termos não traduzíveis foram preservados sem alteração e se as traduções personalizadas foram aplicadas exatamente como definido. São dois critérios de verificação para dois tipos de restrição. Descobrimos cedo que juntar tudo em uma única categoria de "glossário" tornava a pontuação pouco confiável — um termo preservado literalmente quando deveria ter sido traduzido (ou vice-versa) seria marcado como correto em uma verificação unificada.

Como validar a qualidade da localização em idiomas que você não fala?#

Toda a pipeline de recuperação e localização pode ser executada sem erro e ainda assim produzir uma saída terminologicamente incorreta. Um termo de glossário perdido não gera nenhum sinal de erro. Uma tradução personalizada aplicada incorretamente retorna 200. A pipeline é bem-sucedida. A saída está errada.

Essa é a lacuna de observabilidade em localização que a maioria das equipes nunca fecha.

A recuperação é acoplada a uma pontuação assíncrona e independente. Depois que uma solicitação de localização é concluída, modelos de avaliação separados avaliam a saída em relação à configuração do engine de localização:

• Conformidade com o glossário – os termos não traduzíveis foram preservados? As traduções personalizadas foram aplicadas exatamente?
• Conformidade com instrução – as regras específicas do idioma foram seguidas?
• Critérios de pontuação personalizados – dimensões de qualidade por engine definidas pela equipe de localização

Os modelos de pontuação rodam em uma infraestrutura diferente da usada pelo modelo de localização. Eles operam de forma assíncrona em workflows em segundo plano, acionados após cada solicitação que passa por um engine de localização com pontuação ativada. Um modelo localiza; outro pontua. A avaliação entre modelos elimina o problema da autoavaliação.

Os resultados de pontuação retroalimentam a calibração do retrieval:

1. A pontuação detecta uma tendência de alta na não conformidade com o glossário para um par de idiomas
2. A investigação revela que o recall do retrieval caiu — o limite se desviou em relação à distribuição atual do glossário
3. O limite é ajustado; o recall se recupera; as pontuações de aderência se estabilizam

É esse ciclo que torna o sistema autocorretivo. A pontuação cria a observabilidade que o retrieval, sozinho, não oferece. Sem isso, as equipes publicam conteúdo localizado em idiomas que não falam, sem nenhum sinal de que o glossário que construíram está realmente sendo aplicado.

Por que o recall do retrieval se acumula ao longo do tempo?#

Cada solicitação de localização que aplica corretamente os termos do glossário reforça a consistência terminológica em todo o produto. Cada solicitação que deixa escapar um termo introduz deriva — uma superfície diz "engine de localização", outra diz "ferramenta de localização", uma terceira diz "módulo de localização". Em 30 idiomas e lançamentos semanais, essas inconsistências se acumulam.

A diferença entre recall alto e baixo no retrieval não é uma variação de qualidade por solicitação. É um mecanismo cumulativo de consistência. Recall alto significa que o glossário é aplicado de forma uniforme em cada superfície, cada idioma, cada lançamento. Recall baixo significa que o glossário só entra em ação de vez em quando — o que é estruturalmente equivalente a não ter glossário nenhum, só que com uma degradação mais lenta.

O que isso significa para a engenharia de localização#

O problema de retrieval descrito aqui não é específico de uma única implementação. Ele é estrutural em qualquer sistema que tente fazer localização com reconhecimento de glossário usando busca baseada em embeddings. A incompatibilidade de granularidade entre representações de entrada em nível de sentença e alvos de glossário em nível de frase existe independentemente de qual modelo de embedding, qual banco de dados vetorial ou qual LLM gere a saída.

As equipes que desenvolvem automação de localização enfrentam uma escolha: aceitar o retrieval em nível de sentença com sua lacuna invisível de recall ou construir a infraestrutura de decomposição e calibração que fecha essa lacuna. O segundo caminho exige três sistemas — decomposição em n-gramas, retrieval adaptativo e um ciclo de pontuação que retroalimenta o gerenciamento de limites. Cada sistema tem seu próprio ritmo operacional: a lógica de decomposição evolui conforme os formatos de entrada mudam, os limites de retrieval se deslocam à medida que os glossários crescem e os critérios de pontuação são refinados conforme as equipes de localização aprendem quais dimensões importam para seu conteúdo.

Localização com retrieval aumentado em qualidade de produção é uma prática contínua de engenharia — um sistema que é construído, instrumentado, observado e ajustado de forma contínua. A disciplina de engenharia de localização que está surgindo em torno desse trabalho reflete a realidade operacional: a infraestrutura de localização exige a mesma atenção constante que serviços de backend, pipelines de CI/CD e stacks de observabilidade.

Próximos passos#

Perguntas frequentes#

O que é retrieval augmented localization (RAL)? Retrieval augmented localization enriquece cada solicitação de localização com termos do glossário, regras de voz da marca e instruções específicas do idioma no momento da inferência — o mesmo padrão de recuperar e injetar por trás do RAG, aplicado à localização. Em um estudo controlado com cinco provedores de LLM e cinco idiomas europeus, o RAL reduziu os erros de terminologia em 17–45% em comparação com os mesmos modelos sem enriquecimento de contexto.

Por que o embedding em nível de sentença deixa passar termos do glossário? Os termos do glossário normalmente têm de 1 a 3 palavras. Quando são incorporados como parte de uma sentença completa, eles se dissolvem no vetor semântico da sentença. O embedding captura o significado da sentença como um todo — "engine de localização" dentro de "Configure o engine de localização para produção" não é registrado de forma independente. A similaridade de cosseno entre o vetor da sentença e a entrada do glossário cai abaixo do limite de retrieval.

Como a decomposição em n-gramas melhora o recall do retrieval? Em vez de incorporar strings de entrada completas, o sistema decompõe o texto em frases sobrepostas de 1 grama, 2 gramas e 3 gramas antes de gerar embeddings. Cada frase se torna uma consulta independente de retrieval. Um termo de glossário de 2 palavras escondido em um parágrafo de 200 palavras tem o mesmo recall que um rótulo isolado — porque é consultado independentemente do contexto ao redor.

Quantos modos de retrieval o sistema usa? Três. Skip (zero itens de glossário — nenhum retrieval necessário), preload (abaixo de um limite de cardinalidade — todos os itens são carregados diretamente) e busca vetorial (acima do limite — decomposição completa em n-gramas e embedding). O modo é selecionado por solicitação com base na cardinalidade do glossário para o par de idiomas específico.

Como o limite de similaridade é mantido? O limite é calibrado semanalmente com base nas pontuações de qualidade por par de idiomas vindas de um pipeline independente de pontuação. Quando a não conformidade com o glossário mostra tendência de alta, o limite é afrouxado para melhorar o recall. Quando termos irrelevantes vazam para os prompts, o limite é apertado. Diferentes pares de idiomas exigem limites diferentes devido às variações de distância morfológica.

Como funciona a pontuação entre modelos para avaliar a qualidade da localização? Depois que cada solicitação de localização é concluída, um modelo separado — rodando em uma infraestrutura diferente — avalia se os termos do glossário foram aplicados corretamente, se as instruções específicas do idioma foram seguidas e se os critérios de qualidade personalizados foram atendidos. Um modelo localiza; outro pontua. Isso elimina o viés de autoavaliação e cria a observabilidade que o retrieval, sozinho, não oferece.

O que acontece quando o recall de retrieval do glossário é baixo? Recall baixo no retrieval significa que o glossário entra em ação de forma inconsistente — uma superfície recebe o termo correto, outra não. Em mais de 30 idiomas e lançamentos semanais, essas inconsistências se acumulam e viram deriva terminológica. O glossário existe, mas não impõe consistência. Ao longo de meses, isso é estruturalmente equivalente a não ter glossário.

O que é a lacuna de observabilidade da localização? Um pipeline de localização pode ser executado sem erro e produzir uma saída terminologicamente incorreta. Termos do glossário que passam despercebidos não geram nenhum sinal de erro — a API retorna 200, a tradução é gramaticalmente válida. A lacuna de observabilidade é o espaço entre "o pipeline foi bem-sucedido" e "a terminologia está correta". A pontuação independente fecha essa lacuna ao medir a aderência ao glossário em cada solicitação.