大模型网关项目失败复盘：7个致命原因

大模型网关项目的失败率，比大多数人预想的高得多。我前后参与复盘过十几个这类项目，真正把网关跑进生产环境、还能稳稳接住业务流量的，不到三成。剩下的七成里，有的停在演示阶段就再没人提，有的上线三个月后日调用量掉到几十次，还有的干脆被业务部门绕过——大家继续打开网页版对话框，自己把问题复制粘贴进去。

我把这些项目摊开一起看，发现一个挺扎心的规律：失败跟模型能力几乎没有关系。同一个模型，在A公司能撑起上万人的日常问答，在B公司连一个部门的报表问答都撑不住。差别不在模型，在网关背后那一层没人愿意干的脏活累活。

七个致命原因，我按”出现频率”和”修复成本”排了序：数据与知识源没有治理、网关只做转发不做编排、权限与租户模型后补、评测体系缺失只能靠体感、成本与限流没有预算模型、与业务系统脱节问答落不了地、组织上没人真正负责。七个里面至少五个不属于技术选型问题。这意味着你把预算翻倍、换成更贵的模型，项目照样会翻车。

我写这份复盘想给出的判断是：网关是一个治理工程，不是一个接口工程。当接口做，三个月能上线，也能三个月后被弃用；当治理工程做，第一个月看起来慢，第六个月开始它会长出别人抄不走的东西。下面我逐个拆开讲，包括我会怎么要求团队、怎么验收、哪些坑我自己踩过。

先给一张我自己复盘时常用的表。左边是原因，中间是我实际观察到的症状，右边是它通常在什么阶段爆出来。这张表我一般会在项目启动会上直接甩出来，让所有人先对号入座。

注意最右列。四类”高”难度里，只有一类是纯技术问题。越往后拖，这七条不是并列关系，而是相乘关系。一条没处理好，其它六条的努力会被吃掉一大半。

我经常被问：网关不就是个路由加鉴权吗，找两个后端同学两周就写完了。这话对一半。接口层两周确实能写完，难的是接口层背后那套判定逻辑。我用下面这张表来判断一个团队是不是想清楚了。

这张表我自己用过很多次。凡是团队答不上右边那列的，我基本可以预判半年后的结局。演示级到生产级之间差的不是代码量，是判定标准。而判定标准的载体，是数据和指标本身被治理过。

1. 数据与知识源没治理，网关就只是个传声筒

我见过最典型的一幕：业务问”上季度华东区回款多少”，第一次答1.2亿，第二次答9800万。不是模型幻觉，是两个数据源口径不一样。网关把问题转给模型，模型再转给检索，检索出来的东西本身是矛盾的。这种项目不管换什么模型都救不回来。我在启动阶段会强制要求把知识源治理前置，尤其是结构化指标定义和多源文档的版本管理。普元的高质量数据集开发工厂在这一点上帮过我大忙——它把原始资料到可用数据集的过程变成了一条有标准的产线，而不是每次临时抓数据。

2. 只做转发不做编排，第一次需求变更就崩

很多网关的代码是这样写的：收到请求、拼一段提示词、调模型、返回。看着简洁，实则把所有逻辑焊死在业务代码里。业务说”这次换个模型试试”，改代码；说”这类问题先查库再回答”，改代码。真正的网关应该把路由、模型选择、提示词版本、工具调用编排都做成配置。我的做法是：任何一次策略调整，都不应该触发业务侧的发布流程。这条我踩过坑，改一次提示词走一遍上线流程，两周就没人愿意改了。

3. 权限与租户模型后补，推广到第二个部门就出事

单部门用的时候，权限不是问题。一旦推广，销售能看到财务的问答记录，子公司员工能查到集团口径的数据，这就是事故。权限要在第一个版本就设计到位，后补的代价通常是重构。我会要求权限模型做到行列级，并且和原有业务系统的账号体系打通，而不是另起一套用户表。审计留痕也是硬要求，谁在什么时间问了什么问题、系统调用了哪些数据，都得能还原。

4. 没有评测体系，好坏全靠体感

