01

60 秒回答模板

我会先按小爱同学这类语音助手的真实使用场景划分评测对象，而不是只问大模型通用能力。常见场景可以分为设备控制、信息查询、日程提醒、闲聊陪伴、多轮任务、模糊指令、儿童或家庭成员表达、噪声环境和拒答安全。每类场景都要建立离线评测集，包括语音转写文本、上下文、期望意图、可接受答案、不可接受答案和风险标签。核心指标分三层：第一是理解是否正确，包括 ASR 后文本是否被正确识别、意图和槽位是否正确；第二是回答是否满足用户，包括任务完成率、一次满足率、澄清成功率、无效回答率和用户满足率；第三是体验和安全，包括响应时延、多轮轮次、打断恢复、拒答合理性和敏感内容。线上满足率不能只靠点赞，可以结合显式反馈、是否继续追问、是否重复提问、是否改用手动操作、是否放弃。评测要有固定周期，用 badcase 反哺提示词、知识库、场景策略和模型版本。

考点 场景树
难度 真实面经题
回答目标 设计语音助手评测方案
02

深入解析

01

先按语音场景划分评测范围

语音助手不是通用聊天框，评测必须按入口和任务划分。可以区分设备控制、信息查询、日程提醒、内容播放、闲聊、多轮任务、模糊指令、噪声环境和安全拒答。不同场景的成功标准不同，不能用一个总分覆盖全部。

02

离线评测集要保留上下文和标准答案

离线集应包含用户原始语音转写、设备或会话上下文、期望意图、槽位、可接受答案、不可接受答案和风险标签。语音助手还要覆盖口语化、省略、方言或噪声转写错误等样本。这样才能判断大模型是在理解、推理还是回复策略上失败。

03

用户满足率要定义清楚分母和成功标准

用户满足率可以定义为在有效请求中，用户目标被完成或答案被接受的比例。分母要排除无效唤醒、无法听清、非目标噪声等边界情况，也可以单独统计。成功标准要按场景定，例如设备控制看是否执行正确，查询看答案是否有用，闲聊看是否自然且安全。

04

线上信号要结合显式和隐式反馈

线上不能只依赖点赞点踩。可以结合用户是否继续追问、是否重复同一问题、是否改用手机或手动入口、是否取消任务、是否中断会话、是否在多轮后完成目标。显式反馈适合解释原因，隐式行为适合覆盖更大流量。

05

评测要形成版本迭代机制

评测方案要规定更新节奏、回归集、badcase 分层和上线门槛。每次模型、提示词、知识库或场景策略变更，都要比较核心场景满足率、失败率、时延和安全护栏。线上新 badcase 再回流到离线集，避免只优化旧问题。

03

易错点

  • 把语音助手评测答成通用 LLM 排行榜，没有场景划分。
  • 只看文本答案准确率，忽略 ASR、设备执行、多轮和时延。
  • 没有定义用户满足率分母，导致误唤醒和有效请求混在一起。
  • 只依赖点赞点踩，没有结合重复提问、放弃和手动改用等隐式信号。
  • 没有 badcase 回流和版本回归，评测不能支撑持续迭代。
04

面试官追问

语音助手评测为什么不能只看大模型问答准确率？

因为语音助手还涉及唤醒、ASR、上下文、设备状态、执行动作、时延和多轮体验，用户满足不等于文本答案正确。

用户满足率的分母怎么定？

应先定义有效用户请求，再把无效唤醒、环境噪声、无法听清等边界单独统计，否则满足率会被不同问题混淆。

没有显式反馈时怎么估计满足？

可以看用户是否重复提问、继续追问、改用其他入口、取消任务、手动完成或快速结束会话，再抽样人工复核。

离线评测集多久更新一次？

固定回归集要稳定保留，新 badcase 应按周期补充。高频失败、上线新能力和风险场景要优先进入下一轮评测。