AI tạo sinh tiếng Trung trong nhà máy — mô hình 4 lớp để biết sửa đúng chỗ

Vấn đề mà người ta tìm kiếm dưới cụm từ “AI tạo sinh tiếng Trung” hầu như không bao giờ là chuyện “mô hình không biết tiếng Trung”. Các mô hình sinh lớn hiện nay đều có khối lượng dữ liệu huấn luyện tiếng Trung rất lớn. Vậy mà tại hiện trường, độ chính xác vẫn tụt — bởi vì tiếng Trung hỏng ở những chỗ khác hẳn tiếng Nhật hay tiếng Anh. Việc dùng lẫn chữ giản thể và phồn thể, những chữ Hán cùng một mã nhưng khác hình dạng, việc không có dấu cách nên chẳng ai quy định ranh giới của từ, và việc khi token hóa thì máy tự ghép ra những “từ” không hề tồn tại. Những thứ này không biến mất khi bạn đổi mô hình.

Bài viết này dành cho các nhà máy Nhật tại Thái Lan đang phải làm việc với thiết bị sản xuất tại Trung Quốc và với đối tác nói tiếng Trung. Mục tiêu là tách bạch xem việc xử lý tiếng Trung đang hỏng ở đâu, theo từng lớp, để bạn tự phán đoán được sửa chỗ nào thì mới có hiệu quả.

Khi người ta nói “dùng tiếng Trung thì AI tạo sinh kém chính xác”, thực tế đang xảy ra chuyện gì

Các triệu chứng được nêu ở hiện trường thường rơi vào một trong những trường hợp sau.

• Cho dịch tài liệu hướng dẫn của thiết bị Trung Quốc thì cùng một chi tiết lại ra tên tiếng Nhật khác nhau ở mỗi đoạn
• Để bản đặc tả từ Đài Loan và bản từ Trung Quốc đại lục vào cùng một thư mục rồi tìm kiếm thì chỉ ra được một bên
• Đưa chứng từ tiếng Trung vào OCR thì con số đúng nhưng tên hàng lại thành chữ khác
• Cho sinh thư trả lời nhà cung cấp thì nghĩa vẫn thông nhưng lẫn vào thuật ngữ mà bên đối tác không dùng
• Định nạp trọn một bản đặc tả kỹ thuật dài thì chạm trần sớm hơn dự tính rất nhiều

Tất cả đều dễ bị gom lại thành một câu “AI kém chính xác”, nhưng lớp gây ra chúng lại hoàn toàn khác nhau. Trường hợp thứ nhất và thứ tư là vấn đề cắt từ và thuật ngữ, thứ hai và thứ ba là vấn đề ký tự, thứ năm là vấn đề token. Nếu trộn lẫn các lớp rồi kết luận “đổi sang mô hình tốt hơn là xong”, bạn chỉ tăng chi phí hằng tháng còn triệu chứng vẫn còn nguyên.

Với tiếng Thái và tiếng Việt chúng tôi cũng đã trình bày theo đúng cấu trúc này. Mỗi ngôn ngữ hỏng ở một chỗ khác nhau, nhưng thứ tự tách bạch vấn đề thì giống nhau. Bạn có thể tham khảo thêm mô hình 4 lớp cho AI tạo sinh tiếng Thái và mô hình 4 lớp cho AI tạo sinh tiếng Việt.

Bài này chỉ tập trung vào câu hỏi “vì sao tiếng Trung khó xử lý với AI tạo sinh”. Bức tranh tổng thể về tự động hóa nghiệp vụ dịch thuật được trình bày trong bài tự động hóa dịch thuật trong doanh nghiệp.

Vì sao nhà máy Nhật tại Thái Lan cần quan tâm đến AI tạo sinh tiếng Trung

Phản ứng “công ty tôi không có cơ sở ở Trung Quốc nên không liên quan” ngày càng khó đứng vững tại Thái Lan. Có ba lý do.

Tiếng Trung đi vào từ phía chuỗi cung ứng

Theo công bố của Ủy ban Đầu tư Thái Lan (BOI), tính đến năm 2026 chuỗi cung ứng xe điện của Thái Lan đã có tuyên bố đầu tư vượt 4.1 tỷ USD, với 198 dự án bao gồm BEV, xe hybrid, pin, linh kiện và hạ tầng sạc. Riêng phần sản xuất BEV chiếm 18 dự án với 1.18 tỷ USD, trong đó có các hãng Trung Quốc như BYD, SAIC Motor, Aion, Changan Auto, Omoda and Jaecoo, và công suất theo kế hoạch vượt 370,000 xe mỗi năm. Trước đó, vào tháng 3 năm 2025, khoản đầu tư hơn 1 tỷ USD của Sunwoda Electronic (Trung Quốc) vào sản xuất cell pin cũng đã được Ủy ban Chính sách Nâng cao Năng lực Cạnh tranh Quốc gia Thái Lan phê duyệt.

Phía nhà cung cấp cũng dịch chuyển theo cùng hướng. Phân tích của THAIBIZ cho thấy số lượng nhà cung cấp gốc Hoa tiến vào Thái Lan đã đạt 183 trường hợp tính đến tháng 6 năm 2025, trong đó nhóm gia công chế tạo chiếm nhiều nhất với 125 trường hợp. Chỉ trong hai năm rưỡi từ 2023 đến tháng 6 năm 2025 đã có 90 trường hợp mới, và chính sách ưu đãi xe điện của Thái Lan (EV3.0 / EV3.5) được xem là nguyên nhân thúc đẩy.

Nói cách khác, ngay cả khi công ty bạn không hề quyết định dùng tiếng Trung, xác suất có doanh nghiệp Trung Quốc xuất hiện ở lớp nhà cung cấp cấp hai, cấp ba vẫn tăng lên. Việc trao đổi bản vẽ, thông báo thay đổi, báo cáo lỗi — thông tin gốc sẽ đến bằng tiếng Trung ngày một nhiều.

Tài liệu hướng dẫn và đặc tả của thiết bị Trung Quốc

