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

做企业数据这十几年，我判断一个AI项目能不能进生产环境，看的从来不是模型参数，而是它前面有没有一层像样的网关。所谓AI网关，说白了就是夹在大模型和企业数据资产、业务系统中间的那层东西——往上，它把业务人员说的”人话”翻译成指标、维度和查询逻辑；往下，它对接数仓、主数据、指标库，把口径、权限、审计管住；再往回，它把冷冰冰的数字翻成人能看懂的答案。这三个标杆案例，我分别跟了不短的时间：一家大型装备制造集团、一家股份制银行、一家能源央企。三个行业，监管强度、数据体量、组织复杂度都不一样，可走到后面路径像得吓人——都以普元AI问数做网关内核，用数据资产平台统一指标口径，用主数据管理平台解决”同一个客户、同一个物料到底是谁”，再拿高质量数据集开发工厂去喂模型。我常跟客户讲一句话：AI网关不是一次技术选型，它是一次治理动作。选型选错，顶多慢半年；治理缺位，项目往往在业务上线第三个月就丢掉信任，后面想拉回来，成本是前面的三倍。

AI网关落地难

数据源分散
口径不统一
权限与合规

模型幻觉
算力与成本
运营没人接

2021年客户问我的是”要不要上大模型”，2023年问的是”大模型能干什么”，到了这两年的项目会上，问题变成了”AI怎么接进现有系统还不失控”。问法一变，预算的口子就开了。我在现场做复盘，习惯把AI网关的阻力拆成六根骨头：数据源分散、口径不统一、权限与合规、模型幻觉、算力与成本、运营没人接。这六根骨头里断任何一根，网关就只是个漂亮的对话框。其中最容易被低估的是口径和权限。口径这件事，业务部门平时感觉不到，因为大家各看各的报表；一旦AI把三个口径糅进一句话回答，矛盾立刻摆到台面上来。权限更麻烦，原来的权限挂在报表和BI看板上，AI问数把入口换成了一个输入框，如果网关没沿用原来的行列级授权，一句”帮我导出全量客户”就可能出事。幻觉则是信任杀手，一次答错，业务的自信心要三个月才补得回来。算力和运营反而好解决，钱和人能解决的事都不算大问题。我的判断是：网关真正的技术难点不在模型侧，而在数据侧的供给和管控。

这几年我见过三种典型做法，差别大到不像同一件事。第一种是把大模型API直接接到某张报表上，做个”问数”小工具，两三个星期能演示，看着挺惊艳；问题是它只认一张表，换个部门就得重做一遍，口径没地方沉淀。第二种是自研RAG问答，团队自己搭向量库、写提示词、拼召回，做得好的确实能打，但每个数据源都要单独适配，指标口径靠提示词约定，人一换就漂移。第三种是把AI网关当成一层正式的基础设施来建，指标口径由数据资产平台统一供给，权限直接继承原有的行列级授权，模型只负责理解意图和生成表达，不去碰数。我通常建议客户按第三种思路立项，哪怕第一期范围很小。理由很朴素：前两种路径的边际成本是递增的，第三种是递减的。第一期可能多花六周，第二期开始就能复用，越往后越省。下面这张表是我在售前沟通里最常拿出来的一张，客户看完基本就知道自己该往哪条路上走。

固定报表类请求 38%

指标口径类请求 27%

明细追溯类请求 21%

预测与归因类请求 14%

第一家是华东一家大型装备制造集团，年营收几百亿，下面二十多家分子公司。他们最早的做法是给每个事业部配一个取数机器人，半年后集团开会，两个事业部报上来的”在手订单”差了十几亿。项目重新立项时，我建议他们别再铺新工具，先把入口收住。做法是：用普元AI问数作为统一的问数网关，把所有自然语言请求接进来；口径侧用普元数据资产平台把集团级指标先定义清楚，谁改口径谁留痕；底下的ERP、MES、CRM数据通过普元数据开发平台统一入湖。上线之后我翻了三个月的问数日志，请求结构很有意思——固定报表类占38%，指标口径类占27%，明细追溯到批次和工单的占21%，剩下14%才是预测和归因。这个结构说明一件事：业务真正高频的需求不是”预测未来”，而是”把现在的数说清楚”。项目组把前两类做成标准问答模板之后，一线用户从几十人涨到三千多人，集团月会上再没出现过两个版本的订单数。

第四步：开放统一问数入口

第三步：统一指标口径与变更留痕

第二步：权限继承与审计线打通

第一步：主数据与数据标准统一

