Độ chính xác AI tạo sinh tiếng Việt — chỗ hỏng là tiền xử lý chứ không phải mô hình

Phản hồi “AI tạo sinh xử lý tiếng Việt không đủ chính xác” hầu như luôn được đưa lên như một vấn đề của mô hình. Với tiếng Nhật hoặc tiếng Anh thì hệ thống chạy đúng như kỳ vọng, chỉ riêng tiếng Việt là độ chính xác tụt xuống. Phần lớn các nhà máy sẽ đổi sang mô hình khác, và thường là không hết. Thứ đang hỏng không phải mô hình, mà là phần xử lý ký tự và từ nằm phía trước mô hình. Bài viết này chia quy trình xử lý tiếng Việt thành bốn tầng và sắp xếp theo từng mục đích sử dụng — sửa tầng nào thì cải thiện được điều gì.

Khi có báo cáo “AI tạo sinh xử lý tiếng Việt không chính xác”, thực tế đang xảy ra chuyện gì

Ở các cơ sở tại Việt Nam, báo cáo đầu tiên thường có ba dạng sau.

• Tìm kiếm tài liệu nội bộ nhưng tài liệu chắc chắn có lại không ra. Hỏi cùng nội dung đó bằng tiếng Nhật thì lại ra
• Tổng hợp nhật ký sản xuất hoặc hồ sơ kiểm tra viết bằng tiếng Việt thì con số cộng lại không khớp với cảm nhận của hiện trường. Hồ sơ của cùng một thiết bị bị tách làm hai
• Dịch và tóm tắt thì chạy được, nhưng bản dịch cứng, danh từ riêng bị đổi, cách diễn đạt không giống cách nói quen dùng trong nội bộ

Cả ba đều không xuất hiện ở dạng “luôn luôn sai” mà ở dạng “thỉnh thoảng sai”. Đây chính là chỗ khó xử lý. Nếu luôn sai thì người ta sẽ nghi cấu hình. Còn cái thỉnh thoảng sai thì không viết được các bước tái hiện. Lỗi không viết được bước tái hiện rất dễ bị bỏ qua khâu xác định nguyên nhân và dừng lại ở kết luận “mô hình chưa đủ mạnh”.

Thế là người ta đổi mô hình. Mô hình mới hơn, mô hình lớn hơn, mô hình quảng cáo là hỗ trợ tiếng Việt. Nhưng triệu chứng vẫn còn nguyên hình dạng cũ. Số lần tìm kiếm trượt có thể giảm đi chút ít, nhưng tài liệu nào không ra thì vẫn không ra.

Lý do rất đơn giản — mô hình nằm ở cuối chuỗi xử lý. Chuỗi ký tự đã hỏng ở đầu nguồn, hoặc từ đã bị cắt sai ở đầu nguồn, sẽ đi thẳng vào mô hình dưới dạng đầu vào. Nếu đầu vào đã hỏng thì mô hình nào cũng vấp ở đúng chỗ đó. Đổi mô hình không hết bệnh vì chưa ai động vào chỗ cần sửa.

Và có hai đặc điểm của chữ viết tiếng Việt không lộ ra khi hệ thống chỉ xử lý tiếng Nhật hoặc tiếng Anh. Thứ nhất, cùng một từ có thể tồn tại dưới nhiều chuỗi byte khác nhau dù nhìn trên màn hình là giống hệt nhau. Thứ hai, có khoảng trắng nhưng khoảng trắng đó không phải ranh giới từ. Cả hai đều xảy ra trước khi dữ liệu chạm tới mô hình.

Bài viết này chia quy trình xử lý tiếng Việt thành bốn tầng — ký tự, từ, token và ngữ nghĩa. Mục đích của việc chia tầng là tách bạch triệu chứng nào thuộc về tầng nào, để quyết định được thứ tự sửa. Nếu sai thứ tự, phần lớn chi phí và thời gian sẽ bị hút vào tầng cuối cùng.

Xử lý tiếng Việt chia thành bốn tầng — ký tự, từ, token, ngữ nghĩa

Trước khi một tài liệu tiếng Việt đến được AI tạo sinh, nó đi qua bốn tầng. Theo thứ tự từ đầu nguồn xuống là tầng ký tự, tầng từ, tầng token và tầng ngữ nghĩa.

Bốn tầng này có vài khác biệt về tính chất khi đưa vào thực tế vận hành.

Càng ở đầu nguồn, làm một lần thì hiệu lực càng kéo dài. Chuẩn hóa ở tầng 1 chỉ cần đặt một lần ở cửa vào là sẽ tự động áp dụng cho cả những tài liệu phát sinh về sau. Ngược lại, phí sử dụng mô hình ở tầng 3 phát sinh liên tục theo mức dùng.

Càng ở đầu nguồn, phạm vi ảnh hưởng khi hỏng càng rộng. Tầng 1 hỏng thì tìm kiếm, tổng hợp và tóm tắt cùng lệch một lúc. Nếu chỉ tầng 4 yếu thì ảnh hưởng dừng lại ở chất lượng câu văn sinh ra.

Và càng ở đầu nguồn, triệu chứng càng trông giống lỗi của mô hình. Sai sót của tầng 1 và tầng 2 xuất hiện ở dạng “thỉnh thoảng”, nên nguyên nhân không được xác định và trách nhiệm bị đẩy xuống hạ nguồn.

Ở đây cần nắm trước điểm khác biệt khi áp dụng cùng mô hình bốn tầng này cho tiếng Thái. Với tiếng Thái, vấn đề là giữa các từ không có khoảng trắng, nên máy phải tự tạo ra ranh giới vốn không tồn tại. Tiếng Việt thì ngược lại. Khoảng trắng có sẵn, nhưng khoảng trắng đó là ranh giới âm tiết chứ không phải ranh giới từ. Chính tả tiếng Việt đặt khoảng trắng giữa các âm tiết chứ không phải giữa các từ, nên ngay cả khi nhiều âm tiết kết hợp lại tạo thành một từ, trên chuỗi ký tự chúng vẫn bị tách ra bởi khoảng trắng. Nghĩa là việc máy phải làm không phải “tạo ranh giới” mà là “xét trong các ranh giới đã có sẵn, cái nào là ranh giới từ và cái nào nằm bên trong một từ, rồi gom lại cho đúng”. Cách áp dụng cùng mô hình bốn tầng này cho tiếng Thái được trình bày trong bài Khi AI tạo sinh xử lý tiếng Thái không chính xác thì chỗ nào đang hỏng. Cấu trúc tầng là chung, nhưng nội dung công việc ở tầng 2 thì ngược chiều nhau.

Khác biệt này ảnh hưởng cả tới khâu triển khai. Với tiếng Thái, triệu chứng là “cắt quá nhiều hoặc cắt quá ít”. Với tiếng Việt, điểm khởi đầu của triệu chứng là việc lấy luôn khoảng trắng làm ranh giới từ. Xử lý cắt theo khoảng trắng chạy trót lọt trong mọi ngôn ngữ, nên không ai nghi ngờ chỗ đó. Đây là lý do lớn nhất khiến việc xác định nguyên nhân với tiếng Việt bị chậm.

Tầng 1 — tầng ký tự — nhìn giống nhau nhưng bên trong khác nhau

Ở tầng 1 chỉ có một việc duy nhất. Đưa các chuỗi ký tự cùng nghĩa về cùng một chuỗi byte.

Tiếng Việt được viết bằng chữ Latinh. Chính sự thật này sinh ra chủ quan, vì nó dẫn tới giả định rằng đã là chữ Latinh thì xử lý y như tiếng Anh là được. Nhưng chữ viết tiếng Việt có dấu phụ chỉ loại nguyên âm và dấu chỉ thanh điệu. Và các ký tự có dấu thì bên trong máy tính có nhiều cách biểu diễn.

Unicode có khái niệm dạng chuẩn hóa. NFC (dạng tổ hợp chuẩn tắc) thay chuỗi đã bị phân tách bằng ký tự tổ hợp sẵn được biểu diễn bởi một điểm mã duy nhất. NFD (dạng phân tách chuẩn tắc) thì ngược lại, tách ký tự tổ hợp sẵn thành ký tự cơ sở cộng với chuỗi các ký tự kết hợp. Ký tự tiếng Việt có dấu thanh, ở dạng NFD, sẽ được phân tách thành nhiều điểm mã.

Nghĩa là chuyện sau đây xảy ra hoàn toàn bình thường — cùng một từ hiển thị y hệt nhau trên màn hình, nhưng trong tài liệu này được lưu ở NFC còn trong tài liệu kia lưu ở NFD. Với mắt người, đó là cùng một chuỗi. Với máy tính, đó là hai chuỗi khác nhau.

Phần FAQ của VietUnicode giải thích sự khác biệt về dạng lưu trữ này thực tế gây ra chuyện gì. Tóm tắt lại — dấu phụ kết hợp có thể bị tách khỏi ký tự cơ sở ngoài ý muốn, và nếu một ký tự khác lọt nhầm vào khoảng trống đó thì chẳng hạn từ tháng sẽ hiển thị thành dạng như than´g. Cũng FAQ đó đề cập tới cách tính độ dài chuỗi. Một ký tự “ệ” ở dạng NFD được đếm thành hai đến ba điểm mã, còn ở NFC thì luôn được coi là một. Nghĩa là kết quả đếm số ký tự thay đổi theo dạng lưu trữ.

Tính chất “số ký tự thay đổi theo dạng lưu trữ” này ảnh hưởng âm thầm nhưng rõ trong vận hành. Giới hạn số ký tự của ô nhập liệu, việc canh cột của biểu mẫu, phép tính độ dài khi chia chunk — tất cả đều lấy số ký tự làm tiền đề, nên khi NFC và NFD lẫn lộn thì kết quả không đồng nhất.

Ngoài ra, tiếng Việt còn có sự khác biệt về vị trí đặt dấu thanh. Kiểu bỏ dấu cũ đặt dấu thanh ở vị trí gần trung tâm âm tiết, kiểu bỏ dấu mới đặt dấu thanh trên nguyên âm chính. hóa và hoá, hủy và huỷ. Đây là cùng một từ, nhưng xét như chuỗi ký tự thì là hai thứ khác nhau. Sách giáo khoa chính thức dùng kiểu bỏ dấu mới, trong khi văn viết hằng ngày được cho là có xu hướng chuộng kiểu bỏ dấu cũ. Nghĩa là trong tài liệu nội bộ sẽ có cả hai.

