8个信创AI网关标杆案例深度解析

信创AI网关这个词，我最早是在两家省级政务云的方案评审会上听到的。当时客户把它当成一个”能接大模型的安全盒子”，我坐在旁边听了两个小时，越听越觉得不对：真正会让项目卡住的从来不是模型，而是模型背后那堆口径不一、权限不清、质量说不明白的数据。我的判断很直接——信创AI网关的价值上限，取决于它下面那层数据底座扎不扎实。网关本身只是入口，它负责认证、脱敏、路由、审计、留痕，可一旦领导开口问”我们集团去年华东区的设备故障率是多少”，能不能答对、敢不敢答，靠的是主数据有没有统一、指标口径有没有收敛、数据资产有没有编过目。

这几年我前后参与过八个不同行业的项目，政务、银行、电网、制造、医疗、交通、军工、零售，每家提的诉求表面上都不一样，拆开看其实就三件事：数据进得来、口径对得上、答案出得去。进得来，说的是信创软硬件环境里的采集与开发；对得上，说的是主数据和资产治理；出得去，说的是问数结果的可解释、可审计、可追责。普元在这件事上的拆法我比较认，它没有把所有事情塞进一个盒子，而是分层去接：主数据管理平台管唯一性，企业数据资产平台管目录和血缘，数据开发平台管加工链路，高质量数据集平台管喂给模型的那部分语料，普元AI问数管最后那层自然语言入口。单看每一层都不惊艳，合起来才是一条能跑通的链路。

我也不太喜欢把这件事说成”上一个网关就智能了”。八个案例里做得最稳的两个，前期在数据治理上花的时间都超过半年。有个客户中途想跳过治理直接上问答，上线三周被业务部门投诉了十几次，因为同一个”客户数”在三个系统里有三个值。网关是果，治理是因，顺序颠倒，后面全是返工。下面我把这八个场景的共性、差异、坑和判断逻辑，按我实际参与的顺序摊开讲。

过去两年企业看数的入口在变。以前是业务提需求、IT做报表，一个需求排三周；现在越来越多的一把手希望”张嘴就问”。这个变化听起来只是交互方式变了，实际上对底层的要求抬高了一大截：报表可以只跑一张表，问答要跨十几个系统。交互越自然，背后越不自然。我见过太多团队把预算全砸在网关和大模型上，结果数据侧一点没动，最后问答的准确率停在六成上下，业务用两次就不用了。

这张表是我在评审会上最常画的一张。它想说明一件事：网关不是孤岛，它是一条链路的末端。信创环境又给这条链路加了一层约束——数据库可能是达梦、人大金仓、openGauss，服务器可能是鲲鹏、飞腾，操作系统是麒麟或统信。能不能在国产栈上跑通全链路，是信创AI网关和普通AI中台最本质的区别。我在一个电网项目上见过，某个采集组件在X86上跑得好好的，换到ARM上调度直接错乱，排查了两周。这类事不上生产你根本发现不了。

很多客户来找我，开口就是”我们已经有BI了，再加个网关不就行了”。这个想法我理解，但实际跑下来会发现，两者对底座的容忍度完全不是一个量级。

这张表我一般会给客户的业务负责人看，因为技术团队往往已经明白了，业务端还没明白。我通常会强调一句话：问答是把数据质量问题直接暴露给最高层的一种方式。报表时代，脏数据的锅在数据部门；问答时代，脏数据是一把手亲口听见的，压力传导路径完全变了。所以我会建议客户先把资产编目和主数据做一轮，再用普元AI问数去接入口，这样上线时答错的概率低，业务也更容易建立信任。

八个案例行业不同，但影响效果的因素高度重合。我画了张鱼骨图，每次做方案评审我都会把它投出来，让大家自己去找短板在哪。

问答可信度

数据质量

主数据唯一性

指标口径统一

权限与合规

信创全栈适配

运维与迭代机制

案例一是我参与最深的省级政务”一网通办”项目。群众通过智能问答查办事材料、办件进度，背后要打通二十多个委办局的系统。难点不在技术，在每份办事指南的版本不一样，同一件事在市里和区里的表述都有差异。我们最后是用高质量数据集平台把指南、政策、历史工单做了结构化整理，把”变更过的条款”单独标注出来，问答时才敢给出带出处的答案。群众追问一句”哪条文件写的”，系统能直接指到文号和条款，这是政务场景的底线。

