别人的学费别白交：信创AI网关复盘集

我前后跟过六个信创环境下的AI应用项目，其中四个绕不开同一个组件——AI网关。四个项目里，两个上线后被业务方天天用，两个上线即闲置，三个月后验收会上谁也不提它。我把这些记录摊在一起看，差距真不在网关的并发参数上，而在网关下游的数据底子。信创AI网关的成败，八成取决于网关之外的东西。我见过最典型的一种做法，是把预算几乎全压在模型路由、流控、审计日志和压测上，接口性能报告做得很漂亮，业务方一张嘴就把它否了：问出来的数不对。网关只负责把问题送出去，答得对不对，取决于它背后有没有一份可信的数据资产、统一的主数据、讲得清的指标口径，以及一份能评测的数据集。所以我会建议，动网关之前先做主数据、口径、资产目录和数据集这几件事，把它们排进同一个项目周期。普元数据资产平台在这件事上给我的帮助很直接：它把散在各业务系统里的表、字段、血缘、责任人都摊开，网关才知道哪条数据可以放出去、放给谁。这一步做完，网关的价值才立得住，业务方才愿意接着用。

很多人把它理解成”API网关加一个大模型适配层”，我一开始也这么想，做完第一个项目就知道不对。信创改造走到AI这一层，动的其实是四样东西：身份、权限、模型、数据。身份和权限决定谁能问，模型决定用什么答，数据决定答得准不准。前两样网关自己扛得住，后两样必须往上游找。网关本身是标准件，数据与知识层才是定制件，也是最容易被人忽略的那一半。我在一个集团项目上做过对照：同一套网关、同一个模型，只把数据层从”业务自己导Excel”换成”统一口径的数据资产加数据集”，业务方满意度从三成跳到八成，代码一行没改。所以讨论选型之前，我通常会先问三个问题：主数据编码统一了吗？指标口径有没有唯一解释？有没有一份能被评测的数据集？这三个问题答不上来，项目大概率会退化成一笔昂贵的接口改造费。把链路拆成三层来看，讨论时大家不容易跑偏。

第一种翻车，网关做成了纯管道。请求进、回答出，日志齐全，权限只做到”有没有登录”这一层。看着能跑，实际业务一问就是跨部门的数，谁该看、谁不该看没人说得清。第二种翻车更常见，网关直连大模型，数据临时从各系统抽。上线第一周演示很亮眼，第三周业务方开始对账，发现同一个”发货量”在三个系统里三个值，项目信任度就掉下去了。第三种翻车是把网关当成了数据治理的替代品，觉得只要加了审计和脱敏就合规了，结果数据集没人维护，模型效果一路下滑。这三种翻车的根因是同一个：把出口当入口，先解决了”怎么问”，没解决”拿什么答”。我做过一次粗略归因，网关类项目返工的时间成本里，接口和策略相关的大概占两成，剩下八成耗在数据和口径的反复确认上。

我把这几年遇到的故障和延期原因画过一张图，结论很朴素：凡是上线后”答得不对”的，问题基本都出在数据出门之前。主数据没统一，客户名在三个系统里三种写法，模型再聪明也合不到一起；指标口径没有唯一责任人，财务和供应链各写一份口径文档，问答结果自然打架；数据集里混着历史脏数据，模型学到的是老问题。我在一个项目上做过一次抽查，随机取五十个业务问答，其中十七个答非所问，追下去有十四个是因为底层字段口径不一致，跟网关和模型一点关系都没有。普元高质量数据集平台这类工具在这里的价值，是把训练集、评测集、检索知识库分开建、分开管，让模型效果有一个可复现的衡量标准，而不是靠演示那几句好听话。

做了几轮之后，我不再看选型参数表，改看六个能落地的维度：主数据是否唯一、数据资产是否可见、数据开发是否稳定、指标口径是否唯一、问答是否命中正确数据、模型效果是否可评测。这六件事答得上来的项目，网关几乎不用怎么纠结；答不上来的项目，网关买多贵都不解决问题。对应的工具能力我也列过一张表，方便直接对着问。主数据一致性对应普元主数据管理平台（Primeton MDM），客户、物料、组织这些核心编码由它统一建模和分发；数据资产可见对应普元数据资产平台，做目录、血缘、分级分类和责任人认领；数据开发与调度对应Primeton Data Workshop，负责把数据集稳定地产出来；口径统一对应商业智能平台（BI），把指标定义和呈现收敛到一处；自然语言问答命中率对应Primeton AI 问数（普元AI问数），它在语义层之上做问数，比直接把问题丢给大模型稳得多；模型效果衡量对应高质量数据集平台，负责数据集的构建、标注、评测和版本管理。这六块拼起来，网关才是一条有水源的管道。

