Tiếng Việt làm hỏng tính năng AI ở những chỗ ít ai ngờ: hai chuỗi trông giống hệt nhau nhưng khác mã Unicode nên so sánh sai, người dùng gõ không dấu nên tìm kiếm không ra, từ ghép nhiều âm tiết bị tách sai, ngày tháng bị đọc nhầm thứ tự, và mô hình trả lời lẫn tiếng Anh hay xưng hô lệch giọng. Phần lớn những lỗi này không nằm ở mô hình mà ở đoạn mã xử lý văn bản trước và sau khi gọi mô hình.
Bài này dành cho lập trình viên làm sản phẩm cho người dùng Việt. Bạn sẽ có danh sách những bước chuẩn hoá nên làm ở mọi đầu vào, đoạn mã ngắn bằng Python, JavaScript và PHP, cách xử lý tìm kiếm không dấu, cách dặn mô hình về giọng và định dạng, và một bộ câu kiểm riêng cho tiếng Việt.
Một chữ, hai cách mã hoá: chuẩn hoá Unicode trước mọi thứ
Chữ “ế” có thể được lưu bằng một ký tự dựng sẵn, hoặc bằng chữ e cộng dấu mũ cộng dấu sắc dạng tổ hợp. Trên màn hình hai cách trông giống hệt nhau, nhưng với máy tính đó là hai chuỗi khác nhau. Dạng dựng sẵn gọi là NFC, dạng tổ hợp gọi là NFD. Văn bản dán từ một số phần mềm soạn thảo, tên tệp trên macOS, dữ liệu xuất từ hệ thống cũ, và một số bộ gõ có thể cho ra dạng tổ hợp hoặc trộn cả hai.
Hậu quả cụ thể: người dùng tìm “Huế” không ra bài có chữ “Huế” vì một bên dựng sẵn một bên tổ hợp; hai bản ghi khách hàng trùng tên không được gộp; hàm đếm độ dài trả về số khác nhau cho cùng một chữ; bộ đệm theo mã băm câu lệnh trượt vì hai câu hỏi giống hệt nhau về mặt đọc. Với mô hình ngôn ngữ, dạng tổ hợp thường làm tăng số token và có thể làm kết quả kém đi.
Cách xử lý là chuẩn hoá về NFC ngay tại cửa vào: mọi dữ liệu người dùng nhập, mọi tài liệu nạp vào kho, mọi câu trả lời mô hình trả về trước khi lưu. Trong Python dùng unicodedata.normalize("NFC", chuoi). Trong JavaScript là chuoi.normalize("NFC"). Trong PHP cần tiện ích intl: Normalizer::normalize($chuoi, Normalizer::FORM_C). Chuẩn hoá một lần ở cửa vào rẻ hơn rất nhiều so với dò lỗi so sánh rải rác khắp hệ thống.
Tìm kiếm khi người dùng gõ không dấu hoặc thiếu dấu
Lưu thêm một bản không dấu để tìm. Bên cạnh văn bản gốc, lưu một cột hay một trường đã bỏ dấu và chuyển chữ thường. Câu hỏi của người dùng cũng bỏ dấu theo cùng cách rồi mới so. Kết quả hiển thị vẫn lấy từ văn bản gốc có dấu.
Bỏ dấu đúng cách, nhớ chữ đ. Trong Python, tách dấu bằng unicodedata.normalize("NFD", chuoi) rồi bỏ các ký tự có unicodedata.category(c) == "Mn". Chữ đ và Đ không tách dấu theo cách này vì chúng là ký tự riêng, phải thay bằng d và D riêng một bước.
Ưu tiên kết quả khớp có dấu. Bỏ dấu làm “bán” và “bàn” thành một. Khi người dùng gõ có dấu, xếp kết quả khớp đúng dấu lên trước; chỉ khi họ gõ không dấu mới coi các biến thể là ngang nhau.
Để mô hình viết lại câu hỏi khi cần. Với trợ lý RAG, một bước nhỏ nhờ mô hình chuyển câu hỏi không dấu hoặc viết tắt thành câu đầy đủ có dấu trước khi tìm véc-tơ thường cải thiện kết quả. Mô hình lớn đọc tiếng Việt không dấu khá tốt, nhưng mô hình nhúng thì kém hơn với kiểu đầu vào này.
Tách từ: tiếng Việt viết cách theo âm tiết, không theo từ
Tiếng Anh dùng khoảng trắng để tách từ; tiếng Việt dùng khoảng trắng để tách âm tiết. “Học sinh” là một từ gồm hai âm tiết, “sinh học” cũng vậy nhưng nghĩa khác hẳn. Bộ tìm kiếm từ khoá tách theo khoảng trắng sẽ coi hai cụm này gần như giống nhau, vì cùng chứa hai âm tiết “học” và “sinh”.
Có hai hướng xử lý. Hướng đơn giản là đánh chỉ mục thêm theo cặp âm tiết liền nhau, nên “học sinh” và “sinh học” thành hai mục khác nhau và cụm khớp đúng thứ tự được điểm cao hơn. Hướng kỹ hơn là dùng một công cụ tách từ tiếng Việt trước khi đánh chỉ mục; có vài thư viện mã nguồn mở cho việc này, chất lượng và tốc độ khác nhau, bạn thử trên dữ liệu của mình trước khi chọn.
Với tìm kiếm véc-tơ trong RAG, chuyện tách từ do mô hình nhúng tự lo, nên ít phải bận tâm hơn. Nhưng nếu bạn kết hợp tìm véc-tơ với tìm từ khoá, phần từ khoá vẫn cần cách xử lý trên. Hệ quản trị cơ sở dữ liệu phổ biến có chức năng tìm toàn văn, nhưng cấu hình mặc định thường dành cho tiếng Anh; kiểm cách nó tách tiếng Việt trước khi dựa vào.
Dặn mô hình về giọng, xưng hô và định dạng
Mô hình viết tiếng Việt tốt hơn nhiều so với vài năm trước, nhưng vẫn có những lệch mà người dùng Việt nhận ra ngay. Câu lệnh hệ thống nên nói rõ những điều dưới đây.
| Vấn đề hay gặp | Dặn trong câu lệnh thế nào | Kiểm bằng mã được không |
|---|---|---|
| Trả lời lẫn từ tiếng Anh không cần thiết | Luôn trả lời bằng tiếng Việt; thuật ngữ có từ Việt thông dụng thì dùng từ Việt, chỉ ghi tiếng Anh trong ngoặc khi cần | Được một phần: đếm tỉ lệ từ không có trong từ điển tiếng Việt |
| Xưng hô không nhất quán | Nêu rõ trợ lý xưng gì, gọi người dùng là gì, giữ suốt cuộc trò chuyện | Được: tìm các đại từ không nằm trong danh sách cho phép |
| Ngày tháng theo kiểu Mỹ | Ngày viết theo dạng ngày/tháng/năm; khi trả JSON dùng định dạng năm-tháng-ngày chuẩn quốc tế | Được, với đầu ra có cấu trúc |
| Số và tiền sai dấu phân cách | Văn bản cho người đọc dùng dấu chấm phân cách nghìn, dấu phẩy thập phân; JSON dùng số thuần | Được |
| Văn dịch, câu cứng | Đưa hai ba câu trả lời mẫu viết tự nhiên do người Việt viết | Không, cần người đọc |
| Địa danh cũ | Ghi rõ đơn vị hành chính hiện hành nếu tính năng có nhắc địa danh; mô hình có thể dùng tên trước khi sắp xếp lại | Được: so với danh sách tỉnh thành hiện hành |
Hàng cuối đáng lưu ý với sản phẩm có địa chỉ: từ giữa năm 2025, Việt Nam còn 34 tỉnh thành và bỏ cấp huyện. Dữ liệu huấn luyện của mô hình có thể chủ yếu là cách gọi cũ, nên đừng để mô hình tự sinh danh sách địa danh; lấy từ bảng dữ liệu của bạn và đưa vào câu lệnh hoặc công cụ.
Lưu trữ và truyền tải: những lỗi mã hoá vẫn còn gặp
Phần này không riêng gì AI, nhưng tính năng AI thường là lần đầu một hệ thống cũ nhận nhiều văn bản tự do, nên lỗi cũ lộ ra:
- MySQL và MariaDB với bộ mã utf8: tên này thực chất là utf8mb3, chỉ chứa ký tự tối đa ba byte. Câu trả lời của mô hình có biểu tượng cảm xúc sẽ bị cắt hoặc báo lỗi. Dùng utf8mb4 cho bảng, cột và cả kết nối.
- Cắt chuỗi theo byte: hàm cắt chuỗi không hiểu đa byte có thể chém đôi một chữ có dấu, sinh ký tự hỏng ở cuối. Trong PHP dùng nhóm hàm mb_ thay cho hàm thường.
- Đếm độ dài theo byte khi giới hạn ô nhập: một chữ có dấu chiếm nhiều byte, người dùng Việt bị chặn sớm hơn người gõ không dấu.
- Tệp CSV mở bằng phần mềm bảng tính hiện lỗi phông khi thiếu dấu hiệu thứ tự byte; khi xuất kết quả AI ra CSV cho người dùng tải, cân nhắc thêm dấu hiệu này.
- Nhật ký ghi sai mã hoá: dòng nhật ký có tiếng Việt bị lỗi phông làm việc đọc lại câu hỏi người dùng khi gỡ lỗi trở nên vô dụng.
Một phép thử nhanh cho cả hệ thống: nhập một câu có đủ dấu, có chữ đ hoa, có biểu tượng cảm xúc, dạng tổ hợp, rồi theo nó đi qua giao diện, máy chủ, lời gọi mô hình, cơ sở dữ liệu, nhật ký và tệp xuất. Chỗ nào chữ bị biến dạng là chỗ cần sửa.
Bộ câu kiểm riêng cho tiếng Việt
Thêm vào bộ đánh giá của tính năng một nhóm câu hỏi chỉ để kiểm chuyện ngôn ngữ. Gợi ý các loại câu nên có:
- Câu gõ không dấu hoàn toàn, và câu gõ thiếu dấu một phần.
- Câu có lỗi bộ gõ thường gặp, như dấu đặt sai vị trí hay ký tự gõ kiểu Telex chưa được chuyển.
- Câu viết tắt kiểu nhắn tin quen thuộc, như ko, đc, sp, ib.
- Câu dùng từ địa phương ba miền cho cùng một ý.
- Câu chứa số tiền viết kiểu nói, như hai trăm rưỡi, một triệu hai, và ngày tháng kiểu nói, như mùng năm tháng sau.
- Câu dạng tổ hợp Unicode dán từ nguồn ngoài, để chắc bước chuẩn hoá đang chạy.
Với mỗi câu, tiêu chí đạt là trợ lý hiểu đúng ý và trả lời bằng tiếng Việt chuẩn, đúng giọng đã quy định. Nhóm câu này thường lộ ra lỗi ở bước tìm kiếm hay chuẩn hoá nhiều hơn là ở mô hình.
Đầu vào từ ảnh chụp và giọng nói: lỗi dấu sinh ra từ bước trước
Nhiều tính năng AI cho người dùng Việt không nhận chữ gõ mà nhận ảnh chụp hoá đơn, phiếu viết tay, hoặc tin nhắn thoại được chuyển thành chữ. Ở đây văn bản đến tay mô hình đã đi qua một bước nhận dạng, và bước đó có kiểu lỗi riêng: nhầm dấu hỏi với dấu ngã, mất dấu ở chữ in nhỏ, tách sai âm tiết, chép sai tên riêng và số. Mô hình phía sau thường không biết chữ nào là lỗi nhận dạng, nên nó tự tin trả lời trên một câu đã bị méo.
Ba thói quen giúp giảm hại. Thứ nhất, giữ lại bản gốc là ảnh hoặc tệp âm thanh, và lưu kèm văn bản nhận dạng, để người dùng hay nhân viên đối chiếu khi cần. Thứ hai, với các trường quan trọng như số tiền, số lượng, mã sản phẩm, đừng để mô hình tự sửa lỗi nhận dạng bằng cách đoán; yêu cầu nó đánh dấu trường không chắc và hiện ô cho người xác nhận. Thứ ba, nói rõ trong câu lệnh rằng văn bản đến từ nhận dạng tự động và có thể có lỗi dấu, để mô hình bớt bám từng chữ.
Khi dựng bộ kiểm cho loại tính năng này, lấy mẫu từ đầu ra nhận dạng thật chứ không gõ lại sạch sẽ bằng tay. Bộ kiểm sạch sẽ cho kết quả đẹp hơn thực tế rất nhiều.
Câu hỏi thường gặp
Mô hình ngôn ngữ có hiểu tiếng Việt không dấu không?
Các mô hình lớn hiện nay thường hiểu khá tốt câu không dấu trong ngữ cảnh rõ, nhưng dễ nhầm khi câu ngắn hoặc nhiều nghĩa. Mô hình nhỏ và mô hình nhúng kém hơn. Vì vậy với bước tìm kiếm, nên chuẩn hoá hoặc viết lại câu hỏi trước.
Có nên tự thêm dấu cho câu người dùng gõ không dấu không?
Có thể dùng mô hình để thêm dấu cho mục đích tìm kiếm nội bộ, nhưng không nên thay đổi câu người dùng hiển thị trên giao diện mà không báo. Việc thêm dấu có thể sai với tên riêng và từ địa phương.
Câu lệnh hệ thống viết tiếng Việt có tốn token hơn tiếng Anh không?
Thường là có, vì bộ tách token của nhiều mô hình tối ưu cho tiếng Anh và tiếng Việt có dấu bị tách thành nhiều mẩu hơn. Mức chênh khác nhau theo mô hình; đếm thật bằng công cụ của hãng rồi mới quyết định, đừng đổi ngôn ngữ chỉ vì nghe nói.
Chuẩn hoá Unicode có làm hỏng dữ liệu cũ không?
Chuẩn hoá về NFC không làm đổi nghĩa hay cách hiển thị, chỉ đổi cách mã hoá bên dưới. Với dữ liệu cũ, chạy một lần chuyển đổi có sao lưu trước, và nhớ cập nhật luôn các chỉ mục tìm kiếm hay mã băm đã tính trên dữ liệu cũ.
Có nên dùng mô hình chuyên tiếng Việt thay cho mô hình đa ngôn ngữ không?
Tuỳ việc. Một số mô hình được tinh chỉnh cho tiếng Việt viết tự nhiên hơn trong vài loại việc, nhưng có thể kém hơn ở suy luận hay gọi công cụ. Chạy cùng bộ kiểm tiếng Việt của bạn trên các lựa chọn rồi quyết định theo kết quả.
Làm sao xử lý tên người Việt trong dữ liệu đưa vào mô hình?
Tên người là thông tin cá nhân; nếu tính năng không cần tên, thay bằng ký hiệu trước khi gửi. Nếu cần, ví dụ để xưng hô với khách, chỉ gửi phần tên dùng để gọi và đọc điều khoản dữ liệu của nhà cung cấp. Đừng để mô hình đoán giới tính từ tên để chọn xưng hô.