Triển khai AI dịch: chọn lớp, đừng chọn tiếng ồn

Triển khai AI dịch: chọn lớp, đừng chọn tiếng ồn

Một playbook cho team builder: mổ hệ thống dịch AI theo lớp, từ model, ngữ cảnh, UX đến đo tác động trước khi đem lên production.

Có lần mình thấy một team chuẩn bị launch tính năng dịch nội dung hỗ trợ khách hàng. Slack rộn lên: “Dùng model mới nhất chưa?”, “Có nên đổi sang LLM đa ngôn ngữ không?”, “App mobile cần chạy offline không?”. Trong khi đó, câu hỏi quan trọng nhất nằm lặng lẽ ở góc phòng như cuốn sách bị xếp sai kệ: mình đang triển khai hệ thống dịch cho tình huống nào?

Dịch một câu chat ngắn khác với dịch tài liệu kỹ thuật. Dịch UI onboarding khác với dịch điều khoản pháp lý. Dịch để đọc hiểu khác với dịch để gửi cho khách hàng. Nếu gom hết vào một quyết định “chọn model nào”, team rất dễ mua nhầm cả phòng đọc chỉ vì thích cái thẻ mượn sách nhìn đẹp.

Luận điểm của bài này gọn thôi: triển khai AI dịch không phải bài toán chọn mô hình mạnh nhất, mà là bài toán chia đúng lớp quyết định. Model chỉ là một kệ trong thư viện. Bạn còn cần phân loại tài liệu, quy trình mượn-trả, người kiểm tra bản in, và nhật ký xem cuốn nào bị đọc sai.

Sơ đồ minh họa cho bài Triển khai AI dịch: chọn lớp, đừng chọn tiếng ồn

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu: một bản dịch đủ dùng trong đúng ngữ cảnh

Neural Machine Translation, hay NMT — dịch máy bằng mạng neural, đã làm bản dịch bớt “robot” hơn nhiều so với kiểu rule-based cũ. Thay vì thay từng từ theo từ điển rồi đảo trật tự câu, NMT học từ rất nhiều cặp câu người dịch sẵn để đoán cách diễn đạt tự nhiên hơn.

Điểm quan trọng nằm ở context, tức ngữ cảnh quanh từ và câu. Ví dụ kinh điển: “bank” trong “bank deposit” là ngân hàng, còn “river bank” là bờ sông. Một hệ thống dịch tốt không chỉ nhìn từ “bank”, mà nhìn cả câu để hiểu nó đang đứng cạnh ai.

Transformer — kiến trúc dùng attention, cơ chế cho model biết phần nào trong câu nên được chú ý hơn — là nền cho nhiều hệ thống hiện đại. Nhưng với builder, biết lịch sử chưa đủ. Câu hỏi production là: khi đưa vào app thật, bạn sẽ bảo vệ ngữ cảnh đó bằng cách nào?

Hình dung thế này: team bạn làm app support cho khách Việt, Nhật, Anh. Người dùng gửi câu: “Tài khoản bị khoá sau khi verify bank.” Nếu hệ thống dịch “bank” sai, nhân viên support đi nhầm luồng xử lý. Lỗi không nằm hoàn toàn ở model; có thể nằm ở việc bạn không đưa glossary sản phẩm, không log bản dịch rủi ro, hoặc không có đánh giá theo từng user flow.

Checklist quyết định: 5 lớp trước khi viết code

Trước khi mở IDE, mình sẽ ép team trả lời 5 câu này. Không cần hoành tráng, nhưng phải ghi ra được.

| Lớp | Câu hỏi cần chốt | Quyết định kỹ thuật |
|---|---|---|
| Runtime | Dịch ở server hay trên thiết bị? | Cloud API, self-host, hoặc on-device |
| Context | Có thuật ngữ nội bộ không? | Glossary, RAG, hoặc prompt context |
| Quality gate | Ai được phép tin bản dịch? | Human review, confidence flag, fallback |
| UX flow | Bản dịch xuất hiện ở đâu? | Inline, preview, side-by-side, editable |
| Experiment | Làm sao biết nó có ích? | A/B test, regression, task completion |

