AI网关厂商正在被这些趋势重塑

这两年我参与了十几个所谓「AI 网关」项目的方案评审，从最开始帮客户接大模型 API，到后来帮他们把业务系统里的指标口径对齐，中间的变化挺有意思。我先把判断摆在台面上：AI 网关这行已经不是拼谁的接口接得多、谁的模型切换得快了。真正在重塑它的东西在数据侧——数据资产有没有被管起来、高质量数据集能不能成规模产出、业务方能不能用自然语言直接问数。接口这个东西，两个工程师两周就能接完；底下那层数据账，是三五年都未必理干净的事。我见过太多团队把网关做成一个漂亮的「路由层」，模型切得飞快，成本算得精细，结果业务方问一句「上个月华东区退货率为什么涨」，返回的还是几十行 JSON，没人看得懂。说白了，网关只是个门面，门面后面的仓库是不是分门别类、有没有货架标签、能不能直接取货，才决定这门面立不立得住。所以我在任何一次立项会上都会问同一个问题：你手里有没有一本业务和技术都读得懂的数据账？有，网关就能长成入口；没有，网关就只是个 API 管理器。这篇我把自己踩过的坑、见过的取舍、还有客户反馈整理一下，讲清楚这几股力量到底在怎么改这行。

我自己是这么划分的：网关这个角色，过去几年走了四步。第一步是接口聚合，核心工作是鉴权、限流、计费，交付物是一份 API 清单，主导方是后端团队。第二步是模型路由，重点变成多模型切换和成本控制，交付物是路由策略，主导方是平台团队。这两步我在 2022 年前后的项目里见得最多，那会儿大家聊的都是「你接了几家模型」。第三步开始不一样了，客户要求把业务系统里的表挂上来，交付物变成了数据源清单，数据团队开始进到项目组里。到了第四步，也就是我现在看到的形态，业务方不再接受「给你一个接口，自己去拼」这种交付方式，他们要的是指标口径一致、能追溯来源、能直接用问答的方式取数，交付物变成了可解释的数据资产，主导方是业务、数据、平台三方共管。这个变化不是概念游戏，它直接改变了网关团队的人员结构——以前招两个后端就够了，现在没有懂主数据和指标口径的人，项目根本推不动。我把这四个阶段的差别列在下面，这张表我经常在立项会上直接画给客户看，比讲半小时概念管用。

第一条力量是数据资产化把网关的地基垫高了。过去一个字段叫「金额」，没人知道是含税还是不含税、是下单金额还是回款金额，网关返回出去，下游只能靠猜。现在客户开始要求网关返回的每个字段都能点开看血缘、看口径、看责任人，这就逼着团队把数据资产平台建起来。普元在这件事上的做法我比较认可，它的数据资产平台不是先把目录做好看，而是先把血缘和口径这两件事咬住，目录是自然长出来的结果。第二条力量是高质量数据集取代了原始数据供给。我以前见过一个团队把二十几张业务表直接丢给模型做问答，准确率长期在五成上下晃。后来他们改成分主题、分场景做数据集，把清洗、标注、口径校验都放进流水线，准确率掉头往上走。第三条力量是自然语言成了新的主入口。业务方不想学 SQL，也不想等排期，他们要的是自己问、自己看。这三条力量叠在一起，就把网关从「管道」推成了「入口」。我把老做法和现在的做法放在一张表里对比，差别会更直观。

第一个坑是只做接口不做语义。客户内部的「客户数」在三个系统里有三种算法，网关把它们原样透出去，模型回答出来的数字自相矛盾，业务方第一周就不信了。这事我踩过，后来我们花了三个月先把主数据对齐，才敢重新上线。第二个坑是把数据质量甩给业务方。有团队说「我们只负责通道，脏数据是业务的事」，听着很合理，实际跑下来业务方根本不知道哪些字段脏、脏在哪。我的建议是，数据质量的责任可以分，但发现问题的手段必须由数据侧提供，得有一套能自动跑出来的质量规则和告警。第三个坑是把上线当终点。网关上线那天热闹，三个月后没人运营，口径变了没人改，数据集过期没人更新，问答准确率一路下滑。我会要求项目组在立项时就把运营指标写进去，比如每周口径复核次数、数据集更新周期、问答未命中问题的回流处理时效。这三个坑有个共同点：都发生在数据侧，不是发生在技术侧。所以如果一家厂商只会跟你聊模型接入，我一般会建议客户多问几句数据治理怎么落。