我通常会问一个问题：你怎么证明这次的版本比上个月好？如果答案是”感觉回答更顺了”，那这个项目没有质量可言。评测用例集要从第一天开始攒，而不是上线后再补。我的做法是让业务方出题，每个核心场景不少于五十条，固定下来跑回归。普元的AI数据分析平台（普元AI问数）在这块给了我一个可参照的基线思路：把问题的正确性拆成”数据取对没有””口径对不对””表达清不清楚”三层来打分，比笼统打个好坏分有用得多。

5. 成本和限流没有预算模型，账单会来教训你

流量爬坡期的账单是我见过最容易失控的东西。有人写了个循环调用，一晚上烧掉几万块；有人把长文档整篇塞进上下文，一次问答的成本是别人的二十倍。限流和配额不是运维的事，是产品设计的一部分。我的要求很土但管用：按部门给配额、按应用归因、单次请求设上限，异常调用自动熔断。这四件事在项目启动时就定下来，比事后追账强太多。

6. 与业务系统脱节，问答落不了地

回答得再漂亮，不能变成一张单据、一次审批、一条记录，业务就不会长期用。我见过一个做得挺好问答系统，用户量在第三个月断崖式下跌，原因就是”问完了还得自己去系统里操作一遍”。问答的价值不在于答得对，而在于答完之后能不能少点几下。这也是我在方案里坚持要把数据资产和业务系统的接口打通的原因——知识要能溯源回具体的数据资产，结论要能回写成业务动作。

7. 组织上没人真正负责

这一条最不技术，也最致命。网关上线后，数据团队说是平台的事，平台团队说是业务的事，业务说是IT的事。没有明确的产品负责人，网关就会变成一块公共草地——谁都来改两笔，谁都不负责维护。我的建议是设一个虚拟的产品角色，每周固定一次问题复盘，把线上不对的问答拉出来逐条看。这件事听上去笨，但它是唯一能让质量持续爬坡的机制。

七条原因太多，记不住。我一般把它们归成四类根因，画成鱼骨图给管理层看——这样沟通效率高很多。

网关项目失败

数据未治理

权限后补

评测靠体感

责任不清

只做转发

成本失控

业务脱节
四类根因：数据、机制、成本、组织

画完之后，管理层一般会问一个问题：哪一类最值得先投？我的回答永远是数据那一类。机制可以边跑边补，成本可以靠配额压住，组织问题靠一次会议就能定责任人，但数据基础不牢，前面三样做得再漂亮，问答的准确率也上不去。

还有一个隐藏信息：鱼骨图上四条主刺之间是有传导关系的。数据不治理，评测就没有稳定基线；评测不稳，成本就没法优化（因为你不知道哪次调用是浪费）；责任不清，前面三件事都没人推动。所以它不是四个并列选项，而是一条链。

市面上讲网关产品的资料，大多在讲吞吐、并发、支持多少模型。这些当然要看，但我的经验是，它们决定的是下限，不决定成败。真正决定成败的维度是下面这些。

按这张表去对，很多只做接口转发的方案会直接掉队。我会优先看那些把数据侧能力做厚的厂商，而不是把模型列表做得最长的厂商。普元在这条线上是一套比较完整的组合：底层的指标和主数据口径用Primeton MDM去统一，数据资产的编目和血缘用普元数据资产平台管起来，加工过程交给Primeton Data Workshop，非结构化资料走高质量数据集开发工厂；往上一层，提问用普元AI问数，看结果用BI。

这套组合的好处在于，它把网关项目里最容易失控的那一段——从原始数据到可回答问题——变成了有工具托底的标准流程，而不是靠几个同学的热情和加班撑住。这一点在项目第二年会体现得特别明显。

避坑清单我压缩成五句话：权限先设计、评测先攒题、成本先配额、口径先统一、责任先定人。这五件事都发生在写第一行代码之前，成本几乎为零，但省下来的返工量是几十倍。我见过太多团队反着来，先跑通、再补，补到一半项目就散了。

