Tự động hóa dịch thuật doanh nghiệp 2026 — chia tài liệu thành 4 lớp

Khi doanh nghiệp bắt tay vào tự động hóa dịch thuật, mọi thứ thường mắc kẹt ở đúng một chỗ. Đổi engine cũng vậy, mài giũa prompt cũng vậy, phản hồi từ hiện trường vẫn là “bản dịch không nhất quán”. Nguyên nhân không nằm ở độ chính xác mà nằm ở thiết kế. Chừng nào toàn bộ tài liệu nội bộ còn được đổ vào một đường ống duy nhất, thì tài liệu kiểm soát và báo cáo hằng ngày sẽ bị đối xử như nhau, và không ai còn phán đoán được có thể giao tới đâu cho máy. Bài viết này trình bày cách chia tài liệu thành 4 lớp và tổ chức lại quy trình theo 3 tầng — thuật ngữ, sinh dịch, phê duyệt — lấy nhà máy Nhật tại Thái Lan làm ví dụ minh họa xuyên suốt.

Vì sao tự động hóa dịch thuật doanh nghiệp thường dừng lại giữa chừng

Tại các nhà máy Nhật đặt cơ sở ở Thái Lan và Việt Nam, ba ngôn ngữ tiếng Nhật, tiếng Thái và tiếng Anh — có nơi cộng thêm tiếng Việt hoặc tiếng Trung thành bốn đến năm ngôn ngữ — lưu chuyển hằng ngày. Thông báo kỹ thuật từ trụ sở, hướng dẫn công việc tại chỗ, trả lời audit khách hàng, báo cáo sản xuất mỗi ngày. Tất cả đều phát sinh nhu cầu dịch, và phần lớn đang được xử lý bằng giờ làm thêm của một ai đó.

Ngộ nhận “đổi engine là xong”

Khi việc dịch bị ùn ứ, thứ được xem xét đầu tiên thường là thay engine dịch. Từ máy dịch truyền thống chuyển sang dịch dựa trên LLM, hoặc từ LLM đa dụng chuyển sang dịch vụ chuyên dịch thuật. Nhưng sau khi thay engine, phàn nàn từ hiện trường gần như không đổi.

Lý do rất đơn giản: nội dung phàn nàn không phải “dịch dở” mà là “dịch không khớp nhau”. Tháng trước, trong hướng dẫn công việc, “đổi mẫu sản xuất” được dịch là “การเปลี่ยนรุ่น”, nhưng ở bản sửa đổi tháng này lại thành một từ khác. Cùng một tên thiết bị được gọi mỗi tài liệu một kiểu. Hiện tượng này gọi là sai lệch thuật ngữ (terminology drift), và nó phát sinh một cách có cấu trúc chừng nào LLM đa dụng còn được dùng mà không có ngữ cảnh. LLM lần nào cũng sinh ra một cách dịch nghe hợp lý, nhưng nó không ghi nhớ “lần trước đã dịch thế nào”.

Các đánh giá tính đến năm 2026 cũng cho thấy phạm vi mà máy dịch xử lý được đã mở rộng rõ rệt, song vẫn chưa đạt mức có thể loại bỏ phán đoán của con người khỏi hoạt động bản địa hóa của doanh nghiệp. Một kết quả so sánh cho thấy dịch bằng LLM trong điều kiện không được cấp thông tin ngữ cảnh chỉ được đánh giá là “tốt” với tỷ lệ 55,7–80% tùy cặp ngôn ngữ. Cần lưu ý đây là con số cho các cặp ngôn ngữ châu Âu như Anh sang Đức, Ba Lan, Nga; với cặp Nhật sang Thái hoặc Nhật sang Việt như đối tượng của bài viết này, do chênh lệch về khối lượng dữ liệu huấn luyện, nên giả định con số sẽ thấp hơn. Ngay cả khi lấy con số của các cặp ngôn ngữ châu Âu, vẫn có 20% đến 40% không đạt mức “tốt”. Và không thể biết trước 20% nào sẽ trượt.

Sự đổ vỡ do “một đường ống duy nhất” tạo ra

Cấu hình mà phần lớn doanh nghiệp dựng đầu tiên là gom toàn bộ tài liệu nội bộ vào một luồng dịch thuật duy nhất. Nạp file vào thì nhận bản dịch ra. Thoạt nhìn có vẻ hiệu quả, nhưng cấu hình này chứa một sự lẫn lộn tiền đề chí mạng.

Nếu đẩy hướng dẫn công việc và email nội bộ qua cùng một quy trình, một trong hai điều sau sẽ xảy ra. Nếu đặt tiêu chuẩn chất lượng theo hướng dẫn công việc, thì dịch một email cũng phải qua luồng phê duyệt, và rốt cuộc không ai dùng. Nếu đặt tiêu chuẩn theo email, thì hướng dẫn công việc ra tới hiện trường mà chưa được kiểm chứng, và sẽ bị nêu trong audit. Nếu cố chọn mức trung dung, kết quả là một cách vận hành nửa vời không thỏa mãn bên nào.

Tự động hóa dịch thuật doanh nghiệp thất bại không phải vì độ chính xác của engine chưa đủ. Nó thất bại vì doanh nghiệp cố dùng một cấu hình duy nhất để quy định “phạm vi được phép giao cho máy” — thứ lẽ ra phải khác nhau theo từng loại tài liệu.

Chuyển đơn vị phán đoán sang “lớp tài liệu”

Hướng giải quyết rất rõ: chuyển đơn vị phán đoán từ “công cụ” sang “lớp tài liệu”. Không phải hỏi dùng engine nào, mà quyết trước rằng tài liệu này thuộc lớp nào, ở lớp đó giao tới đâu cho máy và từ đâu thì con người ký tên. Việc chọn engine để sau cũng được. Thậm chí dùng engine khác nhau cho từng lớp cũng chẳng có vấn đề gì.

Chia tài liệu nội bộ thành 4 lớp

Bốn nhóm dưới đây được tách ra từ những tài liệu thực tế đang lưu chuyển trong nhà máy Nhật tại Thái Lan, dựa trên tiêu chí “khi dịch sai thì cái gì hỏng”. Chi tiết sẽ thay đổi theo ngành, nhưng bốn nhóm này bao phủ được phần lớn.

Lớp A Tài liệu kiểm soát — AI chỉ làm tới bản dịch thô

