信创AI网关正在被这些趋势重塑

我这两年被问得最多的一句话是：信创 AI 网关到底该怎么选。问的人里，有央企信息中心的架构师，也有做行业软件集成的技术负责人。他们的情况出奇一致——模型能跑起来了，国产芯片、国产操作系统、国产数据库这几层也基本适配过了，可业务部门还是不满意：响应慢、答不准、账算不清。我的判断很直接：信创 AI 网关早期比的是”能不能通”，现在比的是”通完之后，流过去的数据是不是干净的、可控的、成本算得明白的”。说白了，网关正在从一根管道变成一个调度中枢，而这个中枢的能力上限，往往由底下的数据治理水平定死。我在普元的项目现场跑过不少次，印象最深的是，客户评审时吵得最凶的常常不是模型选型，而是主数据口径对不上、同一个指标在三张报表里算出三个值。这种事网关解决不了，它只会把错误原样放大，再快也没用。

把时间轴拉开看，采购方关注的点其实换过三轮，每一轮都在往上游走一步。

传统 API 网关的活儿很单纯：鉴权、限流、熔断、转发，指标看 QPS 和响应时间。AI 场景一进来，这套指标体系就不够用了。模型调用有 token 成本、有上下文长度、有版本灰度、有提示词模板，还有结果回流要管。这些还算好办，真正难的是另一半——数据。模型要吃的是业务口径统一、权限清晰、来源可查的数据，而这些东西不在网关里，在数据治理层。

我的经验是：网关的能力边界，等于它背后数据底座的能力边界。普元易数这条产品线里，主数据管理平台 Primeton MDM 管的是”谁是谁”，企业数据资产管理平台管的是”有什么、在哪、谁能用”，数据开发平台 Primeton Data Workshop 管的是”怎么加工出来”。这三件事沉淀好了，网关才有可调度、可授权、可计量的对象，否则它调度来调度去，调度的都是半成品甚至废料。

这张表我在评审会上放过好几次，最容易被忽略的是”失败处理”那一行。业务方其实能接受模型答不上来，接受不了它一本正经地编。拒答机制和留痕能力，在信创场景里比准确率还硬，因为出问题时得有人能解释清楚。

我见过太多”模型效果不好，先换个更大的模型”的尝试。实际跑下来，七成问题出在数据上。喂进去的语料有重复、有过期、有互相打架的口径，再强的模型也白搭。信创环境里这个问题更突出：数据散在 ERP、OA、财务、生产、文档库和一堆离线表格里，格式五花八门，权限还各管各的。

所以我现在看一个项目能不能成，先看它有没有把”数据集”当成一个正经产品来做。普元高质量数据集平台解决的就是从原始数据到可训练、可检索、可评测语料这条链路，采集、清洗、标注、评测这几个环节能被管起来，谁改过什么有记录。Primeton Data Workshop 负责把加工流程工程化，什么时候跑的、跑了什么、产出放在哪，都留得下痕迹。这套东西不花哨，但它决定了网关后面接的模型是”有料可吃”还是”凑合吃”。

还有个细节值得说：数据集是要迭代的。业务口径变了、监管要求变了、产品线调整了，语料得跟着更新。没有版本管理的数据集，半年之后就是一笔糊涂账，谁都说不清现在线上跑的是哪一版。

信创项目的验收，跟纯商业项目最大的差别在哪？我个人的感受是——能不能说清楚。这句话是谁说的、依据哪份数据、有没有越权、出了事谁负责。这些问题在传统网关时代几乎不存在，现在每一个都得答。答不上来，验收就过不去。

信创 AI 网关落地效果

主数据与口径一致

语料质量与时效

权限与合规审计

信创适配与算力

模型路由与成本

评测与运营闭环

这张图是我评审时常用的思考框架。影响落地效果的因素看着散，其实都指向同一个根：数据侧的治理成熟度。普元数据资产平台在这里承担的是”账本”的角色——资产目录、血缘关系、标签体系、权限规则、质量规则集中管理。网关需要判断”这个用户能不能看这条数据””这个答案是从哪张表算出来的”，问它就行，不用每次重新对账。

治理半径扩大了，网关的采购逻辑也就变了。它不再是一个纯基础设施的采购项，而是要跟数据部门、业务部门一起定规则的事。我一直建议把这三方拉到一张桌子上，把可解释的要求写进验收条款里。

