Độ chính xác và chi phí của AI tạo sinh tiếng Thái — thứ hỏng là tiền xử lý chứ không phải mô hình

Khi đưa AI tạo sinh vào chi nhánh tại Thái Lan, một báo cáo rất hay xuất hiện là hệ thống chạy đúng như mong đợi với tiếng Nhật và tiếng Anh, nhưng riêng tiếng Thái thì độ chính xác tụt hẳn xuống. Phần lớn hiện trường phản ứng bằng cách đổi sang mô hình khác, và phần lớn trường hợp vẫn không hết bệnh. Khi AI tạo sinh tiếng Thái không chạy như mong muốn, thứ đang hỏng không phải là mô hình, mà là phần xử lý ký tự và từ nằm ngay phía trước mô hình. Bài viết này chia việc xử lý tiếng Thái thành bốn tầng, rồi sắp xếp theo từng mục đích sử dụng để thấy rõ sửa tầng nào thì cải thiện được điều gì.

Điều thực sự đang xảy ra khi có người nói AI tạo sinh tiếng Thái không đạt độ chính xác

Ở chi nhánh Thái Lan, những báo cáo đầu tiên đưa lên thường có ba hình dạng sau.

• Cho tìm kiếm tài liệu nội bộ thì tài liệu lẽ ra phải có lại không hiện ra. Hỏi đúng câu đó bằng tiếng Nhật thì lại ra
• Cho tổng hợp báo cáo ngày hoặc hồ sơ kiểm tra viết bằng tiếng Thái thì tổng số 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òng
• Dịch và tóm tắt vẫn chạy, nhưng bản dịch cứng, danh từ riêng bị đổi, mức độ lịch sự không đồng nhất

Điểm chung là tất cả đều không phải dạng sai liên tục, mà là dạng thỉnh thoảng mới sai. Đó chính là chỗ khó chịu. Nếu lúc nào cũng hỏng thì người ta sẽ nghi ngờ cấu hình, nhưng thứ chỉ thỉnh thoảng mới hỏng thì không viết nổi các bước tái hiện. Một lỗi không viết được các bước tái hiện rất dễ bị bỏ qua khâu xác định nguyên nhân và kết luận gọn thành 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 bá là có hỗ trợ tiếng Thái. Nhưng triệu chứng vẫn còn nguyên hình dạng cũ. Số lượt tìm kiếm trượt có thể giảm đi đôi chút, nhưng những tài liệu đã không tìm ra thì vẫn tiếp tục không tìm ra.

Lý do rất đơn giản — mô hình nằm ở vị trí cuối cùng của dòng xử lý. Chuỗi ký tự đã hỏng từ thượng nguồn, hay từ đã bị cắt sai từ thượng 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 khỏi bệnh vì chỗ cần sửa vẫn chưa được ai động tới.

Bài viết này chia việc xử lý tiếng Thái 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 được triệu chứng nào thuộc về tầng nào, để quyết định được thứ tự sửa. Sai thứ tự thì phần lớn chi phí và thời gian sẽ bị hút hết vào tầng cuối cùng.

Xử lý tiếng Thái 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 Thái đến được với AI tạo sinh, nó đi qua bốn tầng. Theo thứ tự từ thượng 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 tính chất khác nhau xét trên thực tế vận hành.

Càng lên thượng nguồn, làm một lần thì hiệu quả kéo dài mãi. Chuẩn hoá của tầng 1 chỉ cần đặt ở cửa vào một lần là tự động có tác dụng với 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 đúng lượng đã dùng.

Càng lên thượng 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 lên thượng nguồn, triệu chứng lại càng trông giống lỗi của mô hình. Vì thất bại ở tầng 1 và tầng 2 xuất hiện dưới dạng thỉnh thoảng mới sai, nên nguyên nhân không được xác định và trách nhiệm bị đẩy xuống hạ nguồn.

Trong phạm vi những gì chúng tôi quan sát được tại các chi nhánh ở Thái Lan, phần lớn các trường hợp được đưa đến với tư cách là vấn đề độ chính xác đều giải thích được bằng tầng 1 và tầng 2. Những thứ đáng lẽ phải xử lý như vấn đề của tầng 4 thì trước khi làm chắc phần thượng nguồn, về cơ bản còn không phân biệt nổi.

Tầng 1 Tầng ký tự — tiếng Thái trông giống nhau nhưng bên trong khác nhau

Ở tầng 1 chỉ có đúng một việc phải làm. Đưa những chuỗi ký tự cùng nghĩa về cùng một dãy byte.

Với tiếng Thái, việc này khó hơn tiếng Nhật. Lý do là chữ Thái có cấu trúc chồng các dấu nguyên âm và dấu thanh lên phía trên, phía dưới, bên trái và bên phải của phụ âm. Dấu nguyên âm và dấu thanh đặt phía trên, dù thứ tự gõ vào có bị đảo, trên màn hình vẫn hiển thị gần như y hệt nhau. Mắt người thấy là cùng một từ, nhưng với máy tính thì đó là hai chuỗi ký tự khác nhau.

Bên cạnh đó, tài liệu tiếng Thái còn lẫn những dao động sau.

• Có ký tự phân cách vô hình được nhúng vào trong nội dung. Nó được dùng để điều khiển vị trí ngắt dòng, và tuỳ nguồn sao chép mà có hoặc không có
• Năm được viết theo Phật lịch. Trong hồ sơ kiểm tra và hợp đồng thì Phật lịch còn thông dụng hơn dương lịch
• Chữ số được viết bằng chữ số Thái. Có khi chỉ lẫn vào một phần của số lô hoặc số bản vẽ
• Tên thiết bị và mã bằng tiếng Anh dao động giữa dạng rộng và dạng hẹp, giữa chữ hoa và chữ thường

Nhìn từ hiện trường thì nó ra sao. Đối chiếu master thiết bị với báo cáo ngày bằng tiếng Thái thì hệ thống trả về không có kết quả. Người phụ trách so hai bên trên màn hình cũng thấy đúng là hai chuỗi ký tự hoàn toàn giống nhau. Thế là câu chuyện chuyển thành tìm kiếm của hệ thống có vấn đề, rồi trôi sang chuyện cấu hình công cụ tìm kiếm hoặc chuyện mô hình. Thực tế thì chỉ là một bên có lẫn thêm đúng một ký tự vô hình.

Cách sửa tầng 1 xét về mặt tính năng thì khá nhạt. Gom cửa vào của khâu nạp dữ liệu về một mối, và bắt buộc mọi thứ đi qua bước chuẩn hoá tại đó. Cụ thể là chuẩn hoá ký tự, loại bỏ ký tự phân cách vô hình, chuyển chữ số Thái sang chữ số Ả Rập, chuyển Phật lịch sang dương lịch, và thống nhất cách viết chữ và số. Chỉ có vậy.

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

