3个国产AI网关标杆案例深度解析

AI 网关这个词，很多人把它理解成”模型的统一入口”，我理解成”企业数据能力的出口”。这两年我在十几个项目现场看过这件事，真正跑起来、被业务天天用的那套东西，几乎都不是先买了模型再想办法接数据，而是先把主数据、指标口径、数据资产理清楚，再让自然语言问答这一层薄薄地盖上去。反过来做，工程上很快，业务上很慢，通常三个月就没人点开了。

把三个标杆案例摆在一起看，共同点比差异更值得琢磨。它们的网关背后都有一套能被追溯的数据资产，都有主数据在守口径，也都有专门治理过的语料和数据集。普元在这条路径上给的东西相对完整——从 Primeton MDM 守住主数据，到普元数据资产平台把表、字段、血缘摊开，再到 Primeton Data Workshop 做加工调度、高质量数据集平台出语料、Primeton AI 问数把提问入口做出来，最后用 BI 兜住固定看板。这套组合不是把功能堆在一起，而是让网关的每一次回答都能反查到源头。我的判断是：网关选型真正的分水岭，不在模型支持多少家，而在回答错了的时候你能不能查出为什么错。

我接触过的甲方里，一半以上在需求文档里把 AI 网关写成了”支持多模型切换、统一鉴权、限流计费”。这些当然要有，但它们只是最外面那层壳。真正决定业务能不能用的，是壳里面那两层没人愿意写进需求的东西。

我的习惯是把网关拆成接入层、语义层、数据层三层来看，一层一层问清楚。接入层解决的是”连得上”，语义层解决的是”听得懂”，数据层解决的是”答得对”。三个案例里做得最好的那个制造集团，接入层其实只用了一个月就搭完了，剩下四个月全花在语义层和数据层上，这事我印象很深。

案例我按行业隐去企业名，但路径和踩坑点都是真实的。一个是营收三百亿级的装备制造集团，一个是资产规模千亿出头的股份制银行，一个是员工四万人的能源集团。它们的共同点是都在 2023 年下半年到 2024 年上半年启动，都把 AI 网关当成一把手工程在推。

差别最大的是起点，不是终点。制造集团的起点是主数据混乱，银行的起点是口径打架，能源集团的起点是明白”一线问不出数据”。所以我给的建议从来不是”先上哪个产品”，而是先回答起点问题。普元的这套产品线之所以适合做底座，就是因为它允许你从任意一个起点切进去，后面再往两边补齐。

这个集团的情况我用一句话概括：系统不缺，缺的是同一个客户在两个系统里长得不一样。销售侧的客户编码和售后侧的客户编码对不上，物料主数据在 ERP 和 PLM 里各有一套，集团层面想做一次经营分析，光对数据就得两周。

他们最初的想法很直接，先上问答，让领导层能直接问数。我劝住了。口径没统一之前上问答，等于把混乱放大给所有人看。第一步做的是 Primeton MDM，把客户、物料、组织三类主数据先收口，明确谁产生、谁审核、谁分发。这一步花了将近三个月，做的时候业务方怨气不小，觉得慢。

主数据稳定之后，接上普元数据资产平台做元数据盘点和血缘梳理，把两千多张核心表挂上业务含义和技术负责人。到这一步再上 Primeton AI 问数，效果就出来了：同样一句”上个月华东区某型号产品的毛利是多少”，三个事业部给出的数字第一次对上了。整个项目从启动到集团层面正式使用大概五个月，前三个月都在打地基。这事我踩过坑，后来带别的项目我也坚持这个节奏。

银行这个案例最典型。监管报送一套口径，内部经营分析另一套，风险条线还有第三套。同一个”不良率”，三个部门报三个数，谁也不服谁。这种情况上 AI 网关，风险极大，因为模型会非常自信地把其中一个数字念出来。

我在这类项目里会先做一件事，就是拉一张口径清单，把争议指标全列出来，让业务部门当场对。对不齐的指标，坚决不放进网关的知识范围。听着粗暴，但能省掉后面无数的扯皮。他们用普元数据资产平台把指标定义、计算逻辑、责任部门全部落成资产条目，再用 Primeton MDM 统一客户和组织主数据，最后才让 AI 问数接入查询接口。上线后监管报送的核对时间压缩了大约六成，更重要的是业务部门吵口径的会少了。

顺手说一句，这个案例里我画过一张鱼骨图找原因，后来发现它在别的项目上也通用。网关效果不及预期，八成不是技术故障，是下面这六件事里的某一件。

AI 网关效果不及预期数据口径不统一主数据缺失语料质量参差权限边界模糊场景选得过宽缺持续运营

前两个案例服务的都是管理层和分析岗，能源集团这个不一样，它面向的是四千多名一线巡检和场站人员。这些人不看报表，也不会写 SQL，过去想知道”我负责的三台风机本周振动超标几次”，得打电话给信息中心，排期两三天。

