评估语音输入产品时最常见的两个数字是识别准确率和模型推理耗时。它们都重要却不足以解释用户为什么试用几次后仍然回到键盘。对交互式语音输入而言用户要完成的不是“获得一次识别结果”而是把一段意思变成可以继续编辑、发送或提交的文本。中间任何不稳定等待、文本反复变化、光标错位和高成本改错都会被统一感知为“不好用”。因此评价体系应该覆盖从开始录音到文本完成的整条链路。一、首个反馈时间从用户按下快捷键或开始说话到界面第一次明确显示“正在录音”或音量反馈的时间。这项指标不等于识别延迟却决定用户是否知道操作已经生效。没有及时反馈时用户会重复按键、重新说话甚至认为权限或麦克风出了问题。除了中位数还要统计未出现反馈和反馈状态错误的比例。二、结束输入到首段文本时间从用户松开按键、点击停止或系统检测到语音结束到第一段可见文本出现的时间。这段时间可能包含音频收尾、编码、上传、网关、排队、推理和结果回传。只记录服务端模型耗时会把网络与客户端处理全部藏起来。埋点时应同时记录客户端总耗时和服务端各阶段耗时先判断问题位于客户端、服务端还是两者之间。三、结束输入到稳定文本时间首段文本出现不等于结果已经可用。流式识别可能不断修改前面的词用户看见文字却不敢开始编辑。Microsoft Speech 的实时字幕文档明确讨论了延迟与稳定性的权衡更早展示临时结果可以降低感知等待但要求更稳定的部分结果通常会增加延迟。语音输入产品需要单独记录“首段文本”和“稳定文本”否则看起来很快的界面可能一直闪烁修改。稳定文本的定义应在产品内固定例如连续若干次结果不再修改或收到服务端 final 标记。不要在不同版本里随意改变口径。四、P50、P95 和超时率平均值会掩盖少量但严重的长尾。稳定的两秒等待通常比“多数一秒、偶尔二十秒”更容易建立使用预期。至少报告 P50、P95 和超过体验阈值的请求比例。阈值应由任务类型和用户研究确定不应直接照搬其他产品。还要按音频时长、网络类型、设备、客户端版本和服务端版本分组否则总体分位数无法定位变化来自哪里。五、文本返工率识别准确率通常基于标注语料计算而真实输入还包含产品名、代码、标点、口头修正和用户自己的表达习惯。更接近生产效率的指标是文本返工率稳定结果出现后用户删除、替换或重新输入的字符数占初始结果字符数的比例。返工率不能简单把所有编辑视为识别错误。用户可能主动润色表达因此需要结合编辑位置、编辑时间和可选的匿名反馈分类并在隐私允许的前提下采集。原始语音和完整文本默认不应为了指标而长期保存。六、单次纠错操作成本同样一个错字如果需要切换鼠标、定位光标、删除整句并重新输入它的体验损失远高于一次快捷撤销或局部重录。可以记录从用户开始修改到再次继续输入的时间、鼠标点击次数、键盘操作次数和是否触发重录。产品优化的目标不是让错误统计看起来更少而是让无法避免的错误更容易修正。七、中断与恢复率语音输入链路可能在麦克风权限、设备切换、录音、上传、识别、写入光标位置等阶段失败。每个阶段都需要稳定的错误码不能全部落成“识别失败”。中断率应按阶段统计同时记录用户是否能在不丢失已录音内容的情况下重试。对于可恢复故障界面需要告诉用户系统正在重连还是必须重新录音沉默等待比明确失败更容易破坏信任。八、半小时会话成功率单次请求通过并不能代表产品可以长期使用。设备切换、模型冷启动、网络波动、队列积压和文本写入冲突往往只在连续使用中出现。可以把一次连续工作会话定义为固定时长或固定请求数统计其中是否发生过阻断性错误、长尾等待和需要重新授权的情况。这个指标更接近“用户敢不敢把它当成日常输入方式”。一套最小埋点结构每次语音输入生成一个随机请求 ID客户端记录录音开始、录音结束、编码结束、上传开始、收到首段文本、收到稳定文本和文本写入完成服务端记录接收完成、排队开始、推理开始、推理结束和响应完成。日志只保存时间戳、阶段、版本和经过脱敏的错误分类。不要在分析日志中保存完整语音、识别文本、真实文件路径、账户或设备标识。确需样本诊断时应使用独立授权、最小留存和可删除机制。分析时先检查事件是否完整再计算阶段耗时。缺失事件不能当作零毫秒时钟不一致时也不能直接拿客户端绝对时间减服务端绝对时间。跨端分析应以各端内部持续时间和关联 ID 为基础。最后看“完成文字”而不是“模型跑完”语音输入并不是键盘的完全替代品。更现实的产品关系是语音负责快速生成键盘负责精确修改系统负责降低等待、反复变化和纠错成本。模型推理速度回答的是一个组件有多快首个反馈、稳定文本、长尾、返工和恢复指标回答的才是用户完成一段文字究竟要付出多少成本。参考资料Microsoft Speech 实时字幕中的稳定结果与延迟权衡Microsoft Speech 实时语音识别说明作者Julian Cooper创作说明本文由作者基于既有语音输入产品材料与 Microsoft Speech 官方资料撰写使用 AI 辅助整理作者对事实和内容负责。