Tầng 1 đã chắc hay chưa thì kiểm tra được bằng con số chứ không phải bằng mắt. Đế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ì tầng 1 vẫn còn việc phải làm.

Tầng 2 Tầng từ — trong một ngôn ngữ không có khoảng trắng, chưa ai quyết định cắt từ ở đâu

Đây là tầng quan trọng nhất của AI tạo sinh tiếng Thái.

Bài báo của PyThaiNLP mô tả cách viết tiếng Thái bằng câu “Thai is a scriptio continua”. Nghĩa là cách viết phổ biến nhất là không có khoảng trắng hay bất kỳ dấu phân cách nào, cả giữa các từ lẫn giữa các câu. Nói cách khác, câu tiếng Thái không tách từ về mặt thị giác như tiếng Nhật, cũng không được ngăn bằng khoảng trắng như tiếng Anh. Nó được viết thành một dãy ký tự liên tục.

Với người đọc tiếng Việt, điều này dễ hình dung theo chiều ngược lại. Tiếng Việt luôn có khoảng trắng giữa các âm tiết, nên ranh giới hiển thị đã tồn tại sẵn trong văn bản ngay từ đầu — dù một từ tiếng Việt có thể gồm nhiều âm tiết, máy vẫn luôn có sẵn một mốc để bám vào. Tiếng Thái thì không có mốc nào cả.

Hệ quả là phía máy tính phải tự quyết định cắt từ ở đâu. Xử lý này gọi là tách từ (word segmentation). Mọi hệ thống làm việc với tiếng Thái, dù tường minh hay ngầm định, chắc chắn đều đang cắt từ ở một chỗ nào đó.

Vấn đề nằm ở chỗ không phải chỉ một xử lý phụ thuộc vào cách cắt này.

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

Tức là cách cắt thay đổi thì bốn thứ này cùng thay đổi. Nói ngược lại, nếu cách cắt tồi thì bốn thứ này cùng hỏng. Hơn nữa, do kiểu hỏng không đồng đều nên triệu chứng hiện ra dưới dạng tìm kiếm lúc trúng lúc trượt.

Ở tài liệu của các chi nhánh Thái Lan, chỗ dễ vỡ nhất về cách cắ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 thứ này không có trong từ điển phổ thông. Từ nào không có trong từ điển thì cơ chế tách từ mặc định sẽ phân rã nó thành tổ hợp của các từ gần giống. Cách phân rã lại thay đổi theo ký tự đứng trước và đứng sau, nên cùng một tên thiết bị sẽ bị cắt theo những kiểu khác nhau tuỳ từng tài liệu.

Nhìn từ hiện trường thì nó ra sao. Báo cáo ngày của cùng một thiết bị nằm thành hai thiết bị trên bảng tổng hợp. Người phụ trách báo lên rằng thiết bị chỉ có một máy mà lại hiện hai dòng, nhưng nguyên nhân không nằm ở master thiết bị cũng không nằm ở khâu nhập liệu — nó nằm ở chỗ ngay tại thời điểm cắt tài liệu thành từ, cái tên đã bị tách làm hai kiểu.

Cách sửa tầng 2 là làm một 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 hơn là mang tính rà soát từ vựng cùng nhân sự bản địa. Và vì mỗi lần có thêm thiết bị hay linh kiện mới lại phải bổ sung, nên nó không phải việc làm một lần là xong.

Cách xây dựng tìm kiếm tri thức đa ngôn ngữ được chúng tôi bàn thêm trong bài cách tiến hành khi xây dựng tìm kiếm tri thức nhà máy bằng RAG. Khi thiết kế một hệ tìm kiếm có bao gồm tiếng Thái, quyết định trước xem tầng 2 sẽ được đảm bảo ở đâu sẽ giúp giảm số lần phải quay lại làm lại.

Đọc con số độ chính xác tách từ 71.18% như thế nào cho đúng

Việc tách từ tiếng Thái có sẵn các benchmark công khai. Theo bài báo của PyThaiNLP, engine mặc định của PyThaiNLP là NewMM đạt 71.18% trên benchmark BEST 2010, còn mức cao nhất tại cùng thời điểm là 95.60%.

NewMM là phương thức cắt từ theo khớp dài nhất (maximum matching) dựa trên từ điển, đồng thời dùng Thai Character Cluster làm ràng buộc cho ranh giới. Lấy từ có trong từ điển sao cho dài nhất có thể. Đó là cơ chế cơ bản của nó.

Khi đọc con số này, có ba điểm không được bỏ sót.

Thứ nhất. 71.18% là hiệu năng của giá trị mặc định, chứ không phải giới hạn trên của xử lý tiếng Thái. Tại cùng thời điểm đó đã tồn tại phương thức đạt 95.60% trên chính benchmark ấy. Nghĩa là nhìn vào con số của trạng thái dùng nguyên xi không cấu hình gì rồi kết luận rằng tách từ tiếng Thái chỉ đạt khoảng bảy phần mười là kết luận quá sớm.

Thứ hai. Lỗi không rải đều. Vì đây là phương thức dựa trên từ điển, nên các từ phổ thông có trong từ điển sẽ được cắt tốt, còn chỗ vỡ là ở những từ không có trong từ điển. Mà những từ quan trọng xuất hiện trong tài liệu nội bộ thì hầu hết đều là từ không có trong từ điển. 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 của vấn đề chính là những từ mà doanh nghiệp muốn bắt trúng nhất trong tài liệu của mình lại là những từ dễ rơi nhất khi để nguyên mặc định. Đây chính là lý do không thể lấy thẳng con số của benchmark phổ thông làm độ chính xác cho tài liệu của công ty mình.

Thứ ba. Con số này là giá trị so sánh trên một benchmark cụ thể. Còn trên tài liệu của chính công ty bạn thì kết quả ra sao, chỉ có đo trên tài liệu của công ty bạn mới biết được. Con số benchmark dùng để nắm xu hướng của phương thức, chứ không phải thứ đặt thẳng vào làm mục tiêu nội bộ.

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

Tầng 3 Tầng token — cùng một tài liệu tiếng Thái mà số token chênh nhau 2.62 lần

Tầng 3 là tầng chia văn bản thành đơn vị mà mô hình dùng để đếm. Tầng này tác động đến chi phí và lượng đưa vào được nhiều hơn là đến bản thân độ chính xác.

Bài báo về Typhoon có ghi rằng tokenizer của Typhoon hiệu quả hơn 2.62 lần so với GPT-3.5 trong việc token hoá tiếng Thái. Nghĩa là với cùng một tài liệu tiếng Thái, số token đếm được khi xử lý bằng tokenizer của Typhoon và khi xử lý bằng tokenizer của GPT-3.5 chênh nhau đúng bằng tỷ lệ đó. Đây là giá trị đo thực tế khi so sánh giữa hai đối tượng cụ thể, chứ không phải con số thể hiện mức chênh lệch tối đa giữa hai tokenizer bất kỳ.

