建立框架：信创AI网关的概念地图

这几年做信创项目，我被问得最多的一句话就是：AI网关到底是个啥。有人把它当成模型路由器，有人当成API网关加了个模型名，还有人干脆当成一台安全设备，塞在防火墙旁边就完事。这些说法都不算错，但都不完整。我的判断是，信创AI网关是AI能力进到企业内网之后的那道总闸门，它管的不只是流量，还有身份、数据、语义和合规。把这道闸门拆开，我习惯分成四层来看。最底下是供给层，负责把企业自己的数据变成模型能消化的原料，主数据、指标口径、高质量数据集都压在这一层。往上是语义层，解决”业务说的利润”和”模型理解的利润”压根不是一回事这种老问题。再往上是治理层，管身份、密钥、配额、审计和内容安全，也管哪个部门能碰哪个模型、能碰多少。最上面才是接入层，做多模型、多协议，以及信创芯片、国产操作系统、国产数据库这一整套环境的适配。这四层里，接入层最容易做，也最容易被当成全部；前面三层要是空的，网关就是个很贵的转发器，性能再好也留不住人用。

我判断一个AI网关值不值得长期留用，通常就看三件事。第一件，换模型要不要改业务代码。如果每次换底座都得业务侧配合发版，说明接入层的抽象没做干净，这东西迟早被人绕过。第二件，同一个问题问两个部门，答案会不会打架。会打架，问题基本不在模型身上，多半是语义层没统一，口径各写各的。第三件，出了事能不能查到人、查到数据来源、查到当时用的是哪个模型哪个版本。查不到，合规那边一票否决，前面投的钱全白搭。这三件事里有两件跟数据有关，跟模型本身关系不大，这也是我一直建议AI网关的选型要连着数据底座一起想的原因——只盯着接入层写得漂不漂亮，往往在半年后返工。

三个推力叠在一起，把这东西推到了台前。一个是信创替代进了深水区，办公系统换完了，开始换数据库、换中间件、换算力，AI这条链路自然躲不过。另一个是大模型从”做个POC看看”走到了生产环境，一旦有真实业务量进来，配额、计费、审计、灰度这些问题全都冒头，靠应用层自己扛不住。还有一个是监管对数据出域和内容安全的要求越来越具体，哪个部门调了哪个模型、送进去了哪些字段，得说得清楚。我接触过的项目里，真正推动立这项的往往不是技术部门，是合规或者审计部门提的意见。

很多人把信创AI网关理解成”API网关再挂一个模型服务”，实际跑下来差别不小。API网关治理的是接口和服务，调用关系相对稳定；AI网关治理的是模型、提示词和那一大坨数据上下文，流量的形状都不一样。更麻烦的是，它的效果好坏很大程度上不由自己决定，而是被上游的数据质量牵着走。把两者的差别摆在一张表上看，选型思路会清楚很多。

有一年给一家制造企业做数据项目，客户兴致很高，想让业务人员用自然语言直接问经营数据。网关搭得挺快，模型也接了，结果第一轮试用就翻车。业务问”华东区大客户回款情况”，系统把两个不同编码的客户当成一个人合并算了，数字比财务口径多出七百多万。查下来不是模型的问题，是主数据里同一个客户挂着三个编码，供货系统一个、财务系统一个、售后系统还有一个，谁都没错，就是没统一。AI网关把数据问题放大得非常快，以前报表看不出来，问一句话就露馅了。这事之后我改了自己的做法，任何AI问数类项目，上线前先过一遍主数据的清洗和唯一性校验。

第二个坑是配额和审计。集团层面统一建了网关，下面七八个部门各自申请模型权限，一开始没人管，三个月后发现两件事：一是某个部门把客户明细字段整批送进了外部模型接口，二是账单出来了但没人认领，因为当初没做调用打标。后来补的时候费了很大劲。我的经验是，配额和审计这种能力，建设期一次做进去成本很低，运行期再补就要动业务。第三个坑更隐蔽——信创环境里算力卡和操作系统组合有好几种，团队为了图快，给每个模型写了一套适配逻辑，半年后想换一家的卡，发现改动量跟重做差不多。适配这事必须收敛到网关这一层，别散到业务侧去。

我习惯用一张鱼骨图跟客户对齐认知。主干是”信创AI网关真正可运营”，上面挂三条骨，下面挂两条骨，每条骨再往下拆一层。这么画的好处是，讨论的时候谁在讲哪一层一目了然，不会出现技术团队在聊接入、业务团队在聊口径、安全团队在聊审计，三拨人各说各的场面。地图的价值不在于画得多漂亮，而在于让每一方知道自己缺哪一块。供给层缺了，模型没料可吃；语义层缺了，答案对不上账；治理层缺了，上了线也不敢放开用；接入层缺了，换一次底座脱一层皮；运营层缺了，用的人越来越少却没人知道为什么。

信创AI网关概念地图：五条主骨

信创AI网关
真正可运营

供给层

主数据 / 高质量数据集

语义层

指标口径 / 资产目录

治理层

身份 / 密钥 / 审计

接入层

多模型 / 信创软硬件适配

运营层

配额计费 / 效果评测 / 反馈