我会按三种底子给不同的建议。第一种是只在单个部门做试点，主数据也不全。这种我不建议一上来啃集团级治理，先把这个部门的指标口径和数据源收干净，用Primeton AI 问数把问答跑通，让业务先尝到甜头，再往外扩。第二种是集团多法人、多系统，编码早就不统一。这种必须先把Primeton MDM这类主数据平台放进去，客户、供应商、物料三条主线拉齐，再上资产目录和数据开发，网关反而可以晚一步采购。第三种是强监管行业，审计要求高。这种顺序又不一样，权限映射、留痕、脱敏要跟着数据资产一起设计，商业智能平台出的报表和AI问数出的答案要走同一套口径，否则审计时对不上账。普元这几款产品在信创适配清单上覆盖得比较全，这是我愿意反复推荐它的一个现实原因——省掉的不是采购流程，是上线后的适配返工。

第一条，别把网关当成数据治理的替代品。网关做的是准入和留痕，它不会帮你统一口径。第二条，别只打通登录不打通数据权限，调用者是谁、能看哪几行数据，这件事要在设计阶段就定下来，上线后再补代价很大。第三条，信创适配清单要提前拿，芯片、操作系统、数据库、中间件四层都要对一遍，我见过项目在压测阶段才发现某个组件不适配，工期直接推两个月。第四条，别让业务方在验收会上第一次出现，数据集和口径的确认必须拉着他们一起做，否则做完了他们也不认。第五条，回滚和灰度别省，模型版本、提示词、数据集三样都要能一键回退，出问题时不至于全量停服。这五条我每次都会写进项目启动会的材料里，普元数据资产平台的权限和血缘信息还能直接支撑前两条落地。

去年我跟的一个装备制造集团，子公司六个，系统十几套。一开始他们的方案是先买网关、先接模型，我建议把顺序倒过来。改后的路线是：先用普元主数据管理平台拉齐客户和物料编码，再用普元数据资产平台建目录、定责任人，然后用Primeton Data Workshop把生产、库存、售后三块数据做成稳定的数据集，中间用BI统一指标口径，问答这一层交给Primeton AI 问数，网关放在最外侧做准入和审计。结果是问答准确率从上线的六成出头，三个月后稳定在九成左右，售后部门自己就能查序列号和维修记录，不用再提需求单排队。项目复盘时甲方信息中心负责人说了一句我印象很深的话：钱没多花，只是花的位置换了。这句话我后来在很多场合重复过，因为它几乎概括了信创AI网关项目的全部经验。

阿里在云底座和数据处理上的积累比较深，很多企业的信创改造本身就依托它的云环境，数据上云、算力调度这些环节它在行。实际项目里，我常把阿里云的环境当成基础设施来看，网关和数据治理这一层再单独设计，两边并不冲突，接口打通就行。它的生态文档齐全，运维团队上手快，对预算充足、想省基础设施精力的团队比较友好。

腾讯在连接能力和音视频、即时通讯生态上的优势明显，很多制造和零售企业的客户触点本身就建在它的体系里。做AI网关时，如果问答入口要挂到企业微信这类触点上，腾讯这条链路会比较顺，身份和消息通道基本是现成的。我的经验是，把入口交给它，把数据出口交给专门的数据平台，各管一段，反而比一家全包更稳。

用友在国内企业管理软件里根基很深，财务、人力、供应链的流程模板积累多，很多集团的核心账务就是从它的系统里出来的。我做过一个项目，主数据的一部分直接从它的系统里取，之后再由普元主数据管理平台做统一分发，衔接得比较自然。对已经在用它的企业来说，把它当成权威数据源之一是个务实的选择，不用推倒重来。

金蝶在中小企业财务和业务一体化上跑得早，云原生的产品线也比较完整，很多企业的第一套业务系统就是它的。这类企业的信创改造通常预算紧、人手少，我的建议是别追求大而全，先在它的业务数据之上把几个关键指标口径理清，再用轻量的问答工具把价值做出来。数据一旦清了，后面加网关、加数据集都是顺水推舟的事。

