一杯咖啡的启示 — Why Evaluation Matters / 一杯咖啡的启示
一杯咖啡的启示
清晨六点四十分，旧金山 Mission District 的 Blue Bottle Coffee 还没开始排队，林越已经坐在靠窗的位置第三个小时了。
她的 MacBook 屏幕上是一份长长 prompt 模板——公司那款智能客服机器人的系统提示词。两个月前产品上线时，她以为最难的部分已经过去了：选型、训练、对接、上线、灰度发布，每一个节点她都亲手盯过。但此刻她正在做的，却是一件上线时从没计划过的事：凌晨四点收到一封客户邮件后，她睡不着，一个人跑到咖啡馆，反复修改一行措辞。
> "你能不能别再跟我说'非常抱歉给您带来不便'了？我问了三遍订单状态你都没答上来，道歉有什么用？"
邮件只有两行，但林越把每一个字都读进去了。她试着从用户的视角重新看自己过去两个月的工作：上线两周后用户投诉率上升，她以为是 prompt 太啰嗦，于是改；改完之后，NPS（Net Promoter Score，净推荐值）数据没什么变化，她以为是数据噪声；一个月后，客服主管私下跟她说"最近转人工的请求变多了"，她以为是产品功能问题，跟算法团队开了个会，调整了转人工阈值；又过了两周，CTO 在周会上随口提了一句"这个项目最近 ROI 看起来一般"，她才意识到有什么东西在系统性地失灵。
但她说不清失灵在哪里。
她盯着 prompt 文件里的最后一行：
```
- 当你无法确定答案时，请礼貌地引导用户转接人工客服。
```
"我让模型在不确定的时候转人工，"她心里想，"但什么算'不确定'？模型自己知道什么算'不确定'吗？我知道它什么算'不确定'吗？"
她问不出答案。两个月的线上运行，她手里有的数据只有：调用量、对话轮次、转人工率、用户评分。这些数字告诉她"有东西坏了"，但没有告诉她"坏在哪一段、为什么坏、修哪一句 prompt 能修好"。
那一刻，咖啡馆门被推开，冷风灌进来，她打了个寒战，脑子里同时跳出了一个她从没对任何人说出口的问题：
"我们到底知不知道这个模型'好'在哪里、'坏'在哪里？"
这个问题的答案，在过去两个月里，是不知道。而更让她后怕的是——她意识到，整个行业里，大量 AI 产品都活在这种"不知道"里。
这就是这本书第一章要回答的问题：为什么 AI 产品必须拥有一套评测体系？ 不是"可不可以有"，不是"有了更好"，而是——没有，就等于在黑暗中开车。
---
1.1 评测缺位：当 AI 产品"看起来在工作"
林越的故事并不是个例。在过去三年里，我和二十多个 AI 产品团队聊过类似的情境：模型上线那一刻，所有人都松一口气；上线之后，所有人都在"救火"，但没有人能说清楚火是从哪里烧起来的。
这种现象在业界没有一个统一的名字。我把它叫做 Evaluation Debt（评测债）——一个借自技术债（Technical Debt）概念的词。技术债指的是为了快而留下代码层面的妥协，评测债指的是为了快而留下"判断能力"层面的妥协：你今天省略了评测，将来你就要为这种省略付利息。利息的形式，是用户流失、是隐性错误、是商业损失。
下面我用三段典型的故事——来自真实的、脱敏过的团队经历——把评测债的代价讲清楚。
1.1.1 代价一：用户流失（User Churn）
第一家公司在做一款 AI 写作助手。MVP（Minimum Viable Product，最小可行产品）上线后，团队把"日活"作为唯一北极星指标。前三个月数据漂亮——日活从 8 千涨到 5 万。董事会很高兴，准备开 B 轮融资。
但 PM（Product Manager，产品经理）张然私下发现一个细节：用户首日留存率（D1 Retention）在缓慢下降，从 65% 跌到 52%，再跌到 41%。他把这个数据抛出来，得到的回复是"产品刚上线，波动正常"。
他没有数据反驳"正常"这个判断。他只能说"我觉得不太对"。
三个月后，公司拿到 B 轮融资；同一个月，日活开始下滑——从 5 万跌到 4 万，又跌到 3 万。董事会开始追问。CEO 让张然"找原因"。张然打开了埋点系统，从用户行为日志里一行一行看，看到一个让他脊背发凉的模式：
> 新用户在首次使用后，平均会发起 7 次"重写"请求。 > 7 次中的 4 次，是"把这句话改得像人话一点"。
这意味着产品有一半的核心输出，在用户眼里是"不像人话"。但因为模型生成的文本"看起来是中文"、"长度合适"、"语法没错"，团队里没有人意识到——"看起来在工作"和"真的在工作"之间，差着一整套评测。
他们从来没有系统地评估过"自然度"、"可读性"、"专业契合度"这些维度。他们只看了"输出长度"、"调用成功率"这些技术指标。直到用户用脚投票，数据才反过来告诉他们。
> 评测债的第一种代价：你以为的"在工作"，和用户感受到的"在工作"，是两件事。当你没法量化后者，你就只能在用户离开之后才被告知。
这种代价的可怕之处在于滞后性：用户流失不是今天不好明天就走，而是"今天差一点、明天差一点、累积到某一天突然大面积流失"。你看到的"突然"，其实是"已经发生了很久"。
1.1.2 代价二：隐性错误（Silent Errors）
第二家公司做的是法律合同 AI 审查。客户是中型律所。产品的核心价值是"自动标出合同里 12 类常见风险条款"。
产品上线后客户反馈不错。客户成功团队（NPS 8.2）报告说"用户觉得很专业"。公司续约率 95%。
九个月后，一家律所的合伙人在行业会议上公开说："他们那个 AI 漏掉了我最重要的一个条款——一个连带责任的兜底条款，让我客户损失了两百万。"
CEO 紧急召集团队复盘。他们调出那一份历史合同，让模型重新跑了一遍。模型输出里，没有标出那个条款。
工程师的第一反应是："这个条款在训练数据里没出现过。"——这是合理的。
但 PM 追问了一个更关键的问题："我们之前怎么没发现？"
答案是：因为他们没有"反向测试集"。他们的评测集是"我找一些合同，跑一遍，看命中率多少"。但他们从未构造过"我专门挑出那些已知会失败、但模型不知道的输入，看模型会不会在它们身上翻车"。
更准确地说，他们从未定义过"漏报"的成本。在他们心里，"召回率 87%"是一个好数字。但他们没有回答：漏的那 13%，是哪些 13%？是边缘案例还是核心案例？
在医疗、法律、金融这些领域，"漏掉的那一个"可能就是命案、就是赔偿、就是退市。 当你只用"准确率"这种平均值来衡量模型时，你其实在赌——赌那 13% 不会落在关键案子上。
而 AI 模型有一个坏脾气：它最擅长翻车的，往往就是那些你最不希望它翻车的地方。
> 评测债的第二种代价：模型在"大部分情况下"表现得越好，团队越容易在"少数情况下"放松警惕，直到那个少数情况真的发生。隐性错误不像崩溃那样报警，它只会在沉默中累积，最后以一种不可控的方式炸开。
这就是为什么林越在那个早晨会觉得"有什么东西系统性地失灵"——她没有数据证明，但她有直觉：转人工率上升不只是阈值问题，而是模型在某些场景下的失败率在悄悄上升。而她无法量化"哪些场景"，所以她无法修复。
1.1.3 代价三：商业损失（Business Loss）
第三家公司的故事最微妙，也最常见。
这是一家电商公司，他们做了一个 AI 推荐助手，集成在客服 IM 里。它的形态是：当用户问"有没有适合夏天穿的衣服"时，AI 会从商品库里挑 3-5 件推荐。
上线三个月，订单转化率（Conversion Rate）从 1.2% 涨到了 1.8%。涨幅 50%。CTO 在季度会上说"AI 项目是我们这季度最成功的产品"。
但财务总监私下做了另一个口径的统计：把"AI 推荐路径"的转化率和"人工推荐路径"的转化率分开看。
> 人工推荐路径：转化率 2.4% > AI 推荐路径：转化率 1.5%
AI 拖累了整体转化率。但因为 AI 路径被大量原本不会走"推荐"流程的用户走了，掩盖了这一点。
换句话说：AI 把很多本来不会进推荐流程的"低意向用户"拉进了推荐流程，这些用户无论如何都不会买，他们的低转化率被算到了 AI 头上；而那些本来会进推荐流程的"高意向用户"，因为被 AI 推荐了不太合适的商品，反而没买。
这是一种典型的辛普森悖论（Simpson's Paradox）——分组看和汇总看，会得出完全相反的结论。
CTO 之所以犯这个错误，是因为他们没有按用户分群做评测。他们只看了"AI 上线前后"的整体数字，没看"原本就会用推荐的用户"这个细分群体在 AI 上线后的表现。
> 评测债的第三种代价：你以为你看到了"提升"，但其实只是平均数骗了你。商业决策一旦建立在错误的口径上，每一次优化都是在错的方向上跑得更快。
林越坐在咖啡馆里想的"ROI 看起来一般"，本质就是这种商业损失。她的产品在某些指标上变好了（比如响应时间），在另一些指标上变差了（比如转人工率），但她没有把这些指标对齐到同一个商业目标上，所以她无法回答："这个项目，对公司来说，到底值不值？"
---
1.2 评测（Evaluation）一词的起源与 AI 中的含义
林越盯着屏幕发呆的时候，咖啡馆里走进来一位老朋友——陈墨，AI 研究背景出身，现在在湾区一家研究机构做 AI Safety 方向的研究员。她是林越读研时期的学姐。
"这么早？"陈墨端着咖啡坐到她对面。
"睡不着。"林越把邮件给她看。
陈墨看完，沉默了几秒，说："你这个不是 prompt 的问题。"
"那是什么问题？"
"评测的问题。 你现在做的所有优化，都是在猜。你不知道什么有效、什么无效、有效在哪、为什么有效。"
"我当然知道，"林越脱口而出，"我们有数据——调用量、对话轮次、转人工率、NPS——"
"这些都是结果指标，"陈墨打断她，"它们告诉你有没有问题，但不告诉你问题在哪。你现在做的事，本质上是在没有 GPS 的情况下开车，只看仪表盘上的速度，却不知道目的地在哪、路线对不对、下一个路口该左转还是右转。"
林越第一次听到有人用"GPS"这个比喻形容她工作的状态。她忽然觉得，过去两个月自己的所有焦虑、所有"救火"、所有"再改一版试试"，本质上都是在没有地图的夜里开车。
陈墨顺势给她讲了"评测"这个词。
1.2.1 评测的传统含义
"Evaluation"这个英文词，词根是拉丁文 *valere*，意思是"有价值"（to be worth）。它的本质含义是：判断某物在某个维度上"值多少"。
在人类的认知系统里，评测无处不在：
- 一个厨师尝一口汤，判断"盐够不够"
- 一个医生看一张 CT，判断"有没有结节"
- 一个老师改一份试卷，判断"学生掌握得怎么样"
- 一个投资人看一份财报，判断"这家公司值不值得投"
评测的本质是比较：把"实际表现"和"某个标准"做比较，得出一个可决策的结论。
这个标准可以是绝对的（比如"盐含量必须达到 2%"），也可以是相对的（比如"比上一版更好"），也可以是分布的（比如"90% 的用户都觉得好"）。但无论如何，没有标准，就没有评测。
1.2.2 评测在 AI 系统中的位置
当评测的对象是 AI 模型时，它的含义会更复杂一些。AI 模型有几种不同的"评测"：
1. 能力评测（Capability Evaluation）：模型能做哪些事？语言理解、推理、数学、代码、常识——每一种能力都可以独立评测。这也是我们在榜单上看到的那些"基准测试"（Benchmark），比如 MMLU、HumanEval、GSM8K。
2. 对齐评测（Alignment Evaluation）：模型的输出是否符合人类意图？有没有幻觉？有没有偏见？有没有有害内容？这种评测关心的是"模型在做什么"，而不是"模型能做什么"。
3. 任务评测（Task Evaluation）：模型在某个具体业务场景下表现如何？这是产品团队最关心的问题。任务评测回答的不是"这个模型聪明不聪明"，而是"这个模型在这个具体场景里够不够用"。
4. 过程评测（Process Evaluation）：模型在生成答案的过程中，有没有"按对的方式"思考？这是 CoT（Chain of Thought，思维链）类技术出现之后越来越被重视的评测维度——它关心的是路径，而不仅仅是终点。
5. 成本评测（Cost Evaluation）：调用一次模型需要多少算力、多少 token、多少钱？延迟多少？这是产品维度最容易被忽略、但实际上最影响商业可行性的评测。
林越做的客服机器人，需要的是第 3 类——任务评测。但过去两个月，她连第 3 类评测都没做，更别说把它和第 5 类（成本）结合起来判断"值不值"。
1.2.3 评测 ≠ 测试（Testing）
这是很多初学者会混淆的概念。
测试（Testing）关心的是"有没有 bug"——程序是否在所有指定输入下都产生指定输出。它是确定性的、有标准答案的、单元化的。
评测（Evaluation）关心的是"够不够好"——在大量输入下，模型的整体表现是否符合预期。它是统计性的、有时没有标准答案的、分布化的。
举一个具体的对比：
> 测试：你输入 `"订单 #12345 状态"`，模型必须返回 `"已发货"`。你可以用单元测试断言这个输出。 > 评测：你输入 10000 个真实订单查询，统计模型返回"正确状态"的比例。但"正确状态"本身没有 ground truth（人工标注）你怎么知道模型对不对？即使有了 ground truth，"模型返回'已发货，预计 3 天到达'"算对还是错？
评测比测试难得多，因为它必须处理模糊性。这也是为什么 AI 评测在 2023 年之后从"一个工程任务"变成了"一个研究任务"——我们甚至连"怎么判定一个生成式模型的输出是好是坏"这件事，都还没有完全解决。
> 林越听完后，沉默了一会儿，问了一个让她自己都吃惊的问题："那是不是说，过去两个月，我的所有 prompt 优化，本质上都是在没有评测的情况下盲调？"
> 陈墨笑了："你终于开始想这个问题了。"
---
1.3 评测在 AI 生命周期中的四个位置
陈墨接着给林越画了一个 AI 产品的"时间轴"——从立项到退役。她指出了四个"评测应该出现"的位置。
1.3.1 训练前（Pre-Training）
很多团队跳过了这一步，直接进入"调模型"。但一个真正成熟的团队，会在训练模型之前就定义好评测协议（Evaluation Protocol）。
这意味着：
- 我要用什么数据来评测这个模型？
- 评测的指标是什么？准确率？召回率？F1？还是更复杂的业务指标？
- 谁来标注 ground truth？标注员之间的一致性怎么衡量？
- baseline（基线）是什么？没有 AI 之前，人工做的效果如何？行业 SOTA（State of the Art，当前最优水平）是多少？
- 评测集本身的质量怎么保证？评测集有没有数据泄露？有没有偏倚？
> "你的客服机器人，"陈墨说，"在训练之前，团队有没有回答过这些问题？"
林越想了想，老实说："没有。我们当时是直接 fine-tune（微调）了一个开源模型，用的是供应商给的数据集，prompt 是边上线边改的。"
"这就是评测债的来源，"陈墨说，"你在盖楼之前没打地基。"
1.3.2 训练中（During Training）
这一步大家比较熟悉：训练过程中每 N 步在验证集（Validation Set）上跑一次，看 loss（损失函数值）下降情况、看验证集上的指标变化。
但一个容易忽略的问题是：训练中的评测指标和最终业务目标，是否一致？
经典的机器学习教科书会告诉你：训练时用 cross-entropy loss（交叉熵损失），评测时用 accuracy（准确率），二者并不等价。同样，训练时用 accuracy，最终业务关心的是 NPS，二者也不等价。
更微妙的是：训练中的评测是收敛导向的——我们关心"模型在训练集和验证集上的 loss 是否同步下降"；而业务上的评测是分布导向的——我们关心"模型在不同用户群、不同 query 类型上的表现是不是都稳定"。
> 一个真实的反例：某团队的客服模型在验证集上 accuracy 95%，但上线后才发现——它对"查物流"的 query 准确率 99%，对"申请退款"的 query 准确率 78%。因为训练集里"查物流"占 80%。验证集的平均数漂亮，掩盖了长尾的灾难。
1.3.3 上线前（Pre-Launch）
这是评测最关键的位置之一。模型在选定之后、上线之前，必须经过严格的、模拟真实环境的评测。
这一步的核心目标是回答一个问题："模型在我这个产品的真实使用场景下，可不可以上线？"
注意：不是"模型能不能跑通"，不是"模型在测试集上准确率高不高"，而是"在我这个产品的真实使用场景下"。
这意味着评测集必须满足：
1. 覆盖真实分布：评测集的用户 query 分布，要和真实业务场景一致。 2. 包含对抗样本：评测集里要有"难例"、有"边界情况"、有"恶意输入"。 3. 反映用户价值：评测的指标要能反映用户真实关心的东西，而不是技术指标。 4. 考虑公平性：评测集要在不同人群、不同地域、不同语言风格上做分组评测。
> 林越的团队在上线前做的"评测"，是让三个工程师各自用 10 个自己编的 query 跑了一遍模型。这是"测试"，不是"评测"。前者只能告诉你"模型在工程师想得到的输入下不出错"，后者必须告诉你"模型在所有可能用户的输入下不出错"。
1.3.4 上线后（Post-Launch）
这一步是绝大多数团队彻底缺位的一步。
上线之后，模型面对的是真实世界的全量流量——用户可能问任何事，AI 可能产生任何输出。这时候评测的目标不再是"选择最好的模型"，而是"持续监控模型在生产环境中的表现，并及时发现问题"。
上线后的评测通常包括：
- **线上 A/B 测试（Online A/B Testing）**：让一部分流量走新模型，一部分走旧模型，比较业务指标。
- **影子模式（Shadow Mode）**：让新模型"偷偷跑"但不真正影响用户，把它的输出和旧模型比较。
- **用户反馈闭环（Feedback Loop）**：收集用户对模型输出的显式反馈（点赞/点踩）和隐式反馈（重写次数、转人工率、跳出率）。
- **异常检测（Anomaly Detection）**：监控关键指标的突变，触发