Todos os pipelines de localização baseados em RAG têm o mesmo ponto cego

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

O padrão é universal: gerar embeddings do texto de entrada, fazer uma pesquisa por similaridade de cosseno num banco de termos, injetar os resultados top-k no prompt. O resultado está gramaticalmente correto. A terminologia está errada. O erro é invisível, a menos que alguém fale ambas as línguas e conheça o glossário.

Nós próprios começámos por construir esta versão ingénua. Depois medimos o recall da recuperação com glossários de produção — e descobrimos que o sistema estava a falhar a maioria dos termos aplicáveis em payloads reais.

Porque é que os embeddings ao nível da frase falham os termos de glossário?#

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

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" é transformada em embedding, o vetor resultante capta 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", dilui-se na representação ao nível da frase.

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

O problema é de granularidade: representações ao nível da frase a consultar alvos ao nível da expressão. O modelo de embeddings representa fielmente 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 isto da forma mais difícil. Em payloads de produção — objetos JSON aninhados com 20–50 chaves e valores de comprimentos variáveis — a recuperação ao nível da frase estava a falhar a maioria dos termos de glossário aplicáveis. O pedido de localização era concluído sem problemas. O resultado lia-se com fluidez. Mas "localization engine" estava a tornar-se "translation tool" — gramaticalmente válido, semanticamente próximo, terminologicamente errado. E o pipeline reportava sucesso.

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

A solução acabou por ser decompor a entrada em unidades ao nível da expressão antes de gerar embeddings. Cada valor de string passa a ser um conjunto de janelas de n-gramas sobrepostas:

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 torna-se uma consulta de recuperação independente. "Localization engine" consulta o glossário como uma expressão autónoma — e encontra a correspondência com elevada similaridade.

O pipeline de decomposição:

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

Um parágrafo de 50 palavras produz aproximadamente 150 n-gramas. Um payload típico de API com 20 chaves produz 1000–3000 expressões pesquisáveis. Cada expressão é transformada em embedding de forma independente, e cada embedding executa uma consulta de vizinho mais próximo ao índice vetorial do glossário.

Medimos a diferença nos mesmos payloads de produção que expuseram o problema original. Os termos de glossário passam agora a corresponder independentemente do contexto frásico em que aparecem — um termo de 2 palavras escondido numa descrição de produto com 200 palavras é recuperado com o mesmo recall que um rótulo autónomo.

Como funciona a recuperação adaptativa para glossários de diferentes dimensões?#

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

Um motor de localização configurado com 8 termos de glossário resolve mais depressa com injeção direta — uma consulta à base de dados, determinística, abaixo de um milissegundo. Um motor de localização com 2000 termos requer vector search — os limites da janela de contexto e a diluição da relevância tornam a injeção completa impossível.

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

O limiar de cardinalidade que separa preload de search é definido a partir do profiling de latência no tráfego de produção e ajustado à medida que mudam o desempenho do modelo de embeddings, a distribuição dos tamanhos de glossário e as características da infraestrutura. O valor inicial que colocámos em produção durou cerca de três semanas até a telemetria indicar que devia ser ajustado. Desde então, foi revisto várias vezes — descobrimos que o limiar ótimo deriva ao longo do tempo, à medida que os motores acumulam termos de glossário e as características dos modelos de embeddings evoluem entre atualizações dos fornecedores.

A latência da recuperação escala com a complexidade do glossário, não com o tamanho do payload. Um motor de localização com 10 termos resolve em milissegundos de um só dígito, independentemente do comprimento da entrada. Um motor de localização com 500 termos usa o pipeline completo de decomposição, mas continua dentro do orçamento de latência de uma etapa durável de workflow em segundo plano.

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

Cada embedding de n-grama consulta o índice vetorial para encontrar os vizinhos mais próximos acima de um limiar de similaridade. As 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:

• Demasiado permissivo: termos não relacionados entram no prompt. O modelo vê contexto de glossário que não se aplica à entrada e, ocasionalmente, segue-o — produzindo resultados com terminologia de um domínio não relacionado.
• Demasiado restritivo: variantes legítimas de formulação e formas morfológicas ficam excluídas. "Deploying" deixa de corresponder à entrada de glossário para "deploy." O recall desce.

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