Đây là nhóm tài liệu nằm trong phạm vi quản lý của ISO 9001. Điều khoản 7.5 “Thông tin dạng văn bản” yêu cầu tài liệu phải sẵn có và phù hợp để sử dụng khi cần, phải nhận biết được và được bảo vệ đầy đủ khỏi những thay đổi ngoài ý muốn. Tài liệu kiểm soát được ban hành sau khi qua rà soát và phê duyệt chính thức, việc phân phối và lưu trữ đều được quản lý.

Ở đây, dịch không nhất quán không chỉ dừng ở chuyện khó đọc. Nếu bản hướng dẫn công việc tiếng Nhật và bản tiếng Thái diễn đạt khác nhau về lực siết, doanh nghiệp sẽ bị hỏi trong audit rằng bản nào mới là bản đúng. Bộ thuật ngữ (thuật ngữ đã phê duyệt) và bộ nhớ dịch thuật (các câu dịch đã được phê duyệt) được xem là tạo thành “tầng từ vựng được kiểm soát” trong bối cảnh tuân thủ, và chuyên gia đánh giá kỳ vọng chúng được văn bản hóa. Nói cách khác, việc quản lý thuật ngữ vừa là công cụ nâng chất lượng, vừa là bằng chứng phải trình ra khi audit.

Ở lớp này, thứ có thể giao cho AI chỉ dừng ở bản dịch thô. Sinh bản dịch thô rất nhanh, và việc con người sửa từ đó rõ ràng nhanh hơn dịch từ trang giấy trắng. Nhưng chữ ký phê duyệt phải do con người thực hiện, và phải lưu lại ai đã phê duyệt phiên bản nào vào lúc nào.

Lớp B Tài liệu vận hành — tự động hoàn toàn là được

Báo cáo ngày, thông báo nội bộ, biên bản cuộc họp, email. Lớp này có chi phí sai sót thấp, và bản thân tốc độ chính là giá trị. Người đọc đang nắm ngữ cảnh ngay tại chỗ, nên dù bản dịch có hơi thiếu tự nhiên thì ý vẫn tới. Không hiểu thì hỏi lại là xong.

Đây chính là mảng mà AI tạo biên bản cuộc họp và AI chuyển giọng nói thành văn bản phát huy hiệu quả nhất. Trong một cuộc họp có cả quản lý người Nhật và nhân viên người Thái, tiếng Nhật và tiếng Thái đan xen liên tục. Trước đây phải có người ghi chép tay rồi sau đó dựng lại bản hai thứ tiếng. Với AI tạo biên bản cuộc họp, có thể xử lý liền mạch từ chuyển giọng nói thành văn bản, trích xuất các quyết định cùng người phụ trách và thời hạn, cho tới xuất ra bản song ngữ. Đây cũng là lớp dễ đọc hiệu quả đầu tư nhất.

Việc cân nhắc đưa AI soạn tài liệu và AI tự động tạo báo cáo vào sử dụng cũng nên bắt đầu từ lớp này. Báo cáo sản xuất định kỳ và bản tóm tắt tháng có mẫu cố định, còn số liệu thì lấy được từ hệ thống. Dù tự động hóa đồng thời cả việc sinh văn bản lẫn dịch thuật, thiệt hại khi thất bại vẫn nằm trong giới hạn.

“Tự động hoàn toàn là được” không đồng nghĩa với “không cần ai xem”. Mỗi tháng rút vài bản ra đọc, chỉ để kiểm tra xem có lỗi dịch nào làm đổi ý hay không. Mục đích không phải đảm bảo chất lượng, mà là một cảm biến để phát hiện suy giảm khi thay engine hoặc đổi cấu hình. Mỗi bản mất vài phút là đủ.

Lớp C Tài liệu đối ngoại — dùng AI để kiểm tra nhất quán, không phải để dịch

Tài liệu gửi khách hàng, trả lời audit, hợp đồng, thư trả lời khiếu nại. Vì dịch sai dẫn thẳng tới quan hệ giao dịch và trách nhiệm pháp lý, nên tránh giao bản thân việc dịch cho máy.

Nhưng điều đó không có nghĩa là không dùng AI. Chỗ dùng khác đi. Với tài liệu do người dịch, hãy để AI dịch ngược rồi đối chiếu với bản tiếng Nhật gốc, phát hiện các số liệu, mã model, ngày tháng bị chép sót, kiểm tra xem có lẫn từ nào trái với bộ thuật ngữ nội bộ hay không. Những khâu kiểm tra tính nhất quán như vậy là sở trường của máy, và cũng đúng là phần mà người rà soát dễ bỏ sót. Xét trên góc độ ứng dụng AI dịch thuật cho doanh nghiệp thì đây là cách dùng khá thầm lặng, nhưng hiệu quả giảm sự cố lại rất lớn.

Lớp D Chữ hiển thị tại hiện trường — đây là thiết kế, không phải dịch thuật

Lớp dễ bị bỏ quên nhất chính là lớp này. Nhãn nút trên màn hình HMI, thông điệp trên bảng andon, tiêu đề cột của biểu mẫu, cảnh báo trên thiết bị poka-yoke. Chúng bị ràng buộc ngặt nghèo về số ký tự và bề rộng hiển thị.

Một dòng hiển thị gói gọn trong bốn ký tự tiếng Nhật với nghĩa “dừng do bất thường” sẽ dài ra đáng kể khi sang tiếng Thái: “หยุดเนื่องจากความผิดปกติ”. Tiếng Việt cũng không khá hơn — “Dừng do bất thường” chiếm nhiều bề rộng hơn hẳn bản tiếng Nhật. Nếu đẩy qua quy trình dịch hiện có, thứ nhận lại sẽ là bản dịch đúng ngữ pháp nhưng tràn khỏi màn hình. Hiện trường rốt cuộc phải tự tay rút gọn, và vì kết quả rút gọn đó không quay về bộ thuật ngữ nên lần cải tiến sau lại lặp lại đúng chuyện cũ.