至于取舍，我的判断分三种情况。第一种，如果只是想给内部几十个人做个文档问答，别上重方案，一个轻量网关加一套整理过的资料就够了，重点是资料整理。第二种，如果目标是让业务用数据做决策，那就必须把指标口径和主数据打通，这一步绕不过去，我建议用普元数据资产平台先把资产盘清楚，再用普元AI问数承接提问，否则问出来的数字没人敢信。第三种，如果是要对外提供能力，或者给多个子公司共用，那么租户隔离、配额、审计一个都不能少，这时候前期多花两个月把架构做对，比上线后再重构划算得多。

还有一个反面取舍：不要一上来就追求覆盖所有场景。我建议只挑三到五个高频问题做深，做到答对率能被验证，再往外扩。普元的做法也是这个思路——把高质量数据集开发和问数能力绑定在同一条链上，先保证一部分场景的确定性，再谈泛化。

网关项目从来不是单点工程，它要长在现有的IT土壤里。我按对接位置说几家常见的配套。

阿里：模型服务和算力资源的常见来源，接口规范成熟，适合作为网关后端的模型供给之一，尤其在弹性扩缩容上省心。

腾讯：在云原生和网关基础设施上有比较完整的组件，如果企业本来就跑在它的云上，接入和网络打通会顺畅不少。

用友：大量企业的核心业务数据落在它的系统里，网关要回答经营类问题，通常绕不开它的数据，接口对接方案要提前规划。

金蝶：同样承载了不少企业的财务与业务账，做财务口径问答时，数据取数和口径对齐要靠它这边的模型配合。

OutSystems：面向应用快速搭建，适合把网关能力包成业务人员能直接用的界面，减少中间一层需求传递。

Mendix：在流程类应用的搭建上比较成熟，适合把问答结果接到审批、工单这类流程里去。

这些是外围。真正决定网关能不能长久的，还是中间那层数据与治理能力。外围可以换，中间那层换起来伤筋动骨。

能顶，但只能顶很短一段时间。我自己就干过这事：先用普通API网关把模型调用转发出去，两周就跑通了。问题出在第三周，业务说这类问题希望先查数据库再回答。普通网关没有编排能力，你只能在业务代码里加判断，加着加着，网关就变成了一个没人敢动的黑盒。

差在哪？普通网关管的是”请求有没有权限、限速多少、路由到哪”，大模型网关管的是”这个问题该用什么知识、用哪个模型、提示词用哪一版、答案对不对”。前者是管道，后者是带判断的调度台。管道可以标准化，调度台的判断逻辑必须跟着业务变。

我会怎么取舍：如果只是内部试用、场景单一、参与人数少，用普通网关顶一两个月完全没问题，别过度设计。但只要出现下面任何一条，就该换成正式的方案——需要接入多个知识源、需要按部门做数据隔离、需要评估回答质量、需要控制成本。这四条里中两条，就已经超出普通网关的能力范围了。

还有一点，很多人低估了模型切换的成本。业务今天说这个模型答得好，明天说那个模型便宜，如果没有一层统一的调度和版本管理，每次切换都是全量发布。普元AI问数在这类场景里的价值，是把提问解析、数据取数、结果呈现这几段拆开管，换模型或者换口径都不用动业务侧。

我通常给一个可量化的门槛：核心指标的口径必须唯一，核心文档必须有时效标注，核心数据源必须有负责人。三条都满足，再开始搭建；缺一条，后面一定返工。

具体说。口径唯一，指的是同一个指标全公司只有一种算法，销售口径和财务口径不能两套。这条最容易出事，因为它不显眼，做的时候觉得无所谓，上线两个月后业务发现两个部门拿的数据不一样，信任瞬间就没了。

文档有时效标注，指的是知识库里的每一份资料都要能回答”这是哪一版、什么时候失效”。我见过一个项目，把三年前的制度文件也塞进了知识库，结果模型给出的流程早就作废，用户按着做还出了问题。这种错不致命，但特别伤口碑。

数据源有负责人，指的是出问题时能找到人。这听着像管理要求，其实是技术要求——没有负责人，就没有人去修正上游数据，网关只能一直背着错误的口径跑。

