Một chữ Việt có dấu như “ệ” có thể được lưu trong máy theo hai cách: một ký tự dựng sẵn (một mã duy nhất cho “ệ”), hoặc một chuỗi tổ hợp gồm chữ “e” cộng dấu mũ cộng dấu nặng. Trên màn hình hai cách trông giống hệt nhau, nhưng với máy chúng là hai chuỗi khác nhau. Hệ quả: tìm “Việt” trong một tệp được gõ kiểu tổ hợp sẽ không thấy, hai tên khách hàng giống nhau bị coi là hai người, dữ liệu đưa vào huấn luyện AI có hai phiên bản của cùng một chữ.
Cách xử lý chuẩn là chuẩn hoá Unicode về một dạng thống nhất, phổ biến nhất là dạng NFC (gộp về ký tự dựng sẵn) trước khi lưu, so sánh hay đưa vào mô hình. Bài này giải thích từ gốc: chữ Việt đã đi qua những bảng mã nào, vì sao Unicode lại có hai cách, lỗi biểu hiện ra sao trong công việc hằng ngày, và người không chuyên kiểm tra thế nào.
Từ TCVN3, VNI đến Unicode: chữ Việt đã đi qua những bảng mã nào
Trước khi Unicode phổ biến, người Việt dùng máy tính với nhiều bảng mã tự chế, mỗi bảng mã đi kèm một bộ phông chữ riêng. Đây là nguồn gốc của những tệp văn bản cũ mở ra toàn ký tự lạ.
- VIQR: không phải bảng mã mà là quy ước gõ chữ Việt bằng ký tự ASCII, ví dụ “Vie^.t Nam”. Từng dùng nhiều trong thư điện tử và diễn đàn thời đầu mạng, khi máy nhận chưa hiển thị được chữ có dấu.
- TCVN3 (hay gọi là bảng mã ABC): bảng mã 8 bit, đi kèm các phông có tiền tố “.Vn” như .VnTime. Rất phổ biến trong văn bản hành chính và trường học một thời; nhiều kho tài liệu cũ vẫn còn ở dạng này.
- VNI: bảng mã của một hãng phần mềm, đi kèm các phông tên bắt đầu bằng “VNI-”. Phổ biến ở phía Nam và trong ngành in một thời gian dài.
- Unicode: bộ mã quốc tế dành chỗ cho mọi chữ viết, trong đó có đủ chữ Việt. Việt Nam có tiêu chuẩn bộ mã ký tự tiếng Việt dựa trên Unicode là TCVN 6909:2001, và đầu những năm 2000 có quyết định của Thủ tướng yêu cầu cơ quan nhà nước dùng bộ mã này. Ngày nay hầu hết hệ điều hành, trình duyệt, điện thoại mặc định Unicode.
Với AI, các bảng mã cũ là một nguồn rác dữ liệu đáng kể. Một tài liệu TCVN3 mở bằng phông Unicode sẽ hiện thành chuỗi ký tự như “ViÖt Nam”. Nếu kho văn bản thu thập từ mạng lẫn những trang như vậy mà không được lọc hoặc chuyển mã, mô hình sẽ học cả những chuỗi vô nghĩa đó. Những công cụ chuyển mã đã có từ lâu, kể cả trong các bộ gõ quen thuộc như Unikey, nhưng phải đoán đúng bảng mã nguồn mới chuyển được.
Vì sao Unicode cho phép hai cách viết một chữ
Unicode được thiết kế để vừa tương thích với các bảng mã cũ của nhiều nước, vừa có cách ghi những tổ hợp chữ và dấu không lường trước được. Vì thế với những chữ có dấu thông dụng, Unicode có sẵn một mã riêng, gọi là ký tự dựng sẵn. Chữ Việt được ưu ái: gần như toàn bộ các tổ hợp nguyên âm với dấu thanh đều có mã dựng sẵn, nằm chủ yếu trong vùng “Latin Extended Additional”. Ví dụ “ệ” có mã U+1EC7.
Song song đó, Unicode có các dấu kết hợp: những ký tự đứng sau một chữ cái và “đội” lên chữ ấy khi hiển thị. Dấu huyền, sắc, hỏi, ngã, nặng, dấu mũ, dấu móc đều có dạng kết hợp. Gõ “e” rồi dấu mũ kết hợp rồi dấu nặng kết hợp, màn hình cũng hiện ra “ệ”. Chuỗi này dài ba ký tự, trong khi bản dựng sẵn chỉ một ký tự.
Unicode coi hai cách viết này là tương đương chuẩn, tức cùng một chữ về mặt ý nghĩa, và định nghĩa các dạng chuẩn hoá để quy đổi qua lại. Hai dạng quan trọng nhất là NFC (gộp: đổi chuỗi tổ hợp thành ký tự dựng sẵn khi có thể) và NFD (tách: đổi ký tự dựng sẵn thành chữ gốc cộng dấu). Vấn đề là phần mềm nào cũng phải chủ động gọi bước chuẩn hoá; nếu không gọi, phép so sánh thông thường chỉ so từng mã, thấy khác là báo khác.
Thêm một chi tiết làm rối: với chữ có hai dấu như “ệ”, thứ tự hai dấu kết hợp cũng có quy tắc. Bộ gõ nhập dấu nặng trước dấu mũ có thể tạo ra một chuỗi tổ hợp khác thứ tự chuẩn. Bước chuẩn hoá NFC và NFD xử lý luôn chuyện sắp thứ tự, nên lại thêm lý do không nên tự viết hàm thay thế ký tự bằng tay.
Lỗi biểu hiện thế nào trong công việc hằng ngày
Tìm không ra chữ đang nhìn thấy. Nhân viên mở một tệp Word nhận từ đối tác, bấm tìm “Nguyễn”, máy báo không có, trong khi chữ “Nguyễn” hiện ngay trên trang. Nguyên nhân thường là tệp gốc được gõ bằng bộ gõ đặt chế độ tổ hợp, hoặc chép từ một hệ thống lưu kiểu tách.
Trùng khách hàng, lệch số liệu. Trong bảng tính, hàm đếm số lần xuất hiện của “Hà Nội” cho ra hai nhóm vì một nửa số dòng được nhập từ biểu mẫu web, nửa kia dán từ thư điện tử. Báo cáo theo tỉnh thành sai mà không ai thấy, vì hai nhóm trông giống hệt nhau.
Sắp xếp theo vần lạ. Danh sách học sinh sắp theo tên ra thứ tự kỳ quặc: các tên có dấu dồn xuống cuối, hoặc cùng một tên đứng ở hai chỗ. Ngoài chuyện dựng sẵn với tổ hợp, việc sắp chữ Việt đúng thứ tự từ điển (a, ă, â, b, c, d, đ…) còn cần quy tắc so sánh riêng cho tiếng Việt mà nhiều phần mềm không bật mặc định.
Tên tệp và đường dẫn. Một số hệ điều hành và hệ thống lưu trữ từng có thói quen lưu tên tệp ở dạng tách. Chép thư mục có tên tiếng Việt qua lại giữa các máy, đôi khi tên tệp hiện giống nhau nhưng chương trình báo không tìm thấy.
Dữ liệu AI đếm sai. Khi gom văn bản để huấn luyện hoặc đánh giá mô hình, cùng một từ ở hai dạng sẽ bị đếm là hai từ, làm sai thống kê tần suất, làm bộ tách token học hai mảnh khác nhau cho một chữ. Ở bước khử trùng lặp, hai văn bản giống hệt nhau về chữ nhưng khác dạng mã sẽ lọt qua.
Chatbot trả lời lệch. Phần lớn mô hình lớn chịu được cả hai dạng vì đã gặp đủ trong dữ liệu, nhưng dạng tổ hợp thường bị cắt thành nhiều token hơn. Trong các hệ thống tìm kiếm tài liệu nội bộ để chatbot trả lời, nếu tài liệu ở một dạng còn câu hỏi ở dạng khác, bước tìm theo từ khoá có thể bỏ sót đúng tài liệu cần.
Kiểm tra một tệp đang ở dạng nào mà không cần lập trình
Có vài mẹo đơn giản để biết văn bản trước mặt là dựng sẵn hay tổ hợp, hay đang ở bảng mã cũ. Làm với bản sao, không làm trên tệp gốc duy nhất.
- Đặt con trỏ ngay sau một chữ có dấu, ví dụ “ệ”, rồi bấm phím xoá lùi một lần. Nếu cả chữ “ệ” biến mất, đó là ký tự dựng sẵn. Nếu chỉ dấu nặng mất và còn lại “ê”, đó là dạng tổ hợp.
- Đếm ký tự: chép một từ như “Việt” vào ô tính rồi dùng hàm đếm độ dài. Dạng dựng sẵn cho 4 ký tự; dạng tổ hợp cho nhiều hơn vì các dấu được tính riêng.
- Nhìn phông: nếu tệp chỉ hiện đúng khi chọn phông .VnTime hay VNI-Times, và đổi sang Arial thì vỡ chữ, tệp đang ở bảng mã cũ TCVN3 hoặc VNI, cần chuyển mã sang Unicode.
- Dùng chức năng chuyển mã của bộ gõ (ví dụ mục chuyển mã trong Unikey) với lựa chọn đích là “Unicode dựng sẵn”, áp lên bản sao, rồi thử tìm kiếm lại.
- Với dữ liệu lớn hay dữ liệu dùng cho AI, giao cho người làm kỹ thuật chạy bước chuẩn hoá NFC trên toàn bộ kho, rồi kiểm thử bằng cách đếm số chuỗi thay đổi trước và sau.
Mẹo xoá lùi phụ thuộc phần mềm soạn thảo; một số trình soạn thảo xoá cả cụm chữ và dấu như một khối. Khi nghi ngờ, phép đếm độ dài là cách chắc chắn hơn.
Quy tắc cho người làm dữ liệu và sản phẩm AI tiếng Việt
Chuẩn hoá ở cửa vào, một lần, thống nhất. Mọi văn bản đi vào hệ thống, dù từ biểu mẫu, tệp tải lên hay dữ liệu thu thập, nên được chuẩn hoá về NFC ngay khi nhận. Không để mỗi bộ phận tự chuẩn hoá theo kiểu riêng. Lưu một dạng, so một dạng.
Chuẩn hoá cả câu hỏi lẫn tài liệu. Trong hệ thống hỏi đáp tài liệu nội bộ, chuẩn hoá tài liệu mà quên chuẩn hoá câu người dùng gõ là lỗi kinh điển. Người dùng iPhone, Android, máy tính bàn với những bộ gõ khác nhau có thể sinh ra dạng mã khác nhau.
Tách chuyện mã ký tự khỏi chuyện chính tả. Chuẩn hoá Unicode không biến “hòa” thành “hoà” hay “kĩ” thành “kỹ”, vì đó là những cách viết khác nhau thật sự chứ không phải hai mã của một chữ. Vấn đề vị trí dấu thanh và i hay y cần một bước chuẩn hoá chính tả riêng, có chủ đích, và nên ghi rõ trong tài liệu dữ liệu.
Đừng bỏ dấu để “cho dễ tìm” rồi quên phục hồi. Một số hệ thống đánh chỉ mục bản không dấu song song để người gõ không dấu vẫn tìm được. Cách này hữu ích, nhưng bản không dấu chỉ dùng để tìm; phần hiển thị và phần đưa vào mô hình phải là bản có dấu đầy đủ.
Ghi lại quy ước. Bộ dữ liệu tiếng Việt chia sẻ cho người khác nên có một dòng nói rõ dạng chuẩn hoá đã dùng. Nhiều lỗi khó hiểu khi ghép hai bộ dữ liệu xuất phát từ việc một bộ ở NFC, bộ kia ở NFD mà không ai ghi lại.
Khi nào lỗi không phải do dựng sẵn hay tổ hợp
Không phải mọi lỗi chữ Việt đều do chuyện mã. Chữ hiện thành ô vuông thường là phông đang dùng không có hình cho ký tự đó, dữ liệu vẫn đúng; đổi phông là xong. Chữ hiện thành chuỗi như “Việt” là lỗi giải mã: dữ liệu ghi theo UTF-8 nhưng chương trình đọc theo một bảng mã khác, thường gặp khi mở tệp CSV bằng bảng tính mà không chọn mã UTF-8.
Lỗi dấu lệch chỗ hay dấu rơi khỏi chữ trên một số máy thường là phông chữ hiển thị kém với dạng tổ hợp: dữ liệu đúng nhưng phông không xếp dấu đẹp. Chuyển về dựng sẵn sẽ hết. Lỗi chữ “đ” bị thay bằng “d” hay chữ “ư” thành “u” lại là lỗi mất dữ liệu thật, thường do một bước nào đó đã bỏ dấu, và không có phép chuẩn hoá nào lấy lại được; phải tìm bản gốc hoặc phục hồi dấu bằng mô hình, kèm người soát.
Một lỗi khác hay bị nhầm là ký tự giống nhau nhưng khác bảng chữ: chữ “o” Latin và chữ “о” Kirin trông y hệt. Trường hợp này hiếm trong văn bản tiếng Việt thông thường nhưng có xuất hiện trong tin nhắn lừa đảo cố tình né bộ lọc. Bước chuẩn hoá NFC không gộp được hai chữ này; cần quy tắc phát hiện riêng.
Thói quen tốt khi gặp một lỗi chữ: trước khi sửa, xác định lỗi thuộc loại nào trong bốn loại vừa kể (phông, giải mã, dạng mã, mất dữ liệu). Sửa sai loại không những không hết lỗi mà còn có thể biến một lỗi hiển thị vô hại thành mất dữ liệu thật.
Câu hỏi thường gặp
Nên chọn Unicode dựng sẵn hay tổ hợp khi cài bộ gõ?
Nên chọn dựng sẵn. Đây là dạng phổ biến nhất trên web, trong văn bản hành chính và trong phần lớn dữ liệu, nên ít gây lỗi tìm kiếm, sắp xếp và hiển thị nhất. Dạng tổ hợp chỉ nên dùng khi một hệ thống cụ thể yêu cầu, và khi đó cần biết rõ lý do.
Chatbot có hiểu văn bản ở dạng tổ hợp không?
Phần lớn chatbot hiện nay đọc được cả hai dạng vì đã gặp đủ trong dữ liệu huấn luyện. Tuy vậy dạng tổ hợp thường bị cắt thành nhiều token hơn, tốn ngữ cảnh hơn, và có thể làm lệch bước tìm tài liệu trong các hệ thống hỏi đáp nội bộ. Chuẩn hoá trước khi gửi vẫn là cách an toàn.
Chuyển tài liệu TCVN3 cũ sang Unicode có mất dấu không?
Nếu đoán đúng bảng mã nguồn và dùng công cụ chuyển mã đáng tin, chữ được giữ nguyên. Rủi ro nằm ở tệp trộn nhiều bảng mã, ví dụ tiêu đề dùng VNI còn thân bài dùng TCVN3, hoặc tệp đã bị mở và lưu sai một lần. Nên chuyển trên bản sao và đọc soát vài trang trước khi xoá bản gốc.
NFC và NFKC khác nhau thế nào, có nên dùng NFKC cho tiếng Việt?
NFKC đi xa hơn NFC: ngoài gộp chữ và dấu, nó còn quy đổi các ký tự “tương đương tương thích”, như chữ số toàn khổ hay ký hiệu đặc biệt, về dạng thường. Cách này tiện cho tìm kiếm nhưng có thể làm mất thông tin định dạng. Với kho văn bản tiếng Việt dùng cho lưu trữ và AI, NFC là lựa chọn mặc định an toàn hơn.
Vì sao chép chữ từ PDF sang Word bị vỡ dấu?
Nhiều tệp PDF lưu chữ theo cách bố trí hình chữ chứ không theo thứ tự ký tự chuẩn, hoặc dùng phông nhúng ánh xạ mã riêng. Khi chép ra, dấu có thể tách khỏi chữ, đổi thứ tự hoặc thành ký tự lạ. Cách khắc phục là chuyển mã, chuẩn hoá lại, hoặc dùng công cụ nhận dạng chữ trên ảnh trang rồi soát lỗi.
Làm sao biết một bộ dữ liệu tiếng Việt tải về đã chuẩn hoá chưa?
Đọc tài liệu đi kèm xem có ghi dạng chuẩn hoá không. Nếu không có, nhờ người kỹ thuật đếm số chuỗi thay đổi khi chạy chuẩn hoá NFC trên một mẫu. Số đó bằng không nghĩa là bộ dữ liệu đã ở NFC; khác không nghĩa là có lẫn dạng tổ hợp và cần chuẩn hoá trước khi dùng.