Chữ hiển thị tại hiện trường phải được tách khỏi quy trình dịch và xử lý như một phần của thiết kế màn hình. Hãy quy định trước số ký tự hiển thị được như một yêu cầu kỹ thuật, rồi soạn nội dung từng ngôn ngữ trong ràng buộc đó. Người quyết định không phải biên dịch viên, mà là người hiểu hiện trường. Nếu đẩy tự động hóa mà không tách bạch chỗ này, việc sửa tay chữ hiển thị sẽ kéo dài mãi, dẫn tới đánh giá “tự động hóa rồi mà chẳng nhẹ đi chút nào”.

Thiết kế 3 tầng để chặn sai lệch thuật ngữ

Nếu việc phân lớp là phán đoán “giao cái gì tới đâu”, thì thiết kế 3 tầng là phương án triển khai “lắp ráp thế nào”. Hãy tách bạch ba tầng: tầng thuật ngữ, tầng sinh dịch và tầng phê duyệt.

Tầng 1 Tầng thuật ngữ — bộ thuật ngữ và bộ nhớ dịch thuật

Đặt ở dưới cùng là bộ thuật ngữ (Term Base) và bộ nhớ dịch thuật (Translation Memory). Bộ thuật ngữ là từ điển cố định “từ này dịch như thế này” ở cấp độ từ; bộ nhớ dịch thuật là kho tích lũy ở cấp độ câu, ghi lại “câu này trước đây đã được dịch thế này và đã phê duyệt”.

Thiếu tầng này thì dù dùng LLM giỏi đến đâu, cùng một từ vẫn ra bản dịch khác nhau mỗi lần. Ngược lại, có tầng này thì dù thay engine ở tầng sinh dịch, tính nhất quán của thuật ngữ vẫn được giữ. Engine thay thế hệ sau vài năm, còn bộ thuật ngữ ở lại như một tài sản. Thứ cần đầu tư trước không phải engine, mà là tầng thuật ngữ.

Những từ cần đăng ký gồm: từ riêng của công ty, tên sản phẩm, tên công đoạn, tên thiết bị, tên phòng ban, tên biểu mẫu, thuật ngữ chất lượng. Về số lượng, bắt đầu từ khoảng 200 từ là đủ. Thay vì nhắm bao phủ toàn bộ ngay từ đầu rồi bỏ dở, hãy khởi động vận hành với 200 từ thường gặp và bổ sung mỗi khi phát hiện sai lệch — cách đó bền hơn.

Tầng 2 Tầng sinh dịch — LLM và việc bơm ngữ cảnh nội bộ

Tầng giữa là nơi thực sự tạo ra bản dịch. LLM được dùng ở đây, nhưng không phải ném thẳng vào LLM trần, mà truyền kèm bộ thuật ngữ, các bản dịch đã phê duyệt trước đây, cùng ngữ cảnh của công đoạn mà tài liệu thuộc về. Dạng chuẩn là dựng cấu hình sinh tăng cường truy xuất (RAG) để mô hình tham chiếu các bản dịch đã được phê duyệt.

Việc bơm ngữ cảnh nội bộ như thế nào có rất nhiều điểm mấu chốt về mặt triển khai. Chọn tài liệu nào làm phạm vi truy xuất, tài liệu có nhiều phiên bản thì lấy bản nào làm bản chính, tài liệu mật cao thì tách ra sao. Cách tư duy quanh những điểm này được xử lý trong bài Chi phí và cách triển khai RAG, nên hãy tham khảo khi bước vào giai đoạn thiết kế tầng sinh dịch.

Đổi mô hình theo mục đích sử dụng cũng là cách làm hiệu quả. Đã có kết quả so sánh cho thấy mô hình phù hợp với bản địa hóa tài liệu kỹ thuật và mã nguồn khác với mô hình phù hợp cho dịch marketing đậm màu thương hiệu. Tài liệu nhà máy nghiêng về nhóm thứ nhất, nhưng tài liệu giới thiệu công ty dùng đối ngoại lại mang tính chất của nhóm thứ hai. Đừng cố gánh tất cả bằng một mô hình duy nhất.

Tầng 3 Tầng phê duyệt — quản lý phiên bản và chữ ký phê duyệt

Tầng trên cùng là phê duyệt. Ghi lại ai đã phê duyệt phiên bản nào vào lúc nào, và tạo ra trạng thái chỉ những phiên bản đã phê duyệt mới được phân phối tới hiện trường. Đặt dưới sự quản lý của điều khoản 7.5 ISO 9001, cụ thể chính là triển khai tầng này.

Có bốn thứ cần chốt ở tầng phê duyệt.

• Ai là người phê duyệt (lớp A là trưởng bộ phận đảm bảo chất lượng, lớp C là trưởng phòng — định nghĩa riêng theo từng lớp)
• Lấy gì làm căn cứ phê duyệt (chữ ký điện tử, bản ghi phê duyệt trên công cụ workflow, hay đóng dấu trên giấy)
• Xử lý phiên bản cũ ra sao (thu hồi khỏi hiện trường, hay vô hiệu hóa trên hệ thống)
• Trả bản dịch đã phê duyệt về tầng thuật ngữ bằng cách nào (không thiết kế chỗ này thì 3 tầng không khép vòng)

Điểm thứ tư đặc biệt quan trọng. Nếu bản dịch đã phê duyệt không quay về bộ nhớ dịch thuật, lần sau con người sẽ lại phải sửa đúng chỗ đó. Thiết kế 3 tầng không phải luồng một chiều từ tầng thuật ngữ lên tầng phê duyệt; nó chỉ vận hành được khi có vòng tuần hoàn đưa bản dịch từ tầng phê duyệt trở về tầng thuật ngữ.

Ý nghĩa của việc giữ 3 tầng ở dạng sơ đồ

Cấu trúc 3 tầng này còn hữu dụng như một công cụ giải thích nội bộ. Nói “chúng tôi sẽ tự động hóa dịch thuật bằng AI” thì ban lãnh đạo sẽ hỏi “ai đảm bảo chất lượng”, còn hiện trường sẽ phản ứng “lại thêm công cụ mới à”. Đưa sơ đồ 3 tầng ra và giải thích rằng tầng phê duyệt do con người nắm, tầng thuật ngữ đăng ký đúng cách gọi của hiện trường, thì đối tượng thảo luận trở nên cụ thể. Sự đồng thuận khi triển khai tiến lên nhờ giải thích ranh giới trách nhiệm, chứ không nhờ giải thích công nghệ.

Thay KPI “độ chính xác 99%” bằng TTE