O limiar é agora calibrado continuamente com base em pontuações de qualidade por par de idiomas provenientes de um pipeline de pontuação independente. Quando o sistema de pontuação deteta um aumento no incumprimento do glossário (termos presentes na entrada, mas ausentes no resultado), significa que o recall da recuperação degradou e o limiar é alargado. Quando a pontuação deteta que o modelo está a aplicar terminologia irrelevante, a injeção de falsos positivos aumentou e o limiar é apertado.

Esta calibração corre semanalmente. Tem de correr — o comportamento dos modelos de embeddings muda entre atualizações dos fornecedores, a distribuição dos glossários muda à medida que as equipas adicionam termos e as características do texto de entrada evoluem à medida que os produtos crescem.

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

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

Termos não traduzíveis — strings na língua de origem que têm de aparecer inalteradas no resultado de destino. Nomes de marcas, identificadores técnicos, nomes de produtos. O modelo preserva-os literalmente.

Traduções personalizadas — mapeamentos origem→destino que se sobrepõem ao próprio juízo do modelo. "Localization engine" tem de se tornar "moteur de localisation." O modelo trata-os como restrições lexicais inegociáveis.

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

A distinção é importante no momento da pontuação: o modelo de pontuação independente verifica se os termos não traduzíveis foram preservados inalterados e se as traduções personalizadas foram aplicadas exatamente. Dois critérios de verificação para dois tipos de restrição. Descobrimos cedo que juntá-los numa única categoria de "glossário" tornava a pontuação pouco fiável — um termo preservado literalmente quando deveria ter sido traduzido (ou vice-versa) seria pontuado como correto numa verificação unificada.

Como validar a qualidade da localização em línguas que não fala?#

Todo o pipeline de recuperação e localização pode correr sem erro e, ainda assim, produzir resultados terminologicamente incorretos. Um termo de glossário falhado não gera qualquer sinal de erro. Uma tradução personalizada mal aplicada devolve um 200. O pipeline funciona. O resultado está errado.

Esta é a lacuna de observabilidade da localização que a maioria das equipas nunca fecha.

A recuperação está acoplada a uma pontuação assíncrona independente. Depois de um pedido de localização ficar concluído, modelos de pontuação separados avaliam o resultado face à configuração do motor de localização:

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

Os modelos de pontuação correm numa infraestrutura diferente da do modelo de localização. Funcionam de forma assíncrona, em workflows em segundo plano, acionados após cada pedido que passa por um motor de localização com a pontuação ativada. Um modelo localiza; outro pontua. A avaliação entre modelos elimina o problema da autoavaliação.

Os resultados da pontuação são reinjetados na calibração da recuperação:

1. A pontuação deteta um aumento da não conformidade com o glossário para um par de idiomas
2. A investigação revela que o recall da recuperação caiu — o limiar desviou-se face à distribuição atual do glossário
3. O limiar é ajustado; o recall recupera; as pontuações de conformidade estabilizam

É este ciclo que torna o sistema autocorretivo. A pontuação dá à recuperação a observabilidade que, por si só, lhe falta. Sem isso, as equipas estão a enviar conteúdo localizado para idiomas que não falam, sem qualquer sinal de que o glossário que criaram está realmente a ser aplicado.

Porque é que o recall da recuperação se acumula ao longo do tempo?#

Cada pedido de localização que aplica corretamente os termos do glossário reforça a consistência terminológica em todo o produto. Cada pedido que falha um termo introduz desvio — uma superfície diz "motor de localização", outra diz "ferramenta de localização", uma terceira diz "módulo de localização". Ao longo de 30 idiomas e lançamentos semanais, estas inconsistências acumulam-se.

A diferença entre um recall de recuperação alto e baixo não é um delta de qualidade por pedido. É um mecanismo cumulativo de consistência. Um recall alto significa que o glossário é aplicado de forma uniforme em cada superfície, cada idioma, cada lançamento. Um recall baixo significa que o glossário é acionado apenas ocasionalmente — estruturalmente, isso equivale a não ter glossário nenhum, apenas demora mais tempo a degradar-se.

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

O problema de recuperação descrito aqui não é específico de uma implementação. É estrutural em qualquer sistema que tente fazer localização com sensibilidade ao glossário usando pesquisa baseada em embeddings. O desfasamento de granularidade entre representações de entrada ao nível da frase e alvos de glossário ao nível da expressão existe independentemente do modelo de embeddings, da base de dados vetorial ou do LLM que gera o resultado.

