如何构建一套你能维护的 eval 集

“我已经有 trace 了，该怎么设置 eval？”这是一个很常见的问题，也很重要，必须做对。本文会带你选择真正应该评估的指标。

三类指标

最后，你会得到一组指标，每个指标都属于下面三类之一：

一套好的指标配置会把这三类结合起来使用。目标指标是你主动想要推高的东西，guardrails 用来捕捉那些一次都不能承受的失败，运营指标则让你更了解系统。

在不觉得缺少可见性的前提下，指标越少越好：

你的指标集是一件活的产物
你的北极星会随时间变化。即使你已经设置好了 eval，持续定期手动查看一部分 trace 样本也很重要。你会发现 eval 还没覆盖到的失败，也可能注意到某些指标随着时间推移已经不那么重要了。

想得到一套好的指标，第一步是收集候选指标。这些指标来自两个地方：

1. 观察到的失败

大多数指标会来自你查看 trace、发现 agent 实际如何表现，以及你希望它变成什么样。有一个结构化流程，可以把你看到的问题转化成要评估的指标，叫作错误分析。在大多数情况下，这都应该是你决定指标的默认方式：为你发现的错误编写 evaluator；不要把重点放在想象中的错误上。

2. 目标和硬约束

有些需求，是你在看到 agent 实际运行之前，就知道必须监控的。合规规则、安全要求和格式契约，从第一天起就应该有 evaluator，即使你还从没见过它们被破坏过。这些通常就是 guardrail 指标。

指标目录适合探索，但要按你的产品裁剪
Evaluator 库里那些现成指标，比如幻觉、毒性或有帮助程度，衡量的是抽象质量，可能和你的应用实际出错的方式并不匹配。

不是所有候选标准都应该被跟踪。

一次性修复，还是泛化问题？

有时候，agent 在某件事上失败，只是因为你没有说明希望它在这个方面怎么表现。如果一次简单的 prompt 修改就能解决某个失败模式，那就直接改掉，然后忘了它。只有当简单的 prompt 修改解决不了问题，并且你需要随着时间持续跟踪某个失败模式时，才保留一个指标。

可能属于一次性修复的例子：

泛化问题的例子：

把每个指标都绑定到一个决策

对每个候选指标，都要判断：当这个指标变化时，你会改变什么行动？是阻止部署、回滚 prompt，还是开启调查？如果没有任何行动会改变，那这个指标就是噪声，不应该被跟踪。

两个例子：

对话长度在用户很投入时会上升，在用户被卡住时也会上升，所以这个数字会因为彼此无关的原因变化，你不能只根据它采取行动。这不是一个好指标。
在 OpenAI 的收据处理 walkthrough 里，商户名称抽取有 85% 的时候是错的，但这些错误后来被发现和系统真正要做出的审计决策并不相关，所以团队停止跟踪它。

注意预算

这一点在你已经设置好 evaluator 之后，用来删减指标会更有帮助。有些 evaluator 的运行成本比其他 evaluator 更高：

如果某个指标没那么重要，而跟踪它又很贵，那么删掉它可能是个好决定。

在拥有指标集之前，你需要先找出 agent 的失败模式。这会帮助你推导出指标。

一开始，可以先用两个通用 score 来启动：一条自由文本记录，描述发生了什么、哪里看起来不对；再加一个整体 pass/fail。只用这两个 score 阅读 30 到 50 条 trace，把记录聚类成有名称的失败类别，然后为每个类别创建一个布尔 score。这个过程叫作错误分析。

一套指标集描述的是你的应用在今天的样子。三个习惯可以让它保持最新：

重大变更后重新做错误分析。 Prompt 重写、模型替换和新功能都可能改变失败分布；什么时候该做，错误分析页面里有说明。
退役那些已经不再抓到问题的指标。 除了 guardrail 检查之外，如果某个 score 连续几个月都是 100%，它就不再携带信息，你很可能可以把它删掉。
盯住你正在优化的指标。 Goodhart 定律在这里同样适用：当你围绕某些指标调 prompt 时，某个时候就可能过拟合。重要的是时不时用新的人工标签重新验证。

这是 Langfuse Academy 的一页。你可以在 langfuse.com/academy 探索更多内容。