Lý do thứ hai nằm ở phía thiết bị. Máy ép phun, thiết bị kiểm tra, dây chuyền vận chuyển, robot công nghiệp, thiết bị nguồn — các nhà máy tại Thái Lan sử dụng máy móc sản xuất tại Trung Quốc không phải chuyện hiếm. Vấn đề ở đây là ngay cả khi có bản hướng dẫn tiếng Anh thì nội dung của nó cũng không khớp với bản tiếng Trung. Bản sửa đổi được cập nhật trước ở phiên bản tiếng Trung, còn bản tiếng Anh chạy theo không kịp. Bảng mã lỗi và danh mục tham số được đính kèm nguyên bản tiếng Trung. Câu trả lời FAQ từ đơn vị bảo trì đến qua nhóm chat tiếng Trung. Kết quả là hình thành một trạng thái mà thông tin chính xác chỉ tồn tại ở phía tiếng Trung.

Trao đổi với nhân viên và đơn vị thầu phụ nói tiếng Trung

Lý do thứ ba là con người. Ngày càng nhiều trường hợp kỹ sư nói tiếng Trung thường trú tại cơ sở Thái Lan, hoặc một phần công đoạn được giao cho đơn vị thầu phụ gốc Hoa. Trao đổi hằng ngày vẫn chạy bằng tiếng Anh hoặc tiếng Thái, nhưng khi vào những tình huống bàn sâu về kỹ thuật thì tiếng Trung nhanh hơn. Thế là biên bản họp, chỉ thị công việc, các chi tiết của tiêu chuẩn kiểm tra được lưu lại bằng tiếng Trung. Vài năm sau, khi bị hỏi về truy xuất nguồn gốc, việc trong công ty có ai đọc được những ghi chép tiếng Trung đó hay không sẽ trở nên quyết định.

Cả ba trường hợp này đều không phải là “kết quả của việc chọn tiếng Trung làm ngôn ngữ nghiệp vụ”, mà là “kết quả của việc tiếng Trung tự đi vào”. Chính vì vậy, thay vì đi theo hướng tăng nhân sự chuyên trách tiếng Trung, sẽ đáng giá hơn nếu nghĩ theo hướng làm cho những người phụ trách hiện có xử lý được thông tin gốc bằng tiếng Trung.

Xử lý tiếng Trung chia thành 4 lớp — lớp ký tự, lớp từ, lớp token, lớp ngữ nghĩa

Trước khi một đoạn văn bản tiếng Trung đến được mô hình, nó đi qua bốn lớp có bản chất hoàn toàn khác nhau. Mỗi lớp hỏng theo một kiểu và cách sửa cũng khác nhau.

Điều quan trọng là thứ tự. Nếu lớp dưới đã hỏng thì dù chọn mô hình tốt đến đâu ở lớp trên cũng không sửa được. Ngược lại, lớp ký tự và lớp từ chỉ cần chỉnh một lần là có hiệu lực lâu dài. Với tiếng Trung, đặc điểm nổi bật là lớp ký tự có trọng số lớn hơn nhiều so với hình dung của người nói tiếng Nhật hay tiếng Việt.

Lớp 1 lớp ký tự — chữ Hán giản thể phồn thể trong AI hỏng đầu tiên ở đây

Giản thể và phồn thể không tương ứng một đối một

Giả định “giản thể với phồn thể chỉ cần chuyển đổi là xong” không đứng vững trong thực tế. Lý do là trong quá trình hợp nhất sang chữ giản thể, có rất nhiều trường hợp nhiều chữ phồn thể bị gộp lại thành một chữ giản thể duy nhất.

Khi chuyển ngược từ giản thể sang phồn thể, phải dựa vào ngữ cảnh để chọn chữ phồn thể nào. Nếu xử lý chỗ này bằng phép thay thế ký tự đơn giản, sẽ xuất hiện lỗi kiểu “理发” biến thành “理發”. Đúng ra phải là “理髮”. Chiều ngược lại (từ phồn thể sang giản thể) về cơ bản là ánh xạ nhiều-về-một nên tương đối an toàn, nhưng vẫn có ngoại lệ ở danh từ riêng và tên người.

Nghĩa là, nếu không quyết định trước tài liệu nội bộ lấy tự dạng nào làm bản chính thì cả tìm kiếm lẫn thống kê đều sẽ phân nhánh.

Cùng một mã Unicode nhưng tự dạng vẫn khác nhau

Một điểm nữa dễ bị bỏ sót là chữ Hán hợp nhất trong Unicode (CJK Unified Ideographs). Chữ Hán dùng ở Trung Quốc đại lục, Đài Loan, Hồng Kông, Nhật Bản và Hàn Quốc về nguyên tắc được hợp nhất vào cùng một điểm mã như “cùng một chữ”, dù hình dạng có khác nhau (ngoại trừ những chữ vốn đã được mã hóa riêng biệt trong các bộ ký tự gốc của từng nước). Hình dạng thực tế hiển thị ra sao thì do phông chữ và thẻ ngôn ngữ quyết định.

Ví dụ, các chữ như “骨”, “直”, “次”, “令”, “者” sẽ có hình dạng khác nhau khi hiển thị bằng phông tiếng Trung so với phông tiếng Nhật. Vì chuỗi byte giống hệt nhau nên tìm kiếm vẫn ra, nhưng diện mạo của bản in hay file PDF thì khác. Và nhìn từ phía OCR, đây là chuyện nghiêm trọng. Đưa một tài liệu in bằng tự dạng phông tiếng Trung cho mô hình được huấn luyện trên tự dạng vùng tiếng Nhật đọc, tỷ lệ nhận dạng sẽ có xu hướng giảm.

Ngoài ra, những ký tự có gắn bộ chọn dị thể (IVS) hầu như không phân biệt được bằng mắt nếu thiếu phông hỗ trợ, nhưng chuỗi byte lại khác với trường hợp chỉ có ký tự nền. Nếu cột tên hàng trong file Excel nhận từ đối tác có lẫn ký tự gắn IVS, việc đối chiếu khớp tuyệt đối sẽ thất bại một cách âm thầm.

Đại lục, Hồng Kông, Đài Loan, Singapore dùng thuật ngữ khác nhau

Không chỉ tự dạng, từ vựng cũng phân nhánh. Dưới đây là những từ xuất hiện nhiều trong ngành chế tạo.

