LLM multilingues : un corpus de 2,8 billions de tokens
Explorez le corpus de 2,8 billions de tokens pour 22 langues indiennes et son pipeline ouvert. Méthodes, résultats et limites pour vos projets IA.
Des LLM plus inclusifs : ce que révèle un corpus de 2,8 billions de tokens
Les grands modèles de langage sont généralement meilleurs quand ils disposent de beaucoup de données... et de données de bonne qualité. Le hic, c'est que cette abondance varie énormément selon les langues. Pour plusieurs langues indiennes, le manque de données disponibles freine le développement de modèles capables de comprendre des demandes, de raisonner et de répondre de façon fiable.
NVIDIA, IIT Madras et son laboratoire AI4Bharat proposent une réponse concrète : un corpus d'environ 2,8 billions de tokens, couvrant les 22 langues inscrites dans la Constitution indienne, ainsi qu'un pipeline ouvert pour produire de nouvelles données à partir de sources anglaises. L'intérêt ne tient pas seulement au volume. Le projet détaille aussi les étapes de traduction, d'évaluation et de correction des textes, avec leurs limites.
Et ça pose une question qui concerne aussi les équipes de recherche en Europe : comment développer des modèles multilingues sans confondre quantité, qualité linguistique et représentation des usages locaux ? Voici ce que contient le corpus, comment il a été construit et ce qu'on peut - ou non - en déduire.
Pourquoi ce corpus compte pour les LLM multilingues
La performance d'un modèle ne dépend pas uniquement de son architecture ou de sa puissance de calcul. Elle dépend aussi de la disponibilité de données adaptées aux langues visées et aux usages prévus. Quand les corpus de préentraînement sont trop dominés par l'anglais, les modèles peuvent produire de bonnes réponses en anglais, mais décrochent ailleurs : vocabulaire moins riche, compréhension moins stable, mélange de scripts, ou difficulté à traiter certains contenus techniques.
Ce problème se voit surtout pour les langues peu présentes dans les données numériques. Mitesh Khapra, responsable d'AI4Bharat, résume l'enjeu par un manque structurel de données pour les langues indiennes. Le corpus annoncé par NVIDIA et ses partenaires vise à élargir cette base. Les 22 langues couvertes correspondent à celles reconnues par la Constitution indienne. D'après le recensement de 2011 cité par les auteurs, elles représentent les premières langues de près de 97 % de la population, soit environ 1,2 milliard de personnes. Attention : ce chiffre sert de repère démographique pour le projet, ce n'est pas une mesure actuelle.
Le volume aide, mais il ne règle pas tout
Un gros corpus apporte davantage d'exemples dans des tâches variées : raisonnement, mathématiques, programmation, questions-réponses. Mais à lui seul, le volume ne garantit ni la fidélité des traductions, ni la couverture des connaissances locales, ni la qualité des réponses produites à partir de ces données.
C'est justement pour ça que l'approche publiée ne se contente pas de lister des textes. Elle décrit aussi la méthode : documents sources, consignes, évaluations automatisées et corrections ciblées. Pour des équipes qui doivent décider si ces données conviennent à leur cas d'usage, c'est un point important.
Pour un acteur européen, l'arbitrage reste comparable, même si les langues et les contextes changent. Construire un projet pour le français, le breton, le basque, ou plusieurs marchés de l'Union européenne, oblige à décider entre données traduites, contenus écrits nativement, représentativité des usages et coût de validation. Les données synthétiques peuvent accélérer la constitution d'un corpus, mais elles ne remplacent pas automatiquement les sources produites par les communautés concernées.
Une logique plus ouverte (mais pas magique)
AI4Bharat, laboratoire de recherche à IIT Madras consacré aux langues indiennes, développe des ressources ouvertes, dont le corpus de préentraînement Sangraha. Le nouveau projet s'inscrit dans cette dynamique en ajoutant une grande quantité de données synthétiques, avec un pipeline réutilisable.
L'idée est intéressante au-delà de l'Inde : partager à la fois les données et la « recette » de génération permet de vérifier des choix, de modifier les consignes et d'expérimenter avec ses propres documents. Mais ça ne dispense pas de contrôler les droits sur les sources, la qualité des sorties et les conditions de licence. En pratique, la chaîne de production devient simplement plus facile à auditer que lorsqu'on ne voit ni la provenance ni les méthodes.
Ce que contiennent les 2,8 billions de tokens
Le corpus annonce 2 601 milliards de tokens en écriture native et 224,6 milliards de tokens romanisés, soit environ 2 825,6 milliards au total. Les auteurs précisent que le calcul utilise le tokenizer Gemma-4. Ces chiffres correspondent à ce qui est conservé dans le jeu de données, pas au nombre de documents anglais uniques, ni au budget d'entraînement d'un modèle.
Et ce point compte vraiment : un même document source peut produire plusieurs traductions ou plusieurs variantes d'écriture. Le corpus comptabilise ces enregistrements, qui peuvent partager du contenu sous-jacent. Autre subtilité : le nombre de tokens dépend du tokenizer. Deux outils peuvent découper un même texte différemment. Donc, il faut distinguer l'inventaire du jeu de données du volume réellement « consommé » pendant l'entraînement.
Vingt-deux langues et 34 configurations langue-écriture
Douze langues sont présentes à la fois en écriture native et en version romanisée : bengali, gujarati, hindi, kannada, malayalam, marathi, népalais, odia, pendjabi, tamoul, télougou et ourdou. Les dix autres - assamais, bodo, dogri, cachemiri, konkani, maithili, manipuri, sanskrit, santali et sindhi - apparaissent en écriture native uniquement.
Au total, le projet couvre 34 configurations langue-écriture. « Écriture native » renvoie ici au système d'écriture de la langue, mais les textes restent traduits depuis l'anglais. « Romanisé » signifie que la langue indienne est transcrite en alphabet latin ; ce n'est pas une version « en anglais ». Pour les douze langues à double configuration, seule une partie des traductions acceptées est convertie en alphabet latin.
Ces variantes ne servent pas exactement le même objectif dans un entraînement. Une application mobile peut accueillir des utilisateurs qui saisissent une langue indienne en alphabet latin, même si ce n'est pas la forme « officielle » de l'écriture. Une autre application peut exiger une génération exclusivement en écriture native. Les données à choisir devraient donc refléter ces usages, pas une préférence technique abstraite.
Des sources variées, avec une traçabilité par document
Les données de départ proviennent de 15 sous-ensembles de Nemotron-CC-v2. On y trouve notamment des textes web, des contenus de questions-réponses, des mathématiques et du code. Les auteurs indiquent que chaque sortie conserve l'identifiant du document source : on peut donc retracer l'origine et mieux auditer le processus.
Ce niveau de traçabilité aide pour analyser les erreurs, repérer des soucis liés à une source et organiser des jeux de test. En revanche, il ne veut pas dire que tout a été dédupliqué « sémantiquement » de bout en bout. Les identifiants évitent les doublons de traitement, mais ne garantissent pas que deux documents proches ont été détectés et éliminés comme tels.
Au final, le corpus fournit une base plus large pour des tâches techniques en langues indiennes, sans prétendre couvrir tout le spectre des connaissances ou tous les registres locaux. Sa valeur dépend donc d'un cas d'usage précis : cohérence du mélange et évaluation par langue.
Résultats, usages et limites à garder en tête
Le corpus a été utilisé dans le préentraînement continu de Nemotron 3.5 Super VL. Le budget configuré pour cette étape était de 100 milliards de tokens, dont 10 % - soit 10 milliards - consacrés à un mélange de textes indiens naturels et synthétiques issus notamment d'un sous-ensemble de douze langues. Les 90 % restants ont gardé les proportions relatives du mélange d'entraînement précédent.
Entre le checkpoint avant cette étape et celui qui suit, les scores progressent sur cinq benchmarks de connaissances et de raisonnement en langues indiennes : MILU, Indic MMLU-Pro, Indic ARC-Challenge, Indic ARC-Easy et Indic GSM8K. Les gains publiés vont de 4,98 à 9,82 points de pourcentage. Le test GSM8K exclut l'odia, car l'évaluation dépassait la limite de contexte utilisée pour le service.
Ce que les résultats montrent - et ce qu'ils ne montrent pas
La comparaison porte sur une étape de préentraînement qui combine données synthétiques et textes indiens naturels. On ne peut donc pas isoler l'effet du seul corpus synthétique. Les résultats soutiennent la recette combinée testée, mais ils ne prouvent pas que le même dosage sera optimal pour d'autres modèles, d'autres langues ou d'autres tâches.
Comparer Nemotron 3.5 Super VL à Nemotron 3 Super donne aussi une vue plus large du modèle publié, puisque le nouveau modèle inclut l'entraînement complet et le post-entraînement. Le modèle récent obtient de meilleurs scores sur cinq des six benchmarks mentionnés, couvrant connaissances, raisonnement, mathématiques, code et traduction. En revanche, le score IFEval 1.5 (suivi des instructions) baisse de 2,04 points.
Les évaluations IndiVibe progressent sur quatre dimensions : utilité, fluidité, fidélité à la langue et à l'écriture, et niveau de détail approprié. Ces scores reflètent des préférences selon des critères, pas un « taux de victoire » mesuré dans un face-à-face simple. Là encore, la nuance compte : un graphique de résultats décrit un protocole donné, pas une garantie générale de qualité pour tous les utilisateurs.
Des usages possibles, à condition de définir le bon mélange
Pour une équipe qui construit un assistant multilingue, un corpus de ce type peut servir à tester l'impact de données supplémentaires dans une langue sous-représentée. On peut imaginer des usages allant de l'accès à des contenus éducatifs à l'assistance documentaire, en passant par des interfaces de service. Mais des gains sur des benchmarks ne suffisent pas à valider un déploiement.
Il faut aussi vérifier la compréhension des requêtes réelles, la qualité des réponses, les risques d'erreur et les conséquences d'une mauvaise traduction.
Un point de départ utile consiste à comparer plusieurs mélanges à budget de tokens constant, plutôt que d'ajouter des données sans mesurer leur effet. Ensuite, il faut suivre les résultats par langue et par écriture, contrôler la conservation des capacités en anglais quand c'est nécessaire, et distinguer les parts de données naturelles et synthétiques. Enfin, les découpages d'entraînement et de test doivent tenir compte des documents apparentés entre langues et scripts, pour éviter qu'un contenu source « fuit » des deux côtés de l'évaluation.
Pour un projet français ou européen, les exigences restent les mêmes : examiner les sources et leurs conditions d'utilisation, documenter les transformations, prévoir des validations humaines et intégrer les règles applicables aux données personnelles. Le RGPD ne valide pas un corpus juste parce qu'il est ouvert ou synthétique : la conformité dépend des sources, du traitement et du contexte d'usage.
Les limites à intégrer dès le plan de déploiement
La traduction donne accès à des contenus existants, mais elle ne remplace pas les textes écrits directement dans la langue. Elle ne garantit pas non plus que les savoirs locaux, les références culturelles ou les façons de s'exprimer propres à chaque communauté seront au rendez-vous. Les auteurs recommandent donc de combiner le corpus avec des données indiennes naturelles, dûment sourcées.
L'évaluation est surtout automatisée, avec des revues humaines par échantillonnage dont la couverture varie selon les langues. Pour le parcours des douze langues, le modèle de traduction intervient aussi comme évaluateur : efficace, mais pas infaillible. Pour les dix autres langues, il faut en plus une validation plus étendue par des locuteurs natifs.
Enfin, le travail d'évaluation doit continuer. AI4Bharat et IIT Madras, avec le soutien de NVIDIA, développent Indic-LLM-Eval-Suite, un ensemble évolutif de benchmarks pour examiner les capacités et la qualité linguistique. Le corpus et les résultats présentés constituent donc une base de travail, pas une certification universelle.
Conclusion
Ce projet apporte deux choses utiles : un corpus d'environ 2,8 billions de tokens couvrant 22 langues indiennes, et une chaîne ouverte pour produire, évaluer et corriger des données à partir de documents anglais. Le plus intéressant n'est pas seulement le volume : c'est la possibilité de regarder les méthodes, de les adapter et de tester des arbitrages sur ses propres données.
Les résultats de Nemotron 3.5 Super VL sont encourageants, mais ils concernent une recette combinant données naturelles et synthétiques. Si une équipe veut s'engager dans une démarche similaire, la décision doit venir des usages, des langues visées, de la qualité attendue et des moyens de validation disponibles - pas du seul chiffre de tokens.
Vous pouvez consulter la publication NVIDIA sur Hugging Face, puis examiner la fiche de données et les ressources techniques associées avant de lancer un test. Commencez petit, mesurez par langue, et ne passez à l'échelle que quand la qualité et la provenance sont suffisamment maîtrisées.
Comment fonctionne le pipeline de génération
La production repose sur NeMo Data Designer, un framework ouvert de NVIDIA pour générer des données synthétiques. Il combine traduction documentaire, évaluation de la qualité et, quand c'est nécessaire, correction des sorties jugées insuffisantes. Les méthodes varient selon les groupes de langues : ce n'est pas le même traitement « au cordeau » appliqué aux 22 langues.
Douze langues : traduire, évaluer, réparer, romaniser
Pour les douze langues avec des versions natives et romanisées, les documents sont traduits dans leur intégralité. Les auteurs indiquent avoir choisi Gemma-4-31B-it après des comparaisons portant sur des documents complets, en regardant notamment la préservation du contenu technique. Les consignes séparent les éléments à traduire des éléments à conserver (code, équations, URL, mise en forme).
Ensuite, le texte traduit est comparé à sa source anglaise via le même modèle. Une grille inspirée des Multidimensional Quality Metrics évalue notamment le sens, la fluidité, la terminologie, le style et le formatage. Les sorties au moins 75 sur 100 sont retenues. Ce score n'est pas un « taux de précision à 75 % », c'est une note issue de la grille.
Les sorties sous le seuil peuvent être réparées à partir des remarques de l'évaluation, puis soumises à un nouveau contrôle. Les auteurs disent que ce mécanisme a permis de récupérer 438,4 milliards de tokens, déjà inclus dans le total annoncé. Ils mentionnent aussi des revues humaines et des tests avec erreurs introduites volontairement, pour repérer des omissions et des passages restés en anglais.
Pour les variantes romanisées, le pipeline part des traductions natives acceptées, puis convertit en alphabet latin et compare le résultat avec le texte d'origine. En séparant traduction et conversion de script, l'objectif est de limiter les ajouts inventés et les résidus anglais. Une première comparaison humaine a été jugée favorable à cette méthode, par rapport à une génération romanisée directement depuis l'anglais.
Dix langues : adapter la méthode aux difficultés observées
Pour les dix autres langues, les auteurs utilisent Indic Translate, un modèle de traduction documentaire développé par Bodhan AI, une organisation à but non lucratif incubée à IIT Madras. Gemma-4-31B-it sert ensuite à évaluer les traductions par rapport aux sources. Huit langues suivent une approche au niveau du document entier.
Deux cas demandent un traitement spécifique. Pour les longs documents en santali, la traduction se fait par fenêtres qui se chevauchent, puis la reconstruction suit. Pour le manipuri, la traduction passe d'abord par l'écriture bengalie, puis la conversion vers Meitei Mayek, son écriture native. Dans les deux cas, les sorties retenues dépassent le seuil de 75 sur 100. En revanche, ce parcours n'inclut pas la réécriture guidée par les retours d'évaluation décrite pour les douze langues.
Cette distinction est utile pour qui veut réutiliser la recette : une procédure adaptée à une langue ne se copie pas automatiquement sur une autre. La stabilité de l'écriture, la longueur des documents, les ressources disponibles et la qualité des modèles de traduction changent les arbitrages.
Reproduire la démarche sans industrialiser trop vite
Le pipeline ouvert, appelé plugin de traduction Nemotron Bharat pour NeMo Data Designer, fournit des consignes de traduction et d'évaluation, une réécriture optionnelle, un découpage de documents et une conversion de scripts. Pour un projet interne, le plus raisonnable est de démarrer avec un petit échantillon représentatif.
Avant de passer à l'échelle, il faut au minimum vérifier :
Le plugin génère des candidats et des scores, mais c'est à l'équipe de définir sa politique d'acceptation. Cette séparation est saine : automatiser la production ne veut pas dire déléguer toute décision de qualité au modèle qui a traduit ou évalué.