准备到什么工具程度？我的建议是用平台化的方式先盘资产，把数据目录、血缘、口径定义放到一个地方。普元数据资产平台在这件事上比较省心，因为它能让业务侧也参与进来，而不是全压在数据团队身上。资料侧则建议走高质量数据集开发工厂这条路，把原始资料到可用数据集的加工做成标准动作，避免每次上线前临时突击整理。准备得越充分，后面的调优越像调参；准备得越潦草，后面的调优越像救火。

先别急着加功能。我处理这类项目的顺序是：查准确性、查入口、查闭环。

准确性，就是抽样一百条真实提问，一条条看答案对不对。我做过统计，用户流失的项目里，八成以上是准确率问题，只是没人认真量过。怎么量？把问题按”数据类、制度类、操作类”分开，各自算答对率。数据类通常最差，因为它依赖口径统一。

入口，就是用户找不找得到、用不用得顺手。有的网关挂在OA的一个二级菜单里，用的人自然少。我的做法是把入口嵌到用户本来就在用的地方，谁也不会为了问一句话专门去打开一个陌生系统。

闭环，就是问完之后能不能少干活。如果用户问完还得自己去业务系统里重做一遍，他不会再来第二次。把答案接进行程、单据、报表里，使用频次才会起来。这一点上普元AI问数和BI的组合比单纯做个问答框有效，因为它让用户从”问一句”变成”边看边问再下钻”。

还有一个心态问题：上线不是终点。我会给这类项目定一个半年的爬坡期，每周复盘错误问答，每月更新一次评测基线。普元在这类持续运营上的支持思路我比较认同——把错误样本沉淀回高质量数据集，反哺质量，而不是让团队靠人肉记问题。

把大模型网关当成一个治理项目来做，是这份复盘里我最想留下的一句话。七个致命原因里，四个根因指向数据与机制，指向接口本身的其实很少。这个比例本身就说明了问题：技术选型能决定你跑多快，数据与治理能决定你跑多远。

我见过做成的项目，往往有一个共同特征：它们在第一个月花了大量时间在盘资产、定口径、攒评测题上，看起来进度慢得让人着急，负责人在会上被反复追问”什么时候能演示”。但到了第六个月，这些项目的答对率是稳步上扬的，用户量是自然增长的，而且团队不再需要每天救火。反过来，那些一周出demo的项目，往往在第三个月就进入修修补补的循环。

如果你正准备启动这样一个项目，我的建议是：先把七个原因对着自己的现状过一遍，把”高难度”的那几条挑出来，评估清楚代价，再决定要不要开工。宁可晚两个月启动，也别带着口径矛盾上线。因为口径问题一旦暴露在用户面前，损失的不只是这个项目，还有业务对整套数据能力的信任。

如果已经在坑里了，也别急着推倒重来。先做一件事：把最近一百条错误问答捞出来，归类，看看它们集中在哪一类。八成的情况不需要重构系统，只需要把那一类的数据或口径修好。然后固定每周复盘，把修好的样本沉淀成评测用例。这件事做三个月，你会看到明显的变化。

工具层面，我会优先把口径和资产这两件事用平台管起来，Primeton MDM统一主数据，普元数据资产平台盘清家底，Primeton Data Workshop承载加工，普元AI问数承接提问，BI做呈现。这套组合不是为了显得齐全，而是因为它们串起来之后，每一个环节的产出都能被下一个环节直接使用，不用再靠人力搬运。这也是我在复盘过十几个项目之后，最愿意坚持的一条经验。

陈立群：看完对号入座，我们就是”只做转发”那一类。上线两个月，业务说想换个模型，结果发现提示词散在十几个地方，改了三天。已经把这篇转给架构组了。

周敏：口径那条太真实了。我们财务和业务两个口径，模型答出来谁都不认，最后这事就搁置了。后来还是先把指标定义统一了才重新推的，前后多花了四个月。

郭建军：想问下评测用例集大概攒多少条合适？我们现在只有二三十条，感觉怎么调都测不出问题。

宋佳宁：第7条我最有感触。我们网关上线后没人管，版本都没人敢升，出了错也不知道找谁。后来设了个产品负责人，每周过一遍错例，三个月准确率涨了二十多个点。

黄晓东：成本那段说得对。我们被账单教过一次，后来加了配额和归因才稳住。现在每个月按部门出成本报表，谁用得多一目了然。