评估 — Copilot 写下的第一段代码
这一章讲三件事: 为什么评估框架该是项目的第一段代码; offline(离线,拿例子测)到 online(在线,拿真人测)这两级台阶各自怎么搭; 以及「让 LLM 评 LLM」这个听起来像作弊的做法在什么条件下成立。 主走查是一间智能家居:「I'm chilly」这句话将贯穿样本、判卷与打分全流程。
1. 这一章讲什么
前面十二章反复出现同一句告诫:要 evaluate, evaluate, evaluate。 这一章把这三个词展开成方法1。
开篇是个有分量的自述:Copilot 是第一个工业级 LLM 应用, 踩了无数「早知道就……」的坑,但有一件事作者自称「做对了」—— 代码库里最老的既不是代理、不是提示词、也不是 IDE 插件壳, 而是评估。因为从第一天起,每个改动都能当场判定: 是进步、是失误、还是白忙。作者的结论一句话:评估框架会指导之后全部的开发2。
方法分成两级。offline:拿独立于线上运行的例子测,不需要真用户, 项目早期就能搭;online:直接部署到真人身上测,风险大但数据最真3。
2. 顶层全景
在实验室(offline) 在人间(online)
┌────────────────────┐ 上线后 ┌──────────────────┐
│ 例题哪 来?(三来源) │ ─────→ │ A/B 分流 │
│ ① 现成记录 │ │ 优化指标 + 护栏指标 │
│ ② 应用使用数据 │ │ 五档信号择优 │
│ ③ 合成例题 │ │ │
│ 答案怎么判?(三法) │ │ │
│ 金标准 / 功能 / LLM │ │ │
└────────────────────┘ └──────────────────┘
图说:offline 侧两个问题各三选项,书末给了两张自检清单;
online 侧的主旋律是「带宽有限」,lab 里先筛掉臭棋再上。
动手之前还有一个元问题要先答:你到底在测什么? 答案有三层——换模型好不好、调提示词好不好、还是整体架构好不好; 对应两种测试件:盖住一大段回路的回归测试(regression,防改坏), 和盯住单次调用的单元测试(unit)。选型口诀:换模型用宽覆盖的回归, 调提示词用单元,动架构只能靠回归;都建不了时,优 先建那个盖住整个 loop 的4。 另外无论哪种测试,延迟和 token 消耗顺手都要记,便宜且迟早要知道5。
3. 核心原理
3.1 主走查:一间会说「I'm chilly」的房子
主走查开始。 场景:你对智能家居管家说「I'm chilly」(我有点冷)6。 这一句话将在本章扮演三个角色:
第一幕 · 当考题 它是 harness 里的一条样例输入
第二幕 · 定判卷面 满分答案是 set_room_temp(temp=77);但判卷只查一件事:
有没有去调暖气这个系统——温度准不准不查
(为什么:不调暖气是常见死法;调了但温度略偏几乎不发生)
第三幕 · 定打分表 SOMA 三张嘴分别问:动作对不对?问题解没解?
克制(没乱来)且果断(不用人手把手)吗?
图说:同一条输入贯穿三个环节。注意 77ºF 这个数只在第一幕出现,
后两幕刻意看不见它——评判抓的是「会犯的那种错」,不是复述标准答案。
第 10 章原书自己也是拿它当主讲线的,连给评估模型看的完整提问模板 (例 10-1)都写在这道题上7。下面沿三个环节逐一拆。
3.2 从 playground 到 harness:四级台阶
起点低到不像话:开会话窗 口试两个例子。它的可扩展版叫 example suite(例子集),只有三个零件——5 到 20 个例子、 一个批量跑并把组装好的提示词与补全落成文件的脚本、一双肉眼(提交进仓库看 git diff)8。
它不是软件工程意义上的测试套件:没有自动判卷,每次改动都要人来翻差异。 换来的是两条好处:写得第一版提示词当天就能上评估; 以及翻着翻着你就会认识这些例子的常客毛病,反过来定点修提示词9。
书的实战案例是 GitHub 的 PR(Pull Request,合并请求)摘要项目: 几十个真实 PR 做例子,翻摘要发现太干就加词 detailed,太啰嗦就限一两段, 瞎猜动机就要求只描述功能——甚至把"功能段+背景段"两段一起生成, 只露功能那段,用的正是第 09 章 fluff 一节的花招10。
往上再升一级就是 harness(带自动判分的评估装置): 需要成百上千个例子(精细效应要靠统计功效才看得见)+ 自动判答案对错11。 复杂交互(一来一回好多轮的对话)有两种测法:
| 方法 | 做法 | 代价 |
|---|---|---|
| canned conversations(罐头对话) | 整场剧本写死,逐轮测,不管模型答什么都用剧本里的答案续下一轮 | 不敢测全环 |
| 让模型扮用户 | 给一份「用户画像」,像即兴戏剧的角色设定那样让它演 | 模型自己的误解与偏见会被烤进结果里 |
两种测法各让渡一点真实性:前者测不到完整回路,后者把扮演者的偏差烤进数据12。
3.3 样本三来源,每来源一道生死题
harness 要吃几百上千例。书给的三个来源,每个都附一个一票否决的问题13:
| 来源 | 是什么 | 陷阱 | 一票否决的判据 |
|---|---|---|---|
| 现成的记录 | 人类早就没有 AI 时做过的事留下的存货。例如某表单应用要 AI 预填摘要字段,手里就有几万条人填的历史记录14 | 多半只是「相似」而非相同,相似度决定结论合法度 | 找得到足够的量吗? |
| 应用使用数据 | 你自己的应用产生的。Copilot 自己就这么造题:开源仓抽函数 → 删掉函数体 → 问「接下来写啥?」。分布偏了(整函数比典型建议长、import 都已就位),但 胜在近乎无限的样本井15 | 上线才有;应用一更新旧数据作废;遥测要过隐私关;而且只有输入没有金标准输出——用户行为被你的建议带着走16 | 数据来得够快吗(算上过期)? |
| 合成例题 | 让 LLM 出题。最好从答案倒推出题;几个侧面可组合(A 方面 n 种 × B 方面 m 种 × C 方面 l 种 × D 方面 k 种=n×m×l×k 个题眼);一次要多个比反复高温重采更多样17 | 套路化、流行误解、事实错误;最毒的一味:出题的 LLM 和被测的 LLM 是同一个——比较模型 A/B 时,A 出的题天然偏袒 A18 | 你愿意花功夫打磨出题流程吗? |
3.4 判卷三法,由易到难
有了题目和候选答案,按难度递增有三条判法19:
其一,对金标准(即可信的标准答案)。 最容易的情形是二选一:Albert 做过一个单测生成应用,循环第一步问自己 「这段代码需不需要单测?」——yes/no 直接数命中就行20。 自由文本用精确匹配会随着长度自由度飙升而失效——答案越长, 逐字命中的概率越趋近于零,指标沦为废纸,而且要先想清楚: 你在优化正确解,还是在优化某种腔调?21
主走查第二幕就在这里:部分匹配(partial match)只挑一个要害切面比对。 代码忽略注释空行;旅行推荐只对国家;而「I'm chilly」只查 有没有去调节供暖系统,不查是不是恰好 77ºF—— 因为「没听懂要去开暖气」是高发死法,而「开了暖气只是没开到 77 度」罕见22。 挑切面的两条准则23:
- 能区分致命偏差和良性偏差(这才是判卷有效的来源);
- 不过细不过粗——过细它几乎永远得不了分,过粗评测失去意义。
作者补了一句诚实的注脚:切面是根据当前模型的典型错法选的,
这里面有个循环(用现在的弱点设计考试,再用考试指导改进)——
但依然好过选一个又弱又误导人的切面24。
工具重的应用还有个免费切面:查「用对工具没有 + 语法对不对」。
并且优先评连续决策里第一个真正可能错的点——在
to=functions. → 选工具 set_room_temp → 填值 {"temp": 77} 这条链上,
第一环错则后面大概率白搭,第一环对而后面形式不同,仍有相当概率是好答案25。
其二,功能测试:能解析吗、只调了存在的函数吗、参数类型对吗。 多数场景嫌弱,但碰巧有的 domain 能走很远——Copilot 就是: 让模型重写某个开源函数,然后跑那个仓库自己的单元测试套件, 看还过不过(更弱的版本是让 linter 静态检查认同)26。
其三,LLM assessment(请模型当裁判)。 直觉抗议:让学生给自己批卷?作者的回答是—— 不会,前提是你别让裁判知道他在给自己的活打分。 实测排序:评第三方最准,评用户稍差,评自己差得多; 因为训练语料里论坛争吵那一面让它习惯性抬杠,RLHF 又教会它一被质疑就慌忙改口—— 两头拉扯之下,自我评价最难客观27。 还有一个必须记住的天花板:LLM 打的分天然只是相对判断。 「它在 81% 的案例里判正确」单独拿出来毫无意义,要比较版本 A 和 B 才有效力28。
3.5 SOMA:把裁判驯化成仪器
要让模型裁判稳定输出,书给出一个配方,SOMA = Specific + Ordinal + Multi-aspect29:
| 字母 | 主张 | 「I'm chilly」上的样子 |
|---|---|---|
| S 具体 | 别问「这答案对吗?」这种空泛问题——验证常比生成容易(五分钟诗验证押韵规则很容易,现场写一首很难),但空泛问题反而不比生成省力,还会衍生多种解读30 | 改问「这个动作能不能解决用户冷的问题?」 |
| O 有序量表 | 别用 yes/no,改 1–5 打分且每级配文字定义——否则每个答案各按一套心情标准(心理测量学的研究也站在 5 级这边)31 | 例 10-1 的五级刻度,从「无济于事」到「必然解决」 |
| MA 多切面 | 「好不好」不止一根尺子;提前定好几张评分表,逐张问,防止裁判随兴换标准6 | 三张表:动作实现了吗(tool 选择与语法)/ 解决冷暖了吗 / 够克制(没乱来)又够果断(不磨叽)吗 |
Intent/execution 二分是常用的多切面起手式;GitHub Copilot chat 的打分体系 RTC(relevance-truth-completeness,相关性-真实性-完整性)就建在其上 (出处是 Lizzie Redford 的《Machine Psychometrics》)32。 还有两条工程细节值得原文照搬:33
- 评估指令要放在被评样本之前——模型不能回头重读, 先立规矩后看答卷,它才知道往哪儿看;
- 把「刚刚好吗?」这类 Goldilocks 问题拆成两问: 「够不够」和「会不会太多」分开问,信号干净得多。
最后,SOMA 本身也要验货:找几个真人独立评一批,量出人之间的分歧 (Kendall's Tau 这类标准方法),再把模型(固定 temperature 0 问一次) 加进评委池——分歧不显著变大,这台裁判才算过关。道理很直白: 模型是人评的平替,不能比原来那台更吵34。
书末两张速查卡把整章 offline 方法论收拢成六个是非题: 来源卡(records 够不够多?应用数据够不够快?愿不愿意手工伺候合成?)
- 判法卡(匹配现实可行吗?有没有可自动化的关键切面?好坏肉眼看得出差别吗?)—— 每行答不出 yes,那行就不能选35。
3.6 online:A/B 与五档信号
实验室有三个好处——安全(搞砸没人知道)、可扩展(想法试得快)、 存在得早(产品还没影就能开工)36。 但歌里唱得好,Life is live:上了线,真人反馈才是产品价值的终极检验37。
标配动作是 A/B 测试:一小部分用户拿新方案 B,其余留守现状 A, 预先定优化指标和护栏(guardrail,不许恶化的底线指标,通常是报错率/投诉率), 到期对比获胜者全量。Optimizely/VWO/AB Tasty 这些成熟平台都能托管。
客户端(装在用户设备上、要发版更新才能改的那一端)应用的推版延迟,是它天生比 offline 慢的原因之一; 还有个小陷阱:不能用「已更新 vs 未更新」的用户分组对比—— 愿意快速更新的用户行为本来就不一样38。
拿到信号后按可靠程度排成五档39:
| 档位 | 问句 | 书里的实测细节 |
|---|---|---|
| ① 直接反馈 | 用户怎么说? | 点踩常见且可靠;点赞稀缺只为惊艳(OpenAI 因此撤掉了单条点赞按钮);对比式「哪个更好」信号最清也最扰民;事后追访(行程回来再说值不值)比当下评分值钱;这类数据质量高,顺手还能当微调训练料40 |
| ② 功能正确性 | 建议灵不灵? | 代码编译通过算一半(可能做的不是对的事);机票确认到手才算硬;小目标更实:程序启动了吗、邮件在不在发件箱41 |
| ③ 用户接受度 | 用户跟了吗? | 点击率起步;Copilot 的关键发现:接受率与用户自报的生产力提升相关最强,强过那些更花哨的 impact 测算——简单指标赢了42 |
| ④ 实际影响 | 用户赚了吗? | 「邮件多大比例出自助手之手」「点了目的地推荐后真的买票没有」43 |
| ⑤ 顺带指标 | 周边数字? | 延迟是互动场景的头号顺带项(快而无用仍可能);会话时长语义含混(秒决可能是爽快也可能是怒退)——所以多记少断言,专办异常调查44 |
选择顺序 书也给死了:先找接受或 impact 类;找不到可靠的就回落到直接反馈; 同时留几条护栏盯着别倒退,顺手保留功能正确性与延迟类顺带指标45。
4. 作者的判断与证据
一线亲历(书中多处标注 our finding / we did):
- Copilot 评估先行是两位作者的亲身经历,「最老的代码是评估框架」出自两人的共同经历2;
- PR 摘要的 example suite、删函数体造题法、「接受率与生产力相关最强」 全部是 GitHub 任内实测,第②③两条直接来自 Copilot 项目101542;
- RTC 打分体系引了 Lizzie Redford《Machine Psychometrics》作为出处32。
方法论立场(有依据但非铁律):
- LLM-as-judge 成立条件(别让它知道在评自己、相对化的读数、SOMA 约束、 人评校准)是一条论证链,其中「1–5 量表是好默认值」引的是心理测量学脚注31, 其余主要为作者的综合判断;
- 例子的合成偏倚警告(出题=做题则偏袒)是机制推断,未给定量实验18。
判断(我们的,不是书里的): 本章与第 12 章合起来看,这本书真正的隐藏主张是 可靠性是测出来的,不是设计出来的——工作流提供「坏了能定位」的结构, 评估提供「定位之后知道好坏」的眼睛,二者缺一都不成立。 这也解释了为什么全书唯一一章以公司秘辛开头:评估先行是一次投入、全程吃红利的选择。 如果错,会错在: 若模型能力跃迁使错误变得稀有而均匀, 重型评估框架的投资回收期会拉长,轻装例子集反而性价比更高—— 但作者恰恰为这种情况保留了 example suite 这一最低台阶。
5. 边界与局限
- 写作时点快照:书中点名的平台(Optimizely/VWO/AB Tasty)、 OpenAI 的按钮取舍,都是 2024 年前的状态;方法论耐用,产品名词会老化3840;
- LLM-as-judge 的偏见谱系仍在演化,RLHF 相关论述引用的是当时共识, 更系统的自评校准研究在书出版后才铺开;
- 没有覆盖统计学细节(比如判定差异是不是碰巧、要攒多少样本才作数),Kendall's Tau 只点到用法不教推导34;
- 安全攻防与多租户权限不在本书任何一章(见总纲「不覆盖」清单);
- 团队规模假设:几位工程师的小团队视角,大型组织的评估平台治理未谈。
6. 可带走的
主走查一行回顾:「I'm chilly」进 harness → 判卷只认「动了暖气系统」→ SOMA 三张嘴各打一轮 1–5 —— 一道题三种身份,没有一个环节依赖复述 77ºF。
- 评估框架写成第一段代码;它指导后面所有开发决策2;
- 先 5–20 例肉眼 diff,不要空手等完美方案;样本攒起来再上百上千换自动判卷811;
- 样本三来源对着生死题选;尤其小心「出题人=考生」的合成偏倚1318;
- 自由文本别比全长,挑能分辨致命/良性偏差的单一切面2223;
- 工具链应用评第一个易错决策点(用没用对工具);
- 让 LLM 裁判可成立的四件事:不知情(不当自己的考官)、问具体、答有序、多个切面,外加人评校准2934;
- 指令前置:评估规则写在样本之前,模型无法回头33;
- online 指标按五档找,优先接受率/impact;点赞别当常规信号394042;
- 所有测试顺手记 latency 与 token 账5。
7. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 第一段代码是评估 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:7(搜「codebase is not the proxy」) · :13(搜「guide all future development」) |
| offline/online 定义 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:17(搜「independent of any live runs」) · :22(搜「Being live raises the stakes」) |
| 测什么三层与回归/单元 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:32(搜「assess three things」) · :44(搜「test harness by carving」) · :75(搜「tests the whole loop」) |
| example suite 零件 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:91(搜「5 to 20 examples」) · :100(搜「not like a test suite」) · :107(搜「codify your very first prompts」) |
| PR 摘要案例 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:116(搜「mined from GitHub」) · :119(搜「word detailed to the prompt」) · :126(搜「fluff in Chapter 7」) |
| 升级 harness 与罐头/扮演 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:130(搜「eyeball each time」) · :156(搜「a whole script is written out」) · :162(搜「improv theater」) |
| 样本三来源 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:179(搜「prefilling a summary」) · :198(搜「Remove the body of that function」) · :208(搜「near-infinite well of samples」) · :231(搜「make stuff up」) |
| 合成的坑 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:244(搜「Exploiting combinatorial explosions」) · :255(搜「incestuous relationship」) · :259(搜「leg up on model B」) |
| 金标准与部分匹配 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:278(搜「unit test generation」) · :290(搜「exact match counts」) · :297(搜「partial match metrics can be useful」) |
| 智能家居切面选择 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:309(搜「smart home manager」) · :314(搜「regulates the right system」) · :325(搜「benign divergence」) |
| 第一个可能错的决策 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:340(搜「right tool is used」) · :345(搜「real chance of going wrong」) · :347(搜「commits to the specific tool」) |
| 功能测试与 Copilot 实战 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:359(搜「taking the completion and confirming」) · :366(搜「reimplement a function」) · :369(搜「linters agree」) |
| LLM 裁判的自我问题 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:384(搜「high schooler」) · :403(搜「forum discussions」) · :407(搜「slightest expression of user doubt」) |
| SOMA 三要素 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:413(搜「multiaspect coverage」) · :419(搜「criteria for being a limerick」) · :430(搜「capriciousness」) · :457(搜「being chilly」) |
| 工程细节与校准 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:467(搜「precedes the example」) · :491(搜「Goldilocks questions」) · :542(搜「Kendall's Tau」) · :543(搜「temperature 0」) |
| online/A/B 与护栏 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:569(搜「no one will know」) · :583(搜「real stinkers」) · :586(搜「guardrail metrics」) · :598(搜「Optimizely」) |
| 五档指标 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:616(搜「five main kinds」) · :638(搜「particular brilliance」) · :673(搜「acceptance metrics」) · :678(搜「buying a ticket」) · :686(搜「rage-quits」) |
| 收束建议 | Chapter 10 | text/13-ch10-chapter-10-evaluating-llm-applications.txt:693(搜「acceptance or impact metric」) · :709(搜「time well spent」) |