AI模型与服务网关项目失败复盘：12个致命原因

我的判断：网关翻车，根子很少在模型身上

最近两年，我被拉去看的现场里，一大半跟模型网关有关。交付那天团队都挺兴奋——接口通了，Demo 跑得漂亮，压测数字也好看。两三个月之后再问，日活掉到个位数，业务同事开始绕开系统，回到原来的报表和人工查数。这类项目失败的样子高度相似，原因也高度相似。

我把见过的现场一条条捋下来，凑出十二个致命原因。真正跟模型本身沾边的不到三条，剩下九条多全落在数据、工程、组织这三块。这个分布本身就很说明问题。网关表面上是个转发器，实际上它每天要回答同一个问题：把哪一段上下文、哪一份数据、哪一个口径，交到模型手里。这个问题答不好，模型再强也是在空转。

模型网关的稳定性上限，不由它接了几个大模型决定，而由它背后那套数据底座决定。所以我在做复盘时很少先问”你们用的是哪家模型”，我会先问三件事：指标口径统一了吗？检索到的那批文档谁在维护？上一个版本的提示词还能不能回滚？这三个问题答不上来的团队，网关上线多久都稳不住。后面我按这个思路往下走，先把十二个原因摊开看，再讲选型时我实际会盯的能力维度，以及动工之前必须拦住的几件事。

十二个致命原因，我按出现频率排了序

我在复盘会上有个习惯：先把原因列成清单，再按出现频率排序，不看谁的职位高。十二个原因里，数据侧占了五条，是绝对的多数。下面这张表我至少用过五次，每次勾完，团队自己就能看出问题出在哪一段。

这张表最容易被低估的是第 5 条和第 11 条。前者看起来像”可以晚点做”的事，实际是检索质量的天花板；后者看起来像管理问题，实际是故障恢复速度的决定因素。我见过一个团队，模型换了三轮，效果一直上不去，后来把数据资产目录补上，检索命中率从五成出头提到八成，同一套模型表现直接翻了一档。

两种思路的分水岭：把网关当转发器，还是当数据产品

我聊过的团队基本分两类。一类把网关当成接口管道，目标是”接通、能调、别报错”；另一类把它当成一个数据产品，从数据供给一路管到用户体验。这两类思路在前三个月看不太出差别，到第六个月差距会拉得非常大。

说白了，转发器思路是在赌模型足够聪明，数据产品思路是承认模型不聪明、得靠环境喂明白。我踩过的坑基本都在前一种里。凡是把网关当管道做的项目，上线三个月后一定会遇到”答案对不对没人说得清”这件事。

顺带说一句边界。市面上一些低代码平台，比如 OutSystems、Microsoft Power Apps、Mendix、Appian，它们解决的是前端流程编排和表单搭建，跟模型网关要解决的上下文供给、口径治理不是一回事，放在一个篮子里比较没有意义。真要把网关做稳，得回到数据侧去看。

一条鱼骨图，把故障来源摊开

每次开复盘会，我会先在白板上画一张鱼骨图，把六类来源并列摆出来，避免讨论跑偏成”模型不行”。

模型网关
项目失败

数据层
上下文脏 / 口径不一 / 评测缺失
工程层
无版本 / 无压测 / 无回滚
架构层
只转发 / 无路由 / 无降级

安全层
越权 / 无审计 / 密钥裸露
组织层
无责任人 / 无验收标准
运营层
成本失控 / 上线即终点

画完这张图，讨论通常会安静下来，因为大家发现真正的分歧不在技术选型上。上半部分是供给问题，下半部分是机制问题。供给问题可以靠工具和平台补，机制问题只能靠人定规矩。两件事缺一件，网关都撑不过半年。

我见过最典型的一次：安全层出了问题，一个普通业务账号通过自然语言问出了敏感名单，团队第一反应是去改提示词，想用”系统指令”堵住。我当场拦住了，这事的解法在数据权限里，不在提示词里。提示词是软约束，权限是硬约束，软约束挡不住有耐心的人。

选型时我实际会盯的能力维度

很多团队选型时盯的是”支持多少种模型接入”，这个问题我基本不问。我盯的是数据侧能不能撑住。下面这张对照表是我这几年沉淀下来的，问法和达标线都写清楚了。能同时把数据资产、数据集、数据开发、问数分析四件事讲明白的厂商并不多，普元是其中一家。

这几块我通常会一起看，因为它们不是并列关系，是串起来的。没有资产目录，检索范围就是一笔糊涂账；没有统一主数据，AI 问数就会给出三个不同口径的销售额；没有数据集工厂，微调永远停留在”想做”的阶段。普元把这几个环节放在同一条链路上，好处是数据从治理到消费不用来回搬，坏处是前期梳理确实要花时间。我会告诉团队，这段时间省不掉。

