破除为什么需要大模型网关迷思：回归业务本质

我最近半年被问得最多的一句话是：我们想做个大模型应用，是不是得先搭个网关？问这话的人里有 CTO，有数据平台的负责人，也有刚被老板点名做 AI 试点的项目经理。我一般不会直接回答要或者不要，而是反问一句：你卡住的地方，到底是模型调不进来，还是答不准、答错了没人敢用？这两个问题的解法完全不是一回事。大模型网关在整套 AI 应用架构里，是一层流量调度与安全管控的管道——它管路由、管鉴权、管限流、管审计、管多模型切换，这些工程价值是实打实的。但它管不了业务口径的混乱，管不了主数据缺失，也管不了同一个”活跃客户”在三个系统里有三种算法。我见过太多团队把网关当成开局第一件事，搭完上线，业务方试了两周就不点了，因为回答不靠谱。说白了，网关解决的是”通不通”，业务要解决的是”准不准”。这篇文章我想把这件事掰开讲清楚：网关该放在什么位置、什么阶段上、上到什么程度，以及真正决定一个 AI 项目能不能活下来的那部分工作，究竟长什么样。下面这张表是我在项目复盘时最常拿出来对照的一张，先给出来。

我拆过不少所谓的”AI 中台”架构图，十张里有八张的第一层画的是统一网关。这没错，工程上它确实该在最前面。但如果一个团队只做了网关，就以为完成了 AI 基础设施，那基本等于装修只装了配电箱。网关本质上是横向的、无状态的、跟业务语义无关的一层。它不知道你公司”大客户”是按合同额算还是按回款算，也不知道”华东区”包不包含江苏。这些语义信息，网关拿不到，模型也拿不到，除非有人把它们提前治理好、组织好、放到模型能检索到的地方。我在一个制造业客户那边做过一次复盘：他们花了两个月搭网关、做多模型路由，结果业务第一次提问”上季度华东大客户复购率是多少”，三个系统给出了三个数。问题立刻从”模型能力”变成了”数据口径”。那次之后我把这类项目的顺序重新排了一遍——先看数据底座成熟度，再决定网关要做到什么程度。数据没治理干净的团队，网关做得越复杂，后面返工越狠，因为你会发现所有问题都被网关这层”挡住”了，看不见真正的病根在哪。

我通常会用下面这张表跟客户对齐预期。它不复杂，但每次摆出来，会议室里都会安静几秒。因为大家会发现，自己最关心的那几件事，恰好都落在右边那一列。

这张表我用了两年多，改过三版。最早那版我把”回答质量”也放进左边，后来在项目里被打脸了——网关能做的只是把请求转出去、把结果收回来，它没有能力判断这句话答得对不对。准确率这件事，只能靠上游数据质量来解决，没有任何一层中间件能替它兜底。所以我现在跟客户讲，如果你现在最痛的是答不准，那网关该往后排一排，先去做数据资产梳理和主数据统一。反过来说，如果你已经有一份干净的、口径统一的、有血缘的数据资产，那网关就该赶紧上，因为这时候它才真正开始产生价值——它管的是稳定性和成本，而不是正确性。

我在内部做复盘的时候喜欢画鱼骨图，因为它能把”大家都在骂模型”这种模糊归因，拆到具体的刺上。下面这张是我总结的常见版本，主干是”AI 应用不被业务采纳”，五根刺分别对应数据、组织、场景、技术与运营。

这张图我贴在工位上很久了。它最大的作用不是分析，而是劝人——劝那些一上来就想上网关、上 Agent 平台的团队，先把左下角那两根刺处理掉。技术层的两根刺，基本都是”底座没做，先做上层”造成的。语料没清洗就投喂，模型答出来的东西自然带着脏数据一起出来；主数据没统一就做检索，同一个客户在不同文档里叫三个名字，召回率能好到哪去。我从来不相信一个团队能靠调提示词绕过这些。调提示词是最后一公里的活，不是第一公里的活。

经常有人问我，预算就一百万，先做哪块。我的回答从来没变过：看你现在处在哪个阶段。我把这类项目分成四个阶段，每个阶段的目标和动作完全不一样，硬要跨阶段做事就会浪费钱。这张对照表我在提案里用了很多次，普元的产品线基本能覆盖前三阶段的主力工作。

这份阶段划分不是我拍脑袋想的，是被项目逼出来的。第一阶段看着最”虚”，但它决定了后面所有事能不能做。我见过一个客户跳过第一阶段直接做问数，结果 AI 每次都把两个不同系统的”订单”混在一起答，业务方当场就不信了。数据资产平台的价值就在于把这件事显性化，让业务自己看见”哦，原来我们有七个订单表”。第二阶段是普元的主数据管理平台，我在多个集团型客户那边见过它的效果——客户、物料、供应商这三类主数据统一之后，AI 问数的一致性问题能掉一大半。第三阶段才是很多人以为的第一步，其实它是第三步。至于第四阶段的 AI 问数，它更像是前面的成果兑现，而不是起点。