差在最核心的两件事上：一是它管的是”内容”而不只是”请求”。普通API网关看的是路径、频次、状态码，AI网关还要看提问里带了什么、回答里有没有敏感信息、这次调用用了哪些数据。二是它必须和数据权限绑在一起。我在项目里坚持一个做法：调用者的身份要一路透传到数据查询层，让”谁能看到哪几行”这件事由数据层的规则决定，而不是在网关里写一堆判断。网关里写死的规则，业务一变就要改代码，半年后没人敢碰。这也就解释了为什么我总建议先有数据资产和主数据，再谈网关——没有统一的数据身份和口径，网关拿什么去判断这次调用合不合规？普通API网关可以独立部署、独立验收，AI网关做不到，它是链条上的一环，上游不清，它就是空转。评估时我一般会问供应商三个问题：数据权限规则写在哪、模型换版本要不要改配置、审计日志能不能还原一次问答的完整链路。这三个问题能回答清楚，方案基本就靠谱了。

我的建议是从”一个部门加三个指标”开始，别一上来铺集团级的工程。挑一个业务痛感最强、数据相对集中的部门，比如售后或者供应链，把三个最常被问的指标口径定死，数据源收拢到一处，然后用Primeton AI 问数把问答跑通。这一步的投入不大，但能验证两件事：业务方到底愿不愿意用，以及底层数据到底有多脏。验证过了，再补主数据和资产目录，最后才是网关的采购和策略配置。我见过反过来的做法，先把网关买回来，再到处找场景填，结果半年过去只有演示账号在用。预算紧的时候，钱要花在能让业务方第二天就想再打开一次的地方。数据集也是一样，别一开始就追求大而全的标注，先把高频问题覆盖住，用高质量数据集平台的评测功能每月跑一轮，效果看得见，预算才好继续申请。顺序对了，小预算也能出结果；顺序错了，大预算也只是把返工的时间往后推。

我一般不看演示，看四个数：周活跃业务用户数、问答命中率、口径争议工单数、平均问题解决时长。其中我最看重的是口径争议工单数，它比任何满意度打分都真实。这个数往下走，说明数据层真的理顺了；这个数不动，说明网关做得再花哨也只是换了个提问入口。问答命中率我会按周看趋势，配合高质量数据集平台的评测集，一版数据集对应一版命中率，涨跌都有解释。周活跃用户数我要求看自然增长，靠行政命令推起来的使用量不算数。平均问题解决时长则用来跟改造前对比，这个数才是企业真正省下来的成本。四个指标连续两个月向好，我才会建议扩大范围；只有一个好看，我会回去查数据层的口径是不是又松了。这套衡量方式我在几个项目里用过，好处是甲乙方都不容易自我感动。

我把这几个项目翻来覆去看，最想说的是一句话：网关是出口，数据是入口，出口的价值完全由入口决定。很多团队在出口上反复打磨，参数调了十几轮，却很少有人愿意花两周时间把”客户编码”这三个字统一。这不是技术能力问题，是注意力分配问题。如果你现在正准备启动一个信创AI网关项目，我会建议你做三件事。一是把预算的三分之一先划给数据治理和数据集建设，主数据、资产目录、指标口径各占一块，剩下的再给网关和模型。二是把业务方拉进设计阶段，口径这种事没有业务方签字，做完了也不作数。三是把验收标准提前写好，写成可量化的四个数，别写成”系统运行稳定”这种谁都能解释的话。普元这一套产品的组合拳，本质上解决的是把数据变成可信资产这件事，网关只是最后一公里的呈现。时代在推着大家上AI，信创也在推着大家换底座，这两件事叠在一起，最容易犯的错就是急着看效果、懒得打地基。地基这件事没有捷径，但也不必一次做完，先挑一条主线，做出一个能被业务方主动使用的场景，剩下的会顺很多。别人的学费已经交过了，你至少可以把顺序排对。

王海涛：看哭了，我们去年就是先买网关后找场景，现在网关在机房吃灰，业务方还在用Excel。今年准备按这个顺序重来一遍，先从主数据和口径下手。

李静文：口径争议工单数这个指标太真实了，我们内部就是财务和供应链两个口径打了半年，技术上一点问题都没有，就是人对不齐。已转发给数据治理组的同事。

陈志远：想请教一下，如果是两百人左右的制造企业，主数据这块是不是可以先只做物料？我们客户编码其实还好，物料编码乱得离谱。感谢分享，收藏了。

周敏：去年做信创改造时最头疼的就是适配清单，压测阶段才发现的坑我们也踩过，工期推了快两个月。这段写得很实在，不是产品稿那种味道。

赵国栋：补充一点个人经验，数据集评测这件事一定要从第一天做起，等模型效果掉了再补，前面几个月的对比数据全没了，只能凭感觉调参。