Singapore về tự dạng thì dùng giản thể, nhưng từ vựng có những cách nói riêng. Hồng Kông dùng phồn thể nhưng đôi khi từ vựng lại nghiêng về cách dùng của đại lục.

Ý nghĩa thực tế là như sau. Khi tìm bản đặc tả về “hàn laser”, tài liệu của nhà cung cấp đại lục viết là “激光焊接”, còn tài liệu của bên Đài Loan viết là “雷射焊接”. Nếu không có từ điển đồng nghĩa mà chỉ tìm bằng một cách viết, phía còn lại sẽ vĩnh viễn không hiện ra. Đây là vấn đề nằm ở ranh giới giữa lớp 1 và lớp 2, và đổi mô hình không sửa được.

Dấu câu và ký hiệu

Tiếng Trung dùng dấu câu toàn phần (，。；：) và dùng dấu ngắt liệt kê (、) cho các thành phần song song. Nếu chỗ này lẫn dấu phẩy hay dấu chấm nửa phần, cả việc phân tách từ lẫn việc tách câu đều rối. Khi nạp tài liệu tiếng Trung từ Excel hay email, việc lẫn ký hiệu nửa phần xảy ra hằng ngày. Việc chuẩn hóa lớp ký tự cần bao gồm cả việc thống nhất các ký hiệu này.

Lớp 2 lớp từ — ngôn ngữ không có dấu cách và chưa ai quyết định “cắt từ ở đâu”

Tiếng Trung không có ranh giới từ bằng dấu cách như tiếng Anh. Các ký tự chỉ đơn thuần nối tiếp nhau. Do đó, cắt từ ở đâu là do hệ thống xử lý quyết định. Và cách quyết định đó về bản chất luôn chứa sự mơ hồ.

Sự mơ hồ mang tính cấu trúc, không phải ngẫu nhiên

Một ví dụ hay được dẫn ra là “部分居民生活水平”. Vốn dĩ chuỗi này phải cắt thành “部分 / 居民 / 生活 / 水平” (mức sống của một bộ phận cư dân). Thế nhưng bên trong nó đồng thời chứa “分居” (ly thân) và “民生” (dân sinh) — bản thân chúng cũng là những từ đúng. Nghĩa là chỉ tra từ điển thôi thì nhiều cách cắt cùng lúc đều hợp lệ.

Loại mơ hồ này đã được biết đến từ lâu trong nghiên cứu xử lý tiếng Trung, và được chia thành hai nhóm lớn: kiểu giao cắt, nơi các ứng viên cắt từ chồng lấn lên nhau, và kiểu tổ hợp, nơi gộp lại hay tách ra đều có nghĩa. Ví dụ tiêu biểu của nhóm sau là “才能” — đọc như một từ thì là “tài năng”, tách thành hai từ thì là “才 / 能” (có thế thì mới có thể). Cái nào đúng chỉ có ngữ cảnh trước sau mới quyết định được.

Công cụ phân tích hình thái đang làm gì

Các công cụ phân tách từ tiếng Trung như jieba giải quyết sự mơ hồ này bằng cách kết hợp đối chiếu từ điển với mô hình thống kê. Nói đại khái, trước tiên công cụ dùng từ điển tiền tố (prefix dictionary) để thu thập toàn bộ ứng viên từ có thể có trong chuỗi ký tự và dựng thành một đồ thị có hướng không chu trình (DAG), rồi dùng quy hoạch động để chọn ra đường đi có xác suất cao nhất. Với những từ không có trong từ điển (từ chưa đăng ký), công cụ dùng mô hình Markov ẩn (HMM) và thuật toán Viterbi để suy đoán vai trò của từng vị trí ký tự và tách ra thành từ.

Đây chính là điểm mấu chốt về mặt thực tiễn. Việc xử lý từ chưa đăng ký bị phó mặc cho thống kê đồng nghĩa với việc mã sản phẩm, tên linh kiện, tên thiết bị và các từ viết tắt nội bộ của công ty bạn, nếu để mặc, sẽ bị cắt sai với xác suất cao. Một chuỗi như “MX-3200型伺服压机” không có gì bảo đảm sẽ được giữ nguyên thành đơn vị có nghĩa nếu không được đưa vào từ điển người dùng.

jieba có cơ chế nạp từ điển người dùng, cho phép đăng ký kèm từ loại và tần suất. Các công cụ khác như pkuseg, HanLP, LTP cũng có cơ chế tương tự. Việc cần làm rất đơn giản — lập danh sách các danh từ riêng mà công ty sử dụng rồi đăng ký, chỉ vậy thôi. Cái khó không nằm ở kỹ thuật, mà ở chỗ quyết định ai lập danh sách và ai tiếp tục cập nhật nó.

Lớp từ hỏng thì kéo theo những gì

Cách cắt từ là nền móng của tìm kiếm, chia chunk, khớp từ khóa, phân loại và thống kê. Nền này lệch thì mọi thứ đặt lên trên đều lệch theo. Khi xây RAG thì ảnh hưởng đặc biệt lớn — nếu ranh giới chunk rơi vào giữa một từ, từ đó sẽ không còn lấy được bằng tìm kiếm nữa. Về bản thân việc xây dựng RAG, xin xem bài chi phí và cách triển khai RAG.

Lớp 3 lớp token — chuyện gì xảy ra khi token hóa tiếng Trung

Vì sao một chữ Hán không nhất thiết là một token

Các mô hình ngôn ngữ lớn chủ đạo hiện nay dùng tokenizer thuộc họ BPE (Byte Pair Encoding) ở mức byte. BPE lần lượt ghép các cặp chuỗi byte thường đứng cạnh nhau trong dữ liệu huấn luyện, rồi cố định các quy tắc ghép đó.

Ở đây có một đặc thù của tiếng Trung phát huy tác dụng. Trong UTF-8, một chữ Hán thông thường chiếm 3 byte. Do đó, nếu quy tắc ghép tương ứng với chữ Hán đó chưa được học đủ, một chữ Hán sẽ bị tách thành nhiều token. Ngược lại, với những từ hai chữ xuất hiện nhiều, quy tắc ghép có sẵn nên hai chữ có thể chỉ thành một token. Nói cách khác, cùng một tài liệu tiếng Trung với số ký tự như nhau, số token vẫn thay đổi theo tokenizer.