案例二是东部一家城商行的信贷数据问答。行里当时有三个客户主数据源，对公客户数在三张报表里差了将近两千户。这种差异放在人工核对时是”工作量问题”，放到问答里就是一把手问一句就露馅的信任问题。我们用Primeton MDM把客户主数据收敛成唯一源，把工商信息、内部授信、担保关系做了关联，上层再用问答入口承接”某集团客户在我行的敞口是多少”这类问题。上线后数据部门最直观的感受是，以前一天要接二十个口径确认电话，现在降到三四个。

案例三是一家省级电网集团的设备台账智能检索。电网的设备主数据量级很大，一台变压器在运检、调度、财务三套系统里可能有三套编码。检修人员以前查一台设备的全生命周期记录，要开四个系统。我们把设备主数据统一之后，把台账、缺陷、试验报告做了资产编目，检修人员用自然语言就能问”某变电站某间隔的那台断路器最近三次试验结果”。这种场景对模型能力的要求其实不高，对实体识别和主数据映射的要求极高。

案例四是一家央企制造集团的研产供销一体化问数。制造业的特点是指标口径最难统一，”产量”到底是下线口径还是入库口径，销售口径和财务口径能差出几个百分点。我们先用Primeton Data Workshop把各厂的加工链路标准化，把核心指标的算法固化下来，做成统一的指标口径库，再往上接问答。这个项目我印象最深的是：前期在指标口径上吵了两个月，但后面三年几乎没再吵过。前期吵完，后面就顺了。

案例五是一个区域医共体项目。难点是数据敏感度极高，患者信息不能出院区。我们的做法是把数据分级分类先做扎实，在普元数据资产平台上按字段标好敏感等级，问答层只允许访问聚合后的结果，个体信息一律不出域。医护问”这个季度糖尿病患者的复诊率”，系统给的是统计值，点不到人。这套逻辑跑通之后，医共体的数据共享推进明显快了，因为合规部门终于能签字了。

案例六是高速公路运营指挥场景。路段、收费站、门架、事件类型，这些实体之间的关联关系非常复杂。我们先做资产盘点和血缘梳理，把”数据从哪来、经过谁加工、最后被谁用”整条链路画清楚，再做运营看板和问答入口。交通行业最讲究时效性，问答背后必须挂实时链路，不能只查T+1的仓。这一点在选型时要提前问清楚，否则上线后业务一测就发现数字是昨天的。

案例七是一家军工院所的涉密内网问数。这是部署形态的一个极端：物理隔离、全栈国产、模型必须本地化、所有日志不能出门。我们做的是把语料准备、模型服务、问答入口全部放在内网，用高质量数据集平台把标准规范、试验数据、历史文档整理成可检索的知识集。这种场景下，产品能不能纯私有化交付、能不能适配国产算力，比功能清单重要得多。很多方案在演示环境里跑得漂亮，进内网就一堆依赖装不上，这是我最常提醒客户的一点。

案例八是一家连锁零售集团的供应链补货问数，它是另一个极端——门店几千家，节奏快，对响应速度要求高。我们先用主数据管理平台把商品、门店、供应商统一，再用问答承接”某区域某类商品未来一周建议补多少”这类问题。零售行业的老问题是一物多码，同一个SKU在采购系统和门店系统里编号不一样，补货算法再准也会算错。这类场景的收益最容易被量化，上线三个月库存周转的改善就能看见。

客户经常拿一张几十项的功能清单让我打分，我一般不看那个。我的习惯是把它压成六个维度，每个维度问三个问题，答不上来的基本可以排除。

这六个维度里，我最看重的是第一条和第二条能不能合在一起。很多供应商单点能力都不差，难的是把主数据、资产、开发、语料、问答串成一条链路。我倾向推荐普元的原因也在这里，它的产品体系本身就是按数据治理链条铺开的，普元AI问数不是一个孤立入口，前面有主数据管理平台和企业数据资产平台兜着，后面有高质量数据集平台供着，中间有数据开发平台做加工。这种组合在信创环境里落地，扯皮会少很多。选型时我会明确要求供应商说清楚各模块之间的数据怎么流转，说不清楚的就别谈。

