AI xử lý sai tiếng Việt: nguyên nhân và cách fine-tuning khắc phục

Những điểm nổi bật

• Tiếng Việt tốn nhiều token hơn hẳn tiếng Anh (gấp 4,54 lần) do thanh điệu và biến thể nguyên âm, cộng với dữ liệu huấn luyện tiếng Việt vốn ít ỏi so với tiếng Anh, tiếng Trung.
• Mô hình tối ưu cho khu vực vượt trội mô hình tổng quát: SeaLLMs-v3-7B đạt 64,9% trên M3Exam tiếng Việt, cao hơn Qwen2-7B (62,4%), và vượt xa Meta-Llama-3-8B trên bài toán MGSM.
• Giải pháp là fine-tune mô hình nhỏ đã tối ưu tiếng Việt bằng dữ liệu riêng của doanh nghiệp, vừa hiệu quả hơn mô hình lớn, vừa đáp ứng Luật 134/2025 về lưu trữ dữ liệu trong nước.

Một nhóm pháp lý ở Hà Nội đưa yêu cầu rà soát hợp đồng vào GPT-4. Model xử lý tốt các điều khoản tiếng Anh thông dụng, nhưng lại âm thầm hiểu sai một điều khoản miễn trừ trách nhiệm bằng tiếng Việt vì đọc lệch một âm trong cụm "miễn trừ trách nhiệm" so với nghĩa thực sự của câu. Một bệnh viện ở Đà Nẵng yêu cầu Llama tóm tắt một bản tóm tắt xuất viện đầy thuật ngữ y khoa Hán Việt, và nhận lại một bản tóm tắt trôi chảy, đầy tự tin, nhưng sai theo một cách rất khó nhận ra. Bộ phận chống gian lận của một ngân hàng chạy các mô tả giao dịch tiếng Việt qua một model đa dụng, và độ chính xác tụt xuống ngay khi văn bản không còn giống câu mẫu trong sách giáo khoa mà giống cách người Việt thực sự viết.

Đây không phải là những trường hợp hiếm gặp. Đó là trải nghiệm mặc định khi chạy một LLM đa dụng, thiên về tiếng Anh, trên dữ liệu tiếng Việt thực tế và nguyên nhân mang tính cấu trúc sâu hơn nhiều so với việc "chỉ cần viết prompt tốt hơn."

Vấn đề bắt đầu trước khi model kịp đọc chữ

Các mô hình ngôn ngữ lớn không "nhìn" tiếng Việt theo cách con người vẫn đọc. Chúng nhìn thấy token — và cách một tokenizer tách tiếng Việt khác với cách nó tách tiếng Anh chính là điểm khởi đầu của khoảng cách độ chính xác.

Tiếng Việt dùng bảng chữ cái Latin nhưng mang tải dấu rất nặng: sáu dấu thanh cộng thêm các biến thể nguyên âm có thể làm thay đổi hoàn toàn nghĩa của từ. "Ma," "má," "mà," "mả," "mã," và "mạ" là sáu từ hoàn toàn khác nhau, chỉ phân biệt bằng dấu thanh. Phần lớn tokenizer được xây dựng và tinh chỉnh trên corpus thiên về tiếng Anh và tiếng Trung, nên không có đơn vị subword hiệu quả cho các tổ hợp dấu của tiếng Việt — kết quả là chúng cắt từ tiếng Việt thành nhiều token hơn hẳn so với lượng token cần cho văn bản tiếng Anh tương đương. Nghiên cứu đo "khoản phụ phí tokenizer" này cho thấy tiếng Việt cần tới 4.54× số token so với tiếng Anh trên các tokenizer kiểu GPT-2/RoBERTa, và ngay cả các tokenizer đa ngôn ngữ được xây để làm tốt hơn vẫn khiến số token tiếng Việt tăng thêm khoảng 1.4×–3.7× tùy theo họ model (mT5, BLOOM, M2M100). Ngược lại, một tokenizer chuyên biệt cho tiếng Việt như của PhoBERT lại gần như đạt ngang mức token với tiếng Anh, đơn giản vì nó được xây dựng dựa trên đúng cấu trúc của ngôn ngữ này (Petrov et al., NeurIPS 2023).

