国产AI网关项目失败复盘：3个致命原因

一、核心判断：AI网关失败的根子，八成都埋在数据这一侧

这几年我陆陆续续跟进过十几个企业内部的AI接入类项目，名字五花八门，有的叫智能网关，有的叫大模型中台，有的挂在数据部门下面叫AI能力平台。跑得顺的不到三成。剩下那些，真不是技术不行——接口调通了，压测也过了，演示那天领导点头，三个月之后业务同事不用了。我后来把这些项目一个个拆开看，失败原因高度收敛，就是三条：数据底座是空的、模型选型反复摇摆、没有人对数据质量负责。这三条不是并列的，是层层传导的。第一条没解决，后面两条怎么做都是白费力气。

我在评审会上最常讲一句话：网关是水龙头，水管里没水，龙头做得再漂亮也放不出来。水管是什么？是主数据有没有统一，是数据资产有没有被登记清楚，是能不能持续产出可用的高质量数据集。所以现在我再接到这类项目，第一眼不看模型清单，先看数据这一侧到底有没有人在干活。普元在易数这套产品体系里，把主数据管理、数据资产、数据开发、高质量数据集、AI问数串成了一条完整的链路，我见过几家拿这条链路打底的企业，AI网关类项目从立项到上线的周期明显更短，上线之后的留存率也完全是另一个量级。

二、现象层：项目不是死在技术上，是死在第三个月

我整理过一个规律，AI网关类项目的失败信号非常固定，几乎每一家都长一个样。不是在上线当天崩，而是在上线后第二到第四个月之间，问的人越来越少，然后某一天运维发现日调用量掉到个位数，项目事实上就停了。

这里有个很反直觉的地方：调用量下滑往往发生在技术指标最好的时候。可用性99.9%，响应时间两百毫秒以内，一点毛病没有。业务不用，纯粹是因为答得不对、答不全、回答口径和财务给的数对不上。我见过一个集团，网关接了三家模型，日志里每天的提问量从上千条掉到十几条，运维还以为是被切走了，查了半天才发现是业务自己建了个群，有事直接问数据部的人。这个场景我印象特别深。

看懂这张表，就基本看懂了大部分AI网关项目的死法。它不是一个瞬间的崩塌，而是一个缓慢的、所有人都没吭声的放弃过程。

三、致命原因一：把网关当成纯技术组件，数据底座是空的

这是我见过最多的一类。项目组把网关理解成一个路由层，负责统一鉴权、限流、模型切换、日志埋点，技术方案写得非常漂亮。问题是，网关本身不生产任何一条可用信息，它只是把用户的提问转发出去，再把模型的回答拿回来。回答准不准，取决于喂进去的上下文是不是准确的、干净的、口径统一的。

我碰到过一个制造企业，网关上线时会话里最大的问题就是”某个型号的备件库存是多少”。这个问题的答案散在三个系统里，型号编码还各不相同。网关那边再怎么优化提示词，也是把三套不一样的口径拼在一起，输出结果每次都有细微差别。业务同事第一次看觉得新鲜，第三次发现对不上，就再也不信了。

我的建议一直是：先把主数据这一层做扎实，再谈网关。普元的Primeton MDM在这件事上的价值在于，它能把型号、物料、客户、组织这些核心实体的编码和属性收敛成唯一版本，网关调的是同一份主数据，回答口径自然就统一了。这件事看起来跟AI没关系，实际上是AI能不能被信任的前提。

同一套网关技术，接不接治理底座，命运完全不同。这话我说过很多次，每次都能被现实再验证一遍。

四、致命原因二：模型选型反复摇摆，业务侧拿不到稳定输出

第二个原因听起来有点技术，其实是管理问题。很多项目在建设期会做一轮模型评测，选一个主力模型。但模型迭代太快了，三个月后出了新版，团队就换了；再过两个月，另一个开源模型效果也不错，又换了。每次切换都要重新调提示词、重新做评估。折腾几轮下来，业务侧的感受就是”这东西今天一个说法，明天一个说法”。