Ở hiện trường điều này trông như thế nào. Đối chiếu danh mục thiết bị với nhật ký sản xuất tiếng Việt thì ra kết quả “không tìm thấy”. Nhân viên phụ trách nhìn cả hai trên màn hình và thấy chuỗi ký tự giống hệt nhau. Thế là câu chuyện chuyển thành “chức năng tìm kiếm của hệ thống có vấn đề” và trôi sang bàn về cấu hình công cụ tìm kiếm hoặc bàn về mô hình. Trên thực tế, chuyện xảy ra chỉ là một bên được lưu ở NFD, hoặc vị trí dấu thanh khác nhau giữa kiểu bỏ dấu cũ và mới.

Cách sửa tầng 1, xét về mặt tính năng, khá là nhạt nhẽo. Gom cửa nạp dữ liệu về một mối, và bắt buộc mọi thứ đi qua chuẩn hóa tại đó. Cụ thể là thống nhất dạng chuẩn hóa Unicode về NFC, dồn cách đặt dấu thanh về một trong hai kiểu bỏ dấu, phát hiện và chuyển đổi những chuỗi đến từ bảng mã cũ, thống nhất chữ số và chữ cái về dạng nửa độ rộng cùng quy tắc viết hoa viết thường. Chỉ có vậy.

Điều quan trọng là đặt xử lý đó ở đâu. Nếu viết xử lý chuẩn hóa rải rác ở phía tìm kiếm, phía tổng hợp và phía tóm tắt, thì khi sửa một chỗ, các chỗ còn lại sẽ lệch. Cho chạy qua đúng một lần ở cửa vào, và thống nhất rằng từ đó xuống hạ nguồn chỉ xử lý chuỗi đã chuẩn hóa — cách này giúp vận hành về sau nhẹ hơn nhiều.

Tầng 1 đã ổn định hay chưa không kiểm tra bằng mắt mà kiểm tra bằng số. Đếm xem một từ lẽ ra phải giống nhau đang bị tách thành bao nhiêu biến thể chuỗi ký tự. Chừng nào con số này còn giảm thì công việc của tầng 1 vẫn còn.

Tầng 2 — tầng từ — có khoảng trắng, nhưng đó không phải ranh giới từ

Đây là tầng quan trọng nhất khi dùng AI tạo sinh với tiếng Việt.

Chính tả tiếng Việt đặt khoảng trắng giữa các âm tiết chứ không phải giữa các từ. Và có rất nhiều trường hợp nhiều âm tiết kết hợp lại tạo thành một từ. Ví dụ, từ “học sinh” gồm hai âm tiết và trên chuỗi ký tự được viết tách ra bằng khoảng trắng. Với người viết đó là một từ, nhưng khi máy cắt theo khoảng trắng thì thành hai đơn vị.

Nếu suy nghĩ theo cảm giác của tiếng Anh rằng “cứ cắt theo khoảng trắng là được”, đứt gãy đầu tiên sinh ra ngay tại đây. Xử lý cắt theo khoảng trắng không báo lỗi. Nó chạy trót lọt. Chỉ có điều kết quả cắt ra là âm tiết chứ không phải từ. Nếu ở trạng thái này mà đi tạo chỉ mục tìm kiếm, chia chunk, đối chiếu từ khóa và đánh giá độ chính xác, thì tất cả những việc đó sẽ vận hành trên “đơn vị âm tiết”.

Trong xử lý ngôn ngữ tự nhiên tiếng Việt, thao tác gom âm tiết trở lại thành từ được gọi là tách từ (word segmentation). Mọi hệ thống xử lý tiếng Việt, dù tường minh hay ngầm định, đều đang đưa ra phán đoán này ở đâu đó. Việc lấy luôn khoảng trắng làm ranh giới cũng là một phán đoán.

Vấn đề là số lượng xử lý phụ thuộc vào cách gom này không chỉ có một.

• Việc tạo chỉ mục tìm kiếm được dựng trên đơn vị là từ đã gom
• Việc chia chunk cho RAG lấy ranh giới từ và câu làm căn cứ để cắt
• Việc khớp từ khóa và tra từ điển đối chiếu từ đã gom với từ trong từ điển
• Việc đánh giá độ chính xác cũng so sánh với đáp án trên đơn vị đã gom

Nghĩa là cách gom thay đổi thì bốn thứ trên cùng thay đổi. Nói ngược lại, nếu cách gom kém thì bốn thứ cùng hỏng. Hơn nữa cách hỏng không đồng đều, nên triệu chứng hiện ra ở dạng “tìm kiếm lúc trúng lúc trượt”.

Tầm quan trọng của tầng này còn được xác nhận từ chính phía các mô hình được xây riêng cho tiếng Việt. Trong README của PhoBERT do VinAI Research công bố có lưu ý viết bằng chữ in hoa với ý rằng văn bản đầu vào bắt buộc phải được tách từ trước. Nguyên văn là “INPUT TEXT MUST BE ALREADY WORD-SEGMENTED!”. Dữ liệu tiền huấn luyện của PhoBERT là dữ liệu đã được chuẩn hóa thanh điệu và tách từ bằng RDRSegmenter của VnCoreNLP, và tài liệu khuyến nghị dùng cùng công cụ tách từ đó ở các tác vụ hạ nguồn.

Đây chính là điểm mấu chốt trong thực tế. Mô hình càng được xây riêng cho tiếng Việt thì càng lấy tiền xử lý làm tiền đề. Nếu đưa dữ liệu vào mà không qua tiền xử lý, mô hình sẽ không phát huy được năng lực vốn có của nó. Rồi nhìn kết quả không ra gì đó, người ta kết luận “mô hình này yếu với tiếng Việt”. Thứ đang bị đánh giá không phải mô hình, mà là khâu tiền xử lý của chính doanh nghiệp.

Trong tài liệu ở các cơ sở tại Việt Nam, chỗ dễ vỡ cách gom nhất là các danh từ riêng nội bộ. Tên thiết bị, tên linh kiện, mã viết tắt nội bộ, tên chuyền. Những từ này không có trong từ điển phổ thông. Từ không có trong từ điển sẽ hoặc bị để nguyên ở dạng các âm tiết rời, hoặc bị gom nhầm thành tổ hợp với một từ gần giống. Cách gom lại thay đổi theo ngữ cảnh trước sau, nên cùng một tên thiết bị bị tách thành các đơn vị khác nhau tùy tài liệu.

Ở hiện trường điều này trông như thế nào. Nhật ký sản xuất của cùng một thiết bị xuất hiện thành hai thiết bị trong bảng tổng hợp. Nhân viên phụ trách báo rằng “thiết bị chỉ có một máy mà bảng lại có hai dòng”, nhưng nguyên nhân không nằm ở danh mục thiết bị cũng không nằm ở khâu nhập liệu, mà ở chỗ tên thiết bị đã bị tách thành hai kiểu ngay tại thời điểm gom văn bản thành từ.

Cách sửa tầng 2 là xây từ điển danh từ riêng nội bộ rồi nạp cho bộ tách từ đọc. Việc này ít mang tính kỹ thuật mà giống công việc rà soát vốn từ cùng với nhân viên tại hiện trường hơn. Và vì mỗi lần có thêm thiết bị hoặc linh kiện lại phải bổ sung, nên nó không kết thúc sau một lần làm.

Cách dựng hệ thống tìm kiếm tri thức đa ngôn ngữ cũng được bàn trong bài Cách triển khai tìm kiếm tri thức nhà máy bằng RAG. Khi thiết kế tìm kiếm có bao gồm tiếng Việt, quyết định trước xem sẽ đảm bảo tầng 2 ở đâu sẽ giảm được việc phải làm lại. Hãy đưa vào ngay từ đầu bước kiểm tra xem phía câu hỏi và phía tài liệu có đang đi qua hai xử lý khác nhau hay không.

Đọc con số về độ chính xác tách từ như thế nào — vì sao số liệu đổi khác giữa benchmark và dữ liệu thực

Tách từ tiếng Việt có các benchmark đã công bố. Nếu chỉ nhìn con số, vấn đề này trông như đã được giải quyết xong. Trên thực tế có những lý do khiến không thể đọc như vậy.

Trước hết là benchmark chính thức. Trên tập kiểm tra của VLSP 2013 (2120 câu), RDRsegmenter — mô-đun tách từ của VnCoreNLP — đạt F1 97.90%. Mức cao nhất hiện nay trên cùng benchmark đó là F1 98.06% của UITws-v1. Nếu chỉ nhìn những con số này thì rất dễ đi tới kết luận rằng tách từ tiếng Việt về cơ bản đã được giải quyết cho mục đích thực dụng.

Mặt khác, ở một benchmark khác lại xuất hiện những con số khác hẳn. Trong một so sánh độc lập sử dụng Vietnamese Universal Dependencies Treebank (hơn 800 câu), kết quả được báo cáo là underthesea đạt 80.04%, VnCoreNLP đạt 78.37% và PyVi đạt 57.88%.

Ở đây cần đặt trước một lưu ý quan trọng nhất. Hai nhóm con số này dùng dữ liệu đánh giá khác nhau, nên không thể đọc như một phép so sánh cùng điều kiện. Đặt 97.90% cạnh 78.37% rồi nói “trên dữ liệu thực thì tụt 20 điểm” là sai. Tập kiểm tra khác nhau thì độ dài câu, phân bố từ vựng và cả định nghĩa đáp án đều khác nhau. Đây không phải con số cho thấy hiệu năng của cùng một công cụ bị giảm xuống.

Dù vậy, việc đặt hai nhóm con số này cạnh nhau vẫn có giá trị. Vì từ đó đọc ra được một sự thật — độ chính xác của tách từ thay đổi rất nhiều tùy theo dữ liệu đánh giá. Và chính sự thật này mới là điều cần nắm khi làm thực tế.

Để tránh đọc sai, cần sắp xếp lại ba điểm.

Thứ nhất. Con số cao trên benchmark chính thức thể hiện giới hạn trên của công cụ, chứ không phải hiệu năng trên tài liệu của doanh nghiệp bạn. Tập kiểm tra của benchmark được xây từ văn bản phổ thông. Phân bố từ vựng của nó khác với vốn từ xuất hiện trong nhật ký sản xuất và hồ sơ kiểm tra của nhà máy.

Thứ hai. Lỗi không phân bố đều. Những từ phổ thông có trong từ điển hoặc trong dữ liệu huấn luyện được gom rất tốt, còn những từ không có thì vỡ. Mà những từ quan trọng xuất hiện trong tài liệu nội bộ thì thường lại nằm trong nhóm không có. Tên thiết bị, tên linh kiện, mã viết tắt, tên công ty. Nghĩa là cấu trúc vấn đề là chính những từ mà bạn muốn bắt trúng nhất trong tài liệu của mình lại dễ trượt nhất nếu để nguyên cấu hình mặc định. Đây là lý do không thể lấy thẳng con số của benchmark công khai làm độ chính xác của hệ thống nội bộ.

