批处理、流式与后处理

本节目标

比较离线批处理和实时流式识别，设计 partial/final 状态、文本规范化和可靠失败处理。

批处理与流式

批处理（batch） 在音频完整可用后识别，便于全局上下文、重试和高吞吐调度，适合会议归档。流式（streaming） 边接收边输出，强调首字延迟和持续更新，适合实时字幕或语音助手。

流式结果不能只靠一个含义模糊的 final。合同至少要区分：

• partial：临时假设，可被后续音频改写；只适合 UI 预览或明确低风险的预测。
• provisional_final：当前段已封口，但提供方仍可能因全局重评分、跨段合并或人工校正发出修订。
• committed：本系统确认可作为持久记录的版本；下游检索、总结、工具和审计只能消费它，后续纠正须以带来源的新修订事件表达，不能静默覆盖。

若目标接口只有 final，适配层必须在接入时写清它对应哪一种语义；不要把“本轮不再出 partial”推断成“永远不可修订”。客户端应按 segment_id + revision 幂等更新，不能每次追加 partial，否则会重复文字；每次 revision 还应关联产生它的模型/规则版本与上游音频时间范围。

当 ASR 驱动实时 Agent 时，partial 不能直接触发写工具；应由独立的 turn.commit 或用户确认把可修订观察提升为可行动输入。完整事件边界见 VAD、轮次与用户打断 与 工具调用与对话状态。

延迟分解

用户感知延迟包括采集缓冲、VAD 等待、传输、排队、推理、后处理和渲染。只报告“模型实时率”不足以解释端到端体验。流式还要设置背压：消费速度低于音频到达速度时，是降级、丢弃、扩容还是断开？策略必须明确。

文本后处理

保留 raw_text，再生成带版本的：

• 大小写与标点恢复；
• 数字、日期、单位规范化；
• 专有名词候选；
• 敏感信息遮蔽副本。

规则不得无证据补写内容。流式中标点可能依赖后文，应与 final 状态一起更新。

重试与幂等

网络失败只对可安全重试的操作使用有界重试和退避。上传整段音频应有请求 ID、片段序号和校验摘要，防止重试产生重复转录。超时后状态为未知时先查询，不盲目再次创建任务。

练习与自测

• 设计 partial -> partial revision -> final 的 JSON 事件序列。
• 给 30 分钟会议画出批处理队列及失败恢复点。
• 为什么“模型推理 200 ms”不能证明端到端延迟 200 ms？还有多段缓冲和系统开销。

下一步与参考

下一步学习 WER、CER 与切片评测。具体产品是否支持真流式、词级时间戳或上下文提示，必须以目标 SDK 的当前官方文档为准；Whisper 官方仓库（获取日期：2026-07-14）示例的是具体实现，不能泛化成所有 ASR 接口。