跳到主要内容

评估你的 Claude Agent(Evals)

高级

你调整了一个提示词,感觉更好了——但真的更好吗?没有评估(evals),你就是在盲飞:每一次改动都像抛硬币,而你往往是从愤怒的用户那里、而不是从测试中得知它出了问题。评估把"感觉"变成一个你可以信任、可以辩护、可以长期跟踪的数字。这是区分业余提示词与生产级 Claude 工作的最重要的一件事。

What you'll learn
  • 为什么"我看着不错"不是测试——以及应该测量什么
  • 从真实的失败(自下而上)构建黄金数据集,而不是凭想象编造
  • 能用代码评分的地方就用代码,不能的地方就用 LLM 作评委(LLM-as-judge)
  • 把评估接入 CI,让提示词或模型的改动永远无法悄无声息地回归

心态:测量,别猜

三条能救你的规则:

  • 自下而上胜过自上而下。 先收集真实的失败,再设计指标去捕捉它们。从真实故障构建的评估能预测真实故障;在白板上凭空发明的评估,大多只是测量你的想象力。
  • 一个可以重跑的数字。 评估是可重复的:相同输入 → 可比较的分数。这正是让你诚实地比较提示词 v1 与 v2,或 claude-haiku-4-5claude-sonnet-4-6 的关键。
  • 跑起来便宜,就经常跑。 如果要花人一个下午,它就不会被执行。把它自动化。

构建黄金数据集(自下而上)

你的黄金数据集是每个评估的核心——一组精心挑选、带有已知良好预期的输入。

Guided walkthrough1 of 4
  1. 从真实的糟糕输出入手:生产环境的调用轨迹、bug 报告、支持工单。这些才是真正重要的案例。

评分:先代码,后评委

优先选用最便宜可靠的检查方式。

  • 程序化(确定性)检查——只要答案有结构,就在任何地方使用它:精确/关键词匹配、"对照此 schema 是否为合法 JSON"、"是否用正确的参数调用了正确的工具"、"是否低于 N 个 token / 低于 X 毫秒"。快速、免费,而且永不抖动。
  • LLM 作评委(LLM-as-judge)——用于代码难以判断的模糊维度(有用性、语气、对来源的忠实度)。给评委一份评分细则(rubric),而不是一种感觉,并且在信任它之前用人工标注来校准它

:::warning 评委有偏见 LLM 评委会偏向更长的答案(冗长偏见),也会偏向最先展示的那个选项(位置偏见)。防御手段:严格的评分细则、用成对比较代替绝对打分、交换答案顺序,以及用人工标注的切片重新核对评委。评委只是一层防线,不是测试的全部。 :::

LLM 作评委评分细则(入门版)

You are a strict grader. You are given a QUESTION, a REFERENCE answer, and a MODEL answer.
Score the MODEL answer from 1-5 on (a) faithfulness to the reference and (b) helpfulness.
Output ONLY JSON, nothing else: {"score": <1-5>, "reason": "<one short sentence>"}

QUESTION: {{question}}
REFERENCE: {{reference}}
MODEL: {{model_answer}}

对于 agent,还要测试轨迹

agent 可能以错误的方式得到了正确的最终答案——陷入循环、调用了破坏性工具,或烧光了你的预算。所以要评估路径,而不只是终点:它是否调用了正确的工具,顺序合理,没有循环,且在预算之内? 工具调用正确性与轨迹检查能抓住只看最终答案的评估永远看不到的失败。

把它接入 CI

这正是评估收益兑现的地方:让回归无法被合并。

Guided walkthrough1 of 3
  1. 能用程序化方式评分的就用程序化;其余的交给评委。
评估术语表
Term shown.
1 / 4

自我检查

0/3
  1. 评估评分的最可靠首选是什么?
  2. 黄金数据集的案例大多应该来自哪里?
  3. 对于 AGENT,除了最终答案你还应该评估什么?
Key takeaways
  • 没有评估 = 凭感觉发布。在信任一个提示词或 agent 之前,先构建一个评估。
  • 黄金数据集来自真实的失败;每周用新的回归扩充它。
  • 先用基于代码的检查;模糊的部分交给 LLM 作评委(配合评分细则并校准)。
  • 对于 agent,给轨迹打分,而不只是输出。
  • 在 CI 中运行它,分数下降就让构建失败——这正是质量停止回归的方式。

来源与延伸阅读

下一步