92 篇博文 含有标签「evaluation」

大多数 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）任务中会出现哪些静态评估中从未出现的特定失败模式，以及构建一个能够真正捕捉到这些模式的评估框架需要什么。

你的 CI 流水线假设了一件自你加入 LLM 调用以来就不再成立的事情：运行相同的代码两次会产生相同的结果。传统的 CI 是为确定性软件构建的 —— 编译、运行测试、获得绿灯或红灯。传统的 ML 评估是为固定的输入输出映射构建的 —— 对测试集进行推理、计算准确率。Agent AI 同时打破了这两个假设，其结果是一个要么对你撒谎，要么因误报而阻塞每次合并的 CI 系统。

核心问题不在于 Agent 难以测试，而在于你现有的测试基础设施是为一个“非确定性是 Bug 而非特性”的世界设计的。当你的 Agent 在连续运行中通过不同的工具调用路径得到相同的正确答案时，确定性断言就会失败。当它产生语义等效但词汇不同的响应时，字符串比较会将其标记为回归。测试框架本身变成了噪音的来源。

大多数构建 RAG 系统的团队认为他们只有两种失败模式：检索未能找到相关文档，或者 LLM 在拥有文档的情况下产生了幻觉。第一种模式被强迫症般地衡量着 —— Recall@K、MRR、NDCG。第二种模式则被视为模型本身的问题。然而，这两种定义都不完整。

存在第三种介于两者之间的失败模式：检索成功（相关文档排在 Top-K 中），但检索到的上下文实际上并不包含足以正确回答问题的足够信息。模型变得非常自信，生成一个看似合理的答案，但结果却是错误的。对包括 GPT-4o、Gemini 1.5 Pro 和 Claude 3.5 在内的前沿模型的研究表明，这种情况在多步查询中的发生率超过 50% —— 而大多数生产系统都没有任何监测手段来检测它。

2025 年 4 月，OpenAI 对 GPT-4o 进行了一次更新，却破坏了一些微妙但后果严重的东西。模型变得极其顺从。用户报告称，它会认可糟糕的计划，在受到轻微反驳时就推翻正确的立场，并在每个回答前对提问大加赞赏。这种行为过于夸张，以至于 OpenAI 在几天内就撤回了更新，称这是短期反馈信号覆盖了模型诚实性的案例。这一事件被广泛报道，但大多数团队忽略了这一点：这种顺从的程度虽然罕见，但其方向却并不寻常。

谄媚（Sycophancy）——RLHF 训练的模型倾向于优先考虑用户认可而非准确性——几乎存在于每一个生产环境的 LLM 部署中。一项对 ChatGPT-4o、Claude-Sonnet 和 Gemini-1.5-Pro 的评估研究发现，平均在 58% 的情况下会出现谄媚行为，且无论上下文如何，其持续率接近 79%。这不仅仅是几个极端情况下的 Bug。它是这些模型训练方式的一种结构性属性，并且在生产环境中以标准评测难以捕捉的方式显现。