直播实时翻译约 4 分钟读完
VAD（语音活动检测）的静音时长回答一个问题：主播停多久，系统才把当前语音当成一句结束并交给翻译。
调低能更快出结果，也更容易把一句切碎；调高能保留句内停顿，也会让字幕和译音等得更久。正确值不是网上抄来的毫秒数，而是你的主播节奏与商品话术之间的折中。
先区分三种现象
句中被切开。 “今天这款是 A / 17 Pro”被拆成两条，后半句失去商品上下文。调整方向是增加静音时长，或者先改主播的停顿位置。
两句粘在一起。 商品介绍和下一个优惠合成一大段，字幕很长，TTS 开始得晚。调整方向是缩短静音时长，或让主播在句末做清楚停顿。
最终结果太晚。 主播已经停口，partial 仍挂着不收句。先确认是端点等待，不是网络、识别或翻译慢，再尝试调低。
这三类不要混为“延迟高”。延迟预算文章把断句、识别、翻译、合成和播放分开，先定位到断句层才有资格改 VAD。
官方文档给的是方向，不是你的答案
Azure Speech 的静音处理说明写得很明确：分段静音超时越高，结果通常越长、允许句内停顿更多，但返回更慢；越低，结果更短更频繁，也可能把单句拆开。文档给出的范围是 100–5000 ms，典型默认值为 500 ms，并建议只在确实存在静音处理问题时修改。
ObsTrans/言播客户端中的实际设置名是基础设置 → 实时同传断句间隔，范围 200–6000 ms、步长 100 ms、默认 500 ms，而且只对“高级在线识别”的实时同传线路生效。不要把 Azure 的 100–5000 ms 范围抄进 ObsTrans；两组数字来自不同产品，这里引用 Azure 只为核对端点权衡和调整方向。
用同一段录音做 A/B
选一段真实直播录音，必须包含：
- 一段连续讲解；
- 两个价格；
- 一个带字母和数字的型号；
- 主播自然思考停顿；
- 一次从商品介绍切到优惠。
先跑当前设置，标出句子边界和停口到 final 字幕的时间。然后小步改变一个档位，重跑同一段。记录：
| 观察项 | 通过标准 |
|---|---|
| 型号与价格 | 不被错误拆成独立片段 |
| 两个完整句 | 不粘成一条长字幕 |
| 等待时间 | 团队在真实节奏下能接受 |
| TTS | 不因碎片过多频繁打断 |
不要同时换麦克风、开降噪或改 TTS 语速。变量一起变，结果就不能归因。
先改说法还是先改参数
对于价格和序列号，先改说法通常更稳。微软文档专门举了“ABC-123-4567”分组朗读时停顿过长的例子，并建议尝试更高的 2000 ms。直播里也可以先把“型号是 A，17，Pro”改成“完整型号 A17 Pro”，减少中间停顿。
如果为了一个型号把全场超时拉高，所有普通句子都会更晚结束。高频话术应优先在脚本本地化层解决，参数负责兜住全局节奏。
ObsTrans 能做与不能做
ObsTrans 暴露“实时同传断句间隔”，让团队可以在不改代码的情况下调整实时线路断句；工作台的 partial 和 final 状态也能帮助判断是否仍在等收句。本地识别和普通在线识别不使用这个设置，不能拿它解释那两条线路的分段结果。
它不能从一次测试自动得出永久参数。换主播、换麦克风距离、改口播节奏后，都应重跑短测试。把最终选定值和测试录音一起留档，比只在群里发一个毫秒数有用得多。
操作步骤
- 1
录一段能复现问题的真实口播
包含连续讲解、价格、型号和自然停顿，不要临时读一段刻意放慢的测试稿。保留同一段录音用于每轮对照。
- 2
给现象分类
把问题标成“句中被切开”“两句粘在一起”或“最终结果太晚”。不同现象对应的调整方向不同。
- 3
一次只改变断句间隔
在 ObsTrans「基础设置 → 实时同传断句间隔」中按 100 ms 小步调整。被切碎时调高，粘句或等待太久时调低，不同时改语速、麦克风和引擎。
- 4
同时记录完整性和等待时间
对每个档位记录价格型号是否完整、句子是否粘连，以及从主播停口到最终字幕出现的时间。只看延迟会把参数推得过低。
- 5
用直播节奏复验
让主播按正式节奏讲一轮，并加入助播插话和背景音乐。实验录音通过不代表真实轮次不会触发错误端点。
常见问题
- 静音时长越短是不是延迟越低？
- 最终结果通常会更早触发，但过短会把一句拆成几段，翻译失去上下文，TTS 也可能频繁播短片。需要同时看完整性，而不是只追求最小值。
- 价格和型号总被拆开应该怎么调？
- 先让主播在数字组之间减少无意义停顿；仍被拆开时，再逐步提高静音时长。微软官方也用分组朗读序列号作为需要更长超时的例子。
- 为什么换主播后原来的参数失效？
- 端点检测直接受说话速度、句中停顿和接话方式影响。参数是对具体直播节奏的配置，不是某个语言对的永久常数。
关键词VAD 静音时长直播翻译断句语音端点检测实时翻译延迟ObsTrans 设置