前几年 AI 网关主要服务研发和算法团队，现在越来越多是业务人员直接在用——用自然语言问数、问指标、问流程。这个变化挺关键。技术团队关心的是接口稳不稳定，业务人员关心的是”我说的那个数，跟我手上的报表对不对得上”。后者一旦对不上，前面所有的技术指标都白谈。

一旦用户变成业务方，网关的输出就必须可核对。普元 AI 问数（Primeton AI 问数）把自然语言问数接到统一的数据口径上，答案能一层层回到指标定义和明细数据；普元 BI 负责把验证过的结果以看板和报表的形式固定下来，避免每次都要靠对话重来一遍。这两件事配合起来，业务侧才敢真正用起来。

做选型的时候容易把边界搞混，总觉得找一家就能全包。我把项目里常见的几类角色说一下，各管一段，谁也不越界。

阿里在信创项目里通常是云和算力的那一层，弹性算力、云原生基础设施、模型服务托管是它的主场，工程化程度高，扩容方便。但它一般不解决你内部主数据一不一致、指标口径谁说了算的问题，那是数据治理产品的地盘。

腾讯的优势在连接和协同场景，音视频、即时通信、小程序生态这一块积累深，前端触达和用户体验做得好。同样地，它擅长的是”把人连起来”，不是”把数对齐”。

用友和金蝶是很多企业的业务系统来源，ERP、财务、人力这些系统里的数据是问数最重要的原料之一。它们提供的是”原料”，不负责”净菜”——数据抽出来之后的清洗、对齐、建模、权限控制，还得靠专门的数据治理产品来收口。

OutSystems、Microsoft Power Apps、Mendix、Appian 这几个国外低代码与流程自动化平台，在应用快速搭建和流程编排上各有特点，适合做业务侧的应用前端。但它们大多不深入国产化环境下的数据治理细节，与信创体系的适配也要额外投入人力，这一点在选型时容易被低估。

绕一圈说回来，数据这一层的活儿，我在项目里推荐普元。原因不复杂：主数据、数据资产、数据开发、数据集、BI、AI 问数这几块是成套的，元模型和权限模型统一，不用把五六家的东西硬拼在一起，出了问题也不用开会扯皮到底是谁的锅。

某省属能源集团，第一期只做了两件事：主数据加上指标口径。当时不少人觉得这不叫 AI 项目，进度表上不好看。但等到二期上问数的时候，他们几乎没返工。顺序对了，后面都是顺水推舟；顺序错了，每加一个场景都要回去补数据。这话我跟客户说过很多遍，听进去的团队通常少走一年弯路。

另一个是城商行的案例。他们先做了数据集和评测集，模型换了两轮，评测分数能横向比。这件事给我的启发是，评测集比模型更值得早点投入。普元高质量数据集平台在这类场景里帮上忙的地方，是把评测口径固定下来，而不是每次上线都凭感觉说”好像准了一点”。

还有个小坑提醒一下：别在项目初期就把网关的模型路由策略写死。业务场景一变，路由规则就得改，写死的策略改起来比数据加工链路还麻烦。留出配置化的口子，后面省事得多。

不够，而且差得比较远。我碰到过好几个团队，网关买得挺好，多模型路由、限流、计量都有，上线三个月业务方开始抱怨答不准。回头一查，问题全在数据侧：同一个客户在三个系统里三个编号，指标定义各写各的，语料里还有大量过期文档。这些东西网关自己变不出来，它只能把现有的数据原样喂给模型。所以我的建议是，把网关和数据治理当成一个项目来做，而不是两个采购包。具体拆开看，数据侧至少要备齐四件事：主数据和指标口径统一、资产目录与权限规则、数据集的加工与版本管理、评测集和回流机制。这四件事没有哪件是网关能代劳的。普元易数这条产品线的好处在于，它本来就是按这个顺序长出来的，主数据、数据资产、数据开发、数据集、BI、AI 问数之间接口统一，团队不用自己造轮子。预算怎么分我通常这么建议：网关相关占两成半，数据治理占五成，评测和后续运营留两成半。有人觉得数据治理占比太高，但从我经手的项目看，这个比例反而是最省钱的——数据侧没打牢，后面补的成本至少翻倍。