Thứ ba. Chọn công cụ nào không quan trọng bằng việc có từ điển nào. Các con số ở trên là so sánh giữa các công cụ với nhau, nhưng chênh lệch trên tài liệu nội bộ chịu ảnh hưởng của việc có hay không có từ điển danh từ riêng nhiều hơn là ảnh hưởng của việc chọn công cụ. Thay vì dành thời gian chọn công cụ, hãy xây từ điển trước.

Kết luận cho thực tế thì đơn giản. Dùng nguyên bộ tách từ mặc định thì sẽ trượt ở chỗ vốn từ riêng của doanh nghiệp. Vì vậy phải bổ sung từ điển. Và hiệu quả của phần bổ sung đó phải được đo trên chính tài liệu của doanh nghiệp. Đó là nội dung công việc của tầng 2.

Tầng 3 — tầng token — mức tương thích giữa bộ tách token đa dụng và tiếng Việt

Tầng 3 là tầng chia văn bản thành đơn vị mà mô hình đếm được. Tầng này ảnh hưởng tới chi phí và lượng nội dung nhét được vào nhiều hơn là ảnh hưởng tới độ chính xác.

Bộ tách token mà các mô hình ngôn ngữ lớn đa dụng đang dùng được xây theo phân bố của dữ liệu huấn luyện. Bộ tách token được xây từ dữ liệu mà tiếng Anh chiếm phần lớn sẽ chuyển tiếng Anh thành chuỗi token ngắn một cách hiệu quả. Ngược lại, với các ngôn ngữ khác, một từ dễ bị phân tách thành nhiều token. Văn bản tiếng Việt dùng nhiều ký tự có dấu thanh, nên bộ tách token đa dụng dễ bị ảnh hưởng này khi gặp tiếng Việt.

Về con số cụ thể, có báo cáo rằng bộ tách token BPE mức byte của GPT-4 cần số token gấp 2.5 lần cho tiếng Việt so với tiếng Anh. Tuy nhiên con số này cần một ghi chú về đường dẫn trích dẫn. Con số 2.5 lần này là kết quả phân tích trong bài báo NeurIPS năm 2023 của Petrov và cộng sự (Language Model Tokenizers Introduce Unfairness Between Languages), được ghi lại bởi một bài báo về sau trích dẫn công trình đó (arXiv 2606.15044). Bài viết này không được viết dựa trên việc trực tiếp kiểm chứng bảng số liệu trong chính bài báo của Petrov và cộng sự. Khi trích dẫn, hãy truyền đạt kèm cả đường dẫn trích dẫn này.

Thêm một điểm nữa cần tránh nhầm lẫn. Con số 2.5 lần này là “tỷ lệ khi so sánh tiếng Việt với tiếng Anh trên cùng một bộ tách token GPT đa dụng”. Còn tỷ lệ được nêu trong bài về tiếng Thái là “chênh lệch hiệu suất khi xử lý cùng một tài liệu tiếng Thái bằng bộ tách token đa dụng so với bằng bộ tách token chuyên cho tiếng Thái” — trục so sánh hoàn toàn khác nhau. Không được đặt phép so sánh giữa các ngôn ngữ và phép so sánh giữa các bộ tách token vào cùng một bảng. Ngay khi đặt cạnh nhau, cả hai con số đều mất ý nghĩa.

Chênh lệch này phát huy tác dụng trong thực tế ở hai tình huống.

Hóa đơn. Với các mô hình tính phí theo mức sử dụng, số token đi thẳng vào số tiền. Ở những mục đích sử dụng có khối lượng tài liệu lớn — chẳng hạn cho đọc hồ sơ kiểm tra của vài năm mỗi ngày — tỷ lệ này trở thành chênh lệch chi phí vận hành.

Lượng nội dung nhét được vào ngữ cảnh. Trong cùng một khung độ dài ngữ cảnh, số trang tài liệu tiếng Việt nhét vào được sẽ thay đổi. Trong RAG, tài liệu lấy được từ khâu tìm kiếm sẽ được đưa cho mô hình. Hiệu suất token kém thì số tài liệu đưa vào được giảm đi. Số tài liệu đưa vào giảm thì căn cứ của câu trả lời mỏng đi. Qua con đường này, tầng 3 chạm gián tiếp tới cả độ chính xác.

Tuy nhiên tầng 3 là hệ số nhân, không phải nguyên nhân. Nếu tầng 2 đang hỏng khiến tìm kiếm không lấy được đúng tài liệu, thì có nhét tài liệu sai vào một cách hiệu quả hơn cũng không làm câu trả lời tốt lên. Xét về thứ tự, coi việc chọn bộ tách token là bước tối ưu sau khi đầu nguồn đã ổn định là hợp lý hơn.

Tầng 4 — tầng ngữ nghĩa — đến đây mới bắt đầu chọn mô hình

Tầng 4 là tầng quyết định diễn giải chuỗi ký tự nhận được như thế nào và sinh ra nội dung như thế nào. Các triệu chứng thuộc về tầng này là những thứ sau.

• Bản dịch cứng, mang giọng dịch sát từng chữ, không giống cách diễn đạt quen dùng trong nội bộ
• Không tuân thủ chỉ dẫn. Chỉ định định dạng cũng không giữ đúng
• Viết ra nội dung không có trong nguồn
• Cách xưng hô và mức độ lịch sự không nhất quán. Cách diễn đạt lệch so với đối tượng và bối cảnh

Có một cách để phân biệt đây có phải vấn đề của tầng 4 hay không. Nếu người chỉnh tay đầu vào rồi đưa lại cùng nội dung đó mà hết lỗi, thì đó là vấn đề của đầu nguồn. Nếu người chọn lại các tài liệu mà khâu tìm kiếm lấy về rồi hệ thống trả lời đúng, thì cái sai nằm ở phía tìm kiếm của tầng 2. Nếu người sửa chênh lệch cách viết hoặc sửa lệch dạng chuẩn hóa rồi mọi thứ chạy thông, thì đó là tầng 1. Nếu đầu vào đã được người chỉnh sạch mà vẫn vỡ y như cũ, thì đến lúc đó mới đến chuyện của tầng 4.

Nếu so sánh mô hình mà chưa làm bước phân biệt này trước, kết luận của phép so sánh sẽ không đáng tin. Vì khi đầu nguồn còn dao động mà đem so hai mô hình, không thể phân biệt được chênh lệch đến từ khác biệt giữa các mô hình hay đến từ khác biệt của những tài liệu tình cờ lấy được.

Với tiếng Việt, bước phân biệt này cần thêm một mức thận trọng nữa. Như đã thấy ở phần trước, trong số các mô hình được xây riêng cho tiếng Việt có những mô hình lấy đầu vào đã tách từ làm tiền đề. Nếu so sánh mà không qua tiền xử lý, có khi mô hình không đặt tiền xử lý làm tiền đề lại cho con số tốt hơn. Đó không phải chênh lệch về năng lực của mô hình mà là chênh lệch về việc có hay không có tiền xử lý. Cho tất cả các mô hình đem so đi qua cùng một tiền xử lý, và đọc trước điều kiện tiền xử lý mà từng mô hình yêu cầu. Phép so sánh không giữ hai điều này sẽ cho kết luận ngược.

Căn cứ để phán đoán ở tầng 4 là số đo thực tế trên bộ đánh giá của chính doanh nghiệp. Thứ hạng trên benchmark công khai có thể dùng làm căn cứ để lọc bớt ứng viên, nhưng có trường hợp nó không trùng với thứ hạng trên tài liệu và tác vụ thực tế của doanh nghiệp.

Hiện trạng các mô hình mạnh về tiếng Việt — PhoGPT, Viettel, SEA-LION

Dưới đây là phần sắp xếp lại những gì xác nhận được về nhóm mô hình đang đầu tư cho tiếng Việt. Những gì chưa xác nhận được thì sẽ ghi rõ là chưa xác nhận được.

Có vài điểm cần bổ sung.

Số tham số của PhoGPT khác với tên gọi. Tên gọi là PhoGPT-4B, nhưng con số mà bài báo ghi là 3.7 tỷ tham số. Nếu trong tài liệu so sánh nội bộ chỉ ghi “4B” thì phép so quy mô với các mô hình khác sẽ lệch đi một chút. Trông có vẻ là chuyện vụn vặt, nhưng nó phát huy tác dụng khi đặt cạnh nhau các ước tính về quy mô và chi phí. Kích thước từ vựng 20480 và độ dài ngữ cảnh 8192 cũng là các tiền đề khi đặt cạnh các mô hình khác.

Lưu ý rằng thông tin về công bố của Viettel là dựa trên tin báo chí. Thông tin về việc một mô hình 120 tỷ tham số được công bố vào ngày 4 tháng 6 năm 2026 là theo tin của truyền thông Việt Nam. Đây không phải thông tin đã xác nhận trong tài liệu kỹ thuật của chính Viettel. Do đó bài viết này không nêu bất cứ điều gì về hiệu năng hay thứ hạng benchmark của mô hình này. Với những điều vượt quá sự thật “đã được công bố”, hãy chờ nguồn sơ cấp xuất hiện rồi mới phán đoán.

Thứ hạng của SEA-LION là do chính đơn vị cung cấp tự công bố. Ghi nhận về việc xếp thứ 5 trong 55 mô hình trên SEA-HELM và đứng thứ 1 trong nhóm mô hình mở dưới 200 tỷ tham số là do chính AI Singapore đưa ra. Đây là cấu trúc trong đó bên cung cấp benchmark công bố thứ hạng của mô hình do chính mình làm, nên hãy tránh đưa thẳng nó vào tài liệu nội bộ như một “đánh giá khách quan”. Cách dùng an toàn là tham chiếu nó ở cửa vào để lọc bớt ứng viên, còn phán đoán cuối cùng thì dựa trên bộ đánh giá của doanh nghiệp.

Số lượng đối tượng được SEA-HELM đánh giá cho thấy độ rộng của tập lựa chọn. Tại thời điểm ngày 5 tháng 8 năm 2026 đã có 61 mô hình trọng số mở và 9 mô hình trọng số đóng được đánh giá. Nghĩa là số ứng viên xử lý được tiếng Việt đã nhiều tới mức phải sàng lọc. Nói ngược lại, nếu bắt đầu so sánh mà chưa có tiêu chí sàng lọc thì sẽ không bao giờ kết thúc.

