Xử lý tiếng Việt trong pipeline LLM/RAG: tokenizer, embedding, chuẩn hóa Unicode cần lưu ý gì?

Pipeline mặc định của các thư viện LLM được tối ưu cho English; đưa tiếng Việt vào có ba điểm phải xử lý chủ động:

1. Token inflation — tokenizer BPE học chủ yếu trên English, nên từ tiếng Việt có dấu thường bị tách thành nhiều token hơn: cùng một nội dung, bản tiếng Việt tốn nhiều token hơn bản English đáng kể. Hệ quả: chi phí/request cao hơn, context budget cạn nhanh hơn, giới hạn chunk phải tính lại. Đếm token bằng tokenizer chính thức trên dữ liệu tiếng Việt thật thay vì ước theo số chữ hay theo tài liệu English.

2. Chuẩn hóa Unicode — tiếng Việt có hai cách mã hóa dấu: dựng sẵn (NFC — "ế" là 1 codepoint) và tổ hợp (NFD — "e" + dấu sắc + dấu mũ). Hai dạng hiển thị giống hệt nhưng là chuỗi byte khác nhau → exact match, hash dedup, keyword/BM25 search lệch nhau, embedding cũng có thể lệch nhẹ. Chuẩn hóa NFC nhất quán ở cả ingest và query. Nguồn dữ liệu trộn lẫn còn gặp khác biệt kiểu bỏ dấu cũ/mới ("hoà" vs "hòa") — cần normalize thêm nếu so khớp chuỗi.

3. Embedding multilingual — model embedding English-only cho retrieval tiếng Việt kém rõ rệt. Chọn model đa ngôn ngữ có hỗ trợ tiếng Việt trong dữ liệu train (vd multilingual-e5, BGE-M3) hoặc embedding API đa ngôn ngữ, và eval retrieval trên chính corpus tiếng Việt của bạn — chất lượng giữa các model chênh lớn với ngôn ngữ ít tài nguyên, leaderboard chung không đủ tin.

Ngoài ra: nếu dùng hybrid search, analyzer BM25 phải xử lý dấu/case đúng; kiểm tra đầu ra model sinh giữ dấu chính xác trong eval.