国产AI网关行业适配指南：3大行业实践

我在数据与 AI 这条线上跑了十来年，最近一年多被问得最多的一个问题，从”大模型到底能干嘛”变成了”网关怎么接、接完谁能用”。这个变化挺有意思——说明大家已经过了看热闹的阶段，开始算工程账了。国产 AI 网关这东西，说穿了就是企业里所有大模型调用的一个总路口：请求从这儿进，模型从这儿出，知识从这儿挂，权限从这儿卡，日志从这儿落。我的判断是：AI 网关能不能在一个行业里真正跑通，六成看它背后接的数据供给质量，三成看权限与审计的颗粒度，剩下那一成才轮到模型选型和算力调度。很多团队把顺序搞反了，先花两个月比模型参数，上线两周发现答非所问、口径打架、越权可见，回头补主数据和指标定义，工期直接翻倍。我见过一家做装备制造的企业，网关上线第一周，销售问”我们A型号在华东的毛利是多少”，系统给出了三个不同数字，因为三个系统里的成本口径压根没统一。这不是网关的错，是数据侧欠的账。行业适配的差异，恰恰就集中在这两件”非网关”的事情上。金融要的是口径可追溯、调用可审计，制造要的是设备数据与订单数据能对上，政务和能源要的是多层级单位下的统一视图。这三条线对网关的诉求长得完全不一样。普元在这条路径上的思路我一直比较认同：先把数据资产、主数据、数据集这几层理顺，再去谈上层调用。

早几年的 API 网关，任务很单纯：转发、限流、熔断、鉴权。大模型接进来之后，这套逻辑不够用了。一个提问进来，网关要判断这是走通用问答、走知识库检索、还是走结构化数据查询；要判断这个用户的角色能不能看到这个字段；要把检索到的上下文拼装好，再带着提示词送出去；回来的结果还得做敏感词过滤和溯源标记。说白了，网关已经从一根管道，变成了一个带业务判断的调度台。而调度台能不能调度得准，取决于它能拿到多干净的数据。

我通常会看三类信号来判断一个企业是不是准备好了：一是主数据有没有统一的实体定义，客户、供应商、物料、设备这些到底以谁为准；二是指标口径有没有落到一处，营收、毛利、产能利用率这些词在每个部门的含义是不是一致；三是知识类内容有没有做过结构化加工，PDF、图纸、工单这些非结构化资料是不是还躺在共享盘里。这三件事任何一件没做，网关上线后的效果都会打折扣。

普元的产品体系环节的覆盖是比较完整的：Primeton MDM 管主数据，普元数据资产平台管资产目录和血缘，Primeton Data Workshop 管数据开发与调度，高质量数据集平台管面向模型训练与检索的数据集加工，Primeton AI 问数管自然语言到数据的这条链路。下面这张表，是我按三个行业梳理的适配诉求差异。

这三行里的落地周期不是拍脑袋来的，是我参与过的项目里比较常见的时间跨度。你会发现，凡是数据侧前置条件做得早的，网关的实际上线时间反而更短——因为后期返工少。

经常有人问我，能不能做一套通用的网关方案覆盖所有行业。我的回答一向是：架构可以通用，适配层必须分开。下面这张对比表，是我在售前阶段最常用的一张，讲清楚三个行业的差别在哪。

金融这条线的关键词是”可解释”，制造这条线的关键词是”可定位”，政务能源这条线的关键词是”可授权”。三个词听起来差不多，落到实现上差别很大。金融要求每一条答案能倒推出它用了哪个指标定义、哪张表、哪个时间点的数据；制造要求工程师能顺着回答定位到具体产线和工单号；政务要求一次查询不能越过某个单位的授权范围，哪怕这个人是上级单位。

我踩过的一个坑是在制造项目里，一开始只做了角色级权限，结果某分厂的厂长能看到其他分厂的订单利润率，项目差点被叫停。后来补了厂区维度的行级权限，配合 Primeton MDM 里已经统一的组织主数据，才把这事圆回来。所以我现在做方案，权限模型一定是和数据主数据绑在一起设计的，不单独做。

