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

Trang /product/overview/how-it-works cũ trên mind.com đã lạc hậu nhiều phiên bản lớn. Trang này mô tả một "engine dịch" duy nhất, giống hầu hết các trang của nhà cung cấp: một mũi tên lớn từ "bạn nói" đến "họ nghe". Hai năm trước, bức tranh đó đã là một sự đơn giản hóa. Ngày nay nó là sai.

Sự thật là InterMIND chạy bốn pipeline dịch thuật riêng biệt. Mỗi pipeline giải quyết một bài toán khác nhau, với engine khác, ngân sách độ trễ khác và mức chất lượng khác. Chúng dùng chung bộ chọn ngôn ngữ. Chúng không dùng chung engine.

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

Bài viết đi kèm: "Bạn hỗ trợ bao nhiêu ngôn ngữ?" nói về phạm vi mà mỗi pipeline bao phủ (23 / 23 / 30 / 17). Bài này nói về việc mỗi pipeline làm gì, và vì sao nó là một thành phần riêng.

Vì sao "một engine cho mọi thứ" là một lời nói dối

Một nền tảng họp trực tiếp phải làm ít nhất bốn việc cùng lúc, và các việc này kéo về những hướng không thể dung hòa:

1. Giọng nói theo thời gian thực — âm thanh vào, âm thanh đã dịch ra khi người nói vẫn đang nói, mỗi người xem nghe bằng ngôn ngữ của riêng mình. Ràng buộc khắt khe nhất là độ trễ.
2. Chat văn bản theo thời gian thực — tin nhắn ngắn, nhanh, giữ nguyên chỉnh sửa, trích dẫn và cấu trúc HTML.
3. Ghi chú chung theo thời gian thực — gõ cộng tác từng ký tự, với cấu trúc phân cấp (danh sách, tiêu đề, hộp kiểm) phải được giữ nguyên sau khi 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ắt khe nhất là độ trung thực: định dạng, bảng biểu, số trang, phông chữ.

Bạn có thể xây một lệnh gọi LLM khổng lồ để làm cả bốn việc. Chúng tôi đã thử. Nó làm cả bốn đều tệ. Ngân sách độ trễ của 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 của tài liệu lại đòi hỏi mô hình phải suy nghĩ. Một lần chỉnh sửa chat cần một bản diff bằng ngôn ngữ của người xem; một tệp PDF 40 trang cần giữ nguyên định dạng, điều mà không mô hình phát token theo luồng nào làm được.

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

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

Bài toán: Một người tham gia nói tiếng Pháp. Người thứ hai vào bằng tiếng Đức, người thứ ba bằng tiếng Bồ Đào Nha của 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 mình, trong tai của mình, với độ trễ đủ ngắn để vẫn có thể giao tiếp bằng mắt.

Ngân sách: người nghe không bao giờ phải chờ. Khi giọng đã dịch trễ đến mức mọi người bắt đầu nói chen lên, cuộc họp sẽ trượt dần về "thôi dùng tiếng Anh đi".

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

Một vài điểm cần nêu rõ:

• ASR chạy trên máy chủ media. Âm thanh của người nói đi qua WebRTC đến engine của chúng tôi — Mind API tại OVH, Pháp — và được nhận dạng ngay tại đó, trên cùng máy chủ đang đảm nhiệm cuộc gọi; trình duyệt chỉ gửi âm thanh và nhận lại các từ. Không có nhà cung cấp giọng nói riêng và không có thêm bước trung gian nào trước khi việc dịch có thể bắt đầu. (Tin nhắn thoại trong chat là ngoại lệ: phần chuyển giọng nói thành văn bản của chúng chạy trên Azure AI Speech, dịch vụ giọng nói của cổng AI mặc định.)
• Dịch không phải là một lần phát tán duy nhất. Engine dịch theo từng ngôn ngữ đích có trong phòng, không theo từng người xem: việc dịch sang một ngôn ngữ bắt đầu khi người nghe đầu tiên bằng ngôn ngữ đó yêu cầu luồng đã dịch, ba người chọn tiếng Đức dùng chung một bản dịch tiếng Đức, và nếu không ai nghe bằng tiếng Ả Rập thì không có gì được dịch sang tiếng Ả Rập. Vì thế một cuộc họp bốn ngôn ngữ có chi phí tương đương một cuộc họp bốn mươi ngôn ngữ, tùy theo ai thực sự có mặt — chúng tôi không bao giờ dịch sang ngôn ngữ mà không người tham gia nào đang nghe.
• Giọng tổng hợp là theo từng người xem. Mỗi người tham gia nhận luồng âm thanh đã dịch của riêng mình, được trộn với video của người nói gốc. Họ không xem một "cuộc họp đã dịch" chung — họ 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 hai người ngồi chung một phòng thực có thể mỗi người đeo tai nghe 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 trục trặc