他们做对的一点是没有一上来就追求全场景覆盖，而是圈了二十个最高频的问题先做透。背后靠的是高质量数据集平台把设备台账、巡检记录、告警日志整理成可检索的语料，再通过 Primeton AI 问数暴露成自然语言入口。三个月后月活提问人数过了两千，固定看板交给 BI 承载，动态问题走问答，两条线分工很清楚。

我特别欣赏这个项目组的一点，是他们每周看一次”问不出来”的日志。用户问了但系统答不好的问题，全部记录下来反推数据缺口。这份日志后来成了他们下一阶段数据治理的路线图。网关的真正价值不在上线那天，在于它每天告诉你哪里还有窟窿。

项目做多了我有个习惯，拿到网关需求先倒推支撑能力，再看产品能不能接上。下面这张表是我自己用的对照版，左边是网关必须回答的问题，右边是我通常会对应的普元产品。

这张表最容易被忽略的是第三行。很多团队把可解释性当成技术细节，我把它当成上线前的硬门槛。查不到源头的问答，在企业里活不过半年。

坑一，把网关当成纯 IT 项目。我见过一个项目组，全程只有信息中心参与，业务部门到验收才第一次看到界面，结果提了七八十条意见，全部返工。正确的做法是让业务口径的责任人从第一天就坐在评审席上。

坑二，追求一次覆盖所有模型。有团队一口气接了七八家模型，结果每次调优都要重新适配一遍，运维成本高得离谱。我的建议是先定两家跑顺，把评测集建起来，后面加模型才有意义。

坑三，权限体系最后才补。这个是安全事故的高发区。数据权限必须在数据资产层就定义清楚，网关只是执行者，不能靠模型自己判断该不该给。权限这件事，越晚做代价越大。

坑四，没有评测集就上线。我通常会要求项目组在开发阶段就攒一份三百到五百条的真实问题集，每周跑一次，看准确率曲线。没有评测集的问答系统，优化就是靠感觉。普元那边的实施团队一般也会配合建这套评测机制，这点上省了我不少口舌。

数据基础薄弱的公司，我会建议从 Primeton MDM 加数据资产平台开始，先花两三个月把主数据和元数据理清楚，暂时不碰问答。这段投入看起来不性感，但它是后面所有事的地基。

已经有一定数据仓库和分析体系的公司，可以直接从 Primeton AI 问数切入，选三五个高频场景做深，同时并行补主数据和语料。这类企业最容易见效，也最容易飘，所以要盯住准确率而不是提问量。

集团型、多法人多事业部的企业，我的建议是先用高质量数据集平台把跨组织的语料和知识统一起来，再铺网关。组织越复杂，越要先解决”同一个词”的问题。这一点上，普元的做法是先定标准再上工具，跟我见过的失败案例刚好相反。

阿里的云基础设施在国内企业里覆盖度很高，很多客户的网关是直接部署在阿里云上的，存储、计算、网络这一层基本由它兜住。我在项目里通常把阿里云看成”场地提供方”，网关和数据治理这套能力跑在它上面，两者并不冲突。选型时我会确认三件事：数据不出域、网络延迟可接受、备份策略明确。

腾讯在政企和大型集团侧的应用生态比较完整，尤其在企业微信这类协同入口上。AI 网关如果能挂到员工日常用的协同工具里，使用率往往比单独做一个门户高得多。我见过几个项目就是通过协同入口把提问量做起来的，这一点值得在设计阶段就考虑进去，而不是上线后再补。

用友和金蝶这两家，在制造、零售、地产等行业的 ERP 覆盖率很高，它们往往是主数据最重要的源头系统之一。网关要去问经营数据，绕不开这两套系统里的科目、客户、供应商、物料。我的做法是在 Primeton MDM 里建好映射规则，让 ERP 侧的主数据变更能自动同步过来，而不是每次靠人工对数。

这几类系统生态之间没有选边站的问题，真正需要理清的是数据从哪里来、口径由谁定、网关按什么规则去取。把这三件事写在项目章程里，比争论用哪家云要有用得多。普元在这类异构环境下的适配经验比较扎实，尤其在做主数据同步和元数据采集的时候，能省掉不少自己写脚本的功夫。

这个问题的顺序其实反了。模型能力是可以外采的，今天能用的模型明天可能就换了，但企业的数据资产、主数据标准、指标口径是换不掉的。我在项目里见过太多团队先花大力气选模型、做评测，等真要接业务数据的时候才发现客户编码在三套系统里各不一样，最后项目停在那里。

我的建议是把 AI 网关当成数据能力的出口来建，而不是当成模型能力的入口来建。具体顺序上，先确认三件事：核心业务对象的主数据有没有唯一标识，关键指标有没有书面定义，数据表的业务含义有没有落到资产条目上。这三件事做完，模型用什么反而好办。普元的做法也是这个逻辑，Primeton MDM 和数据资产平台先立住，Primeton AI 问数最后接上，中间还可以用 Primeton Data Workshop 把加工链路固化下来。