Kiểu thất bại điển hình của một dự án tự động hóa dịch thuật là đặt KPI theo tỷ lệ phần trăm độ chính xác của bản dịch.

Con số % độ chính xác không phản ánh tải của quy trình

Nghe “độ chính xác 95%” thì thấy có vẻ đủ, nhưng trong thực tế nó vô nghĩa. Nếu một tài liệu có 100 câu và 5 câu sai, thì để tìm ra 5 câu đó, con người phải đọc cả 100 câu. Thời gian đọc gần như không giảm khi độ chính xác tăng. Kể cả đạt 99%, chừng nào chưa biết câu nào là câu sai thì vẫn phải rà toàn văn.

Tệ hơn nữa, lỗi của bản dịch LLM không xuất hiện dưới dạng “sai một cách lộ liễu”. Trong một bản dịch trôi chảy và tự nhiên, chỉ riêng thuật ngữ bị thay bằng từ khác. Vì không có sự gượng gạo như máy dịch thế hệ cũ, nên càng dễ bỏ sót. Con số độ chính xác càng cao, sự căng thẳng của người kiểm tra càng giảm, và tỷ lệ bỏ sót càng tăng.

TTE (Time to Edit) là gì

Chỉ số nên đặt thay vào đó là TTE (Time to Edit). Đo thời gian thực tế để con người sửa bản dịch máy đạt tới mức dùng được. Trong các đánh giá máy dịch năm 2026, TTE được định nghĩa là thời gian mà biên dịch viên chuyên nghiệp cần để nâng đầu ra của máy dịch lên chất lượng của con người, và được xem là chỉ số phù hợp để đo hiệu quả triển khai trong môi trường thực tế. Công việc thật sự giảm đi hay chỉ dịch chuyển xuống hạ nguồn — không đo thời gian này thì không biết được.

Cách đo rất đơn giản. Với cùng một tài liệu, so sánh thời gian con người dịch từ đầu với thời gian con người sửa bản dịch thô của máy. Nếu vế sau ngắn hơn rõ rệt thì tự động hóa đang có tác dụng. Nếu gần bằng hoặc dài hơn, thì ở lớp tài liệu đó tự động hóa chưa vận hành được.

Lưu ý khi đo TTE

TTE phải được đo tách riêng theo từng lớp tài liệu. Nếu toàn bộ lớp B giảm được 80% TTE nhưng lớp A giảm bằng không, thì hoặc phải đưa lớp A ra khỏi phạm vi tự động hóa, hoặc tầng thuật ngữ chưa được chuẩn bị đủ. Nhìn vào bình quân toàn bộ thì không đưa ra được phán đoán này.

Một điểm nữa: TTE chịu ảnh hưởng của “độ thành thạo của người sửa”. Ngay sau khi triển khai, chưa ai quen cách sửa nên TTE sẽ dài hơn thực lực. Đừng phán đoán bằng số liệu của tháng đầu tiên; hãy nhìn diễn biến trong khoảng ba tháng. Ngược lại, mảng nào sau ba tháng mà TTE vẫn không giảm thì đó không phải vấn đề làm quen của con người, mà là vấn đề thiết kế.

Những chỗ dễ vỡ trong tiếng Thái và tiếng Việt

Bỏ qua đặc thù riêng của từng ngôn ngữ thì dù thiết kế đúng, hệ thống vẫn không chạy được ở hiện trường. Dưới đây là những điểm cần đặc biệt chú ý trong khu vực ASEAN.

Tiếng Thái — tách từ sai làm hỏng cả bản dịch

Tiếng Thái không đặt khoảng trắng giữa các từ. Do đó, khi máy xử lý, trước tiên phải phán đoán cắt chuỗi ký tự thành từ ở đâu (word segmentation). Sai ở khâu này thì toàn bộ bản dịch phía sau đổ theo.

Danh từ riêng, từ tự chế trong nội bộ, hay các từ katakana tiếng Nhật được phiên âm sang chữ Thái đều không có trong từ điển nên rất dễ bị cắt sai. Trường hợp điển hình là khi các thuật ngữ sản xuất như “poka-yoke”, “andon”, “kanban” được viết bằng chữ Thái. Đăng ký chúng vào bộ thuật ngữ vì thế mang ý nghĩa lớn hơn nhiều so với việc chỉ thống nhất cách dịch.

Sự bất đối xứng giữa số token và chi phí API

Bộ tách token của các LLM đa ngôn ngữ có hiệu suất khác nhau tùy ngôn ngữ. Đã có ghi nhận rằng cùng một nội dung, chữ Thái dễ sinh ra nhiều token hơn tiếng Anh. Vì API tính tiền theo token, chênh lệch này chuyển thẳng thành chênh lệch chi phí. Tiếng Nhật cũng bất lợi hơn tiếng Anh, nên khoảng cách với tiếng Thái không lớn như khi lấy tiếng Anh làm chuẩn — nhưng nếu xuất phát từ đơn giá tính trên tiếng Anh thì sẽ đọc sai con số.

Nếu dùng đơn giá gốc tiếng Anh ở giai đoạn lập dự toán, thì đến khi chuyển sang vận hành tiếng Thái, chi phí sẽ vượt dự kiến. Ở giai đoạn ước tính, nên chạy thử mẫu thật bằng chính ngôn ngữ đích, đo số token thực tế rồi mới đặt đơn giá. Doanh nghiệp có khối lượng dịch càng lớn thì chênh lệch này càng đạt quy mô không thể bỏ qua.

Ngoài ra, việc đánh giá LLM cho các ngôn ngữ Đông Nam Á, trong đó có tiếng Thái, những năm gần đây đã được xây dựng khá bài bản: bên cạnh các sáng kiến xuyên khu vực như SEACrowd hay SEA-HELM, với tiếng Thái còn có các bộ dữ liệu tuân thủ chỉ dẫn như WangchanThaiInstruct và các benchmark đo năng lực văn hóa cùng năng lực nền tảng đã được công bố. Khi chọn mô hình, việc tham chiếu các đánh giá cho ngôn ngữ khu vực như vậy — chứ không chỉ các benchmark lấy tiếng Anh làm trung tâm — là điều đáng làm.

Tiếng Việt — mất dấu

