@lotte_verheyden:在编写好的评估之前,您必须选择正确的评估对象。主要要点:- 从失败中提取指标…
摘要
本文提供了构建和维护AI系统评估集的指导,强调了根据观察到的失败和可行见解选择正确指标的重要性。
查看缓存全文
缓存时间: 2026/08/19 12:44
在撰写优质的评估之前,你必须先选择正确的评估对象。主要要点如下:
- 指标来源于你在追踪记录中发现的失败案例
- 保持评估集小而可维护
- 只保留那些确实会根据其变化采取行动的指标 https://t.co/G2FZjfidrb
如何构建可维护的评估集
“我有追踪记录,该如何设置评估?”这是一个非常常见且重要的问题。本文将引导你选择正确的评估指标。
三类指标
最终,你得到的一组指标将属于以下类别之一:
良好的设置会综合使用这三类。目标指标是你主动提升的,护栏指标捕捉那些一次也不能出现的失败,运营指标则为你提供更多系统洞察。
在保持可见性的前提下,指标越少越好:
- 每个指标都意味着需要运行和维护额外的评估器/数据集
- 当所有事情都重要时,就没有真正重要的了
你的指标集是一个动态文档 你的核心目标会随时间变化。即使你已经设置了评估,定期手动查看一些追踪样本仍然很重要。你会发现评估尚未覆盖的失败模式,或者注意到某些指标随着时间推移变得不那么重要。
候选指标的来源
获得良好指标集的第一步是收集候选指标。这些指标来自两个方面:
1. 观察到的失败
你的大部分指标将来自于你检查追踪记录、发现智能体的行为方式以及你希望它如何改进的过程。有一个结构化的过程将你观察到的内容转化为评估指标,称为错误分析。在大多数情况下,这应该是你决定指标的默认方式:为你发现的错误编写评估器,而不是关注想象中的错误。
2. 目标和硬性约束
有些需求你在智能体实际运行前就知道需要监控。合规规则、安全要求和格式契约从第一天起就需要评估器,即使你从未见过它们被破坏。这些通常是护栏指标。
指标目录适合探索,但需根据你的产品量身定制 现成的评估器库包含诸如幻觉、毒性或有用性等指标,它们衡量的是抽象特质,可能与你的应用出现失败的方式不匹配。
哪些候选指标值得被追踪?
并非所有标准候选都应被追踪。
是一次性修复还是泛化问题?
有时,智能体在某方面失败是因为你未说明你希望它在该方面如何表现。如果一个简单的提示词修改就能解决某种失败模式,那就直接修改并忘掉它。只有当简单的提示词修改无法解决问题,且你需要持续跟踪某种失败模式时,才保留该指标。
可能是一次性修复的例子:
- 输出不是有效的 JSON
- 回复使用了错误的日期格式
- 在纯文本频道使用了 Markdown 格式
- 机器人没有披露自己是 AI 助手
泛化问题的例子:
- 回答是否有检索到的上下文支持
- 是否获取了正确的上下文来回答问题
- 回复是否实际回答了用户的请求
- 智能体是否选择了正确的工具并传递了正确的参数
将每个指标与一个决策挂钩
对于每个候选指标,确定当指标变化时会采取什么行动:阻止部署、回滚提示词、启动调查。如果没有相应的行动变化,该指标就是噪音,不应被追踪。
两个例子:
- 当用户投入或卡住时,对话时长都会上升。因此这个数字因不相关的原因而变动,你无法单独根据它采取行动。这不是一个好的指标。
- 在 OpenAI 的收据处理示例中,商户名称提取有 85% 是错误的,但这些错误结果与系统旨在进行的审计决策并不相关,因此团队停止追踪了它。
注意预算
这个建议在你设置好评估器之后更有助于精简。运行不同的评估器成本不同:
- 代码评估器几乎免费
- 作为评判者的 LLM 评估器运行成本较高,且更难维护(参见编写优质评估器)
如果一个指标不是那么重要且追踪成本高,放弃它可能是明智的决定。
从零开始
在拥有指标集之前,你需要确定智能体的失败模式。这将帮助你推导出指标。
首先,用两个通用分数进行引导:一个自由文本备注,描述发生了什么以及哪里似乎有问题;一个整体通过/失败标记。仅用这两个分数阅读 30 到 50 条追踪记录,将备注聚类为命名的失败类别,然后为每个类别创建一个布尔分数。这个过程被称为错误分析。
保持指标集的活力
指标集描述的是你应用当前的状态。保持其时效性需要养成三个习惯:
- 重大变更后重新进行错误分析。 提示词重写、模型替换和新功能可能会改变失败分布;何时运行它,参见错误分析页面。
- 淘汰那些不再能发现问题的指标。 除了护栏检查,一个持续数月保持 100% 的分数不携带任何信息,你很可能可以丢弃它。
- 审视你正在优化的指标。 古德哈特定律在此适用:当你针对某些指标调整提示词时,可能在某个点上过拟合。定期使用新的人工标注重新验证非常重要。
从何处着手
- 如果还没有,请运行错误分析。
- 记录下产品目标和硬性约束,并将每个目标转化为你可以在追踪记录中观察到的信号。
- 应用筛选器:修复提示词修改就能解决的问题,只保留与决策挂钩的候选指标,并让评判预算成为约束。
- 当你对手头组装的指标集感到满意时,为其实施评估器。关于如何编写优质评估器,请参阅深度解析部分。
这是 Langfuse Academy 的一页内容。探索更多请访问 langfuse.com/academy。
相似文章
人人都说要为AI代理编写评估,但实际该测什么?
一份关于为AI代理编写有效评估的实用指南,重点是从观察到的失败入手,并结合确定性检查和LLM裁判。
@businessbarista: 观点偏激:评测(evals)是阻碍企业成为 AI-native 的头号因素。想搞懂评测,就读这篇……
文章主张评测(evals)是企业成为 AI-native 的最大障碍,并给出了 eval-driven development 的指南:定义好的行为、对 agent 进行测试、将失败案例转化为回归测试,并介绍了 grader、case、run、trace 四个核心概念以及确定性检查、参考答案比对等四种打分方式。
@OpenAI: 我们来聊聊评估。我们一直在寻找更好的方法来衡量和预测模型的进展,尤其是在基准测试...
OpenAI讨论了评估(evals)的重要性,用于衡量和预测模型进展,尤其是在基准测试变得饱和或被操纵的情况下,并邀请了Tejal Patwardhan和Andrew Mayne分享见解。
@suraj_sharma14:作为 AI 评测工程师,你必须完成以下这些项目。 1.)轨迹评分引擎(Trajectory Grading Engine)构建:一个步骤级别的评估器,用于……
# AI Evals 工程师必做的 15 个实战项目 一位从业者梳理了 15 个 AI Evals 工程师必建的项目,涵盖以下方向: 1. 轨迹评分(trajectory grading) 2. 影子路由(shadow routing) 3. 带校准的 LLM-as-a-Judge 4. CI/CD 回归门禁 5. 对抗性 RAG 测试 6. DPO 微调飞轮 7. 统计显著性 8. Agent 红队测试 9. 漂移监控 10. 成本-质量看板 11. 反事实回放调试(counterfactual replay debugging) 12. 合成边缘用例生成 13. 上下文窗口淘汰测试(context-window eviction tests) 14. 数据集污染检查 15. 公开评测方法论拆解(public eval methodology teardowns)
为什么评估初创公司会失败(2025)
本文探讨了为何独立的人工智能评估初创公司很少能成功,原因包括人才流向技术栈中更有利可图的部分、客户群体狭窄,以及优化压力削弱了评估的效用。