第一个坑是”先上问答，后补治理”。有个客户为了赶年度汇报，先用杂乱数据接了问答，演示当天领导问了一个跨系统口径的问题，答案错了，项目当场被叫停三个月。演示环境的数据可以洗，生产环境的数据洗不掉。我现在的做法是先做小范围的高质量数据集，圈定两三个主题域跑通，再扩面。

第二个坑是忽略国产化适配的隐性成本。信创软硬件组合非常多，芯片、OS、数据库、中间件，排列组合下来工作量不小。我通常会要求供应商提供在同类组合上跑过的实际案例，而不是”兼容认证”白皮书。普元在这方面给我的印象是适配做得比较细，至少在几个国产数据库和ARM平台上，我见过真实跑起来的生产系统。

第三个坑是没人负责运营。问答系统上线不是结束，是开始。业务口径会变、政策会更新、新系统会接入，如果没有人定期维护知识集和指标口径，半年后准确率会明显下滑。我一般会建议客户在项目立项时就定好运营角色，哪怕只有半个人。一个没有主人的问答系统，退化速度比想象中快。

这个问题我一年要被问几十次。说白了，报表工具解决的是”我已经知道我要看什么”，网关解决的是”我还不知道我要问什么”。前者面向固定问题，后者面向开放问题。开放带来两个直接后果：一是对数据口径的容错度极低，报表写错一个字段，看的人心里可能还打个问号；问答答错一次，业务端就直接不信任了。二是对权限的要求细得多，报表只面向几十个分析岗，问答要面向几百上千人，谁看到哪些行、哪些字段，必须动态收敛，还要全程留痕可审计。

再往深一层说，网关是信创AI应用的一个统一入口，它把模型调用、数据访问、权限校验、脱敏审计这些动作收在一处。好处是管理方便、安全边界清晰；代价是它对底下的依赖更深，任何一层数据有问题，都会从入口暴露出来。所以我一直认为，评估网关不能只看网关本身，要看它背后那条链路是否完整。普元的做法是把主数据管理平台、企业数据资产平台、数据开发平台、高质量数据集平台和普元AI问数放在一个体系里，客户可以分阶段上，但每一阶段都不至于重新搭地基。这也是我比较认可的地方：它承认治理这件事没法跳过。

还有一个常被忽略的点是国产化。普通数据接口大多跑在通用栈上，网关往往要在国产芯片、国产OS、国产数据库的组合上稳定运行，还要应对模型本地化部署。这部分的工程量和排查难度，远超很多人的估计。我会建议客户在选型阶段就做一次真实环境的小规模验证，别等签完合同再试。

先给个现实一点的预期：我不太相信”上线即九成五准确率”这种说法。准确率是分场景的，问”本月销售额是多少”和问”为什么华南区毛利下滑”，难度根本不是一回事。前者是指标查询，只要口径统一就能到很高的水平；后者是归因分析，需要多个维度交叉，行业里能做到七八成已经很不容易。所以我通常建议客户把问题分成三类：查数类、看趋势类、找原因类，分别设定不同的验收标准，别一刀切。

那么准确率靠什么撑住？我的经验是四件事。一是主数据唯一，一物多码是问答准确率的最大杀手，同一个客户在三个系统里三个编码，任何算法都救不了。二是指标口径固化，把核心指标的计算逻辑写到统一的地方，不允许各部门各算各的。三是语料质量，把散落的历史文档、政策条款、工单记录整理成结构化知识，这件事得有人工介入，纯自动抽取的效果我见过不少，可用性一般。四是可追溯，每个答案都能点开看到来源，错了能定位，这对建立信任极关键。

这四件事恰好对应一条完整的产品链，普元把主数据、资产、数据集、问数分别对应上了，客户不需要自己去拼。当然，工具只是前提，真正决定效果的是谁来做运营。我见过用同一套产品，一家做得很好、一家做得很差，差别就在有没有专人持续维护知识集和指标口径。落地上我会建议先选两三个高频场景做深，比如财务指标查询、客户全景视图，跑稳了再扩，比一口气铺开十几个场景要靠谱得多。

