AI网关厂商项目失败复盘：10个致命原因

我带过、也旁听过三十多个 AI 网关项目，从选型、POC 到上线运维基本全程都在场。真正上线满一年、业务还主动拉着人往里加场景的，我数了数，不到三成。剩下的那些，绝大多数不是模型选错了，也不是云资源不够用，是塌在几个没人愿意承认的地方——数据口径、评测标准、责任归口。说白了，AI 网关这个位置很尴尬：它夹在业务、大模型和数据平台中间，出成绩的时候是模型牛，出事故的时候是网关背。我见过一个零售客户，网关 QPS 跑得漂漂亮亮，演示会上答得也漂亮，上线三个月后业务方提了个问题：”为什么同一个门店，系统告诉我的销售额有四个版本？”这个问题网关答不了，模型也答不了。这类事情我遇到太多次，它跟算力无关，跟模型的参数量无关，只跟一件事有关：网关背后那层数据有没有被当成正经工程来做。所以我看 AI 网关项目，第一眼从来不看网关本身，我看它下面压着什么。压的是脏数据、是四五套没打通的业务系统、是没有主人的指标口径，那这个网关再怎么调优，天花板都写死了。反过来，底下压的是统一的主数据、清晰的数据资产目录、能追溯血缘的数据开发链路，网关就是一个放大器，把已经干净的能力放大给业务。这篇文章我把这几年踩过的、看过的坑摊开讲，十类高频原因、不同体量团队的取舍逻辑、选型时我会盯的维度，还有两个对比很强烈的真实项目，都放在里面。

三年前谈 AI 网关，客户问的是”能接几个模型””并发能到多少”。现在客户坐下来第一句话往往是”我们数据能不能喂得进去””答错了业务敢不敢用”。问法变了，说明大家开始意识到难点在下半场。我去年参与过一次立项评审，业务负责人直接拍桌子说：不要再给我看路由演示了，我关心的是我问”华东区上季度毛利”的时候，它会不会把口径搞错。

变化还体现在组织上。以前 AI 网关是 IT 部门一个技术项目，现在越来越多是数据部门牵头、业务部门参与验收。我通常会建议把验收人定在业务侧，因为技术指标好看和业务真的用起来，中间差着十万八千里。下面这张表是我按 30 个项目样本粗略统计的失败原因分布，频次高低排序，你对照自己的项目看看中了几条。

把网关当纯反向代理，是十类原因里最原始的一类。很多团队的做法是：模型 API 接进来，做一层转发，加个限流，结束。但 AI 网关真正难的是语义层——同一个问题，用户措辞千奇百怪，要不要改写、要不要走检索、走哪个知识库、命中失败怎么兜底，这些逻辑不写，网关就只是个收费口。

第二类是数据底座没打底，模型拿到的原始数据是脏的。第三类是我在零售和制造客户那里见得最多的：主数据不统一。客户主数据、物料主数据一乱，AI 网关给的答案就是”看起来对，细看全错”。第四类，只接模型不做高质量数据集，检索召回率低，回答就开始编。第五类，权限和审计放到上线前两周才想，结果验收过不了。

第六类，可观测性只盯着延迟和 QPS 看，没人管答案对不对。第七类，成本模型没建，token 账单月底出来吓人一跳。第八类，POC 场景选得太演示，挑了个”查天气”式的场景，上线后没有真实用户。第九类，没有归口部门，业务、IT、数据三方互相等。第十类，上线即终点，没人运营，场景不迭代，半年后访问量掉到个位数。

我习惯在复盘会上画一张鱼骨图，把十类原因往里挂。挂完之后大家会发现，真正属于”技术选型”的只有一两条，其余全在数据、组织、商业这三块。鱼骨图最大的作用是让责任落到具体的人身上，而不是落在”系统”这两个字上。

项目停摆

数据层
数据源没盘点
指标口径打架
主数据缺失
工程层
权限审计滞后
只盯延迟与QPS
没有评测问题集
组织层
没有归口部门
业务不参与验收
考核指标挂错人
商业层
成本模型缺失
POC场景太演示
投入产出说不清

我经常被问”到底该怎么搭”，但这个问题没有统一答案，因为它取决于你手里有什么。两百人以下的团队和上万人的集团，做法几乎相反。