Khoảng cách này cộng dồn theo ba hướng trong thực tế vận hành: nhiều token hơn cho mỗi tài liệu nghĩa là chi phí API cao hơn cho cùng một nội dung, nhiều token hơn nghĩa là context window khả dụng bị thu hẹp với các tài liệu tiếng Việt dài như hợp đồng hay hồ sơ bệnh án, và quan trọng nhất — một tokenizer cắt từ vụng về khiến model có một biểu diễn đầu vào kém hơn để suy luận, ngay trước khi nó sinh ra một token đầu ra nào.

Khoảng cách độ chính xác thể hiện rõ trên các benchmark

Sự kém hiệu quả của tokenization chỉ là một nửa câu chuyện. Vấn đề lớn hơn nằm ở chính dữ liệu mà model được huấn luyện. Đa số các LLM hàng đầu được huấn luyện chủ yếu trên dữ liệu tiếng Anh và tiếng Trung, còn tiếng Việt, cùng với Bahasa, tiếng Thái và tiếng Khmer chỉ chiếm một phần rất nhỏ trong tập dữ liệu pretraining. Các benchmark độc lập trên MMLU-ProX đã đo được khoảng cách độ chính xác lên tới 24.3 điểm phần trăm giữa các ngôn ngữ giàu tài nguyên và ngôn ngữ ít tài nguyên, trên cùng một bộ câu hỏi (MMLU-ProX, arXiv 2025).

Xu hướng này cũng đúng với các đánh giá dành riêng cho tiếng Việt. Trên benchmark kiến thức tổng hợp M3Exam, model SeaLLMs-v3-7B được tinh chỉnh theo vùng, đạt 64.9% với tiếng Việt, so với 62.4% của Qwen2-7B-Instruct (model đa dụng) và chỉ 51.3% của Sailor-7B. Trên bài toán suy luận toán học (MGSM) bằng tiếng Việt, SeaLLMs-v3-7B đạt 71.2%, so với 46.8% của Meta-Llama-3-8B-Instruct - một khoảng cách 24 điểm trên cùng một tác vụ, cùng độ khó, cùng nhóm kích thước model (SeaLLMs 3, arXiv 2024).

Việc fine-tune riêng cho tiếng Việt còn đẩy hiệu ứng này xa hơn nữa. VinaLLaMA, một checkpoint LLaMA 7B được điều chỉnh cho tiếng Việt, đạt 0.4046 trên benchmark kiến thức VMLU ở chế độ fine-tuned 0-shot, vượt qua BLOOMZ-7B (0.3945) và Vietcuna-7B-v3 (0.3441). Trên bộ đánh giá VLSP, VinaLLaMA-7B-chat đạt 0.4707, vượt qua không chỉ các model cùng kích thước như SeaLLM-7B-chat (0.4252) mà cả URA-LLaMA-13B lớn hơn đáng kể (0.4282). Trên các tác vụ kiến thức tổng hợp, toán học, nhập vai và viết được chấm điểm so với một model tham chiếu, VinaLLaMA-7B-chat đạt kết quả gần bằng ChatGPT-3.5-Turbo, dù chỉ chạy trên một phần nhỏ số lượng tham số (VinaLLaMA, arXiv 2023). Một model nhỏ hơn, được điều chỉnh đúng cho ngôn ngữ nó cần phục vụ, đã vượt qua những model đa dụng lớn hơn mà trên lý thuyết nó không hề có cơ hội cạnh tranh.

Chồng thêm bộ phân loại KYC của một ngân hàng, từ vựng chuyên ngành bồi thường của một công ty bảo hiểm, hay định dạng tóm tắt xuất viện của một bệnh viện lên trên khoảng cách ngôn ngữ đó, sẽ thấy rõ vì sao một bản demo trông ổn khi test bằng tiếng Anh lại âm thầm giảm hiệu suất ngay khi gặp dữ liệu tiếng Việt thực tế trong production.

Vì sao fine-tuning thu hẹp khoảng cách này mà không cần huấn luyện lại từ đầu