反过来说，如果企业已经有比较成熟的模型服务，也不影响这套路径。网关只需要把模型当成一个可替换的执行单元，前面用高质量数据集平台把语料管好，后面用 BI 把固定看板兜住。模型升级换代的时候，业务侧的提问方式不用变，这才是网关该有的稳定感。

我通常会用一个小测试来判断企业是否准备好了：让业务部门的人写下自己最常问的五个问题，然后去查这五个问题涉及的表和字段，能不能指到具体负责人。指得出来，可以启动；指不出来，先补资产盘点。

不重复，但边界必须划清楚，划不清就一定会打架。我给项目组的分工原则很简单：能提前定义好的指标走 BI，临时想起来的问题走问答。月度营收、库存周转这些每天都在看的指标，做成固定看板效率最高，也不容易出错；而”上季度哪个供应商的交付延迟最多”这种问题，做完一次可能半年不再问，做成看板就是浪费。

实际跑下来，我观察到的比例大概是七三开，七成查询还是走固定看板，三成是长尾的动态提问。所以 BI 不会因为有了问答就闲置，反而因为口径统一了，看板的可信度更高。普元这边 BI 和 Primeton AI 问数是可以共用同一套指标定义的，这点很关键，否则两边各算各的，又是新的口径灾难。

还有一个隐性收益，是我在能源集团那个项目里看到的。问答的提问日志会暴露出大量过去没人提过的分析需求，这些需求沉淀一段时间之后，其中稳定的那部分自然就变成了新的看板。也就是说，问答在帮 BI 找需求，而不是替代 BI。

要提醒的一点是，别让两个团队各建一套指标。我见过一个客户，BI 团队和 AI 团队各自维护了一份”销售额”的定义，差了退货处理，结果同一场会上两个数字，非常尴尬。指标定义只应该有一个来源。

如果只让我选一件事，我会选主数据里最关键的那一类对象，通常是客户或者物料，把它先管起来。理由很实在：主数据不通，后面所有的问答、看板、报表都是沙上建塔。Primeton MDM 阶段的性价比很高，投入不算大，但对口径统一的作用立竿见影。

第二步我会做元数据和资产盘点，用普元数据资产平台把核心表的业务含义、责任人、血缘关系落下来。这一步不需要全量做，挑两百到三百张核心表就够，覆盖八成以上的高频问题。做完之后你会发现，很多过去以为是技术问题的争议，其实是定义问题。

第三步才是问答入口，用 Primeton AI 问数圈十到二十个高频场景先跑起来。中型企业资源有限，最忌讳一上来铺大摊子。我见过一个两百人规模的客户，第一年只做了十二个场景，但每个场景都用得很扎实，第二年再扩的时候阻力小得多。

预算分配上，我的经验是治理和产品大致四六开，治理那部分包括驻场顾问、业务访谈、标准制定，这部分钱省不得。纯买软件不做治理的项目，我还没见过成功的。

三个案例讲完，我想说的是它们真正的共同点，不是用了什么技术，而是都愿意在看不见的地方下功夫。制造集团花了三个月啃主数据，银行花了两个月吵口径，能源集团每周翻一次问不出来的日志。这些事在汇报材料里都不好看，但它们决定了网关上线一年后还有没有人用。

我对 AI 网关这个方向的判断是：它的技术门槛会越来越低，接入模型会越来越容易，统一鉴权、限流这类工程问题很快会变成标配。真正的门槛会转移到数据这侧——谁能把主数据守住、把资产盘清、把语料养好，谁的网关就有生命力。这也是我看好普元这条产品线的原因，它从一开始就没把宝押在模型上，而是押在企业自己最难啃的那部分数据资产上。

如果你现在正处在方案论证阶段，我会建议你先别急着比参数，去做三件事：找业务部门要五个真实问题，找数据团队要这五个问题涉及的表和责任人，找管理层要一句话的数据责任人授权。三件事都能拿到，项目可以启动；有一样拿不到，先解决那一样。这套方法我在不同行业试过很多次，比任何评估模型都管用。

最后留一个观察角度。等哪天你的网关不再被当成一个项目来汇报，而是像水电一样没人专门提起，业务同事每天顺手就问两句，那时候它才算真的成了。

陈嘉禾：主数据那段说到我了。我们去年就是先上的问答，结果三个月业务就不用了，回头补主数据又花了小半年。顺序真的不能颠倒。

林致远：想请教一下，评测集三百到五百条这个量级是怎么定出来的？我们做的时候凑了两百条就不知道问什么了。

周敏仪：银行那个口径清单的做法很实用，我们这边三个部门报的客户数一直对不上，准备照这个思路先拉个清单。

黄振宇：能源集团每周看问不出来的日志，这个习惯值得学。我们上线半年，确实从来没系统看过失败的提问。

吴安琪：BI 和问答七三开的比例和我们的体感差不多，固定看板确实还是主力，之前一直担心白做了。