揭秘驱动 InterMIND 的四大翻译流水线

mind.com 上旧的 /product/overview/how-it-works 页面已经落后了几个主要版本。它像大多数供应商的页面一样，描述了一个单一的“翻译引擎”——从“您说话”到“他们听到”的一根大箭头。这张图在两年前就已经是一种简化了。今天它是错的。

事实是，InterMIND 运行着四条独立的翻译流水线，每条流水线使用不同的引擎、不同的延迟预算和不同的质量标准来解决不同的问题。它们共享一个语言选择器，但不共享引擎。

这是对“它是如何工作的”这一问题的最新解答。

伴随文章：“您支持多少种语言？” 介绍了每条流水线涵盖的内容（23 / 23 / 30 / 17）。本文则介绍了每条流水线所做的工作——以及为什么它们各自独立。

为什么“一个引擎包揽一切”是一个谎言

一个实时会议平台至少要同时完成四项工作，而这些工作在方向上是互不兼容的：

1. 实时语音 —— 音频输入，翻译后的音频输出，延迟在一秒以内，每位观众都能听到自己的语言。核心约束是延迟。
2. 实时聊天文本 —— 短消息，快速，保留编辑、引用和 HTML 结构。
3. 实时共享笔记 —— 逐字符的协同输入，具有必须在翻译后依然保持的结构层次（列表、标题、复选框）。
4. 异步文档文件 —— 投递到聊天中的 40 页 PDF。没有延迟预算。核心约束是保真度 —— 格式、表格、页码、字体。

您可以构建一个巨大的 LLM 调用来尝试完成这四项工作。我们试过。结果它在这四方面都表现糟糕。语音的延迟预算意味着模型没有时间“思考”；而文档的保真度预算又要求模型必须“思考”。聊天编辑需要以观众的语言生成差异（diff）；而 40 页的 PDF 需要格式保留，这是任何 token 流式模型都无法提供的。

因此我们运行了四条流水线。以下是每一条的介绍。

流水线 1：实时语音翻译

问题： 一位参与者说法语。另一位参与者加入时使用德语，第三位使用巴西葡萄牙语，第四位使用日语。每个人都需要以自己的语言、在自己的耳朵里听到发言者的声音，且延迟要足够短，以保持眼神交流。

预算： 端到端低于一秒。超过约 1.2 秒，对话就会中断——人们开始在翻译之上发言，会议会向“我们还是改说英语吧”的方向偏移。

音频的实际传输方式

有几点值得明确指出：

• ASR 在媒体服务器上运行。 发言者的音频通过 WebRTC 传输到我们自己的引擎——位于法国 OVH 的 Mind API——并在承载该通话的同一台服务器上进行识别；浏览器只发送音频并接收返回的文字。没有单独的语音供应商，也没有在翻译开始前的额外跳转。（聊天语音笔记是例外：其语音转文本运行在 Azure AI Speech 上，即默认 AI 网关的语音服务。）
• 翻译不是单一扇出（fan-out）。 引擎是按房间内存在的每种目标语言进行翻译，而不是按观众进行翻译：当某种语言的第一个听众请求翻译流时，就开始翻译成该语言，选择了德语的三名参与者共享一份德语翻译，而如果没人在听阿拉伯语，就意味着不需要翻译成阿拉伯语。这就是为什么一场四语言的会议与一场四十语言的会议成本相同，只要参与者实际需要的语言数量一样——我们从不会翻译成没有参与者在听的任何语言。
• 合成语音是按观众生成的。 每位参与者都会收到自己翻译后的音轨，并与原始发言者的视频混合。他们观看的不是主“翻译会议”——他们观看的是同一场会议，只是将他们的个人音频频道翻译成了他们选择的语言。这就是为什么在同一物理房间里的两个人可以各自戴上耳机并听到不同的语言。

当会议出现问题时这为何重要

在一场使用八种语言的 60 分钟通话中，事情会以各种有趣的方式出错：WebSocket 断开，ASR 暂时拼错专有名词，某个参与者的网络出现抖动。上述架构让我们得以隔离故障：一个观众的音频出现卡顿不会影响其他七位，因为翻译引擎从一开始就不仅仅产生“一份翻译”——它并行产生了八份，只有受影响的那一份需要恢复。

引擎本身是我们的，托管在我们自己的基础设施上。我们不会通过第三方通用 LLM 路由实时语音。延迟预算将它们排除在外；对于真正在意数据驻留的受监管客户，数据驻留的要求也将它们排除在外。