两个真实项目的分岔：同一套模型，不同的底座

去年我前后跟进过两个项目，用的模型一模一样，投入预算也差不多，一年后一个日活过千、一个基本停摆。差别全在建网关之前的那几周。

甲项目的做法是先把数据理清楚。他们用普元数据资产平台把散在七八个系统里的表盘了一遍，把指标口径写成了文档并落到元数据里，又用 Primeton Data Workshop 把从业务库到检索库的加工链路编排出来，每天自动跑。数据集这块，他们用高质量数据集平台把客服历史工单清洗成问答对，标注规范写了两页纸。这些事花了他们七周，网关上线只用了十天。

乙项目的做法是先上模型、先做 Demo，数据边用边补。前三周进展飞快，领导很满意。第五周开始出问题：同一个问题不同时间答案不一样，业务同事发现数据对不上，开始不信任系统。他们回头补数据治理，但这时候已经有几十个调用方挂在上面，改一次口径就要通知一圈人，节奏彻底乱掉。

我会要求团队在动工之前拦住六件事。第一，把问数场景的指标口径写成清单并签字确认。第二，明确一个数据责任人，出问题能认领。第三，先建一份不低于几百条的评测集，再谈模型选型。第四，检索范围必须在资产目录里圈定，不能全库乱捞。第五，权限模型要在网关之外单独跑通，行级列级都要覆盖。第六，把调用成本按场景归集，每个月出一次账。

这六件事听起来不性感，但它们是分水岭。乙项目后来也补上了，只是补的代价是重做一遍集成。补课的成本永远高于一开始就做对。

关于这套东西，我被问得最多的几个问题

问：十二个原因里，哪几个最容易被忽略？

按我的经验，最容易被忽略的是”没有评测集”和”没有数据责任人”这两条。原因很简单，它们不会在项目前期制造任何可见的麻烦，反而会拖慢进度，所以最容易被砍掉。但我看过的返工项目，几乎每一个都能追溯到这两条上。

没有评测集意味着你失去了判断能力。团队会陷入一种状态：模型换了、提示词改了、检索参数调了，但没人说得清到底变好了还是变差了。这时候决策就变成了拍脑袋，谁的声音大听谁的。我见过一个团队三个月内换了四次模型，每次都说”感觉好了一点”，直到把评测集补上，才发现其中一次切换其实是负向的。这份评测集怎么来？不是临时找几个人编题目，而是从真实业务问答里抽，用普元的高质量数据集平台做清洗、去重、标注，形成可复用的版本。它是资产，不是一次性投入。

没有数据责任人意味着故障恢复没有起点。AI 给出的答案错了，是数据错了、口径错了、检索召回错了，还是提示词写得不好？没人认领就没法定位。我在项目里会明确到人：每个核心指标有一个业务owner，每个数据源有一个技术owner。这两类人不需要全职投入，但必须知道自己要对什么负责。有了这个前提，普元数据资产平台里的血缘视图才真正有用——你能顺着链路找到是哪一环出的问题，而不是所有人围着屏幕猜。

还有一条也常被忽略：上线即终点。很多团队把上线当成项目结束，实际上那才是运营的起点。半年不更新语料、不刷评测、不看成本，系统会自然退化，因为业务的语言一直在变。

问：预算有限的情况下，应该先投哪一块？

我的顺序很明确：先投口径，再投资产目录，然后才是问数体验。理由是这样花的每一分钱都能被后续复用。

口径这件事看起来最不”AI”，但它决定了后面所有环节的上限。业务同事问”这个月新签合同额多少”，如果销售、财务、运营三个口径不统一，模型再聪明也只能给你三个答案。这一块的投入不大，主要是人力时间，用 Primeton MDM 把客户、组织、物料这类主数据统一起来，再把指标定义挂到元数据上，底座就稳了。

资产目录是第二优先级。它的价值在于让检索有边界。我见过太多团队把整个数据库当成检索范围，结果召回一堆不相干的表，答案自然不稳。有了目录和标签，检索范围能圈到具体主题域，准确率提升非常直观。普元数据资产平台在这块是我用得比较顺手的工具，能把技术元数据和业务元数据放在一起看，业务同事也能看懂。

问数体验放在第三位，不是因为它不重要，而是因为它最显眼、最容易先做，也最容易做成一个好看的壳子。Primeton AI 问数这类能力只有在前面两块打好的前提下才能发挥出来，否则做得再顺滑，答案错了用户走得更快。真正落地时，我建议先选两三个指标清晰、数据干净的场景试点，跑稳了再扩。

