地图:七组共 24 个概念

一张地铁线路图:先看清整条线路,再一站一站地坐过去。

先是三个基础——评测是什么、为什么凭感觉调参行不通、为什么最后那 15% 的质量是大部分的活儿。然后是六组,每章一组:该测什么、评测集、如何打分、agent、离线与在线,以及把它做好。

后面的每个概念都是同一个样子:它的英文名(记住它——这就是术语)、一幅现实生活里的画面、一张图,以及一张带字段的卡片:问题、思路、例子、代价、何时使用和关联。

Eval——给「猜测者」的测试

给一篇作文评分,不像核对一道加法题——没有唯一正确的字符串可以去对照,而且同一个提示词每次产出的作文都略有不同。

普通测试断言的是 output === expected。LLM 是非确定性且开放式的:同一个提示词给出变化的文本,而「正确」往往是一种质量,不是某个精确的字符串。所以断言这套模型就失效了。**评测(eval)**取而代之:一组输入,每个都配有一种方法去评分输出有多好,反复运行——为一个「不会两次返回同样东西」的组件而生的测试。

Tuning by Vibes——凭感觉调参的陷阱

一个从不尝菜、只是反复改配方然后碰运气的厨师——他根本分不清昨晚的改动是帮了忙,还是悄悄毁了这道菜。

没有评测,你就凭感觉调提示词:试点什么,瞄一眼几条输出,觉得更好了就发布。陷阱在于你看不见回退——一个修好了某个用例的改动,常常会弄坏你没回头去查的另外三个。评测把「感觉更好了」变成「打了 84 分对 79 分」,这就是工程与猜测之间的区别。

The Last Mile——80% 很快,95% 才是整个项目

任何东西的初稿都出得很快。把一份粗糙的草稿变成可靠的东西,时间才真正花在这里。

评测要处理的就是这条残酷的事实:一个80% 情况下正确的 demo 一个下午就能做出来;从那里一路磨到 95%,才是大部分的活儿。最后这一段,即最后一英里(last mile),要一个用例一个用例地找——边缘输入、罕见失败——而且只有你在度量时,才能找到并修好它们。评测就是让这段漫长攀登变得可见的仪器。

评测是你的回退防护网,也是你的规格说明

安全绳让攀岩者敢于尝试难度大的动作,因为失手不会致命——它让大胆的改动变得安全。

一旦有了评测,你就可以改提示词、换模型或重构流水线,并且立刻看出是帮了忙还是添了乱。它在用户之前抓住回退,还悄悄成为你这个功能「好是什么样」的真正规格说明。没有它,每次改动都是一场赌博;有了它,改进就成了一个你真能跑起来的循环。

Eval Criteria——把「好」变成具体的检查

驾照考试不会问「你是个好司机吗?」——它给具体的事项打分:打转向灯了吗、保持在车道里了吗、完全停稳了吗、停进线内了吗。

「质量」太含糊,没法优化。把它拆成可度量的属性——评测标准(eval criteria):答案对不对、是否有来源依据、格式是否有效、是否调用了正确的工具、长度和语气是否合适?每一项都是你能打分的东西。关键功夫在于:挑出对你的任务真正重要的那几项,而不是什么都去测。

Task-specific Metrics——让指标与任务相匹配

评价译者看忠实与流畅,评价收银员看速度与准确——量尺用错了,评价就没用。

不同的功能需要不同的指标。RAG 系统:检索到的片段对不对,答案是否忠实于它们?分类器:对照标签的准确率。agent:选对工具了吗,达成目标了吗?摘要:忠实、完整、简洁。挑那些对应你的任务里「失败究竟意味着什么」的指标,否则你优化的就是一个不重要的数字。

Faithfulness vs Correctness——两件不同的事

学生可以写出论证漂亮但错误的答案,也可以写出笨拙但正确的答案。文采和真相是分开的两项分数。

最重要的两个属性常被混为一谈。**正确性(correctness)**是答案究竟对不对;**忠实性(faithfulness)**是它是否有所给上下文的支持、没有凭空编造。一个有依据的系统可以是忠实的(用了来源)却是错的(来源本身就错了),也可以是正确的却不忠实(蒙对了,而不是出自上下文)。把二者分开度量,才能告诉你失败出在哪里。

Slicing——一个数字隐藏得太多

「舒适」的平均气温,可能掩盖了一间冻人的屋子和一间闷热的屋子。汇总会抹掉你最需要看到的那些情况。

单一的总分是起点,不是全貌。把结果拆开——切片(slicing)——按类别和难度:简单与困难、每种问题类型、每种失败模式——因为一个平平的 85% 可能是简单用例 100%、关键用例 40%。评测的价值在于这种拆解,它告诉你下一步该瞄准哪里。

Golden Set——带有已知为好结果的输入

老师的标准答案——题目与「正确回答是什么样」配成对,这样评分才一致,而不是看心情。

评测的核心是 golden set:一批有代表性的输入,每个都配有已知为好的答案,或对成功的清晰定义。你就是对着它打分。建它是实打实的活儿——正是在这里你才确定「正确」对你的功能究竟意味着什么——它也是让今后每次改动都可度量的资产。