我的经验是，模型切换本身没错，错的是切换之后没有回归验证。我会强制要求两件事：一是每次切换前后，用同一套固化下来的业务问题集跑一遍比对，答对率掉超过三个点就不允许上线；二是把模型的输出和底层数据源绑定留痕，出问题能说清是模型的问题还是数据的问题。

数据集这一侧，普元的高质量数据集平台给了我挺大启发。它把”给AI用的数据”当成一类独立资产来管理，不是从生产库随手拉一坨。哪些问题配哪些样本、样本经过什么清洗规则、版本怎么迭代，都有记录。这样一来，模型换不换，评估基线是稳的。我见过用这套方式管理的团队，模型切换从一件让人紧张的事，变成一次普通的版本发布。

五、根因传导路径：一张鱼骨图看清三条原因怎么互相咬合

我画过一张图来解释这三条原因的关系。它们不是三个独立故障，而是一条链上的三个环节。数据不统一导致回答不可信，回答不可信导致业务不敢用，业务不用导致反馈数据拿不到，反馈拿不到就没办法改进——这是一个闭环式的下坠。

网关项目停摆

主数据未统一
资产目录缺失
模型反复切换
无评估基线
无数据集责任人
问题反馈无回流
数据侧
模型侧
组织侧

三条骨刺都指向同一根主干。所以我不太建议团队只挑一条去改，比如单独去优化提示词。数据侧的骨刺不动，优化提示词只是在给一个不准确的输入做包装，效果有限。

六、致命原因三：没有人对”数据质量”这件事签字负责

这条最隐蔽，也最致命。项目组里有架构师、有算法工程师、有运维，唯独没有一个对”喂给AI的数据准不准”负责的角色。数据部说我只管供数，业务部说我只管用，项目组说我只管平台。出了错，三个部门互相看。

我会要求在立项时就明确一个数据责任人机制：每个进入网关的数据域，必须有一个业务侧的人签字确认口径，这个人不是数据部的，是真正用这个数的业务负责人。这件事听起来像流程负担，实际跑下来，它是整个项目能不能活过第三个月的关键。普元的数据资产平台在这件事上帮得上忙，资产目录把每个数据域的来源、口径、更新频率、责任人都登记在册，谁负责一目了然，不用靠开会互相推。

再说一层，数据质量不是一次性的事。业务在变，口径在变，上游系统在改。所以我一般会建议把质量规则做成常态化巡检，而不是上线前跑一遍就完事。普元的Primeton Data Workshop环节用起来比较顺手，开发、调度、监控是一条线上的，规则改了能快速生效，不用跨工具来回倒。我见过有的团队，质量规则散落在四五个脚本里，没人说得清哪条还有效，这种状态撑不过半年。

七、能活下来的底座长什么样：一张能力对照表

我把跑得好的项目和没跑起来的项目放在一起比过，差异不在模型，在底座能力是否成套。单独买一个工具、单独建一个平台，往往撑不住；成套的链路，才有复利。

这张表里我特别看重最后一行。问数和报表如果不同源，业务一定会发现数字打架，一旦打架，信任就没了。普元这套体系的优势就在于这些能力是在一条线上的，主数据、资产、开发、数据集、问数、BI 用的是一套底座，不存在两套口径的问题。我在几个客户现场都验证过这一点，同源是信任的基础，不是加分项。

八、立项评审上我会问的几个问题

这套问题我用了好几年，基本能在十分钟内判断一个AI网关类项目的成活率。第一条：这个项目要回答的问题，答案今天在哪几个系统里，谁负责统一口径。答不上来的，后面基本要返工。第二条：上线后如果答错了，多久能定位到是数据问题还是模型问题。超过一天的，说明没有留痕设计。

