kazRush supera a NLLB 3.3B en BLEU con un modelo 17 veces más pequeño

En traducción automática es fácil caer en una trampa costosa: recopilar más datos, elegir un modelo más grande y esperar que la calidad aumente por sí sola. El equipo de tecnologías experimentales de IA de VK puso a prueba esta receta en la traducción ruso-kazaja y llegó a una conclusión más útil. El modelo kazRush, con 197 millones de parámetros, superó a NLLB 3.3B en BLEU y chrF al traducir del ruso al kazajo. Lo que funcionó no fue la escala por sí misma, sino la combinación de un corpus preparado con cuidado, un tokenizador compacto y una arquitectura ajustada al volumen de datos.

Primero los datos, después los parámetros

El corpus inicial se reunió a partir de OPUS, KazParC, WMT y Turkic Interlingua. Antes del filtrado contenía unos 12,3 millones de pares de oraciones. Tras eliminar ruido, comprobar los idiomas y alinear los datos, quedaron 9.054.960 pares.

Un ejemplo sencillo muestra el problema. Una fila puede contener a la izquierda una oración en ruso y, a la derecha, un fragmento en kazajo sobre un tema parecido, pero que no es su traducción. Formalmente, ambos textos están escritos en los idiomas requeridos, por lo que una comprobación convencional dejará pasar el par. Sin embargo, el modelo aprenderá una correspondencia falsa.

El equipo eliminó sistemáticamente duplicados exactos, marcado HTML y caracteres basura; aplicó normalización Unicode; determinó el idioma de cada oración mediante fastText; y comparó la similitud semántica con LaBSE. Se descartaron los pares con una puntuación inferior a 0,4. También se comprobaron los números, la relación entre longitudes y la proporción de letras y dígitos en cada línea. Para determinadas fuentes fue necesario escribir reglas propias: un filtro universal no bastaba.

La búsqueda de duplicados cercanos produjo un resultado curioso. Podría parecer que las líneas similares solo contaminan el corpus. Sin embargo, al eliminarlas disminuyó la calidad del modelo. Una posible explicación es que, cuando escasean los datos, pequeñas variaciones de una misma expresión funcionan como aumento natural de datos. Por eso, en el conjunto final se eliminaron las repeticiones exactas, pero se conservaron los duplicados cercanos.

Un modelo compacto en lugar de una carrera de tamaños

Para los dos idiomas se entrenó un tokenizador SentencePiece compartido con 8.000 unidades de subpalabras. La variante de 16.000 obtuvo un resultado ligeramente peor. Es un recordatorio importante: un vocabulario mayor no siempre resulta útil, sobre todo para un idioma con una morfología rica y un corpus limitado.

La base del modelo fue un Transformer con codificador y decodificador al estilo de T5, pero sin pesos preentrenados. La configuración final incluyó 12 capas tanto en el codificador como en el decodificador, un estado oculto de tamaño 512 y bloques feed-forward de tamaño 4.096. En total, unos 197 millones de parámetros.

Los autores lo compararon con T5-Small, T5-Base y T5-Large. El modelo de 738 millones de parámetros no fue el mejor: en la dirección ruso-kazajo obtuvo 15,8 BLEU, mientras que kazRush alcanzó 16,2. En chrF, el resultado fue de 51,9 frente a 51,6, y en COMET, de 0,8836 frente a 0,8804. En otras palabras, multiplicar casi por cuatro el número de parámetros no compensó.

Dónde es realmente sólido el resultado

En el conjunto devtest de FLORES+, kazRush se comparó con la familia NLLB. En la traducción del ruso al kazajo, el modelo obtuvo 16,2 BLEU y 51,8 chrF, por encima de NLLB 3.3B, que registró 15,6 y 50,7. Sin embargo, en COMET el NLLB de mayor tamaño se mantuvo por delante: 0,889 frente a 0,883. Por tanto, no se puede hablar de una victoria incondicional: distintas métricas evalúan propiedades diferentes de la traducción.

En la dirección inversa, kazRush también superó a NLLB distilled 600M, pero quedó por detrás de las versiones de NLLB con 1,3 y 3,3 mil millones de parámetros. Es una herramienta especializada, no un sustituto universal de los grandes modelos multilingües.

La conclusión práctica se aplica mucho más allá de la traducción. Conserve la procedencia de cada registro, mida el efecto de cada filtro y no elimine datos solo porque una regla parezca razonable. Primero haga ablaciones del corpus, el tokenizador y la arquitectura, y solo después pague por capacidad de cómputo adicional. A veces, la mejor forma de reducir un modelo es examinar con más atención los datos con los que se alimenta.