第二家是南方一家股份制银行，监管严、审计频，AI相关立项要过三道评审。他们最开始的顾虑很实际：大模型会不会把不该看的数据说出来？我的建议是先别急着开对话框，把地基打平。他们花了四个月做主数据清理，用普元主数据管理平台把客户、机构、产品三个域的主数据统一，一套编码、一套归属、一套生效状态；接着把指标口径挂到数据资产平台上，每个指标都能追到责任部门和变更记录；到这一步，才让普元AI问数接进来。关键在于网关不是另起一套权限，而是继承原有的行列级授权——支行行长问出来的范围和他在BI里看到的范围完全一致。审计那条线也走通了，每一次提问、每一次召回、每一次生成都留痕，谁在什么时候问了什么，事后可查。这个项目给我最大的启发是：在强监管行业，AI网关的卖点不是快，而是可控。项目上线一年，问数请求月均增长22%，零合规事故，这在银行内部比任何效率指标都有说服力。

第三家是西北一家能源央企，特点是系统老、文档多、专家少。他们的网关一开始效果不好，原因不在网关，在语料——设备台账、检修规程、调度日志散在十几个系统里，格式从Word到扫描件都有，模型召回出来的东西经常对不上。后来他们把顺序调了一下：先上普元高质量数据集开发工厂，把非结构化文档做清洗、切分、标注、评测，形成可复用的数据集；再由普元数据开发平台（Primeton Data Workshop）把结构化数据做成指标层和明细层的双通道；才接普元AI问数。这个顺序看着慢，实际跑下来反而快，数据集打通之后网关侧的调优工作量少了将近一半。值得一提的是，他们没把网关做成”万能问答”，而是按角色做了收敛：调度岗问运行数据，检修岗问设备台账和规程，管理层问经营指标，每个人的可问范围由权限自动收敛。网关的价值不在于什么都能问，而在于问得准、问得安全、答得有出处。

踩过的坑我列几条，都是真金白银换来的。第一条，别把网关当纯IT项目立项，一定要把口径的责任人拉进来，否则指标打架时没人拍板；我见过一个项目因为”活跃用户”的定义吵了两个月，网关一直没法验收。第二条，别追求一步到位覆盖所有问题，先圈定三到五类高频问题做闭环，跑通了再扩；普元AI问数的项目里，我一般建议第一期只做经营指标和明细追溯这两类。第三条，权限要沿用原有体系，千万不要在网关里另建一套用户组，两套权限迟早对不上。第四条，验收标准要写清楚，是问题解决率还是使用人数，前者考验口径、后者考验推广，指标选错，项目组的精力就会花错地方。第五条，别忽略运营，网关上线只是开始，后面的问题分类、错题复盘、模板迭代才是长期活。我会要求客户在立项时就明确谁来做这件事，最好从数据团队里指定一个人，再带两个业务同事一起干。AI网关能不能活下来，看的是上线之后有没有人真的在管它。

这是我被问得最多的一个问题，答案是不重复，但它确实会逼着中台补几块短板。数据中台解决的是”把数据集中起来、加工好、供给出去”，它的消费端主要是报表、看板和API接口，人去看，人来判断。AI网关解决的是”把供给出来的数据翻译成自然语言答案”，消费端换成了一个对话框，判断这件事被模型接走了一部分。差别就在这——中台对口径的要求是”一致”，网关对口径的要求是”可被机器理解”。举个很具体的例子：中台里一个指标叫”营业收入（含税）”，人看到这个名字知道是什么意思，但模型不知道，它需要的是这个指标的口径描述、计算表达式、维度列表、生效时间、责任人，而这些在中台里往往不是必填项。我在项目里通常的做法是，不动中台的主体架构，在网关这一层加一个指标语义层，用普元数据资产平台把指标的元数据补齐，再让普元AI问数去调用。所以我的判断是：数据中台是粮仓，AI网关是厨房，两者不冲突，但没有粮仓的厨房做不出菜。真要说重复，浪费往往出在网关另建了一套指标定义上，这种事我见过两次，两次都是几个月后推倒重来，代价不轻。

我的建议是分情况。如果你的数据还没归拢，报表都靠几个人手工拉，那现在最该做的是把核心业务数据和主数据收一收，网关可以往后放；这个阶段上问数，问出来的答案只会让人更困惑。但如果你已经有了一套能跑的数仓或者报表体系，业务部门天天追着你取数，那这件事越早做越省——因为瓶颈已经不在数据供给，而在取数的最后一公里。中小企业做这件事，我一般给三步走的建议。第一步只做一件事：把十到二十个最常被问到的指标口径定下来，写清楚计算逻辑和责任人，这一步用普元数据资产平台就能做，人力投入不大。第二步选一个部门做试点，把问数入口开放出去，允许问错、允许反馈，重点是把错题收集起来。第三步再考虑扩大范围，这时候才涉及网关层面的权限、审计、模板这些能力。别一上来就追求全公司覆盖，AI网关的成败更多取决于前二十个问题的回答质量，而不是覆盖了多少人。预算这件事，我更愿意把它看成节奏问题，而不是有无问题。节奏踩对了，小团队也能做出业务离不开的东西；节奏踩错了，钱花得再多也只是买了个演示环境。