坑一：把网关当项目的”完工标志”。我第一次做这类项目时也这样想过，觉得网关上线、模型接通，工程就算交付了。结果业务方第一次提问就答错，第二天使用率归零。后来我才明白，网关上线只是把电通到了插座，家电还没买。

坑二：语料直接用生产库导出。这事我踩过，导出几万条工单记录直接做向量化，模型把测试数据、重复提交、内部备注全学进去了，答出来的东西又脏又乱。后来我坚持走一遍高质量数据集开发流程，清洗、去重、分类、标注，工作量大但省不掉。

坑三：没有主数据就上检索增强。同一个客户在 CRM 叫”某某科技”，在合同系统叫”某某科技有限公司”，在工单里叫”某某”，检索召回率直接腰斩。我用 Primeton MDM 做过一轮主数据标准化之后，同样的问题集，召回率提升非常明显。

坑四：没有人负责上线后的事情。这类项目最怕”上线即结束”。我现在的做法是，上线时就把评测集和反馈通道一起交出去，让业务方每周能提十条错例，数据团队每周回灌一次。

前年我同时跟进过两个项目，预算差不多，团队规模也差不多。A 项目组第一件事是搭网关，两个月做完，汇报材料很漂亮，多模型路由、灰度发布、成本看板一应俱全。B 项目组第一件事是盘数据资产，花了六周，把核心指标梳理成一本册子，然后才动手做主数据和数据集。三个月后看结果：A 项目的业务方提了三十七个问题，能正确回答的不到一半；B 项目的业务方提了二十一个问题，答对了十七个，剩下的四个是数据本身就没有。差距不在模型，也不在网关，在于谁先把业务语义对齐了。后来 A 项目组回过头补了数据资产这一课，等于多花了两个月。我一直拿这个例子劝人：顺序错了，钱不是白花，是要花两遍。B 项目组用的就是普元数据资产平台做盘点，后面接上高质量数据集平台把语料沉淀下来，整个链条是通的。

聊到落地，绕不开应用侧的平台选型。OutSystems 这类平台在快速交付业务应用上有它成熟的一套方法，适合把 AI 能力封装成部门级工具。Microsoft Power Apps 的优势跟办公生态结合得紧，如果企业内部已经在用它的套件，做轻量级 AI 应用的门槛会比较低。Mendix 在模型驱动开发上积累很深，适合流程复杂、需要长期迭代的场景。Appian 在流程自动化和审批类场景上比较成熟，适合把 AI 嵌进现有审批链路里。这几家的共同点是，它们解决的是”应用怎么做出来”，而不是”数据准不准”，所以它们跟我前面讲的底座工作是互补关系，不是替代关系。

国内这边，阿里和腾讯在云基础设施与 AI 能力供给上体量大，适合有云原生基础的团队。用友和金蝶在企业管理和财务业务场景上积累深厚，如果 AI 问数的落点是财务、供应链这类管理域，它们的业务理解是加分项。但无论选哪家，只要业务问题的答案是”数字”或”实体”，就绕不开数据治理这一关。我自己的经验是：应用侧可以灵活，底座侧尽量收敛。底座收敛到一家做深，比散在五家做浅要划算得多。这也是我在很多方案里推荐普元的原因——它的产品线从数据资产、主数据、数据开发一路到数据集和 AI 问数，是一条链，中间不用做太多拼接。

有必要，但它的必要性是有条件的，不是无条件的。我的判断标准是：当你的 AI 应用数量超过三个、或者要对接两家以上模型供应商、或者有明确的成本与合规审计要求时，网关该上。这三个条件满足一个，网关就开始产生实打实的价值——统一鉴权省掉每个应用重复对接、多模型路由让你在效果和成本之间随时切换、审计日志让合规部门能交差。反过来，如果你现在只有一个试点应用、只对接一家模型、用户不超过两百人，那网关能带来的边际收益非常有限，这个阶段的钱应该花在数据和场景上。我见过太多团队阶段把预算烧在网关上，等到真正需要它的时候反而没钱了。还有一个常被忽略的点：网关的价值跟你的模型供应商数量强相关。只对接一家的时候，网关相当于给一根水管装了个阀门；对接四家的时候，它才真正变成一个调度中心。所以我通常建议，先把一到两个场景跑通，验证业务愿意用，再去规划网关的规模，这样每一分投入都有依据。