Thứ cần quyết trước khi chọn mô hình không phải thứ hạng mà là các ràng buộc. Tài liệu có được phép ra khỏi doanh nghiệp không. Có cần đặt mô hình trong hạ tầng của chính doanh nghiệp không. Yêu cầu về tốc độ phản hồi ra sao. Có cần xử lý cả tiếng Nhật và tiếng Anh trong cùng một khung với tiếng Việt không. Khi những điều này được chốt, số ứng viên sẽ rút xuống còn vài mô hình. Từ đó trở đi là đo thực tế trên bộ đánh giá.

Theo từng mục đích sử dụng, sửa tầng nào thì hiệu quả

Đây là phần trung tâm của bài viết. Cùng là “AI tạo sinh xử lý tiếng Việt không chính xác”, nhưng tầng chi phối lại khác nhau theo mục đích sử dụng. Nếu động vào mà trượt tầng chi phối thì kết quả sẽ là bỏ tiền ra mà triệu chứng không đổi.

Dưới đây là phần xem chi tiết từng mục đích trong sáu mục đích trên.

Tìm kiếm tài liệu nội bộ (RAG) — tầng 2 chi phối

RAG là cơ chế lấy về các tài liệu liên quan tới câu hỏi bằng tìm kiếm, rồi đưa tài liệu đó cho mô hình để nó trả lời. Với cấu trúc này, mô hình không làm được gì với tài liệu mà khâu tìm kiếm bỏ sót. Tài liệu không lấy được thì cũng như không tồn tại.

Phần lớn nguyên nhân khiến tìm kiếm không trúng trong RAG tiếng Việt nằm ở tầng 2. Cách gom từ ở câu hỏi và cách gom từ ở phía tài liệu không khớp nhau. Đặc biệt khi danh từ riêng nội bộ bị tách thành các đơn vị khác nhau ở hai phía, từ khóa lẽ ra phải khớp lại không khớp.

Ở đây cần xác nhận lại một lần nữa điểm khác biệt với tiếng Thái. Với tiếng Thái, máy phải tạo ranh giới ở chỗ không có ranh giới. Với tiếng Việt, thứ đã được tách sẵn bằng khoảng trắng phải được gom lại theo tiêu chí đến đâu thì hết một từ. Vì chiều của công việc ngược nhau, đem nguyên thiết kế đã dùng cho tiếng Thái sang đây thì sẽ không ăn khớp. Đặc biệt, xử lý mặc định “cắt theo khoảng trắng” với tiếng Việt sẽ chạy trót lọt mà không báo bất cứ lỗi nào, hơn nữa kết quả lại ở đơn vị âm tiết. Vì không có lỗi nào phát ra nên việc phát hiện còn chậm hơn cả tiếng Thái.

Tầng có hiệu quả rõ là tầng 1 và tầng 2. Đưa ký tự về cùng dạng, gom âm tiết thành từ. Sửa chỗ này thì những tài liệu trước đây không trúng sẽ bắt đầu trúng. Tầng 3 ảnh hưởng tới “lượng tài liệu đưa vào được”, nên nó làm dày thêm phần căn cứ.

Tầng hầu như không hiệu quả là việc đổi mô hình ở tầng 4. Đổi mô hình thì kết quả tìm kiếm không đổi. Chỉ có cách diễn đạt của câu trả lời thay đổi, còn triệu chứng “không tìm thấy tài liệu đó” vẫn còn nguyên.

Tầng nên động vào trước tiên là tầng 2. Xây từ điển danh từ riêng nội bộ, và cho phía câu hỏi lẫn phía tài liệu đi qua cùng một bộ tách từ. Chỉ vậy thôi là tỷ lệ trúng đã khác.

Chatbot — tầng 2 để bắt, tầng 4 để trả lời

Bot hỏi đáp nội bộ nằm vắt qua hai tầng cùng lúc. Nửa đầu là xử lý bắt xem “đang được hỏi cái gì”, phần này chịu ảnh hưởng của tầng 2. Nửa sau là “trả lời như thế nào”, phần này thuộc tầng 4.

Triệu chứng hay gặp ở chatbot tiếng Việt là cùng một câu hỏi nhưng diễn đạt theo cách khác thì bot không bắt được. Câu hỏi thường ngắn hơn nhật ký sản xuất, mang tính khẩu ngữ, và có lẫn cả chênh lệch trong việc nhập dấu thanh. Câu càng ngắn thì sai sót ở cách gom từ càng đi thẳng vào kết quả. Thêm nữa, khi nhập từ điện thoại, câu hỏi có thể được gửi đi ở dạng đã rơi mất dấu thanh, nên cần quyết định trước phạm vi hấp thụ của tầng 1.

Tầng có hiệu quả rõ là tầng 2 và tầng 4. Ở tầng 2 thì giữ từ điển vốn từ của các câu hỏi, ở tầng 4 thì chỉnh khuôn mẫu cách trả lời. Tầng hầu như không hiệu quả là tầng 3, vì mỗi lượt chỉ có câu ngắn nên chênh lệch bộ tách token không tác động đáng kể tới cả số tiền lẫn độ dài ngữ cảnh. Tầng nên động vào trước tiên là tầng 2, mà cụ thể là thu thập vốn từ từ chính những câu hỏi thực tế đã đến.

Phần sắp xếp về chatbot đa ngôn ngữ trên phương diện chi phí và quy trình được tổng hợp trong bài Chi phí và cách triển khai chatbot đa ngôn ngữ trong nội bộ. Vì tầng cần đảm bảo khác nhau theo từng ngôn ngữ, đưa điểm đó vào thiết kế ngay từ đầu sẽ giúp vận hành ổn định hơn.

Biên bản họp và chuyển giọng nói thành văn bản — tầng 1 và tầng 4

Ở mục đích chuyển nội dung cuộc họp tiếng Việt thành văn bản, trước hết văn bản được tạo ra từ âm thanh, sau đó mới chồng thêm phần tóm tắt và trích xuất các quyết định.

Tầng có hiệu quả rõ là tầng 1 và tầng 4. Ngay sau khi chuyển thành văn bản, ta có một khối văn bản với cách viết không đồng nhất. Tên người, tên thiết bị, tên công ty xuất hiện với nhiều cách viết khác nhau trong cùng một cuộc họp. Với tiếng Việt, nguồn phát sinh chênh lệch chủ yếu là việc có hay không có dấu thanh và vị trí đặt dấu thanh. Nếu không đưa chỗ này về cùng dạng ở tầng 1, thì ở khâu tóm tắt phía sau, cùng một người có thể bị coi là hai người, hoặc các quyết định bị liệt kê thành những mục riêng biệt. Tầng 4 ảnh hưởng tới việc phân biệt người nói và chất lượng tóm tắt.

Tầng hầu như không hiệu quả là tầng 3. Tuy nhiên với tầng 2 thì chưa thể nói tới mức “không hiệu quả”. Nếu vận hành theo hướng sau này sẽ tìm kiếm trong biên bản họp, thì đúng thời điểm đó tầng 2 bắt đầu có tác dụng. Hiểu theo thứ tự rằng riêng khâu chuyển giọng nói thành văn bản thì ảnh hưởng của tầng 2 là nhỏ, và nó phát huy tác dụng ngay khi chồng thêm tìm kiếm hoặc tổng hợp, sẽ giúp tránh phán đoán sai.

Tầng nên động vào trước tiên là tầng 1, cụ thể là thống nhất cách bỏ dấu thanh cho tên người và tên thiết bị xuất hiện trong cuộc họp.

OCR biểu mẫu — tầng 1 chi phối

Phiếu giao hàng, biên bản kết quả kiểm tra, phiếu chỉ thị công việc. Đây là mục đích lấy dữ liệu từ giấy hoặc PDF. Có thể nói đây là lĩnh vực mà tầng 1 chiếm gần như toàn bộ.

Văn bản ngay sau khi đọc ra sẽ có NFC và NFD lẫn lộn, vị trí dấu thanh dao động giữa kiểu bỏ dấu cũ và mới, và với những chuỗi đến từ định dạng cũ thì còn lẫn cả lỗi hiển thị ký tự do bảng mã cũ. Nếu đưa dữ liệu ở trạng thái này vào hệ thống lõi, sẽ xuất hiện hàng loạt trục trặc như số lô không khớp, tên đối tác được đăng ký thành một công ty khác.

Tầng có hiệu quả rõ là tầng 1. Thống nhất dạng chuẩn hóa, thống nhất cách bỏ dấu thanh, phát hiện và chuyển đổi bảng mã cũ. Ngoài ra, độ chính xác của bản thân việc đọc ra là chuyện phía mô hình ở tầng 4, và phán đoán có dùng mô hình xử lý được OCR hay không cũng nằm ở đây.

Tầng hầu như không hiệu quả là tầng 2. Giá trị của các mục trên biểu mẫu phần lớn vốn không cần gom thành từ. Tách từ cho mã sản phẩm hay số lượng thì cũng không được gì. Chỉ khi dùng phép khớp từ để đối chiếu tên mục thì tầng 2 mới liên quan một phần.

Tầng nên động vào trước tiên là tầng 1, cụ thể là thống nhất NFC và hấp thụ chênh lệch vị trí dấu thanh. Hai việc này có triệu chứng dễ nhận biết và cách xử lý có thể chuẩn hóa thành khuôn mẫu, nên đáng được đặt lên trước trong thứ tự bắt tay vào làm.

Dịch thuật — tầng 4 chi phối

Dịch từ tiếng Nhật sang tiếng Việt và từ tiếng Việt sang tiếng Nhật là mục đích nghiêng về tầng 4 nhất trong sáu mục đích nêu ở đây. Độ tự nhiên của bản dịch, tính nhất quán của thuật ngữ, cách xưng hô và mức độ lịch sự. Những thứ này do chất lượng diễn giải và sinh nội dung của mô hình quyết định.

Tầng có hiệu quả rõ là tầng 4. Cấp cho mô hình bảng thuật ngữ, đổi chỉ dẫn theo từng loại tài liệu, so sánh các mô hình. Tầng 1 cũng có hiệu quả, nhưng vai trò của nó là làm sạch đầu vào. Nếu đưa vào khi các dạng chuẩn hóa còn lẫn lộn thì cách xử lý ở phía mô hình sẽ không ổn định.

Tầng hầu như không hiệu quả là tầng 2. Ở dịch thuật, ta đưa vào nguyên cả câu, nên về cơ bản không cần chèn thêm bộ tách từ tự dựng. Đổ công sức vào đây cũng không làm bản dịch tốt lên. Tuy nhiên có ngoại lệ khi dùng mô hình lấy đầu vào đã tách từ làm tiền đề. Hãy đọc trước yêu cầu của mô hình mà bạn định dùng.

