后记
本页导航
还记得第 1 章开头那个上线后暴露问题的假设性客服 Agent 吗？
它的接口正常、标准问答准确，退款、物流和订单三个主流程也能走通——测试报告看起来很完整。然而上线后，口语化表达识别失败、多轮上下文丢失、知识库冲突条款未处理、工具失败后编造承诺、高风险金额问题未转人工等缺口仍然暴露出来。
如果那个团队采用本书的方法，目标状态可能是什么样？
下面描述的是一个假设性的未来状态。涉及的样本量、阈值、时间和运行结果都用于说明方法关系，不代表真实项目成果或通用行业标准。
同一个 Agent 的目标状态
业务目标从一开始就被拆成了可度量指标：自助解决率、退款政策正确率、工具参数准确率、越权率、转人工率、P95 延迟、单会话成本。每个指标都绑定了数据集、Evaluator、阈值和门禁规则，不再停留在墙上的数字。
客服 Agent 的退款场景有了分层评测。RAG 组件单独测召回率和引用准确率，Tool Call 组件单独测工具选择和参数生成，编排执行层通过 Trace 检查步骤顺序和异常恢复，应用业务层通过端到端 Case 检查任务完成率和风险边界。不再用一个“回答对不对”覆盖所有问题。
Eval Set 不再只有 happy path。它分成了 Golden Set（核心稳定能力）、Regression Set（已修复问题防复发）、Hard Case Set（长尾和边界场景）、Red Team Set（安全攻击样本）。会员部分退款叠加优惠券的场景进入 Hard Case；他人订单查询则通过多轮诱导变体进入 Red Team Set。每层需要多少样本，由风险覆盖和统计目标决定。
Evaluator 不再由单一 Judge 包办。隐私泄露和禁止承诺用规则拦截，退款金额和工具参数用脚本计算，政策忠实度和表达清晰度用 Rubric 约束的 LLM-as-Judge 评分；高风险退款、证据不足或 Judge 自报无法确定的样本进入人工复核。Judge Prompt 还需要通过试标与人评对照校准，避免把表达长度误当作质量。
每次评测 Run 都记录完整版本血缘：模型版本、Prompt 版本、知识库索引版本、工具 Schema 版本、Evaluator 版本、数据集版本。当两个版本分数不同时，团队能够先核对“是什么变了”，再结合切片和证据定位差异来源。
发布不再只凭感觉。项目可以把隐私泄露、越权操作等事件定义为 P0 并直接阻断，把其他高风险失败按制度映射到对应门禁；成本和延迟超过软门禁时进入评审。候选版本在物流场景改善但退款场景退化时，Gate Result 会保留分场景证据，发布责任人再据此作出整体放行、受限灰度或阻断决定，而不是让平均分掩盖风险。
线上监控不再是事后看投诉率。转人工率、追问率、工具失败率、无证据回答率、单会话成本实时看板，异常自动告警。线上出现新的 Bad Case 时，经过脱敏、去重、归因后会进入候选 Regression Set，而不是被人工修完就遗忘。
那个曾经把“积分不会扣回”答错的会员部分退款场景，现在有了明确的处理流程：
- 它在 Hard Case Set 里有覆盖主要边界的变体样本
- 正确政策未召回时归因到 RAG 层，提示优化 Chunk 和召回策略
- 政策已召回但模型仍编造时归因到 Prompt 或模型忠实性，补充约束 Few-shot
- 未调用退款规则工具时归因到编排层，检查工具前置策略
- 无论修复发生在哪一层，完成后都要通过 Regression Set，并在后续版本中持续回归
比分数变化更重要的是，团队讨论质量的语言变了。他们不再争论“模型行不行”，而是追问“这个 Bad Case 的 RAG 召回率是多少”“Trace 里工具参数错在第几步”“门禁规则是否需要调整”“这个样本该进 Golden 还是 Regression”。质量由主观感受变成了可观测、可归因、可改进的工程对象。
从最小闭环开始
我在写这本书的过程中，经常被问到一个问题：评测做到什么程度算“够了”？
不存在适用于所有项目的固定覆盖率或样本数。评测没有一劳永逸的终点，建设可以从一个可验证的范围开始。
很少有团队能在第一天就建成完整的 EvalOps 平台、覆盖所有长尾场景、完成 Judge 校准并实现线上回流自动化。但可以从最小闭环开始：选择一个核心业务场景（例如退款），构建一组覆盖关键风险的起始 Eval Set，实现规则、脚本与 Judge 组合的基础 Evaluator，记录版本血缘，设置最基本的硬门禁，再把线上 Bad Case 经治理后回流到回归集。
这个最小闭环跑通后，再逐步扩展场景、增加数据分层、完善平台能力、接入 CI/CD、建立红队机制。评测体系随后与 AI 应用一起持续演进。
本书提供一套思考框架和可操作的工具。每个企业的业务场景、风险偏好和团队结构不同，具体指标、阈值与流程也会不同；以下原则仍可复用：
- 从业务目标和风险出发选择评测，而不是从 Benchmark 反推业务。
- 对被评对象分层，避免总分掩盖层级问题。
- 按数据资产的方式管理版本、血缘和生命周期。
- 把 Evaluator 当作度量仪器，持续选型、校准和 Meta-Eval。
- 记录版本血缘，让评测可复现、差异可解释。
- 让评测进入门禁，并用线上信号持续校准。
- 把 Bad Case 转成修复、验证和回归资产。
- 将安全作为一等维度贯穿全程。
给正在建设 AI 质量体系的你
如果你正在一家企业从零搭建 AI 评测体系，我会给你三个建议：
先闭环，再扩展。 不必等到平台、数据和 Judge 全部成熟才开始。先用脚本和工作表跑通一个场景的“评测→门禁→回流”最小闭环，并明确当前证据只能支持哪些结论；再根据风险和失败分布扩展覆盖。
先风险，再覆盖。 不要平均分配评测资源。找出你的 P0 场景——那些一旦出错会造成财务损失、合规风险或用户信任崩塌的场景——先把它们评测到可信程度，再扩展到长尾体验问题。一个越权查询都拦不住的系统，答案满意度再高也没有意义。
先归因，再优化。 看到 Bad Case 时忍住直接改 Prompt 或微调模型的冲动。先花时间定位根因：是知识缺失、检索失败、上下文截断、工具错误、编排遗漏，还是模型幻觉？归因对了，一个修复可能解决一类问题；归因错了，十个修复可能只是在打补丁。
AI 系统的质量不会自动发生。它需要被设计、度量、维护和持续改进。评测体系让质量状态可观察，让发布判断有证据，让失败处理有责任人。
希望这本书成为你建设这套基础设施时的有用参考。
愿每一次上线，都有与风险相称的证据和清晰的责任边界。
——作者 2026 年 7 月