InterMIND 四大翻译流水线揭秘

Mind.com 上过时的 /product/overview/how-it-works 页面已经落后于几个主要版本了。它像大多数厂商页面一样，描述了一个单一的“翻译引擎”——一个从“你说话”到“他们听到”的大箭头。这种描述在两年前就已经是一种简化，今天则完全是错误的。

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

这就是“它是如何工作的”的最新答案。

相关文章：《我们支持多少种语言？》介绍了每条流水线覆盖的语言数量（24 / 21 / 30 / 6）。本文则阐述了每条流水线做了什么——以及为什么它们是独立运作的。

为什么“一个引擎搞定一切”是个谎言

一个实时会议平台至少需要同时完成四项任务，而这些任务的方向是相互冲突的：

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

你可以构建一个庞大的 LLM 调用来尝试处理所有这四项任务。我们尝试过。它在所有四项任务上表现都很糟糕。语音的延迟预算意味着模型无法思考；文档的保真度预算意味着模型必须思考。聊天编辑需要以观看者语言显示差异；40 页的 PDF 需要保留格式，而这是任何 token 流式模型都无法提供的。

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

流水线 1：实时语音翻译

**问题：**一位参与者说法语。另一位参与者使用德语，第三位使用巴西葡萄牙语，第四位使用日语。每个人都需要在自己的耳机中听到发言者的母语翻译，并且延迟足够短，以便保持眼神交流。

**预算：**端到端亚秒级。任何超过约 1.2 秒的延迟都会导致对话中断——人们开始在翻译之上讲话，会议就会倾向于“我们还是切换到英语吧”。

音频的实际传输方式

有几点值得明确指出：

• ASR 在发言者的浏览器中运行，而非中央服务器。我们本地使用 Mind SDK；这节省了一次往返，并在翻译开始前以尽可能低的延迟提供源语言的转录文本。
• **翻译并非单一扇出。**我们维护着一个与翻译引擎的 WebSocket 连接池，每个房间中存在的目标语言对应一个连接。如果三位参与者选择了德语，德语将共享一个连接。如果没有人选择阿拉伯语，则不会打开阿拉伯语连接。连接池会在五分钟不活动后断开空闲连接。这就是为什么一个四种语言的会议与一个四十种语言的会议，在实际出席人数这一点上成本相同的原因——我们从不翻译到没有参与者正在听的语言。
• **合成语音是按观看者区分的。**每位参与者都会收到自己独立的翻译音频轨道，并与原始发言者的视频混合。他们观看的不是一个主“翻译会议”——他们观看的是同一个会议，但他们的个人音频通道被翻译成了他们选择的语言。这就是为什么在同一个物理房间里的两个人可以各自插入耳机，听到不同语言的原因。

会议出错时为何这很重要

在一个 40 分钟的八种语言通话中，事情会以有趣的方式出错：WebSocket 断开，ASR 暂时错误转录了专有名词，一位参与者的网络变得不稳定。上述架构使我们能够隔离故障：一位观看者的音频故障不会影响其他七位，因为翻译引擎从未首先生成“整体翻译”——它并行生成了八个翻译，只有受影响的那一个需要恢复。

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

我们发布的语音质量信息：/benchmark 每月针对每个已发布的语言对，使用 FLORES-200 句子运行生产语音流水线。评审者已具名（Gemini 2.5 Flash 为主要评审者，Claude Sonnet 4 为备用评审者）。完整的分布数据——中位数、p10、p90、最小值、最大值、样本大小——都显示在该页面上。请参阅方法论以了解这些数字测量了什么以及没有测量什么。

流水线 2：实时聊天翻译

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

**预算：**快速，但不必是亚秒级。聊天消息在另一种语言中显示可能需要半秒，而没有人会介意。人们关心的是翻译是否正确以及编辑是否有意义。

聊天流水线实际做了什么

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

• **HTML 结构得到保留。**聊天支持富文本（段落、列表、引用、粗体、斜体）。我们将其转换为纯文本供模型处理，翻译，然后将结果重新包裹在原始标签中。模型从未看到 HTML——它看到的是干净的散文。
• **引用独立翻译。**如果您回复消息并引用它，[QUOTE]…[/QUOTE] 块和新内容将作为单独的单元进行翻译，因此模型不会混淆两者。
• **长消息会被分块。**我们以段落边界为准，每块 1,000 个字符进行分割。每个块都是独立的翻译调用。我们不会一次性将 4,000 字符的小说喂给模型——因为故障模式（截断、段落丢失、句子中途切断）过于糟糕。
• **翻译是惰性的。**我们使用 IntersectionObserver：消息仅在滚动进入观看者视口时才被翻译。在长时间运行的频道中切换语言过去会重播历史中的每个翻译 API 调用。现在不会了。

有趣的部分：编辑以差异形式显示

