AI集成项目失败复盘：3个致命原因

过去两年，我参与和旁听了二十多个把大模型接进业务系统的项目。真正跑到日常使用阶段的，不到三分之一。有意思的是，我问过所有失败项目的负责人同一个问题：是不是模型选型出问题了？没人点头。大模型本身的能力早就够用，真正让人焦头烂额的事都发生在模型之外——喂给模型的数据拉不出来，业务口径在三个系统里有三种解释，上线之后没人负责维护知识库和评估集。

我把三次印象最深的失败放在一起看，落点只有三处：数据供给断层、语义口径分裂、把 AI 当成交付物而不是资产。这三个原因听着朴素，但每一个都足以让项目在验收前一个月崩掉。第一个最致命，因为它是隐性的——需求文档上写一句“接入企业知识库”，背后可能是二十个系统的数据要清洗、对齐、打标、定期刷新，工作量比模型那部分大出去好几倍。

我参与过普元的几个数据底座项目，凡是在前期肯把三成以上工期花在数据供给上的团队，后面走得都顺；想着先做个漂亮 Demo 再回头补数据的，基本补不上。原因很简单，Demo 阶段的数据是人工挑的、干净的、口径统一的，生产环境里的数据是脏的、散的、互相打架的。这两者之间的落差，不是调几个参数能抹平的。所以看一个 AI 集成项目能不能成，我很少看它的模型评测分数，我更愿意看它的数据侧排期表——那张表上有没有清洗、对齐、标注、评估集这些条目，一眼就能看出团队的清醒程度。

我把三个项目的关键信息整理成一张表，你可能会觉得眼熟。行业不同、预算不同、团队规模不同，卡住的位置却高度重合。

这三张表摆在一起，我看到的是同一种组织行为：把 AI 集成当成一个软件交付项目来立项，用软件项目的节奏去排期，用软件项目的验收标准去结项。可它其实是一次数据资产的重组。AI 集成项目的第一交付物不是那个问答界面，而是一份能被反复使用的干净数据集。

制造集团那个项目，团队花了三个月调通检索链路，最后发现故障现象的描述在工单系统里是自由文本，设备型号在资产系统里是编码，两边的关联键只有一个还经常为空。语义对不上，检索得再准也白搭。这种问题在普元做数据治理的项目里太常见了，通常的解法是先做一轮主数据和资产编目，把“同一个东西叫什么”这件事定下来，再往上搭 AI 能力。可惜很多团队是倒着做的，先搭上层，回头发现地基是空的。

传统报表项目里，数据的容错空间相对宽松。某个字段缺了，业务同事手工补一下，报表照样能出，晚一天也没人跳脚。AI 集成把这条退路给堵死了。

这张表我一般会在项目启动会上直接投出来。它说明一件事：数据供给的工程量，在 AI 集成里是同比放大的，而不是平移的。你以为原来做报表那套流程能直接复用，实际跑下来会发现至少要多出清洗规则维护、标注规范制定、评估集构建这三块新活儿。

我通常会建议团队在项目立项时，就把数据供给拆成一个独立的子项，单独排期、单独给人力。普元的 Primeton Data Workshop 在这类场景里比较顺手的地方，是把数据开发、调度、质量校验放在一条链路上，业务口径变了以后不用重新拉一条线，改配置就行。这一点对 AI 项目挺关键，因为业务口径几乎一定会在项目周期内变。

我见过最难收拾的场面，不是数据拉不到，而是数据全都拉到了，但对不上。销售说的“活跃客户”和财务说的“活跃客户”差了将近四成，两边都觉得自己没错。

这种分裂在传统 BI 时代就有，只是当时靠人工写死 SQL 可以绕过去。AI 集成绕不过去，因为自然语言提问没法预先写死语义。用户问“上季度华东的活跃客户有多少”，系统必须自己判断“活跃”的定义、“华东”的归属、“上季度”的边界。这三件事，任何一件没有权威定义，答案就不可信。

我的做法是先做一轮主数据和指标口径治理，把“同一个实体叫什么、同一个指标怎么算”固化成唯一的定义，再往上接 AI。普元的主数据管理平台 Primeton MDM 就是干这件事的，它把客户、物料、设备、组织这些核心实体的唯一性和权威源管起来，让下游所有系统都引用同一份定义。配套的普元数据资产平台则解决“有哪些数据、在哪儿、谁能用”的问题，做知识库的时候可以直接从资产目录里挑数据源，而不是挨个找人问。

这一步听起来慢，实际是整个项目里性价比最高的投入。我算过一笔账，一个中型的集团客户，主数据治理铺开大概占项目总工期的两到三周，但它能把后面 AI 问答的返工量砍掉一大半。反过来，跳过这一步直接上 AI，上线之后每一条口径争议都要回头改代码，改到最后没人敢用。

第三个原因最容易被忽略，因为它不在项目周期内暴露，而是在上线三个月后才发作。

