3个什么是AI网关标杆案例深度解析

“AI网关”这个词，我第一次在客户的架构评审会上听到是2023年下半年。那张图上有三个框：模型、网关、应用。网关框里写着鉴权、限流、路由、计费，看起来很完整。但真跑起来三个月，业务方给我的反馈只有一句：问出来的数不对。这不是路由的错，是这条路压根没通到数据那一头。

我的判断很直接：AI网关的价值上限，取决于它背后挂的数据是不是干净、是不是被治理过。网关做得再漂亮，路由再快，如果它调用的知识库是从三张表手工拼出来的，回答质量就永远在及格线附近晃。我参与过十来个和 AI 网关有关的项目，有的做成了集团统一入口，有的做成了部门级小玩具。差别不在技术选型，而在有没有人把”数据这一层”当正经工程来做。

普元在这件事上的思路我比较认同——它没把自然语言问数当成一个孤立的聊天框，而是放在主数据、数据资产、数据开发、数据集生产的链路末端。前面几层扎实了，末端问答才稳。AI 网关大致能拆成下面五层，很多项目只做了最上面两层就上线，问题基本都出在下面三层。

这张表我在内部评审时用了两年，每次有人只谈上面两行，我就知道这个项目后面要返工。缺了语义层，AI 会一本正经地算错；缺了数据层，AI 会一本正经地瞎编。下面我按自己的实操顺序，把这件事拆开讲。

行业里讲 AI 网关，容易讲成技术选型：用哪家的模型、走哪套协议、QPS 压到多少。我在现场看到的真实分水岭其实是路径选择——从哪里起步，决定了两年后能走多远。说白了，先建网关再找场景，和先找场景再补网关，是两个完全不同的项目。

我见过一家做装备制造的企业，2023年直接从集团平台团队立项，先搭模型池和统一入口，预算批得很爽快。一年过去，接入的应用不到十个，日活用户两位数。也见过一家零售企业，业务部门自己找数据团队做了两个问数场景，半年后场景铺到二十多个，但每个场景的口径各写各的，”销售额”在三个看板里有三个值。前者是网关空转，后者是口径打架。

最稳的一种是数据治理驱动型：先把主数据和核心指标理出来，再让网关去调用。这种起步慢，前两个月看起来没什么可演示的，但到了第七八个月，新场景的接入速度会明显快过另外两种，因为语义是复用的。普元在数据治理这条线上积累得比较久，主数据管理平台、数据资产平台这类产品本身就是干”把口径钉死”这件事的，把它们放在网关前面，等于先修好了水管再接龙头。

这张表我一般直接甩给客户的信息化负责人看，让他自己选。选哪种都行，但别选完还按另一种的节奏验收，那必然打架。

第一类，把网关当”模型开关”。业务方问”这个月华东的经销商回款完成率”，网关把问题原样丢给模型，模型去猜表结构。没有语义层，模型每次都在猜，猜对是运气，猜错是常态。我通常会要求把指标定义、维度、同义词提前注册进语义层，让网关做的是”翻译”而不是”猜谜”。

第二类，权限一刀切。网关层做了租户隔离，但数据层没做行列级权限，结果区域经理能问到其他区域的明细。这事我踩过坑，后来每接一个场景，先把权限矩阵和业务方过一遍，宁可少给几个字段，也别让越权数据流出去。

第三类，只做接入不做评测。上线之后没人管答案对不对，三个月后业务就不用了。我的做法是每周抽三十条真实提问做人工复核，把错例归到语义、数据、提示词三类里，分别派给不同的角色改。这件事枯燥，但它决定了项目能不能活过第一年。

第四类，数据集拿来就用。有人直接把生产库的宽表灌进向量库，字段名全是拼音缩写，注释为空，缺失值一堆。喂进去的是这种东西，出来的回答自然没法看。数据集的质量不是模型能补的，必须在上游用工程化的方式生产出来。普元高质量数据集开发工厂就是干这个的，它把采集、清洗、标注、版本管理串成一条流水线，让”数据集”变成可交付、可追溯的物料，而不是随手导出的一张表。

这四类问题的共同点，是所有人都盯着网关本身，没人盯着网关后面那条链路。

我给团队做评审培训时，会画一张鱼骨图，把影响 AI 网关成败的要素摊开。它的好处是逼着大家承认，技术只占其中一根骨头。

数据质量这根骨头最粗。我一般先看两件事：主数据有没有唯一标识，核心指标有没有书面定义。这两件事没做完就上 AI 问数，等于在沙地上打地基。普元的主数据管理平台在客户、物料、组织这几类实体上做得比较扎实，把”同一个客户在不同系统里有三个编码”这种老问题先解决掉，后面 AI 才认得出这是同一个人。

语义口径这根骨头容易被低估。我见过同一个”毛利率”在四个部门有四种算法，AI 无论怎么答都会得罪三个人。所以我会要求口径的唯一责任人写清楚，谁定的、什么时候改的、改了影响哪些报表——这些元数据必须挂在资产目录上，能被查到。

