Bên trong bốn luồng dịch thuật vận hành InterMIND

Trang /product/overview/how-it-works cũ trên mind.com đã lỗi thời sau vài bản phát hành lớn. Nó mô tả một "công cụ dịch thuật" duy nhất giống như cách hầu hết các trang của nhà cung cấp làm — một mũi tên lớn từ "bạn nói" đến "họ nghe." Hình ảnh đó vốn đã là một sự đơn giản hóa từ hai năm trước. Ngày nay, nó là sai lệch.

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

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

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

Tại sao "một công cụ cho mọi thứ" là một lời nói dối

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

1. Giọng nói thời gian thực — âm thanh đầu vào, âm thanh dịch thuật đầu ra, dưới một giây, mỗi người xem bằng ngôn ngữ riêng của họ. Ràng buộc khó khăn nhất là độ trễ.
2. Văn bản trò chuyện 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ú chung thời gian thực — gõ phối hợp từng ký tự một, với hệ thống cấp bậc cấu trúc (danh sách, tiêu đề, hộp kiểm) phải được giữ nguyên qua quá trình dịch thuật.
4. Tệp tài liệu không đồng bộ — một tệp PDF 40 trang được thả vào trò chuyện. Không có ngân sách độ trễ. Ràng buộc khó khăn nhất là độ chính xác — định dạng, bảng, số trang, phông chữ.

Bạn có thể tạo một lệnh gọi LLM khổng lồ cố gắng thực hiện cả bốn nhiệm vụ. Chúng tôi đã thử. Nó tỏ ra kém cỏi ở cả bốn. Ngân sách độ trễ cho giọng nói có nghĩa là mô hình không thể "suy nghĩ"; ngân sách độ chính xác cho tài liệu có nghĩa là mô hình phải làm điều đó. Một chỉnh sửa trò chuyện cần một diff trong 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 truyền phát token nào có thể cung cấp cho bạn.

Vì vậy, chúng tôi chạy bốn luồng. Dưới đây là chi tiết từng luồng.

Luồng 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 họ, trong tai nghe của 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 kỳ điều gì vượt quá ~1,2 giây đều làm gián đoạn cuộc trò chuyện — mọi người bắt đầu nói đè lên bản dịch, và cuộc họp dần chuyển sang "chỉ cần đổi sang tiếng Anh thôi."

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

Một số điểm đáng được nêu đích danh:

• ASR chạy trong trình duyệt của người nói, không phải trên máy chủ trung tâm. Chúng tôi sử dụng Mind SDK cục bộ; điều này tiết kiệm một chuyến đi vòng và cung cấp cho chúng tôi bản chép ngôn ngữ nguồn với độ trễ thấp nhất có thể trước khi quá trình dịch thuật có thể bắt đầu.
• Dịch thuật không phải là một phân phối đơn lẻ. Chúng tôi duy trì một nhóm kết nối WebSocket đến công cụ dịch của mình, mỗi kết nối cho một ngôn ngữ đích có mặt trong phòng. Nếu ba người tham gia chọn tiếng Đức, tiếng Đức sẽ chia sẻ một kết nối. Nếu không ai chọn tiếng Ả Rập, sẽ không có kết nối tiếng Ả Rập nào được mở. Nhóm này loại bỏ các kết nối nhàn rỗi sau năm phút. Đó là lý do tại sao 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ữ, cho đến khi xét đến việc ai 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 lắng nghe.
• Giọng nói tổng hợp dành riêng cho từng người xem. Mỗi người tham gia nhận được luồng âm thanh dịch thuật của riêng họ, được trộn với video của người nói ban đầu. Họ không đang xem một "cuộc họp đã dịch" chung — họ đang xem cùng một cuộc họp, với kênh âm thanh cá nhân được dịch sang ngôn ngữ họ chọn. Đó là lý do tại sao hai người trong cùng một căn phòng vật lý có thể cắm tai nghe và nghe các ngôn ngữ khác nhau.

