Lotte (@lotte_verheyden)
2026-08-19
D
原文
---
title: "如何构建一套你能维护的 eval 集"
author: "Lotte (@lotte_verheyden)"
source_url: "https://x.com/lotte_verheyden/status/2089838277729890437"
published_at: "2026-08-18T22:14:07.000Z"
fetched_at: "2026-08-19T15:31:53Z"
updated_at: "2026-08-19T15:33:26Z"
language: "zh"
review_status: "draft"
---
# 如何构建一套你能维护的 eval 集
“我已经有 trace 了，该怎么设置 eval？”这是一个很常见的问题，也很重要，必须做对。本文会带你选择真正应该评估的指标。
## 三类指标
最后，你会得到一组指标，每个指标都属于下面三类之一：
| 角色 | 它回答的问题 | 常见来源 |
| --- | --- | --- |
| 目标指标 | 我们正在构建的东西，质量有没有变好？ | 错误分析、产品目标 |
| Guardrails | 有没有在绝不能坏掉的地方退化？ | 需求、合规、过往事故 |
| 运营指标 | 成本是多少，每小时能处理多少请求？ | trace，基本免费 |
一套好的指标配置会把这三类结合起来使用。目标指标是你主动想要推高的东西，guardrails 用来捕捉那些一次都不能承受的失败，运营指标则让你更了解系统。
**在不觉得缺少可见性的前提下，指标越少越好：**
- 每个指标都意味着又多一个需要运行和维护的 evaluator / 数据集
- 当所有东西都重要时，就没有东西真正重要
> ***你的指标集是一件活的产物***\
> *你的北极星会随时间变化。即使你已经设置好了 eval，持续定期手动查看一部分 trace 样本也很重要。你会发现 eval 还没覆盖到的失败，也可能注意到某些指标随着时间推移已经不那么重要了。*
## 候选指标从哪里来
想得到一套好的指标，第一步是收集候选指标。这些指标来自两个地方：
**1. 观察到的失败**
大多数指标会来自你查看 trace、发现 agent 实际如何表现，以及你希望它变成什么样。有一个结构化流程，可以把你看到的问题转化成要评估的指标，叫作[错误分析](https://langfuse.com/academy/monitoring/error-analysis)。在大多数情况下，这都应该是你决定指标的默认方式：**为你发现的错误编写 evaluator；不要把重点放在想象中的错误上**。
**2. 目标和硬约束**
有些需求，是你在看到 agent 实际运行之前，就知道必须监控的。合规规则、安全要求和格式契约，从第一天起就应该有 evaluator，即使你还从没见过它们被破坏过。这些通常就是 guardrail 指标。
> ***指标目录适合探索，但要按你的产品裁剪***\
> *Evaluator 库里那些现成指标，比如幻觉、毒性或有帮助程度，衡量的是抽象质量，可能和你的应用实际出错的方式并不匹配。*
## 哪些候选项值得成为指标？
不是所有候选标准都应该被跟踪。
**一次性修复，还是泛化问题？**
有时候，agent 在某件事上失败，只是因为你没有说明希望它在这个方面怎么表现。如果一次简单的 prompt 修改就能解决某个失败模式，那就直接改掉，然后忘了它。只有当简单的 prompt 修改解决不了问题，并且你需要随着时间持续跟踪某个失败模式时，才保留一个指标。
可能属于一次性修复的例子：
- 输出不是合法 JSON
- 回复用了错误的日期格式
- 回复在纯文本渠道里使用了 markdown
- bot 没有说明自己是 AI assistant
泛化问题的例子：
- 回答是否有检索到的上下文支撑
- 是否抓取了回答问题所需的正确上下文
- 回复是否真正回答了用户的请求
- agent 是否选对了工具，并传入了正确参数
**把每个指标都绑定到一个决策**
对每个候选指标，都要判断：当这个指标变化时，你会改变什么行动？是阻止部署、回滚 prompt，还是开启调查？如果没有任何行动会改变，那这个指标就是噪声，不应该被跟踪。
两个例子：
- 对话长度在用户很投入时会上升，在用户被卡住时也会上升，所以这个数字会因为彼此无关的原因变化，你不能只根据它采取行动。这不是一个好指标。
- 在 [OpenAI 的收据处理 walkthrough](https://developers.openai.com/cookbook/examples/partners/eval_driven_system_design/receipt_inspection) 里，商户名称抽取有 85% 的时候是错的，但这些错误后来被发现和系统真正要做出的审计决策并不相关，所以团队停止跟踪它。
**注意预算**
这一点在你已经设置好 evaluator 之后，用来删减指标会更有帮助。有些 evaluator 的运行成本比其他 evaluator 更高：
- 代码 evaluator 几乎是免费的
- LLM-as-a-judge evaluator 运行起来要花钱，也更难维护（见[编写好的 evaluator](https://langfuse.com/academy/evaluate/writing-evaluators)）
如果某个指标没那么重要，而跟踪它又很贵，那么删掉它可能是个好决定。
## 从零开始
在拥有指标集之前，你需要先找出 agent 的失败模式。这会帮助你推导出指标。
一开始，可以先用两个通用 [score](https://langfuse.com/docs/evaluation/scores/overview) 来启动：一条自由文本记录，描述发生了什么、哪里看起来不对；再加一个整体 pass/fail。只用这两个 score 阅读 30 到 50 条 trace，把记录聚类成有名称的失败类别，然后为每个类别创建一个布尔 score。这个过程叫作[错误分析](https://langfuse.com/academy/monitoring/error-analysis)。
## 让指标集保持活着
一套指标集描述的是你的应用在今天的样子。三个习惯可以让它保持最新：
- **重大变更后重新做错误分析。** Prompt 重写、模型替换和新功能都可能改变失败分布；[什么时候该做](https://langfuse.com/academy/monitoring/error-analysis#when-to-run-it)，错误分析页面里有说明。
- **退役那些已经不再抓到问题的指标。** 除了 guardrail 检查之外，如果某个 score 连续几个月都是 100%，它就不再携带信息，你很可能可以把它删掉。
- **盯住你正在优化的指标。** [Goodhart 定律在这里同样适用](https://arxiv.org/abs/1803.04585)：当你围绕某些指标调 prompt 时，某个时候就可能过拟合。重要的是时不时用新的人工标签[重新验证](https://langfuse.com/guides/llm-as-a-judge-calibration-skill)。
##
## 从哪里开始
1. 如果还没有做过，[先做错误分析](https://langfuse.com/academy/monitoring/error-analysis)。
2. 写下产品目标和硬约束，并把每个目标转化成你能在 trace 中观察到的信号。
3. 应用过滤器：prompt 修改能修掉的就修掉；只保留能绑定到决策的候选项；用 judge 预算约束指标数量。
4. 当你对组装出的这套指标满意后，再为它实现 evaluator。关于如何做，可以看[编写好的 evaluator](https://langfuse.com/academy/evaluate/writing-evaluators)这篇深入讲解。
---
*这是 Langfuse Academy 的一页。你可以在 [langfuse.com/academy](https://langfuse.com/academy) 探索更多内容。*