smevals 把评测做小，我觉得比搭平台更重要

7 个文件。

一个 eval.yaml，两个任务，两套打分规则，再加一个短短的运行脚本。没有云端控制台，没有花花绿绿的观测大盘，也没有一张需要销售拉群报价的企业套餐表。

这就是 smevals 官方示例里的一套模型评测。

名字也没藏着掖着，small evals，小评测。Simon Willison 和应用 AI 研究实验室 Prime Radiant 在 7 月 31 日把它公开出来，用来比较不同模型、提示词、参数和 Agent 运行脚手架。后面这个词如果你不熟，可以把它理解成让模型真正干活的那层工程，包括工具、上下文、重试和执行环境。

我看到这个目录大小，第一反应不是「又多了一个评测框架」。

而是，好家伙，终于有人认真承认了一件事，多数团队的评测不是做得不够大，而是大到根本没人愿意维护。

我们很容易把评测想成一座大楼。先接日志，再接追踪，再接数据集管理，还要有排行榜、权限、审批和漂亮图表。三周过去，平台有了，真正能阻止线上回归的题，可能还是那十几条手工 prompt。

这事儿有点荒诞。

Simon 的发布文章把 smevals 称为自己在评测方法上的第三次迭代。我觉得这次最值钱的判断，不是它又支持了哪些模型，而是它把评测重新压回了一个普通工程师愿意打开、愿意改、敢放进 Git 的尺寸。

模型选型，早就不只是挑一个名字

前两年做模型对比还相对简单。拿同一批题，把模型 A、B、C 跑一遍，看正确率、延迟和价格，差不多就能做决定。

现在不行了。

同一个模型，系统提示词换一版，工具描述少一句，输出就可能变。上下文压缩策略不一样，长任务做到一半可能突然失忆。Agent 多一次重试，成功率上去了，账单也跟着飘。甚至只是把结构化输出从 JSON 提示改成 schema 约束，结果都可能不是同一档。

你真正部署的，从来不是一个孤零零的模型名。

你部署的是一整套 config，也就是模型、提示词、参数、工具和运行脚手架的组合。

这也是 smevals 的一个好设计。它没有把「GPT-5.5 对 Claude Opus 4.6」当成唯一比较维度。它的 config 可以替换模型，也可以替换 system prompt、模型参数和 agent harness。题目不动，换不同配置去跑，才能看清到底是哪一层让结果变好或变坏。

这比盯公开排行榜有用得多。公开榜单回答的是「这个模型在别人设计的题上大概多强」，你自己的小评测回答的是「它能不能在我的约束里把活干完」。

两者不是一个问题。

Prime Radiant 在完整发布说明里写得很直接，他们想找出适合不同任务类别的小模型和便宜模型。今天便宜模型的选择太多了，开源权重也在快速追赶。如果没有自己的题库，团队很容易陷入一种朴素但昂贵的决策，凡是不确定的任务，都丢给最贵的模型。

厉害了，风险被解决了，预算也被一起解决了。

小评测给了另一种路。你可以单独测 SQL 生成、工单分类、代码补丁、工具选择、引用完整性。哪类任务小模型能稳稳做，就让它做。哪类任务对长上下文或复杂推理敏感，再把请求路由到前沿模型。

模型路由不是拿价格表拍脑袋，它应该从自己的失败样本里长出来。

这张图只对应两道俳句任务，不是通用模型排行榜。它的价值恰好在这里，分数回答的是一个很窄、很具体的问题。

把考试和判卷拆开，是这套工具最聪明的地方

smevals 有意把 run 和 grade 分成两个步骤。

run 是让某个配置执行某道题，并保存原始结果。grade 是拿一套检查规则去判断这次结果过没过。对应到命令行，就是先跑，再判。

uvx smevals run path-to-eval/ -m gpt-5.5 -m claude-opus-4.6
uvx smevals grade path-to-eval/

看着只是两条命令，工程价值却很实在。

模型调用通常是贵的，也可能慢。判卷规则却经常需要改。团队第一次写 grader，也就是评分器时，很难一次写对。条件太松，坏答案混过去。条件太严，一个标点不一样也算失败。更麻烦的是，用另一个大模型当裁判时，裁判还会有自己的偏好和幻觉。

如果运行和打分绑死，每改一次判卷规则，就得把所有模型重新调用一遍。钱花了，时间花了，新旧结果还未必能严格对齐。

拆开之后，原始 run 留在磁盘上，grader 可以反复修改，再对同一批结果重新打分。

uvx smevals grade . --regrade

这一步看着朴素，我是真的觉得它比一个漂亮排行榜重要。因为它把评测从一次性的结果展示，变成了可追溯的判断过程。

分数错了，你可以回看原始输出。判卷标准变了，你可以重算历史结果。团队对「什么叫通过」有争议，也能对着 checker 的代码讨论，而不是盯着一个 87.4 分互相猜。

