生产差距:为何 80% 的企业 AI 试点项目无法上线

每个企业的 IT 部门里,都藏着一座项目坟场。

里面埋着 2024 年让指导委员会眼前一亮的演示、用三个精挑细选的问题打败 ChatGPT 的 RAG 原型,以及在沙盒里所向披靡的智能助手。然后有人提了那个真正困难的问题 — 能不能让 4,000 名员工都用?能不能和我们的 ERP 集成?能不能在符合《生成式人工智能服务管理暂行办法》和《个人信息保护法》的前提下,用在真实客户数据上? — 项目随后悄悄进入了"第二阶段"。

第二阶段从未开始。

行业报告对企业 AI 项目失败率的估计因报告而异,大致在 70% 到 85% 之间。我们自己的数字,经过十年在网络安全、ERP、制造和电商领域的架构评审和系统集成实践之后,也基本相当 — 客户请我们去救场的试点项目中,大约 4/5 从一开始就没有走向生产的现实路径。

本文是我们希望每位 CTO 在签 SOW 之前都能读到的现场手册。

什么是生产差距

生产差距(Production Gap)指的是能跑通的演示与你的运维团队能在周日凌晨三点接得住的系统之间的距离。它很少是模型问题,几乎总是架构、数据和运营问题。

flowchart TD
    A["演示<br/>精选输入、开发机"] --> B["POC<br/>单一数据集、单一用户、无 SLA"]
    B --> C["生产差距<br/>多数项目停滞之处"]
    C --> D["试点<br/>真实用户、真实数据、尚无值班"]
    D --> E["生产环境<br/>SLA、可观测性、审计追溯"]
    E --> F["运营<br/>成本管理、模型漂移、变更管理"]
    C -.->|"多数项目止步于此"| G["项目坟场"]

要跨越这条差距,需要回答 7 个让人不舒服的问题。每一个都对应一种我们反复看到的失败模式。

模式 1:没人定义过"正确"是什么

大多数 AI 试点是从"看看它能干什么"开始的。半年之后,指导委员会要看准确率数字,团队却拿不出来 — 因为从来就没有过带标注的评估集,只有几个演示用的 prompt。

症状: 团队凭感觉争论模型是否"够好"。
对策: 先做评估集,再选模型。 200 到 500 个具代表性的问题,配上期望答案,持续打分。没有它,你就没有罗盘;有了它,换模型、调 prompt、改检索都会变成可衡量的工程决策,而不是宗教辩论。

模式 2:把检索当作事后补丁

在 RAG 系统里,LLM 是便宜的部分。检索质量才是整个系统。 然而大多数试点把 90% 的预算花在 prompt engineering 上,只把 10% 留给 embedding、分块和索引策略。

症状: 对源文档里写得清清楚楚的问题,模型也会胡编。
对策: 把检索当作一流工程问题来对待。当语料需要时,使用强大的多语言 embedding 模型(中、日、泰多语料场景下我们默认 multilingual-e5-large)。按语义结构 — 章节、表格、标题 — 分块,而不是按 512 token 的窗口。检索的 recall@k 要独立于端到端答案质量来度量。如果你的评估集上 recall@5 低于 90%,再怎么调 prompt 也救不了。

模式 3:身份、权限和数据边界"待定"

企业数据不是单一语料库,而是上千个语料库,每一个都有自己的 ACL,每一个都受不同制度约束。财务总监不该收到 HR 的答案,外包人员不该看到董事会纪要。无论是《个人信息保护法》(PIPL)、《数据安全法》、《生成式人工智能服务管理暂行办法》,还是《信息安全技术 网络安全等级保护基本要求》(GB/T 22239,即等保 2.0),对此都有明确要求。

症状: 在被压平的测试数据集上表现完美。法务一看到生产架构图就叫停项目。
对策: 把行级访问控制下沉到检索层,而不是应用层。在数据摄入时,给每一个 chunk 打上来源 ACL 的标签;查询时根据用户身份过滤,在 LLM 看到数据之前完成过滤。这件事比听起来难,但没有商量余地。

模式 4:没有可观测性,没有审计追溯

