人工同传的行业惯例是"落后发言者 3–4 秒"，AI 同传如果想进会议现场，延迟必须压到这个量级才有意义。差 1 秒，听众就会在发言者停顿后还在接收上一句，节奏全乱。
这篇拆一下 AI 同声传译的链路和延迟预算是怎么分配的。
一、链路拆解
一句话从发言者嘴里出来，到听众听到译文，要经过五段：
VAD 断句 → 流式 ASR → 增量机器翻译 → 流式 TTS → 分发到终端
每一段都有自己的延迟成本，也都有自己的优化手段。
| 环节 | 职责 | 延迟特征 |
|---|---|---|
| VAD 断句 | 判断"这句说完了没有" | 可等可不等，策略性强 |
| 流式 ASR | 语音转文字 | 边说边出部分结果 |
| 增量翻译 | 文本转译文 | 可对不完整句子翻译 |
| 流式 TTS | 译文转语音 | 边生成边播 |
| 分发 | 推到字幕页/音响 | 网络 + 缓冲 |
二、延迟预算为什么能压到 2–3 秒字幕
关键在于不整句处理。
传统做法是"等一句说完 → 识别整句 → 翻译整句 → 输出"，这个流程在中文里平均要等 5–8 秒（一句中文说完通常就是这个时长）。所以串行整句方案天然做不到 2 秒。
流式方案的做法是分段推进：
1. 用稳定的部分识别结果先译。 ASR 流式输出时会有一个"稳定前缀"——已经不太可能被后续语音改写的部分。只对这部分的文本发起翻译，后面的等稳定了再说。
2. 译文按增量修正。 后续识别结果可能推翻前面的判断（比如"我们要"后面接的是"注意"还是"支持"），所以译文要支持增量更新，前端展示也要能平滑替换而不是整屏刷。
3. 字幕不等 TTS。 字幕链路和语音链路是分开的——字幕走文本直接渲染，语音还要多一步合成。这也解释了为什么语音延迟比字幕高 1–2 秒。
三、断句策略的技术权衡
VAD（语音活动检测）判"说完没有"，这里有个矛盾：
- 判得早：延迟低，但可能把一句话切成两半，翻译质量下降
- 判得晚：翻译质量好，但听众等得久
工程上的常见做法是双阈值 + 语义辅助：
- 静音时长超过阈值（比如 300ms）视为句末
- 但如果在语义上明显未完（以"因为""如果""虽然"结尾），可以再等一小段
- 对长句设最大时长上限，超时强制切分，避免无限等待
另一种做法是不严格断句：维护一个滑动窗口，持续翻译窗口内的内容，靠上下文重叠保证连贯。代价是重复翻译算力。
四、术语准确性的两条通道
专业术语是同传最容易翻车的地方——人名、产品名、缩写，通用模型经常听错或译错。技术上有两条独立通道：
通道1：ASR 术语纠错。 给识别引擎一个术语表，让它在解码时优先倾向这些词。比如"吴沐铨"这种名字，不加约束几乎必然识别成同音常用字组合。这一步解决的是"听对"。
通道2：翻译术语锁定。 给翻译引擎一个"原文→译文"的强制映射，保证同一个术语在整场会议里译文一致。这一步解决的是"译准"。
两条通道要分开配置的原因很实在：有些词识别没问题但译法有争议（比如产品功能名），有些词识别就错（比如人名、缩写）。合成一张表反而不好管。
术语规模的经验值。 页面上提到建议术语总数不超过 500 条。这个限制有技术原因：术语约束会显著增加解码搜索空间，表太大反而降低整体识别流畅度，甚至引入误触发（把普通词强行纠成术语）。500 条是个务实的平衡点。
五、多语向并行：9 个语向怎么调度
同传模式支持源语言和目标语言各最多 3 种，组合起来最多 9 个语向。这在工程上有几个问题：
翻译任务数 = 源数 × 目标数。 9 个语向就是 9 条翻译链路，每条都要独立维护上下文和术语表。这跟"一个语向翻 9 次"在架构上完全不同——前者是并行的多个翻译会话。
延迟是并行的，不是累加的。 如果架构设计成串行（先中→英，再英→日），延迟会叠加，9 个语向就没法用了。所以必须是源语言直接译到各目标语言，各链路并行。
这会带来一个功能取舍。 页面上明确写了"多语向同传项目暂不支持会前学习，可手动添加术语"。原因就是会前学习产出的术语要按语向分发映射，9 个语向的术语矩阵管理复杂度高，先用手动配置把可控性留给用户。
六、音色与语速：为什么按语言独立设置
页面上提到每种目标语言可独立设置音色和 0.75–1.5 倍语速。这不是"多给几个选项"，而是必要的技术设计：
语速和信息密度强相关。 同样一段内容，中文和英文的音节数差异很大。固定语速会导致某些语言"来不及说完"（译文被截断或拖长）。按语言独立调节，是为了让译文能在原句的时间窗内说完。
音色与语言绑定有语言学依据。 不同语言的音素分布不同，同一音色模型在不同语言上的自然度差别明显。独立配置让每种语言都能选它表现最好的音色。
0.75–1.5 倍这个区间是有讲究的。 低于 0.75 倍听众会觉得"机器卡顿"，高于 1.5 倍清晰度骤降。区间外不是不能合成，是听感不可用。
七、这套链路的能力边界
诚实地说，AI 同传目前有几个明确的限制：
依赖发言清晰度。 多人抢话、远场拾音、强口音场景，ASR 准确率会明显下降，延迟也会因为反复修正而增大。
长句和复杂逻辑仍是弱项。 中英文语序差异大，长定语从句的处理容易出错，尤其是需要等句末才能确定的结构。
术语覆盖有上限。 500 条之外的新词只能靠模型泛化。
不适合高度机密的场合。 涉及敏感内容时，机器翻译的不可控性（可能误译、可能加入训练分布里的先验）是风险。
八、写在最后
AI 同传的技术核心是"延迟预算的分配"——把整句处理拆成流式增量，把识别和翻译解耦，把术语约束分成两条独立通道。理解了这套结构，就能判断一个方案在什么场景能用、什么场景会掉链子。
睿译宝同声传译方案的完整能力可以看官方页面——查看睿译宝 AI 同声传译的技术方案。具体功能与版本以页面实际展示为准。
你参加过带 AI 同传的会议吗？延迟能接受吗？评论区聊聊。