Giải pháp không phải là một model lớn hơn, hay một foundation model tiếng Việt xây từ đầu. Rất ít đội ngũ có đủ dữ liệu hoặc ngân sách compute cho việc đó, và cũng không cần thiết. Các phương pháp fine-tuning tiết kiệm tham số như LoRA và QLoRA cho phép điều chỉnh một model open-weight có sẵn như một checkpoint SeaLLMs, một base Qwen2.5, hay một model Gemma trên dữ liệu chuyên ngành tiếng Việt của riêng doanh nghiệp, với chỉ một phần nhỏ lượng compute và dữ liệu so với việc huấn luyện lại toàn bộ. Model không cần học lại ngữ pháp tiếng Việt từ đầu; nó đã có sẵn điều đó từ quá trình pretraining nền hoặc từ một checkpoint theo vùng. Điều fine-tuning dạy thêm cho nó là định dạng tài liệu, thuật ngữ và các trường hợp đặc thù của chính doanh nghiệp, đúng lớp mà các model đa dụng thường bị hụt.

Đây là lý do các kết quả của VinaLLaMA và SeaLLMs nói trên có ý nghĩa hơn những gì thoáng thấy trên bề mặt: chúng cho thấy việc điều chỉnh một model có kích thước phù hợp theo đúng ngôn ngữ và lĩnh vực cần xử lý luôn cho kết quả tốt hơn việc dùng một model lớn hơn, tốn kém hơn, và đa dụng hơn cho cùng một bài toán.

Vì sao bạn không cần tự dựng hạ tầng riêng để làm điều này

Trên thực tế, fine-tuning từ trước đến nay bị chặn lại bởi hạ tầng, không phải bởi kiến thức chuyên môn. Với đa số đội ngũ AI ở Đông Nam Á, điểm nghẽn đó thường không nằm ở compute, mà ở việc kỹ sư phải tự tay ghép nối notebook, storage và inference qua ba, bốn vendor khác nhau được xây cho thị trường Mỹ/EU. Đó chính là phần mà GreenNode AI Platform loại bỏ, không phải bản thân việc fine-tuning:

• Notebook cung cấp cho AI engineer một môi trường Jupyter có GPU, với PyTorch đã được cấu hình sẵn, để một job fine-tuning có thể chạy trên dữ liệu thật ngay trong ngày được lên kế hoạch mà không cần thuê hay mua server, không cần vật lộn với driver CUDA, không cần chờ đội IT.
• Network Volume lưu trữ dữ liệu huấn luyện tiếng Việt, checkpoint và log trong một không gian lưu trữ dùng chung, bền vững, tự động đồng bộ giữa Notebook và Inference, nhờ đó một bộ tài liệu KYC hay một tập ghi chú lâm sàng không bao giờ phải chuyển tay thủ công giữa các môi trường, và cũng không biến mất ngay khi một session notebook dừng lại.
• Model Registry theo dõi từng phiên bản fine-tuned, được import qua Triton, vLLM, hoặc một custom container, cùng với metadata và lineage của nó, giúp đội ngũ dễ dàng so sánh các checkpoint, rollback khi có regression, hoặc trả lời câu hỏi "phiên bản nào đang thực sự phục vụ production" mà không phải lục lại file trên máy của ai đó.

Fine-tuning chỉ là một phần trong toàn bộ pipeline, xem toàn bộ những gì AI Platform xử lý, từ dữ liệu đến triển khai.

Câu chuyện hạ tầng này cũng đang có thêm một chiều tuân thủ pháp lý: Luật số 134/2025/QH15 của Việt Nam, có hiệu lực từ 1/3/2026, là luật AI ràng buộc đầu tiên tại Đông Nam Á và mang theo các yêu cầu về lưu trú dữ liệu (data residency) đối với các hệ thống AI được huấn luyện hoặc vận hành trên dữ liệu tiếng Việt. Fine-tuning trên hạ tầng đặt tại Việt Nam, nơi dữ liệu huấn luyện, checkpoint và inference đều nằm trên cùng một đường dẫn nội địa, ngày càng đáp ứng đồng thời cả vấn đề độ chính xác và vấn đề tuân thủ.

Đội ngũ AI thực sự tiết kiệm được gì

