131 篇博文 含有标签「evaluation」

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

发布三周后，准确率徘徊在 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）惊艳全场，功能正式上线，两周内发生了一些灾难性的事情。不是宕机——那些很容易捕捉。而是一些更微妙的事情：模型自信地生成错误信息，成本飙升到预期三倍，或者在真实负载下延迟激增导致功能无法使用。团队手忙脚乱，功能被悄悄禁用，大家一致同意“下次做得更好”。

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

你的 AI 产品在评估套件中获得了 82% 的分数。你向 40 个国家发布了产品。三个月后，法国和德国用户报告的质量与英语用户相似。印地语和阿拉伯语用户则悄悄停止了使用该功能。你的综合满意度评分几乎没有波动 —— 因为英语用户主导了指标池。悬崖一直都在。你只是没有测量它。

这是大多数发布多语言 AI 产品的团队都会遇到的典型情况。质量差距并非微乎其微。像 QwQ-32B 这样的最先进模型，在英语推理基准测试中分数为 70.7%，但在斯瓦希里语中则下降到 32.8% —— 这是 2025 年测试的最佳模型在性能上的 54% 相对崩溃。而且这还是 最佳 模型。这种差距并不会随着模型变大而消失。它在高资源语言中会缩小，但在其他语言中依然很大。

大多数团队把点赞/踩的按钮当作AI质量循环的基础。思路很清晰：用户对回复评分，你积累评分，然后改进。但在实践中，这意味着你需要等整整一个月，才能检测到第一天就已经发生的质量回退。

数字是残酷的。生产环境中LLM应用的显式反馈率在所有交互的1%到3%之间。对于一款B2B产品在第一年的正常规模——每日活跃用户1000人——这意味着每天只有10到30个评分样本。以统计置信度检测5%的质量变化大约需要1000个样本。你要等30到100天，改进循环才有足够的有意义数据来运行。

多智能体系统（Multi-agent systems）是基于一个承诺而诞生的：多个并行的专业化智能体协同工作，产生的结果会优于任何单个智能体。但这个承诺隐藏了一个前提——当智能体给出不同答案时，你知道如何调解它们。大多数团队在发现自己无法调解时，往往为时已晚。

天真的做法是取输出的平均值，或者选择多数票答案，然后继续。在实践中，如果所有智能体共享相同的训练分布，多智能体系统会通过多数表决放大它们的共同错误，而不是抵消错误。一个总是听从最有信心智能体的系统，会盲目跟随那个最过度自信的智能体。而一个将所有分歧都交给 LLM 裁判（LLM judge）处理的系统，会继承该裁判的 12 种已被记录的偏差类型。仲裁问题比看起来要难，如果处理不当，你可能会在一周内遇到四次生产事故。

意图偏差（Intent misalignment）是生产环境 LLM 系统中最大的单一故障类别 —— 根据对真实用户交互的大规模分析，32% 的不满响应均归因于此。这既不是幻觉，也不是拒绝回答，更不是格式错误。它是指模型正确地回答了问题，却完全偏离了用户的实际需求。

这就是意图鸿沟（intent gap）：即用户“所说”与“所想”之间的距离。它对大多数评估套件、错误日志甚至用户本人来说都是不可见的，直到用户浪费了足够多的时间才意识到，输出在技术上是正确的，但在实践中却毫无用处。

一个在 SWE-Bench Verified 上得分 75% 的模型，在处理需要人类工程师花费数小时才能完成的任务时，其得分会降至 25% 以下。同样一个能够稳定处理单轮问答的智能体（agent），在被要求协调十几个步骤以实现一个开放式目标时，可能会陷入语无伦次的循环、幻觉化工具输出，并忘记其最初的目标。基准测试数据与生产环境表现之间的差距并非噪声——它是结构性的。理解这一点，是交付有用产品与交付仅在演示（demo）中好看的产品之间的区别。

本篇文章讨论的就是这个差距：它为何存在，在长程（long-horizon）任务中会出现哪些静态评估中从未出现的特定失败模式，以及构建一个能够真正捕捉到这些模式的评估框架需要什么。