Bên trong bốn pipeline dịch vận hành InterMIND

Trang /product/overview/how-it-works cũ trên mind.com đã lạc hậu qua nhiều phiên bản lớn. Trang này mô tả một "công cụ dịch" duy nhất theo cách mà hầu hết các trang của nhà cung cấp vẫn làm — một mũi tên lớn từ "bạn nói" đến "họ nghe". Cách mô tả đó đã là một sự đơn giản hóa từ hai năm trước. Ngày nay, nó không còn đúng.

Sự thật là InterMIND vận hành bốn pipeline dịch riêng biệt, mỗi pipeline giải quyết một vấn đề khác nhau bằng một công cụ khác nhau, một ngân sách độ trễ khác nhau, và một biên độ chất lượng khác nhau. Chúng dùng chung một bộ chọn ngôn ngữ. Chúng không dùng chung một công cụ.

Đây là câu trả lời được cập nhật cho câu hỏi "nó hoạt động như thế nào."

Bài viết đồng hành: "Bạn hỗ trợ bao nhiêu ngôn ngữ?" trình bày phạm vi mà mỗi pipeline bao phủ (23 / 23 / 30 / 17). Bài viết này trình bày những gì mỗi pipeline thực hiện — và vì sao mỗi pipeline là một thực thể riêng.

Vì sao "một công cụ cho tất cả" là một lời nói dối

Một nền tảng cuộc họp trực tiếp phải thực hiện ít nhất bốn nhiệm vụ cùng lúc, và các nhiệm vụ này kéo theo những hướng không tương thích với nhau:

1. Giọng nói thời gian thực — âm thanh đầu vào, âm thanh đã dịch đầu ra, trong vòng dưới một giây, mỗi người xem nghe bằng ngôn ngữ của riêng mình. Ràng buộc khó nhất là độ trễ.
2. Văn bản chat thời gian thực — tin nhắn ngắn, nhanh, với các chỉnh sửa, trích dẫn và cấu trúc HTML được giữ nguyên.
3. Ghi chú chia sẻ thời gian thực — gõ chữ cộng tác theo từng ký tự, với cấu trúc thứ bậc (danh sách, tiêu đề, hộp kiểm) phải được giữ nguyên qua quá trình dịch.
4. Tệp tài liệu bất đồng bộ — một tệp PDF 40 trang được thả vào chat. Không có ngân sách độ trễ. Ràng buộc khó nhất là độ trung thực — định dạng, bảng, số trang, phông chữ.

Bạn có thể xây dựng một lệnh gọi LLM khổng lồ duy nhất để cố gắng thực hiện cả bốn việc này. Chúng tôi đã thử. Nó làm kém cả bốn việc. Ngân sách độ trễ cho giọng nói có nghĩa là mô hình không có thời gian để "suy nghĩ"; ngân sách độ trung thực cho tài liệu có nghĩa là mô hình buộc phải suy nghĩ. Một chỉnh sửa trong chat cần một bản so sánh khác biệt (diff) bằng ngôn ngữ của người xem; một tệp PDF 40 trang cần khả năng giữ nguyên định dạng mà không mô hình phát trực tuyến theo token (token-streaming) nào có thể mang lại.

Vì vậy, chúng tôi chạy bốn pipeline. Sau đây là từng pipeline.

Pipeline 1: Dịch giọng nói thời gian thực

Vấn đề: Một người tham gia nói tiếng Pháp. Một người khác tham gia bằng tiếng Đức, người thứ ba bằng tiếng Bồ Đào Nha (Brazil), người thứ tư bằng tiếng Nhật. Mỗi người cần nghe người nói bằng ngôn ngữ của riêng họ, qua tai của riêng họ, với độ trễ đủ ngắn để vẫn có thể duy trì giao tiếp bằng mắt.