Trong một cuộc gọi 60 phút với tám ngôn ngữ, mọi thứ có thể hỏng theo những cách thú vị: WebSocket bị rớt, ASR tạm thời nhận sai một danh từ riêng, mạng của một người tham gia chập chờn. Kiến trúc nêu trên là thứ giúp chúng tôi cô lập sự cố: â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, vì engine dịch vốn không bao giờ tạo ra "bản dịch" duy nhất — nó tạo ra tám bản song song, và chỉ bản bị ảnh hưởng phải phục hồi.

Bản thân engine là của chúng tôi, được đặt trên hạ tầng của chúng tôi. Chúng tôi không đưa 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 chúng ra; yêu cầu về lưu trú dữ liệu cũng loại chúng ra đối với các khách hàng chịu quy định nghiêm ngặt, những người thực sự quan tâm.

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 production trên các câu của FLORES-200 cho mọi cặp ngôn ngữ đã công bố, hằng tháng. Bộ chấm điểm được nêu tên (Gemini 3.7 Flash là chính, Claude Sonnet 5 là dự phòng). Toàn bộ phân phối — trung vị, p10, p90, nhỏ nhất, lớn nhất, cỡ mẫu — đều có trên trang. Xem phương pháp luận để biết các con số đó đo được gì và không đo được gì.

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

Bài toán: Mỗi tin nhắn chat trong cuộc họp được dịch cho từng 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à chỉnh sửa phải trông như chỉnh sửa, chứ không phải như một bản dịch lại.

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

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

Mỗi tin nhắn đi qua cùng engine dịch mà pipeline giọng nói dùng, nhưng với khâu tiền xử lý và hậu xử lý khác:

