工程版本日志 · 2026.08
在当前样本中，长录音为何没有让停止后 ASR 线性变慢
最近一组真实记录里，17.6 到 67.8 秒的录音在停止后的 final ASR 约为 0.42–0.47 秒。原因不是模型瞬间读完了整段，而是稳定语音已经在录音过程中完成识别；用户第二次按下 Option 停止时，只剩最后一个未稳定尾段需要收口。
01 · THE CHANGE
停止不再意味着“现在才开始识别”
在 Toggle 模式下，第一次按 Option 开始录音，第二次按 Option 停止。过去，停止之后才上传完整音频并依次等待 ASR、AI 和粘贴；现在音频在录音过程中持续进入会话，停顿感知的 SenseVoice 分段不断生成候选结果，稳定前缀被合并并预存。
录音与上传→分段 SenseVoice→稳定前缀→停止时只收口尾段02 · BOUNDED TAIL
最终 ASR 的工作量由尾段决定，而不是由整段录音决定
如果前面的分段已经完成识别，停止后不需要重新跑完整的 1 分钟、3 分钟或更长音频。final ASR 主要处理最后一个仍可能变化的语音片段，再与已经冻结的稳定前缀合并。
这使停止后的 ASR 时间在正常会话中趋向一个有界尾延迟，而不是随着总录音时长线性增长。
03 · REAL RECORDS
近期真实记录显示 ASR 已经不再是主要等待
- 17.6 秒录音：final ASR 约 416ms，AI 约 2.26s。
- 22.8 秒录音：final ASR 约 424ms，AI 约 2.42s。
- 29.2 秒录音：final ASR 约 436ms，AI 约 1.99s。
- 58.6 秒录音：final ASR 约 444ms，AI 约 3.22s。
- 67.8 秒录音：final ASR 约 467ms，AI 约 2.19s。
04 · THE NEW BOTTLENECK
瓶颈已经从 ASR 转移到最终 AI 整理
这组样本中，停止后的 AI 大约占 ASR 与 AI 合计时间的 82%–88%。ASR 尾段已经压到半秒附近，但最终的纠错、标点、格式和意图约束仍需要约两秒到三秒出头。下一轮优化重点是复用录音期间完成的滚动 AI 结果，只整理尚未冻结的尾部，而不是每次重新处理整篇文本。
05 · WHAT THIS DOES NOT MEAN
长录音不是完全免费
- 网络累计流量、断线恢复和片段去重仍随时间增加。
- 稳定前缀合并必须防止漏词、重复和语言翻转。
- 长文本 AI 的上下文、输出长度和成本仍会增长。
- 10–20 分钟会议需要独立的分块上传、任务队列、说话人和摘要流程。
- 当前数字来自少量真实 History 样本，不等同于完整 p50/p95/p99 生产承诺。
06 · NEXT
下一步是让 AI 也具备同样的尾段有界特性
稳定句子在录音期间异步整理并冻结；停止时只把最后的未稳定语义片段与少量不可变上下文交给 AI。AI 超时或失败时先交付可靠 ASR，不能让润色阻塞输入。达到这一点以后，录音长度对停止后等待的影响才会进一步缩小。
证据 · 诊断
现有证据能说明什么，不能说明什么
这次改动解决的是停止后的尾延迟，而不是宣称长录音没有成本。判断依据来自同一客户端记录的录音时长、final ASR 与 AI 阶段计时；没有用单次 GPU 跑分替代端到端结果。
运维 · 开放工作
失败时如何退化，以及下一道验证门槛
验证还缺少多地区网络、断线恢复、并发会话与 10 分钟以上录音的 p50/p95/p99。若实时会话无法在超时内收口，客户端必须明确降级到完整批量转写，并记录 fallback reason，不能静默丢掉稳定前缀。
- 失败可见性
- 每次降级都必须记录原因码和阶段计时。最终拿到文字，不能抹掉实时、AI 或粘贴此前失败的事实。
- 发布证据
- request ID、实际模型、节点、排队、上传、ASR、AI 和交付时间必须保存在同一条可追踪链路中，才能完整复盘回归。