95%企业GenAI试点失败根因：数据层而非模型

MIT 发现，95% 的企业 GenAI 试点项目没有产生可量化的 P&L 影响，只有 5% 达到了大规模生产。这些失败几乎都不是模型本身的失败。

我们被召去处理的停滞试点，从内部看都是一模一样的。有人在提示词和模型选择上花了三个月，但没有人看过为它提供数据的管道。当我们追溯一个糟糕的输出时，它往往是脆弱的查询在拉取过时或错误的记录——模型在垃圾数据上工作得完全正确。修复管道，同一个模型突然就看起来聪明了。

模型是内核。集成层是围绕它的操作系统，而试点正是在那里死掉的。Gartner 预测，2025 年全球 GenAI 支出将达到 6440 亿美元，同比增长 76.4%，而与之对应的是那 95% 的失败率。大笔投入并不是安全投入。

Demo 到生产的悬崖

Demo 运行在干净的、手工挑选的数据上。生产环境不是。这就是全部的差距所在，而且一旦 Agent 获得了写访问权，它就有三个具体的失败模式：

失控成本。 Agent 卡在重试循环中，无人看管地运行数小时，在有人发现之前就烧掉了数千美元的 API 费用。

提示词注入。 头号 Agent 风险，而且不是假设——一项 arXiv 研究通过叠加多层防御，将攻击成功率从 73.2% 降到了 8.7%。一次成功的注入在几分钟内就能泄露一个 secret。

二次方 token 增长。 成本可能随上下文长度的平方而非线性扩展。"只需添加更多上下文"很快就会变得昂贵，而且在大约超过 40% 上下文填充标记后，许多模型的准确性反而会下降。更多上下文不是免费的，它可能让系统变笨。

这三个都不是模型质量问题。它们都是控制问题，而 NIST 的 GenAI Profile（AI 600-1）将这些全部列了出来。

在任何东西获得写访问权之前，问三个问题

向任何合作伙伴、内部团队或你自己问这些问题：

谁设定了阻止失控 Agent 的熔断器，谁设置了支出上限？

当 Agent 向生产数据写入时，谁拥有审计追踪？

什么操作需要人工审批才能让 Agent 执行？

这三个问题的干净答案，比任何基准测试都更能说明问题。在授予写访问权之前建立熔断器，而不是在第一次事故之后。

Demo 说"我们用 AI"。生产系统命名它的模式，每一种都有你继承的注意事项

Self-RAG — 模型重写查询并检查自己的检索。适合处理混乱的查询。额外的模型调用会增加延迟。

Corrective RAG — 过滤或拒绝弱检索片段。当错误上下文的代价很高时使用。需要一个调优好的相关性评分器。

Adaptive RAG — 对简单和复杂查询进行不同路由。路由逻辑本身就是一种复杂性。

GraphRAG — 在知识图而非扁平文本上进行检索。在关系数据上表现强劲。图构建和维护是真实的、持续的工作。

Agentic orchestration — 有边界的工具调用和控制流。不受信任的输出永远不应该直接调用工具。

这些堆叠成 retrieve、rank、generate、verify。每个层的延迟都会叠加，所以缓存和精准的分块不是你要推迟的优化。

你怎么知道它有效，而不是听起来很自信？

Evals。 这是团队跳过的阶段，也是试点死在真实数据上的原因。

当你可以指定目标并根据它验证输出时，自动化才是安全的。没有验证，就没有安全的自动化——你在凭感觉发版。能够经受住生产数据接触的渐进路径：

聚焦一个可衡量结果的窄范围工作流。

在混乱的生产数据而非干净样本上验证它，这样你才能发现它实际在哪里失败。

添加 evals 和 guardrails，让失败在用户发现之前被捕获。

在真实负载下强化延迟、成本和边缘情况。

移交给有文档的系统，并准备好回滚。

第五步比听起来更重要。模型在会话之间对你的系统没有记忆，所以知识必须存在于文档和代码中，而不是在一个工程师的脑海里。"完成"意味着它在六个月后仍然有效。

它花多少钱，预算实际上漏在哪里

概念验证大约 5 万美元，大规模生产系统加合规大约 200 万美元以上。但构建很少是超预算的原因——运行时才是。二次方 token 计费和云资源冲击，即用静态数据中心思维运行弹性 AI 基础设施的惩罚。在扩展之前正确调整计算规模，而不是之后。

最昂贵的 AI 代码不是坏掉的那种。它是那种几乎能工作的——它能运行，代码审查看起来也没问题，而它向错误的数据写入内容，同时屏幕看起来是正确的。这对试点本身也是真的。它 Demo 起来很漂亮但没有任何回报，而原因从来不是那个每个人都花了三个月调优的部分。

完整分解——集成模式、NIST AI RMF 映射、以及如何评估交付合作伙伴：teamvoy.com/blog/generative-ai-implementation-services

Written by Taras Voytovych, Founder & CEO at Teamvoy. More engineering writing at teamvoy.com/blog.