为什么你的 AI 演示总是优于最终上线表现

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

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

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

经过筛选的输入问题

演示、试点（Pilots）和内部评审都有一个结构性缺陷：它们运行在有人挑选的输入上。无论是由产品经理设计展示查询，还是工程师从数据库中提取“代表性”示例，或者是团队手动测试能想象到的场景，选择过程在进行任何评估之前就已经引入了偏见。

生产环境流量与之完全不同。真实用户发送的查询带有拼写错误、矛盾的约束、指代前三条消息上下文的模糊代词，以及模型从未被设计去回答的问题。他们上传的文件中扫描文本充满了 OCR 噪声，粘贴的表格带有合并单元格，并提出了一些假设模型记得它从未被告知过的事情的后续问题。

一个在你精心挑选的试点数据集上得分 95% 的模型，在实际的生产输入分布中，准确率极有可能掉到 65%。这种差距并不总是如此巨大——但当你的产品团队告诉利益相关者预期会有“接近人类的准确率”时，即使是 15 个百分点的下降也是灾难性的。

背后的数学逻辑是残酷的。你的评估数据只是一个样本。如果这个样本不是来自真实的生产分布，你的准确率数值就不是对生产表现的预测，而只是对模型处理你恰好想到的特定案例能力的测量。

为什么试点会产生系统性误导

试点在人工环境下能够成功，但这些环境在你广泛发布的那一刻就会消失。三个条件的结合会夸大试点的指标，而这些指标往往需要细致的监测才能被察觉。

有利的用户选择。 试点通常在爱好者中运行——这些人早早报名尝试新事物，他们足够了解系统，能够以有帮助的方式表述查询，并以宽容的态度容忍瑕疵。这些用户不能代表完整的用户群。当你进行正式发布时，你面对的是怀疑论者、有着异常复杂需求的专业用户，以及通过不同于你设计的语境发现该功能的用户。

狭窄的任务范围。 在试点中，任务通常被定义得足够窄，以至于大多数输入都在分布范围内。一个处理保修问题的客户服务 AI 试点，不会遇到产品广泛上线后用户会问到的所有问题：退货纠纷、功能对比、对退货部门的投诉、法语提问，甚至是关于你两年前停产的产品的问题。

隐形的化人工干预。 试点中通常会有人——客户成功经理、Slack 上的工程师、界面中的提示——在悄悄地为失败做补偿。模型输出了错误的内容，人类在用户注意到之前将其修正，而成功指标从未记录下这一事件。这种规避手段伪装成了准确率。

在正式发布时，这些条件都不复存在。

复合错误陷阱

对于单轮对话功能，分布不匹配虽然痛苦但尚在可控范围内。对于多步工作流和智能体（Agents）来说，这则是灾难性的。

考虑一个在评估集上每步准确率为 90% 的智能体。在一个 10 步的工作流中，复合后的端到端成功率大约只有 35%。但那个 90% 的每步准确率是在你精心挑选的评估输入上测得的。如果生产环境的输入更难，单步准确率下降到 80%，那么 10 步的完成率就会跌至 11% 以下。

这种机制不仅仅是乘法。早期步骤的错误会污染后续步骤的上下文。第 2 步中提取的错误实体会毒害每一个引用它的下游工具调用。到第 7 步时，智能体正信心十足地针对错误目标执行正确的动作序列，而你的监控层在整个过程中记录的却是“无错误”。

这就是为什么在有利的分布上测量的单步准确率对于智能体系统具有极大的欺骗性。问题不在于模型是否能一步步处理你的示例输入，而在于当第 1 步的输入与你的训练和评估数据完全不同时，它是否能在整个工作流中保持连贯的状态。

在发布前诊断分布差距

没有单一的测试可以弥补这一差距，但有一种方法论。它涉及在看到生产流量之前，就有意识地去理解它的样子——并针对这种流量进行压力测试，而不是针对你希望收到的输入。

尽早收集对抗性输入。 在进行任何内部评审或试点之前，花时间生成你主动不想处理的查询。询问客户支持团队他们收到的最难的请求是什么。从 AI 正在取代的任何现有基于规则的系统中提取失败案例。找出那些导致之前原型崩溃的查询。如果你有任何相关的生产数据——来自类似的功能、搜索日志、支持工单存档——从中挖掘分布末端的输入。

从结构上分析你的生产流量分布。 即使在发布之前，你也可以对分布进行推理。用户会用什么语言书写？文档长度的范围是多少？有多大比例的用户会粘贴结构化数据（表格、JSON）而不是正文？用户会有多频繁地询问该功能并未设计的超纲问题？量化这些维度，然后构建一个按比例覆盖它们的评估集，而不仅仅是理想路径（Happy Paths）。

在测试集中加入现实世界的混乱因素。 引入拼写错误、不完整的句子、模糊的引用以及混合语言的输入。使用低分辨率扫描的文档、被截断的上下文和冲突的指令进行测试。目标不是为了模拟病态输入而模拟，而是在用户发现之前，找出在你生产流量的第一周就会出现的失败模式。

在全面发布前使用影子流量（Shadow Traffic）。 如果你有一个处理相同请求的旧系统——哪怕只是一个基于规则的备选方案——记录其输入样本并在离线状态下运行你的模型。这是在不让用户接触新系统的情况下，获得最接近真实分布的方法。通过真实历史输入的影子流量测得的准确率，比任何内部构建的评估集都更能预测生产环境的表现。

定义输入准入标准，而不只是输出质量指标。 在发布之前，明确列举你的模型设计用于处理的输入类型以及不处理的类型。这会迫使你明确业务范围。它还为处理生产中的分布外请求创建了一个决策框架：它们是获得备选回复、人工介入，还是一个得体的“我无法处理此问题”？最糟糕的生产故障往往发生在为一个输入分布设计的系统接收到其他内容，并自信地给出一个错误答案时。

识别发布前的预警信号

有几个信号可以可靠地表明，你的试点准确率数值并不能预测生产环境的表现：

• 评估集是由你自己的团队构建的。如果构建系统的人同时也选择了测试用例，那么这些用例反映的是系统设计之初所能处理的输入，而不是用户实际发送的输入。
• 你的评估集中没有模型目前会出错的示例。如果模型在发布前的测试集上达到了 97% 的准确率，那么这并不是一个全面的测试集 —— 它只是模型已经解决的问题集合。
• 你的试点用户是资深用户或早期采用者。首批试用你的功能的 100 个人并不能代表你即将面向的全体用户群体。
• 你还没有使用模型设计用途之外的输入进行测试。每个生产系统都会收到“超纲”查询。如果你没有衡量模型在面对这些查询时的表现，你就不算真正了解它。
• 没有人问过：“该系统可能收到的最难输入是什么？”如果这个问题没有得到认真对待，那么答案就不会被纳入你的评估方法论中。

发布前的正确目标

发布前测试的目标不是为了找到你想汇报的分数，而是为了找到你应该预期的分数分布，包括尾部情况。

一个平均准确率为 85% 但带有长尾灾难性失败的模型，与一个准确率为 80% 但方差较小且失败模式可预测的模型，具有完全不同的风险特征。平均指标掩盖了分布情况，而分布情况决定了你的发布是成功的，还是一场突发演习。

构建能够提供该分布的评估基础设施。以对抗性的方式采样输入。针对你能找到的最混乱的数据进行压力测试。运行影子流量。明确定义范围。将试点指标与生产预测之间的差距视为一个需要解决的衡量问题，而不是一个可以信任的预测。

在评估中的输入与用户发送的输入匹配之前，Demo 的效果总是会比正式发布看起来更好。这种差距是你在发版前可以刻意去弥补的。