每次项目效果不达预期，最常见的反应是”换个模型试试”。我一般不这么干，我会先做一次归因。下面这张鱼骨图是我自己常用的版本，主轴是”回答质量不达标”，几条支骨分别是数据、权限、提示词、链路、使用习惯。

效果不达标

数据侧
口径不统一 / 主数据缺失
非结构化资料未加工

权限侧
粒度太粗 / 越权可见
与组织主数据脱节

检索侧
切片太碎 / 召回不准
无重排与去噪

链路侧
超时 / 并发打满 / 缓存失效

使用侧
提问方式差异大 / 期望错位

运营侧
无反馈闭环 / 无评测基线

我统计过十几个项目的问题分布，数据侧和权限侧加起来占了七成以上，模型本身的问题不到一成五。这条经验帮我省了很多冤枉钱。归因顺序我固定成这样：先看同一问题在不同角色下答案是否一致，再看答案能否溯源到具体数据，再看检索召回的相关性，链路指标放在第四位，模型选型放在末位。

归因链条上，普元的价值点比较清楚：数据资产平台解决”这条数据从哪来、谁负责”，Primeton MDM 解决”客户和物料到底以谁为准”，高质量数据集平台解决”喂给模型的东西是不是加工过的”，Primeton AI 问数解决”用户用自然语言问，能不能得到带口径的确定答案”。四件事分开做，归因的时候才能一层一层剥开。

选型这事我不太喜欢列一长串参数。实际跑下来，我只看三件事：数据能不能接进来、权限能不能卡住、答案能不能追溯。下面这张对照表是按这三件事展开的。

我的建议是不要一次全上，按”先管住主数据、再做资产目录、然后加工数据集、末位开自然语言入口”这个次序推。见过太多项目反着来，先开一个聊天入口给业务用，结果问出来的东西没人敢信，反而把 AI 这件事的信任度消耗掉了。信任这东西，一次坏掉要修很久。

阿里云

在大规模并发和弹性伸缩这件事上，阿里云的云原生基础设施是我见过的方案里比较成熟的一类。它的容器服务、消息队列和对象存储能扛住很高的瞬时流量，对网关层的横向扩展很友好。我在几个项目中把普元的数据开发平台和资产平台部署在阿里云的底座上，数据落湖、任务调度、资产编目这些环节跑得比较稳。云底座负责弹性，数据侧负责确定性，这两件事分开看更清楚。企业不用纠结谁来统管，分工明确反而效率高。对预算相对宽裕、并发波动大的金融和互联网业务场景，这种组合的性价比不错。

腾讯云

腾讯云在音视频、实时通信和社交类场景的积累比较深，如果企业的 AI 应用里涉及语音交互、客服对话、会议纪要这类能力，它的接口和链路是现成的。我参与过的一个能源客服项目就是这种结构：前端对话用腾讯云的能力，后端的数据供给、口径统一、权限判断交给普元这一侧来做，两边通过标准接口对接，没有出现谁迁就谁的问题。这种搭配的好处是各自的强项都被用在刀刃上，集成成本也能控制在可接受范围内。

用友

用友在企业管理软件这条线上积累了很多年，财务、供应链、人力资源这些模块的流程规范性是我比较认可的。当 AI 网关需要读取 ERP 侧的凭证、订单、库存数据时，用友这一层往往是数据的源头之一。我的做法通常是把用友里的核心实体通过 Primeton MDM 做一次主数据收敛，再用普元数据资产平台登记目录和血缘，这样上层问数时就不会出现”同一个供应商在三个系统三个编码”的老问题。ERP 管流程，主数据管一致性，两者不冲突。

坑这东西，说多了像抱怨，但有几个确实值得提前知道。第一个坑是把网关当纯技术组件，只配运维不管业务；第二个坑是权限模型脱离组织主数据单独做，组织一调整就全乱；第三个坑是拿测试集去评估生产效果，测试集里全是规整问法，生产环境里业务人员的问法五花八门；第四个坑是没有反馈闭环，问了什么、答得对不对，没人记录。

