Lotte Verheyden 发布了一篇关于 AI 评估（Evals）的系统指南，属于 AI Engineering Lifecycle 系列的一部分。核心命题：如何把生产环境的反馈转化为结构化的开发迭代。
评估在 AI 工程循环中的位置
整个循环大致是这样的：
生产环境（tracing、monitoring）→ 开发迭代（datasets、experiments、evaluation）→ 发布改进 → 产生新数据 → 再次循环。
Offline evaluation 是实验中运行应用后、正式发布前的判断环节——你有一个数据集，已经跑过应用，现在需要判断输出是否合格。
评估的三种方式
| 方式 | 适用场景 | 特点 |
|---|---|---|
| Manual | 初期建立直觉、发现新的 failure mode | 慢，但不可替代 |
| Code-based | 可确定性验证的属性（JSON格式、关键词、长度限制） | 快、便宜、结果一致 |
| LLM-as-judge | 需要理解语言质量的场景（相关性、语气、摘要准确度） | 灵活，但需要校准 |
Code-based evaluator 能做什么
- 输出是否是合法 JSON / 符合 schema
- 输出是否包含（或不包含）特定关键词
- 输出长度是否在限制内
- 生成的 SQL 是否能执行
局限：无法评估语义。它能检查输出包含"refund"这个词，但无法判断输出是否正确解释了退款政策。
LLM-as-judge 的陷阱
LLM 评委不完美，容易出错：
- 不会自动像人类专家那样评分——它们没有专家的业务上下文
- 需要针对人类偏好进行校准，验证它们确实在测你以为它们在测的东西
- 可能和你的应用 LLM 有同样的 blind spots，尤其当两者用同一模型家族时
但这些局限不是不用 LLM judge 的理由。经过人类标签校准、并有 code-based check backing 的 LLM judge 是可靠的评估器。
Reference-based vs Reference-free
两种自动化 evaluator 都可以是"有参考"或"无参考"的：
- Reference-based：输出与预定义的期望输出对比（正确答案、golden response）
- Reference-free：独立评估输出，不需要 ground truth
Reference-free 的优势在于能直接应用于未见过的生产数据。Reference-based 永远需要预定义的参考响应。
从人工到自动化的正确路径
永远从手动review开始。 阅读输出能建立对你应用实际行为的理解：它在哪里挣扎、"好"的标准是什么。这种理解决定了你后续该建什么自动化 evaluator、如何定义它们的 criteria。跳过这步直接上自动化的团队，往往测的是无关紧要的东西。
什么时候该建 evaluator？
问自己：这个问题是一次性修复，还是泛化问题？
- 如果改个 prompt 就能解决，直接改，不需要 evaluator
- 如果你能清晰识别一个 failure mode，想要在不同输入上反复测试——这时候才值得建 evaluator
设计 evaluator 的实用建议
-
避免模糊标准："helpfulness"或"quality"这种泛化指标很少产生有用的信号。 evaluator 检查的标准越模糊，结果越模糊。
-
优先 binary（pass/fail）：比 1-5 评分更 sharp。Binary 强制你清晰定义"可接受"与"不可接受"的分界线。评分 scale 引入歧义——3 和 4 的区别是什么？这让分数更难解读，跨 evaluator 和跨时间的 consistency 也更差。
-
每个关心的质量维度配一个 evaluator：成熟的评估 setup 通常同时使用 code-based 和 LLM-as-judge evaluator，两者结合才能看清应用的整体质量。
生产环境的闭环
评估不应该只停留在离线实验。Reference-free evaluator、用户反馈信号、其他生产安全的 check 都可以应用到线上流量，确认生产质量与部署前一致。
如果生产行为符合预期，可以更有信心地 scale。如果不符合，把 case capture 到 traces 里，转成 dataset items，跑下一轮 evaluation。这就是闭环。
核心 takeaway：评估不是一次性设置，而是持续迭代的系统。从人工 review 建立直觉，只把需要反复测试的 failure mode 自动化，binary 评分比 scale 更 sharp，生产数据反哺开发迭代——这才是可持续的 AI 质量工程。