kazRush devance NLLB 3.3B au score BLEU avec un modèle 17 fois plus petit

En traduction automatique, il est facile de tomber dans un piège coûteux : collecter davantage de données, choisir un modèle plus grand et attendre que la qualité progresse d’elle-même. L’équipe des technologies expérimentales d’IA de VK a testé cette recette sur la traduction russo-kazakhe et en a tiré une conclusion plus utile. Avec 197 millions de paramètres, le modèle kazRush a devancé NLLB 3.3B selon BLEU et chrF pour la traduction du russe vers le kazakh. Ce n’est pas la seule montée en échelle qui a fait la différence, mais l’association d’un corpus soigneusement préparé, d’un tokenizer compact et d’une architecture dimensionnée en fonction du volume de données.

Les données d’abord, les paramètres ensuite

Le corpus initial a été assemblé à partir d’OPUS, KazParC, WMT et Turkic Interlingua. Avant filtrage, il comptait environ 12,3 millions de paires de phrases. Après suppression des déchets, vérification des langues et alignement, il restait 9 054 960 paires.

Un exemple simple permet de comprendre le problème. Une ligne peut contenir à gauche une phrase russe et, à droite, un fragment kazakh portant sur un sujet similaire sans en être la traduction. Formellement, les deux textes sont écrits dans les langues attendues : une vérification classique laissera donc passer la paire. Le modèle apprendra alors une correspondance erronée.

L’équipe a successivement supprimé les doublons exacts, le balisage HTML et les caractères parasites, appliqué une normalisation Unicode, identifié la langue de chaque phrase avec fastText et mesuré la proximité sémantique au moyen de LaBSE. Les paires dont le score était inférieur à 0,4 ont été écartées. Les nombres, le rapport entre les longueurs ainsi que la proportion de lettres et de chiffres dans chaque ligne ont également été contrôlés. Certains jeux de données ont nécessité des règles spécifiques : un filtre universel ne suffisait pas.

La recherche de quasi-doublons a produit un résultat intéressant. On pourrait penser que des lignes similaires ne font qu’encombrer le corpus. Pourtant, leur suppression a dégradé la qualité du modèle. Une explication possible est qu’en situation de pénurie de données, de légères variations d’une même expression agissent comme une augmentation naturelle. Le jeu final a donc été débarrassé des répétitions exactes, mais a conservé les quasi-doublons.

Un modèle compact plutôt qu’une course à la taille

Pour les deux langues, l’équipe a entraîné un tokenizer SentencePiece commun comprenant 8 000 unités de sous-mots. La variante à 16 000 a obtenu un résultat légèrement inférieur. C’est un rappel important : un vocabulaire étendu n’est pas toujours avantageux, en particulier pour une langue à la morphologie riche et lorsque le corpus est limité.

Le modèle repose sur un Transformer encodeur-décodeur de type T5, mais sans poids préentraînés. La configuration finale comporte 12 couches dans l’encodeur et le décodeur, un état caché de dimension 512 et des blocs feed-forward de dimension 4 096, soit environ 197 millions de paramètres au total.

Les auteurs l’ont comparé à T5-Small, T5-Base et T5-Large. Le modèle de 738 millions de paramètres n’a pas été le meilleur : pour la direction « russe vers kazakh », il a obtenu un score BLEU de 15,8, contre 16,2 pour kazRush. Sur chrF, les scores ont été de 51,9 contre 51,6, et sur COMET de 0,8836 contre 0,8804. Autrement dit, une multiplication presque par quatre du nombre de paramètres n’a pas été rentable.

Là où le résultat est réellement solide

Sur FLORES+ devtest, kazRush a été comparé à la famille NLLB. Pour la traduction du russe vers le kazakh, le modèle a obtenu un score BLEU de 16,2 et un score chrF de 51,8, devant NLLB 3.3B, qui atteint respectivement 15,6 et 50,7. En revanche, le grand modèle NLLB est resté en tête sur COMET : 0,889 contre 0,883. Il est donc impossible de parler de victoire absolue, car les différentes métriques évaluent des propriétés différentes de la traduction.

Dans la direction inverse, kazRush a également devancé NLLB distilled 600M, mais est resté derrière les versions de NLLB à 1,3 et 3,3 milliards de paramètres. Il s’agit d’un outil spécialisé, et non d’un remplacement universel des grands modèles multilingues.

La conclusion pratique s’applique bien au-delà de la traduction. Conservez la provenance de chaque enregistrement, mesurez l’effet de chaque filtre et ne supprimez pas des données uniquement parce qu’une règle paraît raisonnable. Commencez par mener des études d’ablation sur le corpus, le tokenizer et l’architecture, puis seulement ensuite achetez des ressources de calcul supplémentaires. Parfois, la meilleure manière de réduire la taille d’un modèle consiste à examiner plus attentivement les données dont on le nourrit.