Ngân sách: Dưới một giây, từ đầu đến cuối. Bất cứ điều gì vượt quá khoảng 1,2 giây, cuộc trò chuyện sẽ đứt quãng — mọi người bắt đầu nói chen vào lúc đang dịch, và cuộc họp dần trôi về hướng "thôi chuyển sang nói tiếng Anh cho xong."

Âm thanh thực sự di chuyển như thế nào

Có vài điều đáng nói rõ ra:

• ASR chạy trong trình duyệt của người nói, không phải trên một máy chủ trung tâm. Chúng tôi dùng Mind SDK cục bộ; điều này giúp tiết kiệm một vòng round-trip và cho chúng tôi bản ghi bằng ngôn ngữ nguồn với độ trễ thấp nhất có thể trước khi việc dịch thậm chí có thể bắt đầu.
• Việc dịch không phải là một lần phân phát duy nhất (fan-out). Chúng tôi duy trì một nhóm (pool) các kết nối WebSocket tới công cụ dịch của mình, một kết nối cho mỗi ngôn ngữ đích có mặt trong phòng. Nếu ba người tham gia chọn tiếng Đức, họ dùng chung một kết nối tiếng Đức. Nếu không ai chọn tiếng Ả Rập, không có kết nối tiếng Ả Rập nào được mở. Nhóm kết nối sẽ loại bỏ các kết nối không hoạt động sau năm phút. Đây là lý do một cuộc họp bốn ngôn ngữ có chi phí giống như một cuộc họp bốn mươi ngôn ngữ, tùy vào số người thực sự tham gia — chúng tôi không bao giờ dịch sang những ngôn ngữ mà không có người tham gia nào đang nghe.
• Giọng nói tổng hợp được tạo riêng cho từng người xem. Mỗi người tham gia nhận được bản âm thanh đã dịch riêng của mình, được trộn cùng video gốc của người nói. Họ không xem một "cuộc họp đã dịch" tổng hợp duy nhất — họ đang xem cùng một cuộc họp, chỉ khác là kênh âm thanh cá nhân của họ được dịch sang ngôn ngữ họ đã chọn. Đây là lý do hai người trong cùng một phòng thực tế có thể đeo tai nghe riêng và nghe hai ngôn ngữ khác nhau.

Vì sao điều này quan trọng khi cuộc họp gặp vấn đề

Trong một cuộc gọi 60 phút với tám ngôn ngữ, sự cố xảy ra theo những cách khá thú vị: WebSocket bị rớt, ASR đôi khi phiên âm sai một danh từ riêng, mạng của một người tham gia bị chập chờn. Kiến trúc nêu trên là thứ giúp chúng tôi cách ly các lỗi này: âm thanh của một người xem bị giật không ảnh hưởng đến bảy người còn lại, vì ngay từ đầu công cụ dịch không tạo ra "bản dịch" (số ít) — nó tạo ra tám bản dịch song song, và chỉ bản bị ảnh hưởng mới cần khôi phục.

Công cụ này là của riêng chúng tôi, được lưu trữ trên hạ tầng riêng của chúng tôi. Chúng tôi không định tuyến giọng nói thời gian thực qua các LLM đa dụng của bên thứ ba. Ngân sách độ trễ đã loại các LLM đó ra; câu chuyện về cư trú dữ liệu cũng loại chúng ra đối với các khách hàng thuộc lĩnh vực chịu quản lý — những người thực sự quan tâm đến vấn đề này.

Những gì chúng tôi công bố về chất lượng giọng nói: /benchmark chạy pipeline giọng nói thực tế (production) đối chiếu với các câu trong FLORES-200 cho mọi cặp ngôn ngữ đã công bố, mỗi tháng. Người đánh giá (judge) được nêu rõ danh tính (Gemini 3.7 Flash là chính, Claude Sonnet 5 là dự phòng). Toàn bộ phân phối số liệu — trung vị (median), p10, p90, giá trị nhỏ nhất, giá trị lớn nhất, kích thước mẫu — đều có trên trang. Xem phương pháp luận để biết những số liệu đó đo được gì và không đo được gì.