Đây là điểm nhiều team hiểu sai: model mới hơn không tự động sửa được quy trình sai. Nếu app của bạn dịch tài liệu kỹ thuật nội bộ, context layer có thể quan trọng hơn model layer. Nếu app cần chạy khi không có mạng, runtime layer lại là chuyện sống còn. Nếu bản dịch tác động tới pháp lý, quality gate phải đứng trước tốc độ.

Mổ hệ thống theo lớp: đừng để model gánh hết

Một hệ thống dịch có thể tách thành bốn lớp vận hành.

1. Lớp hiểu câu

Đây là nơi NMT hoặc LLM làm việc chính: nhận input, tạo output. Với app mobile, bạn cần cân nhắc latency, chi phí, privacy và khả năng offline. Nếu dùng một engine như QVAC trong bối cảnh React Native theo hướng on-device, điểm hấp dẫn là giảm phụ thuộc mạng và giữ dữ liệu gần người dùng hơn. Nhưng đổi lại, bạn phải quan tâm kích thước model, khả năng cập nhật, và kiểm thử trên nhiều thiết bị.

Nếu dùng cloud API, triển khai ban đầu thường nhẹ hơn. Nhưng mỗi request đều đi qua mạng, chi phí tăng theo usage, và dữ liệu phải đi qua lớp bảo mật nghiêm túc hơn.

2. Lớp ngữ cảnh miền nghiệp vụ

Đây là chỗ RAG — Retrieval-Augmented Generation, truy xuất tài liệu liên quan rồi đưa vào model — có thể giúp, nhưng không phải lúc nào cũng cần. Với chatbot hỏi tài liệu, RAG rất hợp: cắt tài liệu thành chunk, tạo embedding, truy xuất vài đoạn liên quan rồi cho model trả lời. Với dịch thuật, RAG nên được dùng hẹp hơn: glossary, style guide, quy tắc dịch tên tính năng, ví dụ câu chuẩn.

Ví dụ cụ thể: nếu sản phẩm có cụm “workspace”, team có thể muốn giữ nguyên tiếng Anh thay vì dịch thành “không gian làm việc”. Nếu không có lớp ngữ cảnh, mỗi lần model có thể chọn một kiểu. Với người dùng, đó là trải nghiệm lổn nhổn như thư viện mà cùng một tác giả bị xếp ở ba kệ khác nhau.

3. Lớp kiểm tra luồng người dùng

Dịch đúng từng câu chưa chắc UX đã ổn. Một nút “Submit” dịch thành “Nộp” trong app thuế có thể ổn, nhưng trong app social nghe kỳ. Automated UX testing bằng model đa phương thức — tức model nhìn được giao diện và thao tác như người dùng — mở ra hướng kiểm tra nhiều flow hơn so với script cứng kiểu chỉ bấm theo selector.

Nhưng đừng nhầm nó với QA tuyệt đối. Nó giúp phát hiện ma sát: bản dịch quá dài làm vỡ layout, label mơ hồ khiến user chọn sai, tooltip dịch thiếu ý. Bạn vẫn cần testcase rõ và log hành vi.

4. Lớp đo tác động

Nếu launch xong chỉ hỏi “mọi người thấy ổn không?”, bạn đang đo bằng cảm giác. Với feature AI, nhất là dịch, nên có experiment. A/B test ngẫu nhiên vẫn là cách sạch nhất khi làm được. Regression — mô hình hồi quy để ước lượng tác động và độ tin cậy — giúp đọc kết quả kỹ hơn: tính năng mới có làm tăng task completion không, có khác nhau giữa nhóm user mới và user lâu năm không.

Không cần biến mọi team thành lab thống kê. Nhưng ít nhất hãy xác định metric trước: giảm ticket do hiểu sai, tăng tỷ lệ hoàn tất form, giảm thời gian xử lý case đa ngôn ngữ, hoặc tăng số cuộc hội thoại được self-serve.