Hard Cases——覆盖边缘和已知的失败

桥梁要用最重的卡车和最糟的风暴来做压力测试,而不只是晴天里的一辆普通轿车。

只有简单、典型输入的集合,会给你一个好看却没用的分数。要刻意放进困难用例(hard cases):含糊的问题、边缘用例、对抗性提示词,尤其是你已经见过的那些失败。每当有 bug 进了生产环境,就把它作为**回归用例(regression case)**加进评测,让它永远不能悄悄回来。集合应当集中在系统最可能出问题的地方。

Production Sampling——采集真实样例

最好的考题来自学生真正考过的那场考试,而不是老师想象他们会问什么。

评测用例最丰富的来源是真实使用:用户实际问了什么,尤其是问了却出了错的。从日志和反馈里挖出真实输入,并入集合。凭空编的样例反映的是你以为会发生什么;生产里的样例反映的是真正发生了什么,包括你绝对想不到的那些凌乱措辞和古怪请求。

小而锋利,胜过大而陈旧

五十个精心挑选、直戳真实弱点的问题,比一千个你从不细看的随机问题教给你的更多。

起步不需要成千上万个用例——几十个精心挑选的,覆盖主要行为和已知的失败模式,就足以抓住大部分回退并指导调参。从小处开始,保持诚实,随着你了解系统在哪里出问题再让它长大。一个你真会去跑的评测,胜过一个庞大却不去跑的。

Code-based Graders——精确的、基于规则的检查

批改选择题不需要判断力——答案要么对要么错,机器瞬间就能打分。

当输出受到约束时,用代码做确定性的打分——基于代码的 grader(code-based grader):分类用精确匹配,格式用正则或 schema 检查,agent 看是否调用了正确的工具,抽取看数字是否正确。这些检查便宜、快速、无可争辩。要尽可能多地把你的评测放进这一类——它是最可靠的打分方式。

LLM-as-Judge——让模型给模糊的东西打分

一篇作文请来第二位考官,拿着清晰的评分细则——是判断,但有明确标准做引导,所以是一致的。

对开放式输出——这个摘要忠实吗?这个回答有用吗?——没有精确匹配可用,所以你用一个模型来打分,即 LLM-as-judge:把输出、上下文和一份清晰的**评分细则(rubric)**交给第二个模型,让它打分。它能把接近人的判断扩展到成千上万个用例。对于你没法用规则检查的质量,它是标准工具——但也有需要注意的地方。

Judge Validation——judge 也得被评判

第二位裁判也可能有偏见——偏爱更长的答案,或听起来更自信的那个——所以你在信任他之前,先拿几个人工判定来检验这位裁判。

LLM judge 有它的失败模式:它可能偏好冗长的答案(verbosity bias),被自信的语气左右,或偏离你的本意。所以要在一个样本上对照人工打分来验证 judge,给它一份带例子的锐利细则,并保持简单。一个你没检验过的 judge,不过是又一个没被度量的模型——在确认它的分数确实跟着你真正在乎的东西走之前,别信它。

Human Review——人在回路,小剂量

即便有自动打分,厨师依然要尝尝菜——快速抽查一下仪器有没有悄悄出错。

自动打分能规模化,但要定期**亲自去读真实的输出——人工复核(human review)。**抽查一个样本,重点看那些失败,并核对你的指标是否仍然反映真实的质量。人工复核没法覆盖每个用例,但小而定期的一剂,能抓住你的自动分数漏掉的东西——并避免你去优化一个已经偏离现实的数字。

干净的最终答案,可能藏着一个坏掉的中间

只按最终数字评分的数学考试,会让那个靠两个相互抵消的错误得到结果的学生过关——你对到底发生了什么一无所知。

在多步骤的 agent 里,中间的错误可以通过最终输出的检查,同时却污染了整个过程——它检索到了正确的来源,中途把一个事实张冠李戴,然后写出一份干净却是错的摘要。只给最终答案打分,你就把它放行了。你最需要抓住的那些失败,恰恰是只看终点的检查最看不见的。

Trajectory Evaluation——给路径打分

驾考官会看整段驾驶——每次打灯、每次看后视镜、每次变道——而不只是看你有没有到达那个地址。

对 agent 你要评估它的轨迹(trajectory):每一步,它是否选对了工具、传对了参数、检索到了正确的上下文、推理是否站得住?这能抓住只看最终结果漏掉的坏中间,还能告诉你是哪一步出了问题——比只知道结尾错了要有用得多。agent 的可靠性,正是在这些步骤里建成或丢掉的。

Step-level Checks——直接检查工具调用和检索

审计一位研究助理,就是检查他实际调取了哪些来源、发出了哪些调用——而不只是读他最后的备忘录。

agent 的很多行为是具体的,不用判断就能打分:该调用 send_email 时它调用了吗,收件人对吗?它检索到相关文档了吗?它是否守在自己的工具权限之内?这些就是对步骤的确定性检查——步骤级检查(step-level checks),廉价而精确,能精确定位很大一部分 agent 的失败。