Tại sao điều này lại quan trọng khi một cuộc họp gặp trục trặc

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

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

Những gì chúng tôi công bố về chất lượng giọng nói: /benchmark chạy luồng giọng nói production dựa trên các câu FLORES-200 cho mỗi cặp ngôn ngữ được công bố, hàng tháng. Trọng tài được nêu tên (Gemini 2.5 Flash làm chính, Claude Sonnet 4 làm dự phòng). Phân phối đầy đủ — trung vị, p10, p90, tối thiểu, tối đa, kích thước mẫu — đều có trên trang. Xem phương pháp luận để biết những con số đó đo được và không đo được điều gì.

Luồng 2: Dịch trò chuyện thời gian thực

Vấn đề: Mọi tin nhắn trò chuyện trong cuộc họp, được dịch cho mỗi người tham gia bằng ngôn 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 như chỉnh sửa, chứ không phải như các bản dịch lại.

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

Luồng trò chuyện thực tế thực hiện những gì

Mỗi tin nhắn đi qua cùng một công cụ dịch mà luồng giọng nói sử dụng — nhưng với quá trình tiền xử lý và hậu xử lý khác nhau:

• Cấu trúc HTML được giữ nguyên. Trò chuyện hỗ trợ văn bản phong phú (đoạn văn, danh sách, trích dẫn, in đậm, in nghiêng). Chúng tôi chuyển đổi thành văn bản thuần túy cho mô hình, dịch, sau đó bọc kết quả lại bằng các thẻ gốc. Mô hình không bao giờ thấy HTML — nó thấy văn bản thuần tịnh.
• Các 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 được dịch như các đơn vị riêng biệt, do đó mô hình không thể nhầm lẫn giữa hai phần.
• Các tin nhắn dài được chia nhỏ. Chúng tôi chia nhỏ tại các ranh giới đoạn văn với 1.000 ký tự mỗi phần. Mỗi phần là một lệnh gọi dịch thuật riêng. Chúng tôi không cung cấp các cuốn tiểu thuyết 4.000 ký tự cho mô hình trong một lần — các chế độ lỗi (cắt bớt, mất đoạn văn, cắt giữa câu) là quá tồi tệ.
• Quá trình dịch thuật diễn ra lười biếng. Chúng tôi sử dụng IntersectionObserver: một tin nhắn chỉ được dịch khi nó cuộn vào khung nhìn của người xem. Việc chuyển đổi ngôn ngữ trong một kênh chạy dài trước đây từng phải phát lại mọi lệnh gọi API dịch thuật từ lịch sử. Giờ thì không còn nữa.

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

Trong phiên bản v1.2, chúng tôi đã thay đổi cách các chỉnh sửa trò chuyện hoạt động đối với người xem bằng ngôn ngữ khác. Hành vi cũ là: một ai đó chỉnh sửa tin nhắn, chúng tôi dịch lại toàn bộ, bạn thấy một đoạn văn hoàn toàn mới và phải tự tìm xem điều gì đã thay đổi.

Hành vi mới:

1. Tin nhắn gốc đã được dịch sang ngôn ngữ của bạn.
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 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 đó nội tuyến — giống như cách Git hiển thị cho bạn những gì đã thay đổi.

Vì vậy, khi "review by Tuesday" trở thành "review by Thursday" trong tiếng Anh, đồng nghiệp đọc tiếng Tây Ban Nha của bạn sẽ thấy martes → jueves được làm nổi bật, chứ không phải một đoạn văn được dịch lại mà họ phải đọc lại từ đầu.

Điều này đòi hỏi việc xử lý luồng trò chuyện như một bộ nhớ đệm có trạng thái (stateful) theo 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 (stateless). Tài liệu và giọng nói không cần điều này. Trò chuyện thì có.

Luồng 3: Dịch ghi chú chung thời gian thực