Trong tiếng Việt, có hay không có dấu — cả dấu thanh lẫn dấu trên chữ cái — sẽ làm đổi nghĩa của từ. Khi văn bản đã mất dấu lọt vào quy trình, máy sẽ coi đó là một từ khác. Đây không phải chuyện lý thuyết — nó đổi trực tiếp nội dung chỉ dẫn trong tài liệu nhà máy.

• “cân” (đo khối lượng) và “cần” (yêu cầu phải có) cùng rơi về “can”. Câu chỉ dẫn “cân sản phẩm trước khi đóng gói” khi mất dấu có thể được máy hiểu thành “cần sản phẩm trước khi đóng gói” — từ một thao tác đo lường biến thành một yêu cầu về vật tư.
• “dầu” (dầu máy) và “đầu” (đầu, phần trên) cùng rơi về “dau”. “kiểm tra dầu máy” thành “kiểm tra đầu máy” là hai công việc bảo trì hoàn toàn khác nhau.
• “sửa” (sửa chữa) và “sữa” (sữa) cùng rơi về “sua”; “mở” (mở ra) và “mỡ” (mỡ bôi trơn) cùng rơi về “mo”. Trong hướng dẫn bảo trì, “tra mỡ” mất dấu thành “tra mo”, và máy hoàn toàn có thể hiểu thành “tra mở”.
• “lỗi” (lỗi, khuyết tật) và “lối” (lối đi) cùng rơi về “loi”. Một bảng mã “danh sách lỗi” bị mất dấu có thể được dịch sang tiếng Nhật hoặc tiếng Anh thành một thứ hoàn toàn không liên quan.

Điều đáng nói là ở những trường hợp này, LLM vẫn trả về một bản dịch trôi chảy và tự tin, chứ không báo lỗi. Người rà soát ở phía ngôn ngữ đích không có cách nào biết rằng bản gốc đã mất dấu.

Nguyên nhân hầu như không nằm ở engine dịch, mà nằm ở phía trước nó: file CSV xuất ra từ hệ thống lõi đời cũ, chọn nhầm bảng mã ký tự, mẫu biểu dùng font không hỗ trợ tiếng Việt, hoặc dữ liệu do nhân viên nhập bằng bộ gõ chưa bật. Vì vậy biện pháp xử lý cũng nằm ngoài quy trình dịch. Hãy đặt bước kiểm tra phát hiện lỗi mã ký tự và mất dấu ở phía đầu vào, chặn lại trước khi đưa sang engine dịch. Nếu coi đây là vấn đề chất lượng dịch thuật thì sẽ không bao giờ lần tới nguyên nhân.

Nhận câu hỏi nội bộ đa ngôn ngữ như thế nào

Khi số ngôn ngữ tăng lên, vấn đề “không biết phải hỏi ai” trở nên lớn hơn cả bản thân việc dịch. Khi một nhân viên người Thái đọc thông báo tiếng Nhật và có thắc mắc, nếu không có cách tra cứu quy định nội bộ viết bằng tiếng Nhật thì rốt cuộc chỉ còn cách hỏi thẳng quản lý người Nhật. Chính chỗ này ngốn thời gian của cấp quản lý.

Cách để tuyến tiếp nhận đầu tiên cho câu hỏi nội bộ hỗ trợ đa ngôn ngữ được trình bày trong bài Chi phí và cách triển khai chatbot. Tự động hóa dịch thuật và tự động hóa tiếp nhận câu hỏi thường bị lập thành hai dự án riêng, nhưng bộ thuật ngữ mà chúng tham chiếu thì hoàn toàn có thể dùng chung.

Phần việc vẫn còn lại sau khi tự động hóa

Lý do lớn nhất khiến quyết định đầu tư vào tự động hóa dịch thuật bị trượt là không đếm những vùng không được tự động hóa.

Chữ nằm trong hình — ngoài tầm với của dịch văn bản

Ghi chú trên bản vẽ CAD, nhãn máy trong ảnh chụp thiết bị, bảng biểu nằm trong file PDF scan. Những ký tự này không xử lý được như văn bản nên không lên được quy trình dịch thông thường. Và trong tài liệu nhà máy, tỷ trọng của chúng hoàn toàn không nhỏ.

Phần lớn công sức của hiện trường đọng lại ở đây. Chỉ dịch tự động phần thân của hướng dẫn công việc, mà chỉ dẫn trong hình vẫn là tiếng Nhật, thì rốt cuộc hiện trường vẫn không đọc được. Để xử lý chỗ này cần kết hợp với AI-OCR: phát hiện vùng chữ trong ảnh, chuyển thành văn bản, dịch, rồi trả về đúng vị trí cũ. Khâu “trả về đúng vị trí cũ” là khó nhất, và trong nhiều trường hợp tự động hóa hoàn toàn là không thực tế.

Khi cân nhắc triển khai, nên đếm trước tỷ lệ tài liệu có chứa chữ trong hình. Nếu quyết “tự động hóa việc dịch hướng dẫn công việc nhà máy” mà không biết con số này, thì sau khi vận hành hiệu quả chỉ đạt một nửa dự kiến.

Vấn đề “đọc được nhưng không làm theo”

Một mối nguy khác nằm ở chiều hoàn toàn khác với chất lượng bản dịch. Bản dịch có đúng ngữ pháp đi nữa, nhưng nếu từ ngữ hiện trường vẫn là bản dịch sát chữ từ trụ sở, thì nhân viên bản địa sẽ đọc lướt qua vì nó không khớp với cách gọi thực tế.

Ví dụ, hoạt động mà trụ sở gọi là “bảo trì phòng ngừa” thì tại hiện trường Thái Lan lại được gọi bằng một cách nói khác có gốc tiếng Anh. Nếu đưa bản dịch sát chữ vào tài liệu tiêu chuẩn, nhân viên đọc sẽ không nhận ra đó đang nói về công việc của mình. Tài liệu vẫn đúng, audit cũng không có vấn đề gì, nhưng hành vi thì không thay đổi.

Thứ cần đăng ký vào bộ thuật ngữ không phải “bản dịch đúng” mà là “từ đang thực sự được dùng tại hiện trường”. Để quyết định điều này, chỉ có cách hỏi lớp tổ trưởng, quản đốc tại hiện trường chứ không phải người phụ trách dịch thuật. Nếu khoán trắng việc xây dựng bộ thuật ngữ cho công ty dịch thuật, kết quả sẽ là một danh sách các từ đúng nhưng không ai dùng.