Ở đây cần dập tắt luôn một cách hiểu sai rất hay gặp. Con số 2.62 lần này không phải là so sánh với tiếng Anh. Đó là mức chênh lệch giữa việc xử lý cùng một tài liệu tiếng Thái bằng một tokenizer phổ thông và bằng một tokenizer đã tối ưu cho tiếng Thái. Do đó không thể nói rằng tiếng Thái đắt gấp 2.62 lần tiếng Anh. Ngoài ra, trên mạng có những bản tóm tắt thứ cấp ghi đối tượng so sánh là GPT-4, nhưng đối tượng so sánh trong tài liệu gốc là GPT-3.5. Khi trích dẫn, hãy bám theo tài liệu gốc.

Có hai tình huống mà khoảng chênh này phát huy tác dụng trong thực tế.

Hoá đơn. Với các mô hình tính tiền theo lượng 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, ví dụ mỗi ngày cho đọc hồ sơ kiểm tra của vài năm, thì tỷ lệ này biến thành đúng khoảng chênh về chi phí vận hành.

Lượng đưa vào được ngữ cảnh. Cùng một khung độ dài ngữ cảnh, số trang tài liệu tiếng Thái nhét vào được sẽ khác nhau. Trong RAG, các tài liệu nhặt được từ 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 được vào giảm. 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 đường này, tầng 3 gián tiếp chạm cả vào độ chính xác.

Tuy nhiên tầng 3 là một hệ số nhân, không phải nguyên nhân. Nếu tầng 2 đang hỏng và tìm kiếm không nhặt được đúng tài liệu, thì có nhồi tài liệu đó vào một cách hiệu quả đến mấy câu trả lời cũng không khá hơn. Việc chọn tokenizer nên được xử lý như một bước tối ưu hoá sau khi phần thượng nguồn đã chắc — đó mới là thứ tự tự nhiê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ự được đưa vào như thế nào và sinh ra cái gì. Các triệu chứng thuộc về tầng này gồm những thứ sau.

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

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

Nếu so sánh mô hình mà không làm bước tách bạch này trước, thì kết luận của phép so sánh sẽ không đáng tin. Bởi vì khi thượng nguồn còn dao động, so hai mô hình với nhau sẽ không phân biệt được chênh lệch sinh ra là do khác biệt giữa hai mô hình hay do tài liệu tình cờ nhặt được khác nhau.

Căn cứ để phán đoán ở tầng 4 là giá trị đo thực tế trên bộ đánh giá của chính công ty bạn. Thứ hạng trên benchmark công khai có thể dùng làm căn cứ để thu hẹp danh sách ứ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ụ của chính bạn.

Vị trí hiện tại của các mô hình mạnh về tiếng Thái — Typhoon 2, SEA-LION và các mô hình tiên phong

Dưới đây là phần sắp xếp lại những gì kiểm chứng được từ nguồn sơ cấp về nhóm mô hình đang đầu tư cho tiếng Thái.

Xin bổ sung vài điểm.

Dải kích thước của Typhoon 2 đồng nghĩa với độ rộng của lựa chọn. Có đủ từ 1B đến 70B nghĩa là dễ dựng được thiết kế kiểu xử lý những tài liệu không đưa lên đám mây được bằng một mô hình nhỏ chạy on-premise. Ngoài ra Typhoon2-Vision tích hợp sẵn OCR, còn Typhoon2-Audio xử lý vào ra bằng giọng nói. Với các mục đích như OCR chứng từ hay biên bản họp, hai bản này sẽ lọt vào diện xem xét.

SEA-LION do AI Singapore phát triển. AI Singapore là tổ chức nhận hỗ trợ từ National Research Foundation của Singapore và được đặt tại Đại học Quốc gia Singapore. Đây là nhóm mô hình theo định hướng xử lý gộp nhiều ngôn ngữ dành cho khu vực Đông Nam Á, nên không chỉ tiếng Thái mà cả ngôn ngữ của các nước lân cận cũng nằm trong cùng một khung. Với doanh nghiệp có chi nhánh ở cả Việt Nam hay Indonesia bên cạnh Thái Lan, điểm này tạo ra khác biệt thật sự về mặt vận hành.

SEA-HELM thì thuộc về phía đánh giá. Nó không phải mô hình, mà là khung đánh giá LLM cùng bảng xếp hạng, với trọng tâm đặt vào các ngôn ngữ Đông Nam Á. Tuy nhiên bài viết này không đi sâu vào điểm số hay thứ hạng của từng mô hình cụ thể, vì chúng tôi chưa kiểm chứng được các con số đó từ nguồn sơ cấp. Cách dùng an toàn là tham chiếu nó như một cửa vào để thu hẹp ứng viên, còn phán quyết cuối cùng thì để cho bộ đánh giá của chính mình.

Không cần loại các mô hình tiên phong ra khỏi danh sách. Các mô hình lớn đa dụng cũng xử lý được tiếng Thái. Có điều, vì lần này chúng tôi không kiểm chứng được từ nguồn sơ cấp một điểm số so sánh nào ở tiếng Thái, nên bài viết này không viết rằng mô hình chuyên tiếng Thái luôn tốt hơn, cũng không viết rằng mô hình tiên phong luôn tốt hơn. Điều gì chưa kiểm chứng được thì chúng tôi ghi đúng là chưa kiểm chứng được.

Thứ cần quyết trước khi chọn mô hình không phải là thứ hạng, mà là các ràng buộc. Có cần giọng nói hay OCR không. Tài liệu có được phép đưa ra ngoài công ty không. Có bắt buộc phải đặt mô hình trong môi trường nội bộ không. Yêu cầu về tốc độ phản hồi ra sao. Quyết được chỗ này thì danh sách ứng viên rút xuống còn vài cái. 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ì có hiệu quả

Đây là phần trung tâm của bài viết. Cùng là chuyện tiếng Thái không đạt độ chính xác, nhưng tầng chi phối lại khác nhau theo mục đích sử dụng. Nhắm trượt tầng chi phối rồi mới ra tay 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 trong sáu mục đích sử dụng.

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

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

Trong phạm vi các ca chúng tôi được hỏi ý kiến tại chi nhánh Thái Lan, phần lớn nguyên nhân khiến tìm kiếm trong RAG tiếng Thái không trúng đều nằm ở tầng 2. Cách cắt của câu hỏi và cách cắt phía tài liệu không khớp nhau. Đặc biệt khi danh từ riêng nội bộ bị phân rã khác nhau ở hai phía, thì những từ khoá lẽ ra phải khớp lại không khớp.

Tầng có hiệu quả rõ là tầng 1 và tầng 2. Đưa ký tự về một mối, đưa từ về một mối. 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 tác động lên lượng tài liệu đưa được vào, nên nó làm dày thêm phần căn cứ.

Tầng gần 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 hành văn 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 đó thì vẫn còn nguyên.