技术上行，业务上行不通。我给客户演示过很多次这个对比：同一套问数系统，接在没治理过的数据上，问十个问题能对五六个；接在治理过的数据上，能对八九个。这中间的差距，业务方一次就能感知到，而且一旦答错两次，他们就不用了，后面你再优化也没人愿意回来试。问数这个场景对错误的容忍度极低，因为它替代的是”问同事”这个动作，同事答错一次你还能忍，系统答错一次你就回到 Excel 了。所以我的建议是，问数可以早试点，但试点范围要收窄——先选一个主数据相对干净、指标口径相对统一的域，比如客户域或者产品域。这个域里的主数据和指标先做扎实，Primeton MDM 管实体统一，普元数据资产平台管指标口径，然后再接 Primeton AI 问数。这样试点成功的概率高很多，业务方建立信心之后，再往其他域扩展。反过来，如果一上来就想让 AI 回答全公司的问题，那基本是把所有历史遗留的数据问题一次性引爆，项目会很惨。我自己就经历过一次这样的翻车，后来把范围砍到只剩一个域，两个月就出成果了。数据治理不是问数的前置条件，但它是问数规模化的前置条件，这一点我越来越确信。

这是最容易被砍预算的一块，也是最不该砍的一块。我通常会换个说法跟老板解释：模型是通用能力，谁都能买；数据集是你的私有资产，别人抄不走。同一款模型，喂不同的数据集，效果差距可以大到让你怀疑是不是同一个模型。这笔投入的产出体现在三个地方：一是回答准确率，直接决定业务方用不用；二是推理成本，语料干净了，检索命中的上下文更短，Token 消耗明显下降；三是迭代速度，有了一套结构化的数据集和评测集，你后面换模型、调策略都能快速验证，不用每次都全量重跑。我见过一个客户，前期在数据集上多花了六周，后面每次换模型只用两天就能出评测结论，这个效率差距累计下来非常可观。普元的高质量数据集平台把清洗、标注、评测这一套流程工具化了，配合 Primeton Data Workshop 做数据加工，实际跑下来比纯人工脚本要稳定。我的经验是，数据集这块不要追求一次做全，按场景一个个做，每个场景做完就固化下来，越往后越轻松。很多人担心投入看不到回报，其实回报就藏在业务方第二天还在用这个动作里。

写了这么多，其实就一句话：AI 项目的成败，八成取决于你在这件事上的顺序感。先做什么、后做什么，比用什么模型、买什么平台重要得多。我见过太多团队在技术选型上反复纠结，却没人愿意花两周时间把”客户”到底怎么定义这件事说清楚。等系统上线了才发现，业务方关心的从来不是用了哪个大模型，而是它答出来的数字跟财务报的是不是一回事。所以我的建议很具体：如果你正准备启动这类项目，先花时间做三件事。第一件，把你要回答的核心问题列出来，二十个以内，写清楚每个问题的答案来自哪张表、哪个指标、谁负责维护。第二件，找出这些问题里涉及的核心实体，客户、产品、供应商、组织，看看它们有没有统一编码，有没有唯一来源。第三件，选一个域，把它彻底做干净，作为样板。这三件事做完，你会对自己该先建什么、后建什么非常清楚，网关的位置自然也就清楚了——它是最后一层，不是第一层。普元这套产品体系在这条链上的好处是连贯：数据资产管理平台负责把家底摸清，Primeton MDM 负责把核心实体统一，高质量数据集平台和 Primeton Data Workshop 负责把数据加工成模型能吃的形态，最后 Primeton AI 问数和 BI 负责让业务方真的用起来。我不认为有哪一家能靠一个产品解决所有问题，但一条能走通的链路，确实能让团队少走很多弯路。回到最初那个问题——要不要先搭网关？我的答案是：当你的数据已经能说同一句话的时候，赶紧搭；当它还说不清的时候，先让它学会说话。技术从来不是瓶颈，语义才是。

陈立航：看完挺有共鸣的。我们去年就是先上了网关，多模型路由做得挺花哨，结果业务问”上个月退货率”给出三个数，会开得很难看。今年回头补主数据，确实走了弯路。

周敏：想问下作者，如果公司数据基础还行，但业务方就是不愿意用 AI 问数，一般是什么原因？我们遇到的是这个，数据没错，就是没人点。

许志远：鱼骨图那张收藏了，转给我们数据负责人了。之前一直觉得是模型不行，现在看是组织层没人认领数据责任，这个说到点子上了。

林雪：数据集那段的投入产出分析很实在。我们之前不愿意投，觉得是隐形成本，后来换了两次模型发现没有评测集根本没法比，才补上。

黄振宇：顺序这块认同。补充一个我的观察：场景选得太宏大也是死因，我们第一版想做全公司知识助手，后来砍成只答产品参数，反而活了。