一家制造企业的信息化负责人月底要向管理层汇报智能客服项目的成效。他打开后台，能看到的只有访问次数和对话条数，至于智能体回答得准不准、用户到底解决了多少问题、哪个业务模块的问题最集中，系统没有留下任何可量化的记录。他只能在汇报里写一句系统运行正常、用户反馈总体良好。一个月后，管理层抽看了五十条客服对话，发现其中十一条的回答存在明显错误，有两处还把退换货政策说成了已经废止的旧版本，而这些问题此前从未被任何机制主动暴露出来。
这类问题的核心不在于智能体能力不足，而在于效果评估的缺位。智能体上线后被当作一个已经完成的项目来管理，没有人提前定义什么叫答得好、用哪些指标去衡量、拿什么样本去验证。等到真正需要评估时，才发现既没有评测基准，也没有结构化的反馈数据，只能依靠没被投诉这种被动而滞后的信号来判断效果。评估缺位的后果不是没有结论，而是结论来得太晚，问题已经在用户侧积累了一段时间。
一种常见的做法是把用户没有投诉当作效果好坏的判断依据。用户不投诉的原因很复杂：可能问题不算严重，可能用户懒得反馈，可能用户根本不知道该向谁反馈，也可能用户直接放弃了这项功能转回人工。投诉量低只能说明没有爆发式的严重错误，无法证明回答质量达到了预期。把投诉当作判断效果好坏的全部依据，等于把质量问题的发现时间推迟到了用户已经受损之后，也让团队失去了在上线前主动拦截错误的机会。
另一种做法是只统计一个解决率指标。解决率通常定义为用户在一次会话后未再次提问的比例，但没有再问可能是问题真的解决了，也可能是用户对结果不满意却不想再纠缠。单一指标无法区分答对了和用户不抱希望了这两种截然不同的情况。指标本身没有错，错在只用一个指标就下结论，一个维度的数字很容易掩盖另一个维度的问题。
一类原因是没有建设评测集。评测集是一组事先标注了标准答案或验收标准的问题样本，覆盖核心业务流程、高频提问和已知的易错点。没有评测集，任何一次模型升级或流程调整都无法在上线前回答这次改动有没有把原本答对的问题改坏，只能上线后靠真实用户去试错。评测集缺失还带来一个连带后果：团队无法对不同版本做横向比较，优化改进变成了凭感觉调参，改完不知道是好是坏。
另一类原因是指标没有分层。一套完整的效果评估需要区分离线指标和在线指标，离线指标回答这个版本在标准样本上表现如何，在线指标回答真实用户的实际体验如何。两类指标回答的问题不同，不能互相替代。只盯在线指标，问题往往已经在真实用户中扩散；只盯离线指标，评测集又可能偏离真实使用场景。两者缺失任何一个，评估结论都是片面的。
还有一类原因是反馈没有结构化回流。用户对回答的点赞、点踩、追问、转人工这些行为，如果没有被记录并关联到具体的问答对和知识片段，就无法形成持续改进的输入。反馈散落在日志里，评估体系就失去了自我更新的能力。更常见的情况是反馈虽然被记录了，但只记了一个点踩总数，没有记下用户点踩的是哪条回答、对应哪段知识、是什么类型的问题，这样的反馈几乎没有分析价值。
这类问题在青山不语AI工作室的部分企业AI应用开发项目方案中，被归纳为效果评估与指标分层体系，整个处理流程分为四个环节。
起始环节是评测集建设。在智能体上线前，由业务人员和技术人员共同整理一组黄金问题，覆盖核心业务流程、高频提问和已知的易错点。每个问题标注标准答案或验收要点，并按业务模块分类。评测集作为后续所有评估和回归测试的基准，随业务规则变化持续补充。评测集不是一次性做完了事，业务上线新功能、政策发生变化时，都要同步把对应的问题加进去。
接下来是离线评测。每次智能体版本更新前，用评测集对当前版本跑一遍，记录每个问题的通过情况和整体通过率。离线评测在发布前完成，用于拦截明显的回答退化，那些原本能答对、这次改动后答错的问题，会在发布前被评测集标记出来。通过率低于预设阈值的版本不予发布，或只发布到灰度环境小范围验证。
再往后是在线指标分层。上线后按多个层级监控，结果层看回答是否命中标准答案或通过验收，行为层看用户是否追问、点踩、转人工。结果层和行为层的组合比单一指标更能反映真实体验，一个回答结果层达标但行为层大量点踩，说明答案可能正确但表达方式有问题。各层指标按业务模块分别统计，避免一个高分业务掩盖另一个低分业务。
最后是抽样复核与反馈回流。从每日对话中按比例抽样，由人工对照评测标准复核回答质量，作为离线指标的补充，也用于发现评测集没有覆盖到的新问题。用户的正负反馈结构化记录后，与对应问答对和知识片段关联，定期回流到评测集建设和知识库更新流程中。点踩集中的问题会被补充进评测集，成为下一次离线评测的考察点，形成评估到改进的闭环。
评测集的内容标准由业务团队负责定义，哪些问题属于必须答对的高风险问题由业务团队划定。离线评测和在线指标的技术实现由工程团队负责。抽样复核的执行由质量或运营团队负责。智能体本身不参与效果判定，它只负责在给定条件下生成回答，回答的好坏由上述评估体系独立衡量。
效果评估是智能体项目里最容易拖到最后的环节，很多团队把它当成上线后再补的事。但评测集的价值恰恰在上线之前，它是每次版本升级前拦住退化的那道闸。一个没有评测基准的智能体，每改一次都是一次不知道会不会倒退的试探。我的建议是，把答得好不好这把尺子在开发阶段就跟着智能体一起立起来，而不是等用户用流失来投票。