• Cấu trúc HTML được giữ nguyên. Chat hỗ trợ văn bản có định dạng (đoạn, danh sách, trích dẫn, in đậm, in 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ả bằng các thẻ gốc. Mô hình không bao giờ nhìn thấy 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 được dịch như hai đơn vị riêng, để mô hình không thể nhầm lẫn giữa chúng.
• Tin nhắn dài được chia nhỏ. Chúng tôi tách theo ranh giới đoạn văn ở mức 1.000 ký tự mỗi phần. Mỗi phần là một lệnh gọi dịch riêng. Chúng tôi không đưa những "tiểu thuyết" 4.000 ký tự cho mô hình trong một lần — các kiểu lỗi (bị cắt cụt, mất đoạn, ngắt giữa câu) quá tệ.
• Dịch theo kiểu lười (lazy). Chúng tôi 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. Trước đây, việc đổi ngôn ngữ trong một kênh hoạt động lâu ngày sẽ phát lại mọi lệnh gọi API dịch từ lịch sử. Giờ thì không còn như vậy.

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

Ở v1.2, chúng tôi đã thay đổi cách chỉnh sửa chat hoạt động với người xem dùng ngôn ngữ khác. Hành vi cũ là: ai đó sửa một tin nhắn, chúng tôi dịch lại toàn bộ, bạn thấy một đoạn mới tinh 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 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 dòng — giống cách Git cho bạn thấy điều 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 tô sáng, thay vì một đoạn văn dịch lại mà họ phải đọc lại từ đầu.

Điều này đòi hỏi coi pipeline chat là một bộ nhớ đệm có trạng thái theo từng người xem, chứ không phải một endpoint dịch không trạng thái theo từng yêu cầu. 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ú chung theo thời gian thực

Bài toán: Người chủ trì mở khung ghi chú chung và bắt đầu gõ. Mỗi người tham gia thấy ghi chú bằng ngôn ngữ của mình, từng ký tự một, với cấu trúc tài liệu — tiêu đề, danh sách lồng nhau, danh sách việc cần làm, khối mã — còn nguyên vẹn.

Ngân sách: Giống chat, nhưng có thêm hai ràng buộc:

• Thứ đang được dịch thay đổi ngay trong lúc 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" ở mỗi lần nhấn phím sẽ gây nhấp nháy và đốt sạch ngân sách 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 phân cấp bị làm phẳng một cách tinh vi, các mục bị đánh số lại hoặc thụt lề bị dịch chuyển. Chúng tôi không để mô hình nhìn thấy toàn bộ khối đó.

Pipeline ghi chú khác chat ở điểm nào

Điểm chính là việc bảo toàn cấu trúc. 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. Mô hình thấy:

"Compliance review — Q2 deliverables"

— chứ không phải:

"# Project plan\n## Quarter\n- Compliance review — Q2 deliverables\n- Vendor scoring\n - Tier 1 vendors..."

Tài liệu bao quanh — thẻ <ul>, các tiêu đề, phần thụt lề — được dựng lại ở phía client theo đúng cấu trúc mà tài liệu gốc có, với mỗi nút lá đượ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" phân cấp.

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

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

Bài toán: Ai đó thả một tệp PDF 40 trang, một tài liệu Word, một bộ slide PowerPoint hoặc một bảng 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 mình. Tệp đã dịch phải trông giống bản gốc — cùng phông chữ, cùng bảng biểu, cùng số trang, cùng tiêu đề đầu trang, các biểu đồ vẫn nằm đúng 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à độ trung thực — nếu tệp PDF đã dịch không giống bản gốc, người nhận sẽ không tin nó.

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

Một LLM đa dụng, dù rất giỏi, sẽ trả cho bạn một văn bản đã dịch của tài liệu. Nó sẽ không trả cho bạn 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 "ô bảng phải giữ nguyên độ rộng cột".

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

Chi phí này là bao nhiêu và vì sao chúng tôi không giấu

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ỹ mỗi tệp ở gói Pro, bất kể tài liệu dài một trang hay ba mươi trang. Chúng tôi tự chịu chi phí này thay vì tính phí theo tệp; nó hiện trong mức sử dụng dịch của cuộc họp dưới dạng ký tự đã tính phí, được quy đổ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.

Chúng tôi chọn DeepL cho bề mặt này vì dịch tệp như là tệp chính là việc nó được tạo ra để làm — chúng tôi không cố xây một thứ tốt hơn. Chiều ngược lại thì không đúng: DeepL không vận hành 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. Bài toán khác nhau; công cụ khác nhau. Câu trả lời trung thực cho "điều gì vận hành bản dịch của InterMIND" là "engine phù hợp cho từng pipeline" — chứ không phải "engine của chúng tôi, ở mọi nơi".

Những ngôn ngữ pipeline này bao phủ mà giọng nói thì không

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

Sự bất đối xứng đó là có thật. Nó có nghĩa là một người tham gia người Pháp trong cuộc họp có thể yêu cầu bản 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 trong bộ chọn thay vì che đi bằng một con số duy nhất. Lý do được trình bày trong bài về số lượng ngôn ngữ.

Nơi các pipeline gặp nhau

Bốn pipeline không chạy cô lập. Phòng họp là nơi chúng chạm vào nhau, và các điểm nối đó rất quan trọng:

• Một tin nhắn chat kèm tài liệu đính kèm kích hoạt pipeline chat cho phần văn bản và pipeline tài liệu cho tệp. Người tham gia dùng ngôn ngữ khác thấy tin nhắn được dịch ngay lập tức, còn bản dịch của tệp đính kèm đến sau, bất đồng bộ, dưới dạng tệp có thể tải về.
• Một ghi chú chung trích dẫn một dòng của bản ghi đi qua cả ghi chú ↔ giọng nói. Bản ghi là thứ pipeline 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 đoạn trích đó cho từng người xem bằng ngôn ngữ của những người còn lại, với phần ghi nguồn được giữ nguyên.
• Bản ghi được xuất sau cuộc họp 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 theo từng ngôn ngữ để người tham gia tải về. Đây là cùng đường mã với dịch chat, chỉ khác là chạy theo lô.

Bộ chọn ngôn ngữ là một mảnh giao diện. Hạ tầng bên dưới là bốn pipeline, trò chuyện với nhau.

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

• Không có "mô hình dịch thống nhất". Chúng tôi không xây một mô hình duy nhất làm 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ó người thắng. Chúng tôi dùng engine phù hợp cho từng bề mặt.
• Không định tuyến lại âm thầm. Nếu pipeline tệp hôm nay không thể dịch sang tiếng Hindi, chúng tôi không lặng lẽ chuyển sang engine giọng nói rồi giả vờ là đã xong — bộ chọn tệp đánh dấu khoảng trống đó thay vì giấu nó.
• Không có "chúng tôi dịch sang 200 ngôn ngữ". Engine của chúng tôi cho ra 24. Các bề mặt trực tiếp có 23, tài liệu có 30 — và thay vì một con số đẹp cho tiếp thị, chất lượng theo từng cặp ngôn ngữ, thứ phải đứng vững trước kiểm toán viên, được công bố tại /benchmark, kể cả các cặp yếu hơn.

Tự mình thử

• Dùng 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. Chính pipeline này tạo ra điểm số trên /benchmark.
• Xem benchmark — chất lượng theo từng cặp, từng tháng, trên lưu lượng thực. Mọi cặp trong bộ chọn, mạnh hay yếu, đều có thể liên kết trực tiếp.
• Đọc phương pháp luận — các con số là gì, không phải là gì, và ai là bộ chấm điểm.

Bốn pipeline, bốn engine, 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 — cách đếm mức sử dụng và tính phí (mức tối thiểu 50.000 ký tự cho mỗi tệp), FLORES-200; các thông tin nội bộ về pipeline được đối chiếu với mã đã phát hành, kiểm tra vào tháng 8 năm 2026.