Làm trong một buổi: bản skeleton đủ để tranh luận

Trong một buổi chiều, bạn không cần build full system. Bạn cần tạo một skeleton để team nhìn thấy tradeoff.

Bước 1 — Viết decision file

Tạo translation-decision.md:

# Translation feature decision

Use case: dịch tin nhắn support ngắn
Languages: vi, en, ja
Risk level: medium
Runtime: server first, mobile cache later
Context: product glossary required
Review: flag low-confidence / legal terms
Metric: support resolution time, correction rate

Bước 2 — Tách glossary khỏi code

Đừng hardcode thuật ngữ trong prompt rải rác. Dùng file cấu hình:

{
  "terms": [
    { "source": "workspace", "target_vi": "workspace", "note": "Giữ nguyên tên tính năng" },
    { "source": "bank verification", "target_vi": "xác minh tài khoản ngân hàng", "note": "Không dịch là xác minh bờ sông" }
  ],
  "style": {
    "tone": "friendly_support",
    "preserve_product_names": true
  }
}

Ý tưởng này giống cách Gin Config tách tham số thí nghiệm khỏi code training: code ổn định, biến thể nằm ở config. Với translation app, config giúp bạn đổi glossary, style, fallback mà không phải sửa logic lõi.

Bước 3 — Gắn log cho bản dịch rủi ro

Log tối thiểu:

{
  "request_id": "...",
  "source_lang": "en",
  "target_lang": "vi",
  "domain": "support",
  "glossary_version": "2026-07-18",
  "fallback_used": false,
  "user_edited_output": true
}

user_edited_output là tín hiệu vàng. Nếu người dùng liên tục sửa cùng một loại câu, bạn có dữ liệu để cải thiện glossary hoặc prompt.

Bước 4 — Chạy 10 câu thật, không chạy câu demo đẹp

Lấy 10 câu từ ticket hoặc nội dung sản phẩm đã ẩn thông tin nhạy cảm. Bao gồm câu ngắn, câu sai chính tả, câu có thuật ngữ, câu có mơ hồ. So sánh ba hướng: cloud, on-device, và bản có glossary. Đừng cần benchmark lớn; mục tiêu là phát hiện lỗi lớp hệ thống.

Bẫy dễ dính khi triển khai

Bẫy 1: nhét toàn bộ tài liệu vào prompt. Với RAG chatbot, việc chunk tài liệu rồi truy xuất đoạn liên quan có lý do rõ ràng: tránh tràn context window — vùng ngữ cảnh model còn giữ được — và giảm nhiễu. Với dịch, cũng vậy: chỉ đưa glossary và ví dụ liên quan, đừng bê cả handbook vào.

Bẫy 2: xem offline là mặc định tốt hơn. On-device hấp dẫn, nhất là về privacy và latency trong vài bối cảnh. Nhưng nếu glossary đổi liên tục, model cần cập nhật thường xuyên, hoặc thiết bị người dùng quá phân mảnh, server-side có thể dễ vận hành hơn.

Bẫy 3: chỉ đo BLEU hoặc điểm tự động. Metric tự động có ích khi so sánh bản dịch, nhưng product metric mới trả lời câu hỏi kinh doanh: user có hoàn thành việc không, support có ít phải sửa hơn không, nội dung có gây hiểu sai không.

Nếu là mình, mình sẽ chọn thế này

Với team builder ở Việt Nam đang triển khai lần đầu, mình sẽ không bắt đầu bằng câu “model nào xịn nhất?”. Mình sẽ bắt đầu bằng decision matrix theo lớp:

Sau bài này, điều mình muốn bạn nghĩ khác là: AI translation không phải một nút “dịch” cắm vào app, mà là một hệ thống có nhiều lớp cần được xếp đúng kệ. Chọn sai kệ thì sách vẫn nằm đó, chỉ là người cần đọc sẽ không bao giờ tìm thấy.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo