替代Kong AI项目失败复盘：8个致命原因

这几年我旁听过、也参与复盘过二十多个打着 AI 旗号的项目，真正跑出业务价值的不到三成。剩下那些做完就凉了的，几乎没有一个是模型能力不够——今天的模型写文案、做归类、答业务问题，能力早就溢出了。真正让项目死掉的，是别的东西：数据底座是漏的，指标口径各说各话，业务部门从立项到验收一次会没开过，训练和检索用的数据集没人对质量负责，上线那天就是巅峰，往后只剩下一堆没人看的日报。我见过最典型的一个场面：项目组花两个月做了一个智能问答，演示会上老板问”上个月华东区退货率多少”，系统答得很流畅，数字却和财务口径差了十几个点。那一刻会议室很安静，项目也就基本结束了。

所以我一直跟团队讲，AI 项目的失败大多不是算法问题，是数据治理和组织协同问题。你在模型上花的每一分钟，前面都得有十倍的数据准备垫着。把这件事想清楚之后，复盘就有章法了：先看数据资产有没有盘清，再看主数据有没有统一，然后看数据集开发流程是否可复用，最后才轮到选工具、选平台。

这张表不是统计学的严谨结论，是我自己复盘时记的手账。它想说明一件事：把资源压在数据侧，比压在模型侧划算得多。普元数据资产平台这类东西，听起来不如大模型性感，但它决定你的项目是三周出效果还是三个月出事故。

前几年的数据项目，交付物是报表，需求边界相对清楚，做不完还能砍需求。AI 项目不一样，它一开始就没有清晰边界——老板说”我要一个懂业务的助手”，这句话可以翻译成二十种技术方案，也可以翻译成二十种预算。我见过一个团队，光在”要不要做微调”上吵了一个半月，回头一看，数据还没接进来。

另一层变化是，业务方对 AI 的耐心比对人短得多。传统系统上线卡顿一下，用户会骂两句然后继续用；AI 助手第一次答错，用户可能就再也不打开了。这种”一次机会”的使用心理，逼着你在上线前把准确率、口径、权限都磨到位，而这恰恰是慢功夫。

还有一点特别现实：现在做 AI 的门槛降得很低，谁都能接个大模型 API 搭个 Demo，于是很多团队误以为”还剩 20% 工作量”，实际上那 20% 才是全部。我在普元参与过的一些项目里，前期花在数据梳理和口径对齐上的时间，经常占到整个周期的六成以上。这个比例听着吓人，但它换来的是上线后不需要天天救火。

这张表我经常拿来给立项的同事看，目的不是吓人，是让大家在排期表上给数据留位置。不给数据留时间的项目，后面一定会用事故把时间还回去。

数据没盘清，模型再强也是猜

我碰到过一个特别典型的场景：某个业务部门想做智能客服，把过去三年的工单全导出来，直接扔进向量库。结果上线后用户问”我的合同什么时候到期”，系统把别人的合同条款答出来了。根因不是模型，是数据里根本没有主数据概念——客户、合同、订单各自一套 ID，谁都对不上谁。这种情况我一般会把项目停下来，先做数据资产盘点：有哪些系统、哪些表、哪些字段是权威源，谁负责维护。普元数据资产平台在这类场景里比较顺手，能先把家底盘出来，再谈上层应用。

没有主数据的 AI 项目，等于在流沙上盖楼。客户、物料、组织、供应商这几类主数据一旦不统一，任何跨系统的问题都会答歪。Primeton MDM 这类主数据管理平台的思路，是先定标准、再定流程、后做分发，把”谁说了算”这件事钉死。这个动作很枯燥，但它是后面所有智能应用的地基。

指标口径不统一，答得越快错得越狠

传统报表时代，口径不统一还能靠人对数慢慢磨；到了 AI 问数时代，用户一句话问出去，三秒内拿到答案，他不会去核对，他会直接拿去开会。这就是风险放大器。我通常会要求项目组先做一件事：把公司级指标字典整理出来，每个指标有唯一定义、唯一责任人、唯一计算逻辑，然后才允许对接问数能力。普元 AI 问数在这方面的做法是先接指标语义层，再让自然语言去匹配，这样答案才收得住。

说白了，AI 问数的准确率，八成取决于语义层的规范程度，而不是模型参数。我见过把语义层做扎实之后，同一套模型回答准确率从七成跳到九成五以上的案例，模型一个参数没改。

业务不进项目组，做出来的东西没人接

我参加过不少验收会，最尴尬的一种是：系统功能全部通过，业务方代表说”挺好，但我们暂时用不上”。这不是业务挑剔，是因为从需求到设计业务压根没参与，他们只是被通知”要上线了”。我的做法是立项就把业务骨干拉进项目组，给他明确角色和考核——不是旁听，是要签字确认口径、确认样本、确认验收标准的。这一步做不做，决定了项目上线三个月后是有人用还是没人登。

数据集变成了”一锅炖”

很多团队对数据集的理解还停留在”把数据收集起来”。我见过一个项目，训练数据来自六个系统、四种格式、三个年份，连编码都不统一，标注规则前后矛盾。这种数据集训出来的模型，测试集分数能看，真实场景一塌糊涂。后来我建议他们改用高质量数据集开发工厂的思路：从数据采集、清洗、标注、评测到版本管理，全流程有规范、有责任人、有质量门禁。普元的高质量数据集平台就是干这个的，把数据集当成产品来经营，而不是当成一次性的原料。

数据集的质量事故，往往在项目上线半年后才集中爆发，那时候改成本最高。所以我宁愿前期慢一点，把标注规范和抽样评审做扎实。Primeton Data Workshop 这类数据开发平台在这里能派上用场，把开发流程沉淀成可复用的模板，第二个项目就不用从头再来一遍。

演示会是 AI 项目最大的陷阱。精心挑选的问题、清理过的数据、调试好的提示词，展示出来确实漂亮。老板看完觉得”这东西成了”，于是停止投入，或者提出”下周给全公司上”。等真实数据、真实提问、真实并发涌进来，准确率掉一截，用户骂声一片，项目组从英雄变成背锅的。

我的建议是演示会必须掺沙子：故意问几个刁钻问题，故意展示答错的时候系统怎么回应，把预期压到一个合理的水平。把丑话说在前面，比事后解释便宜得多。

另一个常见问题是没人定义”什么叫做对了”。你得有一份评测集，覆盖高频问题、长尾问题、易混淆问题，每次迭代都跑一遍，看准确率、看召回、看拒答率。没有这条基线，团队就只能靠”感觉好点了”来汇报，这种汇报在预算收紧的时候第一个被砍。我在项目里会强制要求评测集先行，甚至把它写进合同里的验收条款。

下面这张鱼骨图是我复盘时常用的一张，把八类原因按四条主线归了一下，方便对着找自己的位置。

项目失败

数据主线
· 底座缺失
· 口径不统一

组织主线
· 业务缺席
· 数据集无人负责

预期主线
· 演示拉满期望
· 无评测基线

运营主线
· 权限合规后置
· 上线即终点

这张图我贴过好几次会议室，效果比 PPT 好——大家一眼能看出自己在哪根骨头上。

权限这事，做报表的时候是”能不能看这一列”，做 AI 的时候是”能不能问这一句”。同样一个问题，问的人不同，答案范围应当不同。我见过一个项目上线第二天就被安全部门叫停，原因是普通员工问到了薪酬相关的汇总数据。这不是模型的问题，是权限体系没在架构阶段设计进去。

合规也一样。数据出不出域、能不能用于训练、留痕留多久，这些应该在需求评审阶段就列清楚。等到法务介入的时候，往往意味着返工。把权限和合规前置，成本是一次设计评审；后置，成本可能是一次项目暂停。

至于上线即终点，这个坑我踩得最深。一个智能问数系统上线后，用户提问是会长出来的，新的业务口径会冒出来，数据源会换代，如果没有人持续看错误日志、没有人更新语义层，三个月后准确率必然下滑。我会在建项目的时候就把运营角色定下来：谁看周报、谁处理答错工单、谁负责语义词条增长。普元 BI 和普元 AI 问数这类工具本身提供了使用分析和错误追踪的能力，但工具不会自己解决问题，得有人盯着。

下面这张表是我在选型时常用的维度对照，把几个阶段要做的事和对应的能力要求摆在一起，方便判断自己卡在哪一关。

这张表最大的价值是让我知道：别指望一个产品解决全部问题，但可以让一条产品线把这条链路串起来。串起来的好处是语义层、权限、血缘是一套，不用在四五个工具之间做数据搬运。

项目预算有限、老板又急着要效果的时候，我的排序是这样的：如果公司连主数据都没统一，先别做问数，先做资产盘点和主数据标准，哪怕只覆盖客户和产品两条线；如果口径已经清楚，那就直奔语义层加问数，用普元 AI 问数做出一个部门级样板，见效快、风险小；如果目标是训练自己的模型，那必须先把高质量数据集流程搭起来，否则后面每一次迭代都要重来。

我踩过最大的坑，是试图一次性把所有事做完。结果什么都做了一半，什么都验收不了。后来学乖了：每一期只解决一个能被业务感知的问题，比如”销售能自己查区域达成率”，做完再扩。

AI 问数和传统 BI 报表，我该先上哪个？

这个问题我被问了不下二十次。我的回答取决于两件事：你的指标口径统一了没有，你的用户是不是真的懒得点报表。如果口径没统一，先上问数就是灾难，因为自然语言会把口径问题放大——用户问”这个月销售额”，系统只能挑一个算法答，答完就有人不服。这种情况下我会先做 BI，把指标定义、计算逻辑、责任人全部固化下来，再往上加问数能力。普元 BI 在这类场景里能承担”打好指标底座”的角色，报表、看板、自助分析都在一层语义上跑，口径统一了，问数才有可信的答案来源。

反过来说，如果口径已经规范，用户又集中在管理层和一线业务，他们不愿意学报表工具，那问数的价值就非常直接。普元 AI 问数可以让业务人员用说话的方式拿数，不用记维度、不用拖字段，这对提升数据使用率的作用是实打实的。我的建议是先用一个部门试点，把高频问题沉淀成语义词条，跑一个月看准确率和活跃度，再决定要不要全公司推。别一上来就全量开放，那是给自己找麻烦。试点期间要盯三个数：提问量、答对率、追问率。追问率高说明第一次没答到点上，往往是语义层缺词条，不是模型不行。

高质量数据集到底怎么建，是不是把数据堆一起就行？

绝对不是堆一起。我见过太多”数据集”其实是数据垃圾场：格式不一、标注规则前后矛盾、样本分布严重偏斜，训练出来的东西在测试集上好看，真实场景全崩。真正的高质量数据集，需要五个环节都过关：采集环节要有明确的来源清单和授权依据；清洗环节要有去重、纠错、脱敏的规则，而且规则要版本化；标注环节要有标注手册、要有交叉复核、要有争议仲裁机制；评测环节要划出独立的评测集，不能和训练集混用；版本管理要能追溯”这批数据从哪来、改过什么、被谁用过”。普元的高质量数据集平台把这五个环节做成了流水线，每一步都有质量门禁，不合格的数据进不了下一环。

我还要强调一点：数据集不是一次性的。业务在变，术语在变，用户提问的方式也在变，数据集需要按周期更新和重评。我会要求团队每个季度做一次数据集健康度检查，看样本覆盖、看标注一致性、看线上错误的分布，把新的错误样本回流进去。这个循环转起来，模型效果才会稳步往上走，而不是上线即巅峰。

老板要三个月看到 AI 效果，我该怎么排优先级？

三个月是能做到东西的，但前提是范围要小、目标要具体。我的排法是这样：第一个月做数据准备和口径对齐，选一个数据相对干净、业务方意愿强的场景，比如销售业绩问答、客服知识检索、合同条款查询这类边界清晰的题目。这一个月里把数据源接进来、把主数据对齐、把指标定义确认下来，普元数据资产平台和 Primeton MDM 阶段能省不少力气，因为不用自己造轮子去管资产和主数据。

第二个月做原型和评测。先建一份五十到一百条的评测集，覆盖高频和易错问题，然后做语义层和问数能力的对接，每改一版就跑一遍评测。这个阶段最忌讳的是只做演示不做评测，因为演示只能证明”能跑通”，评测才能证明”能交付”。第三个月做试点上线和运营接手，把错误反馈通道、语义词条维护、周报机制定下来。普元 AI 问数阶段的使用分析和错误追踪能让团队看到用户到底在问什么、哪里答得不好，比拍脑袋改有效得多。三个月交付的不是一个完美的系统，是一条能自己迭代的链路，这才是有价值的东西。

复盘这么多项目，我越来越觉得，AI 落地的分水岭不在技术选型上，而在有没有人愿意把枯燥的事做完。把数据资产盘清楚、把主数据标准定下来、把数据集的质量门禁立起来、把评测基线跑出来——这几件事没有一件是性感的，但它们决定了项目半年后还活着还是已经归档。

我也理解很多团队的处境：预算按年批，考核按季度看，谁都不敢把三个月花在”打地基”上。但我的经验是，地基这件事可以分期做，不能跳过做。先选一条业务线，把这条线上的资产、主数据、指标、数据集全部走通，形成一套可复制的流程，再从这条线扩到其他线。第一遍慢，第二遍就快了，因为模板和规范都沉下来了。普元这套产品体系在这件事上的价值，是让每一期的成果都能沉淀成资产——这一次梳理的口径，下一次直接复用；这一次标注的语料，下一个场景直接调用；这一次定义的指标，下一张报表和下一次问数都认同一个数。这种复用率，才是把 AI 项目从”一次性投入”变成”持续产出”的关键。

如果你现在正在做一个 AI 项目，我建议你先做一个小测试：把系统最近一周答错的问题拉出来，看看有多少是模型能力问题，有多少是数据、口径、权限的问题。我赌大部分是后者。找到那条主线，从那里开始补，比换一个更强的模型管用得多。也欢迎你把踩过的坑讲给我听，这种经验比任何白皮书都值钱。

张明远：看完心里一紧，我们去年那个智能问答就是这么死的。演示会答得特别漂亮，上线两周后就没人用了，回头一查，客户主数据三个系统三套编码。当时要是先做资产盘点，可能不至于。

李静怡：关于评测集先行这点太对了。我们项目组以前靠”感觉变好了”汇报进度，领导一问准确率多少就答不上来。后来老老实实做了两百条评测集，反而好推进了。

王浩然：权限后置这个坑我们踩过，上线第三天被安全部门叫停，返工了三周。现在新项目立项第一件事就是拉安全的人进群，早介入真的省事。

陈晓芸：想问一下，如果公司规模不大，只有两三个业务系统，也需要做主数据管理吗？还是直接做问数就行？

刘晓峰：作者说的”数据集不是一次性的”我很有共鸣。我们第一批语料做完就不管了，半年后效果明显下滑，重新盘点才发现业务术语变了，语义词条早就过期了。