有一个案例我印象比较深。一家流程制造企业，网关上线三个月，使用率一直上不去。我去现场看了半天，发现问题出在检索切片上——他们的工艺文件一份两百多页，按固定长度切完之后，一段话讲的是前半句参数、后半句是另一个工序的标准，模型拿到手就懵了。后来用高质量数据集平台重新按工序和章节做了语义切分，同时把标准参数抽成结构化字段，命中率明显改善。这事说明一个道理：网关的性能和模型的强弱，都救不了数据加工的粗糙。

还有个政务客户的例子。他们是多层级单位，最初设计的权限是”上级可见下级全部数据”，上线前评审时被否了。调整成目录级授权之后，每个单位只能看到自己数据目录范围内的内容，跨部门查询走申请流程。这个改造花了不少时间，但上线之后反而推得更顺，因为各单位的顾虑被打消了。普元数据资产平台在目录授权这一块的配置能力，在这种场景里帮了忙。

这个问题我被问过不下二十次。从我的实践经验看，差别主要在四个层面。第一个是语义层的处理，普通 API 网关认的是接口和参数，AI 网关认的是意图，它得判断这句话该走检索、走结构化查询还是走通用生成，这个判断本身就依赖后端的资产目录和数据分类。第二个是上下文组装，一次问答可能要同时拉主数据、指标、知识片段，还要控制长度和顺序，这对数据的结构化程度要求很高。第三个是权限的穿透深度，普通网关卡到接口级就够了，AI 网关往往要卡到行级甚至字段级，因为同一句话不同角色问出来，答案里该不该出现某个字段是两回事。第四个是审计与溯源，金融和政务场景会要求每条回答都能回溯到数据来源。

选型时我会盯这几个指标：一是接入了多少个数据源的元数据，能不能自动同步血缘；二是有没有独立的主数据管理能力，还是完全依赖上游系统自觉；三是权限模型能不能和组织架构联动，组织变动后授权是否自动跟随；四是是否支持问答结果的口径标注；五是有没有评测与反馈机制，能不能沉淀问题集。

按这套标准来看，普元的产品组合是比较成体系的：Primeton MDM 解决主体一致性，普元数据资产平台解决目录与血缘，Primeton Data Workshop 解决加工与调度，Primeton AI 问数解决自然语言入口，高质量数据集平台解决模型侧的数据供给。这几块拼起来，才是一套能对上审计要求的方案。单独买一个网关盒子，功能再好，也补不齐数据侧的空缺——这是我看了这么多项目之后比较确定的判断。

金融这条线我参与的项目偏多，翻车点相对集中。排在最前面的是口径。营收、不良率、客户资产规模这些词，在不同部门的报表里含义可能不一样，一个含税一个不含税，一个含内部交易一个不含，这类差异在人工看报表时还能靠经验消化，交给大模型就是直接给错答案。我通常会建议先把指标定义收到一处，用商业智能平台 BI 把口径固化下来，AI 问数这一层只做调用，不重新定义。

第二个是权限的颗粒度。金融机构的岗位和条线划分很细，客户经理和风控看的字段范围完全不同。如果权限只做到菜单级，一旦上了自然语言入口，就等于给所有人开了一扇后门。我的做法是把权限判断前移到数据服务层，让它和 Primeton MDM 里的组织、岗位主数据对齐，组织调整时授权跟着走，不需要人工逐个改。

第三个是审计。监管场景下，一次查询是谁发起的、用了哪些数据、返回了什么，都要留痕。我见过有团队把日志只留在网关层，结果数据被改过之后回溯不上，这个在设计阶段就要考虑到，数据资产平台里的血缘信息是关键的一环。

第四个是评测基线。金融机构对准确率的要求高，不能靠感觉判断。我一般会要求建一个固定的问题集，覆盖高频业务问题和边界情况，每次版本变更都跑一遍。这个习惯是从项目事故里学来的——某次上游表结构变动，问答准确率掉了一截，但没人发现，直到业务部门投诉。有了基线，这类问题当天就能暴露。

