💡 Sáu lỗi thầm lặng làm suy giảm bộ dữ liệu huấn luyện LLM tiếng Việt trước khi quá trình huấn luyện bắt đầu: lỗi mã hóa legacy mojibake, sự không khớp Unicode NFC/NFD, nhiễu dữ liệu web crawl, lỗi phân tách từ ở cấp âm tiết, mất cân bằng phương ngữ và thất bại trong gán nhãn. Khắc phục sớm tốn kém ít hơn nhiều so với tái huấn luyện sau triển khai.
Ý chính
- Chuẩn hóa toàn bộ văn bản về UTF-8 NFC ngay khi nhập dữ liệu. Ký tự tiếng Việt mã hóa VISCII, Windows-1258 và NFD trông giống hệt nhau nhưng phá vỡ loại trùng và phân đoạn từ.
- Dự kiến loại bỏ khoảng 90% dữ liệu CommonCrawl tiếng Việt thô. Tài liệu chưa lọc có thể chứa trên 99% ký hiệu; bộ lọc dựa trên bộ phân loại là bắt buộc, không phải tùy chọn.
- Chạy công cụ phân đoạn từ tiếng Việt (RDRSegmenter hoặc VnCoreNLP) trước khi phân tách subword. Tách bằng khoảng trắng đơn thuần phá vỡ các từ đa âm tiết.
- Lấy mẫu cả ba vùng phương ngữ: miền Bắc (Hà Nội), miền Trung (Huế) và miền Nam (TP.HCM). Kho ngữ liệu chỉ từ miền Bắc gây thiên kiến với 40% dân số Việt Nam.
- Gán nhãn bằng LLM hoạt động kém hơn trên tiếng Việt ít tài nguyên. Dành ngân sách cho người review bản ngữ kiểm tra ít nhất 10% mỗi lô gán nhãn.
Tại sao tiếng Việt đặc biệt khó để xây dựng bộ dữ liệu LLM sạch?
Chất lượng bộ dữ liệu LLM tiếng Việt gặp thách thức đặc biệt vì năm vấn đề hiếm khi cùng xuất hiện trong ngôn ngữ châu Âu lại hội tụ ở đây. Tiếng Việt có sáu thanh điệu được đánh dấu bằng dấu phụ chồng nhau - tới ba combining mark Unicode trên mỗi ký tự. Ngôn ngữ này từng được viết bằng ba hệ thống mã hóa byte khác nhau trước khi UTF-8 trở thành chuẩn. Việc phân cách bằng khoảng trắng ở cấp âm tiết trông giống phân đoạn từ nhưng thực ra không phải. Có ba phương ngữ vùng với ngữ âm và từ vựng riêng. Và nguồn tài nguyên NLP vẫn còn hạn chế so với 97 triệu người nói.
Mỗi thách thức tương ứng với một chế độ thất bại cụ thể trong pipeline xử lý dữ liệu. Tin tốt là: mỗi lỗi đều có thể phòng ngừa được với sáu bước khắc phục dưới đây.
Lỗi mã hóa và chuẩn hóa Unicode nào làm hỏng dữ liệu huấn luyện tiếng Việt?
Trước khi UTF-8 trở thành chuẩn web, tiếng Việt sử dụng nhiều mã hóa byte đơn: VISCII (Vietnamese Standard Code for Information Interchange), Windows-1258 (CP1258), TCVN 5712 và VNI. Các website tiếng Việt cũ, cơ sở dữ liệu chính phủ và tài liệu số hóa vẫn phục vụ nội dung theo các mã hóa này. Pipeline giả định UTF-8 sẽ âm thầm làm hỏng dấu phụ thành mojibake trên từng tài liệu bị ảnh hưởng.
Cách khắc phục mã hóa: dùng thư viện chardet (Python) để phát hiện mã hóa từng tài liệu, sau đó chuyển đổi ngay sang UTF-8 trước khi xử lý. Áp dụng bước này khi nhập dữ liệu, không phải như phần bổ sung sau khi làm sạch.
Vấn đề thứ hai là chuẩn hóa Unicode. Dấu phụ tiếng Việt có thể được lưu theo hai cách. NFC (precomposed) lưu ký tự ề dưới dạng một code point duy nhất (U+1EC1). NFD (decomposed) lưu dưới dạng ba code point riêng biệt: e + combining circumflex + combining grave accent. Cả hai hiển thị giống hệt nhau trong mọi trình duyệt. Nhưng hàm băm chuỗi và loại trùng coi chúng là hai chuỗi khác nhau, giữ lại cả hai bản sao.
Cách khắc phục chuẩn hóa: chuẩn hóa tất cả văn bản về NFC trước khi loại trùng, phân đoạn từ và băm. Trong Python: import unicodedata; text = unicodedata.normalize("NFC", text). FAQ Chuẩn hóa của Unicode Consortium ghi chi tiết các code point bị ảnh hưởng và tại sao NFC là dạng khuyến nghị cho lưu trữ và trao đổi văn bản.
Dữ liệu web CommonCrawl và mC4 tiếng Việt nhiễu đến mức nào?
Rất nhiễu, hơn những gì hầu hết đội nhóm kỳ vọng. Nhóm NeMo Curator của NVIDIA xây dựng kho ngữ liệu tiền huấn luyện tiếng Việt từ CommonCrawl, mC4, OSCAR, Wikipedia và kho báo. Sau khi áp dụng định dạng lại Unicode, lọc theo heuristic và lọc dựa trên bộ phân loại, họ giữ lại khoảng 10% dữ liệu thô. Tài liệu chưa lọc có những nội dung mà ký hiệu chiếm 99,44% ký tự.
VietVault, kho ngữ liệu tiếng Việt có sẵn công khai, bắt đầu từ 6TB văn bản CommonCrawl thô và cho ra 27,5GB dữ liệu được kiểm duyệt sau lọc, giảm hơn 99,5%.
Bộ lọc nhiễu ba bước thực tế:
- Lọc heuristic: loại tài liệu có tỷ lệ ký hiệu quá cao (>30%), độ dài rất ngắn (<50 từ) hoặc mật độ khoảng trắng cao. Bước này xử lý nhiễu nặng nhất một cách nhanh chóng.
- Lọc dựa trên bộ phân loại: huấn luyện bộ phân loại fastText hoặc BERT nhỏ trên các ví dụ tiếng Việt sạch so với nội dung nhiễu. Trong pipeline NVIDIA, bước này loại bỏ 45% dữ liệu và là đòn bẩy chất lượng chính.
- Loại trùng chính xác: băm từng tài liệu sau khi chuẩn hóa và loại bỏ trùng. Kho ngữ liệu CommonCrawl tiếng Việt thường có khoảng 8% tài liệu trùng chính xác.
Bẫy phân tách từ trong tiếng Việt là gì?
Tiếng Việt là ngôn ngữ đơn lập cấu tạo âm tiết. Khoảng trắng phân cách âm tiết, không phải từ. Cụm "học sinh" (student) xuất hiện với khoảng trắng giữa "học" và "sinh". Bộ phân tách dựa trên khoảng trắng tạo ra hai token mồ côi không mang đủ nghĩa độc lập. Điều này phá vỡ ngữ nghĩa từ đa âm tiết trên toàn bộ kho ngữ liệu.
Giải pháp chuẩn là tiền phân đoạn. PhoBERT, mô hình BERT tiếng Việt hàng đầu, yêu cầu RDRSegmenter làm bước tiền xử lý bắt buộc trước khi mã hóa BPE. VnCoreNLP là lựa chọn thay thế phổ biến. Cả hai công cụ chú thích ranh giới từ đa âm tiết, tạo ra "học_sinh" (có gạch dưới) như một token duy nhất để bộ phân tách subword xử lý đúng.
Thực hành khuyến nghị: chạy phân đoạn từ trên 5% mẫu giữ lại trước. So sánh perplexity có và không có tiền phân đoạn. Hầu hết đội nhóm thấy cải thiện 10-15% hiệu suất trên các tác vụ xuôi chiều từ một thay đổi duy nhất này, không cần thay đổi hạ tầng huấn luyện.
Khoảng trống phương ngữ mà mô hình sẽ thừa hưởng
Vi-VN chuẩn dựa trên tiếng Việt miền Bắc (Hà Nội). Phương ngữ miền Bắc có sáu thanh điệu phân biệt. Tiếng Việt miền Nam (TP.HCM) thực tế có năm thanh: thanh hỏi và thanh ngã nhập lại thành một đường nét xuống rồi lên giữa. Tiếng Việt miền Trung (Huế) có âm vị nguyên âm đặc trưng riêng.
Trong dữ liệu văn bản, sự khác biệt phương ngữ thể hiện ở từ vựng (miền Bắc "bố/mẹ" so với miền Nam "ba/má" cho cha và mẹ), một số quy ước chính tả và trong văn viết thông thường trên mạng từ mỗi vùng. Kho ngữ liệu xây dựng gần như hoàn toàn từ báo miền Bắc sẽ tạo ra mô hình sinh văn bản tự nhiên hơn cho người dùng miền Bắc và có thể xử lý kém với tiếng lóng, thành ngữ và văn phong thông thường miền Nam.
Với mô hình tiếng Việt phục vụ toàn quốc: lấy mẫu có chủ đích - báo và văn bản chính phủ miền Bắc, mạng xã hội và thương mại điện tử miền Nam, nguồn vùng miền Trung. Nếu ngân sách giới hạn, miền Bắc cộng miền Nam là sự cân bằng tối thiểu cần thiết.
Tự làm được gì và khi nào cần chuyên gia tiếng Việt bản ngữ?
Tự triển khai hoàn toàn được đối với hạ tầng pipeline. Phát hiện mã hóa và chuyển đổi UTF-8, chuẩn hóa NFC, băm loại trùng, bộ lọc heuristic và xác định ngôn ngữ cơ bản là công việc kỹ thuật không đòi hỏi phán đoán ngôn ngữ học. Kỹ sư dữ liệu có thể triển khai tất cả từ các thông số kỹ thuật trong bài viết này.
Chuyên gia tiếng Việt bản ngữ xứng đáng đầu tư tại ba điểm cụ thể:
- Gán nhãn dữ liệu gốc cho bộ phân loại chất lượng: bộ phân loại lọc tài liệu kém chất lượng cần các ví dụ tiếng Việt sạch để huấn luyện. Người gán nhãn thiếu lưu loát tiếng Việt bản ngữ không thể đánh giá đáng tin cậy văn phong, độ chính xác dấu thanh hay tính phù hợp lĩnh vực trong ngữ cảnh.
- Kiểm định gán nhãn: gán nhãn bằng LLM cho thấy tỷ lệ lỗi cao hơn trên tiếng Việt ít tài nguyên so với tiếng Anh. Ngân sách review 10% bằng người bản ngữ mỗi lô bắt các lỗi có hệ thống trước khi chúng nhân rộng trên toàn bộ dữ liệu.
- Kiểm toán độ bao phủ phương ngữ và lĩnh vực: xác minh kho ngữ liệu bao quát văn viết thông thường miền Nam, văn phong chính thức miền Bắc và thuật ngữ Hán Việt kỹ thuật đòi hỏi người review bản ngữ đọc được cả ba.
Với các dự án bao gồm gán nhãn và kiểm tra chất lượng dữ liệu AI tiếng Việt, trang dịch vụ dữ liệu huấn luyện AI tiếng Việt trình bày các tùy chọn gán nhãn, LQA và review kho ngữ liệu.
Câu hỏi thường gặp
Kho ngữ liệu tiền huấn luyện tiếng Việt sạch tối thiểu cần bao nhiêu token?
Không có ngưỡng tối thiểu chung, nhưng các đội đã thành công huấn luyện mô hình tiếng Việt chuyên biệt với 1-5 tỷ token văn bản sạch. Chất lượng quan trọng hơn nhiều so với kích thước thô. Một tỷ token tiếng Việt được chuẩn hóa, loại trùng và cân bằng phương ngữ đúng cách cho kết quả tốt hơn 10 tỷ token dữ liệu CommonCrawl nhiễu có lỗi mã hóa.
Thư viện phát hiện ngôn ngữ nào tốt nhất cho tiếng Việt?
FastText (mô hình lid.176.bin) và langdetect được dùng phổ biến nhất. FastText nhanh hơn cho xử lý theo lô. Với dữ liệu web crawl có nhiều thuật ngữ kỹ thuật tiếng Anh, CLD3 đôi khi phân loại sai nội dung tiếng Việt. Bộ phân loại fastText được tinh chỉnh trên mẫu web tiếng Việt cho kết quả tốt hơn với những trường hợp đó. Luôn chạy phát hiện ngôn ngữ sau khi chuẩn hóa mã hóa.
Nên dùng tokenization của PhoBERT hay SentencePiece cho LLM tiếng Việt sinh?
Với mô hình encoder-only (phân loại, NER, QA), PhoBERT với tiền xử lý RDRSegmenter là lựa chọn đã được xác lập. Với LLM sinh, SentencePiece được huấn luyện trên văn bản tiếng Việt đã phân đoạn thực tế hơn vì xử lý token ngoài từ điển tốt hơn. Điều quan trọng: huấn luyện từ điển SentencePiece trên văn bản đã tiền phân đoạn, không phải tiếng Việt thô, để có các đơn vị subword có nghĩa.
Làm thế nào để xử lý sự nhập thanh hỏi/ngã trong tác vụ gán nhãn?
Trong tiếng Việt viết, thanh hỏi và thanh ngã luôn được viết khác nhau bằng dấu khác nhau, bất kể nghe như thế nào trong phương ngữ miền Nam. Vi-VN viết chuẩn theo chính tả miền Bắc. Hướng dẫn gán nhãn nên yêu cầu dùng chính tả chuẩn, không phải phiên âm theo cách phát âm. Với tác vụ gán nhãn ASR, cần bước kiểm tra nhất quán theo dạng viết chuẩn.
Có thể dùng GPT-4 hay Claude để gán nhãn bộ dữ liệu LLM tiếng Việt không?
LLM hữu ích cho gán nhãn sơ bộ theo lô trong tiếng Việt, nhưng tỷ lệ lỗi cao hơn tiếng Anh - đặc biệt với thuật ngữ chuyên ngành, phân loại cảm xúc nhạy cảm với thanh điệu và nhận dạng phương ngữ. Dùng LLM để tạo nhãn ban đầu, sau đó xác nhận bằng người nói tiếng Việt bản ngữ trên ít nhất 10% mỗi lô. Với tác vụ liên quan đến văn phong Hán Việt chính thức hoặc thông tục miền Nam, xác nhận bằng con người là bắt buộc.
Nguồn
- NVIDIA Developer Blog - Xử lý dữ liệu tiếng Việt chất lượng cao với NeMo Curator - thống kê lọc: tỷ lệ ký hiệu/số trong dữ liệu thô, giảm 90% dữ liệu, tác động của bộ lọc heuristic và phân loại. Đã xác minh tháng 10/2026.
- Unicode Consortium - FAQ Chuẩn hóa Unicode - dạng NFC vs NFD, dấu phụ tiếng Việt precomposed vs decomposed, dạng khuyến nghị cho lưu trữ. Đã xác minh tháng 10/2026.
- W3C Quốc tế hóa - Chuẩn hóa trong HTML và CSS - hướng dẫn thực tiễn về chuẩn hóa Unicode, combining diacritics. Đã xác minh tháng 10/2026.
- Bộ dữ liệu VietVault - Hugging Face - 6TB CommonCrawl thô xuống 27,5GB sau lọc, pipeline xây dựng kho ngữ liệu tiền huấn luyện tiếng Việt. Đã xác minh tháng 10/2026.
- Crossing Linguistic Horizons: Đánh giá LLM tiếng Việt (arXiv 2403.02715) - độ nhạy dấu phụ, bẫy phân tách từ, kết quả thiên kiến gán nhãn. Đã xác minh tháng 10/2026.
Bài viết bởi Đào Huy (Lucas), biên dịch viên và chuyên viên bản địa hóa tiếng Việt (Anh, Trung, Pháp sang Việt). See translation services →