A verificação de retrotradução detecta erros? Nós medimos.

O que é a verificação

Após traduzir cada string, KAERIS executa três verificações, duas determinísticas e uma baseada em modelo:

• Integridade do placeholderUma verificação em nível de regex de que cada {name}, %s, %(count)s e plural ICU na origem sobreviveu à tradução. Isso é um fato, não um julgamento.
• Integridade de tags e marcaçõesA mesma verificação determinística para marcações inline (<b>, <a>, <0> e tags de auto-fechamento), para que uma tag perdida ou reordenada seja detectada antes de ser enviada.
• Deriva de significado (o juiz)Cada tradução é independentemente traduzida de volta para o seu idioma por um modelo diferente, então um juiz compara o original com essa retrotradução e sinaliza mudanças genuínas de significado: uma negação invertida, um número errado, uma ação oposta.

A tradução e a retrotradução usam modelos diferentes, então nenhum modelo revisa o próprio trabalho.

Como testamos

Teste A: integridade de placeholder e tags (fim a fim, modelo real)

20 strings de UI realistas com uma mistura de estilos de placeholder (Rails %{name}, Python %(name)s, printf %.2f/%02d, .NET {0}, HTML <b>, i18next <0>, plurais ICU) foram traduzidas para quatro idiomas com sistemas de escrita diferentes (alemão, russo, japonês e árabe) pelo modelo gratuito de produção da época (DeepSeek V3; desde 1º de agosto de 2026 todos os planos, inclusive o gratuito, usaram o GPT-4o-mini e desde 5 de agosto de 2026 usam o Gemini 2.5 Flash-Lite, escolhido medindo candidatos dentro deste mesmo pipeline). Isso totaliza 80 traduções. Em seguida, executamos a verificação determinística na saída real do modelo.

Resultado: o modelo perdeu um placeholder em 3 de 80 traduções (~4%). A verificação marcou as 3: ela conta placeholders, não adivinha.

Teste B: o juiz de distorções (respostas certas conhecidas)

Criamos 28 retrotraduções que alteram claramente o significado (negação perdida, número errado, ação oposta, obrigatório→opcional, e similares) e 40 retrotraduções que mantêm o significado, mas reescrevem extensivamente (o caso difícil para falsos positivos). O juiz (Gemini 2.5 Flash, independente do modelo de tradução direta) as viu sem rótulos.

• Recall: 28/28 (100%)Cada erro de significado plantado foi sinalizado, com um motivo preciso ("negação perdida", "número errado", "significado oposto").
• Taxa de falsos positivos: 0/40 (0%)Nenhuma paráfrase reescrita corretamente foi sinalizada.

O que o benchmark também corrigiu

Esse teste revelou um bug real no nosso próprio pipeline: em um lote grande, a chamada ao juiz podia exceder o tempo limite e, como o erro era silenciado, não retornar nenhuma sinalização, subnotificando sem alarde em arquivos grandes. Agora dividimos as chamadas ao juiz em sublotes pequenos com nova tentativa, para que a verificação continue confiável qualquer que seja o tamanho do arquivo. A correção foi publicada junto com esta página.

Limites

O que esses números não cobrem:

• Este é um conjunto pequeno e controlado (148 casos), não uma amostra de tráfego em tempo real.
• As 28 distorções são mudanças claras de significado. Deriva sutil, como um tom alterado ou um modal suavizado, é mais difícil, e 100% aqui não significa 100% em tudo.
• Nós escrevemos os casos de teste, então as respostas certas são conhecidas. É um teste justo do juiz, não um estudo de campo sobre a qualidade da tradução.
• Um modelo de tradução direta (DeepSeek V3, o modelo gratuito na época) e um modelo juiz (Gemini 2.5 Flash); o conjunto de distorção é centrado no inglês.

O que a verificação entrega: cada alerta é um fato verificável (um placeholder perdido, uma negação invertida), não uma pontuação de confiança. Um modelo de tradução melhor gera menos alertas, não uma verificação mais fraca.