Collecter des données web multilingues et régionales pour les LLM

La majeure partie du web ouvert est écrite dans une poignée de langues, et un crawler qui tourne depuis un seul pays en voit une part encore plus étroite : la version anglaise ou par défaut de sites qui afficheraient un texte local à un visiteur local. Si vous entraînez ou affinez des modèles pour plusieurs marchés, collecter des données réellement multilingues et régionales est un problème à part entière, et c’est là que la collecte de données pour l’IA et le ML se complique.

Ce guide explique comment planifier la couverture par langue, où trouver des sources locales, comment récupérer la version que voient les lecteurs locaux, puis comment identifier, filtrer et équilibrer le texte. Pour le pipeline général du crawl au corpus, consultez notre guide pour construire des jeux de données d’entraînement à grande échelle à partir du web ouvert.

Planifier la couverture par langue et par région

Commencez par un tableau, pas par un crawler. Pour chaque langue cible, notez :

• Les régions qui comptent. L’espagnol d’Espagne, du Mexique et d’Argentine diffère par le vocabulaire, l’orthographe et les sujets. Le portugais du Brésil et du Portugal diffère encore davantage. Décidez des variétés dont vous avez besoin.
• Le volume cible par langue et par variété, en tokens ou en documents.
• Les domaines à couvrir : actualités, forums, administrations, commerce, ouvrages de référence, documentation technique.
• Les écritures. Certaines langues s’écrivent dans plusieurs alphabets, comme le serbe en cyrillique et en latin. Décidez si vous gardez les deux.

Ce tableau devient votre test. À la fin de chaque collecte, comparez ce que vous avez obtenu avec lui, langue par langue.

Trouver des sources locales

Les crawls généraux sous-représentent les petites langues : constituez donc des listes de départ par langue.

• Les domaines nationaux comme .pl, .vn ou .co.ke sont un bon premier signal de contenu régional.
• Les versions linguistiques des sites mondiaux. Les balises hreflang dans les en-têtes de page et les sitemaps listent toutes les versions linguistiques d’une page. Notre guide pour utiliser hreflang afin de trouver toutes les versions linguistiques d’une page montre comment les extraire.
• Les annuaires locaux, agrégateurs d’actualités et portails publics, qui renvoient vers de nombreux sites dans la même langue.
• Les résultats de recherche dans la langue locale, obtenus depuis la région, qui font apparaître des sites qu’un crawl mondial atteint rarement.

Notez la source et le statut d’opposition de chaque point de départ. Respectez robots.txt et les oppositions à l’IA au moment de la récupération, et conservez ces informations avec les données.

Récupérer la version que voient les lecteurs locaux

Beaucoup de sites décident quoi servir selon la localisation du visiteur : langue, devise, actualités locales, édition régionale ou mur de consentement. Un crawler installé dans un data center reçoit la version par défaut pour chaque pays, souvent en anglais, et l’enregistre comme s’il s’agissait de contenu local.

Pour collecter la version locale, chaque requête doit ressembler à celle d’un lecteur local :

• Une IP dans le pays cible, idéalement une connexion domestique. Les requêtes passant par des proxys résidentiels arrivent depuis des IP résidentielles du pays ou de la ville choisis, si bien que les sites les routent et les localisent comme pour de vrais visiteurs.
• Un en-tête Accept-Language cohérent, par exemple pl-PL,pl;q=0.9 pour des lecteurs polonais en Pologne.
• Des signaux cohérents. Le fuseau horaire et les paramètres régionaux d’un navigateur headless doivent correspondre à l’IP. Les incohérences sont l’une des raisons pour lesquelles les sites reviennent à une version par défaut ; notre article sur l’accord entre géolocalisation, fuseau horaire et paramètres régionaux du proxy détaille les vérifications.

Contrôlez à la main un échantillon de chaque région dès le début de la collecte. Si le lot « vietnamien » est rempli de pages en anglais, la couche de récupération est en cause, et aucun filtre ultérieur ne le corrigera.

Identifier la langue de chaque document

Ne vous fiez jamais au seul attribut lang ni au domaine. Faites passer un modèle d’identification de langue sur le texte extrait :

• Le modèle lid.176 de fastText couvre 176 langues et est assez rapide pour traiter chaque document.
• Des modèles plus larges comme GlotLID couvrent bien plus de langues et sont meilleurs pour les langues peu dotées.

Identifiez la langue par paragraphe en plus de par document. Beaucoup de pages mélangent les langues : un article local avec un menu de navigation en anglais, ou un fil de forum où les utilisateurs changent de langue. Gardez les paragraphes dans la langue voulue et enregistrez un score de confiance pour pouvoir resserrer le seuil plus tard. C’est sur les textes courts que l’identification échoue le plus : fixez une longueur minimale avant de vous fier à une étiquette.

Filtrer par langue, pas globalement

Les filtres de qualité réglés sur l’anglais abîment les autres langues. Des heuristiques comme le nombre de mots vides, la longueur moyenne des mots ou la proportion de ponctuation se comportent autrement en thaï, qui ne sépare pas les mots par des espaces, ou en finnois, aux mots très longs. Fixez des seuils par langue, à partir d’un échantillon relu par un locuteur natif.

Deux problèmes prennent de l’ampleur dans les données multilingues :

• Le contenu traduit automatiquement. Beaucoup de sites publient des traductions automatiques de pages anglaises. Elles ajoutent du volume, mais apprennent au modèle des erreurs de traduction. Signalez les pages qui sont presque des traductions de pages anglaises connues, et méfiez-vous des sites entiers qui traduisent tout automatiquement.
• Les erreurs d’encodage. Un texte mal décodé produit des caractères corrompus qui ressemblent à une langue réelle mais étrange. Normalisez en Unicode, réparez ou écartez les encodages cassés et normalisez les formes Unicode pour qu’un même mot ne soit pas stocké de deux façons.

Dédupliquez dans chaque langue et entre les langues, car le même texte standard, les mêmes mentions légales et les mêmes modèles apparaissent dans toutes les versions d’un site.

Équilibrer le mélange

Les données web brutes sont dominées par quelques langues. Entraîner sur les parts brutes signifie que les petites langues sont à peine apprises. Entraîner sur des parts égales signifie que les petites langues sont répétées de nombreuses fois et que le modèle les mémorise.

La voie médiane habituelle est l’échantillonnage par température : chaque langue est échantillonnée en proportion de sa taille élevée à une puissance inférieure à un. Les articles sur mT5 et XLM-R ont utilisé un exposant de 0,3. Quel que soit votre choix, consignez-le avec le nombre de tokens par langue avant et après échantillonnage, pour que le mélange soit reproductible et explicable. Notre guide sur la provenance dans le pipeline d’entraînement de l’IA précise ce qu’il faut enregistrer.

En résumé

Des données multilingues ne sont pas des données anglaises avec une étape de traduction. Planifiez la couverture par langue et par variété, trouvez des sources locales, récupérez chaque région comme la voient ses lecteurs, identifiez la langue par paragraphe, filtrez avec des seuils propres à chaque langue et équilibrez le mélange de façon délibérée. C’est la couche de collecte qui décide si vos données « polonaises » sont vraiment polonaises : commencez donc par fiabiliser la récupération.