Tầng nên động vào trước tiên là tầng 2. Làm từ điển danh từ riêng nội bộ, rồi cho cả 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 đã thay đổi.

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

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 người ta đang 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, và phần này thuộc tầng 4.

Với chatbot tiếng Thái, triệu chứng hay gặp là hỏi cùng một câu nhưng diễn đạt khác đi thì bot không bắt được nữa. Câu hỏi thường ngắn hơn báo cáo ngày, mang tính khẩu ngữ, và có lẫn cả dao động chính tả. Câu càng ngắn thì thất bại về cách cắt càng đánh thẳng vào kết quả.

Tầng có hiệu quả rõ là tầng 2 và tầng 4. Giữ một từ điển từ vựng câu hỏi ở tầng 2, và chỉnh khuôn mẫu cách trả lời ở tầng 4. Tầng gần như không hiệu quả là tầng 3, vì mỗi lượt câu đều ngắn nên khác biệt tokenizer không ảnh hưởng nhiều đến 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, và cụ thể hơn là thu thập từ vựng từ chính những câu hỏi thực tế đã đến.

Phần sắp xếp chatbot đa ngôn ngữ theo góc độ chi phí và các bước triển khai được chúng tôi 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ì mỗi ngôn ngữ lại đảm bảo ở một tầng khác nhau, nên đư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

Với mục đích biến cuộc họp tiếng Thái thành văn bản, trước hết văn bản được dựng lên 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 giọng nói thành văn bản, thứ ta nhận được là văn bản ở trạng thái cách viết còn dao động. 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 ngay trong cùng một cuộc họp. Nếu không đưa chỗ này về một mối ở tầng 1, thì ở khâu tóm tắt phía sau cùng một người có thể bị xử lý thành hai người, hoặc một quyết định bị liệt kê thành hai mục riêng biệt. Tầng 4 thì tác động đến việc phân biệt người nói và chất lượng tóm tắt.

Tầng gần 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 là không hiệu quả. Nếu vận hành theo hướng về sau còn tìm kiếm lại biên bản họp, thì đúng thời điểm đó tầng 2 bắt đầu có tác dụ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 nhỏ, và nó bắt đầu có tác dụng ngay khi ta chồng thêm tìm kiếm hoặc tổng hợp lên trên — hiểu theo thứ tự này thì sẽ không phán đoán sai.

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

Về những chỗ khiến bản tóm tắt vỡ trong các cuộc họp đa ngôn ngữ, chúng tôi có sắp xếp lại trong bài những đứt gãy khi tạo biên bản họp đa ngôn ngữ bằng AI. Ở những cuộc họp mà người nói chuyển qua lại giữa các ngôn ngữ, chỗ bị vỡ sẽ khác với cuộc họp thuần tiếng Thái.

OCR chứng từ — tầng 1 chi phối

Phiếu giao hàng, biên bản kết quả kiểm tra, chỉ thị công việc. Đây là mục đích lấy dữ liệu ra từ giấy hoặc từ 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ẽ lẫn lộn chữ số Thái với chữ số Ả Rập, năm ghi theo Phật lịch, và có cả ký tự phân cách vô hình chen vào. Đưa nguyên trạng thái này vào hệ thống lõi thì sẽ có một loạt lỗi kiểu số lô không khớp, thứ tự ngày tháng loạn, phán đoán hạn không chạy.

Tầng có hiệu quả rõ là tầng 1. Chuẩn hoá chữ số, chuyển đổi lịch, chuẩn hoá mã ký tự. Ngoài ra, độ chính xác của chính việc đọc ảnh thì thuộc phía mô hình ở tầng 4, và quyết định có dùng mô hình tích hợp sẵn OCR hay không nằm ở đây.

Tầng gần như không hiệu quả là tầng 2. Giá trị các trường trên chứng từ phần nhiều vốn không cần cắt thành từ. Tách từ mã hàng hay số lượng thì chẳng thu được gì. Chỉ khi dùng cách khớp từ để đối chiếu tên trường thì tầng 2 mới dính vào một phần.

Tầng nên động vào trước tiên là tầng 1, và cụ thể là chuẩn hoá chữ số Thái và Phật lịch. Hai thứ này có triệu chứng dễ nhận ra và biện pháp xử lý cũng chuẩn hoá được thành khuôn, nên rất đáng đặt lên trước trong thứ tự bắt tay vào việc.

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

Dịch từ tiếng Nhật sang tiếng Thái và từ tiếng Thái 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ữ, mức độ lịch sự. Những thứ này do chất lượng diễn giải và sinh văn bản 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 một bảng thuật ngữ, đổi chỉ thị theo từng loại tài liệu, so sánh các mô hình. Tầng 1 cũng có tác dụng, nhưng vai trò của nó là làm sạch đầu vào. Nếu để nguyên ký tự phân cách vô hình rồi đưa vào, phía mô hình sẽ bị nhiễu trong việc phán đoán ranh giới từ.

Tầng gần như không hiệu quả là tầng 2. Trong dịch thuật ta đưa cả câu vào, nên về cơ bản không cần chèn thêm một bộ tách từ tự dựng. Dốc công sức vào đây thì bản dịch cũng không khá hơn.

Tầng nên động vào trước tiên là tầng 4, và cụ thể là sắp xếp bảng thuật ngữ cùng việc phân loại tài liệ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ì thế nào cũng có một loại bị lệch tông.

Cách phân loại tài liệu để chặn dao động của bản dịch được chúng tôi bàn trong bài thiết kế khi tự động hoá dịch thuật trong ngành sản xuất bằng AI. Điểm mấu chốt là đặt trước tiền đề rằng mỗi loại tài liệu đòi hỏi một tính chất bản dịch khác nhau.

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 báo cáo ngày và báo cáo lỗi bằng tiếng Thái theo từng hạng mục. Chỗ này do sự phối hợp giữa tầng 1 và tầng 2 quyết định.

Kết quả tổng hợp thay đổi tuỳ theo việc các từ dùng làm khoá 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 sẽ tách thành hai dòng, và nếu việc tách từ không ổn định thì cùng một lỗi sẽ rơi vào hai hạng mục khác nhau. Tầng có hiệu quả rõ là tầng 1 và tầng 2.

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

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

Có một điều đúng cho mọi mục đích sử dụng. Nhìn vào cột tầng nên động vào trước tiên trong bảng, ta thấy mục đích duy nhất nên đặt việc chọn mô hình làm nước đi đầu tiên là dịch thuật, còn năm mục đích còn lại đều bắt tay 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à phần thượng nguồn. Nước đi đầu tiên kiểu cứ đổi mô hình trước đã là sai thứ tự ở 5 trên 6 mục đích sử dụng.

Sáu cái bẫy đặc thù của tiếng Thái

Phần này hạ toàn bộ cuộc bàn luận về các tầng ở trên xuống thành những triệu chứng cụ thể. Ở tài liệu của các chi nhánh Thái Lan, sáu thứ sau là những chỗ dễ vấp nhất.