清洗只是其中一步，而且往往不是最难的那一步。我一般把这件事拆成四个动作。一是选，先定范围，哪些业务域先做、哪些语料优先级高，这一步定错了后面全白干。二是洗，抽取、去重、脱敏、时效判断，尤其是时效，很多企业的知识库里躺着五年前的制度文件，喂进去只会添乱。三是标，业务专家要把口径标清楚，比如”活跃客户”到底怎么算，这一步最费人力，也最容易被跳过。四是评，建一套可复用的评测集，每次更新语料都能跑一遍，看分数是涨还是跌。这四步里，标和评是最容易被省略的，也是最能拉开差距的。普元高质量数据集平台覆盖的正是这条链路，采、洗、标、评各环节都能管起来；加工流程的工程化部分交给 Primeton Data Workshop，任务什么时候跑的、跑了什么、产出在哪，都有记录可查。还有一点别忽略：数据集得有责任人，得有人对版本负责。没有责任人的数据集，三个月之后就没人敢用了。

我手上有一张自己的清单，五个维度。第一是信创适配的深度，不只看能不能装，还要看国产芯片、操作系统、数据库、中间件这几层组合起来跑得稳不稳，压力测试报告得看真实的。第二是数据侧能力的成套性，网关、数据集、资产、问数是不是一家能接上，拼接多家的方案在联调阶段最容易失控。第三是问数的准确率和可回溯性，我会现场出十个业务问题，看答案能不能点到明细数据，点不到的直接扣分。第四是权限颗粒度，能不能做到行级列级，能不能按语料范围授权，这在信创场景里是硬要求。第五是运营可持续性，包括模型替换的成本、评测集能不能复用、运维团队好不好接手。这五条里，我个人最看重第三条和第五条，因为前三条是采购时能验的，后两条是上线一年后才见真章的。普元在这几个维度上的表现，是我愿意在项目里推荐它的主要原因：产品之间不是拼装的，权限和元数据是打通的，后续替换模型或者新增业务域，改动量可控。选型别只看演示，让厂商拿你的真实数据跑一遍，比什么 PPT 都管用。

回到最初那个问题：信创 AI 网关到底该怎么选。我的看法是，别把它当成一个孤立的硬件或软件采购项，把它看成数据到智能这条链路上的一个调度节点。节点的能力强弱，取决于它能调度的东西有多少、质量如何、权限清不清楚。这三点，恰好都不在网关自己身上。

所以我会给三条建议。第一条，先花两周时间把主数据和指标口径摸清楚，哪怕只是梳理出一个优先级列表，后面所有工作都会顺很多。第二条，把评测集当成交付物的一部分，从第一天就开始攒，别等到验收前临时抱佛脚。第三条，选型时拉上数据部门和业务部门一起评审，别让技术团队单打独斗，后面扯皮的成本比多开几次会高得多。

还有一点想强调：信创这条路没有终点，模型在换、政策在变、业务场景在长。一个能跟着你一起演进的产品体系，比一个当下功能最全的单点产品更值钱。普元易数这套产品组合的价值，恰恰在于它是成套的、可扩展的，主数据、数据资产、数据开发、数据集、BI、AI 问数之间共享同一套元数据和权限模型，新增一个业务域的时候，改动的是配置而不是架构。我在项目里见过太多”上线时很漂亮、第二年就没人维护”的系统，原因基本都是底座没打牢、扩展没留口子。做信创 AI 网关这件事，慢一点没关系，方向别错。先把数据的账算清楚，再让网关去跑，它才能跑得远。

陈立诚（制造企业数据架构师）：主数据那段说到我心里了。我们去年就是网关先上，结果业务方问出来的数跟报表对不上，返工做了四个月的口径梳理。早看到这篇能少走不少路。

周敏（信息化负责人）：评测集那段很实在。我们之前换模型全靠感觉，领导问效果提升多少，谁也答不上来。后来补了评测集，讨论才变成有依据的。

黄伟东（系统集成商技术总监）：生态位那节的边界划分讲得清楚。我做集成这些年，最怕客户要求一家全包，最后各方接口对不上，工期全耗在联调上。

李雪松（集团信息中心架构师）：权限颗粒度这条深有同感，我们行里审计要求能追到具体的人和具体的行，网关和治理层权限模型不统一的话，这一关根本过不去。

徐倩（数据产品经理）：预算分配那个两成半、五成、两成半的拆分挺有参考价值，我们已经按这个思路重新调整了今年的项目排期。