Thiết kế cho phía tiếp nhận

Chỉ đưa công cụ vào thì cách vận hành không đổi. Với tự động hóa dịch thuật, thứ thay đổi không phải công việc của “người từng đi đặt dịch” mà là công việc của “người kiểm tra bản dịch”. Người trước đây gửi tài liệu ra ngoài để dịch nay chuyển sang vị trí phê duyệt bản dịch của máy. Vai trò đã đổi thì phải có đào tạo.

Những nguyên nhân điển hình khiến đào tạo liên quan tới AI tạo sinh không bén rễ được tổng hợp trong bài 4 nguyên nhân khiến đào tạo AI tạo sinh không bén rễ. Không riêng tự động hóa dịch thuật, mọi nỗ lực tự động hóa nghiệp vụ bằng AI đều va vào cùng bức tường này, nên tốt hơn là dành sẵn một phần ngân sách cho đào tạo ngay trong kế hoạch triển khai.

Tại hiện trường sản xuất ở Thái Lan, rào cản ngôn ngữ trong OJT đã được chỉ ra như một gánh nặng học tập, và việc chuẩn bị tài liệu đào tạo cho nhân viên nói tiếng Thái được khuyến nghị. Tự động hóa dịch thuật cũng là một phương tiện làm rẻ đi việc chuẩn bị tài liệu đó. Nếu chỉ tính hiệu quả ở phần giờ công dịch thuật tiết kiệm được, khía cạnh này sẽ biến mất khỏi tầm nhìn.

Ước tính chi phí tại nhà máy Nhật quy mô vừa ở Thái Lan

Dưới đây là ước tính năm cho một nhà máy Nhật có cơ sở sản xuất tại Thái Lan với khoảng 300 nhân viên. Xin nói trước rằng đây không phải số liệu đo thực tế, mà là giá trị giả định đặt theo mức chuẩn quan sát được ở nhiều dự án. Hãy dùng nó như bộ khung để thay số liệu của chính công ty bạn vào rồi tính lại.

Đây là ước tính lấy cơ sở tại Thái Lan làm ví dụ, nên toàn bộ số tiền được giữ nguyên bằng THB. Khi đọc sang bối cảnh một nhà máy ở Việt Nam, xin lưu ý rằng mặt bằng chi phí nhân sự, đơn giá dịch thuật thuê ngoài và đồng tiền hạch toán đều khác — do đó đừng quy đổi cơ học các con số dưới đây, mà hãy thay bằng đơn giá và khối lượng thực tế của cơ sở mình. Cấu trúc của bảng (chi phí nào nổi lên hóa đơn, chi phí nào biến mất thành giờ công nội bộ) mới là phần dùng lại được.

Điều kiện giả định

Toàn bộ số tiền được đặt bằng THB. Vì tỷ giá biến động nên tránh so sánh sau khi quy đổi sang JPY; giữ nguyên THB để ra quyết định mới là cách làm thực tế. Ngoài ra, thời gian chờ của bên thuê ngoài cũng là một biến số thiết kế. Với trường hợp dịch sổ tay chất lượng và checklist kiểm tra của một nhà sản xuất linh kiện ô tô từ tiếng Nhật sang tiếng Thái, đã có ví dụ công ty dịch thuật báo thời hạn giao khoảng ba tuần. Với tài liệu kiểm soát có tần suất sửa đổi cao, ba tuần đó chuyển thẳng thành độ trễ triển khai tới hiện trường.

So sánh 3 kịch bản

Phần in đậm là tổng số. Hai dòng trên là chi phí xuất hiện trên báo giá và hóa đơn, năm dòng dưới là chi phí không nổi lên mặt giấy, tan biến thành thời gian nội bộ. Chênh lệch nằm đúng ở đây, và đó là luận điểm của bài viết này.

Giờ công kiểm tra của người phê duyệt được tính bằng nhau ở cả kịch bản thuê ngoài 100% và kịch bản phân lớp. Lý do là chữ ký phê duyệt cho lớp A và lớp C phát sinh bất kể ai dịch, và không biến mất chỉ vì đã đưa ra ngoài. Chỉ riêng cột AI tự động 100% để trống là vì kịch bản này ngay từ đầu đã không bố trí chỗ cho khâu phê duyệt — nó không rẻ hơn, nó chỉ bỏ qua một bước. Ngoài ra, kịch bản thuê ngoài 100% được tính với giả định rằng để tiện so sánh, chữ hiển thị hiện trường lớp D cũng được đưa ra ngoài dịch và ràng buộc bề rộng hiển thị đã được đưa vào yêu cầu đặt hàng, nên cột này không có khoản sửa lỗi vỡ bố cục.

Cách đọc bảng

Kịch bản thuê ngoài 100% có chi phí trực tiếp lớn vượt trội. Khoảng 89% tổng số là tiền trả cho công ty dịch thuật, phần còn lại là giờ công nội bộ. Quản lý thì nhẹ, nhưng cấu trúc là khối lượng tăng thì chi phí tăng theo đúng tỷ lệ.

Kịch bản AI tự động 100% có chi phí trực tiếp nhỏ đi rõ rệt, nhưng đối chiếu thuật ngữ và làm lại phình lên tới 950.000 THB. Đó là giờ công để về sau đi hiệu chỉnh những tài liệu lớp A đã bị sai lệch thuật ngữ, phát hành lại và phân phối lại. Khoản sửa lỗi vỡ bố cục hiển thị 250.000 THB chỉ xuất hiện duy nhất ở cột này trong ba kịch bản, cũng vì không có ai để nhận ràng buộc bề rộng hiển thị như một yêu cầu kỹ thuật.

Và điểm quan trọng nhất: tổng số của kịch bản AI tự động 100% đang che giấu một rủi ro. Trạng thái tài liệu kiểm soát không có bản ghi chữ ký phê duyệt sẽ không hiện ra thành tiền, nhưng sẽ thành vấn đề khi audit. Chi phí trong trường hợp dẫn tới hành động khắc phục phụ thuộc quá nhiều vào tình huống nên không được tính vào bảng này. Quyết định chọn tự động hoàn toàn chỉ vì tổng số rẻ là một quyết định bỏ sót phần thiếu này.