Pipeline 2: Dịch chat thời gian thực

Vấn đề: Mọi tin nhắn chat trong cuộc họp cần được dịch cho mọi người tham gia bằng ngôn ngữ riêng của họ, ngay khi được gửi. Cộng thêm các chỉnh sửa — và các chỉnh sửa cần trông giống chỉnh sửa, không giống như những bản dịch lại từ đầu.

Ngân sách: Nhanh, nhưng không cần dưới một giây. Một tin nhắn chat có thể mất nửa giây để xuất hiện bằng ngôn ngữ khác mà không ai để tâm. Điều người dùng quan tâm là bản dịch có đúng hay không và các chỉnh sửa có hợp lý hay không.

Pipeline chat thực sự làm gì

Mỗi tin nhắn đi qua cùng công cụ dịch mà pipeline giọng nói sử dụng — nhưng với các bước xử lý trước và sau khác nhau:

• Cấu trúc HTML được giữ nguyên. Chat hỗ trợ văn bản định dạng phong phú (đoạn văn, danh sách, trích dẫn, chữ đậm, chữ nghiêng). Chúng tôi chuyển sang văn bản thuần cho mô hình, dịch, rồi bọc lại kết quả trong các thẻ gốc. Mô hình không bao giờ thấy mã HTML — nó chỉ thấy văn xuôi sạch.
• Trích dẫn được dịch độc lập. Nếu bạn trả lời một tin nhắn và trích dẫn nó, khối [QUOTE]…[/QUOTE] và nội dung mới sẽ được dịch như hai đơn vị riêng biệt, để mô hình không nhầm lẫn giữa hai phần này.
• Tin nhắn dài được chia nhỏ (chunk). Chúng tôi cắt theo ranh giới đoạn văn, tối đa 1.000 ký tự mỗi phần (chunk). Mỗi phần là một lượt gọi dịch riêng. Chúng tôi không đưa nguyên một "cuốn tiểu thuyết" 4.000 ký tự vào mô hình trong một lần — các kiểu lỗi có thể xảy ra (bị cắt cụt, mất đoạn văn, đứt giữa câu) quá tệ để chấp nhận.
• Việc dịch được thực hiện theo kiểu lazy (chỉ khi cần). Chúng tôi dùng IntersectionObserver: một tin nhắn chỉ được dịch khi nó cuộn vào vùng hiển thị (viewport) của người xem. Trước đây, việc đổi ngôn ngữ trong một kênh chat đã hoạt động lâu sẽ khiến toàn bộ lịch sử gọi API dịch được phát lại. Bây giờ thì không còn như vậy nữa.

Phần thú vị: chỉnh sửa dưới dạng diff

Trong v1.2, chúng tôi đã thay đổi cách các chỉnh sửa chat hiển thị đối với người xem dùng ngôn ngữ khác. Hành vi cũ là: ai đó chỉnh sửa một tin nhắn, chúng tôi dịch lại toàn bộ, và bạn thấy một đoạn văn hoàn toàn mới, phải tự tìm xem chỗ nào đã thay đổi.

Hành vi mới:

1. Tin nhắn gốc đã được dịch sang ngôn ngữ của bạn từ trước.
2. Khi người gửi chỉnh sửa, chúng tôi dịch lại phiên bản mới.
3. Chúng tôi tính toán sự khác biệt (diff) giữa bản dịch trước đó của bạn và bản dịch mới của bạn, bằng ngôn ngữ của bạn.
4. Chúng tôi hiển thị diff đó ngay trong văn bản — giống cách Git cho bạn thấy những gì đã thay đổi.

Vì vậy, khi "xem xét trước thứ Ba" trở thành "xem xét trước thứ Năm" trong tiếng Anh, đồng nghiệp đọc tiếng Tây Ban Nha của bạn sẽ thấy martes → jueves được đánh dấu nổi bật, thay vì một đoạn văn được dịch lại hoàn toàn mà họ phải đọc lại từ đầu.

