评估语音智能体

文字记录正是那件藏起故障的东西。

几乎每个语音团队都从评估文本开始：把文字记录喂进给聊天智能体打分的同一套框架，检查答案，发布。而那套框架量的恰恰是最不可能坏掉的那一层。在干净文本上做推理的模型是这个栈里成熟的部分；故障住在它的上面和下面。

• 识别错误按定义就被抹掉了。如果语音识别把"Preston"听成了"Preston Road"，文字记录里就是那个错的字符串，而智能体的回答是对着错误问题给出的完全正确的回答。文字记录评测会判它通过，因为文字记录是它拥有的唯一"真值"。
• 时序压根没被表示出来。文字记录有顺序，没有钟。工具执行时的那三秒沉默、在来电者说完之前就开口的那次响应、被智能体压过去的那次打断——没有一样能在渲染中幸存，而它们全是来电者记住的东西。
• 语调携带着文本没有的意义。"行啊，好"是同意还是讥讽，取决于任何进不了文字记录的东西。人工坐席一秒就能捕捉到的那个升级信号，是来电者的语气变了，而没有任何文本流水线看得见它。
• 这种故障是无声的，不是响亮的。没有任何东西报错。智能体很流畅，文字记录读起来很好，评测是绿的，而自助解决率就那么静静地低于 demo 所暗示的十个百分点。

后果是结构性的：语音智能体的评估单位必须是一个音频文件，而这个决定的下游一切都由它推导而来。识别层究竟对你的输入做了什么，见 STT、TTS 与语音到语音。

词错误率是错的那个数字；要给决定结果的那些实体打分。

WER 是语音行业塞给你的指标，而它对智能体近乎无用，因为它对每个词一视同仁。一份 96% 准确的记录仍然可能已经毁掉了这通电话——如果那 4% 是账号的话。反过来，一份满是语气词错误的记录，在功能上可能完美无瑕。

• 按用例定义一个实体集合。人名、日期、金额、订单号、邮编、地址、产品 SKU，以及对关键问题的是/否回答。任务就系在这些 token 上。给实体错误率打分——这些实体中被转写错的比例——并把它当作正式的准确率指标。
• 字母数字混合串自成一类，而且是最难的一类。参考编码、车牌、会员号：语言模型的先验帮不上忙，电话带宽抹掉了字母之间的声学区别，而一个字符之差就是"正确的账户"与"别人的账户"之别。如果你的任务牵涉它们，它们需要评测集里一片专门的切片，多半还需要一套专门的确认策略。
• 给"纠回来"打分，而不只是给"错了"打分。识别一定会出错；问题是智能体有没有察觉。一个会把捕获到的值复述一遍、从而抓住听错的智能体，把一次错误变成了两秒的延迟；一个自信地往下走的智能体，则把它变成了一个错误的结果。把"使用前已确认"写成套件里的一条断言。
• 按来电者分段，而不只是看总体。聚合后的实体错误率会掩盖这样一件事：智能体对某个口音群体好用，对另一个不灵。这是最容易让平均值在政治上舒服、在运营上失真的指标。

用真实音频搭黄金集，且要在通话真正发生的条件下录。

评测集就是整件事本身，而在语音里它比在文本里难组建得多，因为输入带有物理属性。一段配合的说话人在录音棚里照稿念出来的干净录音，几乎测不到生产环境会对你做的任何事。

• 从录下来的生产通话出发，先把知情同意与脱敏处理好。真实来电者会打断、会说到一半改主意、会开免提、会答非所问。没有哪个合成脚本能造出那样的分布。
• 有意识地覆盖声学维度。固话与手机、免提、车噪、咖啡馆、婴儿、一条带丢包的糟糕连接。电话音频是窄带的——8 kHz 会改变每一个基准——所以一份用笔记本麦克风录出来的评测集，量的是一条你并不服务的信道。
• 有意识地覆盖说话人维度。口音、语速、年龄、非母语者，还有那位正在发火的来电者。其中任何一项代表性不足，都意味着交付出一个只对"碰巧听起来像你团队"的人好用的智能体。
• 留一片"困难切片"并单独报告。那二十通真正难的电话——重噪声、一个逐字母拼出来的罕见姓名、一次通话中途的更正——会被平均值淹没。而它们恰恰是能预测生产投诉的那些。
• 用合成音频来扩量，不要用它来认证。TTS 生成的测试来电者对回归的广度很有用，也几乎不花钱，但它们太干净、节奏太好、太配合。一套完全合成的套件报出来的数字，你真实的来电者不会认。要给它下锚：保留一片固定的真人音频切片，并检查两者是否同向移动。

给时序打分，因为对来电者而言时序就是产品。

