从 Demo 到生产环境的“税收”：原型隐藏了 90% 的 AI 开发工作

演示成功了。你输入了一个问题，智能体调用了三个工具，经过多步计划的推理，最后给出了一个让全场人都为之振奋的答案。有人说：“上线吧。”三个月后，你的产品依然没有上线，而且没人能解释时间都去哪儿了。

时间都花在了这里：演示只占了 10% 的工作，它只是大脑。剩下的 90% 是管道工程——那些在正常运作时无人喝彩，一旦出故障就是灾难性的评估（Evals）、护栏（Guardrails）、可观测性、成本控制和备用路径。这 90% 就是“从演示到生产的税”，而大多数团队在做预算时，却把它当成了一个可以忽略不计的舍入误差。

数据说明了另一番景象。MIT 2025 年的一项企业 AI 研究发现，95% 的生成式 AI 试点项目未能产生可衡量的损益（P&L）影响。另一项分析则更加直截了当：企业每启动 33 个概念验证（PoC）项目，只有 4 个能进入生产阶段。这意味着夭折率高达 88%，而死因几乎从未出现在模型身上，而是演示让你跳过的所有环节。

为什么演示会欺骗你

原型是一个装扮成产品的受控实验。你挑选了输入数据，你运行了三次并展示了成功的那一次。工具是健康的，语料库是干净的，用户说的话也完全符合你训练他们的预期。这一切在接触到生产环境时都会土崩瓦解，因为那里的输入会因各种意外而具有对抗性，且出错的代价是真实存在的。

最残酷的部分在于数学逻辑。假设你的智能体在每一步的可靠性是 95%——对于调用工具的 LLM 来说，这已经是非常优秀的表现了。但如果你将这 10 个步骤串联起来，你的端到端成功率就是 0.95^10，大约只有 60%。演示通常只是一个三步的任务，所以你看到了 86% 的成功率并认为它很出色。而生产环境通常是平均十步的任务，现在每五个会话中就有两个会在中间某个地方失败。性能并没有变差，只是你无法再隐藏这种复合效应了。

而且，失败的形式并不像你测试时那样是清晰的错误，它们看起来往往是这样的：

• 迷之自信地选错工具：大约每 20 次调用中就有一次，当用户询问远足路线时，模型会伸手去调酒店预订 API，因为嵌入向量（Embeddings）将“旅行”放在了“预订”附近。它毫不犹豫，直接下单。
• 缓慢的依赖项：在演示期间 3 秒内返回的搜索 API，在负载下需要 30 秒。智能体不会等待——它会超时并幻觉出一个看似合理的结论，或者陷入重试循环，让你的 Token 账单翻三倍。
• 部分成功：由于上游的一个 bug，分页 API 只返回了 2 个结果而不是 15 个。智能体完全不知道自己是在基于碎片进行推理，因此它会根据仅有的三分之一数据生成一个看似完整的答案。
• 状态漂移：在一个长任务中，智能体在第一步选择了巴黎，在第三步预订了飞往戴高乐机场（CDG）的航班，到第五步却推荐了一家伦敦的餐厅。每一步在局部看来都是合理的，但整个轨迹毫无逻辑。

你无法通过提示词（Prompt）工程来解决这些问题。这些是系统性故障，而系统性故障需要系统工程来解决。这就是那份“税”。

评估：看起来可选但实则必不可少的部分

这份“税”中最大的单项开支是评估（Evaluation），而且它是团队最先砍掉的，因为它感觉就像测试——而“我们以后再加测试”是每个工程师都撒过的谎。

但 LLM 评估套件并不是普通的测试套件。它是你每天回答核心问题的唯一工具：我刚刚做的更改是改进了产品，还是悄悄搞砸了它？没有它，每一次提示词修改、模型升级和检索优化都像是一场你看不见结果的掷硬币。你发布了产品，感觉有些地方变差了，但你无法判断是因为你的改动、模型供应商的静默更新，还是你的错觉。

生产级版本包含两个部分。**离线评估（Offline evals）**在 CI 环境中运行，针对一组包含几百到几千个带标签示例的版本化数据集，按标准评分；当通过率回退时，它们会阻断 Pull Request。**在线评估（Online evals）**对 5-20% 的实时流量进行采样，为每个请求附加质量分，并在滚动平均值出现偏移时提醒你——下降 2% 需要“去查看”，下降 5% 则需要“呼叫运维”。演示阶段这两者都没有，你只是盯着屏幕，凭感觉判断输出是否良好。这在用户超过一个人的时候是无法扩展的，而那唯一的一个用户就是你自己。

尽早构建这个体系，因为它是所有其他工作的支架。如果你无法衡量备用模型是否更差，你就无法安全地添加它。如果你无法看到廉价路由对质量的影响，你就无法优化成本。评估能让你将“感觉还行”转化为一个你可以辩护的数字。

加载中…