15 Golden Dataset、Trace、可观测与评估基础设施
章节目标
理解 evaluation as infrastructure：评估不是上线前一次测试，而是贯穿开发、发布和生产监控的基础设施。
为什么重要
生产 Agent 最大风险不是单次输出不好，而是无法复现、无法解释、无法回归、无法发现漂移。没有 Trace 和评估，用户会成为测试人员。
开篇案例：一次 Prompt 优化导致的退化
团队为了让客服回复更自然，改了一版 Prompt。新版本在演示样本上更像真人，但上线试用后，高风险投诉工单的转人工率下降了，几个应该升级的工单被生成了普通回复。问题不是 Prompt 改坏了语气，而是没有回归测试：团队只看了几个成功样本，没有用高风险 Golden Dataset 跑一遍。
这就是 evaluation as infrastructure 的意义。AI 系统每次改模型、Prompt、检索、工具或知识库，都可能改变行为。没有评估和 Trace，团队只能靠用户报错发现退化。
EDD：评估驱动开发
Evaluation-Driven Development（EDD） 让 AI 项目从“感觉调参”变成指标驱动迭代：
- 先定义业务指标和 Ground Truth（通常由 AIBP / 业务专家确认）。
- 再搭建最小链路和 Golden Dataset。
- 每次 Prompt、检索或工具变更都跑回归。
- 未过阈值则阻断发布。
五层评估
在三层评估（组件 / 任务 / 业务）基础上，生产项目可细化为五层：
| 层级 | 评估对象 | 示例 |
|---|---|---|
| L1 解析 / ETL | 文档解析、切分质量 | 表格还原率、元数据完整率 |
| L2 检索 | 召回与引用 | 召回率、引用准确率 |
| L3 生成 | 答案与结构 | 格式合规、事实一致性 |
| L4 工具 | 调用与执行 | 工具成功率、参数正确率 |
| L5 业务 | 端到端任务 | 任务完成率、人工修改率、采纳率 |
五类 Golden Dataset
| 类型 | 用途 |
|---|---|
| 典型样本 | 覆盖主路径 happy path |
| 边界样本 | 模糊问法、多意图、缺字段 |
| 失败样本 | 已知历史败例，防回归 |
| 高风险样本 | 合规、资金、承诺类必过人审 |
| 对抗样本 | 诱导幻觉、越权、注入 |
PoC 阶段可先用 20–50 条，生产前扩展到 100–300 条。
LLM-as-Judge
可用 LLM 作评审员加速评估，但必须：
- 使用明确 Rubric（打分维度与阈值）。
- 用人工标注集校准 Judge 偏差。
- 高风险结论仍以人工为准。
Judge 适合大规模初筛，不适合替代合规终审。
回归门禁
推荐三类检查：
- PR 快速检查：工具是否调用正确，输出结构是否合规。
- 夜间回归测试：核心样本是否退化。
- 生产监控：漂移、失败率、成本和高风险输出是否异常。
Trace 记录
一次任务应能回放：用户输入、检索内容、Prompt 版本、模型输出、工具调用、人审结果、最终输出、成本与延迟。
评估报告模板
## 本次评估范围
- 场景：
- 模型 / Prompt 版本：
- 知识库版本：
- 工具版本：
## 样本分布
| 类型 | 数量 | 通过率 |
| --- | --- | --- |
| 典型 | | |
| 边界 | | |
| 失败回归 | | |
| 高风险 | | |
| 对抗 | | |
## 主要失败类型
- 检索失败：
- 引用错误：
- 工具参数错误：
- 风险判断错误：
## 是否允许发布
- 结论：
- 阻断项：
- 下次改进：
评估不是为了追求 100 分
PoC 阶段最重要的是找出失败边界，而不是把分数包装得好看。一个诚实的评估报告应该告诉客户：
- 哪些任务已经稳定。
- 哪些任务只能建议，不能自动执行。
- 哪些样本必须人审。
- 哪些指标还不足以上线。
这类透明度反而会提高客户信任。
实操任务
为你的场景设计：
- 20 条 Golden Dataset。
- 5 类失败样本。
- Trace 字段。
- 发布阈值。
- 生产告警规则。
交付物
- Golden Dataset 表。
- 失败样本分类。
- Trace 字段表。
- 评估仪表盘草图。
常见误区
- 只看最终答案，不看中间步骤。
- 只用人工主观判断，不设阈值。
- 没有版本化 Prompt 和知识库。
- 没有回归测试。
检查清单
- 是否能复现一次失败？
- 是否知道是检索错、工具错还是生成错？
- 是否能阻止效果退化上线？
- 是否能跟踪 cost per task？