Các tokenizer thế hệ từ cl100k_base trở đi được cho là chứa nhiều từ vựng tiếng Trung hơn so với thế hệ trước, nhưng hiệu suất vẫn không bằng tiếng Anh. Ở những mô hình tuyên bố tăng cường hỗ trợ tiếng Trung, tokenizer có xu hướng chứa từ vựng tiếng Trung dày hơn nữa. Vì hệ số cụ thể thay đổi theo lĩnh vực tài liệu và tự dạng, cách chắc chắn duy nhất là tự đếm trên tài liệu thật của công ty mình. Trước hết hãy lấy vài tài liệu nội bộ tiêu biểu, cho chạy qua tokenizer của các mô hình ứng viên và đếm số token. Chỉ riêng việc này đã cải thiện đáng kể độ chính xác của bản dự toán chi phí hằng tháng và của thiết kế độ dài ngữ cảnh.

Hiện tượng ghép sai

Còn một hiện tượng nữa đã được báo cáo với tiếng Trung. Trong bài viết “To Merge or Not to Merge – The Pitfalls of Chinese Tokenization in General-Purpose LLMs” của The Digital Orientalist, khi đưa câu ví dụ “他是学科技的，他不相信神秘和超自然的事物” qua tokenizer của nhiều mô hình, người ta ghi nhận ở nhiều mô hình các trường hợp ghép thành một token những chuỗi không hề tồn tại như một từ (lỗi ghép “的事” được báo cáo ở các mô hình họ LLaMA), hoặc ghép bất chấp ngữ cảnh (lỗi ghép “他不” và “的事物” ở DeepSeek).

Nguyên nhân nằm ngay trong cơ chế của BPE. Vì BPE cố định các quy tắc ghép theo thứ tự tần suất xuất hiện trong dữ liệu huấn luyện, nên lúc suy luận nó không nhìn ngữ cảnh. Chỉ vì tần suất cao, nó áp dụng trước một phép ghép vốn sai xét theo ngữ cảnh. “的” là một trong những chữ xuất hiện nhiều nhất trong tiếng Trung, nên về mặt cấu trúc, quy tắc ghép nó với chữ đứng sau rất dễ xếp hạng cao.

Hàm ý thực tiễn tuy giới hạn nhưng cũng không thể bỏ qua. Khi ranh giới token lệch khỏi ranh giới ngữ nghĩa của từ, mô hình khó coi từ đó như một đơn vị nghĩa trọn vẹn. Đặc biệt với các ứng dụng xử lý số lượng lớn đoạn ngắn (chuẩn hóa tên hàng, phân loại câu ngắn, trích xuất từ khóa), ảnh hưởng này dễ lộ ra. Không nên chỉ vì điểm này mà quyết định chọn mô hình, nhưng nó đáng được ghi nhớ như một ứng viên nguyên nhân khi xử lý câu ngắn liên tục sinh lỗi khó hiểu.

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

Chỉnh xong lớp ký tự và lớp từ, ước lượng được chi phí và độ dài ngữ cảnh ở lớp token, khi đó mới đến chuyện chọn mô hình. Dưới đây là các mô hình chủ đạo thường được nhắc tới khi xử lý tiếng Trung ở thời điểm 2026. Ở đây chỉ ghi các xu hướng định tính. Vì điểm số benchmark công bố thay đổi rất lớn theo điều kiện đo, bài viết này không khẳng định hơn kém bằng con số cụ thể.

Bên cạnh đó, các mô hình tiên phong của Âu Mỹ cũng xử lý tiếng Trung ở mức cao. Với các ứng dụng phải đi lại giữa tiếng Nhật và tiếng Trung, chất lượng phía tiếng Nhật cũng bị đặt lên bàn cân cùng lúc, nên mô hình chuyên tiếng Trung không phải lúc nào cũng là lựa chọn tối ưu.

Điều cần nhìn khi chọn không phải là tổng điểm benchmark, mà là những điểm sau.

• Trên tài liệu của công ty bạn, chất lượng có như nhau với cả giản thể lẫn phồn thể không
• Khi được đưa bảng thuật ngữ, mô hình có giữ thuật ngữ đó đến cuối không (với tài liệu dài, có bị lệch từ giữa chừng không)
• Có tuân thủ định dạng đầu ra đã chỉ định không (bảng, JSON, cấu trúc tiêu đề cố định)
• Khi dịch từ tiếng Trung sang tiếng Nhật hoặc tiếng Việt, phía ngôn ngữ đích có tự nhiên theo cách nói của ngành chế tạo không
• Dữ liệu được xử lý ở đâu (liên quan trực tiếp đến vấn đề PDPA nói ở phần sau)

Và quan trọng nhất là công ty bạn phải tự có một bộ đánh giá để phán đoán những điều trên. Chọn từ 30 đến 50 tài liệu thật của công ty và tạo đáp án đúng bằng tay. Không có bộ này thì khi đổi mô hình, không ai nói được là tốt lên hay xấu đi.

Nhìn theo từng mục đích sử dụng — sửa lớp nào thì hiệu quả với dịch thuật, OCR tiếng Trung và chuẩn hóa tên

Chuyện lớp lang dễ trở nên trừu tượng, nên hãy quy về các mục đích cụ thể.

Cách đọc bảng rất đơn giản. Tìm mục đích đang phát sinh triệu chứng, rồi bắt tay từ “lớp chi phối” ở dòng đó. Cột ngoài cùng bên phải là những biện pháp hay được thử nhưng ít hiệu quả.

Nếu bạn muốn xây cơ chế tiếp nhận câu hỏi nội bộ bằng tiếng Trung, xin tham khảo thêm bài tự động hóa tiếp nhận câu hỏi nội bộ; còn nếu đưa ra ngoài dưới dạng chatbot đa ngôn ngữ thì xem bài chi phí và cách triển khai chatbot.

Ước tính riêng — chi phí và hiệu quả thay đổi thế nào theo từng kiểu triển khai

Từ đây là phần ước tính dựa trên một nhà máy mô hình giả định. Các con số về đầu tư xe điện và số lượng nhà cung cấp trích dẫn ở các phần trước là dữ liệu công bố có thật, nhưng toàn bộ số liệu dưới đây là giá trị mô hình được đặt ra để giải thích, không phải thành tích của một doanh nghiệp có thật. Chúng tôi ghi lại toàn bộ các bước tính để bạn có thể thay bằng số liệu của mình mà kiểm tra lại.

