160 篇博文 含有标签「evaluation」

大多数 AI 产品团队都会遇到这样一种场景：某位领导层成员询问新的文案生成模型是否比旧的好。团队运行了评估套件，准确率数据看起来不错，于是发布了模型。三周后，营销团队悄悄换回了旧模型，因为新模型“听起来不对劲”。准确率指标是真实的，只是他们衡量错了对象。

这就是 AI 品味问题。只要你的输出是主观的——文案创作、设计建议、创意内容、语气调整、风格推荐——它就会出现。当没有客观的基准事实（Ground Truth）时，传统的机器学习评估框架会给你一种虚假的自信。而大多数团队对于该如何应对并没有系统性的方案。

大多数团队在选择标注策略时，都会比较单价：众包工人大约 $0.08/条，LLM 生成不到$0.003/条，人类领域专家约 $1/条。跑一遍表格，选出看起来"足够好"的最便宜选项，然后上线。这套算法经常让团队陷入麻烦。

真正的决策并非只看单条标签的成本。每种标签来源都有一个隐藏的质量税——以垃圾梯度、误导性评估曲线，或花费数月排查生产故障的形式复利叠加；而干净的标签本可以在训练阶段就捕获这些问题。最便宜的来源往往是计入下游信任成本后最昂贵的一种。

大多数构建 AI 产品的团队会花费数周时间设计评分组件、星级点击、点赞/点踩按钮。然而六个月后，他们查看数据时发现响应率仅为 2% —— 数据偏向于极端体验，被那些带有强烈偏好的人主导，而且在区分 7/10 和 9/10 的输出方面几乎毫无用处。

与此同时，每一个用户会话都在产生源源不断的真实、明确的行为信号。接受代码建议并继续操作的用户是满意的。立即按下 Ctrl+Z 的用户则不满意。连续四次重新组织问题的用户正在告诉你一些显式评分永远无法捕捉到的信息：前三次回答都失败了。无论你是否收集，这些信号都存在。问题在于你是否正在闭合这个反馈回路。

当GPT-4在MMLU上得到88%时，感觉是一个里程碑时刻。MMLU——大规模多任务语言理解基准——涵盖从小学数学到专业法律的57个学科。在如此广泛领域达到88%的准确率，看起来是真正广泛智能的有力证据。后来研究人员创建了MMLU-CF，一个无污染变体，替换掉了与已知训练语料库存在可疑相似性的问题。GPT-4o下降到73.4%——差距高达14.6个百分点。

这个差距不是小的舍入误差。它代表的是"在复杂学术问题上可靠正确"与"在见过这道题时可靠正确"之间的区别。对于基于排行榜分数做模型选择决策的团队来说，这意味着购买了一种并不真正存在的能力。

你花了三周时间精心整理一套高质量的评估集。你编写了测试用例来覆盖产品经理担心的边缘情况，从内测用户中采样了真实查询，并得到了一个团队认可的准确率数字。六个月后，这个数字仍然出现在每周的仪表盘上。你刚刚发布了一次在评估中表现出色的模型更新，用户却在提交工单。

问题不在于模型退步了。问题在于你的评估集几个月前就已经不再代表现实——而没有人注意到。

这种失败模式有个名字：评估集衰退。它几乎发生在每一个生产AI团队身上，而且几乎从不会在用户行为中出现可见损失之前被发现。

在 2024 年底，OpenAI 的 o3 系统在 ARC-AGI 基准测试中获得了 75.7% 的分数——这是一个专门为抵抗优化而设计的测试。AI 研究界欢欣鼓舞。但从业者仔细观察后发现：o3 使用了该基准测试 75% 的公开训练集进行训练，且最高算力配置使用的资源是基准线的 172 倍。这并不是伪装成分数的能力突破，而是伪装成能力突破的分数。

这就是评估悖论（Evaluation Paradox）。一旦某个基准测试成为团队优化的目标，它就不再能衡量其最初设计的目的。古德哈特定律（Goodhart's Law）——“当一个衡量指标变成目标时，它就不再是一个好的指标了”——虽然是在 20 世纪 70 年代的经济政策中提出的，但它却极其精准地描述了 AI 基准测试的现状。

你的 LLM 幻觉率是 3%。但你的用户仍然讨厌它。这并不矛盾 —— 而是衡量标准错误的症状。

幻觉率已成为 LLM 质量的默认头条指标，因为它很容易向利益相关者解释，且在基准测试（benchmark）中计算起来非常简单。但在生产环境中，它与用户真正关心的东西相关性很低：任务是否完成、结果是否值得信赖并足以据此行动、以及系统是否为他们节省了时间？

某医院部署的医疗AI在测试中达到了97%的准确率。它通过了所有内部审查，顺利上线，然后悄然失败——当寄生虫密度低于1%的细胞时，它无法检测出寄生虫感染，而这恰恰是早期干预最为关键的场景。直到一位医生注意到特定患者群体中异常高的漏诊率，问题才得以浮出水面。

这就是长尾覆盖问题。你的聚合指标看起来很好，但系统在最重要的输入上已经损坏。

在AI工作中遇到困难的工程师，最常见的问题不是缺乏技术知识，而是他们一直在问错误的问题。他们想知道的是："这能用吗？"但他们真正应该问的是："这个系统的失败率是多少，这个失败率对于这个使用场景来说是否可以接受？"

这一转变——从二元正确性转向可接受的失败率——是有经验的AI工程师思考问题的核心差异。听起来简单，其实不然。由此延伸的一切都是不同的：你如何调试、如何测试、如何部署、监控什么、以什么为信心基础。没有完成这一转变的工程师会一直在与工具对抗并且不断失败。

你的 AI 功能上线时，任务成功率达到了 91%。你运行了评估，迭代了提示词，并不断调优，直到达到质量标准。然后你面向全球发布了——三个月后，一名东京的用户提交了一个支持工单，称你的 AI “不太理解”他们的输入。你的日本用户一直都在默默忍受一个比英语用户体验差 15–20 个百分点的功能。你的团队中没有人注意到这一点，因为没有人去衡量它。

这就是提示词本地化债务（Prompt Localization Debt）：你为之构建 AI 的语言与用户所使用的其他每种语言之间不断累积的性能差距。它不会在仪表盘上显现，也不会导致服务中断。它只是静悄悄地制造出二等公民用户。

大多数团队上线 LLM 变更的方式，与 2005 年上线 Web 变更如出一辙——跑几个离线评估，说服自己数字看起来不错，然后直接推上去。意外总在周一早上到来：一个通过了所有基准测试的系统提示词调整，悄无声息地破坏了评估集之外 40% 的用户查询。

影子流量就是解决方案。思路很简单：将候选模型或提示词与生产系统并行运行，向其输入每一个真实请求，对比输出结果，同时只让用户接触当前版本。零用户暴露、真实生产数据、上线前的统计置信度。但将这一方法应用于 LLM，需要重新思考几乎所有实现细节——因为语言模型是非确定性的、推理成本高昂，且其输出无法通过简单 diff 进行比较。

大多数团队选择 LLM 的方式，和十年前选数据库一样：看一张对比表，挑出最关心那一列得分最高的，然后开始构建。六个月后，他们要么在迁移，要么疑惑为什么评估结果和用户实际体验截然不同。基准没有错——只是模型选错了。

错误不在于选了错误的模型，而在于还没搞清楚自己的生产任务分布就急着选模型。基准测试的是别人认为重要的东西；你的生产系统有完全不同的分布。这两件事根本不是一回事。