Phật lịch — phép so sánh ngày tháng hỏng trong im lặng

Trong hồ sơ kiểm tra, hợp đồng và giấy tờ công của Thái Lan, năm được viết theo Phật lịch (พ.ศ.). Năm Phật lịch 2569 tương ứng với năm 2026 dương lịch.

Nhìn từ hiện trường thì nó ra sao. Nếu nạp vào mà không đổi sang dương lịch, thì ngày tháng vẫn vào đúng dưới dạng con số, nhưng mọi phép so sánh và sắp xếp đều lệch. Khi năm Phật lịch và năm dương lịch lẫn vào cùng một cột, sắp xếp lại sẽ tạo ra khoảng cách hàng trăm năm. Nếu có dựng phán đoán hạn, thì một thời hạn lẽ ra đã hết sẽ bị phán là chưa hết. Hơn nữa nó không phát sinh lỗi, nên chẳng ai nhận ra.

Thuộc tầng nào. Tầng 1. Chuyển sang dương lịch ngay tại cửa vào của khâu nạp dữ liệu, đồng thời giữ lại cách viết gốc. Chuẩn bị sẵn khả năng đưa ngược về Phật lịch khi hiển thị sẽ giúp nhân sự bản địa kiểm tra nhẹ nhàng hơn.

Chữ số Thái — cùng một số lại thành số khác

Tiếng Thái có bộ chữ số Thái (๐๑๒๓๔๕๖๗๘๙). Chúng tương ứng với các chữ số Ả Rập từ 0 đến 9, nhưng trên máy tính thì đó là những ký tự hoàn toàn khác.

Nhìn từ hiện trường thì nó ra sao. Có khi chữ số Thái chỉ lẫn vào một phần của số lô hoặc số bản vẽ. Việc này xảy ra khi chép lại từ phiếu viết tay, hoặc khi vẫn tiếp tục dùng các biểu mẫu theo định dạng cũ. Kết quả là cùng một số lô tồn tại dưới hai kiểu chuỗi ký tự, và trên bảng tổng hợp chúng nằm thành hai lô riêng biệt. Người phụ trách báo lên rằng trên màn hình có hai dòng cùng một số, nhưng xét về chuỗi ký tự thì đó là hai thứ khác nhau, nên phía hệ thống đang chạy đúng.

Thuộc tầng nào. Tầng 1. Đặt bước chuẩn hoá về chữ số Ả Rập ngay tại cửa vào.

Thứ tự kết hợp — trông giống nhau nhưng tìm kiếm không khớp

Chữ Thái được viết bằng cách chồng dấu nguyên âm và dấu thanh lên phụ âm. Khi có từ hai dấu trở lên nằm phía trên, dù thứ tự gõ có bị đảo thì hình thức trên màn hình gần như không đổi. Nhưng nếu thứ tự các code point khác nhau thì xét về chuỗi ký tự đó là hai thứ khác nhau.

Nhìn từ hiện trường thì nó ra sao. Nhân sự bản địa gõ tay một từ vào ô tìm kiếm tiếng Thái thì máy trả về không có kết quả. Nhưng sao chép chính từ đó rồi dán vào thì lại trúng. Từ phía người phụ trách, việc này thành báo cáo rằng tìm kiếm thỉnh thoảng không ăn, rồi bị bỏ đó vì không giải thích nổi nguyên nhân. Thực tế chỉ là thứ tự nhập vào khác với phía tài liệu.

Thuộc tầng nào. Tầng 1. Cho đi qua bước chuẩn hoá ký tự để đưa thứ tự về một dạng duy nhất.

Khoảng trắng độ rộng bằng không — ký tự phân cách vô hình

Vì tiếng Thái không đặt khoảng trắng giữa các từ, nên để nguyên như vậy thì máy không quyết định được vị trí ngắt dòng. Do đó, người ta có khi nhúng vào nội dung một ký tự phân cách vô hình để chỉ ra những vị trí được phép ngắt dòng.

Nhìn từ hiện trường thì nó ra sao. Cùng một câu, nhưng bản dán từ Word và bản dán từ web lại cho kết quả tìm kiếm khác nhau. Đếm số ký tự thì không khớp với số ký tự nhìn thấy. Cho đi qua bộ tách từ thì từ bị tách làm đôi ngay tại chỗ có ký tự phân cách. Ở đây triệu chứng cũng hiện ra dưới dạng thỉnh thoảng tìm kiếm không trúng.

Thuộc tầng nào. Tầng 1. Về nguyên tắc là loại bỏ, nhưng với dữ liệu dùng để hiển thị mà muốn giữ hình thức ngắt dòng đẹp thì cũng có thể quyết định giữ lại. Tách bạch theo hướng dùng bản đã loại bỏ cho tìm kiếm và tổng hợp, dùng bản còn giữ cho hiển thị thì cả hai yêu cầu đều được đáp ứng.

Trộn Anh và Thái — ngôn ngữ chuyển đổi ngay trong một câu

Ở tài liệu hiện trường của các chi nhánh Thái Lan, tên thiết bị, tên linh kiện, mã viết tắt nội bộ và đơn vị được viết nguyên bằng tiếng Anh, còn phần diễn giải thì viết bằng tiếng Thái. Ngay trong một câu, hệ chữ viết chuyển đổi nhiều lần.

Nhìn từ hiện trường thì nó ra sao. Bộ tách từ thường coi ranh giới giữa chữ Thái và chữ Latin là ranh giới từ, nên phần tiếng Anh bị cắt rời khỏi ngữ cảnh tiếng Thái. Kết quả là từ bổ nghĩa tiếng Thái đứng ngay trước tên thiết bị tiếng Anh bị dính vào một từ khác, và đơn vị ngữ nghĩa bị lệch đi. Ở khâu tìm kiếm, chỉ phần tiếng Anh được nhặt lên còn ngữ cảnh thì mất. Ở khâu dịch, có khi mã model tiếng Anh bị đem đi dịch mất.

Thuộc tầng nào. Trọng tâm là tầng 2. Đăng ký vào từ điển những từ cần giữ nguyên tiếng Anh, rồi cố định cách cắt và cách xử lý chúng. Ngoài ra còn cần đưa dạng rộng và dạng hẹp, chữ hoa và chữ thường về một mối ở tầng 1.

Tiểu từ lịch sự cuối câu — manh mối về người nói và mức độ lịch sự

Tiếng Thái có những từ chỉ sự lịch sự gắn ở cuối câu. Người nói là nam thì dùng ครับ, là nữ thì dùng ค่ะ, tức là nó thay đổi theo giới tính của người nói.

