破除信创AI网关迷思：回归业务本质

这两年我参加过的信创AI项目评审，少说也有几十场。翻方案的时候有个规律：只要沾上”AI”两个字，架构图上大概率会多出一层叫AI网关的东西，位置卡在业务系统和模型之间，被写成”必备组件”。写方案的人往往还会配一段话，说它负责统一鉴权、统一路由、统一审计、统一限流，仿佛这一层立起来，智能能力就能安全合规地流进每个业务口子。

我的判断是：信创AI网关该建，但它从来不是决定AI落地成败的那道门槛。网关管的是请求怎么进来、往哪走、留没留痕、超没超配额。它管不了数据口径对不对、主数据全不全、业务人员问出来的一句话模型能不能答准。这两件事差着十万八千里，但在很多方案里被混成了一件事。

我见过网关做得极讲究的项目，策略配了上百条，脱敏、黑白名单、灰度、多模型路由一应俱全，上线三个月，日调用量不到两百次。原因不复杂：业务试了几回，发现回答驴唇不对马嘴，就没人用了。也见过网关就是个轻量统一入口的项目，没什么花活，但底下的数据整得扎实，AI问数答得准，业务人员自己天天追着用。

差别在哪？在于项目组有没有把”AI能用”当成一个数据问题，而不是一个接入问题。网关处理的是流量，业务要的是答案。流量层做得再标准，答案不准，前面所有的架构美感都会在第一次真实使用中崩掉。所以这篇文章我想聊的不是该不该建网关，而是怎么把它放回它该待的位置，然后把真正的力气花在业务侧看得见价值的地方。

把网关写进方案，动机其实差别很大。我大致归了三类。

第一类是合规驱动。行业有明确要求，数据不能随便出域，调用要留痕，模型来源要可审。这种情况下网关是刚需，不用争论，建就完了，重点是怎么建得省事。

第二类是集成商带进来的。整套方案是打包交付的，网关是标准件之一，装上去项目好验收。这种我能理解，但我会多问一句：这个组件在你们已经交付的项目里，业务侧真实使用率是多少？问过几次，回答往往含糊。

第三类是技术团队想先占位。先把入口收拢，以后再慢慢往下接。思路没错，但风险在于”以后”可能永远不来——入口建好了，业务没感知，预算就被判了死刑。

我会在评审时先看一张表，把动机和后续动作对上。

这三类里，真正能持续产生价值的，是那些一开始就想清楚了”谁在用、用在哪、答得准不准”的项目。网关只是它们顺带做的事，不是它们的起点。

把两边的要求并排放在一起，落差特别明显。

左边一列是工程语言，右边一列才是需求语言。很多方案失败，不是因为左边做得不好，而是因为右边那一列从头到尾没人问过。

我会要求项目组在网关之外，明确列出三件必须同时推进的事：一是业务口径的统一定义，谁是”有效客户”、什么叫”活跃订单”，这些词必须先有唯一解释；二是主数据的唯一来源，客户、物料、组织这几条主线的编码要能对得上；三是面向AI的数据准备方式，包括结构化指标怎么组织、非结构化文档怎么切分入库、问答结果怎么回溯到原始数据。这三件事做不好，网关再标准，业务端得到的也只是”能问，但问不出有用的东西”。

说白了，接入层解决的是”通不通”，数据侧解决的是”准不准”。通不通是技术活，一周能搞定；准不准是组织和标准的事，得按月算。

我印象比较深的是一次集团客户的复盘会。项目上线两个月，网关层零故障，可用率接近满分，但业务侧的满意度评分只有六十几分。我们把提问日志拉出来看了两百条，发现真正答得让人满意的不到四成。

逐条看下来，问题集中在三处。一是同一件事在不同系统里的口径不一样，”在库商品”这个概念，ERP、WMS、报表系统各有一套算法，差着几万条记录。模型随便挑一个口径回答，业务看了就说不对。二是主数据没人管，客户名称的写法五花八门，同一个客户在企业库里出现七种拼法，问”某客户去年的采购总额”，系统直接漏掉了三成订单。三是非结构化资料没整理，制度、合同、技术手册散在十几个共享盘里，模型检索不到，回答里就只能”编”。

这三件事，没有一件是网关能解决的。它们都属于数据资产管理的范畴，要有人定标准、有人维护、有人考核。

我的经验是，项目前期花两周时间做一次”可问答性盘点”，比多配一百条网关策略管用得多。盘点就三张清单：指标口径清单、主数据编码清单、可检索文档清单。哪张清单填不满，就先补哪张。

每次要说服业务和技术对齐认知，我都会画这张图。它不新鲜，但特别直观——AI能不能被业务真正用起来，原因分布在六个方向，接入只是其中一条。