如果你说不清楚上周二下午 14:30,系统对"我们的退款政策是什么"这个问题给出了什么回答,那你拥有的不是生产系统,是法律风险。

症状: 用户投诉 AI 给了错误信息。团队无法复现,无法调查,也无法从事件中学到任何东西。
对策: 记录每一次检索、每一次 prompt、每一次输出、每一笔成本,并配以跨服务一致的 trace ID。和 SOC 团队处理安全事件用的是同一套纪律 — 不可篡改、可查询、按合规要求的期限保留。在 soc-integrator 项目中,我们对 SIEM 摄入采用的可观测性模式,在这里完全适用: 结构化日志、OpenSearch 索引、分层留存策略。

模式 5:成本模型是一厢情愿

每天 50 个查询的试点几乎不产生成本。把同一套架构铺给 4,000 名员工、每人平均 30 个查询、每个查询都带丰富的上下文检索 — 你的月度 LLM 账单将超过整个开发团队的工资。

症状: 推广开始两个月后,财务收回预算。
对策: 从第一天起,按"每次有效操作的成本"建模,而不是按 token 单价。激进缓存。简单问题路由到小型/低价模型,前沿模型留给真正困难的问题。压缩检索上下文 — 大多数试点用 8,000 token 的上下文回答只需要 800 token 的问题。先度量,再优化。成本工程也是工程。

模式 6:围绕单一 LLM 供应商搭建

在 Q1 比测中胜出的模型,到 Q4 不一定还是最便宜、最快,甚至不一定在你的地区可用。供应商锁定是多年期 AI 投资的隐形杀手。

症状: 一次价格调整或地区可用性变化,逼你紧急重构平台。
对策: 从一开始就把模型边界抽象出来。一个轻量的内部网关,提供稳定接口、模型路由规则和回退链路。就像你不会把单一支付供应商硬编码到结账流程里一样,也不要把单一 LLM 硬编码到知识产品里。前期成本很小,期权价值很大。

模式 7:上线之后没有人负责

试点是创新部门的"宝宝"。生产系统需要一个有值班轮换、有运行手册、有预算去处理模型漂移、刷新评估集、按季度重建检索索引的所有者。

症状: 上线半年后,源文档已经变了但没人重新索引,准确率悄悄退化。
对策: 在发布之前就决定谁来运营这套系统。AI 系统需要和其他生产服务相同的运营纪律 — SLO、变更管理、事件响应 — 再加上几个新的(评估集复跑、漂移监控、prompt 版本管理)。如果组织内部没有这种能力,就建设,或者外包。能力齐备之前不要上线。

七种模式背后的模式

注意这份清单上没有什么: 模型选型、微调、向量数据库品牌、agent 框架选择。这些是团队喜欢争论的问题,因为有趣。但真正决定投资是否回本的,是上面那 7 个问题 — 它们枯燥、偏运营、偏架构。

这和我们在交付 SOC 平台时学到的教训(SIEM 是便宜的部分 — 检测工程和调优才是系统),以及在 ERP 集成中学到的教训(连接器是便宜的部分 — 数据契约和对账才是系统),是完全相同的道理。新技术,旧物理。

如果是我们,会怎么做

一个务实的 90 天从试点到生产路径:

不华丽,但有效。

Simplico 在哪个位置

过去十年,我们为中国、日本、泰国以及更广泛的亚太地区客户交付了大量生产级系统 — 关键基础设施的 SOC 平台、制造业 ERP 集成、电商核心系统,以及近年按同样标准搭建的 RAG 与智能体系统。

如果你有一个卡住的试点 — 或者根本不想做一个会卡住的试点 — 我们很乐意帮你看一看。

预约免费架构评审 →

与我们一位架构师进行 90 分钟通话。我们会绘制现状图,坦诚指出生产差距所在,并留给你一份一页纸的推进计划。没有 PPT 表演。

Simplico 是一家总部位于曼谷的工程工作室,专注于 AI/RAG、网络安全、ERP 集成、电商和移动端交付。我们为泰国、日本、中国及英语市场的企业团队提供服务。