用大白话讲评测

评测到底是什么。

剥掉术语，一项评测就是三件事的列表，反复跑：

1. 一个输入——一段提示词、一份文档、一句任务描述、一次工具调用请求。
2. 一个预期行为——什么算好的响应：正确的答案、正确的动作、正确的形状。
3. 一条评分规则——你（用代码或用人）如何决定模型产出的东西匹不匹配那个预期。

就这样。一个评测集就是许多这样的三元组，丢到同一个模型（或智能体）跑一遍，结果聚合成一个分数。分数是你的记分牌；集合是你的检测台；整件事，就是用一种你可以反复跑的形式，把"好"对你的任务到底意味着什么写下来。能用代码描述成功，就能写评测。如果根本描述不出来，那你还没有一个被定义清楚的任务——你面对的是另一个问题。

评测之所以管用，跟单元测试管用的理由一样：一个小而可重复、可自动化的信号，胜过一个大而有损、依赖人工的信号。模型变好或变坏，你的记分牌告诉你是哪一种。

为何公开基准不够用。

挑一个在 MMLU 或 LMSYS 竞技场榜首的模型、然后宣布"搞定了"，听起来很顺。但这会因四个相互叠加的原因而失败：

• 它们测的是代理任务。MMLU 测的是各种小知识；竞技场测的是"多数用户更喜欢哪个答案"。两者都不是你的客服分类器、你的合同条款抽取器、或你的代码评审智能体。一个模型可以在代理任务上拿满分，对你仍然不对。
• 饱和。一旦一个基准被攻克，所有前沿模型都打 ~95%，差距全都消失在噪声里。当一组模型对同一道题都答"是"时，你没法靠这个挑出谁。
• 污染。有名的基准会渗进训练数据。高分可能反映的是记忆，而非能力。基准越新、越冷门，信号越干净——而这恰恰是你自己的私有集天然具备的性质。
• 选择偏差。厂商基准表格挑选了提示词、测评框架、对比基线。它适合做一种主张，做不了一次审计。

这不是说公开基准毫无用处——它们很适合选短名单。但一旦决策变成"我到底上哪个模型"，唯一算数的数字就是你自己那套评测集跑出来的。这个论证的完整版本在批判地阅读基准里；此处的结论只一条：别把决策外包给排行榜。

一个有用的评测集长什么样。

第一次造评测集的人最容易犯的错，就是奔着体量去。他们抓 1 万个样例、写一段笼统的 LLM-as-judge 提示词，然后纳闷为什么分数飘得到处都是、什么也告诉不了他们。一个有用的评测集恰好反过来：

• 小。10 到 100 个就够开局。20 个你逐个看过、能讲清楚的样例，能比 2000 个你从没读过的告诉你更多。
• 贴你的任务。从你真实流量里造、从你真实客户里造、从你真实的边界情形里造。通用评测套件只能测出通用的东西。
• 评分要么便宜，要么至少可重复。最好：代码可校验的规则（精确匹配、正则、schema 校验、工具调用断言）。次好：一个评分量表收紧、模型版本钉死的 LLM 评判者。最差但有时也行：人工抽样审查。
• 至少留一个简单样例。一个本该轻松通过的"心跳检查"——如果它都挂了，那是你的测评框架坏了，不是你的模型。
• 至少留一个困难样例。一个你以前修过的已知差例，作为回归目标保留。哪天某次模型发布悄悄把它打回原形，你的记分牌会告诉你。

在线 vs 离线，以及接下来读什么。

有一个区分值得从本篇带走：离线评测跑在一个精心整理的集合上，类似 CI 循环——你控制输入、你知道预期输出、你在上线前跑。在线评测跑在真实生产流量上——你事先并不知道正确答案，所以你测代理指标（解决率、用户点赞、下游转化、被覆盖率）。两者你都需要。离线评测在上线前接住回归；在线评测告诉你系统对用户是否真的有效。它们彼此不替代。

"为何评估智能体特别难"的深入版本——非确定性、多步误差复合、没有单一标准答案、路径依赖、评测成本、数据集腐烂——在 Operations · 为什么评估智能体很难。把评测集编进开发循环的实务（CI 关卡、黄金轨迹、生产到评测的飞轮）在评估驱动的智能体开发。按这个顺序读。