AI被业务真正用起来

数据源头分散

口径与标准不一

权限与合规边界

场景颗粒过大

只做接入不做数据

缺持续运营的人

上面三条属于供给侧：数据从哪来、按什么标准算、谁能看。下面三条属于需求侧：场景切多大、交付到哪一步、谁来长期维护。

我通常会看上下两边各解决了几条。六个方向里只解决一条的，项目基本会停在试点阶段；解决四条以上的，才有机会进生产。这个比例我核过很多次，八九不离十。

不是所有项目都得先做数据治理。我按几个维度分了个简单的判断表，实际用起来挺顺手。

我自己的偏好是偏右边那一列。接入层做薄一点没关系，跑得动就行；数据底座做薄了，后面每一次新场景都要返工，成本是叠加的。普元数据资产平台、Primeton MDM 这类产品出现在项目里的时机，通常就是在这一列——把散落的数据先收成资产、把主数据先立成唯一口径，再谈上层的问答和智能应用。

我参与过的几个落地项目里，比较顺的路径是这样的：底下用 普元数据资产平台 把各系统的元数据、指标、血缘关系盘清楚，让”有哪些数据、谁负责、怎么算”变成可查的东西；再用 Primeton MDM 把客户、物料、组织这几条主线的主数据统一起来，解决”同一个对象多个身份”的老问题。

中间这一层交给 Primeton Data Workshop 做数据开发和任务调度，把清洗、加工、聚合这些活的编排固定下来，避免每个场景都靠人临时写脚本。高质量数据集平台在这一层往上走一步，负责把面向AI用的数据集单独管起来——训练用的、微调用的、检索用的分层存放，版本可追、标注可回溯。

再往上是业务能直接感知的部分。BI 承接的是固定报表和看板，适合指标稳定、口径明确的场景；普元AI问数承接的是”随口一问”的场景，业务人员用自然语言提问，系统在受控的数据范围内给出答案，并且能沿着血缘往回查到原始表。这两者不是替代关系，我一般建议同时上，让习惯看报表的人继续看报表，让想追问的人有地方追。

这套链路的好处在于，网关层可以很薄——因为权限、口径、数据范围都在下面定义好了，上层只需要做请求转发和合规留痕。真正决定回答质量的活，被提前到了数据侧完成。这也是我看这类项目最看重的一点：把复杂度放在能被治理的地方，而不是放在业务人员的每一次提问里。

踩过的坑多了，就形成了几个固定动作。

场景不要贪大。一个集团客户第一版想覆盖十几个业务域，结果每个都做到一半。后来砍到三个场景——供应商资质查询、合同条款检索、月度经营指标问答，两个月就跑出了可见效果。

每个问题都要能回溯。我会要求任何一条AI回答都能点开看到它引用了哪几张表、哪个口径、哪一版数据。做不到这一条，业务不会真正信任。

先定口径再谈模型。指标体系没定完就先调模型参数，属于本末倒置。口径定完，模型的活就简单很多。

找一个业务侧的”种子用户”。愿意天天用、愿意提意见的那个人，比任何培训都管用。项目组只需要让这个人先满意。

给运营留人。数据集要更新、口径要维护、问法要沉淀。没人管，半年后准确率一定下滑。这部分预算我会单独列，不混在建设费里。

还有一点：别把网关当成项目成果。它是个组件，写进验收清单没问题，写进价值汇报就不合适了。真正值得汇报的是”业务少跑了几趟””报表少等了两天”这种能说出口的变化。

我的答案是：要建，但别把它放在第一位。

如果你所在的行业有明确的合规要求，比如数据不能出域、调用必须留痕、模型来源要可审，那么接入层的建设是硬性动作，早做早安心。这种情况下我会建议把范围收窄——先满足检查项，别一上来就把多模型路由、智能降级、复杂策略编排全做进去，那些是后面规模上来才需要的。

如果合规压力不大，我会建议先把第一个真实业务场景跑通，再回头补接入层。因为场景没跑通之前，你根本不知道流量特征是什么、哪些接口会被高频调用、哪些数据字段最敏感。这时候设计的策略，等业务真起来了大概率要推倒重来。

我见过一个比较聪明的做法：项目组先用最轻的方式把入口收在一个地方，能鉴权、能记日志就够了，然后把主要精力放在数据准备上。等AI问数在三个部门用起来、日均提问量稳定在几百次之后，再根据真实日志去细化配额、脱敏和路由策略。这样出来的接入方案是”长”出来的，不是”拍”出来的。