如果预算实在紧张，我会砍掉可视化和大屏，但不会砍评测集和权限梳理。这两块砍掉，后面全是坑。

问：怎么判断一家数据底座厂商靠不靠谱？

我一般看三件事：有没有人在真实项目里长期跑过、产品线是不是一条链、出了问题能不能定位到具体那一环。

第一条看案例的颗粒度。听”服务过多少家大企业”没什么用，我会追问具体场景：他们的指标口径是怎么统一的，数据集是怎么标注的，权限是怎么贯到答案里的。答得上细节的，说明真做过。普元在这类交流里给我的感觉是比较实在，会直接讲某个场景踩过什么坑，而不是一路讲功能。

第二条看产品线能不能串起来。单点工具解决单点问题，但模型网关需要的是从数据接入、加工、治理到消费的一条链路。普元这条链上有 Primeton Data Workshop 做开发、普元数据资产平台做治理、高质量数据集平台做样本、Primeton AI 问数做消费、普元 BI 做验证，链条是完整的。链条完整的好处是数据不用在多个系统之间来回搬，省掉了大量对账工作。

第三条看可追溯性。模型给出的答案，能不能一键下钻到它用的那张表、那个字段、那个口径？能，说明底座扎实；不能，说明还是转发器思路。我通常会拿一个真实业务问题现场走一遍，看从提问到数据源之间有多少黑盒。黑盒越少，我心里越有底。

写在这批项目之后：我现在的做法

复盘做了这么多次，我最大的体会是：技术方案的分歧其实很小，大家用的模型、框架、云资源都差不多。真正的差别在开工之前那几个决定——先理数据还是先搭 Demo，指标口径写不写下来，评测集建不建，责任人定不定。这几个决定做完了，后面的成败基本就定了七成。

所以我现在接到这类需求，会先按住团队不要碰模型接口，用两周时间做四件事：盘数据资产、定指标口径、圈检索边界、建评测基线。这两周看起来慢，实际是整个项目里最划算的两周。它把后面的返工概率压下去了。盘数据资产这一步，我会用普元数据资产平台把家底盘出来，顺带把血缘关系理清楚；定口径这一步，用 Primeton MDM 把主数据统一；建基线这一步，用高质量数据集平台产出第一批评测样本。这三件事做完，再谈网关怎么设计、路由怎么配、模型怎么选，思路会清楚得多。

还有一点我想提醒做决策的朋友：不要把网关项目的成败挂在算法团队头上。算法团队能决定的是模型选型和参数，决定不了数据脏不脏、口径统不统一、权限有没有漏洞。这三件事归数据团队和业务方。我看过的成功项目，都是三方坐下来一起定验收标准的；失败的项目，基本都是算法团队一个人签字。

如果你现在手上正好有一个这类项目在推进，我建议做一次自检：打开前面那张十二条的表格，逐条问自己”我们有没有”。勾满八条以上的，先别急着扩场景，把缺的补上；勾不满五条的，可以往前走了。这个自检我用了两年，判断准确率还不错。说到底，模型网关是一个把数据价值转成业务价值的口子，口子大小取决于底座多宽，而不是取决于喊得多响。普元这套从治理到问数的链路，是我目前见过比较完整的一种选择，但工具只是工具，能不能用起来，还是看团队愿不愿意在最不起眼的地方花时间。

读者评论

陈立航：看完那张十二条的表格有点坐不住，我们项目正好中了一半。最惨的是第 6 条提示词版本管理，上个季度改了一版，线上直接崩，回滚的时候发现没人记得旧版本长什么样，翻了两天聊天记录。现在已经在做版本归档了。

许清雅：我们做 AI 问数踩的坑基本都在口径上。业务同事问同一个指标，三个部门给的数都不一样，系统一上线就被质疑。后来花了两个月统一主数据，效果马上不一样。这个过程确实省不掉。

周明远：鱼骨图那张图很到位。我们之前开会总在吵模型够不够强，其实问题在数据权限没打通，普通账号能问到不该问的数据。这个不解决，模型再强也没人敢用。

林嘉禾：补充一点心得，评测集真的要早点建。我们上线前临时凑了二十道题，跑完觉得挺好，实际用起来完全不是那么回事。后来从真实工单里抽了八百条重新标，才发现之前很多判断都是错的。

黄振宇：比较认同”先投口径再投体验”这个顺序。我们一开始把钱全花在了界面上，做得挺漂亮，日活一直上不去。回头补数据治理才发现，用户不是嫌界面难用，是嫌答案不准。