目录

你打磨了提示词，用 RAG 补充了知识，或许还做了微调——那么如何确认它「真的变好了」呢？这正是 AI evals（评估）登场的地方。到了 2026 年，评估对于构建 AI 已经不可或缺，人们甚至称它为「基础设施」。

本文面向初学者，梳理什么是 AI evals、为什么需要它、评估的两种方法、备受讨论的「LLM-as-judge」如何运作及其陷阱，以及如何在实践中落地。

AI EVALS · 能衡量才能改进

用代码衡量，用 AI 评判品味

——把「好像还不错」变成一个数字

📏

定义标准

把「好的输出」变成一把具体的尺子。

⚙️

自动打分

用代码或 AI，每次都一致地评分。

📈

追踪变化

持续观察什么变好了、什么变差了。

1. 什么是 AI evals（评估）？

AI evals 就是系统化地衡量 LLM 输出的质量。「这个回答准确吗？」「有没有幻觉（编造的事实）？」「是否遵循了要求的格式？」「语气是否得当？」——你用一把固定的尺子来打分，而不是当下凭感觉来判断。

可以想象成「批改试卷」。你给学生（AI）出一道题（输入），再对照标准答案或评分量规（rubric）打分。一旦能打分，你才终于能看清「哪个改动让它变好了、哪个让它变差了」。没有评估，改进就只是一种直觉。

💡 一句话：evals = 「为 AI 输出打分的系统」。提示词的调整与微调，只有当你有了衡量它们的尺子时才有意义。

2. 为什么需要它：不要凭感觉上线

普通程序是固定的——「输入 A 总会得到输出 B」——但 AI 即使是相同输入也会变化（具有非确定性），而且「好或坏」往往是主观的。所以「我试了几个看起来不错，那就上线吧」是有风险的。你恰好看到的那几个，可能只是运气好。

把评估系统化，能让你做到以下几点：

  • 用数字来判断改动：更换提示词或模型时，用分数来比较
  • 捕捉回归：看一项「改进」是否破坏了别的东西
  • 监控生产质量：在运营中察觉 AI 性能何时下滑

这与规格驱动开发很搭。先确定「要构建什么」（规格），再「衡量是否构建到位」（评估）——两者齐备，AI 开发才终于变成可以管理的事情。

3. 两种方法：代码评估 vs LLM-as-judge

评估大致有两种方式。能机械衡量的用代码量，主观的交给 AI 来评判——这种分工就是基本原则。

代码评估（确定性）

按规则机械判断

  • 完全匹配、必需的格式（JSON 等）
  • 包含必需词 / 避免禁用词
  • 快、便宜，每次结果都一样
  • 最适合有明确正确答案的项目
LLM-AS-JUDGE（模型评分）

让 AI 给 AI 打分

  • 幻觉、相关性、有用性、语气
  • 没有唯一正确答案的主观项目
  • 比人工更快更便宜，且可规模化
  • 但要小心它的怪癖（偏见）

经验法则是：「能用代码衡量的，就别让 AI 来打分。」代码评估更快、更便宜、更稳定。把 LLM-as-judge 留给代码难以判断的主观项目，比如是否存在幻觉。

4. LLM-as-judge 的工作原理

LLM-as-judge 指的是用一个强大的 LLM 当「裁判」，给另一个 AI 的输出打分。你给裁判 LLM 一个包含评判标准、输入和输出的提示词，它就会返回一个分数、一个 pass/fail（通过/不通过），或者「哪个更好」。主要有两种风格。

成对比较（pairwise）

把两个回答并排放在一起，问「哪个更好？」AI 擅长判断哪个相对更强。非常适合 A/B 比较。

单输出评分

对照评分量规给单个回答打一个分数。适合长期追踪绝对质量。

⚠️ 粗粒度评分更准确：AI 不擅长 1–10 这样细粒度的打分，会摇摆不定。像「pass/fail」或「1–3」这样的粗粒度刻度，反而能得到更稳定的结果。

