AI客服验收，别只看平均准确率

先说明新材料改变了什么

AWS于11月4日发布的技术文章，介绍将固定选项的判断模型接入Amazon Bedrock AgentCore Evaluations。原文同时保留代码评估和解释型大模型评估：有些问题可以按明确规则检查，有些需要在有限标签中分类，另一些需要更深入地解释原因。这不是一种方法取代全部方法。

配套文档也说明，自定义评估器可以采用模型或代码。本站的判断是，经营者最先需要的并非选出一个“最聪明”的评委，而是写清楚哪些错误会阻断上线。如果验收问题本身含糊，换一个评估模型也可能只是更快地产生一个难以行动的总分。

依据 [1] Amazon Web Services · [2] AWS Documentation

为什么92.5%仍可能漏掉大部分重要问题

下面完全是自拟示例：准备200个客服案例，其中180个普通问题回答正确，另外20个必须转人工的案例只识别出5个。把全部正确结果相加是185个，总体准确率为185÷200＝92.5%；但需要转人工的案例只识别了5÷20＝25%。一个好看的总分，遮住了15个关键遗漏。

同样需要检查反方向错误。如果系统把大量普通订单查询都送人工，虽然看上去谨慎，客服队列却可能被占满。因而至少应分开看该转未转、无需转却转，以及已经转交后是否给出正确背景。不能用单个总分同时代表安全性、服务成本和回答质量。

例如，对普通配送咨询答复稍显冗长，与对尚未确认的退款作出确定承诺，影响并不相同。哪些情况必须复核，应由业务负责人根据自己的规则明确，而不是让模型临时发明。示例中的比例只用来说明统计盲点，不是行业门槛。

把检查方式放到它擅长的位置

对于必填字段、是否带订单依据、格式是否符合约定等明确条件，可以先用代码检查；对于“普通咨询还是需要复核”这样的有限选择，可以研究分类式评估；涉及答复是否充分、解释是否误导，则需要结合原问题和资料做较深入的判断。AWS材料支持这些方法能够组合，并不证明任一业务都应照搬同一套配置。

落到操作上，每个验收案例应保存问题、当时可用资料、预期处理及理由。对存在争议的案例，先由业务方厘清标准，再比较评估结果。模型给出的置信信息可以帮助排序复核工作，不能直接解释为未来业务错误的真实发生概率，除非在自己的样本上完成相应验证。

依据 [1] Amazon Web Services · [2] AWS Documentation

上线判断要能被后来的错误推翻

建议从真实业务允许使用且已处理隐私的案例中建立固定验收集，再补入故意设计的边界案例。固定集用于比较不同版本，新增案例用于暴露旧题库没有覆盖的问题。日常抽查也应保留正常案例，不能只看已经被模型标记为异常的记录，否则漏掉的错误仍然不可见。

AWS文章中的人力资源助手使用模拟工具数据，不能拿来证明某家店铺的售后助手已经可靠。反过来，如果团队只做内部资料检索、从不对客户承诺或执行操作，所需的验收重点也会不同。风险范围变了，检查组合和人工介入条件都应重新评估。

验收集也需要版本记录。商品政策、退款条件或知识资料更新后，旧答案可能不再成立；如果不更新依据，评估器反而会奖励过时回答。每次比较应说明使用哪一版规则、哪些案例因业务变化被调整，并保留调整理由。对资料缺失的案例，正确处理可能是承认无法确认，而非输出一段形式完整却没有依据的答案。

真正有用的验收结论应能说清：在哪些问题上可以使用、哪些情况仍要人工处理、发现哪类遗漏就暂停扩大应用。这样，即使总体分数没有上涨，减少了一类高代价漏判，也可能是比“准确率又高一点”更有价值的进展。

依据 [1] Amazon Web Services