深入解析驱动 InterMIND 的四条翻译管线

mind.com 上旧版的 /product/overview/how-it-works 页面已经落后好几个大版本了。它像大多数厂商页面那样,描述了一个单一的"翻译引擎"——从"您说话"到"对方听到"的一支大箭头。两年前那张图就已经是简化版了,如今它已是错的。

事实是,InterMIND 运行着四条独立的翻译管线,每一条用不同的引擎解决不同的问题,各有不同的延迟预算和质量边界。它们共用一个语言选择器,但不共用引擎。

这就是对"它是如何工作的"这一问题的更新版回答。

配套阅读:《你们支持多少种语言?》 介绍了每条管线覆盖哪些语言(24 / 22 / 30 / 12)。本文则讲每条管线在做什么——以及它为什么必须自成一体。

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

一个实时会议平台至少要同时完成四项工作,而它们的方向彼此冲突:

1. 实时语音——音频输入,翻译音频输出,延迟一秒以内,每位听众听到自己语言的版本。硬约束是延迟。
2. 实时聊天文本——短消息,要快,要保留编辑、引用和 HTML 结构。
3. 实时共享笔记——逐字符的协同输入,且结构层级(列表、标题、复选框)必须在翻译后保留下来。
4. 异步文档文件——一份 40 页的 PDF 被丢到聊天中。没有延迟预算。硬约束是保真度——格式、表格、页码、字体。

您可以构建一个庞大的 LLM 调用,试图同时完成这四件事。我们试过,四件事它都做得不好。语音的延迟预算让模型来不及思考;文档的保真度预算又要求模型必须思考。一次聊天编辑需要在观看者语言里呈现 diff;一份 40 页的 PDF 则需要任何流式 token 模型都给不了的格式保留。

所以我们运行四条管线。下面逐一介绍。

管线一:实时语音翻译

**问题:**一位参会者说法语。另一位以德语加入,第三位用巴西葡萄牙语,第四位用日语。每个人都需要用自己的语言、在自己的耳朵里听到说话者的内容,延迟要短到不影响眼神交流。

**预算:**端到端低于一秒。一旦超过约 1.2 秒,对话就会断裂——人们会开始压过翻译说话,会议就会滑向"我们干脆全说英语吧"。

音频实际是如何流动的

有几点值得明确指出:

• ASR 运行在说话者的浏览器内,而不是在中央服务器上。我们在本地使用 Mind SDK;这省掉了一次往返,并以尽可能小的延迟拿到源语言转录文本,以便翻译可以尽早启动。
• **翻译并不是单次扇出。**我们维护一组到自有翻译引擎的 WebSocket 连接,会议室中每种目标语言一条。如果三位参会者选了德语,他们共用一条德语连接。如果没人选阿拉伯语,就不会打开阿拉伯语连接。空闲连接在五分钟后会被释放。这就是为什么一个四语言会议和一个四十语言会议在成本上是一样的——只要实际到场的人没有变化——我们绝不会翻译到没有任何参会者收听的语言。
• **合成语音是每位观看者独立的。**每位参会者接收自己的翻译音轨,与原始说话者视频混合。他们看的不是一个统一的"翻译会议"——他们看的是同一场会议,只是个人音频通道被翻译成他们所选的语言。这就是为什么同一个物理房间里的两个人可以各自插上耳机,听到不同的语言。

当一场会议出问题时,这一架构为什么重要

在一通 60 分钟、八种语言的通话里,各种意想不到的故障都会出现:WebSocket 断开、ASR 临时把某个专有名词转录错了、某位参会者的网络出现抖动。上述架构正是让我们能够隔离故障的关键:一位观看者的音频卡顿不会影响其他七位,因为翻译引擎压根就没生成过"一个翻译"——它并行生成了八个,只有受影响的那一个需要恢复。

引擎本身是我们自研的,部署在我们自己的基础设施上。我们不会把实时语音通过第三方通用 LLM 路由。延迟预算把它们排除在外;对真正在意的受监管客户来说,数据驻留这一点也把它们排除在外。

我们就语音质量公开了哪些数据:/benchmark 每月针对每一对已发布的语言,对生产环境的语音管线运行 FLORES-200 句子。评测模型是公开的(Gemini 2.5 Flash 为主、Claude Sonnet 4 为备)。完整分布——中位数、p10、p90、最小值、最大值、样本量——都在页面上。这些数字测量了什么、未测量什么,请参见方法论说明。

管线二:实时聊天翻译

**问题:**会议中的每条聊天消息,都要在发送时,被翻译为每位参会者各自的语言。还有编辑——而且编辑要看起来像编辑,而不是像重新翻译。

**预算:**要快,但不必到亚秒级。一条聊天消息在另一种语言里花半秒钟出现,没人会在意。人们在意的是翻译准不准,以及编辑是否合乎逻辑。

聊天管线实际在做什么

每条消息走的是与语音管线相同的翻译引擎——但前后处理不同:

• **保留 HTML 结构。**聊天支持富文本(段落、列表、引用、粗体、斜体)。我们将其转为纯文本送给模型,翻译完后再用原有标签包回去。模型从未看到 HTML——它看到的是干净的散文。
• **引用独立翻译。**如果您回复一条消息并引用它,[QUOTE]…[/QUOTE] 区块与新输入的内容会作为两个独立单元分别翻译,这样模型就不会把两者混淆。
• **长消息分块。**我们在段落边界切分,每块最多 1,000 字符。每块单独发起一次翻译调用。我们不会把一篇 4,000 字符的长文一次性喂给模型——它的失败模式(截断、丢段落、句子中间断开)都太难看。
• **翻译是惰性的。**我们用 IntersectionObserver:消息只有在滚动进入观看者视口时才会被翻译。以前在长会话里切换语言会把历史里每一次翻译 API 调用重放一遍。现在不会了。