Điều này đòi hỏi phải xử lý pipeline chat như một bộ nhớ đệm (cache) có trạng thái cho từng người xem, chứ không phải một endpoint dịch-theo-yêu-cầu không trạng thái. Tài liệu và giọng nói không cần điều này. Chat thì cần.

Pipeline 3: Dịch ghi chú chia sẻ thời gian thực

Vấn đề: Người chủ trì mở một khung ghi chú chia sẻ và bắt đầu gõ. Mọi người tham gia thấy ghi chú bằng ngôn ngữ của họ, theo từng ký tự, với cấu trúc của tài liệu — tiêu đề, danh sách lồng nhau, danh sách kiểm tra, khối mã — vẫn được giữ nguyên vẹn.

Ngân sách: Giống như chat (~nửa giây), nhưng có thêm hai ràng buộc:

• Nội dung cần dịch thay đổi ngay trong lúc đang dịch. Người chủ trì vẫn còn đang gõ. Một hệ thống ngây ngô dịch lại "toàn bộ tài liệu" sau mỗi lần gõ phím sẽ gây hiện tượng nhấp nháy (flicker) và đốt hết ngân sách gọi API. Chúng tôi dịch ở mức chi tiết của đơn vị đã thay đổi, không phải toàn bộ tài liệu.
• Cấu trúc phải được giữ nguyên. Nếu bạn yêu cầu một mô hình dịch một khối markdown với ba danh sách lồng nhau, bạn sẽ nhận lại thứ trông giống bản gốc nhưng với thứ bậc bị làm phẳng một cách khó nhận ra, các mục bị đánh số lại, hoặc thụt lề bị xáo trộn. Chúng tôi không để mô hình thấy toàn bộ khối văn bản.

Pipeline ghi chú khác pipeline chat như thế nào

Việc giữ nguyên cấu trúc là điều quan trọng nhất. Chúng tôi dịch từng mục danh sách một cách độc lập thay vì dịch như một tài liệu duy nhất. Mô hình chỉ thấy:

"Đánh giá tuân thủ — hạng mục cần giao Q2"

— không phải:

"# Kế hoạch dự án\n## Quý\n- Đánh giá tuân thủ — hạng mục cần giao Q2\n- Chấm điểm nhà cung cấp\n - Nhà cung cấp Tier 1..."

Tài liệu bao ngoài — thẻ <ul>, các tiêu đề, phần thụt lề — được dựng lại ở phía client, sử dụng đúng cấu trúc mà tài liệu gốc có, với mỗi nút lá (leaf node) được thay bằng bản dịch của nó. Mô hình không bao giờ có cơ hội "cải thiện" thứ bậc cấu trúc.

Ghi chú cũng dùng cùng mô hình diff riêng cho từng người xem như các chỉnh sửa chat: nếu người chủ trì thay đổi một dòng, người xem ở các ngôn ngữ khác sẽ thấy các từ đã thay đổi được đánh dấu nổi bật, không phải một đoạn văn hoàn toàn mới.

Pipeline 4: Dịch tài liệu bất đồng bộ

Vấn đề: Ai đó thả một tệp PDF 40 trang, một tài liệu Word, một bộ trình chiếu PowerPoint, hoặc một bảng tính Excel vào chat. Mỗi người tham gia có thể yêu cầu một bản sao bằng ngôn ngữ của riêng họ. Tệp đã dịch phải trông giống bản gốc — cùng phông chữ, cùng bảng, cùng số trang, cùng tiêu đề đầu trang, cùng các biểu đồ ở đúng vị trí.

Ngân sách: Không có ràng buộc thời gian thực. Một phút cũng được. Hai phút cũng được. Ràng buộc ở đây là độ trung thực — nếu tệp PDF đã dịch không trông giống bản gốc, người nhận sẽ không tin tưởng nó.

Vì sao pipeline này không dùng chung công cụ với giọng nói