Thiết lập nhà máy mô hình

Khối lượng công việc cần xử lý bằng tiếng Trung và thời gian hiện tại (chỉ làm thủ công) như sau.

Chi phí hằng tháng hiện tại là 220 giờ × 600 THB = 132,000 THB.

Ba phương án cấu hình

Cấu hình A — dùng thẳng AI tạo sinh phổ thông (không sửa lớp nào)

Chỉ vận hành bằng giấy phép AI tạo sinh phổ thông sẵn có (3,000 THB/tháng), không đưa vào bảng thuật ngữ cũng không chuẩn hóa. Số thành phần là 1.

Cấu hình B — sửa lớp ký tự và lớp từ

Ngoài cấu hình A, còn triển khai từ điển đối chiếu giản thể / phồn thể / tiếng Nhật cho 1,200 thuật ngữ thiết bị, cùng bộ quy tắc chuẩn hóa giản phồn. Số thành phần là 3 (AI phổ thông, từ điển đối chiếu, quy tắc chuẩn hóa).

Cấu hình C — chạm vào cả 4 lớp

Ngoài cấu hình B, còn xây dựng template OCR cho chứng từ tiếng Trung, đo thực tế số token của các mô hình ứng viên rồi chọn ra mô hình ngôn ngữ lớn hỗ trợ tiếng Trung. Số thành phần là 5 (quy tắc chuẩn hóa, từ điển đối chiếu, OCR chứng từ, thiết kế token, LLM hỗ trợ tiếng Trung kèm bộ đánh giá). Ở cấu hình C, khoản giấy phép AI phổ thông 3,000 THB được thay bằng chi phí của LLM hỗ trợ tiếng Trung nên không tính trùng.

Thay đổi về thời gian

Việc đọc chứng từ không đổi ở cấu hình A và B là vì công việc này phụ thuộc vào phần triển khai OCR thuộc lớp 1, không rút ngắn được nhờ dùng AI phổ thông hay từ điển thuật ngữ. Ngược lại, ở cấu hình C nó giảm từ 9 phút xuống 3 phút vì có template OCR và hậu xử lý giản phồn nên thu hẹp được phạm vi phải kiểm tra bằng mắt.

Chi phí và hiệu quả

Chúng tôi gắn phần chi phí ban đầu vào từng lớp, phân bổ đến từng phút xem khoản chi nào tạo ra bao nhiêu thời gian tiết kiệm.

Phần tiết kiệm 56 giờ của cấu hình A là phần phát sinh chỉ nhờ giấy phép AI phổ thông với chi phí ban đầu bằng 0 (dịch 25 phút → 16 phút, email 12 phút → 8 phút). Hãy kiểm tra xem cách phân bổ ở bảng trên có khớp với thời gian tiết kiệm đã nêu hay không. Phần cấu hình B cộng thêm so với cấu hình A là 17 + 17 = 34 giờ, khớp với 90 − 56 = 34 giờ. Phần cấu hình C cộng thêm so với cấu hình B là 40 + 8 + 9 = 57 giờ, khớp với 147 − 90 = 57 giờ. Nghĩa là cắt bỏ dòng chi phí nào thì thời gian tiết kiệm ghi ở dòng đó cũng biến mất theo.

Chi tiết chi phí hằng tháng như sau.

Quy đổi thời gian tiết kiệm ra tiền và tính lợi ích ròng.

Điểm đáng đọc của bảng này là ở mốc 12 tháng, khoảng cách giữa ba cấu hình nhỏ hơn ta tưởng (367,200 / 403,200 / 439,200 THB). Khoảng cách chỉ giãn ra từ năm thứ hai, và ở mốc 24 tháng cấu hình C đạt khoảng 1.7 lần cấu hình A. Nếu trình cấu hình C lên một tờ phê duyệt lấy giả định thu hồi vốn trong một năm, về mặt con số nó sẽ trông yếu. An toàn hơn cả là chia sẻ trước rằng kết luận thay đổi tùy theo cách đặt thời hạn đánh giá.

Độ nhạy — trường hợp thời gian tiết kiệm chỉ đạt 70% so với dự kiến

Ước lượng về thời gian tiết kiệm là phần bất định nhất trong các giả định. Chúng tôi chỉ hạ riêng phần này xuống 70% và giữ nguyên chi phí để tính lại. Đơn giá 600 THB và các khoản chi phí được giữ nguyên như giả định ban đầu.

Thứ hạng ở mốc 12 tháng đảo ngược. Nếu hiệu quả chỉ đạt 70% so với dự kiến, tại mốc 12 tháng cấu hình A có lợi nhất còn cấu hình C xếp cuối. Phải nhìn đến mốc 24 tháng thì cấu hình C mới nhỉnh hơn cấu hình B một chút (603,360 so với 597,600 THB).

Kết quả này không có nghĩa là “nên bỏ cấu hình C”. Nó có nghĩa là phải kiểm chứng ở quy mô nhỏ xem thời gian tiết kiệm có thật sự đạt được hay không, trước khi chốt khoản đầu tư. Lộ trình 90 ngày nói ở phần sau được sắp xếp theo đúng thứ tự đặt việc kiểm chứng lên trước.

Những vấn đề phát sinh thêm tại cơ sở ở Thái Lan và ASEAN

PDPA và chuyển dữ liệu xuyên biên giới

Luật Bảo vệ Dữ liệu Cá nhân của Thái Lan (PDPA) đặt ra điều kiện khi chuyển dữ liệu cá nhân ra nước ngoài. Chứng từ tiếng Trung và email với đối tác thường chứa dữ liệu cá nhân như tên người phụ trách, thông tin liên hệ, chữ ký. Khi gửi những dữ liệu này tới API ở nước ngoài, bạn cần nắm được dữ liệu sẽ được xử lý bởi nhà cung cấp nào, ở quốc gia nào. Nếu chọn dịch vụ đặt trong lãnh thổ Trung Quốc để hỗ trợ tiếng Trung, ngoài PDPA của Thái Lan còn có các quy định pháp luật về dữ liệu phía Trung Quốc, nên hãy coi việc chọn nơi xử lý là quyết định pháp lý chứ không phải quyết định kỹ thuật.