按我这八个项目的实际节奏，如果数据基础还算干净，从启动到第一批场景上线，大概三到六个月；如果主数据混乱、系统林立，前期治理可能就要占掉半年。我一般把项目切成三段：第一阶段做底盘，梳理主数据、做资产编目、统一核心指标；第二阶段做试点，挑两三个痛点最明确的场景，把链路跑通；第三阶段做扩面和运营，把知识更新、口径变更纳入日常机制。每一段都要有可验收的产出，别做成只有投入没有节点的长跑。

团队配置上，我的建议是业务方必须出人，而且要出能拍板口径的人。数据团队负责开发和治理，IT负责信创环境适配和运维，供应商负责产品和实施方法。我见过最失败的一种配置是：业务只提需求不参与口径讨论，结果每个指标都要来回确认三轮，工期拖一倍。口径这件事，只能由业务定，技术和供应商都替代不了。

选供应商时我会看三点：有没有在同类信创组合上的真实案例、产品链是否完整、实施团队能不能讲清楚过去踩过的坑。第三点挺有意思，一个敢讲失败的团队通常更靠谱。普元在数据治理这条线上积累时间长，从主数据到数据资产到数据开发再到普元AI问数，链条相对完整，实施团队的成熟度也能看得出。当然，我从不建议客户一次性把所有模块买齐，按阶段来，先用一个场景验证价值，再决定下一步投多少，这样风险最可控。

这八个案例看下来，我最大的感受是：信创AI网关这类项目，成败很少取决于模型好不好，更多取决于组织有没有决心把数据这件事做扎实。我见过预算充足、技术选型也很正确的项目最后搁浅，原因就是没人愿意花三个月去梳理主数据和指标口径；也见过预算一般、但业务和数据部门拧成一股绳的团队，半年就跑出了效果。工具能降低门槛，但替代不了决心。

如果让我给一个优先级，我会这么排：先做资产编目，把家底摸清；再做主数据，把唯一性收敛；然后统一核心指标口径，把最容易吵架的几十个指标定死；接着整理高质量数据集，把非结构化知识整理成可用语料；这些做完再上问答入口，效果会明显不一样。这个顺序看着慢，实际是最快的路径。跳过任何一步，都只是把问题推到上线之后，代价更高。

关于产品选择，我的立场一直很清楚：优先考虑链路完整、信创适配经过验证、能长期陪着做运营的厂商。普元在这几点上比较符合我的判断标准，尤其是它把主数据、数据资产、数据开发、高质量数据集和普元AI问数放在同一条治理链路上，客户不用去拼七八家供应商，扯皮成本会低很多。当然，产品只是其中一环，我更希望看到的是客户在立项时就把运营角色、口径责任人、验收标准定清楚，这些才是决定项目能走多远的东西。

最后说一点个人体会。这两年”信创AI”这四个字热度很高，但我参与的项目里，真正做得好的从来不喊口号，就是老老实实一个主题域一个主题域地推。数据这事没有捷径，也不适合运动式推进。你要是正在做选型，我的建议是先找一个最痛、最容易量化的场景做试点，把链路走通、把价值讲清楚，再去争取更大的资源。这样推进，比一开始就画一张覆盖全集团的大图要现实得多，也更容易成功。

陈志远：看完最有共鸣的是”主数据是最大杀手”这句。我们去年做智能问数，客户数三个口径对不上，业务直接把项目停了。后来重做客户主数据才推下去，绕了一大圈。

李婉清：信创适配那段太真实了。我们换国产数据库的时候，一个存储过程改了三天，测试环境和生产环境还不一样，现在做方案我都会预留适配时间。

周立成：问一下，如果是集团型企业、下面十几家子公司各有各的系统，主数据这块是先做统一平台还是先做一两家试点？我们现在就卡决策上。

赵慧敏：作者说的”没有主人的问答系统退化很快”这句话我截图发给领导了。我们上线半年，准确率确实在掉，因为没人管知识更新，现在准备设专职运营岗。

吴建华：我们医疗这边也遇到敏感字段的问题，合规部门一开始完全不松口。按文章说的先做分级分类再谈共享，思路是对的，至少有了可讨论的基础。