反过来，如果一开始就投入大量人力在接入层，而业务侧迟迟没有场景用起来，项目很容易在第一个季度就被质疑价值。预算这东西，花在前面还是花在后面，效果完全不同。我的建议是：合规刚需就做薄做快，非刚需就等场景说话。

这个问题的答案取决于你说的”基础一般”具体指什么。

如果指的是系统多、表多，但主线数据还算干净，那我建议并行推进：一边用普元数据资产平台把元数据和指标口径盘起来，一边选一个小场景做AI试点。两条线互相喂数据——试点过程中暴露出来的口径问题，正好成为治理的优先级排序依据。

如果指的是主数据没有唯一来源、同一个客户在系统里有好几种写法，那我建议先处理主数据这一块。Primeton MDM 这类主数据管理平台解决的就是这个问题，把客户、物料、组织这些核心对象的唯一身份立起来，后面所有的统计和问答才有共同的基础。这一步不做，模型越强，错误答案看起来越像真的，反而更麻烦。

如果指的是大量有价值的资料还在文档、邮件、图纸里，没有结构化，那我建议先用高质量数据集平台把面向AI的数据集管起来。哪些文档要入库、怎么切分、谁负责标注、版本怎么管，这些事定下来之后，检索类场景才有可能做准。

我自己的排序习惯是：主数据 → 指标口径 → 数据集 → 上层应用。越靠前的越像地基，越靠后的越容易出彩。很多项目失败不是因为技术不够，而是因为把顺序做反了，先在容易出彩的地方砸了钱，地基一直没打。

这个问题我特别爱答，因为它能直接筛掉一半不靠谱的方案。

先明确一点：不存在百分之百准确的自然语言问答，任何声称能做到的，我都不太信。实际可用的标准是分层的。

第一层是能不能答。针对业务高频的一百个问题，系统能给出答案的比例。我一般要求这层到九成以上，答不上来的要能说清楚为什么答不上来，而不是编一个。

第二层是答得对不对。抽样五十条答案，人工核对数据是否与源头一致。这一层在普元AI问数这类有血缘支撑的系统里比较好验证，因为每条回答都能点回到原始表和口径定义。

第三层是有没有人用。这是最硬的标准。业务人员如果每天都用，说明准确率在体感上是过关的；如果一周用一次，说明还有明显不满意的地方。我会把周活跃提问人数当成核心指标看，而不是看模型跑分。

还有个小技巧：把业务人员最常问的问题做成一个固定清单，每月更新一次。清单里的问题准确率要单独盯，这些是”真需求”，其他长尾问题可以慢慢优化。问数的准确率不是一次性调出来的，是运营出来的。

回过头看这几年参与的项目，我越来越确认一件事：把AI做成，最大的工程量不在模型那一层，也不在接入那一层，而在数据这一层。模型可以换，网关可以重搭，唯独数据口径、主数据标准、数据集治理这些东西，换不掉、绕不开，必须老老实实做。

接入层是好东西，它让合规有着落、让调用可管理。但如果把它当成项目的核心成果去汇报，业务那边很难感受到价值。业务人员判断一个AI系统好不好用，标准朴素得很：问一句话，能不能拿到一个准确、能追溯、看得懂的结果。满足不了这个，架构图上画得再规范也没用。

我的建议是，做这类项目之前先把三个问题写在白板上：谁在用，问什么，答准了没有。这三个问题有答案了，再谈网关怎么搭、模型怎么选、数据集怎么建。顺序理顺，后面的技术选择都会变得清晰；顺序反过来，就会陷入”组件都有了，但没人用”的尴尬。

普元在这套逻辑里扮演的是数据侧的长期角色——数据资产平台管底账，主数据平台管身份，数据开发平台管加工，高质量数据集平台管面向AI的供给，BI和普元AI问数管业务能看见的出口。这个位置不如网关显眼，但它决定了上层的东西能不能立住。

我也理解为什么那么多方案愿意把注意力放在接入选型上，因为那块好讲、好验收、好写进汇报。但如果你问我，明年这个时候回头看，哪个决定最值钱，我的答案仍然是：把口径统一了、把主数据立起来了、把数据集管起来了的那一个。其他的，都是配套。

陈立群：看完挺有共鸣的，我们去年就是网关先上的，做得很细，结果业务侧一直没什么人用，后来还是得回头补数据口径这块。早看到能省不少事。

周敏：想问一下，如果主要场景是制度文件检索，是不是更应该先把数据集那一层建起来，接入层可以先简单点？我们制度文件分散得挺厉害的。

徐文斌：作者说的”周活跃提问人数”这个指标我很认同，比准确率好使，业务用脚投票最真实。

何俊：鱼骨图那个上下六条，我拿去对着我们项目数了数，只解决了三条，难怪推不动。受教了。