Nhìn từ hiện trường thì nó ra sao. Trong bản chuyển giọng nói thành văn bản của biên bản họp, từ này trở thành manh mối để suy đoán người nói. Nếu ở khâu tiền xử lý ta loại bỏ nó với lý do là từ không mang nghĩa, thì ở khâu sau việc phân tách người nói sẽ yếu đi. Ngược lại, trong dịch thuật, nếu dịch thẳng từ này ra thì phía tiếng Nhật trở nên không tự nhiên, còn nếu lược bỏ quá tay thì mức độ lịch sự không còn khớp với bản gốc.

Thuộc tầng nào. Thay đổi theo mục đích sử dụng. Với biên bản họp là không được xoá nó ở khâu tiền xử lý của tầng 1, còn với dịch thuật là phải viết vào chỉ thị của tầng 4 cách tái hiện mức độ lịch sự. Cùng một từ, tuỳ mục đích mà trở thành thứ phải giữ hoặc thứ phải bỏ. Nếu dùng chung một khâu tiền xử lý cho mọi mục đích thì chỗ này sẽ xung đột, nên cách an toàn là làm sao cho khâu tiền xử lý tách được theo từng mục đích sử dụng.

Tạo dữ liệu đánh giá tiếng Thái — lộ trình ngắn nhất để nói được về độ chính xác

Toàn bộ câu chuyện từ đầu đến giờ đều đặt trên tiền đề là đo được. Nếu sửa các tầng mà không đo, thì không biết là đã sửa được hay chưa sửa được.

Các bước tạo dữ liệu đánh giá tiếng Thái 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. Cố đo nhiều thứ trong cùng một bộ đánh giá thì sẽ không đọc đượ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ật. Không dùng câu ví dụ tự soạn. Câu ví dụ tự soạn không chứa dao động cách viết, không có ký tự phân cách vô hình, cũng không có Phật lịch, nên vấn đề của tầng 1 và tầng 2 đã biến mất ngay từ đầu
• Quyết đáp án cùng với nhân sự bản địa. Lấy gì làm đáp án là thứ không thể quyết một mình từ phía Nhật Bản. Đặc biệt với dịch thuật và phân loại, không có cảm nhận nghiệp vụ của người bản địa thì đáp án không định được
• Viết trước tiêu chí phán định thành câu chữ. Nói bản dịch tự nhiên thì không đo được. Phải hạ xuống thành những điều kiện phán định được, kiểu 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
• Chốt phiên bản và cố định lại. Nếu giữa chừng cứ thêm bớt và sửa bộ đánh giá thì sẽ không so sánh được với lần trước

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

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

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

Phân rã chi phí thành năm tầng

Chi phí của AI tạo sinh tiếng Thái không chỉ có phí sử dụng mô hình. Đúng hơn là phần ngoài phí sử dụng mô hình mới là thứ về sau bóp nghẹt ngân sách.

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

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

Bài viết này không nêu số tiền. Vì biên độ rất rộng tuỳ theo mục đích sử dụng, khối lượng tài liệu, số ngôn ngữ đối tượng và tình trạng tài liệu nội bộ, và chúng tôi chưa kiểm chứng được từ nguồn sơ cấp một mặt bằng giá nào có thể tổng quát hoá. Thay vào đó, xin hãy nắm lấy sự khác nhau về tính chất của các loại chi phí.

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

Tầng 3 có một hệ số nhân đè lên. Tỷ lệ 2.62 nói ở trên tác động vào chính tầng này. Vì cùng xử lý một tài liệu tiếng Thái mà số token đếm được lại thay đổi tuỳ tokenizer. Ở những mục đích có khối lượng tài liệu lớn, khoảng chênh này hiện ra hằng tháng dưới dạng chênh lệch chi phí vận hành.

Phần dễ bị bỏ qua nhất là tầng 4. Việc xây dựng dữ liệu đánh giá có sản phẩm đầu ra rất nhạt và không trực tiếp làm cái gì chạy được, nên nó bị cắt khỏi ngân sách đầu tiên. Nhưng bỏ qua chỗ này thì toàn bộ các cuộc bàn luận về sau đều thành cảm tính. Chỉ dựa trên cảm giác rằng đổi sang mô hình mới thì có vẻ tốt hơn, cuộc bàn luận không đi tiếp được đến đâu 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 ra đời, và mỗi lần như thế độ 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 quyết chỗ này thì thời gian càng trôi, hệ thống càng quay về gần trạng thái trước khi vận hành.

Ba vấn đề phát sinh thêm ở chi nhánh Thái Lan và ASEAN

So với việc đưa AI tạo sinh vào trong nước Nhật, ở chi nhánh Thái Lan có thêm ba thứ sau chồng lên.

Giai đoạn của quy định khác nhau theo từng nước

Tại Thái Lan, ETDA đã công bố bản dự thảo mới của luật về trí tuệ nhân tạo vào ngày 2 tháng 7 năm 2026. Thời gian lấy ý kiến công chúng được nêu là khoảng 30 ngày. Tính đến tháng 8 năm 2026, luật này chưa được thông qua và cũng chưa có hiệu lực. Các vấn đề đang nằm trong bản dự thảo hiện tại gồm khung phân chia rủi ro thành ba cấp, quy định buộc doanh nghiệp nước ngoài phải có đại diện trong nước, nghĩa vụ gắn dấu hiệu máy đọc được lên sản phẩm do AI sinh ra, và trách nhiệm liên đới có thể phát sinh ngay cả khi không có lỗi.

Về diễn biến trước đó, vào tháng 6 năm 2025 đã có một phiên lấy ý kiến công chúng nhằm hợp nhất hai bản dự thảo, và sau đó văn bản vẫn tiếp tục ở giai đoạn dự thảo.

Điều có thể nói ngay lúc này về tác động thực tế là xây dựng bám sát những yêu cầu chưa chốt thì còn quá sớm, nhưng vẫn có giá trị khi để lại một cấu trúc cho phép bổ sung về sau. Đặc biệt là việc gắn dấu hiệu lên sản phẩm sinh ra, cùng với việc ghi lại mô hình và đầu vào đã dùng để sinh ra nó, thuộc loại yêu cầu rất khó truy ngược để bổ sung sau. Chỉ cần lo trước phần thiết kế log thôi cũng đã giúp giảm khối lượng phải làm lại khi các yêu cầu được chốt.

Ngoài ra, ngay trong khu vực ASEAN thì giai đoạn cũng khác nhau theo từng nước. Việt Nam đã ở giai đoạn có hiệu lực, nhưng bài viết này chỉ dừng ở việc chỉ ra sự thật rằng Thái Lan và Việt Nam đang ở hai giai đoạn khác nhau. Chi tiết yêu cầu của từng nước, xin hãy tra cứu nguồn sơ cấp của chính nước đó.

Vận hành với từ ba ngôn ngữ trở lên

Ở chi nhánh Thái Lan, tiếng Nhật, tiếng Thái và tiếng Anh chạy song song cùng lúc. Báo cáo về tổng công ty ở Nhật thì bằng tiếng Nhật, hiện trường thì tiếng Thái, tài liệu của nhà sản xuất thiết bị thì tiếng Anh — cấu trúc thường là như vậy.

