Como medimos realmente a qualidade da tradução e por que muitos benchmarks se equivocan

Em SyncWords trasladamos áudio em direto de um idioma a outro em tempo real. Em cada segundo de transmissão decidimos que sistema de tradução executar, para que combinação linguística, com que custo e com que tolerancia às falhas.

Por isso não podemos depender de apresentações comerciais nem de benchmarks proporcionados pelos fornecedores. Necesitamos saber, com confiança estadística, que motor obtiene melhores resultados para uma combinação linguística concreta no momento da evaluação.

Creamos um marco de evaluação próprio cuja metodologia incorpora mais matices dos que costumam mostrar os benchmarks.

Este artigo apresenta o abordagem técnico completo.

_________________________
‍
Solicite acesso gratuito à ferramenta que utilizamos para comparar motores de tradução automática
‍

Por que não bastan os benchmarks genéricos

O abordagem habitual para avaliar tradução automática consiste em escolher um conjunto de referência, executar vários sistemas e comunicar uma única pontuação.

O problema é que essa valor oculta grande parte do que importa em produção.

Não indica se o sistema tem fallado sem avisar, se uma saída correta no idioma padrão é inadecuada para uma público regional, cuánto cuesta ejecutarlo ao ritmo do fala em tempo real nem se a diferença com o sistema situado inmediatamente depois é estadísticamente significativa.

Nosso marco, construido sobre o conjunto WMT24++, mostra esses aspectos. Assim funciona.

O conjunto de dados: WMT24++

WMT24++ é um corpus paralelo poseditado que abarca 55 combinações linguísticas, do inglês ao idioma de destino, com 960 segmentos por combinação. As referências são posedições humanas, não traduções automáticas nem traduções sem rever, pelo que oferecem uma base consistente para avaliar qualidade.

Cada sistema traduz os 960 segmentos de cada combinação linguística compatível. Assim obtenemos 960 pontos de dados por celda de sistema e combinação, suficientes para calcular intervalos de confiança estrechos e detectar patrones de falha por segmento.

Dois métricas, não uma

A evaluação combina dois sinais de qualidade independientes. Nenhuma basta por sim sola.

MetricX24, basada em referências

MetricX-24-Hybrid-XL é uma métrica de qualidade de tradução automática aprendida por Google Research. Utiliza um modelo mT5 de aproximadamente 3.7 mil milhões de parámetros, entrenado para obter uma pontuação de qualidade a partir de ternas (source, hypothesis, reference). É uma métrica de referência com buen desempenho e mostra correlação com juicios humanos em condições controladas.

Não entanto, tem um sesgo conocido que nosso marco trata expressamente: favorece as salidas em uma variedade padrão neutra frente a traduções regionais auténticas.

na prática, MetricX pode penalizar uma tradução correta ao dialecto árabe egipcio frente ao árabe moderno padrão, ao francês de Quebec frente ao de París ou ao espanhol de México frente ao de Espanha. A métrica se entrenou principalmente com referências em variedades padrão e refleja essa composição.

Para uma empresa que trabalha em mercados como Latinoamérica, a comunidade hispana de Estados Unidos e Oriente Meio, a autenticidade dialectal pode determinar se o conteúdo é natural ou alheio. Por isso este sesgo impide depender de uma única métrica.

MetricX continua sendo uma sinal precisa e reproducible, mas precisa uma segunda evaluação complementaria.

GEMBA-MQM, evaluação através de LLM

GEMBA-MQM fornece essa segunda evaluação. Em vez de comparar a saída com uma tradução de referência, pide a um modelo linguístico avançado que anote diretamente os erros segundo a taxonomia MQM (Multidimensional Quality Metrics).

O evaluador recebe (source, reference, candidate) e deve identificar erros em seis dimensões: exatidão ou tradução incorreta, fluidez ou gramática, estilo, configuração regional ou formato e terminologia, cada um com um de três níveis de gravidade.

A pontuação do segmento é a combinação ponderada por gravidade do padrão WMT, com um máximo de 25:

Fourmula: score = min(25, Σ severity_weight(e))

Onde minor = 1, major = 5, critical = 25.

Dois decisões de design melhoram a fiabilidade prática.

Em primeiro local, o razonamento está habilitado para os evaluadores. Sem esta configuração, os LLM podem atribuir erros que não estão presentes e producir puntuações sem uma base clara na tradução. Com o razonamento habilitado (thinking_budget=-1 dinâmico para Gemini e reasoning_effort=medium para GPT), as anotações são coerentes e auditables.

Em segundo local, a instrução indica expressamente que as variantes regionais e dialectales são traduções válidas. Assim se compensa o sesgo de MetricX para o idioma padrão. Uma saída correta em árabe egipcio não deve penalizarse por utilizar essa variedade e o design da instrução de GEMBA o contempla.

Atualmente ejecutamos vários evaluadores à vez. Cada um escreve no seu próprio directorio de resultados; o relatourio detecta automaticamente todos os evaluadores e mostra uma columna por cada um. Uma coincidencia ampla fornece uma sinal com maior confiança. As divergencias assinalam onde a própria métrica mantiene incerteza, o que também é útil.

Que é GEMBA Rate? GEMBA Rate, mostrado como GEMBA Combined na ferramenta, é a pontuação media de todos os evaluadores ativos para uma celda concreta de sistema e combinação linguística. É a valor resumida de GEMBA. As columnas individuais, por exemplo GEMBA Gemini-3.1-Flash-Lite e GEMBA GPT-5.4-Mini, surgem ao lado para mostrar onde coinciden ou divergen os evaluadores. Se a tasa combinada é baja e as puntuações individuais são prouximas, ou sinal de qualidade tem mais confiança. Se divergen de forma notable, a tasa combinada deve interpretarse como orientativa e convém rever as columnas individuais.

Como interpretar ambas métricas

MetricX indica cuánto se aproxima a saída a uma referência padrão. GEMBA indica se um lector qualificado encontraria erros em ela.

Quando ambas métricas oferecem um resultado soulido, ou sinal é consistente. Se MetricX puntúa um sistema peor que GEMBA, pode ser tratadas de uma saída regional auténtica penalizada por MetricX. Se GEMBA puntúa peor que MetricX, a saída pode estar perto da referência e contener, aun assim, problemas reais de fluidez ou exatidão.

Ambas puntuações utilizam a mesmà escala da 0–25 e, nas dois, um valor menor é melhor.

Intervalos de confiança

Cada celda do relatourio mostra mean ± half-width de um intervalo de confiança bootstrap do 95% sobre a media dos segmentos.

Este dado recebe menos atenção da necessária em muitos relatourios. Com 960 segmentos, os intervalos do sistema costumam ser estrechos, em torno a ±0.02. Por combinação linguística são mais amplos, em torno de ±0.10, mas continuam aportando informação.

A consequência prática é que dois sistemas cujos intervalos se solapan estão empatados estadísticamente. Não é defendible situar um por encima do outro. O relatourio refleja esta limitação e não declara um ganador quando os dados não o respaldan.

Custo: cuánto cuesta executar o sistema ao ritmo do fala

A valor $/hr do relatourio não é uma tabla de preços de API. É uma estimação do custo de executar cada sistema como uma única transmissão de tradução em tempo real para um orador.

Usamos aproximadamente 750 caracteres por minuto como referência, a partir de uma cadencia media em inglês. A transmissão de produção mais rápida que hemos observado alcança uns 1,200 cpm; os custos aumentam linealmente.

Para os sistemas LLM, o custo se calcula por token a partir da instrução de produção e uma janela de contexto acumulada de 7 fragmentos, sem aplicar um desconto por caché de instruções, o que oferece uma estimação conservadora. Para os sistemas NMT, como DeepL, Google Translate e Amazon Translate, se calcula por carácter segundo tarifas públicas ou contratadas.

Uma precisão importante: os sistemas em modo párrafo mostram a estimação do modo oração, porque a produção nunca se ejecuta em modo párrafo. Estimar o modo párrafo reduciria artificialmente o custo e llevaria a decisões de implementação incorrectas.

Clasificação de falhas

Esta é uma parte que muitos benchmarks omiten.

Uma tradução deficiente obtiene uma pontuação alta. Um falha catastroufico, por exemplo um sistema que rechaza traduzir, entra em um bucle ou devuelve uma canal vacia, poderia inscrever-se como cero, distorsionar a media e ocultar o risco real.

Etiquetamos cada segmento com um ou mais indicadores de falha. Um segmento se considera fallido se se activa qualquer pessoa de os mesmos. As traduções deficientes que sim são salidas válidas não se marcan: surgem com puntuações altas em MetricX e GEMBA.

Falhas de API são os mais relevantes desde o ponto de vista operacional:

• stuck: bucle de descodificação degenerado. O modelo emite repetidamente o mesmo token, normalmente após receber texto de origem com caracteres repetidos (noooooOOOOoo, waaaaahoooo!!). Aumentar o orçamento de tokens produz mais tokens repetidos, não uma tradução melhor, pelo que limitamos a saída e a marcamos.
• refused: o modelo rechazou traduzir. Inclui o filtro contra memorização de Gemini (RECITATION), os filtros de segurança e as listas de bloqueo de conteúdo. O segmento queda inaccesible para esse sistema.
• api_erro: falhas de infraestrutura, como erros 4xx diferentes de 429 e tiempos de espera de gRPC agotados após os reintentos. É a categoria que convém rever quando se pergunta se a integração tem fallado.
• empty: a llamada à API foi correta, mas o modelo devolviu uma canal vacia. Se distingue das falhas anteriores.

Falhas de estructura de saída detectan modelos que técnicamente devolvieron conteúdo, mas não uma tradução:

• untranslated: a hipoutesis coincide com a origem. Omitimos segmentos breves, texto principalmente não alfabético e conteúdo que não deve ser traduzidas, como hashtags, URL ou menções.
• markdown_fence: o modelo envolviu a saída em bloques de código pese à instrução expresa de não fazê-lo.
• preamble: a saída começa com "Translation:", "Here's the translation" ou equivalentes regionais. O modelo não siguiu o formato de saída.
• reasoning_leak: o modelo expuso seu razonamento interno na saída. Isto indica uma configuração incorreta de um modelo de razonamento híbrido.
• multiple_alternatives: o modelo ofreciu várias opções em vez de uma soa tradução.
• translator_note: o modelo acrescentou uma nota final entre paréntesis.

A columna de tasa de falhas adiciona todos estes indicadores. Um sistema com uma tasa de falhas do 0% para uma combinação linguística concreta difiere de outro com um 2–3%, especialmente em uma transmissão em direto, onde um segmento fallido gera silencio ou conteúdo incorreto.

Que implica para as decisões de produção

Creamos este marco e o ofrecemos publicamente porque a selecção de um motor de tradução não é uma decisiun que se tome uma sola vez.

Mudam as capacidades dos modelos, surgem versiones, se modifican os preços e aumenta a cobertura de combinações linguísticas. O sistema adequado para inglês → espanhol faz seis meses pode não serlo hoje.

Ejecutamos a evaluação de forma continua. A ferramenta refleja o desempenho atual, não benchmarks archivados.

Para canais e serviços de streaming que operan em mercados multilingues, escolher um motor inadecuado para uma combinação linguística pode reduzir a qualidade, aumentar o custo ou elevar o risco de falha em conteúdo em direto. A decisiun exige dados, não suposições.

O marco está concebido para fornecer esses dados.

A ferramenta de comparação de motores de tradução automática é gratuita. Solicite acesso em syncwords.com ou contacte diretamente com nous para rever os dados de seus combinações linguísticas.

‍