评测最怕的并不是低分。

是一个没人说得清怎么算出来的高分。

确定性检查先上，模型裁判晚一点再请

官方拿俳句做了一个很小的示例。两道题，一道写鹈鹕，一道写相爱的水獭。第一版 grader 只检查输出是不是恰好三行非空文本。

这当然不够。三行日志也能过。

于是他们又加了一个 checker，用另一个模型检查 5、7、5 的音节结构，以及要求的主题有没有真的出现。每个 checker 都会给出分数、指标和说明，所有检查通过，整道题才通过。

这个例子把 grader 最常见的演进过程摊开了。先用脚本卡住能确定的东西，再用模型判断脚本很难覆盖的语义。

做代码 Agent 也一样。补丁能不能应用、测试能不能跑、有没有改到禁止目录、输出 JSON 是否符合 schema，这些都该交给确定性程序。至于改动有没有满足模糊需求、解释是否清楚、交互是否自然，再考虑让模型裁判参与。

不要反过来。

如果每一项都扔给 LLM-as-judge，也就是大模型裁判，评测会变成两个模型互相看眼色。被测模型写得像模像样，裁判模型点点头，CI 一片绿。真部署后，字段少了一个，工具参数传错，用户拿到一个语气很好的失败结果。

棒棒的，所有模型都很满意，只有生产环境不满意。

模型裁判不是不能用。它适合处理语义质量、风格一致性和开放式任务，但要保留原始输出、裁判说明和评分版本。更稳一点，还可以对关键样本安排人工抽查，记录人和裁判分歧最大的案例，再把这些案例变成新的确定性规则。

题库就是这样长出来的。不是开会想出一百道「全面覆盖」的题，而是线上每撞一块礁石，就把那块礁石画进海图。

能进 Git，评测才有机会变成日常工程

smevals 的 README同时写给人和编程 Agent。你可以让 Agent 先运行下面这条命令读文档，再让它生成一套初始 eval。

uvx smevals docs

工具会把评测放进一个普通目录。YAML 写题目和配置，脚本负责运行与检查，结果跟着目录保存。没有私有数据格式，也不要求先把全部样本上传到某个平台。

一旦它进了 Git，很多熟悉的工程动作就回来了。

谁改了题，diff 里看得见。谁放宽了通过条件，代码评审能拦。某个线上事故补成回归用例，可以和修复补丁放在同一个 PR 里。模型升级后，在 CI 里跑一遍关键小题，失败就不放行。

这才是评测真正该待的位置，离代码、prompt 和配置足够近。

当然，小也有代价。smevals 不会替你自动发明好题，不会保证 grader 公平，也不会把一堆脏兮兮的历史对话自动变成高质量数据集。团队如果没有人愿意读失败样本，再轻的工具也会积灰。

而且它现在更像一把锋利的小刀，不是一间配齐人员的实验室。大型组织需要权限、敏感数据隔离、并发调度、成本归集和审计策略，这些不会凭空消失。我也不觉得一个小 CLI 能把企业评测平台全替掉。

但顺序很重要。

先让十道关键题跑起来，确认每道题都在保护真实业务。再扩到五十道、一百道。等多人协作、调度和合规真的变成痛点，再把平台搭在已经活着的评测上。

别先建一座机场，然后发现根本没有飞机。

如果今天开始，我会守住四件小事

我会从真实失败里挑题，不从能力清单里凑题。工具调用传错参数、引用了不存在的资料、补丁改坏邻近模块，这些都比「请解释某个概念」更接近生产风险。一开始十到二十道足够，前提是每道失败都真的会让团队难受。

我会保存原始产物，不只存一个分数。prompt、模型版本、参数、工具返回、输出和 grader 说明都应该能回看。否则三周后同一个 0.8，可能已经不是同一种 0.8。

我会把 config 当成被测对象。换模型只是其中一种实验，换系统提示词、上下文策略、工具 schema、重试次数同样要测。很多 Agent 退化不是模型变笨了，而是它周围那层脚手架悄悄动了一颗螺丝。

我还会让报告能被人打开。smevals 可以启动本地网页，也能用 smevals build 导出静态 HTML。官方俳句报告就是一个例子。静态报告不花哨，却很好分享。产品、工程、测试可以看到同一批原始结果，不必靠一张截图转述。

评测做到这里，才不再是某位 AI 工程师电脑里的神秘仪式。

回到开头那 7 个文件。

它们小得有点寒酸，却比一张无法复查的大榜单更接近可靠性。因为真正能保护生产环境的，不是某次评测有多隆重，而是下一次模型、prompt 或 Agent 脚手架变化时，那套题还会老老实实再跑一遍。

先把题写小。

然后，让它一直跑。