AI evaluation 是什么?为什么上线 AI 应用需要它
AI evaluation（AI 评估）是在上线前和上线后，用一套明确定义的“好”的标准，对模型或智能体的输出质量进行打分和比较的过程。它适合任何已经在生产环境跑 AI 应用、或者准备把 AI 应用推给真实用户的团队——因为 AI 系统的失败方式和普通软件不同，会静默漂移和回归，没有评估就很难在用户察觉之前发现问题。
AI evaluation 解决的是什么问题
普通软件的 bug 通常是确定性的：同样的输入必然触发同样的错误，测试用例能稳定复现。AI 应用不是这样。同一个 prompt，模型可能这次答得好、下次答得差；换一个模型版本、改一句系统提示、调整一次检索策略，整体质量就可能悄悄下滑，而日志里看不出任何“报错”。
Braintrust 对这件事的描述是：agents fail differently than normal software，需要 active observability 来监控和修复；AI 会静默漂移和回归（AI drifts and regresses silently），所以团队要能“针对预期做评估并持续迭代”。
评估的作用就是把“感觉变差了”变成“在某个数据集上，某项指标从 X 降到了 Y”，从而可以判断、可以拦截、可以复现。
评估、可观测性、监控、测试分别管什么
这几个词经常混用，但解决的问题不同。Braintrust 把 AI observability 拆成三个支柱：Observability、Evals、Discovery。
| 概念 | 回答的问题 | 典型动作 |
|---|---|---|
| 可观测性（Observability） | 生产环境里到底发生了什么？ | 实时查看 agent trace、prompt、响应、工具调用，跨海量日志搜索，跟踪延迟、成本、质量 |
| 评估（Evals） | 什么算“好”？现在达标了吗？ | 在真实数据集上跑实验，并排比较 prompt 和模型，用 LLM、代码或人工给输出打分 |
| 监控（Monitoring） | 现在有没有异常？ | 实时性能监控、自定义视图和标注，跟踪线上指标 |
| 测试（Testing） | 这个改动会不会引入回归？ | 用版本化的数据集跑对比实验，在发布前拦住坏版本 |
简单说：可观测性让你看见，评估让你判断，监控让你持续盯着，测试让你在发布前拦住问题。它们不是替代关系，而是同一条质量闭环上的不同环节。
三种打分方式，各自适合什么场景
评估的核心动作是“给输出打分”。Braintrust 支持三类打分方式：LLM 打分、代码打分、人工打分。
- 代码规则打分：适合有确定答案或确定格式的场景，比如输出必须是合法 JSON、必须包含某个字段、分类结果必须落在固定标签集合里。优点是快、便宜、可重复；缺点是无法评价开放式回答的质量。
- LLM 打分：适合开放式生成、语义正确性、风格一致性这类没有唯一答案的场景。用一个模型当裁判，按你定义的标准给输出打分。适合大规模、需要语义理解的判断，但裁判本身的标准要写清楚。
- 人工打分：适合主观性强、或需要领域专家判断的场景，比如客服话术是否得体、医疗或法律相关表述是否稳妥。Braintrust 提到可以构建匹配团队工作流的标注界面，比如审阅客服对话和审阅其他内容用不同的界面。
实际项目里通常是组合使用：先用代码规则卡住硬性约束，再用 LLM 打分覆盖大部分语义质量，最后用人工打分校准和抽查。
评估的数据从哪来
评估要有数据集，而最好的数据集来源就是生产环境本身。Braintrust 的 Discovery 环节描述了一条路径：对 trace 应用智能分析，识别重要行为，验证证据，测试一个改进，再在同一个系统里衡量结果。它还有 Pattern automations，能自动识别生产 trace 中反复出现的问题和机会。
这条路径的实际含义是：
- 在生产 trace 里发现反复出现的行为模式（比如某类问题总是答错、某个工具调用总是失败）；
- 把这条 trace 和它的期望输出整理成一条评估样本；
- 用这条样本跑一次实验，确认改动是否真的解决了问题；
- 把有效的样本沉淀进版本化数据集，成为后续每次发布的回归测试。
这样数据集不是凭空编的，而是来自真实用户遇到过的真实情况。
怎么开始第一次评估
不需要一开始就搭一套完整体系。可以按下面的顺序做：
- 选一个真实场景：从生产 trace 里挑一个具体、高频、你已经在意的任务，比如“用户问退款政策时的回答是否准确”。
- 定义“好”的标准：写清楚什么样的输出算通过。标准要具体到可以被打分，比如“必须引用正确的退款时限，且不承诺政策外的补偿”。
- 选打分方式：硬性约束用代码规则，语义质量用 LLM 打分，边界情况留人工复核。
- 建一个小数据集：从真实 trace 里取 20–50 条有代表性的样本，包含正常情况和已知的失败情况。
- 跑一次对比实验：用同一数据集比较当前版本和一个改动版本（换 prompt、换模型、改检索），看分数是否真的提升。
- 把评估接进发布流程：让评估成为发布前的一道关卡，分数下降就拦住这次发布。
验证方法：如果评估有效，你应该能在一个改动上线前就预测它对质量的影响，而不是等用户投诉。如果每次评估结果都和线上表现对不上，说明数据集或打分标准需要调整。
常见卡点：
- 标准写得太模糊（“回答要好”），导致 LLM 打分不稳定；
- 数据集只覆盖正常情况，没有包含已知失败案例，评估通过但线上仍然出问题；
- 只做一次性评估，没有接进持续流程，模型或 prompt 一改就失去保护。
一句话判断你要不要引入评估
如果你的 AI 应用已经面向真实用户，且你会改动 prompt、模型、检索或工具调用中的任何一项，那么你需要评估——因为每一次改动都可能带来静默回归，而评估是唯一能在用户之前发现它的手段。如果还在纯原型阶段、没有真实用户流量，可以先从可观测性入手，把 trace 记录下来，等有真实数据后再建评估集。