Về biện pháp né tránh thực tế, có cách đưa vào bước tiền xử lý loại bỏ dữ liệu cá nhân trước khi gửi (thay tên người và thông tin liên hệ bằng ký tự che). Về mặt kỹ thuật thì không khó, nhưng điều kiện tiên quyết là phải thống nhất với bộ phận pháp chế về định nghĩa những mục nào cần loại bỏ.

Điều khoản ưu tiên ngôn ngữ trong hợp đồng và đặc tả

Trong hợp đồng với nhà cung cấp gốc Hoa, việc lập cả bản tiếng Trung lẫn bản tiếng Anh là chuyện thường gặp. Ở đây hãy kiểm tra xem có điều khoản quy định bản nào được ưu tiên (điều khoản ưu tiên ngôn ngữ) hay không. Nếu không có, khi cách hiểu hai bên khác nhau thì sẽ chẳng có căn cứ nào để dựa vào.

Trong bối cảnh AI tạo sinh, điều này phát huy tác dụng ở ranh giới quyết định xem tài liệu đã dịch có được coi là tài liệu tham chiếu chính thức trong nội bộ hay không. Bản tiếng Nhật do AI dịch, xét theo hợp đồng, chỉ là bản dịch tham khảo. Nếu dùng nó làm chỉ thị công việc hay tiêu chuẩn kiểm tra, cần thiết lập quy trình lưu lại hồ sơ ai đã kiểm tra và phê duyệt nội dung.

Lấy giản thể hay phồn thể làm bản chính

Đây là vấn đề thỏa thuận nội bộ chứ không phải kỹ thuật, nhưng ảnh hưởng lan ra toàn bộ lớp ký tự. Nếu nhà cung cấp đại lục chiếm đa số thì giản thể là tự nhiên, nếu bên Đài Loan chiếm đa số thì phồn thể là tự nhiên, nhưng điều quan trọng là phải chọn một trong hai. Chọn xong thì chuẩn hóa về tự dạng bản chính ngay khi nạp tài liệu, còn bản gốc thì lưu riêng như bản gốc. Vận hành theo cách này thì cả tìm kiếm lẫn thống kê đều không phân nhánh.

Nếu không quyết định và cứ để cả hai lẫn lộn trong vài năm, chi phí chuẩn hóa về sau sẽ tăng tỷ lệ thuận với khối lượng tài liệu. Đây là loại quyết định càng chốt sớm càng rẻ.

Lưu trữ tài liệu tiếng Trung và truy xuất nguồn gốc

Nếu bạn nhận hồ sơ chất lượng và phiếu kết quả kiểm tra bằng tiếng Trung, trong tình huống bị kiểm toán bạn sẽ bị hỏi “ai đã xác nhận nội dung của hồ sơ này”. Nếu có đi qua bản dịch bằng AI, hãy thiết kế sao cho lưu lại được quan hệ tương ứng giữa bản gốc (tiếng Trung) và bản dịch, người đã kiểm tra bản dịch, và ngày kiểm tra. Cách vận hành không lưu lịch sử dịch thuật thì sau này không thể dựng lại được.

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

Ngày 1 đến 30 — tập trung vào việc đếm

Giai đoạn này không triển khai gì cả. Chỉ đếm hiện trạng.

• Thu thập các tài liệu tiếng Trung đi vào theo từng loại, đếm số lượng và số trang mỗi tháng
• Phân loại nơi gửi là bên đại lục, Đài Loan hay Hồng Kông, nắm tình hình lẫn lộn tự dạng
• Đo thực tế thời gian đang bỏ ra cho việc xử lý hiện tại theo từng công việc (đo thực tế, không phải ước lượng)
• Trích ra khoảng 50 đến 100 thuật ngữ xuất hiện nhiều, lập bản nháp bảng đối chiếu giản thể, phồn thể và tiếng Nhật
• Cho 3 đến 5 tài liệu tiêu biểu chạy qua tokenizer của các mô hình ứng viên và đếm số token

Sản phẩm của 30 ngày này chính là bảng ước tính ở phần trước với các cột “khối lượng hằng tháng” và “thời gian mỗi đơn vị” đã được điền bằng số liệu của chính công ty bạn. Nếu chưa điền được chỗ này mà đã đi tiếp thì quyết định đầu tư không có căn cứ.

Ngày 31 đến 60 — kiểm chứng ở quy mô nhỏ

Xác nhận xem thời gian tiết kiệm có thật sự đạt được không, với khoản đầu tư tối thiểu.

• Lập từ điển tạm khoảng 50 thuật ngữ, áp dụng vào bản dịch thô rồi đo lại thời gian
• Áp dụng chuẩn hóa giản phồn cho đúng một loại tài liệu và xem cách tìm kiếm có thay đổi không
• Với OCR, thử làm template cho một loại chứng từ với khoảng 20 tờ và đo thời gian kiểm tra bằng mắt
• Chọn 30 tài liệu thật và tạo đáp án đúng bằng tay làm nguyên mẫu cho bộ đánh giá

Đến ngày thứ 60 này, bạn sẽ biết con số “70%” trong phân tích độ nhạy có thực tế không, hay hiệu quả còn cao hơn hoặc thấp hơn. Nếu ở đây con số không ra, bạn có thể quyết định thu hẹp phạm vi hoặc giới hạn lại nghiệp vụ mục tiêu.

Ngày 61 đến 90 — chốt phạm vi và cố định lại

• Quyết định tự dạng làm bản chính và ghi vào quy định quản lý tài liệu
• Quyết định người chịu trách nhiệm cập nhật từ điển thuật ngữ và tần suất cập nhật
• Thống nhất với pháp chế về phạm vi tiền xử lý dữ liệu cá nhân
• Dựa trên kết quả kiểm chứng, quyết định đi theo cấu hình A, B hay C
• Chốt phiên bản bộ đánh giá và quy định rằng mọi thay đổi mô hình về sau đều so sánh trên phiên bản này

Sản phẩm của ngày thứ 90 không phải là một hệ thống chạy được, mà là “những giả định đã được chốt”. Với tiếng Trung, càng nhiều thứ chưa được quyết định thì về sau càng tốn kém.