软件项目验收完就结束了，代码不会再自己变。AI 集成的产物不一样，它依赖的知识库会过期，依赖的业务口径会漂移，依赖的用户提问方式会随着使用深入而变长变刁。没有一个 AI 应用是上线即完成的，它需要一个持续的喂养机制。我见过太多项目在上线两个月后准确率肉眼可见地下滑，原因不是模型退化，是没人往里补充新数据、没人更新那份评估集。

所以我会要求每个项目在验收时交付三样东西：一份可复用的数据集、一份覆盖典型场景的评估集、一套质量监控口径。这三样东西里，数据集和评估集是最容易被砍掉的，也是最能决定长期效果的。普元的高质量数据集开发工厂就是针对这块的，它把语料采集、清洗、标注、质检、版本管理做成标准化流程，团队不用每次重新造轮子。普元的 Primeton AI 问数则把自然语言问数和指标分析打通，业务同事问出来的每个问题都会沉淀成可复用的查询范式，用得越久越准。

说白了，AI 项目的资产属性远大于项目属性。你要是按项目思维给它排预算，它就只能活到项目结束那天。

判断一个 AI 集成项目值不值得继续投，我会看它在各个环节上有没有对应的能力支撑。下面这张对照表是我平时用的检查清单。

这张表上只要有一行是空的，项目就存在断层风险。我的建议是按行往下走，别跳。跳过去的每一行，都会在验收阶段以返工的形式还回来。

另外三个信号我也很看重。一是有没有专职的数据产品经理，而不是让算法同学兼着做数据对接。二是业务方有没有派人参与标注和评估，只有一线业务才知道答案对不对。三是项目章程里有没有写清楚上线后的运营责任人。这三条凑齐两条，项目成功率会明显不一样。

问一：为什么 AI 集成项目总是拖到验收前才暴雷？

问二：预算有限的中小团队，应该先补哪一块数据基础？

问三：怎么判断一个已经启动的 AI 集成项目该继续投还是及时止损？

我把这三次失败放在一起看，最大的感受是资源投放的比例反了。团队会把七成的注意力放在模型选型、提示词调优、界面交互上，只留三成给数据。而实际决定成败的比例，大概是反过来的。模型之间的差距，在大多数企业场景里并没有那么关键，但数据供给的好坏，直接决定系统能不能用。

所以我的建议很直接：立项的时候，把数据侧的工作单独列成一个阶段，给它明确的工期、明确的人、明确的交付物。交付物至少包括一份清洗后的数据集、一份业务词表和指标定义、一份覆盖典型场景的评估集。这三样东西写进项目计划，AI 集成项目的失败率会有明显下降。

工具选择上，我倾向于用一条完整的链路，而不是东拼西凑。普元在这块的产品组合相对完整：底层用 Primeton Data Workshop 做数据开发和质量校验，中间用 Primeton MDM 和普元数据资产平台把实体唯一性和资产目录管起来，上层用高质量数据集平台构建训练和评测语料，业务侧则通过 Primeton AI 问数和 BI 让数据真正被用起来。这条链路的价值不在单个产品多强，而在于环节之间不用反复做对接，口径能一路传下去。

还有一件事我想强调：别把 AI 集成当成一次性的技术采购。它更像是给企业装了一套需要持续维护的数据器官，得有专人定期检查、补充、校准。项目章程里如果只写了上线时间，没写上线后的运营机制，那这个项目的生命周期大概率就止于上线那天。

如果你现在手里的项目正卡在数据侧，我的建议是先停下来，花两周把核心实体的口径对齐，把评估集搭起来。这两周不产出任何可演示的界面，但它是整个项目里回报最高的两周。相反，如果继续往前冲，你会在验收前一个月遇到那堵墙，那时候能选的只有延期或者带伤上线，两个选项代价都不小。数据侧省下来的每一分力气，后面都要以两倍的成本还回去。

陈立群：第二张表说得很实在。我们去年做的就是设备问答助手，卡点和文中制造集团那个几乎一模一样，台账字段对不上，检索再准也没用。后来花了六周重做数据映射才救回来。

周敏：评估集这块我踩过坑。项目做到后期所有人口径都不一样，技术说准确率九成，业务说答非所问。后来才补了一份五十题的评估集，两边的认知才算对上。早做这一步能省太多争论。

许建华：有个不同看法。中小团队不一定需要完整的数据治理平台，主数据梳理和评估集这两件事人工也能做，关键是有没有人愿意为它排期。工具是放大器，不是地基。

林晚：上线后的运营责任人这条太对了。我们那个助手刚上线时挺好，半年后业务规则改了两轮没人同步，答的全是老黄历，最后就被弃用了。养数据这件事没人愿意接。

高远：我们用的是数据开发加资产目录这套组合，体感最深的是口径变更不用重拉链路这一点。以前改一个指标定义要走两周流程，现在配置层面就解决了，对 AI 场景太重要了。