Operational Metrics——也要度量那些乏味的真相

评价一家快递,不只看包裹到没到,还要看用了多久、试了几次、花了多少钱。

除了正确性,还要追踪 agent 的运行指标(operational metrics):它走了多少步、多频繁地陷入循环或重试、延迟(latency),以及每个任务的成本。一个循环用二十个昂贵的步骤得出正确答案,而三步就够了,这是一个可靠性与成本的问题,你的最终答案分数是显示不出来的。这些数字揭示出那些能跑、却撑不过生产环境的 agent。

Offline Eval——发布之前的闸门

一条试车道,让一辆车在载上第一位乘客之前先经受考验——受控、可重复、在发布前运行。

**离线评测(offline eval)**就是在改动发布之前,拿你的 golden set 去跑:这个新提示词或新模型,在你精心挑选的那些用例上得分更高吗?它受控且可重复,是你抓回退、安全地比较各种方案的地方。这是你要接进开发循环的评测——最好做成 CI 里的闸门,这样任何让分数下降的东西都发布不出去。

Online Eval——度量真实世界

不管试车道多好,车上了真实的路,你仍然要监控——因为真实的路上有试车道从没有过的坑洼。

生产环境的表现,没有哪个离线集合能完全预测:真实用户的措辞你想象不到,输入分布也会漂移。所以你也要在线度量——在线评测(online eval):对线上输出抽样并打分,盯着质量指标,收集用户信号。离线集合证明一个改动可以安全发布;在线度量则告诉你,它上线之后实际在发生什么。

User Feedback——免费的评测信号

一个点赞按钮和一个投诉邮箱,就是一份持续、免费的调查,告诉你这东西对使用它的人是否真的管用。

不管你收不收集,你的用户都在给你打分。把用户反馈信号(user feedback signals)——点赞/点踩、修改、重试、放弃、转人工——抓起来并喂回去。重试或点踩的突增是早期预警;那些具体的失败,会成为明天的评测用例。这就闭合了循环:生产环境教会评测集现实是什么样,评测集又保护下一次发布。

Drift——盯住缓慢的衰退

一台秤慢慢偏离校准——没有什么戏剧性,只是每次读数都多错一点,直到某天数字就错了。

一个曾经得分很高的系统,会悄无声息地退化——这就是 drift:模型提供方更新了,你的数据变了,使用模式变了。没有持续的在线度量,你是从愤怒的用户而不是从仪表盘那里得知的。随时间追踪质量,让 drift 显现为一个你能采取行动的趋势,而不是一个意外。评测不是一次性的闸门;它是你要持续读取的生命体征。

Eval-driven Development——先写评测,再调参

你得先校准温度计,再去调烤箱——否则每次调整都是披着进步外衣的猜测。

常见的错误是无休止地调提示词,到后来也许才去建评测。把它倒过来:在优化之前先写一个小评测,让每次改动从一开始就被度量——这就是 eval-driven development。哪怕十个用例也胜过零个。没有评测的调参感觉很有成效,其实多半没有——你在挪动你看不见的数字。

CI Gate——把评测做成 CI 里的闸门

测试不通过,代码就不能合并——同样的纪律,也能防止一个悄悄变差的提示词到达用户手里。

有了评测,就在每次改动时自动运行它,分数跌破门槛就拦住发布——这就是 CI gate。它把评测从「想起来才做的事」变成一道始终开着的护栏——AI 版的「测试套件全绿」。「没有评测就不发布」是值得坚持的标准:对 AI 功能做一个没被度量的改动,就是一次没测过的部署。

Goodhart's Law——别让指标变成目标

只为考试而教,会教出考试拿高分却干不了活的学生——分数上去了,它所衡量的东西却没有。

当一个度量变成目标,它就不再是一个好的度量——这就是古德哈特定律(Goodhart's law)。你可能把提示词对你那些具体的评测用例过拟合(overfit),眼看着分数上升而真实质量原地不动。要防范:留出一部分用例不参与调参(held out),用新的生产失败刷新集合,并记住评测只是用户价值的一个代理,而不是价值本身。一个在涨、而用户却没有感觉的数字,是个警告,不是胜利。

从小处开始,随失败而成长

好的测试套件不是一次写成的——它是积累出来的,一个 bug 一个用例,直到悄悄覆盖了所有出过错的地方。

别等一个完美、全面的评测——那样你永远发布不了。先为核心行为准备一把用例,然后**每次有东西坏了就加一个。**久而久之,集合恰好沿着你的系统真正出错的轮廓长大,而这正是你想要覆盖的地方。评测随产品一起成熟,它永远不算真正完成。

这些概念如何连在一起

一只不断转动的轮子:每转一圈,集合就更诚实,发布就更安全。

这门课里的一切都属于同一个循环。criteria 说明测什么;golden set 说明拿什么来测;grader(代码、judge、人)给出分数。带 CI gate 的离线评测把守发布,在线评测盯着现实——反馈和 drift——它发现的失败变成新用例,回到集合里。对 agent,你给轨迹打分,而 Goodhart 定律提醒你:分数只是个代理。