Vấn đề: Người chủ trì mở một ngăn ghi chú chung và bắt đầu gõ. Mỗi người tham gia thấy các ghi chú bằng ngôn ngữ của họ, từng ký tự mộ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ã — được giữ nguyên vẹn.

Ngân sách: Giống như trò chuyện (~nửa giây), nhưng với hai ràng buộc bổ sung:

• Thứ đang được dịch thay đổi ngay giữa quá trình dịch. Người chủ trì vẫn đang gõ. Một hệ thống ngây thơ dịch "toàn bộ tài liệu" tại mỗi lần gõ phím sẽ tạo ra hiện tượng nhấp nháy và tiêu tốn ngân sách API. Chúng tôi dịch ở mức độ chi tiết của đơn vị thay đổi, chứ 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 thuật dịch một khối markdown với ba danh sách lồng nhau, bạn sẽ nhận lại một thứ trông giống bản gốc nhưng với hệ thống cấp bậc bị san phẳng một cách tinh tế, các mục được đánh số lại, hoặc thụt lề bị thay đổi. Chúng tôi không để mô hình thấy toàn bộ khối.

Luồng ghi chú khác với trò chuyện như thế nào

Việc giữ nguyên cấu trúc là điều chính yếu. Chúng tôi dịch mỗi mục trong 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 thấy:

"Đánh giá tuân thủ — Các kết quả bàn giao Q2"

— chứ không phải:

"# Kế hoạch dự án\n## Quý\n- Đánh giá tuân thủ — Các kết quả bàn giao Q2\n- Chấm điểm nhà cung cấp\n - Nhà cung cấp Tier 1..."

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

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

Luồng 4: Dịch tài liệu không đồng bộ

Vấn đề: Một ai đó thả một tệp PDF 40 trang, một tài liệu Word, một bản trình bày PowerPoint, hoặc một bảng tính Excel vào trò chuyện. 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 như bản gốc — cùng phông chữ, cùng bảng, cùng số trang, cùng tiêu đề, cùng biểu đồ tại chỗ.

Ngân sách: Không có ràng buộc thời gian thực. Một phút là ổn. Hai phút cũng ổn. Ràng buộc là độ chính xá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ó.

Tại sao luồng này không chia sẻ công cụ với giọng nói

Một LLM mục đích chung, ngay cả một mô hình rất tốt, cũng sẽ trả lại cho bạn văn bản đã dịch của một tài liệu. Nó sẽ không trả lại cho bạn một 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 nguồn" hoặc "ô bảng phải giữ nguyên độ rộng cột."

Cho bề mặt này, chúng tôi sử dụng trực tiếp DeepL Document API. Nó được xây dựng chuyên biệt để dịch tệp như các tệp, chứ không phải văn bản được 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 luồng của DeepL, dịch ở phía máy chủ với định dạng nguyên vẹn, và trả về dưới cùng định dạng đó. Sau đó, chúng tôi tải kết quả lên bộ nhớ đối tượng (object storage) của mình và hiển thị lại trong trò chuyện dưới dạng tệp đính kèm có thể tải xuống.

Điều này tốn kém bao nhiêu và tại sao chúng tôi không che giấu nó

DeepL tính phí tối thiểu 50.000 ký tự cho mỗi tài liệu — khoảng một đô la Mỹ cho mỗi tệp trên gói Pro, bất kể tài liệu dài một trang hay ba mươi trang. Chúng tôi gánh vác chi phí đó thay vì tính phí theo từng tệp; nó thể hiện trong mức sử dụng dịch thuật của cuộc họp dưới dạng ký tự đã thanh toán, được chuyển đổi sang đơn vị từ 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 thuật.