Thứ cần quyết ở đây là lấy ngôn ngữ nào làm bản gốc chuẩn. Không quyết bản gốc chuẩn thì người ta sẽ bắt đầu tranh luận bằng cách đối chiếu các bản dịch với nhau, và không ai quyết được bên nào mới đúng. Khâu tiền xử lý cũng vậy, nếu chỉnh chuẩn hoá và từ điển trên ngôn ngữ gốc chuẩn rồi cho các ngôn ngữ khác phái sinh từ đó, thì việc duy trì từ điển chỉ còn một bộ.

Quyết định ai là người duy trì từ điển

Từ điển của tầng 2 không thể duy trì chỉ bằng độ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. Mặt khác, giao việc cập nhật từ điển cho thiện chí của hiện trường thì sẽ không bề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 làm thực tế là nhúng nó vào quy trình nghiệp vụ sẵn có, chẳng hạn đưa bước bổ sung từ điển vào thủ tục khi có thiết bị mới được đưa vào. Nếu đưa hệ thống vào chạy mà chưa quyế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 tụt.

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

Đây là lộ trình 90 ngày để không đi sai thứ tự.

• Từ ngày 1 đến ngày 30 — Thu hẹp về đúng một loại tài liệu mục tiêu, và chỉ làm phần chuẩn hoá của tầng 1. Đồ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ỉ báo đo tiến độ của tầng 1
• Từ ngày 31 đến ngày 60 — Đến tầng 2. Làm từ điển danh từ riêng nội bộ cùng với nhân sự bản địa. Và nhất định phải có những buổi ngồi nhìn tận mắt kết quả tách từ. Chỉ nhìn con số thì sẽ không thấy được những từ ngoài từ điển đang vỡ ra sao
• Từ ngày 61 đến ngày 90 — Làm bộ đánh giá của tầng 4 và so sánh 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 đã chắc 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ứ chúng tôi cố ý loại ra. Đó là tối ưu hoá tokenizer ở tầng 3. Tầng 3 có tác dụng khi tối ưu chi phí, nhưng không đóng góp gì cho việc tách bạ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 tối ưu chi phí thì bắt tay sau khi vận hành đã chạy đều — làm vậy thì căn cứ để phán đoán sẽ đầy đủ hơn.

Còn một điểm nữa. Việc thu hẹp về đúng một loại tài liệu không nhằm bó hẹp phạm vi, mà nhằm làm cho nguyên nhân trở nên nhìn thấy được. Xử lý báo cáo ngày, hồ sơ kiểm tra và hợp đồng cùng lúc thì mỗi loại vỡ theo một kiểu khác nhau, nên sẽ không biết biện pháp nào có tác dụng lên cái gì. Làm xong khuôn trên một loại rồi thì từ loại thứ hai trở đi có thể áp thẳng khuôn đó vào.

Năm thất bại thường gặp và cách né

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

Đây là dạng chúng tôi gặp nhiều nhất trong các ca được hỏi ý kiến tại chi nhánh Thái Lan. Trước một báo cáo rằng tiếng Thái không đạt độ chính xác, phản ứng đầu tiên lại là chuyển sang mô hình khác. Đú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 làm nước đi đầu tiên là dịch thuật, còn năm mục đích còn lại đều theo thứ tự bắt tay từ thượng nguồn.

Cách né. Gom các ca có triệu chứng về một chỗ, rồi kiểm tra xem để người chỉnh đầu vào trước khi đưa vào thì có hết lỗi không. Nếu hết thì đó là vấn đề của thượng 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 cả khi đi mua mô hình.

Xây tìm kiếm khi chưa quyết cách cắt của bộ tách từ

Đây là trạng thái mà tìm kiếm, chia chunk, khớp từ khoá và đánh giá mỗi thứ dùng một cách cắt khác nhau. Vì từng cái nhìn riêng thì đều có vẻ đang chạy, nên vấn đề chỉ lộ ra khi không còn giải thích được độ chính xác của tìm kiếm nữa.

Cách né. Chốt về đúng một bộ xử lý tách từ và một từ điển, rồi dựng cấu hình sao cho mọi xử lý đều tham chiếu đến đúng bộ đó. Cũng cần đưa vào thiết kế điểm rằng khi cập nhật từ điển thì phải dựng lại chỉ mục tìm kiếm.

Tiến hành mà không làm bộ đánh giá

Đây là trạng thái mà quyết định được đưa ra dựa trên cảm giác rằng đổi sang mô hình mới thì 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à tình cờ những câu hỏi đem ra thử lần đó dễ hơn.

Cách né. Quyết luôn rằng chưa làm xong bộ đánh giá thì không so sánh mô hình. Ở giai đoạn chưa có bộ đánh giá, thứ duy nhất làm được là chỉnh trang các tầng thượng nguồn.

Viết xử lý chuẩn hoá rải rác 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ó một đoạn mã chuẩn hoá riêng. Sửa việc chuyển đổi Phật lịch ở một chỗ thì ở đường đi khác nó vẫn còn nguyên bản cũ.

Cách né. Gom cửa vào của khâu nạp dữ liệu về một mối, và chỉ chuẩn hoá ở đúng chỗ đó. Thoả thuận rằng phía hạ nguồn chỉ nhận vào những chuỗi đã chuẩn hoá.

Không quyết người phụ trách và tần suất cập nhật từ điển

Đây là dạng điển hình mà ngay sau khi vận hành thì độ chính xác cao, rồi tụt dần theo thời gian. Vì thiết bị mới và mã viết tắt mới không được đưa vào từ điển, nên tầng 2 cũ đi từng chút một.

Cách né. Cài bước bổ sung từ điển vào thủ tục đưa thiết bị vào hoặc thủ tục khởi động sản phẩm mới. Ngoài ra, đưa việc đo lại định kỳ trên bộ đánh giá vào quy trình vận hành, để phát hiện bằng con số khi chất lượng bắt đầu tụt.

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

AI tạo sinh tiếng Thái có kém chính xác hơn tiếng Nhật không?

Tuỳ mục đích sử dụng. Với những mục đích xoay quanh tầng 4 như dịch thuật hay tóm tắt thì có chênh lệch ở cách phía mô hình xử lý tiếng Thái. Mặt khác, phần lớn những trường hợp mà người dùng cảm thấy tìm kiếm hay tổng hợp kém hơn tiếng Nhật thực chất là chênh lệch về mức độ chỉnh trang của tầng 1 và tầng 2. Có khi đơn giản chỉ là tài liệu tiếng Nhật đã được thống nhất cách viết từ trước, còn tài liệu tiếng Thái thì chưa. 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 về năng lực ngôn ngữ của mô hình hay chênh lệch về tiền xử lý.

AI tạo sinh nào mạnh về tiếng Thái?

