企业AI试点项目为什么会在生产之前停滞不前：问题不在模型，而在其周围的环境

模型从来都不是难点。从内部来看，生产的成败取决于模型周围的层：检索、接地、路由和评估。

每一项针对企业AI的重大调查都描述了同一个瓶颈：组织可以访问模型、运行试点项目，并演示出令人印象深刻的东西，但几乎没有任何一个项目能够进入生产阶段。这些报告从外部描述了这个差距，通过高管回答问卷。这是从内部的视角：从构建项目中，试点项目要么进入生产阶段，要么悄悄地消失。

每个人都在衡量的差距

数字已经变得熟悉。 德勤的企业AI现状报告发现，AI的访问几乎是普遍的，但只有大约四分之一的组织能够将40%的实验推向生产，而且大约五分之一的组织报告了自治代理的成熟治理。 MIT的Project NANDA更直接地指出：在数百个部署中，绝大多数产生了没有可衡量的财务回报。 Gartner预测，大量生成式AI项目将在概念验证阶段后被放弃，理由是数据质量差、成本增加和商业价值不明确。

将这些发现堆叠起来，一个单一的形状就会出现。瓶颈不是访问能力强大的模型。这个问题已经解决了。瓶颈是模型在演示中有效和系统在生产中有效之间的距离，每次、每个用户、在真实负载下、有错误的真实后果。

需要明确说明的一个问题是：很多试点项目之所以没有上线，并不是因为技术原因，而是因为没有真正的商业案例、没有可用的数据、没有高管支持，或者成本没有被任何人建模。把这些情况放在一边。下面讨论的是那些技术上是真实的、演示令人信服、并且有真正的使用案例支持的试点项目，但仍然在进入生产阶段时停滞不前。对于这些项目，决定因素几乎从来都不是模型。

调查数据无法告诉我们的，是什么真正弥合了这个差距。答案不在问卷中，而在工程决策中：在演示令人印象深刻之后，在系统被信任使用真实客户之前的工程决策。

模式：决定性的解决方案几乎从不在模型上

在我们可以讨论的企业AI项目中，一个一致的模式存在：当一个停滞的试点项目终于进入生产阶段时，促成这一结果的变化很少是更好的模型。它是模型周围的层：信息如何检索和接地，输出如何在到达用户之前被检查，工作如何被路由到正确的模型，而不是最强大的模型，以及整个系统如何被持续评估。

我们称之为“马鞍”层。从实际角度来看，一个代理是一个具有工具访问权限的模型，而马鞍是所有管理模型检索上下文、使用这些工具以及对其产生的内容负责的东西：检索、接地检查、模型路由、防护栏和评估。这些组件不在孤立中工作。你必须故意地将它们组合起来，针对特定的使用案例。这种组合的学科就是我们所说的代理马鞍，它是生产就绪性真正赢得或失去的地方。

这重新定义了概念验证陷阱。团队停滞不前，因为他们不断优化已经有效的部分。他们交换新的模型，重新设计提示，并等待下一个前沿版本发布，而真正的故障点则位于系统的其他部分，演示永远不会强调这些部分。

接地，而不是更聪明的模型，是使代理足够安全以部署的原因

考虑一个 我们在保险领域构建的推荐和咨询助手，这是一个领域，自信地错误的答案不是故障，而是责任。这种情况下的第一直觉是伸手去拿最有能力的可用模型，并假设能力买来安全性。它不这样工作。更流畅的模型产生更令人信服的幻觉，在一个受监管的环境中，这更糟糕，而不是更好。

使系统能够部署的，是马鞍：一种检索设计，仅从受管理的、租户安全的源中提取；接地检查，验证生成的声明与这些源之前任何内容到达用户；以及一个验证步骤，宁愿放弃也不愿断言不支持的东西。结果是，相对于仅LLM基线，幻觉减少了80%至90%，接地准确率超过95%，同时保持了低于2秒的P95延迟，因此安全层从不使系统感觉慢。

对于任何人来说，安全性与模型选择等同的反直觉教训：接地和验证层是治理。政策文件和批准委员会很重要，但它们不会阻止模型在推理时编造事实。检索和验证马鞍可以做到。在我们的部署中，技术接地层是真正的治理机制：这是“AI不能编造东西”的地方，停止成为原则，成为系统的强制属性。

模型路由，而不是模型选择，是决定AI成本的地方

试点项目死亡的第二个地方是预算审查。系统可能运行得很好，但仍然会在每个令牌的经济学被乘以成千上万的用户和数十个使用案例时被取消，当总拥有成本问题在前期没有被建模出来时。

在这里，选择一个强大的模型并将所有内容路由到它的直觉也是错误的。大多数企业工作负载都是混合的：大量请求是常规的，少量请求是真正具有挑战性的。将每个请求发送到前沿模型意味着为_triage_工作支付前沿价格，而较小、较便宜的模型可以完美地处理它。

在 我们运行的从第三方LLM API迁移到Amazon Bedrock的过程中，收益来自于重新架构模型层，而不是交换模型。将每个任务路由到适当的模型层，结合Bedrock原生成本和治理控制，实现了42%的AI基础设施成本减少和60%更快的合规内容生成，没有重建应用程序。

扩展这一原则，它会带来复合效果。一个分层的“顾问”架构，廉价的模型处理大部分请求，前沿模型保留用于真正需要它们的案例，将路由从一次性节省转变为结构性节省。

这一模式已经将企业AI成本降低了60%至80%，在一些部署中降低了85%。重点不是头条百分比；而是AI系统的成本由其架构决定，而不是选择哪个模型。

为什么这在调查数据中不可见

这在调查中没有清晰地体现出来，因为调查询问高管关于结果的问题，而不是询问工程师关于机制的问题。“你的试点项目是否进入生产？”是一个高管可以回答的是/否问题。“是什么具体使其进入生产？”是一个只有构建团队才能回答的问题，答案很少是“我们找到了一个更好的模型”。几乎总是某种版本的“我们修复了模型周围的层”。

这种不匹配解释了概念验证陷阱的奇怪持续存在。行业不断诊断模型问题并购买模型解决方案，而实际的约束位于检索、接地、路由和评估中：演示永远不会展示的、基础模型发布广告永远不会宣传的无光泽的管道。

这也解释了为什么治理和交付速度不是人们所认为的对立面。常见的叙述将治理视为制动器，阻碍发布。在我们的经验中，它更接近于相反：使系统可治理的接地和验证工作也是使其值得信赖到可以面向真实用户的工作。通过在马鞍层完成，治理不是减慢构建速度的东西。它是允许构建发布的东西。

如果你的试点项目停滞不前，这意味着什么

如果你有一个生成式AI项目正处于概念验证的炼狱中，你可以做的最有用的事情是抵制查看模型的冲动。模型是最有可能已经足够好的部分。相反，查看模型周围的层：

• 检索和接地：系统是否从受管理的、可验证的源中回答，还是从其训练中即兴发挥？
• 验证：输出是否在到达用户之前被检查，还是模型的信心直接通过？
• 路由：每个请求是否支付前沿价格，还是工作被匹配到可以很好地完成它的最便宜的模型？
• 评估：质量是否被连续测量到您自己的基准，还是只在演示中验证一次，然后再也没有验证？

2026年从试点项目转向生产的组织，并不是那些拥有最好的模型的组织。每个人都拥有这些。他们是那些理解模型从来都不是难点的人，并且将工程努力投入到马鞍中，也就是生产实际上赢得的地方。