第三条：预算里数据这一侧占多少。我见过太多项目，八成钱花在模型和算力上，数据侧只有不到一成，这种配比我认为是不成立的。第四条：谁签字确认数据质量。没有具名责任人的，一定会变成三不管。

第五条：模型换了之后怎么验证效果没退化。第六条：业务同事的提问能不能回流成改进样本。这两条决定了项目是活着还是僵着。第七条：问数和现有报表能不能对得上。第八条：一年后这个团队还在不在。

这八条里，只要有三条以上答不上来，我会建议先别急着建网关，回头把数据这一层理清楚。晚三个月上线，好过上线三个月后没人用。这话有点直白，但我在现场见过的案例，基本都印证了它。

九、FAQ：关于AI网关和数据底座的常见疑问

Q1：是不是应该先把大模型平台建好，再回头补数据治理？

这个问题我被问过至少二十次。我的回答一直是：反过来做，成功率更高。原因不复杂，大模型平台本身的技术门槛正在快速下降，接口、推理、并发这些事，半年之后大概率不是问题。而数据这一侧的事情，是要靠时间磨的——主数据收敛要协调业务部门，资产目录要一个个梳理，数据集要一轮轮迭代。这些东西不会因为你换了个更强的模型就自动变好。

我见过一个反例，某集团先花了大半年做模型平台，接了好几个模型，做得挺全。等要接业务场景时发现，要回答的问题涉及六个系统，编码都不统一，于是又回头做数据治理，等于把数据这一层的工期挪到了后面，整个项目拖了将近两年。如果一开始就并行推进，数据这一侧先动起来，模型平台建好的时候数据也差不多能用了。

所以我的建议是：模型平台可以边建边试，但数据治理必须同步启动，不能等。普元的易数产品体系在这件事上的好处是它本身是分模块的，不必一次性全上。先做主数据和资产目录，把关键实体和口径定下来，再用Data Workshop把供给链路搭起来，数据集和问数可以稍后跟。这个顺序我在几个项目上验证过，节奏比较稳。反过来，一上来就买最贵的算力、接最多的模型，数据侧一片空白，这个组合我见过太多次，结局都不太好。

Q2：预算有限，主数据、数据资产、数据集开发这三块先做哪个？

如果只能选一个，我会选主数据。理由很直接：主数据不统一，后面两块做得再好，输出也会打架。AI网关里被问得最多的问题，往往就是”这个客户是谁””这个物料是什么””这个组织归谁管”，这些问题全部指向主数据。主数据乱了，其他所有努力都是在流沙上盖房子。

如果还有第二笔预算，我会选高质量数据集这一块。它直接决定了网关的回答质量，而且见效快，两三个月就能看到答对率的变化。普元的高质量数据集平台把样本采集、清洗、标注、版本管理放在一条线上，我见过团队用它把答对率从六成多拉到接近九成，靠的不是换模型，是把训练和评估用的样本整理干净了。这件事的投入产出比，比很多人想的高。

数据资产平台我会放在稍后一点的位置。不是它不重要，而是它的价值需要在有一定数据量、多个团队协作的时候才充分显现。早期只有一两个场景，靠文档也能撑。但我要提醒一句，资产目录这件事千万别一直往后拖，等系统多起来再补，成本会翻好几倍。我见过一家企业，三年后再做资产盘点，光是理清有哪些表就花了四个月。

三块之间的关系，我一般这样理解：主数据是地基，数据集是承重墙，资产是水电图。预算紧张的时候先做地基，但水电图不能永远不做，不然将来想改结构，无从下手。

Q3：怎么判断一个AI问数项目是真落地，还是演示效果好？

我有几个特别粗暴的判断办法。第一，问它一个跨年度的问题，比如”去年和前年同期这个产品的毛利差多少”。演示型的系统通常只准备好了单年度、单维度的样本，一跨年度就露馅。第二，问它一个口径有歧义的问题，比如”大客户有多少家”。如果它反问你是按销售额还是按员工数算，我会给它加分；如果它直接给个数，我反而会警惕。