Tầng nên động vào trước tiên là tầng 4, cụ thể là sắp xếp bảng thuật ngữ và phân loại loại tài liệu. Nếu dịch hợp đồng, quy trình thao tác và thông báo nội bộ bằng cùng một cấu hình, thì chắc chắn sẽ có một loại bị lệch giọng.

Phân loại và tổng hợp — tầng 1 và tầng 2

Đây là mục đích tổng hợp nhật ký sản xuất và báo cáo lỗi tiếng Việt theo từng hạng mục. Kết quả ở đây do sự phối hợp của tầng 1 và tầng 2 quyết định.

Kết quả tổng hợp thay đổi theo việc các từ dùng làm khóa có khớp nhau hay không. Nếu tên thiết bị bị tách thành hai chuỗi ký tự thì bảng tổng hợp tách thành hai dòng, và nếu cách gom từ không ổn định thì cùng một lỗi rơi vào các hạng mục khác nhau. Tầng có hiệu quả rõ là tầng 1 và tầng 2. Với tiếng Việt, việc tách ở tầng 1 xảy ra trên hai trục là “NFC so với NFD” và “kiểu bỏ dấu mới so với kiểu bỏ dấu cũ”, nên cùng một từ có khi bị tách thành từ ba biến thể trở lên.

Tầng hầu như không hiệu quả là tầng 4. Đổi mô hình cũng không thay đổi được sự thật rằng ngay từ khâu đầu vào, cùng một thiết bị đã bị tách làm hai. Ngay cả với thiết kế giao chính việc phán đoán phân loại cho mô hình, mô hình cũng không hấp thụ giúp chênh lệch ở đầu vào.

Tầng nên động vào trước tiên là tầng 1, cụ thể là thống nhất NFC cho các từ dùng làm khóa tổng hợp. Tên thiết bị, tên chuyền, chủng loại lỗi. Chỉ cần đưa ba nhóm này về cùng dạng là kết quả tổng hợp đã sát với cảm nhận của hiện trường hơn.

Có một điều đúng xuyên suốt các mục đích sử dụng. Nhìn cột “tầng nên động vào trước tiên” trong bảng sẽ thấy mục đích duy nhất nên đặt việc chọn mô hình ở nước đi đầu tiên là dịch thuật, còn 5 mục đích còn lại đều bắt đầu từ tầng 1 hoặc tầng 2. Chatbot và biên bản họp có tầng 4 chạy song song, nhưng thứ được động vào trước vẫn là đầu nguồn. Nước đi đầu tiên “cứ đổi mô hình trước đã” là sai thứ tự ở 5 trong 6 mục đích.

Năm cái bẫy đặc thù khi xử lý tiếng Việt

Phần này chuyển các thảo luận về tầng ở trên thành các triệu chứng cụ thể. Trong tài liệu ở các cơ sở tại Việt Nam, năm chỗ sau đây dễ vấp nhất.

Chênh lệch vị trí dấu thanh — cùng một từ tồn tại ở hai cách viết

Dấu thanh tiếng Việt có hai quy ước về vị trí đặt. Kiểu bỏ dấu cũ đặt dấu thanh ở vị trí gần trung tâm âm tiết, kiểu bỏ dấu mới đặt dấu thanh trên nguyên âm chính. hóa và hoá, hủy và huỷ. Cùng một từ, nhưng xét như chuỗi ký tự thì là hai thứ khác nhau. Sách giáo khoa chính thức dùng kiểu bỏ dấu mới, trong khi văn viết hằng ngày được cho là có xu hướng chuộng kiểu bỏ dấu cũ.

Ở hiện trường điều này trông như thế nào. Tìm kiếm khớp chính xác không cho kết quả. Cơ chế phát hiện trùng lặp không hoạt động và cùng một mặt hàng được đăng ký thành hai bản ghi. Trong bảng tổng hợp từ khóa, cùng một từ hiện ra ở hai dòng khác nhau. Vì nhân viên phụ trách nhìn thấy cùng một từ trên màn hình, họ sẽ báo cáo đây là lỗi hệ thống.

Thuộc tầng nào. Tầng 1. Quyết một quy tắc dồn về một trong hai cách viết, rồi chuyển đổi ngay tại cửa vào. Về việc dồn về bên nào, thực tế nhất là theo cách viết chiếm đa số trong dữ liệu đang có sẵn trong hệ thống hiện hữu.

Không khớp dạng chuẩn hóa Unicode — nhìn giống nhau nhưng bên trong khác nhau

Đây là khác biệt giữa NFC và NFD. Được lưu ở dạng ký tự tổ hợp sẵn với một điểm mã duy nhất, hay được lưu ở dạng đã phân tách thành ký tự cơ sở cộng chuỗi ký tự kết hợp. Ký tự tiếng Việt có dấu thanh, ở dạng NFD, sẽ được phân tách thành nhiều điểm mã.

Ở hiện trường điều này trông như thế nào. Từ gõ tay vào ô tìm kiếm thì không ra kết quả, nhưng sao chép từ trong tài liệu rồi dán vào thì lại ra. Hoặc ngược lại. Việc đếm số ký tự cũng dao động. Đúng như FAQ của VietUnicode nêu, “ệ” ở dạng NFD được đếm thành hai đến ba điểm mã, còn ở NFC thì luôn là một. Giới hạn số ký tự của ô nhập liệu và việc canh cột của biểu mẫu cho ra kết quả khác nhau tùy theo dạng lưu trữ.

Thuộc tầng nào. Tầng 1. Thống nhất về NFC ngay tại cửa vào. Về mặt kỹ thuật, chọn NFC hay NFD làm đích đều được, nhưng điểm mấu chốt là chốt một bên rồi giữ đúng trên mọi đường dẫn dữ liệu. Vấn đề nằm ở chỗ chưa chốt, chứ không nằm ở chỗ chọn bên nào.

Lỗi tổ hợp của bộ gõ — ký tự bị tách rời ngay giữa lúc nhập

Việc nhập tiếng Việt dùng các kiểu gõ như Telex hoặc VNI. Các kiểu gõ này được cho là có thể xuất ra cả văn bản đã tổ hợp sẵn (NFC) lẫn văn bản đã phân tách (NFD) từ cùng một chuỗi phím gõ. Cái nào được xuất ra thì tùy phần mềm.

Hơn nữa, nếu phía ứng dụng không xử lý đúng việc gộp ký tự kết hợp thành một ký tự thì hiển thị sẽ vỡ. Trong năm 2026 đã có báo cáo về lỗi ở một công cụ đang được dùng thực tế, trong đó gõ “ư” thì ký tự bị tách rời và lặp lại thành dạng như “u ư”. Đây là trường hợp xảy ra ở một công cụ dòng lệnh dành cho lập trình viên, nhưng nguyên nhân nằm ở việc phía ứng dụng không xử lý đúng cơ chế tổ hợp của bộ gõ, và vấn đề cùng cấu trúc như vậy hoàn toàn có thể xảy ra ở ô nhập liệu của hệ thống nghiệp vụ.

Ở hiện trường điều này trông như thế nào. Nhân viên tại hiện trường báo lên rằng “chỉ riêng màn hình này là chữ bị lỗi”. Vì các màn hình khác vẫn bình thường nên nó không được xử lý như vấn đề của cả hệ thống, mà dễ bị bỏ mặc như vấn đề riêng của máy cá nhân. Nếu dữ liệu nhập ở trạng thái đó cứ tích lũy lại, số bản ghi mà sau này tìm kiếm cũng không trúng, tổng hợp cũng không trúng sẽ tăng lên.

Thuộc tầng nào. Tầng 1. Tuy nhiên chỉ chuẩn hóa ở cửa vào thôi thì chưa đủ, cần thêm một bước kiểm tra hành vi của chính ô nhập liệu trên thiết bị thật. Trên đúng thiết bị và trình duyệt mà nhân viên tại hiện trường thực sự dùng, hãy gõ tay một từ có dấu thanh rồi lưu lại và kiểm tra chuỗi byte đã được lưu. Hãy đưa bước kiểm tra này vào danh mục kiểm tra khi triển khai.

Lỗi hiển thị ký tự do bảng mã cũ — xuất hiện khi nạp tài liệu quá khứ

Tiếng Việt có các bảng mã 8 bit được dùng từ trước thời Unicode. TCVN3, VNI, VSCII. Đây là các phương thức gán riêng các ký tự có dấu thanh vào những phím ASCII tiêu chuẩn, nên trong môi trường không có phông chữ chuyên dụng thì sẽ gây lỗi hiển thị ký tự. Các trình duyệt lớn đã ngừng hỗ trợ các bảng mã 8 bit này, trừ Windows-1258, vào năm 2014.

Ở hiện trường điều này trông như thế nào. Tài liệu tiêu chuẩn thao tác cũ, hồ sơ kiểm tra trong quá khứ, tệp CSV xuất ra từ hệ thống lõi đã chạy nhiều năm. Khi nạp những dữ liệu này vào hệ thống hiện hành, riêng phần tiếng Việt trở thành một chuỗi ký hiệu vô nghĩa. Hoặc nó xuất hiện ở dạng thoạt nhìn vẫn đọc được nhưng tìm kiếm thì hoàn toàn không trúng. Dạng sau mới là dạng khó xử lý. Không ai nhận ra đó là lỗi hiển thị ký tự, và dữ liệu đó cứ tiếp tục nằm trong phạm vi tìm kiếm.

Thuộc tầng nào. Tầng 1. Trước khi nạp, hãy chèn thêm một bước xác định bảng mã của dữ liệu gốc rồi chuyển đổi. Việc xác định có thể tự động hóa, nhưng kết quả chuyển đổi cần được nhân viên tại hiện trường kiểm tra bằng mắt. Vì với chuyển đổi máy móc, khi diễn giải nhầm sang một bảng mã khác thì có thể tạo ra một chuỗi ký tự khác mà vẫn trông như đọc được.

Chưa xử lý ranh giới giữa âm tiết và từ — lấy luôn khoảng trắng làm ranh giới

Cái thứ năm chính là vấn đề nằm ở trung tâm bài viết này. Nếu dựng tìm kiếm, chia chunk và khớp từ khóa mà không tách từ, thì một từ gồm nhiều âm tiết sẽ bị xử lý như những đơn vị riêng biệt.

Ở hiện trường điều này trông như thế nào. Tìm kiếm “thỉnh thoảng” trượt. Chỉ một trong hai âm tiết của một từ hai âm tiết khớp, khiến những tài liệu không liên quan nhảy lên đầu. Trong bảng tổng hợp, một hạng mục lẽ ra là một lại bị tách thành nhiều. Và điều khó xử lý nhất là xử lý này hoàn toàn không phát ra bất cứ lỗi nào. Việc cắt theo khoảng trắng kết thúc bình thường. Log cũng không lưu lại gì. Vì trông như đang chạy tốt, nó không bao giờ được đưa vào danh sách nghi vấn về nguyên nhân.