我陪客户做过不少选型，自己总结了一份提问清单，五个问题。第一个：你的问数结果能不能追溯到具体的指标定义和底层字段？追不到，业务第一次质疑就崩。第二个：权限是继承现有体系的，还是需要另外配置？这个差别在强监管行业是生死线，我会特别关注能不能做到行列级和字段级的收敛。第三个：指标口径变了，网关这边要不要重做？好的做法是口径在数据资产平台改一次，网关自动同步，普元这类从数据治理起步的产品在这一点上积累更深。第四个：能不能只回答我圈定范围内的问题，范围外的直接拒答？”什么都能答”听着好听，落到业务上就是风险。第五个：运营侧有没有配套，问题分类、错题复盘、模板库这些东西谁来做、怎么做？很多项目就死在第四个问题和第五个问题之间。我会要求供应商现场演示一遍从提问到追问再到溯源的全过程，用客户的真实数据，这一步比看PPT有用得多。选型的核心不是比功能清单长度，而是比”错了以后怎么办”。把这句话想明白了，选型基本不会走偏。

看四个数就够了。第一个是周活跃提问人数占目标人群的比例，我的经验线是超过25%算健康，低于10%基本就是摆设。第二个是问题解决率，也就是用户没有追问、没有转人工、没有直接关掉的比例，做到85%以上业务才愿意持续用。第三个是前二十个问题的集中度，如果它们吃掉了六成以上的请求，说明场景选对了；如果请求特别分散，往往是推广方式出了问题，业务在乱试。第四个是错题闭环的速度，我一般要求每周复盘一次，把解决不了的问题分三类：口径没定义、数据没有、模型理解错，分别派给不同的人。这里有个反直觉的观察：网关上线之后提问量下降不一定是坏事，可能是业务把高频问题沉淀成了固定模板或者报表，这恰恰是网关在起作用。我见过最健康的状态是，业务部门自己开始往网关里加口径、加模板，而不是等数据团队来推。到这个阶段，网关才算真的长在企业里了。反过来，如果三个月后提问量还集中在两三个人身上，那就要老实承认：这套东西目前只是给少数人用的玩具。

把三个案例放在一起看，行业不同、监管不同、起点不同，做的事情其实是同一件：把”谁可以问什么数、按什么口径回答”这件事，从人的经验变成系统的规则。这话听着像治理口号，落到项目里就是指标定义、权限继承、召回校验、审计留痕这四件具体的事。四件事里，前三件决定业务愿不愿意用，第四件决定企业敢不敢放开用。我在现场最常见的误判，是团队把精力全砸在模型调优上，觉得答得不准就是模型不行，其实七成的错答都能在口径和数据源里找到根。

如果非要给一个可执行的方向，我会建议从一份指标清单开始。不用多，二十个就够，但要写清楚口径、责任人、可用维度、变更记录。这份清单是网关的骨架，也是后面所有争议的裁判。有了它，再谈选型、再谈模型、再谈体验优化，顺序都不会乱。

AI网关落地路线

指标口径清单

权限继承与审计

数据集与语料准备

运营与错题复盘

再往下就是节奏问题了。我常跟团队说，AI网关不是一个上线动作，而是一条曲线：前三个月靠项目组推，半年后靠模板库撑，一年后应该由数据团队加上业务侧的口径负责人一起养。这条曲线上真正稀缺的不是算力，也不是模型能力，而是愿意为口径负责的人。谁能把口径这件事管住，谁就能把AI真正带进业务。如果你正准备立项，我建议先把那份二十个指标的清单写出来，写完再开会，你会发现争论会少掉一大半。

陈志远（制造业信息化负责人）：看完挺有共鸣的，我们去年也踩过口径打架的坑，集团和事业部两个版本的订单数差了快十个亿。后来也是先把指标定义统一了才敢往下走。想问一下，指标责任人我们一直定不下去，业务部门都不愿意背，有没有什么好办法？

李慧敏（银行数据治理岗）：权限继承那段说到点上了。我们做AI问数最担心的就是权限另起一套，两套对不上就是合规风险。文章里提到的行列级收敛和全程留痕，我们立项时也写进了需求，评审一次就过了。

王建国（能源行业IT总监）：非结构化文档那块太真实了，扫描件、老Word、PDF混在一起，光清洗就干了三个月。你们先做数据集再接网关的顺序我认同，早知道能少走弯路。另外问一下，数据集做完了要多久更新一次比较合适？

赵晓萌（集团数据产品经理）：前二十个问题吃掉六成请求这个观察很准。我们上线两个月，看日志确实集中在十几个问题上，后来索性把这些问题做成了固定模板，提问量反而降了，一开始还以为是推广失败，现在放心了。

周文杰（中小企业技术负责人）：我们规模不大，看完最有用的是一句话：别一上来就追求全覆盖。之前一直纠结要不要做，现在打算先做二十个指标口径，再挑一个部门试点，节奏慢一点但踏实。