160 篇博文 含有标签「evaluation」

构建 LLM 应用的团队总会犯同一个错误：他们等待积累足够的标注数据之后，才肯投入评估基础设施建设。他们告诉自己需要 5000 个样本，或者 10000 个。评估系统始终停留在待办事项清单上，而"感觉不错"的主观判断代替了真正的指标度量。ZenML 对 1200 个生产部署的分析发现，即便是成熟的部署，非正式的直觉判断依然普遍存在——许多团队从未真正建立起系统性的评估机制。

数据量直觉是从经典机器学习时代借来的——在那个时代，更多的标注样本确实能稳定提升模型性能。但对于 LLM 评估，这个直觉基本上是错的。对稀疏基准测试的研究表明，20–40 个精心挑选的样本就能可靠地估算完整基准的排名，而 100 个样本产生的平均绝对误差低于 1%，与使用数千个样本相比相差无几。问题不在于数据量，而在于大多数团队跳过了使小规模评估集值得信赖的结构化流程。

本文介绍这个流程的实际操作方式：如何通过主动学习选取合适的样本，如何用弱监督大规模生成噪声标签，如何借助 LLM 评判者进行冷启动，以及如何判断你的小型评估集何时可以正式使用。

你的评测套件得分 91%，但用户反映系统感觉不可靠。事后复盘发现了问题所在：你同时用 GPT-4o 来生成响应和评分。这个模型在评判自己的镜像，而它喜欢自己所看到的。

这就是裁判模型独立性问题。它比大多数团队意识到的更为普遍，产生的评分虚高幅度足以影响决策，而且修复方法既不复杂也不昂贵。但你必须知道从哪里找起。

一个安全模型在公开基准测试集上取得了 85.3% 的准确率。当研究人员用并非来自公开数据集的新型对抗性提示进行测试时，这个数字跌至 33.8%。该模型并未真正学会如何推理安全性，而是学会了识别评估数据分布。

这就是合成评估数据核心问题所在：当同一个模型家族既生成训练数据又生成测试用例时，通过评估意味着符合某个共同的统计先验，而非真正展示能力。这是一个看起来像质量保证的反馈循环，直到生产流量到来，数字对不上号才会暴露问题。

这种失败是结构性的，而非偶然的。修复它需要的不仅仅是增加更多合成样本。

你的 AI 功能在上线时通过了所有评估。六周后，与其交流最频繁的用户群体的流失率翻了一倍，而你的 CSAT 仪表板却显示出一条无人能解释的平线。提示词（Prompts）没有变，模型没有更换，检索索引增长了，但没人觉得它坏了。上线时的表现第一轮（turn one）很好。真正变质的是在第 400 轮、第 17 次会话、注册三周后发生的事情。

大多数团队的评估套件无法察觉到这种失败。他们测试的是固定数据集上的单轮准确性，如果有追求的话，可能会测试单次会话中的多轮对话，然后就宣布该功能可以上线。真正重要的失败模式——即随着系统积累用户状态而质量下降——存在于评估工具从未设计去覆盖的时间维度中。在记忆研究文献中，研究人员称之为“自我退化”（self-degradation）：在初始阶段之后，受记忆膨胀（memory inflation）和错误记忆累积的驱动，性能出现明显且持续的下降。生产工程师则将其称为留存用户群无声流失的原因。

当你的 LLM 功能上线后，监控面板可能会追踪准确率、延迟和错误率。但几乎可以肯定，它不会追踪方差——即同一个提示每次输出差异有多大。这个盲区，正是生产环境 AI 功能悄然崩溃的地方。

方差决定了你的产品是让用户感觉可信赖还是喜怒无常。一个在评估套件中得分 88% 的功能，如果 40% 的时候返回两句话、60% 的时候输出十个段落，其对用户信任的侵蚀速度，会比一个得分 80% 但表现一致的功能快得多。只优化准确率的团队，解决的是可靠性问题的错误一半。

提示熵预算正是填补这一空白的概念：一种结构化的方法，用于衡量、预算和控制模型在相同输入下的输出分布——就像你在 SLO 框架中对待 p99 延迟或错误预算一样。

演示非常精彩。模型流利地回答了每一个问题，总结文档时没有出现幻觉，并处理了你提出的每一个边缘情况。利益相关者印象深刻。上线日期也就此定下。