Thuộc tầng nào. Tầng 2. Đặt xử lý tách từ một cách tường minh, và cho phía câu hỏi lẫn phía tài liệu đi qua cùng một xử lý đó. Rồi cấp cho nó từ điển danh từ riêng nội bộ. Viết ba điểm này vào thiết kế sẽ phát huy tác dụng về sau.

Xây dữ liệu đánh giá cho tiếng Việt — quy trình ngắn nhất để nói được về “độ chính xác”

Toàn bộ những gì nói tới đây đều lấy việc “đo được” làm tiền đề. Nếu sửa tầng mà không đo được, thì không biết đã sửa xong hay chưa.

Quy trình xây dữ liệu đánh giá cho tiếng Việt như sau.

• Thu hẹp về đúng một tác vụ mục tiêu. Tìm kiếm thì chỉ tìm kiếm, dịch thì chỉ dịch. Nếu cố đo nhiều tác vụ bằng một bộ đánh giá thì sẽ không đọc ra được cải thiện ở tầng nào đã có tác dụng
• Lấy mẫu từ chính tài liệu nội bộ thực tế. Không dùng câu ví dụ tự soạn. Câu ví dụ soạn mới sẽ được viết ở dạng NFC theo kiểu bỏ dấu mới, nên vấn đề của tầng 1 đã bị xóa sạch ngay từ đầu
• Chốt đáp án cùng với nhân viên tại hiện trường. Lấy gì làm đáp án thì phía trụ sở Nhật Bản không tự quyết được. Đặc biệt với dịch thuật và phân loại, không có cảm nhận nghiệp vụ tại chỗ thì không chốt được đáp án
• Viết trước tiêu chí đánh giá thành câu chữ. “Bản dịch tự nhiên” thì không đo được. Phải quy về những điều kiện phán đoán được như có đúng bảng thuật ngữ không, con số có được giữ nguyên không, có đúng định dạng chỉ định không
• Cắt phiên bản và cố định lại. Nếu vừa đo vừa thêm bớt hoặc sửa bộ đánh giá thì không so sánh được với lần trước

Với tiếng Việt, mục cần đặc biệt lưu ý là mục thứ hai. Câu ví dụ dùng để đánh giá, nếu được soạn mới, sẽ là tiếng Việt sạch sẽ. Đồng nhất về NFC, vị trí dấu thanh thống nhất, không có lỗi hiển thị ký tự do bảng mã cũ. Đo trên dữ liệu như vậy thì vấn đề của tầng 1 coi như không tồn tại ngay từ đầu. Rồi ngay khi đưa lên vận hành thật, toàn bộ những vấn đề tưởng đã bị xóa sẽ hiện ra hết. Mẫu bắt buộc phải lấy từ những tài liệu thực sự được tạo ra tại hiện trường.

Và trong đánh giá tiếng Việt, thứ đặc biệt có hiệu quả là gắn nhãn tầng cho từng lỗi. Với mỗi trường hợp sai, hãy ghi lại nó bắt nguồn từ tầng 1, tầng 2 hay tầng 4.

Làm như vậy thì tầng cần động vào tiếp theo sẽ được quyết định bằng dữ liệu. Nếu phần lớn lỗi bắt nguồn từ tầng 2 thì biết ngay rằng so sánh mô hình cũng vô nghĩa. Nếu lỗi bắt đầu tập trung vào tầng 4 thì đến lúc đó mới đáng bỏ tiền cho việc chọn mô hình. Đánh giá không có nhãn chỉ cho ra được con số “tổng thể đúng bao nhiêu phần trăm”, nên không quyết được hành động tiếp theo.

Có một cách gắn nhãn riêng cho tiếng Việt rất hữu ích — chia tầng 1 thành hai nhóm nhỏ. Nhóm do không khớp dạng chuẩn hóa, và nhóm do chênh lệch vị trí dấu thanh. Cách xử lý của hai nhóm này khác nhau, nên gộp chung để đếm thì không quyết được nước đi.

Về quy mô của bộ đánh giá, ở đây không nêu số lượng cụ thể. Số lượng phù hợp thay đổi theo tác vụ mục tiêu và cách lỗi phát sinh, và chưa xác nhận được một con số khái quát hóa được từ nguồn sơ cấp. Trong thực tế, cách dễ vận hành là bắt đầu xây theo tiêu chí bao gồm toàn bộ các dạng lỗi hiện đã nắm được, rồi bổ sung mỗi khi xuất hiện một dạng lỗi mới.

Phân tách chi phí thành năm tầng

Chi phí của AI tạo sinh với tiếng Việt không chỉ có phí sử dụng mô hình. Thậm chí phần ngoài phí sử dụng mô hình mới là phần gây sức ép lên ngân sách về sau.

Cần sắp xếp trước một điểm. Năm tầng chi phí ở đây tuy đánh số giống với bốn tầng xử lý đã giải thích ở nửa đầu, nhưng không phải cùng một thứ. Quan hệ tương ứng như sau.

• Tầng 1 của chi phí là chi phí xây dựng tầng 1 của xử lý (tầng ký tự)
• Tầng 2 của chi phí là chi phí xây dựng và duy trì tầng 2 của xử lý (tầng từ)
• Tầng 3 của chi phí là phí sử dụng tỷ lệ thuận với tầng 3 của xử lý (tầng token)
• Tầng 4 của chi phí là chi phí cho dữ liệu đánh giá dùng để đo tầng 4 của xử lý (tầng ngữ nghĩa)
• Tầng 5 của chi phí là chi phí vận hành trải trên cả bốn tầng

Bài viết này không nêu số tiền. Vì biên độ dao động rất lớn theo mục đích sử dụng, khối lượng tài liệu, số ngôn ngữ đích và tình trạng tài liệu nội bộ, và chưa xác nhận được mặt bằng giá khái quát hóa được từ nguồn sơ cấp. Thay vào đó, hãy nắm sự khác nhau về tính chất của các khoản chi phí.

Phân biệt chi phí một lần và chi phí kéo dài. Tầng 1 là khoản chi gần với làm một lần là xong. Tầng 2 và tầng 5 thì kéo dài. Tầng 3 phát sinh theo mức dùng. Nếu phán đoán chỉ dựa trên ước tính ban đầu mà không phân biệt điều này, thì nửa năm sau sẽ giật mình vì chi phí vận hành.

Tầng 3 có hệ số nhân. Như đã nêu, có báo cáo rằng bộ tách token BPE mức byte của GPT-4 cần số token gấp 2.5 lần cho tiếng Việt so với tiếng Anh (đây là con số được ghi lại bởi một bài báo về sau trích dẫn kết quả phân tích trong bài báo năm 2023 của Petrov và cộng sự). Với hình thức tính phí theo mức sử dụng, chênh lệch này tác động trực tiếp lên số tiền. Ở những mục đích có khối lượng tài liệu lớn, nó hiện ra thành chênh lệch chi phí vận hành hằng tháng. Tuy nhiên đây là phép so với tiếng Anh, không phải phép so giữa các bộ tách token với nhau. Khi dùng nó làm căn cứ ước tính, hãy luôn ghi kèm đó là tỷ lệ so sánh giữa cái gì với cái gì.

Chỗ dễ bị bỏ qua nhất là tầng 4. Việc xây dựng dữ liệu đánh giá cho ra sản phẩm khá nhạt và không trực tiếp làm chạy được cái gì, nên nó bị cắt khỏi ngân sách đầu tiên. Nhưng bỏ qua chỗ này thì mọi thảo luận sau đó đều thành cảm tính. Từ câu “đổi sang mô hình mới thì thấy có vẻ tốt hơn” sẽ không đi tiếp được.

Tầng 5 phát huy tác dụng sau nửa năm. Từ điển để mặc thì sẽ cũ đi. Thiết bị mới được đưa vào, mã viết tắt mới sinh ra, và mỗi lần như vậy độ chính xác tách từ lại lặng lẽ tụt xuống. Ai, với tần suất nào, nhìn vào cái gì để cập nhật từ điển. Không chốt được chỗ này thì càng theo thời gian, hệ thống càng quay về gần với trạng thái trước khi vận hành.

Với tiếng Việt có thêm một khoản chi phí phát sinh. Đó là xử lý bảng mã cũ cho tài liệu quá khứ. Khoản này nằm trong tầng 1, nhưng tùy khối lượng tài liệu cần xử lý, nó có thể trở thành hạng mục lớn nhất trong tầng 1. Hơn nữa vì là chi phí một lần, nếu không đưa vào ước tính ban đầu thì sẽ thành khoản phát sinh giữa chừng. Hãy quyết định có đưa tài liệu quá khứ vào phạm vi tìm kiếm hay không trước khi lập ước tính.

Ba vấn đề phát sinh thêm ở cơ sở tại Việt Nam

So với việc triển khai AI tạo sinh trong nội địa Nhật Bản, ở cơ sở tại Việt Nam có thêm ba vấn đề sau.

Luật về AI đã có hiệu lực

Tại Việt Nam, Law on Artificial Intelligence No.134/2025/QH15 đã được Quốc hội thông qua ngày 10 tháng 12 năm 2025 và có hiệu lực từ ngày 1 tháng 3 năm 2026. Với các hệ thống AI đã vận hành từ trước ngày có hiệu lực, luật quy định thời gian chuyển tiếp là 12 tháng đối với các lĩnh vực thông thường và 18 tháng đối với lĩnh vực y tế, giáo dục và tài chính. Cả hai đều được tính từ ngày có hiệu lực (mốc 12 tháng kể từ ngày có hiệu lực, quy đổi theo ngày dương lịch, rơi vào khoảng tháng 3 năm 2027 — đây là phép tính của bài viết này chứ không phải cách diễn đạt của văn bản gốc, vốn nêu theo số tháng).

Điểm cần nắm ở đây là Thái Lan và Việt Nam đang ở hai giai đoạn khác nhau. Luật về trí tuệ nhân tạo của Thái Lan đang ở giai đoạn dự thảo, chưa được thông qua và cũng chưa có hiệu lực. Việt Nam thì đã có hiệu lực. Khi muốn dựng một cách vận hành chung cho toàn khu vực ASEAN, chênh lệch giai đoạn này là điểm rẽ nhánh đầu tiên. Phán đoán “chưa chốt nên cứ chờ xem” có thể đứng vững ở Thái Lan, nhưng không đứng vững ở Việt Nam.