在文本里，延迟是一个舒适度问题。在一通电话里，它是一个正确性问题：超过一定长度的沉默会被理解成线路断了，而开始得太早的响应读起来就是打断。这些都可测，都该进套件，而它们也正是多数团队从没量过的评分项。

• 逐轮的首段音频时间，看尾部。p95 才是来电者体验为"这智能体坏了"的那个数字，而它能舒舒服服地躲在健康的中位数背后。把它按延迟预算拆开，让一次回归自己点出是哪一段出的问题。
• 端点检测的准确性要看两个方向。抢话率——来电者还在说，智能体就开口了——与悬空时间——来电者说完了，什么也没发生。这两者互相牵制，所以单一的"端点检测质量"数字没法据以行动；你需要两个数，并各有一个明确目标。
• 打断成功率。来电者插话了：智能体有没有在两三百毫秒内停下，又有没有正确吸收对方说的内容？一个压过打断继续说的智能体，是让来电者开口要人工的最可靠办法。见轮次与打断。
• 空气死寂按次数计，不要取平均。任何超过约两秒、既无语音也无填充的空档都是一起事件。按通话计数并对次数报警，因为一次四秒的沉默比处处多出四十毫秒糟糕得多。
• 专门对工具调用的空档做断言。空气死寂最常见的来源，是一次没有前导语的同步工具调用。这是一个你的套件可以确定性地抓住的设计缺陷：每一次超过阈值的工具调用之前，都必须先有语音。

评判结果，而不是评判对话。

一旦音频路径被插上桩，剩下的问题就是这通电话有没有把事办成——而诱惑在于去给"这场交流听起来多舒服"打分，那相当于按编码智能体的解释有多自信来给它评级。

• 任务成功是业务侧的事实，要到记录系统里核。预约真的建上了吗，时间对不对，人对不对？地址是不是被更新成了来电者说的那串字？对着数据库验，永远别对着智能体自称已经做了的说法验。这与结果评估与轨迹评估是同一套纪律，而语音让这条捷径格外诱人——因为那段总结听起来实在太像真的。
• 自助解决率是一个带阴暗面的指标。无需人工即被解决的通话占比，是管理层会要的那个数字，而当智能体拒绝转接时它就会变好看。永远把它和一个升级质量分、以及"之后发生了什么"配对：一通被"解决"的电话如果 24 小时内跟着一次回拨，那是一次失败，而自助解决率会把它报成成功。
• 把移交单独打分。智能体升级之后，人工那边收到上下文了吗，还是来电者要把一切重讲一遍？一次丢状态的转接比没有这个智能体更糟，而它在上面每一个指标里都是隐形的。
• 在文字记录上用 LLM 评判去做它擅长的事——语气、政策遵循、必须说的告知有没有说到——同时把音频派生的指标单独保留。一个给文字记录打分的评判者，量的是第 1 步告诉你本来就没坏的那一层；有用，但永远不该是头条。见 面向智能体的 LLM 评判。
• 合规项是断言，不是分数。录音告知、外呼时的身份披露、同意采集：它们是布尔值，而且是法律问题。它们该作为能拦住发布的不变量进入套件，与外呼要求你必须说出口的那些话放在一起。

把它做成一套框架，而不是一次活动。

一套"有人想起来才跑"的语音评测，就是一套只在首次上线前跑过、此后再没跑过的语音评测。这里独特的运营难题在于：你的栈比文本智能体多出好几家会动的供应商——识别器、模型、合成器、电信运营商——而它们中任何一家都可能不通知你就变。

• 把音频重放进真实流水线，而不是打向 mock。重点就是要把识别器与端点检测逻辑跑一遍。一套从文本起步的框架，已经跳过了最可能出现回归的那两个部件。
• 固定套件要按计划跑，而不只在部署时跑。STT 厂商的一次模型更新、运营商换了编解码、TTS 声音被改版：这些都不会出现在你的变更日志里，而定时跑的那一遍才是当天抓住它们的东西。
• 持续给一小片线上流量打分。一小部分生产通话，就实体字段与时序事件做人工复核，长期进行。你会在这里发现黄金集没能代表的那群来电者。
• 把每一次升级都当作一个带标签的样本。"来电者要人工"是每天免费送上门的监督信号。把原因聚类，排在前三的会比任何离线分析都更准确地点出你接下来该修的三件事。
• 把一切声学配置纳入版本管理。识别模型与版本、音色 ID、VAD 设置、端点检测阈值、编解码。指标一动，你就需要归因，而在语音里，变化出在音频配置上的可能性至少不低于出在提示词上。

相关：语音智能体失败模式是这套套件试图检出的清单，实时智能体架构讲了为何级联与语音到语音两种设计需要不同的插桩，而评估智能体是更一般的情形。