我们公布的语音质量数据： /benchmark 每月针对每个已发布的语言对，使用 FLORES-200 句子运行生产环境的语音流水线。评判模型已公开指定（Gemini 3.7 Flash 为主，Claude Sonnet 5 为备）。完整的分布数据——中位数、p10、p90、最小值、最大值、样本量——均展示在页面上。请参阅方法论了解这些数字能衡量什么、不能衡量什么。

流水线 2：实时聊天翻译

问题： 会议中的每一条聊天消息，在发送时都要为每位参与者翻译成他们自己的语言。加上编辑——而且编辑需要看起来像编辑，而不是像重新翻译。

预算： 快，但不需要低于一秒。一条聊天消息花半秒钟以另一种语言显示，没有任何人会在意。人们在意的是翻译是否正确，以及编辑是否有意义。

聊天流水线的实际工作方式

每条消息都经过与语音流水线相同的翻译引擎——但使用了不同的预处理和后处理：

• 保留 HTML 结构。 聊天支持富文本（段落、列表、引用、粗体、斜体）。我们将其转换为纯文本供模型翻译，然后用原始标签将结果重新包裹。模型永远不会看到 HTML——它只看到干净的文本。
• 引用被独立翻译。 如果您回复一条消息并引用它，[QUOTE]…[/QUOTE] 块和新内容会作为独立的单元进行翻译，这样模型就不会将两者混淆。
• 长消息被分块。 我们按段落边界在每块 1,000 个字符处进行拆分。每个块都是独立的翻译调用。我们不会将 4,000 个字符的长篇大论一次性喂给模型——其失败模式（截断、丢失段落、句子中途截断）太难看。
• 翻译是惰性加载的。 我们使用 IntersectionObserver：仅当消息滚动到观看者的视口中时才会被翻译。过去，在长时间运行的频道中切换语言需要重放历史记录中的每一次翻译 API 调用。现在不需要了。

有趣的部分：以差异（diff）形式呈现编辑

在 v1.2 版本中，我们更改了聊天编辑对其他语言观看者的显示行为。旧的行为是：有人编辑一条消息，我们重新翻译整条消息，您看到一个全新的段落，并且必须自己找出变动的地方。

新的行为：

1. 原始消息已经被翻译成您的语言。
2. 当发送者编辑时，我们重新翻译新版本。
3. 我们在您的语言下，计算您之前的翻译和您的新翻译之间的差异（diff）。
4. 我们内联显示该差异——就像 Git 向您展示更改的内容一样。

因此，当英语中的 "review by Tuesday" 变为 "review by Thursday" 时，阅读西班牙语的同事会看到高亮显示的 martes → jueves，而不是他们必须重新阅读的重新翻译的段落。

这要求将聊天流水线视为一个有状态的按观看者缓存，而不是无状态的按需翻译端点。文档和语音不需要这样做。聊天需要。

流水线 3：实时共享笔记翻译

问题： 主持人打开共享笔记窗格并开始输入。每位参与者都以自己的语言逐字符地看到笔记，并且文档的结构——标题、嵌套列表、核对列表、代码块——保持完整。

预算： 与聊天相同（约半秒），但有两个额外约束：

• 被翻译的内容在翻译过程中发生变化。 主持人仍在输入。如果一个天真的系统在每次击键时翻译“整个文档”，就会产生闪烁并耗尽 API 预算。我们以更改单元的粒度进行翻译，而不是整个文档。
• 结构必须保留。 如果您要求翻译模型翻译一个包含三个嵌套列表的 markdown 文本块，您得到的东西看起来像原件，但层级被微妙地扁平化，项目被重新编号，或者缩进被移动。我们不让模型看到整个文本块。

笔记流水线与聊天的区别

结构保留是主要区别。我们独立翻译每个列表项，而不是作为一个整体文档。模型看到的是：

"合规审查 —— Q2 交付物"

—— 而不是：

"# 项目计划\n## 季度\n- 合规审查 —— Q2 交付物\n- 供应商评分\n - 一级供应商..."

外层文档——<ul>、标题、缩进——是在客户端使用原始文档相同的结构重建的，每个叶子节点被替换为其翻译。模型永远无法“改进”层级结构。

笔记也使用了与聊天编辑相同的按观看者差异模型：如果主持人更改了一行，其他语言的观看者会看到更改的单词被高亮显示，而不是一个全新的段落。

流水线 4：异步文档翻译

问题： 有人在聊天中投入了一份 40 页的 PDF、Word 文档、PowerPoint 演示文稿或 Excel 表格。每位参与者都可以请求一份自己语言的副本。翻译后的文件必须看起来像原件——相同的字体、相同的表格、相同的页码、相同的页眉、相同的图表位置。

预算： 没有实时约束。一分钟可以。两分钟也可以。约束在于保真度——如果翻译后的 PDF 看起来不像原件，收件人就不会信任它。