5. 陷阱：裁判模型的偏见

LLM-as-judge 有它的「裁判怪癖」。不了解这些，你就会过于信任分数，从而做出错误的改进。记住下面这三大偏见。

① 冗长偏见

倾向于给更长、更复杂的回答打更高的分——即便内容空洞，也会因篇幅长而占便宜。

② 位置偏见

你列出回答的顺序（例如排在第一个的那个）会带来优势或劣势。

③ 自我偏好

倾向于给自己（同一系列模型）写出的回答打更高的分。

应对方法很简单。

  • 用不同的模型当评分者：不要用 GPT 给 GPT 的输出打分。让不同系列的模型——Claude、Gemini 等——来当裁判，以避免自我偏好。
  • 交换顺序后打两次分：两次一致就保留结果，冲突就丢弃（控制位置偏见）。
  • 把「简洁性」写进评分量规：只说「别按长度评判」是不够的。加入一条简洁性标准，并指示裁判对冗长进行扣分。
  • 用人工判断来校准：让人对一小批样本打分，调整标准使其与 AI 的分数对齐。这是最有效的一步。

6. 实践中：把评估当作「基础设施」

在 2026 年的实践里，评估不是一次性的——标准做法是跨三个层级持续运行（「评估即基础设施」）。

① 每次改动即时检查

在每次代码改动时（CI）自动运行轻量的代码评估。即时拦下明显的故障。

② 每晚回归测试

夜间用 LLM-as-judge 批量评估质量。捕捉缓慢、悄然蔓延的退化。

③ 持续监控生产环境

观察线上输出，质量下降时告警。把对真实用户的影响降到最低。

工具也成熟了。轻量的 CI 运行可用 DeepEval（用起来像 pytest）或 Promptfoo；专门针对 RAG 则用 RAGAS（衡量忠实度、相关性等）。人工审核、仪表盘和生产监控，则可用 Braintrust、LangSmith、Arize 这类平台。实践中，把「一个轻量 CI 工具」和「一个监控平台」搭配使用是常态。同样的评估机制也支撑着构建 AI 智能体的质量。

※ 工具名称与方法引自各类指南和公开披露（截至 2026 年 6 月）。最佳配置因团队规模和使用场景而异。

总结

关于 AI evals 的三个要点。

  • 是什么：一个为 LLM 输出打分的系统，把改进从「直觉」变成「数字」。是 AI 开发中不可或缺的一步。
  • 两种方法：确定性项目用代码评估，主观项目用 LLM-as-judge。凡是代码能衡量的，就用代码衡量。
  • 要注意：LLM-as-judge 有冗长、位置和自我偏好三种偏见。用不同的评分者模型、粗粒度刻度和人工校准来应对它们。

先从自己的 AI 中各收集 10 个「好输出」和「坏输出」，按简单的标准给它们打分。这就成了你的第一把尺子。把微调和上下文工程一起读，能补全改进 AI 的完整图景。

FAQ

Q. 让 AI 给 AI 打分，真的靠得住吗？

A. 不能盲目相信。由于存在冗长、位置和自我偏好等偏见，重要的是用不同系列的模型来打分，并用一小批人工评判的样本来校准。一旦校准好，它就能以接近人工的准确度规模化运行。

Q. 评估需要多少个示例？

A. 只用几十个就能很好地起步。诀窍是收集真实的好例子和坏例子，先搭建一个小的评估集。与其追求完美，不如边做边扩充标准——这样更务实。

Q. 代码评估还是 LLM-as-judge——我该用哪个？

A. 都用。格式、必需词这类可机械衡量的用代码评估；幻觉、语气这类主观的用 LLM-as-judge。能确定性衡量的东西，没必要让 AI 来打分。

Q. 独立开发者需要评估吗？

A. 无论规模大小都有帮助。哪怕只有一个小小的「好输出的标准」，也能让你判断一次提示词或模型的改动是改进还是回归。哪怕只是手动给少量样本打分，也是个有用的开始。