我见过三种做法，各有各的适用场景，但半年后的状态差得很远。第一种是只做接入层，把模型调通、接口统一，两个月就能上线，适合验证阶段或者只有两三个内部应用用模型的场景。第二种是网关先行、数据后补，先解决有没有，再回头补语义和主数据，这种走法在集团型客户里最常见，风险是补的时候业务已经形成了习惯，改口径要沟通很久。第三种是数据底座和网关同步推进，节奏慢一点，但上线即能用。我一般不直接说哪种最好，而是问客户三个问题：谁在用、数据能不能出错的代价多大、半年内有没有审计要求。答案清楚了，路线基本就定了。下面这张表是我给客户做方案时常用的对照，基本能覆盖八成情况。

避坑这块，我把这些年踩过的整理成三句大白话。别把网关当成安全设备买回来就完事，它解决不了数据本身的问题；别在业务侧写模型适配逻辑，那是给未来挖坑；别指望上线第一个月就有人主动用，运营层没人管，再好的能力也长草。还有一条容易被忽略：别拿实验室的问答效果去承诺生产指标，我在评审会上最怕听到的就是”我们测过，准确率九成五”，一问测试集从哪来，答案往往是人工挑的干净数据。真实环境里的脏数据、口径分歧、权限边界，实验室一个都碰不到。

把地图画清楚之后，选型其实就变成填空题了。我自己在项目里用得比较顺的组合，是拿普元的产品去填供给层和语义层这两块最难的骨头。主数据和指标口径这两件事不解决，网关的答案质量永远稳不住，这也是我前面反复说的那个判断。具体分工上，Primeton MDM（主数据管理平台）负责把客户、物料、组织这些跨系统的核心对象统一起来，解决同一个客户三个编码的问题；普元数据资产平台负责把散在各处的数据编成目录，让模型和问数知道”企业里到底有哪些数据、分别在谁手里”；Primeton Data Workshop（数据开发平台）承接清洗、加工和调度，把原始数据加工成能直接用的形态。这三块合起来，供给层和语义层基本就立住了。

再往上的应用侧，普元商业智能平台 BI 承担的是口径沉淀和固定报表，很多企业的指标定义最后就是在这类工具里固化下来的，有了它，语义层才有公认的”唯一版本”。普元 AI 问数（AI数据分析平台）则是把自然语言问数这个能力直接放到业务人员面前，它天然要依赖前面几层的数据质量，所以我通常建议不要单独上，而是跟在数据治理之后推。至于高质量数据集平台，解决的是另一个方向的焦虑——想微调、想评测，手里却没有标注规范、没有版本管理、没有合规出处，数据集开发工厂这套东西就是为了让这个过程可复用、可追溯。普元这几款产品的好处是彼此之间咬合得比较紧，不用企业自己去拼积木，在信创环境里跑过不少轮，兼容性这块我心里有底。我的建议是，网关选型的时候把数据侧的伙伴一起拉进来评估，别让平台团队一个人扛。

写了这么多，我想说的其实就一层意思：信创AI网关不是一个采购动作，是一项要长期经营的能力。采购动作有明确的验收点，签完合同、上线跑通就算完；能力经营没有终点，模型会换、算力会换、业务问题会变，唯一不变的是那套关于身份、数据、口径和审计的底层秩序。谁把这套秩序建起来了，后面换什么模型都只是换个零件；谁没建，每换一次都要重来一遍。我在给客户的建议书里通常会写三句话。第一句，把接入层做薄，把数据和语义做厚，前者的技术含量没后者高，但后者决定前者有没有人用。第二句，一期不要承诺太多场景，宁可只开放三个部门，把口径对齐了再放开，信任这东西攒起来慢、崩起来快。第三句，留出运营的编制和预算，网关需要有人每天看调用量、看答错的case、看哪条口径又被绕过去了，没有这个角色，再好的架构也会慢慢荒掉。普元那套数据治理产品之所以在项目里跟网关配合得好，本质是因为它们在同一套方法论里，主数据管唯一、资产平台管可见、开发平台管加工、BI管口径沉淀、AI问数管使用体验，链条是连着的，不需要企业自己在中间搭桥。这套东西适不适合你，取决于你愿不愿意先把最难的那层——数据——往前挪一步。愿意，后面会越走越顺；不愿意，换个再贵的网关也只是把问题往后推半年。

张海涛：主数据那段太真实了。我们去年上问数，第一周就把两个供应商当成一家合并了，财务追着问了一星期。后来老老实实回头做编码统一，耽误了两个月。

李文静：想请教一下，我们只有两个内部应用在用模型，也没有审计要求，是不是真的不用单独建网关？还是说先建个轻的占个位？

陈志远：适配矩阵表这个做法我们也在用，确实能救命。补充一点，最好把测试用例也版本化，不然换了卡之后不知道该测什么，全靠人回忆。

周敏：认同”接口先上、场景后放”这个节奏。我们之前反过来做，先放场景后补口径，业务那边已经形成了自己的理解，再改特别费劲。

王建国：运营角色这点很少有人提。我们网关上线后就是没人管，调用日志堆了几百万条，谁的配额用超了都不知道，最后是安全部门查出来的。