发布三周后，准确率徘徊在 60% 左右。用户感到困惑。工单堆积如山。在演示中表现出色的模型，在处理生产环境流量时却步履维艰。

这不是一个关于模型好坏的故事，而是一个几乎每个构建 LLM 功能的团队都会遇到的错配故事：你测试的输入并不是用户发送的输入。

你的团队花了三天时间迭代系统提示词。评估分数从 82% 提升到了 85%。你上线了。三周后，生产指标毫无变化。发生了什么？

简短的答案是：你的评估欺骗了你。不是恶意为之，而是样本量不足加上忽视了方差。在 100 个样本的测试集上提升 3 个百分点，完全在大多数 LLM 系统的噪声底线以内。在这个规模下，你无法区分信号与随机性——但几乎没有人会在采取行动之前做这个数学验证。

这就是 LLM 评估中的统计功效问题，它正在悄无声息地腐蚀大多数 AI 产品团队的迭代循环。

Andrej Karpathy 直言不讳：AI 实验室正在"过拟合"Arena 排行榜。某头部实验室在公开发布前私下评估了 27 个模型变体，只发布了表现最佳的那个。研究人员估计，仅凭选择性提交就可以将排行榜分数人为提高多达 112%。所有人都视为基准真相的众包评估系统已经成为博弈目标——一旦成为目标，它就不再是有效的衡量标准了。

这就是古德哈特定律在发挥作用：当一个指标成为目标时，它就不再是好的指标。这一规律在经济学和政策领域已被充分理解了数十年。在 LLM 工程中，它正在实时摧毁评估套件，而构建这些套件的团队往往浑然不知。

大多数 AI 功能用自然语言描述需求，也用自然语言进行评估。产品经理写下"助手应当给出有帮助的回复，并避免有害内容"。工程师上线了一个 Prompt，演示时的输出看起来符合要求。团队在站会上达成共识，却在上线时产生分歧——边缘案例浮现，不同工程师对同一输出的评判各异，而"有帮助"这个词，不同评审者的理解竟有七种之多。

这不是工具问题，而是翻译问题。规格说明一直停留在抽象层面，评估标准从未被具体化。Spec-to-Eval 是一门在编写第一个 Prompt 之前，将英文需求转化为可证伪标准的方法论——提前做这件事，将从根本上改变迭代速度。

这是一个按计划交付存在缺陷的 AI 功能的典型规格说明书（Spec）：“助手应准确回答客户问题并保持友好的语气。”每一位利益相关者都点头示意，产品需求文档（PRD）获得了批准。六个月后，团队在事后分析中争论 87% 的准确率是否可以接受 —— 而这是一个在发布前没有人想到要回答的问题。

这种失败并非技术性的。模型本身可能没有问题。失败之处在于直接从传统软件引入的需求格式没有为 AI 输出的核心属性留出空间：即它们是概率性的。“正确”不是一种状态，而是一个分布。你无法用一个用户故事（User Story）来定义一个分布。

AI工程领域最诱人的想法，就是通过运行第二个LLM来检查第一个模型的输出，从而让任何LLM系统变得更可靠。从理论上看，这显而易见。但在实践中，那些天真地部署这一模式的团队，往往最终面临的是2倍的推理成本和一种虚假的安全感——他们的"验证"不过是让原始模型的偏差跑了两遍而已。

做得好，双模型验证能带来真实的准确率提升：推理任务提升6–18%，RAG忠实度可测量地改善，代码正确性的问题也能被有意义地发现。做得不好，两个模型对同一个错误答案达成共识，比一个模型出错更糟糕——因为你同时也消除了不确定性信号。

这篇文章就是关于如何识别两者的区别。

AI 功能发布中存在一个重复出现的模式：演示（demo）惊艳全场，功能正式上线，两周内发生了一些灾难性的事情。不是宕机——那些很容易捕捉。而是一些更微妙的事情：模型自信地生成错误信息，成本飙升到预期三倍，或者在真实负载下延迟激增导致功能无法使用。团队手忙脚乱，功能被悄悄禁用，大家一致同意“下次做得更好”。

问题不在于演示做得不好。问题在于演示成了唯一被重视的测试。