Evals 是 evaluations 的简称，中文一般叫「评估」或直接说「评测集」。Anthropic 给过一个很朴素的定义：eval 就是给 AI 系统做的测试——给它一个输入，然后用打分逻辑衡量输出是否达标，重点是那些开发期就能自动跑、不需要真实用户参与的评估。
它要对付的是传统测试对付不了的一类问题：同一段提示词，今天跑和明天跑结果可能不同；换个模型版本、改一行检索逻辑，输出可能悄悄变差，却不会报任何错。
先用一句话抓住它
Evals 是把「AI 输出好不好」变成可复现、可对比的分数，让改动前后能被比较。
生活里的类比是餐厅的出品标准和试菜流程。厨师换了、供应商换了、锅换了，菜看起来还是那道菜，但味道可能已经变了。靠老板偶尔尝一口不靠谱，得有固定的试菜清单和评分表，每次改动后照着跑一遍。Evals 就是 AI 应用的那份清单和评分表。
为什么会出现这个词
典型的失败故事是这样的：团队做了个不错的原型，用十几条手挑的提示词试了试，觉得「看着挺好」就上线了。上线后开始出问题，改一个失败案例又带出另一个，团队陷入反复救火，始终不知道整体质量是变好还是变坏。
2026 年比较普遍的判断是：限制 AI 可靠落地的主要瓶颈不是模型能力，而是评估方法。Anthropic 在自家指南里也把话说得很直白——有评估的团队几天就能完成模型升级，没有评估的团队要花几周做手工验证。
Agent 让这件事更难。单次问答只需要看一个输出，而 Agent 要跑很多轮、调用工具、修改状态、根据中间结果调整策略，「对不对」不只看最后一句话，还要看它中间做了什么。
flowchart LR
Data["评测集<br/>输入 + 期望"] --> Run["被测系统<br/>提示词 / 模型 / 检索"]
Run --> Out["输出与轨迹"]
Out --> Grade["打分<br/>规则 / 模型评判 / 人工"]
Grade --> Score["分数与失败案例"]
Score -->|回归则拦截| CI["CI 门禁"]
Score -->|新失败模式| Data它通常包含什么
一套评估系统一般由三样东西撑起来。第一是评测集，一组带输入和期望的样本，业内常叫 golden dataset；第二是指标，明确这次要衡量什么，是准确率、格式合规、引用是否真实存在，还是工具调用顺序对不对；第三是评判机制，也就是谁来打分。
评判大致分三类。程序化评判是确定性的代码检查：JSON 能不能解析、字段是否齐全、数值是否在范围内、测试是否通过。这类最便宜也最可靠，能用就优先用。模型评判（LLM-as-judge）是让另一个模型按评分标准打分，适合那些没有唯一正确答案的任务，比如摘要质量、语气是否得体。人工评判成本最高，但能捕捉自动方法看不见的细微问题，通常用来抽样校准前两类。
工程上还有一块常被低估：可追溯。一个分数要能对应回是哪个版本的提示词、哪个模型、哪份数据集跑出来的，否则分数下降时你无从查起。
和传统测试的区别
单元测试断言的是确定结果：输入 A 必须输出 B，不等就失败。Evals 面对的输出是概率性的，同一输入两次运行可能都对但措辞不同，所以判定通常不是「等于」，而是「是否满足某些性质」或者「分数是否高于阈值」。
另一个区别是评测集本身会过期。生产环境会不断冒出原来数据集里没有的失败模式，如果不持续把线上真实案例回流成新样本，评测集会慢慢长出盲区，跑满分但线上照样出事。这一点和传统测试很不一样——传统测试写完就一直有效。
和 RAG、Agent、Loop Engineering 的关系
RAG 系统的评估通常要拆成两段看：检索有没有把对的资料找回来，生成有没有忠实使用这些资料。两段分开量，才知道问题出在哪一头。
Agent 的评估要看轨迹而不只看结果：工具选得对不对、有没有绕远路、失败后能不能恢复、有没有做出越权动作。Loop Engineering 那类无人值守的循环更是直接把评估当成刹车——没有自动验收的循环等于批量生成未经检查的产物，所以评估在这类系统里不是加分项，是必需品。
容易误解的地方
第一个误解是「让大模型当裁判就够了」。模型评判有已知偏好，比如偏爱更长的回答、偏爱自己家族的模型输出、对位置顺序敏感。它需要用人工标注抽样校准，也需要写清楚的评分标准，不是丢一句「给这个答案打分」就完事。
第二个误解是追求单一总分。一个总分好看，掩盖不了「格式合规率 99%、但引用真实性只有 60%」这种结构性问题。分维度看比看总分有用得多。
第三个误解是把评测集当成一次性交付。它更像测试套件，需要随着新失败案例持续扩充；同时也要注意，随着模型变强，老评测集会饱和——一年之内 SWE-bench Verified 上的前沿模型成绩就从四成涨到八成以上，半年前还有区分度的题目今天可能人人满分。
第四个误解是被工具选择卡住。市面上的评估平台很多，且大部分评测文章由厂商自己撰写并把自己排在第一位，参考时把定义性内容和排名结论分开看。
怎么判断它该不该用
只要这个 AI 功能会持续迭代，就值得有评估。判断优先级看三件事：改动频率高不高（提示词、模型、检索逻辑经常动就必须有）、出错代价大不大（涉及金额、医疗、法律、对外发布的场景要早做）、以及你现在能不能回答「上周和这周比，质量是升是降」——如果答不上来，那就是该做评估的信号。
起步不必大。先从二三十条真实案例开始，覆盖典型场景和已知的失败模式，配上最便宜的程序化检查；等这套跑起来了，再加模型评判和人工抽检，再考虑接进 CI 做发布门禁。比起一开始就搭一整套平台，先有一个能天天跑的小评测集要有用得多。