Một LLM đa dụng, dù rất tốt, cũng chỉ trả lại cho bạn văn bản đã dịch của một tài liệu. Nó không trả lại một tệp PDF đã dịch với cùng bố cục. Mô hình không có khái niệm về "ngắt trang phải khớp với bản gốc" hay "ô trong bảng phải giữ đúng độ rộng cột."

Đối với tính năng này, chúng tôi sử dụng trực tiếp DeepL Document API. Công cụ này được thiết kế chuyên biệt để dịch tệp dưới dạng tệp, không phải văn bản trích xuất từ tệp. DeepL xử lý:

• PDF (giữ nguyên bố cục)
• DOCX, DOC
• PPTX
• XLSX

Tài liệu được tải lên pipeline của DeepL, dịch ở phía server với định dạng được giữ nguyên, và trả về dưới đúng định dạng ban đầu. Sau đó, chúng tôi tải kết quả lên object storage của mình và hiển thị lại trong chat dưới dạng tệp đính kèm có thể tải xuống.

Chi phí của việc này và vì sao chúng tôi không giấu nó

DeepL tính phí tối thiểu 50.000 ký tự cho mỗi tài liệu — tương đương khoảng một đô la Mỹ mỗi tệp ở hạng Pro, bất kể tài liệu có một trang hay ba mươi trang. Chúng tôi tự gánh chi phí này thay vì tính phí theo từng tệp; chi phí đó xuất hiện trong mức sử dụng dịch của cuộc họp dưới dạng số ký tự được tính phí, được chuyển đổi thành đơn vị từ (word-units) khớp với cách phần còn lại của sản phẩm báo cáo hoạt động dịch.

Chúng tôi chọn DeepL cho tính năng này vì dịch tệp dưới dạng tệp chính xác là công việc mà nó được xây dựng để làm — chúng tôi không cố xây một công cụ tốt hơn để làm việc đó. Điều ngược lại không đúng — DeepL không chạy một pipeline giọng nói trực tiếp như loại chúng tôi đã xây cho các cuộc họp. Vấn đề khác nhau; công cụ khác nhau. Phiên bản trung thực của câu hỏi "điều gì vận hành việc dịch của InterMIND" là "công cụ phù hợp cho mỗi pipeline" — không phải "công cụ của chúng tôi, ở mọi nơi."

Những ngôn ngữ pipeline này hỗ trợ mà giọng nói không có

Pipeline tài liệu hỗ trợ 30 ngôn ngữ, so với 23 ngôn ngữ ở giọng nói. Các ngôn ngữ bổ sung bao gồm: tiếng Bulgaria, tiếng Hy Lạp, tiếng Estonia, tiếng Indonesia, tiếng Litva, tiếng Latvia, tiếng Slovak, tiếng Slovenia. (Tiếng Ả Rập cũng thuộc danh sách này, và nó là một trong các ngôn ngữ bổ sung: nó bị rút khỏi bộ chọn thời gian thực vì chất lượng giọng nói của nó vẫn dưới mức tiêu chuẩn của chúng tôi, và điểm số theo từng cặp ngôn ngữ của nó vẫn được công khai tại /benchmark — con số đó chính là thứ sẽ đưa nó trở lại. Sự bất đối xứng diễn ra theo hướng ngược lại đối với tiếng Hindi — đã có ở giọng nói, nhưng chưa có ở tệp.)

Sự bất đối xứng đó là có thực. Nó có nghĩa là một người tham gia nói tiếng Pháp trong cuộc họp có thể yêu cầu tệp PDF hợp đồng bằng tiếng Estonia, dù họ không thể nghe cuộc họp bằng tiếng Estonia. Chúng tôi đánh dấu điều này rõ ràng trong bộ chọn thay vì che giấu nó bằng một con số duy nhất. Lý do được giải thích trong bài viết về số lượng ngôn ngữ.

Nơi các pipeline giao nhau

Bốn pipeline này không hoạt động riêng lẻ, tách biệt nhau. Một phòng họp là nơi chúng chạm vào nhau, và những đường nối đó rất quan trọng:

