kazRush supera o NLLB 3.3B em BLEU com um modelo 17 vezes menor

Na tradução automática, é fácil cair em uma armadilha cara: reunir mais dados, escolher um modelo maior e esperar que a qualidade aumente sozinha. A equipe de tecnologias experimentais de IA da VK testou essa receita na tradução entre russo e cazaque e chegou a uma conclusão mais útil. O kazRush, um modelo com 197 milhões de parâmetros, superou o NLLB 3.3B em BLEU e chrF na tradução do russo para o cazaque. Não foi a escala por si só que funcionou, mas a combinação de um corpus cuidadosamente preparado, um tokenizador compacto e uma arquitetura ajustada ao volume de dados.

Primeiro os dados, depois os parâmetros

O corpus inicial foi montado a partir de OPUS, KazParC, WMT e Turkic Interlingua. Antes da filtragem, havia cerca de 12,3 milhões de pares de frases. Após a remoção de ruído, a verificação dos idiomas e o alinhamento, restaram 9.054.960 pares.

Um exemplo simples mostra o problema. Uma linha pode conter uma frase em russo à esquerda e, à direita, um trecho em cazaque sobre um tema semelhante, mas que não corresponde à sua tradução. Formalmente, ambos os textos estão escritos nos idiomas exigidos, portanto uma verificação convencional deixará o par passar. O modelo, porém, aprenderá uma correspondência falsa.

A equipe removeu sistematicamente duplicatas exatas, marcação HTML e caracteres indesejados; aplicou normalização Unicode; identificou o idioma de cada frase com o fastText; e comparou a proximidade semântica usando o LaBSE. Pares com pontuação inferior a 0,4 foram descartados. Também foram verificados números, a proporção entre os comprimentos e a participação de letras e algarismos em cada linha. Para algumas fontes, foi necessário criar regras próprias: um filtro universal não foi suficiente.

A busca por duplicatas aproximadas produziu um resultado curioso. Seria natural supor que linhas semelhantes apenas poluíssem o corpus. No entanto, a remoção delas reduziu a qualidade do modelo. Uma possível explicação é que, quando há escassez de dados, pequenas variações da mesma expressão funcionam como aumento natural de dados. Por isso, o conjunto final removeu repetições exatas, mas preservou duplicatas aproximadas.

Um modelo compacto em vez de uma corrida por tamanho

Para os dois idiomas, foi treinado um tokenizador SentencePiece compartilhado com 8.000 unidades de subpalavras. A variante com 16.000 apresentou um resultado ligeiramente pior. É um lembrete importante: um vocabulário maior nem sempre é útil, especialmente para um idioma de morfologia rica e um corpus limitado.

A base do modelo foi um Transformer com codificador e decodificador no estilo do T5, mas sem pesos pré-treinados. A configuração final recebeu 12 camadas tanto no codificador quanto no decodificador, estado oculto de tamanho 512 e blocos feed-forward de tamanho 4.096. No total, cerca de 197 milhões de parâmetros.

Os autores compararam o modelo com T5-Small, T5-Base e T5-Large. O modelo de 738 milhões de parâmetros não foi o melhor: na direção russo-cazaque, alcançou 15,8 BLEU, enquanto o kazRush chegou a 16,2. Em chrF, o resultado foi 51,9 contra 51,6; em COMET, 0,8836 contra 0,8804. Em outras palavras, aumentar o número de parâmetros em quase quatro vezes não compensou.

Onde o resultado é realmente forte

No conjunto devtest do FLORES+, o kazRush foi comparado à família NLLB. Na tradução do russo para o cazaque, o modelo obteve 16,2 BLEU e 51,8 chrF, superando o NLLB 3.3B, com 15,6 e 50,7. Em COMET, porém, o NLLB maior permaneceu à frente: 0,889 contra 0,883. Portanto, não é possível falar em vitória absoluta: métricas diferentes avaliam propriedades diferentes da tradução.

Na direção inversa, o kazRush também superou o NLLB distilled 600M, mas ficou atrás das versões do NLLB com 1,3 bilhão e 3,3 bilhões de parâmetros. Trata-se de uma ferramenta especializada, e não de uma substituição universal para grandes modelos multilíngues.

A conclusão prática vale muito além da tradução. Preserve a proveniência de cada registro, meça o efeito de cada filtro e não remova dados apenas porque uma regra parece razoável. Primeiro, faça ablações no corpus, no tokenizador e na arquitetura — e só depois pague por capacidade computacional adicional. Às vezes, a melhor forma de reduzir um modelo é observar com mais atenção os dados usados para alimentá-lo.