Chúng tôi chọn DeepL cho bề mặt này vì việc dịch tệp như các tệp chính xác là công việc nó được tạo ra để làm — chúng tôi đã không cố gắng xây dựng một công cụ tốt hơn. Điều ngược lại thì không đúng — DeepL không chạy luồng giọng nói trực tiếp kiểu như cái chúng tôi đã xây dựng 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ái gì đang vận hành dịch thuật InterMIND" là "công cụ phù hợp cho từng luồng" — chứ không phải "công cụ của chúng tôi, ở mọi nơi."

Những ngôn ngữ mà luồng này bao phủ nhưng giọng nói thì không

Luồng tài liệu tiếp cận 30 ngôn ngữ, so với 24 ngôn ngữ của 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 từng nằm trong danh sách này khi chất lượng giọng nói của nó dưới tiêu chuẩn của chúng tôi; hiện nó đã có trong bộ chọn thời gian thực, với điểm số theo từng cặp được công khai trên /benchmark giống như mọi ngôn ngữ khác. Sự bất đối xứng hiện nay ngược lại đối với tiếng Hindi — trực tiếp trên giọng nói, nhưng chưa có trên tệp.)

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

Nơi các luồng giao nhau

Bốn luồng không chạy trong sự cô lập. Một phòng họp là nơi chúng chạm vào nhau, và các đường nối rất quan trọng:

• Một tin nhắn trò chuyện có tệp đính kèm tài liệu kích hoạt luồng trò chuyện cho văn bản và luồng tài liệu cho tệp. Người tham gia bằng ngôn ngữ khác 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 đến không đồng bộ dưới dạng tệp có thể tải xuống.
• Một ghi chú chung trích dẫn một dòng bản chép lại vắt ngang qua ghi chú ↔ giọng nói. Bản chép là những gì luồng giọng nói đã tạo ra cho ngôn ngữ của người gửi; bản dịch ghi chú tạo ra một bản sao của trích dẫn đó cho từng người xem bằng ngôn ngữ của những người khác, với nguồn gốc được giữ nguyên.
• Một bản chép được xuất ra sau cuộc họp chạy luồng văn bản kiểu trò chuyện trên toàn bộ cuộc hội thoại, tạo ra một tệp cho từng ngôn ngữ mà những người tham gia có thể tải xuống. Đây là cùng một đường dẫn mã như dịch trò chuyện, chỉ khác là được xử lý theo lô.

Bộ chọn ngôn ngữ là một thành phần UI duy nhất. Cơ sở hạ tầng bên dưới là bốn luồng, đang giao tiếp với nhau.

Những gì chúng tôi cố tình không thử

• Không có "mô hình dịch thuật thống nhất." Chúng tôi không xây dựng một mô hình duy nhất làm giọng nói, trò chuyện, ghi chú và tài liệu. Sự đánh đổi giữa độ trễ và độ chính xác không có người chiến thắng. Chúng tôi sử dụng công cụ phù hợp cho từng bề mặt.
• Không có việc chuyển hướng ngầm. Nếu luồng tệp không thể dịch sang tiếng Hindi ngày hôm nay, chúng tôi không âm thầm dự phòng sang công cụ giọng nói và giả vờ nó hoạt động — bộ chọn tệp đánh dấu khoảng trống đó thay vì che giấu nó.
• Không có "chúng tôi dịch sang 200 ngôn ngữ." Công cụ của chúng tôi xuất ra 24. Các bề mặt trực tiếp gửi đi tất cả 24, tài liệu là 30 — và thay vì một con số thân thiện với tiếp thị, chất lượng theo từng cặp phải đứng trước một người kiểm toán được công khai tại /benchmark, bao gồm cả các cặp yếu hơn.

Tự mình dùng thử

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

Bốn luồng, bốn công cụ, một phòng họp. Đó là sự 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 — số lần sử dụng và thanh toán (mức tối thiểu 50.000 ký tự mỗi tệp), FLORES-200; các sự thật về luồng nội bộ được xác minh dựa trên mã nguồn đã phát hành, kiểm tra vào tháng 8 năm 2026.