在 v1.2 版本中，我们改变了聊天编辑对其他语言观看者的行为方式。旧行为是：有人编辑消息，我们重新翻译整个内容，您会看到一个全新的段落，不得不自行找出哪些内容发生了变化。

新行为是：

1. 原始消息已翻译成您的语言。
2. 当发送者编辑时，我们重新翻译新版本。
3. 我们以您的语言计算您之前的翻译与您的新翻译之间的差异。
4. 我们以内联方式显示该差异——与 Git 显示变更的方式相同。

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

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

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

**问题：**主持人打开共享笔记面板并开始输入。每个参与者都能看到他们语言的笔记，逐字符显示，并且文档的结构——标题、嵌套列表、复选框、代码块——保持完整。

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

• **翻译中的内容会在翻译过程中发生变化。**主持人仍在输入。一个每次按键都翻译“整个文档”的简单系统会导致闪烁并消耗大量 API 预算。我们以变更单元的粒度进行翻译，而不是整个文档。
• **结构必须保留。**如果您要求翻译模型翻译一个包含三层嵌套列表的 markdown 块，您会得到一个看起来像原始内容但层级微妙地扁平化、项目重新编号或缩进移动的结果。我们不允许模型看到整个块。

笔记流水线与聊天的区别

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

“合规性审查 — 第二季度交付物”

— 而不是：

“# 项目计划

季度

• 合规性审查 — 第二季度交付物
• 供应商评分
  • 一级供应商...”

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

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

流水线 4：异步文档翻译

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

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

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

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

对于这个功能，我们直接使用 DeepL 文档 API。它专为翻译文件本身而设计，而不是从文件中提取的散文。DeepL 支持：

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

文档被上传到 DeepL 的流水线，在服务器端进行翻译，保留格式，并以相同的格式返回。然后我们将结果上传到我们的对象存储，并在聊天中以可下载附件的形式呈现。

这会产生什么成本以及我们为何不隐藏它

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

我们选择 DeepL 用于此功能，因为它专门用于文档翻译是同类最佳引擎。我们不假装已经构建了一个更好的引擎。反之则不然——DeepL 不运行我们为会议构建的那种实时语音流水线。不同的问题需要不同的工具。“InterMIND 翻译由什么驱动”的真实版本是“每条流水线使用正确的引擎”——而不是“我们的引擎，无处不在”。

这条流水线涵盖但语音不支持的语言

文档流水线支持 30 种语言，而语音支持 21 种。额外的九种语言包括：保加利亚语、希腊语、爱沙尼亚语、印度尼西亚语、立陶宛语、拉脱维亚语、挪威语（博克马尔）、斯洛伐克语、斯洛文尼亚语——以及阿拉伯语和土耳其语，我们将其从实时选择器中隐藏，因为语音质量未能达到我们的标准，但 DeepL 作为文档处理得很好。

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

流水线的交汇点

这四条流水线并非独立运行。会议室是它们相互接触的地方，而这些连接点很重要：

• 带有文档附件的聊天消息会触发文本的聊天流水线和文件的文档流水线。使用其他语言的参与者会立即看到消息的翻译，并异步接收作为可下载文件的附件翻译。
• 引用转录行内容的共享笔记连接了笔记 ↔ 语音。转录内容是语音流水线为发送者语言生成的结果；笔记翻译会为其他所有语言的观看者生成该引用的副本，并保留其来源归属。
• 会议结束后导出的转录文本会对整个对话运行聊天式文本流水线，生成一份参与者可以下载的每种语言的文件。这与聊天翻译的代码路径相同，只是批量处理。

语言选择器是一个 UI 组件。底层基础设施是四条相互协作的流水线。

我们刻意不尝试做的事情

• **没有“统一翻译模型”。**我们不构建一个可以处理语音、聊天、笔记和文档的模型。延迟与保真度的权衡没有赢家。我们为每个功能表面使用正确的引擎。
• **没有静默重路由。**如果语音今天无法翻译成印地语，我们不会悄悄地回退到文档引擎并假装它有效。印地语在这两个功能表面上都从选择器中隐藏，因为目前在这两个表面上的结果都无法交付。
• **没有“我们翻译 200 种语言”。**我们的引擎输出 24 种。我们的产品在实时功能上支持 21 种，在文档上支持 30 种。营销友好的更大数字只是引擎的上限。产品数字才是真正能通过审计的标准。

亲自尝试

• /demo — 使用您提供的音频，以 21 种产品语言中的任意一种运行实时语音流水线。这与/benchmark 中进行评分的流水线相同。
• /benchmark — 每月每对语言在实际流量上的质量。包含我们刻意从选择器中隐藏的语言对，可深度链接。
• /benchmark/methodology — 这些数字是什么，它们不是什么，以及评审者是谁。

四条流水线，四个引擎，一个会议室。这就是旧版 how-it-works 页面的真实替代。

— Mind.com 团队