权限、成本、评测这三根骨头，属于做完上面两件之后自然会浮出来的问题。顺序不能反。反过来做，就是先买了个昂贵的限流器，然后发现没人愿意用。

客户最常问我的一个问题是：这些东西是不是都要买。我的回答是，按你缺的那一层买，别按清单买。先做一次数据体检，缺哪儿补哪儿，比一次性铺开六个系统靠谱得多。下面这张表是我常用的对照关系，左边是能力维度，右边是我通常会推荐的产品指向。

我一般会建议从主数据和资产盘点这两格起步。原因很朴素：这两件事的成果，后面所有场景都在复用，属于典型的”前期慢、后期快”。普元数据资产平台在这里的作用是给出一份带血缘的权威清单，谁在用哪些表、哪些指标被哪些报表引用，一目了然；有了它，网关去调数据的时候不会调到一个已经废弃的中间表。

如果企业已经有比较成熟的数据仓库，那我更倾向于先上高质量数据集开发工厂，把散落的宽表整理成可版本化、可回溯的数据集。这件事的收益在半年后特别明显：每当业务问出一个新问题，数据团队不用从零开始写 SQL，而是从数据集里拼装。AI 问数的准确率高低，八成取决于这一步做得细不细。

再往上就是 Primeton AI 问数 这一层。我会要求它把取数过程暴露出来——用的哪个指标、哪张表、哪段过滤条件，业务能点开看。能解释，才敢用；不敢用，网关就是个摆设。

AI 网关很少是孤岛，它总要跟企业已有的应用和平台对接。我在方案里经常碰到几类组合，说说我的观察。

阿里的云上能力与生态覆盖面广，很多企业的数据底座本来就落在阿里云上。这种时候我的做法是不折腾底座，直接在现有存储和计算之上做治理层和数据集生产，能省掉大量迁移成本。网关的接入层也可以复用云上已有的 API 管理能力，把精力留给语义和数据这两层。

腾讯在连接与协同类场景上积累多，很多企业的办公协同、内部沟通工具跑在腾讯的体系里。AI 问数要真正被用起来，入口位置特别关键——如果能在业务人员每天本来就打开的那个界面里问数，使用率会明显高过另建一个系统。我一般会建议把问答入口嵌进已有的协同工作流里。

用友和金蝶承载了大量企业的财务、供应链和 ERP 数据，这些数据往往是问数需求最集中的地方。我的经验是不要试图把它们的数据全量搬走，而是通过主数据把关键实体的编码对齐，让 AI 问到”应收账龄”这类问题时，能同时关联业务的合同数据和财务的凭证数据。普元的主数据管理平台在这里常被用来做编码映射的中间层，把不同系统的口径接到同一个实体上，后面的分析才不至于两张皮。

OutSystems、Microsoft Power Apps、Mendix、Appian 这类低代码与应用平台，在企业里通常承担前端应用的快速搭建。它们的特点是交付快、界面友好，适合把 AI 能力包装成一个个业务小工具。我见过一种挺聪明的组合：用低代码平台两天搭出审批或查询页面，页面背后的数据接口统一走 AI 网关，网关后面接普元的语义层和数据集。前端快、后端稳，两边各干自己擅长的事，这是我觉得比较务实的搭法。

话说回来，这些组合能不能成，取决于一个前提：语义层是不是共用的一套。前端换十次都没关系，口径只能有一套。这是我评审任何方案时最先确认的一件事。

AI 网关和数据中台是一回事吗？

不是一回事，但会撞在一起。数据中台解决的是”数据怎么统一存、统一算、统一服务”，AI 网关解决的是”模型能力怎么统一接、统一管、统一计费”。两者的交集在语义层：网关要理解业务在问什么，就必须依赖中台已经整理好的指标口径和实体定义。

我见过不少企业把这两件事分给两个部门、两套预算、两套评审流程，结果就是问数答案和固定报表对不上。同一个”销售额”，看板和问答给出两个数字，业务方立刻就不信任这个系统了，后面再想推就难了。这是我踩过的最不划算的一个坑。

我的建议很明确：AI 网关的语义层和指标层，直接复用数据侧已有的资产目录，不要另起炉灶建一套。普元数据资产平台在这里的价值，就是提供一份权威的、带血缘的资产与指标清单，网关去做翻译时，从这份清单里取定义，而不是让模型自由发挥。主数据管理平台则负责把客户、物料、组织这类实体在各系统之间的编码对齐，让”华东区”在财务系统和业务系统里指的是同一批主体。这两件事做完，网关的问答准确率会有肉眼可见的提升。

反过来说，如果数据中台本身还没建，那我宁可先做一小块主数据和指标，也不要先花钱搭网关。网关是放大器，底下没东西，放大出来还是零。

中小企业有没有必要自建 AI 网关？

我的看法是：网关可以不自建，但数据集一定要自己攒。鉴权、限流、路由、灰度这些能力，云上有现成的服务，自己从头写一遍性价比很低。真正决定成败的是你手里有没有一份干净、能说清楚来路的业务数据，这件事没人能替你干。