As equipas que desenvolvem automação de localização enfrentam uma escolha: aceitar a recuperação ao nível da frase com a sua lacuna invisível de recall, ou construir a infraestrutura de decomposição e calibração que a fecha. O segundo caminho exige três sistemas — decomposição em n-gramas, recuperação adaptativa e um ciclo de pontuação que alimenta a gestão de limiares. Cada sistema tem a sua própria cadência operacional: a lógica de decomposição evolui à medida que os formatos de entrada mudam, os limiares de recuperação deslocam-se à medida que os glossários crescem e os critérios de pontuação são refinados à medida que as equipas de localização aprendem quais são as dimensões que importam para o seu conteúdo.

A localização aumentada por recuperação com qualidade de produção é uma prática contínua de engenharia — um sistema que é construído, instrumentado, observado e afinado de forma contínua. A disciplina de engenharia de localização que está a emergir em torno deste trabalho reflete a realidade operacional: a infraestrutura de localização exige a mesma atenção contínua que os serviços de backend, os pipelines de CI/CD e as stacks de observabilidade.

Próximos passos#

FAQ#

O que é a localização aumentada por recuperação (RAL)? A localização aumentada por recuperação enriquece cada pedido 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. Num estudo controlado com cinco fornecedores de LLM e cinco línguas europeias, o RAL reduziu os erros de terminologia em 17–45% face aos mesmos modelos sem enriquecimento de contexto.

Porque é que o embedding ao nível da frase falha termos do glossário? Os termos do glossário têm, normalmente, 1 a 3 palavras. Quando são incorporados como parte de uma frase completa, diluem-se no vetor semântico ao nível da frase. O embedding capta o significado da frase como um todo — "motor de localização" dentro de "Configure o motor de localização para produção" não é registado de forma independente. A similaridade de cosseno entre o vetor da frase e a entrada do glossário fica abaixo do limiar de recuperação.

Como é que a decomposição em n-gramas melhora o recall da recuperação? Em vez de incorporar cadeias de entrada completas, o sistema decompõe o texto em expressões sobrepostas de 1 grama, 2 gramas e 3 gramas antes de as incorporar. Cada expressão torna-se uma consulta de recuperação independente. Um termo de glossário com 2 palavras, escondido num parágrafo de 200 palavras, obtém o mesmo recall que um rótulo autónomo — porque é consultado independentemente do contexto em redor.

Quantos modos de recuperação utiliza o sistema? Três. Omitir (zero itens de glossário — não é necessária recuperação), pré-carregamento (abaixo de um limiar de cardinalidade — carregar diretamente todos os itens) e pesquisa vetorial (acima do limiar — decomposição completa em n-gramas e embedding). O modo é selecionado por pedido com base na cardinalidade do glossário para o par de idiomas específico.

Como é mantido o limiar de similaridade? O limiar é calibrado semanalmente com base em pontuações de qualidade por par de idiomas, provenientes de um pipeline de pontuação independente. Quando a não conformidade com o glossário mostra uma tendência de subida, o limiar é alargado para melhorar o recall. Quando termos irrelevantes se infiltram nos prompts, o limiar é apertado. Pares de idiomas diferentes exigem limiares diferentes devido às variações na distância morfológica.

Como funciona a pontuação entre modelos para a qualidade da localização? Depois de cada pedido de localização estar concluído, um modelo separado — a correr numa 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 cumpridos. Um modelo localiza; outro pontua. Isto elimina o viés de autoavaliação e cria a observabilidade que a recuperação, por si só, não tem.

O que acontece quando o recall da recuperação do glossário é baixo? Um recall baixo da recuperação significa que o glossário é acionado de forma inconsistente — uma superfície recebe o termo correto, outra não. Ao longo de mais de 30 idiomas e lançamentos semanais, estas inconsistências acumulam-se e transformam-se em desvio terminológico. O glossário existe, mas não impõe conformidade. Ao longo de meses, isto é estruturalmente equivalente a não ter glossário nenhum.

O que é a lacuna de observabilidade da localização? Um pipeline de localização pode correr sem erros e produzir um resultado terminologicamente incorreto. Termos do glossário falhados não produzem qualquer sinal de erro — a API devolve 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 conformidade com o glossário em cada pedido.