Kịch bản phân lớp giữ nguyên 252.000 THB giờ công phê duyệt bằng đúng kịch bản thuê ngoài, đồng thời kéo cả chi phí trực tiếp lẫn chi phí làm lại xuống. Phê duyệt không phải đối tượng để cắt giảm; đó là chi phí được giữ lại một cách có chủ ý. Nhờ bộ thuật ngữ phát huy tác dụng, giờ công đối chiếu và làm lại giảm còn 154.600 THB, và giờ công giải trình khi audit cũng gói gọn trong 20.000 THB vì đã có lịch sử phê duyệt.

Những gì không được viết trong ước tính này

Khoản thiết lập ban đầu 570.000 THB của kịch bản phân lớp bao gồm xây dựng bộ thuật ngữ, chuẩn bị bộ nhớ dịch thuật và tách riêng phần thiết kế chữ hiển thị lớp D. Phần đáng kể trong đó là chi phí một lần dồn vào năm đầu, và sẽ giảm từ năm thứ hai. Tuy nhiên, con số bao nhiêu năm thì hoàn vốn lại phụ thuộc quá nhiều vào tốc độ tăng khối lượng dịch và tần suất sửa đổi tài liệu, nên không có căn cứ để đặt. Ở đây không viết ra.

Tương tự, chi phí của các sự cố chất lượng do dịch sai gây ra cũng không được tính vào, vì không có căn cứ để đặt xác suất xảy ra. Nếu bắt gặp một bản ước tính có chứa loại số liệu này, tốt hơn hết là kiểm tra xem giả định đó đến từ đâu.

Lộ trình 90 ngày để chạy trọn một vòng

Thay vì lập một kế hoạch đồ sộ, chạy trọn một vòng trong 90 ngày để có số liệu đo thực tế sẽ nhanh hơn. Dưới đây là cách tiến hành với cấu hình tối thiểu.

Ngày 1–30 Kiểm kê hiện trạng và phân lớp

Tháng đầu tiên dùng để viết ra toàn bộ công việc dịch thuật hiện có. Ai, dịch cái gì, với tần suất bao nhiêu, tốn bao nhiêu thời gian. Tách riêng phần đang thuê ngoài và phần đang xử lý nội bộ.

Trên cơ sở đó, gán các tài liệu đã liệt kê vào 4 lớp. Công việc này nên do ba bên cùng làm: đảm bảo chất lượng, sản xuất và khối quản lý. Làm một mình thì chắc chắn sẽ dao động ở ranh giới giữa lớp A và lớp C. Đồng thời, hãy đếm luôn tỷ lệ tài liệu có chứa chữ trong hình ở giai đoạn này.

Ngày 31–60 Xây bộ thuật ngữ và triển khai trước ở lớp B

Tháng thứ hai chạy song song việc xây dựng tầng thuật ngữ và vận hành thử ở lớp B. Bộ thuật ngữ bắt đầu từ 200 từ thường gặp, vừa điền vừa xác nhận cách gọi thực tế với các tổ trưởng hiện trường. Đừng để riêng bộ phận dịch thuật quyết định.

Ở lớp B, chọn một hoặc hai mục đích như tạo biên bản cuộc họp tự động, dịch tự động báo cáo ngày, sinh tự động báo cáo định dạng cố định, rồi chạy thật. Mục đích ở đây không phải đo hiệu quả mà là tạo ra khuôn mẫu vận hành. Hãy làm quen trước ở lớp mà thất bại cũng ít thiệt hại.

Ngày 61–90 Đo TTE và chạy thử lớp A

Tháng thứ ba, chạy thử mô hình “dịch thô bằng máy + con người phê duyệt” ở lớp A. Đối tượng giới hạn ở vài tài liệu hướng dẫn công việc có tần suất sửa đổi cao. Đo TTE thực tế ở đây và so với trường hợp dịch từ đầu.

Đồng thời, tổng hợp cả số liệu vận hành thực tế của lớp B. Tại thời điểm kết thúc 90 ngày, những thứ phải còn lại trong tay là: TTE đo thực tế theo từng lớp, bộ thuật ngữ 200 từ, kết quả vận hành lớp B, và những con số của chính công ty dùng được cho quyết định đầu tư tiếp theo. Có đủ bốn thứ này là có thể ra quyết định triển khai chính thức.

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

Tự động hóa dịch thuật doanh nghiệp có thể giao tới đâu?

Câu trả lời thay đổi theo lớp tài liệu. Các tài liệu vận hành như báo cáo ngày, biên bản cuộc họp, thông báo nội bộ có thể tự động hoàn toàn (chỉ giữ lại việc kiểm tra mẫu vài bản mỗi tháng). Các tài liệu kiểm soát như hướng dẫn công việc hay sổ tay chất lượng thì chỉ tới bản dịch thô, phê duyệt do con người làm. Tài liệu gửi khách hàng và hợp đồng thì người dịch, AI dùng để kiểm tra tính nhất quán. Chữ hiển thị như màn hình HMI thì đưa ra khỏi quy trình dịch và xử lý như thiết kế. Nếu cố quy định “giao tới đâu” bằng một chuẩn chung cho toàn công ty, chắc chắn sẽ vỡ ở đâu đó.

Chi phí AI dịch thuật cho doanh nghiệp khoảng bao nhiêu?

Bản thân phí API, nếu khối lượng tài liệu ở mức như ước tính trong bài này, sẽ gói gọn trong quy mô hơn chục nghìn THB mỗi năm. Vấn đề nằm ở các chi phí đi kèm: xây dựng bộ thuật ngữ, thiết lập luồng phê duyệt, sắp xếp lại tài liệu hiện có — những chi phí ban đầu này ở quy mô vài trăm nghìn THB. Khi lấy báo giá, nên so sánh dựa trên phạm vi chuẩn bị ban đầu chứ không phải đơn giá API. Ngoài ra, tiếng Thái cùng một nội dung nhưng dễ sinh nhiều token hơn, nên áp thẳng bảng đơn giá tính trên tiếng Anh sẽ vượt dự kiến.

AI tạo biên bản cuộc họp có dùng được cho cuộc họp trộn tiếng Nhật và tiếng Thái không?