为什么这条流水线不与语音共享引擎

通用的 LLM，即使是非常好的模型，也会向您返回文档的翻译文本。它不会向您返回保持相同布局的翻译后 PDF。模型没有“分页符必须与源文件对齐”或“表格单元格必须保持其列宽”的概念。

对于此场景，我们直接使用 DeepL Document API。它是专门为将文件作为文件进行翻译而构建的，而不是从文件中提取文本进行翻译。DeepL 处理：

• PDF（保留布局）
• DOCX, DOC
• PPTX
• XLSX

文档被上传到 DeepL 的流水线，在服务器端进行翻译且格式保持不变，并以相同的格式返回。然后，我们将结果上传到我们的对象存储中，并在聊天中将其作为可下载的附件展示。

这需要多少成本以及我们为何不隐瞒它

DeepL 对每个文档最少收取 50,000 个字符的费用——在 Pro 版本上大约每文件一美元，无论文档是一页还是三十页。我们承担了这笔成本，而不是按文件收费；它以计费字符的形式显示在会议的翻译使用量中，并转换为与产品其余部分报告翻译活动方式相匹配的单词单位。

我们为这个场景选择 DeepL，是因为将文件作为文件进行翻译正是它为之构建的工作——我们没有试图构建一个更好的引擎。反之则不然——DeepL 不运行我们为会议构建的那种实时语音流水线。不同的问题；不同的工具。“驱动 InterMIND 翻译的是什么”的诚实回答是“每条流水线使用合适的引擎”——而不是“到处都是我们的引擎”。

此流水线涵盖而语音未涵盖的语言

文档流水线支持 30 种语言，而语音支持 23 种。额外的语言包括：保加利亚语、希腊语、爱沙尼亚语、印尼语、立陶宛语、拉脱维亚语、斯洛伐克语、斯洛文尼亚语。（阿拉伯语也在此列表中，并且它是额外的语言之一：由于其语音质量未达到我们的标准，已从实时选择器中撤下，其每对语言的分数在 /benchmark 上保持公开——这个数字将决定它何时回归。不对称性在印地语上则相反——在语音上可用，但在文件上尚不可用。）

这种不对称性是真实存在的。这意味着会议中的法国参与者即使无法用爱沙尼亚语收听会议，也可以请求爱沙尼亚语的合同 PDF。我们在选择器中对其进行标记，而不是用一个单一的数字来掩盖它。原因详见语言数量文章。

流水线的交汇点

四条流水线并非孤立运行。会议室是它们相互接触的地方，而接缝处很重要：

• 带有文档附件的聊天消息会触发文本的聊天流水线和文件的文档流水线。使用另一种语言的参与者会看到消息立即被翻译，而附件翻译则以可下载的形式异步到达。
• 引用转录行的共享笔记横跨笔记 ↔ 语音。转录本是语音流水线为发送者语言生成的内容；笔记翻译为其他所有人的语言生成该引用的按观看者副本，并保留其来源归属。
• 会议后导出的转录本对完整对话运行聊天风格的文本流水线，生成参与者可以下载的按语言划分的文件。这与聊天翻译的代码路径相同，只是采用了批处理。

语言选择器只是一块 UI。其底层基础设施是四条相互通信的流水线。

我们刻意不做的事情

• 不使用“统一翻译模型”。 我们没有构建一个模型来同时处理语音、聊天、笔记和文档。延迟与保真度的权衡没有赢家。我们针对每个场景使用合适的引擎。
• 不进行静默重路由。 如果文件流水线今天无法翻译成印地语，我们不会悄悄退回语音引擎并假装它成功了——文件选择器会标出这个缺口，而不是隐瞒它。
• 不宣称“我们翻译成 200 种语言”。 我们的引擎输出 24 种。实时场景交付 23 种，文档交付 30 种——我们没有使用一个有利于营销的数字，而是将必须经得起审计人员审查的每对语言的质量发布在 /benchmark 上，包括较弱的语对。

亲自尝试

• 尝试实时演示 —— 针对您的音频运行实时语音流水线，支持 23 种产品语言中的任意一种。这也是在 /benchmark 上评分的同一条流水线。
• 查看基准测试 —— 真实流量下每对语言、每月的质量。选择器中的每一对语言，无论强弱，均可深度链接。
• 阅读方法论 —— 了解这些数字代表什么、不代表什么，以及评判者是谁。

四条流水线，四个引擎，一个会议室。这是对旧的 how-it-works 页面的诚实替代方案。

— Mind.com 团队

来源：DeepL — 支持的语言，DeepL — 使用计数和计费（每个文件 50,000 字符的最低限制），FLORES-200；内部流水线事实已根据发布的代码进行验证，于 2026 年 8 月核对。