Bỏ qua toàn bộ chu trình mua hoặc thuê và vận hành GPU. Bỏ qua nhiều tuần thường phải dùng để dựng và hoàn thiện một môi trường huấn luyện trước khi chạy fine-tuning lần đầu. Và có được phần thực sự hiện diện trong một buổi review QA: độ chính xác tăng lên đo lường được trên chính văn bản tiếng Việt mà model có nhiệm vụ đọc vì cuối cùng nó đã được huấn luyện trên dữ liệu giống với những gì nó sẽ gặp trong production, không phải trên phần lớn dữ liệu web tiếng Anh mà base model ban đầu được xây dựng từ đó.

Khám phá GreenNode AI Platform để xem model nền được tinh chỉnh theo vùng nào sẽ cho dự án fine-tuning tiếng Việt của bạn điểm khởi đầu tốt nhất, và khởi tạo một Notebook để bắt đầu điều chỉnh model đó trên dữ liệu của riêng bạn.

Câu hỏi thường gặp

Vì sao các model như GPT-4 hay Llama lại hoạt động kém hơn trên tiếng Việt so với tiếng Anh?

Có hai nguyên nhân cộng dồn: tokenizer được xây cho tiếng Anh cắt các từ tiếng Việt mang nhiều dấu thành số token nhiều hơn hẳn (tới 4.54× so với tiếng Anh trên các tokenizer kiểu GPT-2/RoBERTa), và dữ liệu pretraining chủ yếu là tiếng Anh và tiếng Trung, khiến tiếng Việt bị đại diện quá ít, các benchmark cho thấy khoảng cách độ chính xác lên tới 24.3 điểm phần trăm giữa ngôn ngữ giàu và nghèo tài nguyên, trên cùng một bộ câu hỏi.

Tôi có cần huấn luyện một LLM tiếng Việt từ đầu để giải quyết vấn đề này không?

Không. Các phương pháp tiết kiệm tham số như LoRA và QLoRA có thể điều chỉnh một model open-weight có sẵn như một checkpoint SeaLLMs, Qwen2.5, hay Gemma trên dữ liệu chuyên ngành tiếng Việt của riêng bạn, chỉ với một phần nhỏ lượng compute và dữ liệu so với việc huấn luyện lại toàn bộ.

Một model nhỏ hơn đã fine-tune có thực sự vượt qua một model đa dụng lớn hơn không?

Trong nhiều trường hợp, có. VinaLLaMA, một model tiếng Việt 7B đã fine-tune, vượt qua URA-LLaMA-13B lớn hơn đáng kể trên benchmark VLSP, và đạt kết quả gần bằng ChatGPT-3.5-Turbo trên các tác vụ tổng hợp; bằng chứng cho thấy mức độ phù hợp về ngôn ngữ và lĩnh vực quan trọng hơn số lượng tham số thô đối với các tác vụ này.

Sự khác biệt giữa việc dùng một model theo vùng như SeaLLMs và tự fine-tune model riêng là gì?

Một model nền theo vùng như SeaLLMs đã thu hẹp một phần khoảng cách ngôn ngữ ngay từ đầu, không cần chỉnh sửa gì thêm. Fine-tuning đi xa hơn bằng cách dạy cho model đó định dạng tài liệu, thuật ngữ và các trường hợp đặc thù của riêng doanh nghiệp, lớp kiến thức chuyên ngành mà một model nền theo vùng vẫn chưa thể biết.

Tôi có cần mua GPU để fine-tune một model trên dữ liệu của mình không?

Không. Một môi trường notebook có GPU với framework huấn luyện đã được cấu hình sẵn cho phép bạn chạy một job fine-tuning ngay trong ngày được lên kế hoạch, cùng với hệ thống lưu trữ bền vững giữ dataset và checkpoint luôn sẵn sàng qua các session mà không cần thuê server hay tự dựng cluster.

Fine-tuning trên hạ tầng trong nước có giúp ích gì cho việc tuân thủ Luật AI mới của Việt Nam không?

Luật số 134/2025/QH15 của Việt Nam (có hiệu lực từ 1/3/2026) mang theo các yêu cầu về lưu trú dữ liệu đối với các hệ thống AI được huấn luyện hoặc vận hành trên dữ liệu tiếng Việt. Fine-tuning trên hạ tầng đặt vật lý tại Việt Nam giúp giữ dữ liệu huấn luyện, checkpoint và inference trên cùng một đường dẫn nội địa, giải quyết đồng thời cả vấn đề độ chính xác và vấn đề tuân thủ.