有意思的部分:把编辑表达为 diff

在 v1.2 中,我们改变了另一种语言下观看者看到聊天编辑的方式。旧行为是:有人编辑一条消息,我们重新翻译整条,您看到的是一段全新的文字,得自己去找哪里变了。

新行为是:

1. 原消息此前已被翻译成您的语言。
2. 当发送方编辑时,我们重新翻译新版本。
3. 我们用您的语言,计算您之前那版译文与您新的译文之间的 diff。
4. 我们将这一 diff 内联展示——与 Git 显示变更的方式相同。

于是当英文里"review by Tuesday"变成"review by Thursday"时,读西班牙语的同事看到的是高亮的 martes → jueves,而不是一段需要重新读一遍的新译文。

为此我们必须把聊天管线视为一个有状态、按观看者维护的缓存,而不是无状态的"按需翻译"端点。文档和语音都不需要这一点,聊天需要。

管线三:实时共享笔记翻译

**问题:**主持人打开共享笔记面板开始输入。每位参会者都在自己的语言里看到逐字符出现的笔记,且文档结构——标题、嵌套列表、清单、代码块——保持完好。

**预算:**与聊天相同(约半秒),但多了两个约束:

• **被翻译的内容在翻译过程中还在变。**主持人仍在打字。如果每次按键都"翻译整个文档",会产生闪烁,并烧掉 API 预算。我们以发生变化的单元为粒度翻译,而不是整篇文档。
• **结构必须保留。**如果让翻译模型翻译一段带三层嵌套列表的 markdown 块,您拿回来的东西看起来像原文,但层级被微妙地拍平了,序号被重排了,缩进被移位了。我们不会让模型看到整个文档块。

笔记管线与聊天管线的差异

结构保留是关键。我们逐项翻译每个列表条目,而不是把整篇文档作为一体送进去。模型看到的是:

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

——而不是:

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

外层文档——<ul>、标题、缩进——由客户端按原文档的结构重建,每个叶子节点替换为其译文。模型没有机会"改善"层级结构。

笔记也使用与聊天编辑相同的"按观看者维护 diff"模型:如果主持人改动了一行,其他语言的观看者看到的是被高亮的变更词,而不是一整段新译文。

管线四:异步文档翻译

**问题:**有人把一份 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 种语言,而语音覆盖 22 种。多出的语言包括:保加利亚语、希腊语、爱沙尼亚语、印度尼西亚语、立陶宛语、拉脱维亚语、挪威博克马尔语、斯洛伐克语、斯洛文尼亚语——还有阿拉伯语,我们将其从实时选择器中隐藏,因为语音质量未达我们的标准,但 DeepL 处理阿拉伯语文档表现良好。

这种不对称是真实存在的。这意味着一位法语参会者可以在会议中索要爱沙尼亚语版的合同 PDF,即便他无法用爱沙尼亚语收听会议。我们会在选择器中明确标注,而不是用一个数字掩饰过去。理由详见语言数量那篇文章。

这些管线在哪里相遇

四条管线并非彼此孤立运行。会议室就是它们交汇的地方,接缝至关重要:

• 带附件的聊天消息会同时触发文本走聊天管线、文件走文档管线。使用另一种语言的参会者会立即看到翻译后的消息,而附件的译本则以可下载形式异步到达。
• 引用了转录文本的共享笔记横跨了笔记 ↔ 语音两条管线。被引用的转录是语音管线为发送者所用语言生成的;笔记翻译则为其他人各自的语言生成该引用的副本,并保留其来源标注。
• 会议结束后导出的转录会让整段对话走聊天风格的文本管线,生成每种语言一份的文件,供参会者下载。这与聊天翻译走的是同一份代码路径,只是批量化处理。

语言选择器只是一处 UI。其下的基础设施是四条相互通话的管线。

我们刻意不去尝试的事

• **不做"统一翻译模型"。**我们不会去打造一个同时做语音、聊天、笔记和文档的模型。延迟与保真度之间没有赢家。我们在每个使用面上用最合适的引擎。
• **不做静默回退。**如果今天语音无法翻译到印地语,我们不会悄悄回退到文档引擎然后假装一切正常。印地语在两个使用面的选择器中都被隐藏,因为今天的结果在两个面上都达不到可发布的标准。
• **不说"我们翻译 200 种语言"。**我们的引擎输出 24 种。我们的产品在实时使用面上发布 22 种,在文档使用面上发布 30 种。营销友好的更大数字只是引擎天花板。产品数字才是真正能在审计员面前过关的数字。

您可以亲自试试

• /demo ——让实时语音管线处理您的音频,支持 22 种产品语言中的任意一种。这正是 /benchmark 评测的同一条管线。
• /benchmark ——基于真实流量,按语言对、按月给出质量数据。包括我们刻意从选择器中隐藏的语言对,可深链接。
• /benchmark/methodology ——这些数字是什么、不是什么、评测者是谁。

四条管线,四个引擎,一个会议室。这就是旧版 how-it-works 页面诚实的替代品。

—— The Mind.com Team