• Một tin nhắn chat có kèm tài liệu kích hoạt pipeline chat cho phần văn bản và pipeline tài liệu cho tệp đính kèm. Người tham gia dùng ngôn ngữ khác sẽ thấy tin nhắn được dịch ngay lập tức, và bản dịch của tệp đính kèm sẽ đến sau đó, dưới dạng bất đồng bộ, có thể tải xuống.
• Một ghi chú chia sẻ trích dẫn một dòng trong bản ghi lời nói (transcript) sẽ đi qua ranh giới giữa ghi chú và giọng nói. Bản ghi lời nói là thứ pipeline giọng nói đã tạo ra cho ngôn ngữ của người nói; bản dịch ghi chú sẽ tạo ra một bản sao riêng cho từng người xem của trích dẫn đó bằng ngôn ngữ của mỗi người, với nguồn trích dẫn được giữ nguyên.
• Một bản ghi lời nói được xuất ra sau cuộc họp sẽ chạy pipeline văn bản kiểu chat trên toàn bộ cuộc trò chuyện, tạo ra một tệp riêng cho từng ngôn ngữ mà người tham gia có thể tải xuống. Đây là cùng đường xử lý mã (code path) như dịch chat, chỉ khác là được xử lý theo lô (batch).

Bộ chọn ngôn ngữ chỉ là một phần của giao diện người dùng (UI). Hạ tầng bên dưới là bốn pipeline, đang trò chuyện với nhau.

Những điều chúng tôi cố tình không làm

• Không có "mô hình dịch thống nhất". Chúng tôi không xây dựng một mô hình duy nhất làm cả giọng nói, chat, ghi chú và tài liệu. Sự đánh đổi giữa độ trễ và độ trung thực không có bên thắng tuyệt đối. Chúng tôi dùng công cụ phù hợp cho từng tính năng.
• Không âm thầm định tuyến lại. Nếu pipeline tệp hiện tại không thể dịch sang tiếng Hindi, chúng tôi không lặng lẽ chuyển sang dùng công cụ giọng nói rồi giả vờ như nó hoạt động — bộ chọn tệp sẽ đánh dấu rõ khoảng trống đó thay vì che giấu.
• Không có tuyên bố "chúng tôi dịch sang 200 ngôn ngữ". Công cụ của chúng tôi tạo ra 24 ngôn ngữ. Các tính năng trực tiếp cung cấp 23, tài liệu cung cấp 30 — và thay vì đưa ra một con số dễ tiếp thị, chất lượng theo từng cặp ngôn ngữ — thứ phải đứng vững trước một người kiểm toán (auditor) — được công bố tại /benchmark, bao gồm cả những cặp ngôn ngữ yếu hơn.

Tự bạn hãy thử

• Thử bản demo trực tiếp — chạy pipeline giọng nói trực tiếp trên âm thanh của bạn, bằng bất kỳ ngôn ngữ nào trong 23 ngôn ngữ của sản phẩm. Cùng pipeline được chấm điểm tại /benchmark.
• Xem benchmark — chất lượng theo từng cặp ngôn ngữ, theo từng tháng, trên lưu lượng thực tế. Mọi cặp ngôn ngữ trong bộ chọn, mạnh hay yếu, đều có thể truy cập trực tiếp qua liên kết.
• Đọc phương pháp luận — các số liệu là gì, không phải là gì, và ai là người đánh giá (judge).

Bốn pipeline, bốn công cụ, một phòng họp. Đó là bản thay thế trung thực cho trang how-it-works cũ.

— Đội ngũ Mind.com

Nguồn: DeepL — các ngôn ngữ được hỗ trợ, DeepL — cách tính số lượng sử dụng và tính phí (mức tối thiểu 50.000 ký tự mỗi tệp), FLORES-200; các thông tin về pipeline nội bộ đã được xác minh dựa trên mã nguồn đã triển khai, kiểm tra vào tháng 8 năm 2026.