Trong phạm vi kiểm chứng được từ nguồn sơ cấp, Typhoon 2 của SCB 10X được công bố ngày 10 tháng 1 năm 2025, và bản văn bản có đủ 5 kích thước từ 1B đến 70B. Còn có Typhoon2-Audio với vào ra bằng giọng nói và Typhoon2-Vision tích hợp sẵn OCR. Dành cho các ngôn ngữ Đông Nam Á thì có SEA-LION của AI Singapore, hỗ trợ 11 ngôn ngữ SEA trở lên, bản mới nhất là SEA-LION v4.5 (ngày 20 tháng 5 năm 2026). Về khung đánh giá thì có SEA-HELM. Tuy nhiên vì chúng tôi chưa kiểm chứng được từ nguồn sơ cấp các điểm số và thứ hạng cụ thể, nên bài viết này không đi vào thứ hạng. Cái nào hợp với công ty bạn thì đo bằng bộ đánh giá của chính công ty bạn là cách chắc chắn duy nhất.

Có cần tự chuẩn bị bộ tách từ tiếng Thái không?

Không cần tự viết lấy bản thân cơ chế tách từ. Đã có sẵn các thư viện. Thứ cần tự chuẩn bị là phía từ điển, và cụ thể hơn là từ điển danh từ riêng nội bộ. Vì engine mặc định NewMM của PyThaiNLP chạy theo khớp dài nhất dựa trên từ điển, nên cách cắt sẽ vỡ ngay ở chỗ những tên thiết bị và mã viết tắt không có trong từ điển. Phần này chỉ có chính công ty bạn mới làm được.

Vì sao tìm kiếm trong RAG tiếng Thái không trúng?

Trong phạm vi các ca chúng tôi được hỏi ý kiến tại chi nhánh Thái Lan, nguyên nhân nằm ở tầng 2 chiếm phần nhiều. Vì cách cắt của câu hỏi và cách cắt phía tài liệu không khớp nhau, nên những từ khoá lẽ ra phải khớp lại không khớp. Đặc biệt hay gặp là trường hợp danh từ riêng nội bộ bị phân rã khác nhau ở hai phía. Kế đến là tầng 1, nơi ký tự phân cách vô hình và dao động cách viết cản trở việc khớp. Vì đổi mô hình thì kết quả tìm kiếm không đổi, nên việc chuyển mô hình không có tác dụng với triệu chứng này.

AI tạo sinh tiếng Thái có tốn kém hơn không?

Tuỳ tokenizer mà số token đếm được sẽ khác nhau ngay cả với cùng một tài liệu tiếng Thái. Bài báo về Typhoon có ghi rằng tokenizer của Typhoon hiệu quả hơn GPT-3.5 2.62 lần trong việc token hoá tiếng Thái. Với hình thức tính tiền theo lượng dùng, khoảng chênh này đi thẳng vào số tiền. Tuy nhiên đây là phép so sánh giữa các tokenizer cùng xử lý tài liệu tiếng Thái, chứ không phải so sánh với tiếng Anh. Ngoài ra trên thực tế, chi phí chỉnh trang 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, nên an toàn hơn là đừng dựng cuộc bàn luận về chi phí chỉ dựa trên phí sử dụng mô hình.

Đo độ chính xác của tiếng Thái bằng cách nào?

Lấy mẫu từ tài liệu nội bộ thật, quyết đáp án cùng nhân sự bản địa, viết trước tiêu chí phán định thành câu chữ, rồi cố định phiên bản. Không dùng câu ví dụ tự soạn. Vì trong đó không có dao động cách viết cũng không có ký tự phân cách vô hình, nên vấn đề của tầng 1 và tầng 2 biến mất ngay từ đầu. Sau đó, 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. Có nhãn này thì tầng cần động vào tiếp theo sẽ được quyết bằng dữ liệu.

Tổng kết

Khi AI tạo sinh không đạt độ chính xác với tiếng Thái, 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 ý chính của bài viết.

• Việc xử lý tiếng Thái chia thành bốn tầng gồm tầng ký tự, tầng từ, tầng token và tầng ngữ nghĩa. Mô hình nằm ở tầng 4, nên chỉ đổi mỗi chỗ đó thì phần hỏng ở thượng nguồn vẫn còn nguyên
• Tầng 1 là tầng đưa về một mối những chuỗi trông giống nhau nhưng bên trong khác nhau. Phật lịch, chữ số Thái, ký tự phân cách vô hình và thứ tự kết hợp đều nằm ở đây
• Tầng 2 là then chốt. Vì tiếng Thái không có khoảng trắng giữa các từ nên phải quyết cắt từ ở đâu. Tìm kiếm, chia chunk, khớp từ khoá và đánh giá cùng phụ thuộc vào cách cắt này
• Độ chính xác tách từ của engine mặc định NewMM thuộc PyThaiNLP là 71.18% trên benchmark BEST 2010. Mức cao nhất tại cùng thời điểm là 95.60%. Để nguyên mặc định thì sẽ rơi ở chỗ từ vựng riêng của công ty không có trong từ điển
• Tầng 3 tác động lên chi phí và lượng đưa vào được. Tokenizer của Typhoon hiệu quả hơn GPT-3.5 2.62 lần trong việc token hoá tiếng Thái. Tuy nhiên đây không phải là so sánh với tiếng Anh
• 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 làm nước đi đầu tiên là dịch thuật, còn RAG, chatbot, biên bản họp, OCR chứng từ, phân loại và tổng hợp đều bắt tay từ tầng 1 hoặc tầng 2
• Chi phí chia thành năm tầng. Phần dễ bị bỏ qua nhất là việc xây dựng dữ liệu đánh giá, và bỏ qua nó thì không còn bàn được về độ chính xác
• 90 ngày đầu tiên hãy đi theo thứ tự chuẩn hoá, từ điển rồi bộ đánh giá. Việc so sánh mô hình đặt ở cuối cùng

Những câu hỏi về việc tiếng Thái không đạt độ chính xác đều có thể bắt đầu từ chỗ tách bạch xem chuyện đang xảy ra ở tầng nào. Bạn đang ở giai đoạn muốn xem thử tài liệu của công ty mình đang vỡ ở tầng nào, hay chỉ muốn trao đổi riêng về cách xây bộ đánh giá, cũng hoàn toàn không sao. Xin liên hệ với chúng tôi tại đây.

Thông tin tham khảo

• Bài báo arXiv về PyThaiNLP — Thai Natural Language Processing in Python
• Bài báo arXiv về Typhoon — Thai Large Language Models
• SCB 10X giới thiệu Typhoon 2
• SEA-LION của AI Singapore
• Bảng xếp hạng SEA-HELM của AI Singapore
• Mondaq — Thái Lan công bố dự thảo mới của Luật Trí tuệ nhân tạo
• Norton Rose Fulbright — dự thảo luật AI của Thái Lan