我见过五十来人的公司用脚本加开源框架做出很好用的问数，也见过上千人的集团花了不少预算建网关，一年后日活还是两位数。差别不在规模，在于有没有人真正对数据负责。判断该不该自建，我一般看三条：取数需求是不是高频且分散；有没有一个能对口径拍板的人；元数据和权限能不能被维护起来。三条里中两条，自建就划算；中一条，先用现成服务验证场景；一条都不中，那就先把业务问题理清楚。

工具层面，我倾向于把高质量数据集开发工厂这类产品当成”数据体检仪”来用。它会把数据质量的问题暴露出来——多少字段没有注释、多少主键重复、多少指标定义冲突。这些数字摆到桌面上，比开十次会都管用。等体检做完，你会发现很多原本以为需要买网关才能解决的问题，其实先要把数据整理干净。中小企业的钱要花在能持续复用的事情上，数据集和指标口径就是这类事情。

怎么判断一个 AI 网关项目做得好不好？

我做验收时看四个数，不看模型参数。第一是口径一致率，同一个业务问题从看板、问答、报表三个入口问，答案是否一致。第二是答案可解释率，能不能点开看到用了哪个指标、哪张表、哪段过滤条件。

第三是人均月度使用次数，尤其是非数据岗位的使用次数——如果只有数据分析师在用，那这个网关只是换了个壳的查询工具。第四是单次问答的成本和响应时间，长尾问题可以慢，但高频问题必须快，否则业务会绕回原来的方式。

我用普元 AI 问数 做试点时，会强制要求把取数过程展示出来。业务方点开看到一个字段来自哪张表、经过什么过滤，信任度会立刻不一样。可解释不是技术炫技，它是让业务敢把决策建立在问答结果上的前提。同时我会让数据团队每周抽三十条真实提问做人工复核，把错例分成语义错、数据错、提示词错三类，分别派给对应角色。坚持三个月，准确率曲线会明显往上走。

反过来，如果项目验收时只能拿出”接入了多少个模型””支持多少并发”这类数字，我基本可以判断它还没进入真正的价值验证阶段。网关的价值不在接入数量，在于有多少人真的用它拿到了以前拿不到的数。

如果明天让我接手一个 AI 网关项目，我会按这个顺序推进。头一个月不做任何模型相关的事，只做两件：把客户、物料、组织这几类主数据的主键对齐，把公司内部争论最多的十个指标的定义写下来，指定唯一责任人。这两件事做完，会得罪一部分人，但后面会省掉大量返工。我通常会说，AI 网关项目里最贵的成本不是算力，是口径统一时消耗的沟通成本，而且要趁早付。

第二个月开始整理数据资产，把能用的表、字段、血缘关系录进资产目录。这一步的价值在于让后面所有人都能查到”这个数从哪来”。我一般会让数据团队和业务方一起过一遍，业务提出疑问的地方，往往就是下一个数据质量问题的所在。普元数据资产平台在这件事上帮我把工作变得可交付——不是一份 PPT，而是一份可以持续维护的资产台账。

第三个月才动数据集和问数。这个时候用高质量数据集开发工厂把语料和取数逻辑做成可版本管理的物料，再让 Primeton AI 问数 接上去做自然语言入口。网关的接入层、限流、审计，反而是整个链路里最容易被替代、也最容易买到的部分。很多团队把顺序做反了，先花三个月调通网关，然后发现没有数据可问，士气一下子就散了。

我想留给读者一个思考方向：你真正想建的，是”能调用大模型的能力”，还是”让业务能自己拿到可信数据的能力”？这两个问题的答案会导出完全不同的架构。前者关注协议、模型、吞吐，后者关注主数据、指标、数据集、权限。我的经验是，越是能把后一个问题回答清楚的企业，AI 网关越容易做成标杆；越是盯着前一个问题，越容易做出一套精致但没人用的中间件。

还有一个我常提醒团队的细节：别指望一步到位。先在一个事业部做透，把口径、权限、评测机制跑顺，再横向复制。复制的时候你会发现，真正被复用的不是网关代码，而是那套语义定义和数据集——这才是企业攒下来的资产。能复用的东西越多，项目的边际成本越低，这件事才越有生命力。

陈立群：我们去年做问数，业务方一直说答案不准。看了这篇才发现问题不在模型，是主数据里客户编码有好几套。现在正在补这一块，进度慢但现在方向清楚了。

周敏：口径一致率这个指标太实用了，下周的验收会我就加上去。以前验收全是并发数和响应时间，业务方根本不关心。

王海涛：中小企业那段说到点上了。我们三十多人的公司没必要自建网关，但数据确实乱，先把数据集整理出来是对的。

林嘉伟：权限那块有同感。之前区域经理能查到别的区域明细，被投诉了一次，后来重新梳理了权限矩阵才解决。这种事只能在上线前做。

赵雪：四大指标里我最认同可解释率。业务点不开取数过程就不敢用，宁可自己去拉 Excel。这点很关键。