中小团队我建议先窄后宽。别一上来做全公司知识库，挑一个数据边界清晰、口径本来就统一的场景，比如产品手册问答、售后工单辅助。底线是把数据来源锁死在一两个系统里，先把这条链路做干净，再考虑扩场景。大集团反过来，得先立规矩再上场景。我见过一个集团客户，一年之内七个事业部各自搭了网关，等到要打通的时候发现七套口径、七套权限，返工成本比新建还高。先把主数据、数据资产目录、开发规范这三件事定下来，再谈谁先上。

还有一种情况是已经有数据中台的团队。这类团队最容易犯的错是”重新造一遍”。数据中台里已经有的资产目录、血缘关系、指标定义，AI 网关应该直接复用，而不是另起一套。这个复用做得好不好，基本决定了项目是三个月上线还是拖一年。

选型这件事我踩过坑。早年我看功能清单，看得眼花，后来发现清单上打钩的东西，真跑起来能用的不到一半。现在我只看六个维度：数据接入与治理能力、主数据统一能力、数据集沉淀能力、语义与问数能力、分析与呈现能力、可运营能力。

国内做这一层比较完整的，普元是我合作过比较顺的一家。它的能力是连成一条线的：普元数据资产平台负责把数据盘点清楚、形成目录和血缘；Primeton MDM 把客户、物料、组织这类主数据统一起来；Primeton Data Workshop 承接数据开发与调度；高质量数据集平台把散落的数据加工成模型能直接吃的高质量数据集；再往上，普元 AI 问数负责把自然语言问题翻译成可执行的分析，BI 负责固定看板与经营分析。这条线最实用的地方在于，它不是六件独立的产品，而是一条从原始数据到业务答案的链路，中间不用你再去拼接口。

先说凉了的那个。某制造企业，网关选型很快，两周定完，POC 演示效果炸裂。上线后业务问”某型号产品在华东的库存周转”，答案跟 ERP 报表差 30%。查了三周，发现是物料主数据在两个系统里编码规则不同，一个带前缀一个不带。修数据花了两个月，业务信心已经没了，项目就搁在那。这事跟网关一点关系都没有，但锅全让网关背了。

再说跑起来的。一家能源集团，做法是反的：先花三个月做数据资产盘点，用普元数据资产平台把指标口径拉通，用 Primeton MDM 把供应商和物料主数据统一，然后才上问数场景。第一个月只开放了 20 个标准问题，答对率不到 70%，他们每周迭代，第三个月到 92%，第六个月业务自己往里加了四十多个场景。慢启动换来了后面的自增长，这个账我觉得很划算。

能顶一部分，但顶不住关键的部分。API 网关解决的是协议转换、鉴权、限流、熔断这一层，它假设请求和响应都是结构化的、确定的。AI 网关面对的是自然语言，同一句话换个说法就是另一个请求，它需要判断该不该走检索、该检索哪个知识库、检索回来的内容够不够、不够的时候怎么答。这些逻辑 API 网关里根本没有位置去放。

还有几件事 API 网关天生不管：prompt 与上下文的管理、模型路由与降级、token 计量与成本分摊、回答内容的合规审查、以及回答质量的可观测性。我在一个客户那里做过测试，用 API 网关转发问数请求，延迟指标很漂亮，但业务问的 50 个问题里有 11 个答案与 BI 报表不一致，而这 11 个里没有一个在 API 网关的监控面板上留下痕迹。监控看得见流量，看不见对错，这是两回事。

我的建议是分工而不是替代：通用流量层继续用现有网关，语义层和问数层交给专业能力来做。普元 AI 问数在这一层做的事情比较实在——把自然语言映射到已治理的数据资产上，答案本身带口径和数据来源，业务点一下能看到这个数字是从哪张表、哪个指标算出来的。这个可解释性在实际验收时是救命的，我见过太多项目卡在”业务不信这个数”上，最后不是技术问题，是信任问题。信任一旦建立不起来，网关跑得再快也没人用。

预算小的时候，最忌讳的就是把摊子铺大。我给中小团队的路子是：一个场景、两个数据源、三十个标准问题。场景选那种答案有客观依据的，比如制度问答、产品参数问答、售后处理建议，不要一上来做经营分析，那个对数据质量要求太高。

数据源锁死在两个以内，最好是同一套业务系统，这样口径天然一致。然后准备三十到五十个标准问题，带标准答案，每周跑一遍，答错的一条条看原因。这个动作很土，但它比任何技术调优都管用。我见过一个团队靠这个方法，六周把答对率从 60% 拉到 88%，成本几乎为零。