Dùng được, nhưng có điều kiện. Tiền đề là mỗi người nói có micro riêng, hoặc môi trường ghi âm yên tĩnh. Trong phòng họp nhà máy có tiếng ồn, hoặc khi nhiều người nói cùng lúc, độ chính xác của việc chuyển giọng nói thành văn bản sẽ giảm. Trước hết phải chỉnh môi trường ghi âm đã. Ngoài ra, từ riêng của công ty và tên thiết bị nếu không đăng ký từ điển trước thì sẽ bị nghe sai. Cấu hình chia sẻ bộ thuật ngữ sang cả phía chuyển giọng nói thành văn bản sẽ phát huy hiệu quả.

Vì sao riêng tiếng Thái chất lượng dịch không ổn định?

Có nhiều yếu tố chồng lên nhau. Tiếng Thái không có khoảng trắng giữa các từ nên trước hết phải phán đoán cắt chuỗi ký tự ở đâu, và sai ở đây thì bản dịch đổ theo. Thêm vào đó, khối lượng dữ liệu huấn luyện ít hơn so với tiếng Anh hay tiếng Trung. Hơn nữa, các từ riêng của công ty và thuật ngữ sản xuất được phiên âm sang chữ Thái không tồn tại trong từ điển nên cả việc cắt từ lẫn cách dịch đều dễ lệch. Đăng ký vào bộ thuật ngữ có tác dụng chính vì nó tác động trực tiếp lên yếu tố thứ ba này.

Nên xây bộ thuật ngữ như thế nào?

Có ba nguyên tắc. Thứ nhất, bắt đầu từ khoảng 200 từ thường gặp — nhắm bao phủ toàn bộ thì sẽ không bao giờ xong. Thứ hai, cách dịch được quyết bằng cách hỏi tổ trưởng hiện trường chứ không phải tra từ điển (lý do đã viết ở mục “đọc được nhưng không làm theo” phía trên). Thứ ba, xây cơ chế tự động nhặt từ trong các bản dịch đã phê duyệt để bổ sung vào. Nếu chỉ duy trì bằng sức người, sau nửa năm việc cập nhật sẽ dừng.

Nên xử lý hợp đồng với công ty dịch thuật hiện tại ra sao?

Không cần nội bộ hóa toàn bộ. Với tài liệu đối ngoại lớp C, tiếp tục thuê ngoài thường là quyết định hợp lý. Ngoài ra, nhờ công ty dịch thuật xây dựng bộ thuật ngữ ban đầu cũng là một lựa chọn, nhưng ngay cả khi đó thì việc xác nhận cách gọi tại hiện trường vẫn phải do công ty bạn tự làm. Mục tiêu không phải đưa mức thuê ngoài về không, mà là chọn tuyến xử lý tối ưu cho từng lớp.

Audit ISO 9001 sẽ yêu cầu những gì?

Đối tượng là việc quản lý theo điều khoản 7.5 “Thông tin dạng văn bản”. Yêu cầu là tài liệu phải sẵn có và dễ đọc, phải nhận biết được, và được bảo vệ khỏi những thay đổi ngoài ý muốn. Với bản dịch cũng vậy: khi dịch tài liệu ISO sang tiếng Thái hay tiếng Việt, doanh nghiệp phải ở trạng thái giải thích được phiên bản nào đã phê duyệt và được phân phối ra sao. Nếu việc quản lý thuật ngữ đã phê duyệt được văn bản hóa, việc giải trình với chuyên gia đánh giá sẽ rõ ràng. Ngược lại, trạng thái đầu ra của máy dịch được phân phối thẳng tới hiện trường là trạng thái rất khó giải thích.

Tổng kết

Tự động hóa dịch thuật doanh nghiệp bị đình trệ không phải vì hiệu năng của engine, mà vì vấn đề thiết kế. Chừng nào tài liệu còn được xử lý mà không phân loại, thì đến cuối cùng vẫn không chốt được ai chịu trách nhiệm cho bản dịch nào.

Có thể gói các biện pháp thành ba điểm. Thứ nhất, chia tài liệu thành 4 lớp — tài liệu kiểm soát, tài liệu vận hành, tài liệu đối ngoại, chữ hiển thị tại hiện trường — và thay đổi phân công giữa máy và người theo từng lớp. Thứ hai, tổ chức theo 3 tầng gồm tầng thuật ngữ, tầng sinh dịch, tầng phê duyệt, và tạo vòng tuần hoàn đưa bản dịch đã phê duyệt trở về tầng thuật ngữ. Thứ ba, thay KPI từ tỷ lệ phần trăm độ chính xác sang TTE (Time to Edit) để đo thực tế xem công việc có thật sự giảm hay không.

Tại hiện trường Thái Lan và ASEAN, việc tách từ, hiệu suất token, dấu thanh tiếng Việt, chữ nằm trong hình, và vấn đề “đọc được nhưng không làm theo” trở thành những rào cản đặc thù. Chúng không được giải quyết bằng việc chọn engine dịch, mà bằng cách thiết kế lớp tài liệu và cách xây bộ thuật ngữ. Thực tế nhất là bắt đầu bằng 90 ngày, từ việc phân lớp và đo TTE.

Ngay cả khi bạn mới đang ở giai đoạn muốn sắp xếp xem tài liệu của mình thuộc lớp nào và nên tự động hóa từ đâu, cũng không sao. TOMAS TECH triển khai IT, OT và AI cho các nhà máy sản xuất tại Thái Lan và khu vực ASEAN, và có thể trao đổi về tự động hóa dịch thuật ngay từ bước kiểm kê hiện trạng. Nếu bạn muốn trao đổi thông tin ở giai đoạn cân nhắc, hãy liên hệ qua trang liên hệ.

Tài liệu tham khảo

• Machine Translation 2026 Assessment (Translated)
• Best LLM for Translation 2026 (Alconost)
• What is the Best LLM for Translation (Lokalise)
• Compliance Best Practices for Translation: 2026 Guide (Adverbum)
• Assuring Quality Through Document Control (QualityWeb360)
• WangchanThaiInstruct: Bộ dữ liệu và đánh giá tuân thủ chỉ dẫn tiếng Thái (arXiv:2508.15239)
• Benchmark năng lực văn hóa và nền tảng cho phát triển LLM tiếng Thái (arXiv:2410.04795)
• Nghiên cứu thực nghiệm về bộ tách token của LLM đa ngôn ngữ (arXiv:2606.15044)
• Dịch vụ dịch thuật tiếng Thái (Kawamura International)