Với trường hợp triển khai mới, thiết kế sẽ nhẹ hơn vì không cần bàn tới thời gian chuyển tiếp. Lý do là có thể đưa các yêu cầu vào ngay từ đầu. Ngược lại, nếu đang có hệ thống chạy sẵn, hãy sớm xác nhận ngày bắt đầu tính thời gian chuyển tiếp và phạm vi áp dụng. Quan hệ giữa việc triển khai AI tại Việt Nam và khung pháp lý cũng được sắp xếp trong bài Những điểm cần nắm khi triển khai AI tại Việt Nam.

Phạm vi áp dụng cụ thể và nội dung nghĩa vụ của văn bản pháp luật thì hãy xác nhận với chuyên gia pháp lý tại chỗ theo từng dự án. Bài viết này giới hạn phạm vi ở sự thật rằng luật đã có hiệu lực và ở số tháng của thời gian chuyển tiếp.

Từ điển và dữ liệu đánh giá cần sự tham gia của nhân viên tại hiện trường

Từ điển của tầng 2 không thể được duy trì chỉ bởi đội kỹ thuật. Người biết cách viết đúng của tên thiết bị và mã viết tắt là hiện trường. Với tiếng Việt còn có thêm phán đoán “lấy cách bỏ dấu thanh nào làm chuẩn”. Việc này không có đáp án kỹ thuật, mà được quyết bởi thói quen tại chỗ và phân bố của dữ liệu đang có.

Điều tương tự cũng đúng với dữ liệu đánh giá của tầng 4. Lấy gì làm đáp án thì phía trụ sở Nhật Bản không tự quyết được. Đặc biệt với phân loại và dịch thuật, không có cảm nhận nghiệp vụ tại chỗ thì không chốt được đáp án.

Thứ cần có là định nghĩa thành nghiệp vụ rằng ai, với tần suất nào, nhìn vào đầu vào nào để cập nhật từ điển. Cách thực tế là nhúng nó vào quy trình nghiệp vụ hiện có, chẳng hạn đưa “bổ sung vào từ điển” thành một bước trong thủ tục khi có thiết bị mới. Nếu vận hành mà chưa chốt chỗ này, thì đồng thời cũng không có cơ chế nào để nhận ra rằng độ chính xác đang giảm.

Kết nối với hệ thống hiện hữu chắc chắn sẽ có lỗi hiển thị ký tự

Ở các cơ sở tại Việt Nam có thể đang chạy những hệ thống lõi đã nhiều năm tuổi, hoặc những hệ thống nghiệp vụ được làm tại chỗ. Nếu các hệ thống này đang giữ dữ liệu ở bảng mã cũ, thì khi tích hợp vào hệ thống hiện hành, việc xử lý lỗi hiển thị ký tự chắc chắn sẽ phát sinh.

Điều dễ bị bỏ sót ở đây là lỗi hiển thị ký tự không nhất thiết hiện ra ở dạng “không đọc được”. Do bị diễn giải theo một bảng mã sai, kết quả có thể là một chuỗi ký tự khác mà thoạt nhìn vẫn đọc được như tiếng Việt. Dữ liệu ở trạng thái này sẽ lọt qua khâu kiểm tra bằng mắt. Rồi nó tích lũy lại thành những bản ghi mà tìm kiếm cũng không trúng, tổng hợp cũng không trúng.

Cách xử lý là xác định bảng mã của dữ liệu gốc trước khi tích hợp, và cho nhân viên tại hiện trường đọc mẫu sau khi chuyển đổi. Hãy nhờ họ kiểm tra không phải là có đọc được hay không, mà là nội dung viết ra có đúng như tài liệu gốc hay không.

Làm gì trong 90 ngày đầu tiên

Đây là cách tiến hành trong 90 ngày để không sai thứ tự.

• Ngày 1 đến ngày 30 — Thu hẹp về một loại tài liệu mục tiêu, và chỉ xây phần chuẩn hóa của tầng 1. Thống nhất về NFC và thống nhất cách bỏ dấu thanh. Đồng thời đếm xem “một từ lẽ ra phải giống nhau đang bị tách thành bao nhiêu biến thể”. Con số này chính là chỉ số đo tiến độ của tầng 1
• Ngày 31 đến ngày 60 — Đến tầng 2. Xây từ điển danh từ riêng nội bộ cùng với nhân viên tại hiện trường. Và nhất định phải có những buổi kiểm tra kết quả tách từ bằng mắt. Nếu chỉ nhìn con số thì không thấy được những từ không có trong từ điển đang bị gom như thế nào
• Ngày 61 đến ngày 90 — Xây bộ đánh giá của tầng 4 và đem so hai mô hình. So sánh mô hình là việc cuối cùng. So sánh trước khi tầng 1 và tầng 2 ổn định thì không đọc được chênh lệch đến từ mô hình hay đến từ đầu vào

Trong 90 ngày này có một thứ được cố tình gạt ra ngoài. Đó là việc tối ưu bộ tách token ở tầng 3. Tầng 3 có hiệu quả khi tối ưu chi phí, nhưng không đóng góp gì cho việc phân tách nguyên nhân của vấn đề độ chính xác. Dùng 90 ngày đầu để xác định và dập nguyên nhân của triệu chứng, còn việc tối ưu chi phí thì bắt tay vào sau khi vận hành đã chạy — như vậy sẽ có đủ căn cứ để phán đoán hơn.

Một điểm nữa. Thu hẹp về một loại tài liệu không phải để giới hạn phạm vi, mà để làm nguyên nhân hiện ra. Nếu xử lý nhật ký sản xuất, hồ sơ kiểm tra và hợp đồng cùng lúc, mỗi loại sẽ hỏng theo một kiểu khác nhau, nên không biết được biện pháp nào có tác dụng với cái gì. Làm xong khuôn mẫu trên một loại thì từ loại thứ hai trở đi có thể áp cùng khuôn mẫu đó.

Với giai đoạn từ ngày 1 đến ngày 30, tiếng Việt có thêm một việc. Đó là khảo sát theo từng đường dẫn dữ liệu xem tài liệu mục tiêu đang được lưu ở NFC hay NFD. Ngay trong cùng một hệ thống, dữ liệu vào qua ô nhập liệu trên web và dữ liệu vào qua đường nạp tệp có thể ở hai dạng khác nhau. Bản thân việc lập danh sách các đường dẫn chỉ mất một ngày, nhưng không làm việc này thì không quyết được nên đặt xử lý chuẩn hóa ở đâu.

Năm sai lầm thường gặp và cách tránh

Đổi mô hình trước

Đây là dạng hay gặp nhất trong các buổi tư vấn ở cơ sở tại Việt Nam. Với báo cáo “AI tạo sinh xử lý tiếng Việt không chính xác”, phản ứng đầu tiên là đổi mô hình. Đúng như bảng theo mục đích sử dụng trong bài này, mục đích duy nhất nên đặt việc chọn mô hình ở nước đi đầu tiên là dịch thuật, còn 5 mục đích còn lại đều theo thứ tự bắt đầu từ đầu nguồn.

Cách tránh. Thu thập các trường hợp đã xảy ra triệu chứng, rồi kiểm tra xem nếu người chỉnh đầu vào cho gọn rồi đưa vào thì có hết lỗi không. Nếu hết thì đó là vấn đề của đầu nguồn. Việc kiểm tra này không cần chuẩn bị gì đặc biệt và có thể làm trước khi mua mô hình.

Cắt theo khoảng trắng rồi tưởng đó là từ

Đây là sai lầm đặc thù khi xử lý tiếng Việt. Vì văn bản được viết bằng chữ Latinh và được tách bằng khoảng trắng, nên xử lý y như tiếng Anh vẫn chạy trót lọt. Không có lỗi nào phát ra. Kết quả là cả tìm kiếm lẫn tổng hợp đều vận hành trên đơn vị âm tiết.

Cách tránh. Trong buổi rà soát thiết kế, chỉ cần hỏi đúng một câu — “văn bản tiếng Việt đang được gom thành từ ở chỗ nào”. Nếu không ai trả lời được, hoặc câu trả lời là “đang cắt theo khoảng trắng”, thì đó là ứng viên nguyên nhân. Việc kiểm tra này làm được mà không cần đọc mã nguồn.

Đưa văn bản thô cho mô hình yêu cầu đầu vào đã tách từ

Trong số các mô hình được xây riêng cho tiếng Việt có những mô hình lấy đầu vào đã tách từ làm tiền đề. README của PhoBERT ghi rõ rằng văn bản đầu vào bắt buộc phải đã được tách từ. Nếu không đọc điều kiện này mà đưa văn bản thô vào thì hiệu năng sẽ không ra. Rồi nhìn kết quả không ra gì đó, đánh giá về mô hình đó bị hạ xuống.

Cách tránh. Ngay khi đưa một mô hình vào danh sách ứng viên, hãy xác nhận điều kiện tiền xử lý mà nó yêu cầu qua README hoặc bài báo, và đưa điều kiện đó thành một mục trong bảng so sánh. Trước khi so sánh, hãy xác nhận rằng tất cả các mô hình đem so đều đi qua cùng một tiền xử lý và đều thỏa mãn điều kiện yêu cầu của riêng chúng.

Triển khai mà không xây bộ đánh giá

Đây là trạng thái mà quyết định được đưa ra dựa trên câu “đổi sang mô hình mới thì thấy có vẻ tốt hơn”. Không phân biệt được là hệ thống tốt lên thật hay chỉ là những câu hỏi tình cờ đem thử lần này dễ hơn.

Cách tránh. Chốt nguyên tắc rằng chưa xây xong bộ đánh giá thì không so sánh mô hình. Ở giai đoạn chưa có bộ đánh giá, việc làm được chỉ là chỉnh trang các tầng đầu nguồn. Và tài liệu dùng để đánh giá thì lấy từ tài liệu của hiện trường chứ không soạn ở phía trụ sở.

Viết xử lý chuẩn hóa ở khắp nơi

Đây là trạng thái mà phía tìm kiếm, phía tổng hợp và phía tóm tắt đều có đoạn mã chuẩn hóa riêng. Sửa việc thống nhất NFC ở một chỗ thì trên các đường dẫn khác vẫn còn nguyên bản cũ. Với tiếng Việt, do có hai trục là dạng chuẩn hóa và cách bỏ dấu thanh, nên càng nhiều đường dẫn thì càng nhiều tổ hợp không khớp.

Cách tránh. Gom cửa nạp dữ liệu về một mối, và chỉ chuẩn hóa tại đó. Thống nhất rằng hạ nguồn chỉ nhận chuỗi ký tự đã chuẩn hóa.

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

AI tạo sinh xử lý tiếng Việt có kém chính xác hơn tiếng Nhật không

