跳到主要内容

7.4 给自己的任务造一把尺子

榜单到此为止​

前三节讲的都是怎么读别人的成绩单：认识各张考卷（7.1）、识破分数失真（7.2）、亲手体验评委有多容易被骗（7.3）。

但你真正要回答的那个问题，榜单一个字都没提：

这个模型，在我的场景里，够不够用？

7.2 节已经点破了：一个 MMLU 88 分的模型，完全可能在你的具体业务里不如 85 分的那个。榜单测的是通用能力的平均值，你要的是特定任务上的表现——两者的相关性没有你以为的那么高。

所以从这一节开始，问题换成了：怎么给自己的任务造一把尺子？

这个问题的答案会贯穿三本书。中篇的 K6 教你量 RAG，下篇的 A7 教你量智能体，而它们共用的地基就在这一节。

反直觉的第一步​

问一个团队「我们该怎么评测」，十有八九的第一反应是：先定几个指标，再写个自动评分脚本。

这条路几乎总是走歪。

原因很朴素：你还不知道你的系统是怎么坏的。 指标是用来量问题的，可你连问题长什么样都没见过，量什么？结果往往是造出一把精致的尺子，量了三个月，分数纹丝不动——因为它量的根本不是真正在出问题的那个环节。

正确的第一步平淡得让人失望：

打开日志，一条一条地读。

业界把这个动作叫错误分析（error analysis）。它没有任何技巧，就是人肉看数据。但它决定了后面所有工作的方向——经验丰富的团队会把开发时间的一大半花在这上面，而不是花在搭评测框架上。

亲手做一遍​

先别急着信，自己做一遍就知道了。下面这个实验会先问你一个问题，再给你 12 条真实形态的会话记录：

🎮 动手实验
错误分析：先看数据，再建评测器
一个「公司制度问答」机器人上线了，用户开始抱怨。你手上有 12 条真实会话记录。先猜一猜问题出在哪，再逐条读完——看看你的直觉准不准。
先别看数据。凭你对这类系统的直觉猜一下：用户抱怨最多的，最可能是哪个问题？
💡 要点：错误分析的全部动作就是逐条读数据、给失败归类、数出哪一类最多——没有任何技巧，但它决定了你接下来该修什么。业界的经验法则是先读 100 条左右，连着 20 条读不出新类别就可以停手。
12 条会话是教学构造的，但类别分布刻意做成了生产 RAG 的典型形态：检索环节的失败最多、最容易被低估，而人们最爱猜的「幻觉」往往只占一小块。

三个提醒：

一、认真做第一步的猜测。 组件会记下你的答案，最后拿它跟真实分布对照。绝大多数人会猜「模型在编数字」——因为幻觉是最出名、最容易想到的失败。

二、逐条看完，别跳。 有两条失败是「隐蔽」的：第 4 条数字被悄悄改大了、第 6 条引用指向了错误的文档。它们读起来都非常通顺，不核对原文根本发现不了。漏掉它们不丢人——这恰恰说明为什么错误分析这件事没法外包给一眼扫过去的人。

三、看最后那张帕累托图。 9 条失败里有 4 条是同一个病根：检索压根没捞到对的文档。这意味着修检索一件事，能一口气解决近一半的失败；而你多半猜的那个「幻觉」，只占 1 条。

如果跳过这一步直接建评测器，你很可能造出一把专门量幻觉的尺子，然后困惑于「为什么分数怎么调都不动」。

一个绕不开的怪圈​

做完实验，你可能会注意到一件别扭的事：你是在读数据的过程中，才慢慢想清楚「什么算失败」的。

比如第 11 条——模型说「资料中未提及」，这算失败吗？看上去像拒答，可它拿到的资料里确实没有答案，模型的行为其实是对的，病根在检索。你多半是读到第 11 条时才意识到「拒答」得拆成两类。

这个现象有个名字，叫标准漂移（criteria drift，2024 年的研究正式命名）：

你需要先有标准才能给输出打分；但恰恰是打分的过程，才让你想清楚标准是什么。

这是个真实的循环，绕不过去。它直接推翻了那条听起来天经地义的做法——「先把评测标准定义清楚，再开始评测」。标准不是想出来的，是看出来的。

实践上的应对不复杂：把它当成迭代过程。读一批 → 归一次类 → 修订标准 → 拿新标准回头重读之前那批。前两三轮的标准一定会改，这不是没规划好，这是这件事本来的样子。

这套方法在哪里有边界

一、它不能自动化。 错误分析的价值恰恰来自「懂业务的人亲眼看了」。让模型去读日志、自动归类，看上去省事，但模型会漏掉它自己也犯的那类错误——第 4 条那种改了数字的答案，让同一个模型去判，它多半觉得没问题。（下一节会给出这件事的量化证据。）

二、样本会有偏。 你从日志里捞的，只是已经用起来的人产生的数据。那些试了一次觉得不好用、再也没回来的用户，他们的失败案例不在你的日志里。所以随机抽样之外，还要专门去找投诉、差评、以及流失用户的最后几条会话。

三、别为不值得的失败建基础设施。 读完数据你会发现一批问题当场就能改——提示词里少了一句话、某个字段没传。这类直接修掉就行，不需要为它建评测器。只有那种「修了还会以别的形式回来、你要反复迭代」的失败模式，才值得为它造一把尺子。

判分方式的阶梯​

知道了要量什么，接下来是怎么量。按成本从低到高、可靠性从高到低排：

方式适用代价
代码断言客观可判：JSON 能不能解析、必填字段在不在、数字对不对、代码跑不跑得过几乎免费，且 100% 可靠
模型裁判主观质量：语气对不对、有没有答到点上、引用是否支撑结论便宜但会错，用前必须校准（下一节）
人工评判定标准、校准裁判、处理疑难最贵，但它是前两者的真值来源

能用代码判的，绝不要用模型判。 这条规则听着像废话，实际最常被违反——很多团队一上来就写「让 GPT 给答案打 1 到 5 分」，而他们真正想查的其实是「引用的文档编号存不存在」，一行代码的事。

还有一条同样重要的：能做成二元判断，就别做 1~5 分的评分。「这条算通过还是不通过」人和模型都能答得稳；而「这条该给 3 分还是 4 分」——换个人、甚至同一个人换个时间，答案都会飘。分数看着信息更多，实际上多出来的那部分全是噪声。

本节要点
  • 公开榜单答不了「它在我的场景里够不够用」——你需要自己的评测集。
  • 第一步不是写评测器，是逐条读数据（错误分析）：开放归类 → 数出分布 → 找到真正的大头。
  • 真正的失败大头往往和直觉猜的不一样（实验里：检索没召回 44%，而幻觉只有 1 条）。
  • 标准漂移：标准不是先想出来的，是在读数据的过程中看出来的——所以评测标准必然要迭代几轮。
  • 判分优先级：能用代码断言就别用模型；能二元就别打 1~5 分。
  • 别为「当场就能修掉」的问题建评测基础设施。
📝 动手自测0/3
1. 要给自己的业务系统建评测，正确的第一步是？
2. 「标准漂移」（criteria drift）指的是什么？
3. 你想检查 RAG 系统「引用的文档编号是否真实存在」。最合适的判分方式是？

延伸阅读​