C7.15.2Truncate chunk or reject over-limit audio设计研究
超过上限时系统可能截断、分段处理或直接拒绝
别名: 超长截断 · 分段识别 · 拒绝请求
概念解释
音频碰到时长或字数上限之后，系统有三种常见处置：截断（只认前一段，后面丢掉）、分段（切成多次请求再拼接）、拒绝（整段失败、不返回可用文本）。三种对用户的可见结果完全不同，却常常用同一个转圈图标结束。超过上限不是一种错误，而是要选一种协议。
机制
截断实现最便宜：计时器到就封口，等于一次强制端点，后半段不在任何缓冲里。分段把长流切成窗口，每个窗口独立解码，再在文本层拼接，能保住内容，但窗口边界会制造自己的错误。拒绝保护服务端，把责任推回用户，听写场景最伤：说了两分钟只换来失败。产品内部不同层可能各选一种——端上截断、云端拒绝——用户看到的是随机。与端点过早截断相比，这里的切断由容量触发，即使用户一直在说、声学上毫无静音。
怎么研究
送超上限音频，分类实际行为，并询问用户以为发生了什么。测量分段拼接后的 WER 相对整段离线识别。记录是否有错误码或提示。把三种处置做成实验条件，比较任务完成。不要假设文档写的“支持长音频”等于不分段。
边界
实时字幕必须分段，拒绝不成立。命令若超过上限，拒绝比截断安全，以免执行半句。法律取证录音另有完整保存义务，不能用识别上限当删除借口。用户手动停止属于主动截断，不是超限协议。
怎么落地
- 选定一种处置并在界面上说清：截断要标明“只识别了前 N 秒”，分段要允许用户看到接缝，拒绝要给缩短后再试的路。
- 命令路径偏拒绝或让用户确认半句；听写路径偏分段。
- 验收超限样本，禁止出现“成功返回却缺了后半段还不提示”。