为什么要先建评估体系
很多 AI 项目的早期验收方式很朴素：找几个同事随便问一问，感觉“回答还不错”，就开始推进上线。这个阶段当然有价值，它能帮助团队确认方向，但它不能支撑一个长期运行的产品。
因为 AI 产品的质量问题不是一次性的。知识库会更新，用户问题会变化，Prompt 会被优化，模型版本会升级，工具调用链路也会调整。只靠人工体验，很难知道一次修改到底让系统变好了，还是只是让某几个样例变好了。
AI 产品的评估体系，本质上是把“感觉还行”变成“可以被复现、比较和追踪”的产品机制。
先定义评估对象
我们最开始踩过一个坑：试图给“AI 回答质量”打一个总分。结果大家很快发现，总分没有指导意义。一个回答可能事实正确但语气很差，也可能语气很好但引用了错误资料。总分会把这些问题混在一起。
后来我们把评估对象拆成了几个更具体的任务层级：
- 意图识别：用户到底在问售后、订单、制度、活动，还是投诉？
- 知识召回：系统有没有找到正确的文档、条款或历史记录？
- 答案生成：回答是否准确、完整、可读，并且没有编造？
- 工具调用：是否在该查订单、查会员、查工单时调用了正确工具？
- 边界处理：遇到敏感、超范围或不确定问题时，有没有正确拒答或转人工？
这一步很重要。评估粒度越清楚，问题定位越快。否则你只会得到一句“AI 不好用”，但不知道该改知识库、改 Prompt、改 RAG、改工具，还是改产品流程。
7 类评估模板
在智能问答平台里，我们把测试样本按任务类型做成了 7 类模板。每一类模板都有固定字段、评分维度和失败原因，便于产品、测试和研发使用同一套语言沟通。
评分规则不要太复杂
评分规则越复杂，早期越难落地。我的经验是先用 0 / 1 / 2 三档，再配失败原因，比一开始就设计 100 分制更有效。
| 分数 | 含义 | 处理方式 |
|---|---|---|
| 2 | 答案可直接交付，事实正确、信息完整、表达清楚。 | 进入通过样本，可作为后续回归评估基线。 |
| 1 | 方向正确但有瑕疵，例如缺步骤、表达绕、引用不够明确。 | 记录为可优化样本，进入 Prompt 或知识库改进队列。 |
| 0 | 事实错误、答非所问、越权承诺、错误调用工具或应转人工未转。 | 阻断上线或回滚修改，必须定位到具体原因。 |
这套分法的好处是产品和研发都容易理解。更细的分数可以后面再加，但第一版必须让团队愿意长期填写和复盘。
阈值怎么设
评估体系真正起作用，是从设置阈值开始的。没有阈值，评估只是记录；有了阈值，它才会变成发布门禁。
我们通常会把样本分成三组：
- 核心高频问题：必须高通过率，任何明显错误都不应该上线。
- 长尾普通问题：允许部分表达不完美，但不能出现事实错误和明显误导。
- 高风险问题：宁可保守转人工，也不要让 AI 自信地给错答案。
评估流程怎么跑
一套可持续的评估流程，至少要覆盖上线前和上线后两个阶段。
上线前：回归评估
每次改 Prompt、改知识库、换模型、调整 RAG 参数之前，都要跑一遍固定样本集。重点不是看单次结果多漂亮，而是看和上一个版本相比有没有退化。
上线后：真实会话抽检
线上真实问题永远比测试集丰富。我们会定期抽取未解决、低满意度、转人工、重复追问的会话，把它们沉淀成新的评估样本。这样测试集会随着业务一起生长。
异常样本：反向进入产品 Backlog
如果某类问题反复失败，不要只让工程师改 Prompt。它可能意味着产品流程不清晰、知识文档结构不好、业务规则本身有歧义。评估结果应该进入产品 Backlog，而不是停留在测试报告里。
落地后的变化
评估体系上线后，团队讨论 AI 质量的方式会明显变化。过去大家说“这个回答感觉不太行”，现在会说“这个样本事实正确，但完整性是 1 分，因为漏了售后时效条件”。
- 问题定位更快：失败样本可以直接归因到知识、Prompt、工具或流程。
- 发布更有底：每次调整都有回归数据，不再依赖零散体验。
- 跨团队沟通更顺：产品、测试、研发和业务都用同一套质量语言。
总结
AI 产品的质量评估体系，不是为了把 AI 变成一个考试机器，而是为了让团队持续知道：系统在哪些问题上可靠，在哪些问题上不可靠，以及下一步应该改哪里。
对企业级 AI 产品来说，评估体系和功能本身一样重要。没有评估，AI 很难从 Demo 走向可持续交付；有了评估，产品迭代才有真正的方向感。
欢迎通过邮件和我交流：shaoyanyan91@163.com
本文首发于邵炎炎个人博客。转载请注明出处。