Những thất bại thường gặp và cách tránh

Bắt đầu từ việc chọn mô hình

Đây là thất bại phổ biến nhất. Nếu bắt đầu bằng việc tra cứu “LLM nào mạnh tiếng Trung”, bạn sẽ chỉ thay mỗi lớp 4 trong khi lớp ký tự và lớp từ vẫn hỏng. Các triệu chứng như thuật ngữ không nhất quán hay tìm kiếm không ra vẫn còn nguyên dù đổi mô hình, nên bạn sẽ nhảy qua nhảy lại nhiều lần và mất thời gian. Cách tránh là đối chiếu triệu chứng với bảng theo mục đích sử dụng ở trên để xác định lớp chi phối trước đã.

Triển khai chuyển đổi giản phồn bằng phép thay thế ký tự đơn giản

Nếu viết phép chuyển giản thể sang phồn thể bằng một bảng thay thế một đối một, bạn sẽ cố định “发” thành “發” và mọi từ liên quan đến tóc đều hỏng. Cách tránh là thống nhất chiều chuyển đổi theo một hướng về phía giản thể, hoặc dùng thư viện chuyển đổi có nhìn ngữ cảnh và loại danh từ riêng ra khỏi phạm vi chuyển đổi.

Lập từ điển thuật ngữ rồi ngừng cập nhật

Dù ban đầu có lập từ điển 1,200 thuật ngữ, khi thiết bị mới được đưa vào và nhà cung cấp mới xuất hiện thì từ điển sẽ lạc hậu. Từ điển là cơ chế cưỡng chế cách dịch, nên một từ điển không được cập nhật sẽ tiếp tục cưỡng chế những cách dịch cũ. Cách tránh là chốt người phụ trách và tần suất cập nhật ngay tại mốc ngày thứ 90. Bản ước tính đã dự trù 4 đến 6 giờ công bảo trì mỗi tháng, và đây không phải khoản có thể cắt.

Không lập bộ đánh giá mà cứ đi tiếp với cảm giác “hình như chính xác hơn rồi”

Không có bộ đánh giá thì không thể bàn luận việc đổi mô hình là tốt hay xấu. Ấn tượng của người phụ trách trở thành căn cứ, và không bàn giao được cho người kế nhiệm. Cách tránh là tạo đáp án đúng với khoảng 30 tài liệu thật cũng được, rồi cố định phiên bản. Ngay cả 30 tài liệu cũng khác một trời một vực so với không có gì.

Xử lý tài liệu từ Đài Loan và Hồng Kông bằng thiết lập dành cho đại lục

Vì không chỉ tự dạng mà cả từ vựng cũng khác, từ điển đồng nghĩa làm cho đại lục sẽ không tìm ra tài liệu Đài Loan. Cách tránh là để từ điển có cột đối chiếu giữa từ vựng đại lục và từ vựng Đài Loan. Bảng đối chiếu thuật ngữ ở trên chính là dạng tối giản của việc này.

Bắt đầu gửi dữ liệu lên API khi chưa quyết định cách xử lý dữ liệu cá nhân

Đôi khi vì lý do “chỉ là PoC thôi” mà việc ném thẳng email của đối tác thật lên API bên ngoài đã trở thành thói quen vận hành. Cách tránh là đưa bước tiền xử lý dữ liệu cá nhân vào ngay từ giai đoạn kiểm chứng, hoặc chỉ dùng những tài liệu không chứa dữ liệu cá nhân để kiểm chứng.

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

AI tạo sinh tiếng Trung là chỉ cái gì

Nó chỉ toàn bộ việc sử dụng AI tạo sinh có văn bản tiếng Trung ở đầu vào hoặc đầu ra. Nó không đồng nghĩa với việc dùng mô hình do Trung Quốc phát triển. Trường hợp xử lý tiếng Trung bằng các mô hình tiên phong của Âu Mỹ cũng được tính vào. Bài viết này sắp xếp vấn đề theo góc nhìn tiếng Trung hỏng ở lớp xử lý nào, chứ không theo xuất xứ của mô hình.

OCR tiếng Trung đạt độ chính xác khoảng bao nhiêu

OCR tiếng Trung đang ngày càng chính xác với cả giản thể lẫn phồn thể, và nhiều bài phân tích kỹ thuật cho biết đã xuất hiện những hệ thống đạt tỷ lệ nhận dạng vượt 95%. Tuy nhiên, vì phồn thể có tự dạng phức tạp hơn giản thể nên rủi ro nhận dạng sai được cho là tương đối cao hơn. Ngoài ra, loại con số này chịu ảnh hưởng rất lớn từ chất lượng in, phông chữ, bố cục và độ phân giải khi quét, nên chúng tôi khuyến nghị đo thực tế trên chứng từ của chính công ty bạn. Trong thực tế, thiết kế xem phát hiện lỗi ở đâu khi lỗi xảy ra còn quan trọng hơn bản thân tỷ lệ nhận dạng.

Giản thể và phồn thể có thể để AI chuyển đổi là xong không

Không xong. Vì một chữ giản thể có thể tương ứng với nhiều chữ phồn thể, và chọn chữ nào lại do ngữ cảnh quyết định. Chuyển từ giản thể sang phồn thể rất dễ sinh lỗi, chiều ngược lại an toàn hơn. Trong thực tế, cách vận hành ổn định nhất là chọn một tự dạng làm bản chính và chuẩn hóa về đó ngay khi nạp tài liệu.

Có nên chọn mô hình do Trung Quốc phát triển làm mô hình ngôn ngữ lớn tiếng Trung không

Tùy vào mục đích sử dụng và cách xử lý dữ liệu. Nếu chỉ làm việc với tiếng Trung và sự tự nhiên ở các chi tiết tiếng Trung là quan trọng, có những tình huống mô hình Trung Quốc chiếm ưu thế. Ngược lại, với các ứng dụng đi lại giữa tiếng Nhật và tiếng Trung thì chất lượng phía tiếng Nhật cũng bị đặt lên bàn cân, còn nếu xử lý dữ liệu cá nhân tại cơ sở Thái Lan thì vấn đề PDPA và nơi xử lý phải được xét trước. Đừng quyết chỉ bằng tổng điểm benchmark, hãy so sánh trên bộ đánh giá của chính công ty bạn.