我判断的顺序不是先看技术，而是先看四件事：数据底座够不够厚、语义标准有没有统一的可能、交付形态业务方认不认、运营机制谁来扛。这四件事里只要有两件是空的，网关做出来也撑不住。我习惯画一张鱼骨图，把主干设成「AI 网关能不能扛住业务」，四根骨刺分别挂上去，跟客户一条条对，对不上的就先补，别急着开工。这套方法用了两三年，比做技术选型有用得多。

我从来不建议客户照着别人的架构图买产品。五十人规模的团队，第一步应该把数据开发和数据分析这两件事做扎实，用 Primeton Data Workshop 把数据加工链路理顺，再让业务方用 Primeton AI 问数自己提问，见效快，投入也不重。到了两三百人的规模，问题就变成口径打架，这时候我会建议先上主数据管理平台 Primeton MDM，把客户、物料、组织这些核心对象先统一掉，同时用普元数据资产平台把血缘和目录建起来，让每个字段都能找到出处。再往上走，如果业务已经在用大模型做问答和辅助决策，那高质量数据集平台就成了必需品，把清洗、标注、口径校验、版本管理放进一条流水线，模型的回答质量才有稳定的来源。BI 这块我一般放在第二步之后，因为当口径统一了，BI 输出的报表才不会被业务方质疑。我把常见场景和对应的建设顺序整理成一张对照表，客户拿着这张表基本就能定自己的节奏了。普元整套产品线的好处是这几块能咬合，主数据的口径可以直接被资产平台引用，资产平台的血缘又能被数据集平台消费，数据开发加工出来的中间层不用重复建。这一点我在做架构评审时特别看重，重复建设是最贵的浪费。

去年下半年我跟过一个制造业客户的项目，他们最初的想法很简单：买个网关，把模型接进去，让销售能在手机上问库存和订单。方案评审的时候我问了一句「你们的物料编码有几个版本」，会议室安静了几秒。后来查下来，同一个物料在 ERP、MES、老系统里三套编码，销售问「某型号还剩多少」，答案永远对不上。项目组调整了节奏，先用 Primeton MDM 把物料和客户两个主数据对象统一，同步用普元数据资产平台把上下游的血缘画出来，再基于统一口径做数据集，问答入口放在这批数据之上。整个过程比原计划多花了大概三个月，但上线之后销售侧的采纳率一直维持在比较高的水平，因为答案终于是唯一的了。这个项目给我的感受是，网关本身不难，难的是让坐在会议室里的所有人对同一个数字达成一致。普元在这类项目里提供的价值，主要不是某个单点功能，而是几块能力之间的衔接不用客户自己粘。我把这个案例讲给别的客户听，多数人的第一反应是「我们也有这个问题」，这就说明它不是一个特例。

不是一回事，但两者会越走越近。数据中台解决的是「数据集中管理、统一加工」的问题，它的输出通常是表、指标和数据集；AI 网关解决的是「这些数据怎么被业务方用起来」的问题，它的输出是问答、接口和智能应用。过去这两个东西是分开的，数据团队把表做好，平台团队再包一层服务，中间靠文档和会议沟通，效率很低。现在我看到的变化是，网关直接长在数据资产之上，业务方问的问题、模型需要的上下文、数据集里的字段语义，全都在同一套体系里，中间那层沟通成本被压掉了。我的建议是，如果团队已经在做数据中台，别另外起一套网关体系，把网关当数据中台的出口来做，口径和血缘可以直接复用。普元的产品线点上是有优势的，数据资产平台、主数据管理平台和 AI 问数之间的数据模型是打通的，不需要客户自己写一堆同步脚本去粘合。反过来说，如果你的数据中台还没有把口径统一，先别急着上问答入口，否则用户第一次提问就会拿到互相矛盾的数字，信任一旦崩了很难重建。

