💡 Six pièges dégradent silencieusement un dataset LLM vietnamien avant le premier pas d'entraînement : mojibake d'encodage hérité, désaccords Unicode NFC/NFD, bruit de crawl web, erreurs de tokenisation syllabique, déséquilibre dialectal et échecs d'annotation. Les corriger coûte bien moins cher qu'un réentraînement après déploiement. Cette liste de vérification aide votre équipe à identifier et corriger chaque problème.
À retenir
- Normalisez tout le texte en UTF-8 NFC dès l'ingestion. Les caractères vietnamiens encodés en VISCII, Windows-1258 et NFD paraissent identiques à l'écran mais cassent la déduplication et la tokenisation.
- Prévoyez de rejeter environ 90 % des données vietnamiennes brutes de CommonCrawl. Les documents non filtrés peuvent contenir plus de 99 % de symboles ; le filtrage par classifieur est obligatoire, pas optionnel.
- Exécutez un segmenteur de mots vietnamien (RDRSegmenter ou VnCoreNLP) avant la tokenisation en sous-mots. La coupure sur les seuls espaces fragmente les mots polysyllabiques.
- Échantillonnez les trois régions dialectales : Nord (Hanoï), Centre (Hué) et Sud (Hô Chi Minh-Ville). Les corpus à dominante nordique biaisent le modèle contre 40 % de la population vietnamienne.
- L'annotation par LLM est moins performante en vietnamien à faibles ressources. Prévoyez un budget de révision humaine native pour au moins 10 % de chaque lot d'annotation.
Pourquoi le vietnamien est-il particulièrement difficile pour construire un dataset LLM propre ?
La qualité d'un dataset LLM vietnamien est particulièrement difficile à assurer parce que cinq problèmes rarement réunis dans les langues européennes convergent ici. Le vietnamien possède six tons marqués par des diacritiques empilés - jusqu'à trois marques combinantes Unicode par caractère. Il a été écrit dans trois systèmes d'encodage différents avant l'universalisation de l'UTF-8. L'espacement au niveau des syllabes ressemble à une segmentation des mots, mais ne l'est pas. Il existe trois dialectes régionaux avec des phonologies et des vocabulaires distincts. Et il reste sous-doté en ressources NLP par rapport à ses 97 millions de locuteurs.
Chaque défi correspond à un mode de défaillance concret dans un pipeline de données. La bonne nouvelle : chaque mode de défaillance est évitable. Les six pièges ci-dessous sont chacun accompagnés d'une correction que votre équipe d'ingénierie peut mettre en oeuvre sans aide extérieure.
Quels pièges d'encodage et de normalisation corrompent les données d'entraînement vietnamiennes ?
Avant qu'UTF-8 devienne la norme du web, le vietnamien utilisait plusieurs encodages mono-octet : VISCII (Vietnamese Standard Code for Information Interchange), Windows-1258 (CP1258), TCVN 5712 et VNI. Des sites vietnamiens anciens, des bases de données gouvernementales et des documents numérisés servent encore du contenu dans ces encodages. Un pipeline qui suppose UTF-8 corrompra silencieusement les diacritiques en mojibake sur chaque document concerné.
La correction pour l'encodage : utilisez une bibliothèque comme chardet (Python) pour détecter l'encodage de chaque document, puis convertissez immédiatement en UTF-8 avant tout traitement. Appliquez cela à l'ingestion, pas comme une étape de nettoyage a posteriori.
Le deuxième problème, plus subtil, est la normalisation Unicode. Les diacritiques vietnamiennes peuvent être stockées de deux manières. NFC (précomposé) stocke le caractère ề comme un seul point de code (U+1EC1). NFD (décomposé) le stocke comme trois points de code séparés : e + accent circonflexe combinant + accent grave combinant. Les deux s'affichent de manière identique dans tout navigateur. Mais le hachage de chaînes et la déduplication les traitent comme des chaînes différentes, conservant les deux copies.
La correction pour la normalisation : normalisez tout le texte en NFC avant la déduplication, la tokenisation et toute étape de hachage. En Python : import unicodedata; text = unicodedata.normalize("NFC", text). La FAQ de normalisation Unicode du Consortium Unicode documente quels points de code sont affectés et pourquoi NFC est la forme recommandée pour le stockage et l'échange.
Quel est le niveau de bruit des données web vietnamiennes de CommonCrawl et mC4 ?
Extrêmement bruyant, plus que la plupart des équipes ne l'anticipent. L'équipe NeMo Curator de NVIDIA a construit un corpus de pré-entraînement vietnamien à partir de CommonCrawl, mC4, OSCAR, Wikipedia et un corpus de presse. Après reformatage Unicode, filtrage heuristique et filtrage par classifieur, ils ont conservé environ 10 % des données brutes. Les documents non filtrés incluaient du contenu où les symboles représentaient 99,44 % des caractères.
VietVault, un corpus vietnamien disponible publiquement, est parti de 6 To de texte CommonCrawl brut pour produire 27,5 Go de données après filtrage - une réduction de plus de 99,5 %.
Un filtre de bruit en trois étapes pour les données web vietnamiennes :
- Filtrage heuristique : supprimez les documents avec des ratios de symboles extrêmes (>30 %), une longueur très courte (<50 mots) ou une densité d'espaces élevée. Cette étape traite rapidement le bruit le plus sévère.
- Filtrage par classifieur : entraînez un classifieur fastText ou BERT léger sur des exemples vietnamiens propres par rapport au contenu bruité. Dans le pipeline NVIDIA, cette étape a supprimé 45 % des données et constitue le principal levier de qualité.
- Déduplication exacte : hachez chaque document après normalisation et supprimez les doublons. Les corpus vietnamiens basés sur CommonCrawl contiennent généralement environ 8 % de doublons exacts.
Quel est le piège de tokenisation spécifique au vietnamien ?
Le vietnamien est une langue isolante monosyllabique. Les espaces séparent les syllabes, pas les mots. L'expression "học sinh" (étudiant) apparaît avec un espace entre "học" et "sinh". Aucun des deux ne porte son sens complet de manière indépendante. Un tokeniseur qui coupe sur les espaces traite chaque syllabe comme un token indépendant, détruisant la sémantique des mots polysyllabiques dans tout le corpus.
La correction standard est la pré-segmentation. PhoBERT, le modèle BERT vietnamien de référence, exige RDRSegmenter comme étape de prétraitement obligatoire avant l'encodage BPE. VnCoreNLP est une alternative largement utilisée. Les deux outils annotent les frontières des mots polysyllabiques, produisant "học_sinh" (avec underscore) comme un seul token que le tokeniseur en sous-mots peut traiter correctement.
Pour les pipelines de corpus d'entraînement : exécutez d'abord la segmentation des mots sur un échantillon de contrôle de 5 %. Comparez la perplexité avec et sans pré-segmentation. La plupart des équipes observent une amélioration de 10-15 % des performances sur les tâches en aval grâce à cette seule correction.
Les lacunes dialectales que votre modèle héritera des corpus nordiques
Le vi-VN standard est basé sur le vietnamien du Nord (Hanoï). Le dialecte nordique possède six tons distincts. Le vietnamien du Sud (Hô Chi Minh-Ville) en a effectivement cinq : les tons hỏi et ngã fusionnent en un seul contour descendant-montant. Le vietnamien central (Hué) a ses propres qualités vocaliques distinctes.
Dans les données textuelles, les différences dialectales apparaissent dans le vocabulaire (nordique "bố/mẹ" vs sudiste "ba/má" pour père et mère), certaines conventions orthographiques et dans l'écriture informelle en ligne de chaque région. Un corpus construit presque entièrement à partir de journaux nordiques produira un modèle générant du texte plus naturel pour les utilisateurs nordiques et pouvant mal gérer l'argot, les expressions idiomatiques et le registre informel sudistes.
Pour un modèle vietnamien servant un public national : visez un échantillonnage dialectal intentionnel - presse et documents gouvernementaux nordiques, réseaux sociaux et e-commerce sudistes, sources régionales du Centre. Si le budget est limité, la couverture Nord plus Sud est l'équilibre minimum nécessaire.
Ce que vous pouvez gérer en interne, et quand un spécialiste vietnamien vaut-il l'investissement ?
L'infrastructure pipeline est entièrement gérable en interne. La détection d'encodage et la conversion UTF-8, la normalisation NFC Unicode, le hachage pour la déduplication, les filtres heuristiques de bruit et l'identification de langue de base sont des tâches d'ingénierie ne nécessitant aucun jugement linguistique. Vos ingénieurs de données peuvent toutes les implémenter à partir des spécifications de cet article.
Un spécialiste vietnamien natif vaut l'investissement à trois points précis :
- Annotation de départ pour les classifieurs de qualité : le classifieur qui filtre les documents de faible qualité a besoin d'exemples vietnamiens propres pour l'entraînement. Un annotateur sans aisance native en vietnamien ne peut pas juger de manière fiable le registre, la correction des marques tonales ou l'adéquation au domaine en contexte.
- Validation de l'annotation : l'annotation par LLM montre des taux d'erreur plus élevés sur le vietnamien à faibles ressources qu'en anglais. Un budget de révision native de 10 % par lot d'annotation capture les échecs systématiques avant qu'ils se multiplient dans tout le dataset.
- Audit de la couverture dialectale et des domaines : vérifier que votre corpus représente l'écriture informelle sudiste, le registre formel nordique et la terminologie Hán Việt technique nécessite un relecteur natif capable de lire les trois. Un ingénieur de données ne peut pas détecter une sous-représentation systématique du Sud en scannant le texte.
Pour les projets nécessitant une annotation de données d'entraînement IA en vietnamien et une révision de qualité, la page des services de données d'entraînement IA vietnamiennes couvre les options d'annotation, de LQA et de révision de corpus pour les équipes francophones.
FAQ
Quelle est la taille minimale d'un corpus vietnamien propre pour le pré-entraînement ?
Il n'existe pas de minimum universel. Des équipes ont réussi à entraîner des modèles vietnamiens spécialisés avec seulement 1 à 5 milliards de tokens de texte propre. La qualité compte bien plus que la taille brute : 1 milliard de tokens vietnamiens correctement normalisés, dédupliqués et équilibrés dialectalement surpassent 10 milliards de tokens de données CommonCrawl bruyantes avec des erreurs d'encodage. Commencez par un corpus propre et plus petit plutôt qu'un grand dump bruité.
Quelle bibliothèque de détection de langue fonctionne le mieux pour le texte vietnamien ?
Le modèle lid.176.bin de fastText et langdetect sont les plus utilisés. FastText est plus rapide pour le traitement par lot. Pour les données web crawlées avec beaucoup de termes techniques anglais mélangés, CLD3 (utilisé dans mC4) classe parfois mal le contenu vietnamien ; un classifieur fastText affiné sur des échantillons web vietnamiens gère mieux ces cas limites. Exécutez toujours la détection de langue après la normalisation d'encodage, pas avant.
Faut-il utiliser la tokenisation PhoBERT ou SentencePiece pour un LLM vietnamien génératif ?
Pour les modèles encodeur seulement (classification, NER, QA), PhoBERT avec le prétraitement RDRSegmenter est la norme établie. Pour les LLM génératifs, SentencePiece entraîné sur du texte vietnamien pré-segmenté est plus pratique car il gère mieux les tokens hors-vocabulaire. L'étape critique : entraînez le vocabulaire SentencePiece sur du texte pré-segmenté (avec annotation des frontières de mots), pas sur de l'entrée vietnamienne brute tokenisée par espaces, pour obtenir des sous-mots significatifs.
Comment gérer la fusion des tons hỏi/ngã dans les tâches d'annotation ?
En vietnamien écrit, les tons hỏi et ngã sont toujours orthographiés avec des diacritiques distincts, quelle que soit leur sonorité dans le dialecte sudiste. Le vi-VN écrit standard suit l'orthographe nordique. Les consignes d'annotation doivent préciser l'orthographe écrite standard, pas la transcription phonétique. Pour les tâches d'annotation ASR, intégrez une vérification de cohérence par rapport à la forme écrite standard pour capturer la variance de transcription entre annotateurs nordiques et sudistes.
Peut-on utiliser GPT-4 ou Claude pour annoter un dataset LLM vietnamien ?
Les LLM sont utiles pour la pré-annotation en masse en vietnamien, mais les taux d'erreur sont plus élevés qu'en anglais - notamment pour la terminologie spécialisée, la classification de sentiment sensible aux tons et la reconnaissance dialectale. Utilisez les LLM pour générer des étiquettes initiales, puis validez avec des locuteurs natifs vietnamiens sur au moins 10 % de chaque lot. Pour les tâches impliquant le registre Hán Việt formel ou le registre informel sudiste, la validation humaine est indispensable.
Sources officielles
- Blog développeurs NVIDIA - Traitement de données vietnamiennes haute qualité avec NeMo Curator - statistiques de filtrage : ratios symboles/nombres dans les données brutes, réduction de 90 %, impact classifieur vs heuristique. Vérifié octobre 2026.
- Consortium Unicode - FAQ de normalisation Unicode - formes NFC vs NFD, diacritiques vietnamiennes précomposées vs décomposées, forme recommandée pour le stockage. Vérifié octobre 2026.
- W3C Internationalisation - Normalisation en HTML et CSS - guide pratique sur la normalisation Unicode pour le contenu web et les diacritiques combinantes. Vérifié octobre 2026.
- Dataset VietVault - Hugging Face - 6 To de CommonCrawl brut vers 27,5 Go curatés, composition des sources et pipeline de filtrage pour données vietnamiennes. Vérifié octobre 2026.
- Crossing Linguistic Horizons : Évaluation des LLM vietnamiens (arXiv 2403.02715) - sensibilité aux diacritiques, fragilité de tokenisation, résultats de biais d'annotation. Vérifié octobre 2026.
Écrit par Đào Huy (Lucas), traducteur vietnamien et spécialiste de la localisation (anglais, chinois et français vers le vietnamien). See translation services →