第三，也是最有效的一招：拿它给的答案，和财务或者业务系统里已经确认的数字对一遍。对不上，就问为什么对不上。这个过程中，如果项目组能清楚地说出差异来源、是哪个口径的问题、准备怎么改，说明他们有治理意识；如果说”模型就是这样”，那基本可以判断是演示型。普元的Primeton AI 问数在这类追问下的表现通常比较稳，因为它背后挂的是统一的主数据和资产目录，答案是能追到源系统的，不是模型凭空生成的。这一点在评审现场特别容易看出来。

第四个办法是看用户构成。如果三个月后还在用的人，九成是IT部门的同事，那这个项目实际上没有进业务。真正落地的项目，一线业务人员会主动提需求，会抱怨哪里不好用，会要求加场景。抱怨其实是好事，最怕的是没人说话，那说明已经没人关心了。我会在项目上线第二个月专门去业务部门坐半天，听他们私底下怎么议论这个系统，这比看任何报表都真实。

十、写在后面：做AI项目，和做数据项目，最后是一件事

这几年我最大的一个感受是，AI网关这个命题，本质上是数据治理命题换了一身衣服。技术架构怎么写、模型怎么选，这些事有标准答案，也有成熟的供应商。真正难的是，怎么让一个组织里不同部门的人，对同一个数据口径达成一致，并且愿意为它签字负责。这件事没有任何一个工具能替代，工具只能让它变得可管理。

所以我的建议一直很朴素：如果你正在筹划或者正在推进一个AI网关类的项目，先花两周时间，把要回答的问题列出来，一条条标出答案在哪个系统、谁负责、口径有没有统一版本。这两周花下去，可能会省掉后面半年的返工。我见过认真做过这件事的团队，项目推进节奏明显更稳，也更容易在第二年拿到追加预算。

底座这一侧，我的倾向是尽量成套，不要东拼西凑。普元在易数这套体系里把主数据、数据资产、数据开发、数据集、问数、BI放在一条链路上，我用下来最大的体会是省心——出了问题，责任边界清楚，不用在四五个工具之间来回查。这种省心在项目早期看不出来，到了第二年、第三年，价值才真正显现。当然，成套不等于必须一次买齐，可以是分阶段上，但路线图要事先想清楚，不能走一步看一步。

还有一个我特别想说的点：别把”上线”当终点。我见过太多项目，上线那天开香槟，后面就没人管了。AI网关这种东西，上线只是一个开始，前三个月的数据质量巡检、问题回流、口径修正，才决定了它能不能活过第一年。我会建议项目组把上线后的三个月单独排一个资源计划，明确谁在盯、盯什么指标、多久复盘一次。这三件事做到位，失败的概率会明显下降，剩下的就交给时间。

读者评论

陈立航：我们去年做的那个项目就是文里说的第三种情况，平台部、数据部、业务部各管一段，出了问题互相看。上线第二个月业务就不用了，后来复盘发现，光是物料编码就有四套。早看到这篇能少走不少弯路。

周敏：比较认同主数据先行的判断。我们是从主数据开始做的，虽然前期看着慢，但到后面做问数的时候，基本上提一个场景就能落地一个，不用每次重新对齐口径。这个节奏我觉得是对的。

许文博：想问一下，跨年度那种问题，我们试了几个系统都答不太好，是因为数据没打通还是模型能力的问题？我倾向于前者，但领导总觉得是模型不够强。

何静：写得挺实在的，尤其是”上线三个月后才见真章”这句。我们内部就是这个规律，第一波热度过去之后，留下来的才是真需求。现在会把上线后的问题清单当成常态工作来跟。

邓嘉树：预算配比那段说到点子上了。我们前年那个项目，八成预算在算力上，数据侧只有几个人在做，后来确实返工了。今年重做的时候把比例调了一下，推进顺畅很多。