Chứng từ tiếng Trung của chúng tôi đang lẫn lộn giản thể và phồn thể, nên bắt đầu từ đâu

Trước hết hãy quyết định lấy tự dạng nào làm bản chính. Trên cơ sở đó, đưa vào bước chuẩn hóa về tự dạng bản chính ngay khi nạp tài liệu. Chỉ hai việc này thôi đã giảm đáng kể tình trạng bỏ sót khi tìm kiếm và tính trùng khi thống kê. Việc xây dựng template OCR có thể để sau.

Tổng kết

Những lời than phiền rằng AI tạo sinh không chính xác với tiếng Trung, trong đa số trường hợp, không phải là vấn đề của mô hình. Giản thể và phồn thể không tương ứng một đối một, cùng một mã Unicode nhưng tự dạng khác nhau theo vùng, không có dấu cách nên cách cắt từ mơ hồ về mặt cấu trúc, và BPE cố định quy tắc ghép mà không nhìn ngữ cảnh. Những chuyện này xảy ra ở lớp ký tự, lớp từ và lớp token, nên có đổi mô hình ở lớp 4 cũng không mất đi.

Với nhà máy Nhật tại Thái Lan, tiếng Trung không phải là ngôn ngữ được chọn để đưa vào, mà là ngôn ngữ tự đi vào thông qua chuỗi cung ứng xe điện và thiết bị sản xuất tại Trung Quốc. Chính vì vậy, thiết kế theo hướng làm cho những người phụ trách hiện có xử lý được thông tin gốc bằng tiếng Trung sẽ đáng giá hơn hướng tăng nhân sự chuyên trách.

Như đã thấy trong phần ước tính, cấu hình chạm vào cả 4 lớp tạo ra hiệu quả lớn nhất, nhưng khoảng cách trong năm đầu là nhỏ và thứ hạng sẽ đảo ngược nếu hiệu quả thấp hơn dự kiến. Vì thế, 90 ngày đầu tiên hãy dùng cho việc đếm và kiểm chứng ở quy mô nhỏ, chứ không phải để triển khai. Những thứ cần chốt là tự dạng bản chính, người chịu trách nhiệm cập nhật từ điển, phạm vi tiền xử lý dữ liệu cá nhân, và phiên bản bộ đánh giá. Chốt được bốn thứ này rồi thì đi theo cấu hình nào cũng sẽ không lệch quá xa.

Về việc trao đổi ở giai đoạn cân nhắc

Vấn đề độ chính xác AI tiếng Trung có thể bắt đầu được xử lý từ chỗ tách bạch xem nó đang xảy ra ở lớp nào. Bạn muốn thử xem tài liệu hướng dẫn thiết bị Trung Quốc hay chứng từ tiếng Trung của mình đang hỏng ở lớp nào, muốn sắp xếp lại xem nên chuẩn hóa giản phồn đến đâu, hay chỉ muốn trao đổi riêng về cách xây bộ đánh giá — ở giai đoạn còn đang cân nhắc cũng hoàn toàn được. Xin liên hệ với chúng tôi qua trang liên hệ.

Tài liệu tham khảo

• Thailand Secures $4.1 Billion in EV Chain Investments as Southeast Asia Auto Hub Pivots to Next-Gen Tech – Thailand Board of Investment — Công bố chính thức về tổng vốn đầu tư tuyên bố 4.1 tỷ USD vào chuỗi cung ứng xe điện Thái Lan, 198 dự án, sản xuất BEV 18 dự án với 1.18 tỷ USD và công suất vượt 370,000 xe mỗi năm (ngày 3 tháng 7 năm 2026)
• Thailand approves Sunwoda to invest $1B in EV battery cell plants – TechNode Global — Bản tin về việc phê duyệt khoản đầu tư của Sunwoda Electronic vào sản xuất cell pin (ngày 17 tháng 3 năm 2025)
• Kịch bản tiến vào Thái Lan và ASEAN của các nhà cung cấp gốc Hoa – THAIBIZ — Phân tích với các số liệu 183 trường hợp nhà cung cấp gốc Hoa vào Thái Lan, 125 trường hợp thuộc nhóm gia công chế tạo, và 90 trường hợp mới từ 2023 đến tháng 6 năm 2025 (thuộc hệ Viện Nghiên cứu Tổng hợp Nomura, tháng 2 năm 2026)
• To Merge or Not to Merge – The Pitfalls of Chinese Tokenization in General-Purpose LLMs – The Digital Orientalist — Các ví dụ thực tế về ghép sai tiếng Trung trong tokenizer của LLM phổ thông và giải thích nguyên nhân bắt nguồn từ BPE (ngày 4 tháng 2 năm 2025)
• jieba – Chinese text segmentation — Phần triển khai từ điển tiền tố, đồ thị có hướng không chu trình (DAG), quy hoạch động, xử lý từ chưa đăng ký bằng HMM và Viterbi, cùng cách đăng ký từ điển người dùng
• China LLM Guide 2026 – Top Chinese LLMs Compared – Swift Horse AI — So sánh xu hướng theo mục đích sử dụng của các LLM Trung Quốc, tập trung vào DeepSeek, Qwen, Kimi và GLM (tháng 6 năm 2026)
• Parsing Through Boundaries in Chinese Word Segmentation – arXiv — Nghiên cứu về ảnh hưởng của cách đặt ranh giới phân tách từ tiếng Trung đối với các bước phân tích phía sau (tháng 3 năm 2025)
• Bộ dữ liệu Maximum Overlapping Ambiguous String – Nhóm Xử lý Ngôn ngữ Tự nhiên Đại học Thanh Hoa — Bộ dữ liệu đánh giá phân tách từ tiếng Trung tập hợp các trường hợp mơ hồ kiểu giao cắt
• Personal Data Protection Act B.E. 2562 – Office of the Personal Data Protection Committee Thailand — Văn bản luật bảo vệ dữ liệu cá nhân của Thái Lan
• Cross-border personal data transfer under Section 29 – Office of the Personal Data Protection Committee Thailand — Các yêu cầu đối với việc chuyển dữ liệu xuyên biên giới dựa trên biện pháp bảo vệ thích hợp