深入了解驱动 InterMIND 的四大翻译管道

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

真实情况是，InterMIND 运行着 四个独立的翻译管道，每个管道使用不同的引擎、不同的延迟预算和不同的质量范围来解决不同的问题。它们共享一个语言选择器，但不共享引擎。

这是关于“它是如何工作的”的最新解答。

相关阅读： “你们支持多少种语言？” 介绍了每个管道 覆盖 的范围（24 / 24 / 30 / 17）。本文则介绍每个管道 做什么 —— 以及为什么它们各自独立。

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

一个实时会议平台至少要同时完成四项工作，而且它们在互相矛盾的方向上拉扯：

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

您可以构建一个巨大的 LLM 调用来尝试完成这四项工作。我们试过了。它在四个方面都做不好。语音的延迟预算意味着模型没有时间思考；而文档的保真度预算意味着模型必须思考。聊天编辑需要在听众语言中显示差异；而 40 页的 PDF 需要保留格式，这是任何 token 流式模型都无法提供的。

因此我们运行了四个管道。以下是每一个的介绍。

管道 1：实时语音翻译

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

预算： 端到端低于一秒。任何超过 ~1.2 秒的延迟都会破坏对话——人们开始在翻译之上说话，会议会偏向“我们还是直接切英语吧”。

音频的实际传输方式

有几件事值得明确指出：

• ASR 在发言人的浏览器中运行，而不是在中央服务器上。我们在本地使用 Mind SDK；这节省了一次往返过程，并在翻译开始之前以尽可能低的延迟为我们提供源语言转录文本。
• 翻译不是一次扇出。 我们维护着一组与翻译引擎的 WebSocket 连接池，会议室内存在的每种目标语言各一个连接。如果三位参与者选择了德语，德语共享一个连接。如果没有人选择阿拉伯语，就不会打开阿拉伯语连接。连接池会在五分钟后丢弃空闲连接。这就是为什么在参与者实际到达的范围内，一场四种语言的会议与一场四十种语言的会议成本相同——我们绝不会翻译成没有参与者收听的语言。
• 合成语音是按听众划分的。 每个参与者都会收到自己翻译后的音轨，与原始发言人的视频混合。他们观看的不是主“翻译会议”——他们观看的是 同一场会议，只是个人音频频道被翻译成了他们选择的语言。这就是为什么在同一物理房间里的两个人可以各自插上耳机听到不同的语言。

当会议出现意外时，这为何很重要

在一场 60 分钟、使用八种语言的通话中，情况会以各种有趣的方式出错：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 数据块，您会得到看起来像原始内容的东西，但其层次结构被巧妙地扁平化、项目被重新编号或缩进被移动。我们不让模型看到整个数据块。

笔记管道与聊天的区别

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

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

—— 而不是：

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

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

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

管道 4：异步文档翻译

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

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

为什么此管道不与语音共享引擎

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

对于这一层面，我们直接使用 DeepL Document API。它是专门为 将文件作为文件 翻译而构建的，而不是翻译 从文件中提取的散文。DeepL 处理：

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

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

这需要多少成本以及我们为什么不隐藏它

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

我们在此层面选择 DeepL 是因为 将文件作为文件 翻译正是它为之构建的工作——我们没有试图构建一个更好的引擎。但反过来则不然——DeepL 不运行我们为会议构建的那种实时语音管道。不同的问题；不同的工具。对于“什么支持 InterMIND 翻译”的诚实回答是“每个管道使用合适的引擎”——而不是“到处都是我们的引擎”。

此管道覆盖而语音未覆盖的语言

文档管道覆盖 30 种语言，而语音为 24 种。额外的语言包括：保加利亚语、希腊语、爱沙尼亚语、印尼语、立陶宛语、拉脱维亚语、斯洛伐克语、斯洛文尼亚语。（阿拉伯语曾在此列表中，因为其语音质量低于我们的标准；它现在已在实时选择器中，并且其每对语言的质量得分像其他所有语言一样公开在 /benchmark 上。现在这种不对称性反过来了——印地语在语音上可用，但在文件上尚不可用。）

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

管道交汇之处

四个管道不是孤立运行的。会议室是它们相互接触的地方，这些衔接点很重要：

• 带有文档附件的聊天消息 触发文本的聊天管道和文件的文档管道。使用其他语言的参与者会看到消息立即被翻译，而附件翻译则以异步方式作为可下载项到达。
• 引用转录行的共享笔记 跨越了笔记 ↔ 语音。转录内容是语音管道为发送者语言生成的内容；笔记翻译为其他每种语言的听众生成了该引用的按听众副本，并保留了其来源归属。
• 会后导出的转录内容 对完整对话运行聊天样式的文本管道，生成参与者可以下载的按语言划分的文件。这与聊天翻译的代码路径相同，只是进行了批处理。

语言选择器只是一个 UI 组件。其底层基础设施是四个相互通信的管道。

我们刻意不做的事情

• 没有“统一翻译模型”。 我们没有构建一个同时处理语音、聊天、笔记和文档的模型。延迟与保真度的权衡没有赢家。我们在每个层面使用合适的引擎。
• 没有静默重路由。 如果文件管道今天无法翻译成印地语，我们不会悄悄回退到语音引擎并假装它有效——文件选择器会标记这一空缺，而不是隐藏它。
• 没有“我们翻译成 200 种语言”。 我们的引擎输出 24 种。实时界面交付全部 24 种，文档交付 30 种——并且不是给出一个对营销友好的数字，那些必须经受审计的每对语言质量都被公开在 /benchmark 上，包括较弱的组合。

亲自体验

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

四个管道，四个引擎，一个会议室。这是对旧版 how-it-works 页面的诚实替代。

— Mind.com 团队

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