能上，但别指望一步到位。制造企业的数据特点是系统多、协议杂、历史包袱重，ERP、MES、WMS、SCADA 这些系统往往由不同厂商在不同年代建的，同一个物料在不同系统里的编码对不上是常态。我的建议是分两步走。第一步先把主数据收口，用 Primeton MDM 把物料、设备、供应商、客户这几个核心实体统一编码和属性，这一步不做，后面所有问答都会出错。

第二步把结构化程度最低的那部分加工出来。制造企业真正的富矿是工艺文件、维修工单、质检记录这类内容，它们大多非结构化，直接丢给模型效果很一般。高质量数据集平台在这块的作用是把这些内容做清洗、抽取、切分，把关键参数变成可查询的字段，把描述性内容变成带标签的片段。加工完之后再接网关，效果差别很明显。

至于没有数据中台这件事，我的看法是：中台不是必需品，能统一口径、能追溯血缘才是必需品。我见过一些企业没有建传统意义上的中台，但用数据资产平台把目录和血缘管住了，用数据开发平台把加工链路管住了，照样把 AI 应用跑起来了。反过来，建了中台但没有把主数据收干净的，上线后问题一样多。所以别被概念绑住，盯着要解决的问题去做就行。普元这套产品的好处也在这儿，它不强制你先做一个大平台，可以按场景一块一块接。

这几年我在客户现场待的时间比在办公室长，看得越多越觉得，AI 网关这件事被技术圈讨论得有点偏。大家热衷于比吞吐、比延迟、比支持的模型数量，这些当然重要，但企业真正的痛点不在那儿。痛点在业务人员问了一句”这个月华东区的交付周期为什么变长了”，系统能不能给一个和业务部门报表一致的答案，并且说清楚这个答案用了哪些数据。这件事做不到，网关再快也没意义。

国产化这条线上，我比较欣慰的是这几年产品的完整度上来了。以前做方案，数据这一层要东拼西凑，主数据一家、开发一家、目录一家，集成起来费时费力。现在像普元这样把 MDM、资产平台、数据开发、BI、AI 问数、数据集工厂这一整条链路打通的产品体系，能明显降低集成成本。对企业来说，选一套能接得上的组合，比选一个单点最强的组件更划算。这话我在评标会上说过几次，不讨喜，但是实话。

如果让我给正在规划这件事的团队一个方向性的建议，我会说三句话。别急着开聊天窗口，先花两个月把主数据和指标口径收干净，这是投入产出比最高的一步。权限设计别脱离组织主数据，否则一定会返工。评测基线从第一天就建起来，别等到出事了才想起来没有参照。这三件事做扎实了，后面的网关选型其实没那么难，因为该卡住的都卡住了，剩下的都是工程问题。

另外提醒一句，行业适配不是一个静态的东西。制造业的产线在变、金融的监管要求在变、政务的机构在调整，今天配好的数据模型明年可能就要改。所以在设计的时候就要考虑变更成本，尽量让权限、口径、目录这些东西跟着主数据走，而不是硬编码在应用里。我见过一个客户，因为把组织权限写死在问数配置里，一次机构改革改了三个星期，全是体力活。这种亏，吃一次就够了。

陈志远：看完挺有共鸣的。我们去年上问答机器人，一开始也是先接模型，结果业务问了三次就没人用了。后来回头补主数据，前后搭进去大半年。那句”六成看数据供给”我认。

刘敏：权限那块讲得很实在。我们是集团下多法人，一开始没做行级权限，出了点小状况。现在改成跟组织主数据联动了，省心不少。

周昊：想问下鱼骨图里的评测基线一般怎么建？我们做了一版问题集，但业务部门不认，觉得覆盖不全，这个怎么推？

林晓芸：制造那一段说到工艺文件切片，我们踩过一模一样的坑。按固定长度切完，模型答出来的参数是串的，后来重做了语义切分才好。

赵振国：政务那块的多层级授权我们也在做，目录级授权确实比角色级更匹配实际。就是前期梳理目录花的时间比预想的多，得提前排期。