Tùy mục đích sử dụng. Ở các mục đích lấy tầng 4 làm trung tâm như dịch và tóm tắt, phía mô hình có chênh lệch trong cách xử lý tiếng Việt. Ngược lại, phần lớn những trường hợp cảm thấy “kém hơn tiếng Nhật” ở tìm kiếm và tổng hợp lại là chênh lệch về tình trạng chỉnh trang tầng 1 và tầng 2. Có những trường hợp mà thực chất chỉ là tài liệu tiếng Nhật đã có cách viết đồng nhất sẵn, còn tài liệu tiếng Việt thì NFC và NFD lẫn lộn và vị trí dấu thanh cũng có cả kiểu cũ lẫn kiểu mới. Nếu không đưa về cùng điều kiện rồi mới so, thì không phân biệt được đó là chênh lệch năng lực ngôn ngữ của mô hình hay chênh lệch ở khâu tiền xử lý.

AI tạo sinh nào mạnh về tiếng Việt

Trong phạm vi xác nhận được, PhoGPT-4B của VinAI Research đã được công bố như một mô hình nền chuyên cho tiếng Việt. Chính xác thì nó có 3.7 tỷ tham số, được tiền huấn luyện trên kho ngữ liệu tiếng Việt 102 tỷ token, kích thước từ vựng 20480 và độ dài ngữ cảnh 8192. Cũng có bản hội thoại PhoGPT-4B-Chat. Cho nhóm ngôn ngữ Đông Nam Á thì có SEA-LION của AI Singapore, và AI Singapore tự công bố rằng SEA-LION v4 xếp thứ 5 trong 55 mô hình trên SEA-HELM, đứng thứ 1 trong nhóm mô hình mở dưới 200 tỷ tham số. Ngoài ra, vào ngày 4 tháng 6 năm 2026 có tin đưa rằng Viettel AI đã công bố mô hình tiếng Việt 120 tỷ tham số VT-Super-120B-A12B, nhưng đây là thông tin dựa trên tin báo chí trong nước, và về hiệu năng thì chưa xác nhận được nguồn sơ cấp. Mô hình nào hợp với doanh nghiệp bạn thì cách chắc chắn duy nhất là đo trên bộ đánh giá của chính doanh nghiệp.

Có cần tự xây bộ tách từ tiếng Việt không

Không cần tự làm bản thân cơ chế tách từ. Đã có sẵn các công cụ như VnCoreNLP hay underthesea. Thứ cần tự chuẩn bị là từ điển, cụ thể là từ điển danh từ riêng nội bộ. Tên thiết bị, tên linh kiện, mã viết tắt, tên chuyền. Những từ này không có trong từ điển của các công cụ phổ thông, nên nếu để nguyên cấu hình mặc định thì chúng sẽ bị để rời thành các âm tiết hoặc bị gom nhầm. Đây là phần chỉ doanh nghiệp bạn mới làm được. Ngoài ra, hãy xác nhận trước xem mô hình định dùng có yêu cầu đầu vào đã tách từ hay không. Có những mô hình yêu cầu điều này một cách tường minh, như PhoBERT.

Vì sao RAG tiếng Việt tìm kiếm không trúng

Phần lớn trường hợp nguyên nhân nằm ở tầng 2. Tiếng Việt được tách bằng khoảng trắng, nhưng khoảng trắng đó là ranh giới âm tiết chứ không phải ranh giới từ. Nếu lấy luôn khoảng trắng làm ranh giới từ thì tìm kiếm sẽ vận hành trên đơn vị âm tiết. Nếu cách gom từ ở câu hỏi và ở phía tài liệu không khớp nhau, thì từ khóa lẽ ra phải khớp lại không khớp. Tiếp theo là tầng 1, nơi việc không khớp giữa NFC và NFD cùng chênh lệch vị trí dấu thanh cản trở việc khớp. Vì đổi mô hình cũng không làm thay đổi kết quả tìm kiếm, việc đổi mô hình không có tác dụng với triệu chứng này.

AI tạo sinh với tiếng Việt có tốn kém hơn không

Về mặt số token thì có bất lợi khi dùng bộ tách token đa dụng. Có báo cáo rằng bộ tách token BPE mức byte của GPT-4 cần số token gấp 2.5 lần cho tiếng Việt so với tiếng Anh. Tuy nhiên con số này là do một bài báo về sau ghi lại kết quả phân tích trong bài báo năm 2023 của Petrov và cộng sự, và bài viết này không trực tiếp kiểm chứng bảng số liệu trong bài báo gốc. Với hình thức tính phí theo mức sử dụng, chênh lệch này tác động lên số tiền. Thêm nữa, trong thực tế, chi phí xây dựng từ điển và chi phí vận hành thường mới là thứ phát huy tác dụng về sau nhiều hơn phí sử dụng mô hình, và với tiếng Việt thì việc xử lý bảng mã cũ cho tài liệu quá khứ cũng có thể trở thành một khoản chi phí ban đầu. An toàn hơn là đừng dựng bài toán chi phí chỉ bằng phí sử dụng mô hình.

Đo độ chính xác với tiếng Việt bằng cách nào

Lấy mẫu từ tài liệu nội bộ thực tế, chốt đáp án cùng nhân viên tại hiện trường, viết trước tiêu chí đánh giá thành câu chữ, rồi cố định phiên bản. Không dùng câu ví dụ soạn ở phía trụ sở Nhật Bản. Vì câu ví dụ soạn mới sẽ được viết ở dạng NFC theo kiểu bỏ dấu mới, nên vấn đề của tầng 1 bị xóa sạch ngay từ đầu. Và với mỗi lỗi, hãy gắn nhãn cho biết nó bắt nguồn từ tầng 1, tầng 2 hay tầng 4. Với tiếng Việt, chia thêm tầng 1 thành nhóm do không khớp dạng chuẩn hóa và nhóm do chênh lệch vị trí dấu thanh sẽ giúp dễ quyết nước đi hơn. Có nhãn này thì tầng cần động vào tiếp theo sẽ được quyết định bằng dữ liệu.

Tổng kết

Khi AI tạo sinh xử lý tiếng Việt không đủ chính xác, thứ đang hỏng không phải mô hình mà là khâu tiền xử lý. Dưới đây là phần sắp xếp lại các điểm chính của bài viết.

• Xử lý tiếng Việt chia thành bốn tầng — tầng ký tự, tầng từ, tầng token và tầng ngữ nghĩa. Mô hình nằm ở tầng 4, và chỉ đổi riêng chỗ đó thì chỗ hỏng ở đầu nguồn vẫn còn
• Tầng 1 là tầng đưa về cùng dạng những chuỗi ký tự nhìn giống nhau nhưng bên trong khác nhau. Không khớp giữa NFC và NFD, chênh lệch vị trí dấu thanh, lỗi tổ hợp của bộ gõ và lỗi hiển thị ký tự do bảng mã cũ đều thuộc về đây
• Tầng 2 là mấu chốt. Tiếng Việt có khoảng trắng, nhưng đó là ranh giới âm tiết chứ không phải ranh giới từ. Xử lý cắt theo khoảng trắng chạy trót lọt mà không báo lỗi, nên nó không bao giờ được đưa vào danh sách nghi vấn về nguyên nhân
• Về độ chính xác tách từ, trên tập kiểm tra của VLSP 2013 (2120 câu), RDRsegmenter đạt F1 97.90%, còn mức cao nhất trên cùng benchmark là 98.06% của UITws-v1. Mặt khác, trên Vietnamese Universal Dependencies Treebank (hơn 800 câu) thì có các con số underthesea 80.04%, VnCoreNLP 78.37%, PyVi 57.88%. Vì dữ liệu đánh giá khác nhau nên không thể so sánh trực tiếp, nhưng điều đó cho thấy con số thay đổi rất nhiều tùy dữ liệu đánh giá
• Tầng 3 ảnh hưởng tới chi phí và lượng nội dung nhét được vào. Có báo cáo rằng bộ tách token của GPT-4 cần số token gấp 2.5 lần cho tiếng Việt so với tiếng Anh (con số qua một bài báo về sau trích dẫn bài báo năm 2023 của Petrov và cộng sự)
• Mô hình càng được xây riêng cho tiếng Việt thì càng lấy tiền xử lý làm tiền đề. PhoBERT bắt buộc đầu vào phải đã được tách từ
• Tầng chi phối khác nhau theo mục đích sử dụng. Mục đích duy nhất nên đặt việc chọn mô hình ở nước đi đầu tiên là dịch thuật, còn RAG, chatbot, biên bản họp, OCR biểu mẫu, phân loại và tổng hợp đều bắt đầu từ tầng 1 hoặc tầng 2
• Chi phí chia thành năm tầng. Chỗ dễ bị bỏ qua nhất là việc xây dựng dữ liệu đánh giá, và bỏ qua chỗ này thì không còn bàn được về độ chính xác
• Luật về AI của Việt Nam đã có hiệu lực từ ngày 1 tháng 3 năm 2026. Với hệ thống hiện hữu, thời gian chuyển tiếp là 12 tháng cho lĩnh vực thông thường và 18 tháng cho lĩnh vực y tế, giáo dục và tài chính. Thái Lan còn ở giai đoạn dự thảo, hai nước đang ở hai giai đoạn khác nhau
• Trong 90 ngày đầu, hãy tiến theo thứ tự chuẩn hóa, từ điển, rồi bộ đánh giá. Việc so sánh mô hình đặt ở cuối cùng

Vấn đề độ chính xác khi xử lý tiếng Việt có thể bắt đầu từ việc phân tách xem nó đang phát sinh ở tầng nào. Bạn cũng có thể liên hệ ở giai đoạn còn đang cân nhắc, chẳng hạn chỉ muốn xem thử tài liệu của doanh nghiệp mình đang vỡ ở tầng nào, hay chỉ muốn trao đổi về cách xây bộ đánh giá. Vui lòng liên hệ với chúng tôi qua trang liên hệ.

Tham khảo

• VnCoreNLP (GitHub) — Bộ công cụ xử lý ngôn ngữ tự nhiên tiếng Việt
• arXiv — A Fast and Accurate Vietnamese Word Segmenter
• undertheseanlp NLP-Vietnamese-progress — Bảng xếp hạng tách từ
• huybik — Word Tokenizer Benchmark
• VinAIResearch PhoBERT (GitHub)
• VietUnicode — Câu hỏi thường gặp
• arXiv — PhoGPT Generative Pre-training for Vietnamese
• AI Singapore — Bảng xếp hạng SEA-HELM
• VILAF — Việt Nam ban hành Luật Trí tuệ nhân tạo đầu tiên