Aller au contenu
Corpshore Colombia

Livraison d'IA

L'espagnol d'Amérique latine n'est pas une seule langue : ce que cela signifie pour vos modèles d'IA

10 min de lecturePour: Responsables ML et data science construisant des modèles hispanophones

En bref

L'espagnol d'Amérique latine varie systématiquement selon la région dans le vocabulaire, les conventions de politesse et l'usage pragmatique. Les modèles entraînés majoritairement sur une variante sous-performent sur les autres, et c'est l'annotation native de chaque variante qui corrige l'écart.

Le problème se cache dans vos scores de référence

Un modèle entraîné sur l'espagnol castillan et européen obtiendra souvent un bon score sur un test de référence en espagnol puis échouera en production à travers l'Amérique latine. L'échec est réel, structurel et facile à manquer, car le test de référence et le trafic de production ne proviennent pas de la même distribution. Un modèle qui lit l'espagnol caraïbe avec soixante-dix pour cent de précision tout en obtenant quatre-vingt-dix sur le castillan n'est pas un bon modèle d'espagnol. C'est un bon modèle de castillan.

C'est l'un des problèmes les plus lourds de conséquences et les moins reconnus de l'IA hispanophone. L'espagnol est parlé par environ cinq cents millions de personnes dans plus de vingt pays, et la variation entre eux n'est pas cosmétique.

Où la variation se loge réellement

Les différences qui cassent les modèles sont rarement les plus évidentes. Elles se regroupent dans quatre domaines. La divergence de vocabulaire sur des concepts ordinaires, où le même objet ou la même action du quotidien porte des mots différents selon les pays. Les conventions de politesse et de franchise, où une formulation qui paraît polie dans un pays paraît distante ou abrupte dans un autre. L'usage du diminutif, qui porte un poids pragmatique différent d'une région à l'autre. Et l'alternance codique, le mélange fluide de l'espagnol et de l'anglais courant sur certains marchés et rare sur d'autres.

Un modèle qui interprète mal ces éléments n'échoue pas bruyamment. Il classe à tort une plainte comme une demande, interprète mal le sentiment, ou applique une règle de modération de façon incohérente selon les pays. Les échecs atteignent directement les utilisateurs, et ils sont difficiles à diagnostiquer car chaque erreur individuelle ressemble à du bruit plutôt qu'à un schéma.

Pourquoi la traduction ne corrige pas le problème

Le correctif instinctif, traduire automatiquement les données d'une variante vers une autre, rend le problème plus difficile à voir plutôt que plus facile à résoudre. La traduction produit un texte grammaticalement régional et pragmatiquement étranger : des mots corrects dans le mauvais registre culturel. Les scores de référence s'améliorent car la forme de surface correspond. La performance en production, elle, ne s'améliore pas, car le contenu pragmatique reste erroné.

Annotation native, par variante, sur un seul site

Le correctif est l'annotation native de véritables données propres à la variante, par des personnes qui parlent la variante et en comprennent la culture. C'est autant un problème d'approvisionnement qu'un problème linguistique, car il requiert des locuteurs natifs de plusieurs variantes travaillant selon une norme commune, idéalement sur un seul site afin de pouvoir se calibrer les uns par rapport aux autres.

La Colombie est bien placée pour cela. La réputation de plaque tournante technologique de Medellín a attiré une main-d'œuvre mobile et multinationale, de sorte que des locuteurs natifs de plusieurs variantes de l'espagnol d'Amérique latine peuvent être réunis et calibrés au sein d'une seule opération. L'annotation saisit les traits pragmatiques, la franchise, le registre, l'urgence, l'intensité du sentiment, et pas seulement les étiquettes sémantiques, car ce sont ces traits qui varient et provoquent l'échec.

Le test pratique

Si vous construisez une IA hispanophone pour l'Amérique latine, mesurez la performance de votre modèle par variante, et non de façon agrégée. Si l'écart entre votre meilleure et votre pire variante est large, la précision agrégée masque un problème que vos utilisateurs vivent déjà. L'annotation native, propre à la variante, est le moyen de resserrer cet écart, et le resserrer est souvent la différence entre un programme d'automatisation qui se lance et un programme qui reste reporté.

Prêt à en discuter ?

Dites-nous ce que vous voulez faire bouger et nous tracerons une approche nearshore pour y parvenir.

Réserver un appel