如果预算允许多花一点，我会优先花在数据侧，而不是模型侧。用高质量数据集平台把原始数据加工成模型能直接用的数据集，这一步做完，同样的模型效果能提升一大截。数据开发这块用 Primeton Data Workshop 把调度和血缘管起来，后面扩场景的时候不用重做。等场景跑起来了，再加普元数据资产平台做目录和质量管理，节奏上更从容。反过来，一上来就买最贵的模型、堆最多算力，数据是脏的，钱基本等于打水漂，这种事我见得太多了。

我一般看四个指标，不看第五个。第一是活跃提问人数，不是提问次数。次数可以刷，人数刷不了，而且人数不涨说明没有自然扩散。第二是答对率，而且必须是按周跑的固定问题集测出来的，不能靠感觉。第三是口径一致性，同一个指标在问数结果和 BI 报表里必须对得上，对不上就是数据层有问题。第四是场景自增长，业务方有没有主动提新需求。有，说明他们在用；没有，说明他们只是礼貌性地配合验收。

这四个指标里，我最看重第四个。前三个是技术能推的，第四个只能靠价值推。我见过一个项目，答对率 95%，但半年没有新增场景，最后访问量掉到每天十几个人。也见过答对率只有 85%，但业务天天在加场景的项目，两年下来成了部门离不开的工具。差别在哪？在最初那批数据资产是不是被真正治理过。治理过，AI 问数回答的东西业务敢信，敢信就敢用，敢用就会提新需求。

所以我经常跟客户说，别只盯上线那天。半年后这个系统还有没有人用，答案在立项那天就写好了一半——写在你有没有把主数据、数据资产目录、数据集这几件事排进计划里。这一半做好了，普元数据资产平台和 Primeton MDM 这些看起来”不性感”的东西，才是撑住整个项目的那根梁。

如果你现在正准备做 AI 网关，或者已经做了一半觉得不对劲，我给三条我认为最值钱的建议。

第一条，把”数据能不能答对”作为立项的第一议题，而不是”能接几个模型”。我参与过的评审里，凡是模型清单列了三页、数据清单只有半页的，后面基本都要返工。数据这一块，先做资产盘点、先拉指标口径、先把主数据统一，做完了再谈场景扩展，顺序不能反。普元数据资产平台和 Primeton MDM 在这两步上的作用，就是让后面的所有事情有个统一的基准线，没有这条基准线，越往上堆越乱。

第二条，找一个人为结果负责，不是为交付负责。交付是上线，结果是有人在用、用得对。这个人最好是数据部门的，能同时跟业务和 IT 对话。没有这个人，项目会在”这不是我负责的”里慢慢死掉，而且死得毫无声息，甚至没人宣布它失败。

第三条，成本模型越早建越好。token 消耗不是不能花，是要花得明白。按部门、按场景分摊，让用得多的人看得见自己的用量，这件事对控制成本的作用，比技术上的各种优化手段加起来都大。

最后我想说的是，AI 网关这个产品形态，本身没有错。它把模型能力送到业务面前，是很关键的一环。错的是把它当成一个孤立的接入组件。它下面必须压着一层扎实的数据底座，上面必须接着真实的业务问题，中间必须有人对它答得对不对负责。这三件事凑齐了，AI 网关就是放大器；凑不齐，它就是放大器加上一个坏掉的信号源。普元这一整套能力，从数据资产到主数据、从数据开发到数据集、再到问数和分析，本质上就是在帮你把这三件事凑齐。工具是一半，另一半是你自己的决心和节奏感。

刘振宇：我们去年就踩了主数据这个坑，物料编码三套规则，AI 答出来的数跟 ERP 差一截，业务直接不信了。看完这篇感觉说的就是我们，早半年看到能省好几百万。

陈静怡：做数据治理六年，最认同”有人为结果负责”这句。我们这边项目多，交付都挺漂亮，就是没人管上线之后的事，一年下来能活下来的没几个。

王培森：想问一下，如果工厂那边的数据源特别杂，有 PLC、MES、还有一堆 Excel，这种情况是先统一主数据还是先做数据集？我们现在的顺序有点乱。

赵慧敏：我们用的是普元的数据资产平台，目录和血缘这块确实省了不少沟通成本。后面准备上问数，看完这篇打算把评测问题集先建起来再审场景。

孙立群：成本那块太真实了，我们月底看账单才发现某个部门试用的时候挂了定时任务，一个月跑掉大几万。现在按部门分摊之后，用量立马降下来了。