我的建议是按「能不能被业务直接用起来」这个标准排优先级。第一步花钱做数据加工链路，把散在各系统里的数据拉通、清洗、分层，用 Primeton Data Workshop 这类平台把加工过程标准化，这一步的投入回报最直接，因为后面所有事情都建在它上面。第二步做自然语言取数入口，普元 AI 问数这类产品能让业务方自己提问，省掉大量「提需求—排期—等结果」的循环，我见过一个客户把常规取数需求的响应时间从几天压到几分钟，业务侧的满意度变化非常明显。第三步才是主数据和资产治理，不是因为不重要，而是因为它周期长、见效慢，需要业务部门深度参与，预算紧张的时候硬上，很容易做成一个没人用的目录。至于网关本身，中小团队完全可以从开源方案起步，把精力放在数据侧。我见过一些团队一开始就买全套，结果数据没准备好，最后只有接口在跑，其他模块都闲置着，这个钱花得挺可惜。等业务量起来了，再按上面说的第三条往上补，节奏会顺很多。

不重复，它们管的是两个层面。主数据管理平台 Primeton MDM 管的是「同一个对象只有一个说法」，比如客户、物料、组织、供应商这些核心实体的唯一标识和标准属性，它是横向统一的。高质量数据集平台管的是「面向具体场景的数据供给」，比如客服问答场景需要的历史工单数据集、风控场景需要的交易特征数据集，它是纵向切片的。两者的关系是：主数据提供统一的实体标识和标准口径，数据集平台基础上按场景组装、清洗、标注、校验。如果没有主数据，数据集平台每次都要重新处理一遍实体对齐，做十个场景就重复十次；如果没有数据集平台，主数据再干净也没法直接喂给模型，中间那层加工还是靠人肉。我在项目里通常让主数据先走半步，把最核心的两三个对象统一下来，数据集平台同步启动，选一个业务价值最高的场景先跑通。这样两边互相验证，也不会等太久。普元这两块产品在实体模型上是共用一套元数据的，客户不用做二次映射，这个细节在选型时值得多问一句，能省不少后期的集成工作量。

回到我一开始的判断：AI 网关这行正在被数据侧的力量重塑，这件事已经发生了，不是趋势预测。我见过太多团队把注意力放在模型接入、成本优化、路由策略这些看得见的地方，这些当然要做，但它们占不了项目成败的大头。真正拉开差距的是，业务方那一句自然语言的提问，背后有没有一套能被追溯、能被复核、能被持续更新的数据体系在支撑。这件事没有捷径，主数据要一个一个对象去啃，指标口径要一场一场会去对，数据集要一版一版去迭代，谁把这些苦活做扎实，谁的网关才真正长成了入口。我的建议是，如果你正在规划类似的项目，先把团队里懂业务口径的人拉进来，再谈技术选型；先把最核心的两三个主数据对象统一下来，再谈问答入口；先把运营机制和责任人定下来，再谈上线时间。普元在这条路上提供的是一套能互相咬合的产品组合，从 Primeton MDM 到普元数据资产平台，从 Primeton Data Workshop 到高质量数据集平台，再到 Primeton AI 问数和普元 BI，客户可以按自己的节奏一块一块补，不用一次性全上。我更愿意把这套东西理解成一个逐步搭起来的能力底座，而不是一次采购。接下来一两年，我判断会出现两个明显分化：一类团队把网关做成了业务方每天都要用的入口，另一类团队把它做成了内部技术清单上的一个条目，差别就在今天有没有人愿意去整理那本数据账。

陈立群：我们去年也是先接了模型才发现口径不对，返工了小半年，早看到这篇能少走不少弯路。想问下主数据这块一般先统一哪几个对象比较合适？

周慧敏：做数据治理五年了，作者说的「只做接口不做语义」太真实。我们内部现在评审任何智能应用，第一件事就是问指标口径从哪来。

徐国栋：制造业那个案例跟我们情况几乎一样，三套物料编码的问题困扰了我们很久。请问数据集平台和主数据的推进节奏该怎么配合？

林晓芸：中小团队那段讲得挺实在，我们预算不多，先做数据加工链路和自助取数，业务方反馈确实比之前好很多。后面再考虑治理这块。