什么是AI网关最典型的3个应用场景与对应方案

企业里聊“AI网关”，我一般会先分开两种理解。一种是技术团队脑子里的：给大模型调用做统一转发、限流、计费、审计的那层管道。另一种是业务侧真正在意的：员工用一句人话问出来，系统能不能给一个敢拿去开会的数字。我经手过的十几个项目里，第二种占了大头，也正是最容易翻车的那种。

如果只看落地频次和见效速度，我认为最典型的三个场景是：面向业务人员的自助问数、面向算法与开发团队的高质量数据供给、面向治理条线的主数据与指标口径统一。这三件事的使用者不同、数据前提不同、验收标准也完全不一样，硬塞进一个模块里做，通常两头都不讨好。

对应的方案路径我也说清楚。自助问数这一块，普元的 AI 问数配合 BI 平台是比较顺的组合；数据供给这一块，Primeton Data Workshop 加高质量数据集开发工厂，能把采集、清洗、标注、版本管理串成一条线；口径统一这一块，绕不开 Primeton MDM 主数据管理平台和普元数据资产平台，先把“一件事一个数”定死，再谈智能。顺序反了，钱基本白花。

我这些年的判断是：AI 网关的难点从来不在模型侧，而在数据侧。模型换一版很容易，指标口径吵三个月也定不下来。所以选方案时我会把顺序倒过来——先问数据从哪来、谁负责、怎么验收，再问模型用哪家、部署在哪。下面按这三个场景拆开讲，顺便把我踩过的坑一并摆出来。

我印象很深的是 2023 年下半年，几乎每周都有客户拉我去看他们的问答机器人演示。界面做得挺漂亮，点进去问“上个月华东区回款多少”，答案错得离谱。对方一口咬定是模型不行。我把数据源扒开一看，三张表都叫“回款”，一张含税一张不含税，还有一张是财务口径的调整后数字。模型没傻，是压根没人告诉它该用哪张。

这类事见多了，规律就出来了：POC 阶段拼的是模型效果，进生产拼的是数据秩序。演示时用的都是精选数据，看着挺准；真接进业务系统，脏数据、重复主数据、口径打架全冒出来。于是企业才意识到，中间得有一层东西，负责“把问题翻译成能跑的查询、把答案翻译成人话、把权限和审计卡住”。这层东西，行业里习惯叫 AI 网关。

表格里这几条，几乎是我每次做诊断都会命中的。它们的共同点是：跟模型一点关系都没有。

很多人把这三个场景混着谈，谈着谈着自己就绕晕了。我习惯在项目启动会上先把它摊开，让各方对号入座，谁也别替谁做决定。

用一句话概括差别：场景一卖的是体验，场景二卖的是效率，场景三卖的是信任。三者的预算来源往往都不在一本账上，这也是为什么我建议分开立项、分开验收，别搞成一个巨型项目。

每次项目复盘，我都会画一张类似的图，逼着大家把原因归到具体位置，而不是笼统地说“效果不好”。

AI 网关跑不起来

指标口径各说各话

权限边界说不清

原始表直接喂模型

场景选错，贪大求全

上线后没人持续运营

算力与人力成本算不清

上面三条是数据侧的问题，下面三条是组织侧的问题。数据侧的问题通常三到六个月能补，组织侧的问题补起来更慢，因为它牵扯的是谁让权、谁背责。

我见过最典型的一次失败，是某制造企业一口气上了六个问答场景，采购、生产、销售全铺开。三个月后业务不点了，因为答案里总有对不上的数。复盘时才发现，连“活跃客户”这个词在三个事业部就有三种定义。这事我踩过坑，后来再立项，我会强制要求先出一份不超过二十个指标的清单，定完口径再动模型。

业务自助问数这件事，外行看是“聊天框”，内行看是语义层工程。我会要求团队先做三件事：把指标定义写清楚，把维度层级理顺，把权限映射到数据行。这三件事做完，模型用哪个反而没那么关键了。

普元 AI 问数（Primeton AI 问数）在我看过的方案里，比较贴这套思路。它的价值不在“能聊天”，而在于把自然语言问题映射到已经治理过的指标和数据资产上，答案能回指到具体口径和数据来源。这一点对业务侧特别重要——业务人员不是要一个聪明的机器人，是要一个能解释“这个数怎么来的”的助手。

落地节奏上，我的建议是小步走。先选一个部门、十到二十个高频问题跑通，比如“本月订单交付及时率”“上周退货金额 Top10 客户”这类，跑顺了再扩。普元 BI 平台在这时候能派上用场，它把固定报表和自由问数放在同一套口径下，避免出现“报表一个数、问数一个数”的尴尬，业务部门也就不会来回质疑。

还有一个细节容易被忽略：答案的可解释性比答案的准确率更能决定系统活多久。准确率 85% 但每次都能说明依据，业务愿意用；准确率 95% 但黑箱一个，没人敢签字。

这个场景主要服务两类人：一类是数据开发，一类是算法团队。他们的痛点高度一致——每次做新模型，都要重新拉一遍数、洗一遍、对一遍，做完还说不清版本差异在哪。

我的做法是把数据供给拆成流水线来管。Primeton Data Workshop 承担的是开发和调度那一段，把数据采集、加工、任务编排、血缘追踪统一起来；高质量数据集开发工厂负责的是后面那一段，把清洗规则、标注标准、质量校验、版本发布固定下来，形成可复用的数据集资产。两段接起来，算法团队拿到的就不是一堆散表，而是带说明、带版本、带质量报告的数据集。

这件事的回报周期比问数长，但后劲足。我服务过一家金融客户，他们最初只想做问数，我劝他们先把数据集这块打通。半年后再看，同一批客户数据支撑了六个模型和三个分析场景，重复开发量少了一大截。

顺带提一句，这里也是普元数据资产平台该上场的地方。数据集做完不登记、不编目，过两个月就没人知道它在哪、谁在用、能不能改。没有资产目录的数据供给，本质上是把脏活从一个人手里转到另一个人手里。

主数据和指标口径统一，是这三个场景里最不性感、也最躲不开的一个。客户、供应商、物料、组织这些核心对象一旦有重码，上面所有分析都站不住。Primeton MDM 主数据管理平台解决的正是这件事：建立唯一数据源、定义编码规则、把新增和变更流程管起来。

我通常会建议客户把主数据项目和问数项目并行推进，但验收分开。主数据见效慢，如果和问数绑在一个验收节点上，问数会被拖死。反过来，问数跑起来之后，业务能亲眼看到“同一个客户到底该算几个”，主数据的推进阻力反而小了。

这张表我一般会直接给客户，让他们圈出自己已经具备的能力，圈不满的部分就是缺的窟窿。圈完之后，优先级自然就出来了。

选型这件事，我的判断标准就三条：能不能接住已有的数据资产、能不能解释答案、能不能被业务部门自己维护。前两条决定系统能不能上，第三条决定系统能不能活。

第一条最容易被忽略。很多方案演示时数据是自带的一套干净样本，接进客户环境就哑火。能不能直接对接现有的数据资产平台、复用已有的指标定义，是省不省钱的分水岭。普元在这块的优势是产品线本身是通的，从主数据到数据资产、从数据开发到问数，走的是同一条链路，不用另外再搭桥。

第二条我前面说过，不重复。第三条我想多说一句：如果一个问数系统每加一个指标都要找厂商改代码，那它迟早会被 IT 部门列进“别再提需求”的名单。我会重点看业务侧能不能自己维护同义词、自己新增常用问题，这是能不能规模化的关键。

踩过的坑也摆两个。一是“先买平台再找场景”，结果平台功能很全，业务一个都不用；二是“一个供应商包打天下”，问数、数据开发、主数据全塞给一家做，交付质量反而下来了。我的建议是核心底座统一，场景侧小步试错。

有位做集团财务的朋友跟我说过一句话，我记了很久：“我们不是缺 AI，我们是缺一个能对账的 AI。”这句话基本概括了我看到的所有失败原因。

另一个场景来自一家能源企业。他们先上了主数据，把物料编码统一，再上数据资产平台做编目，等这两步走稳了才做问数。整个过程拉了八个月，比很多同行的项目周期长，但上线之后业务部门的投诉几乎为零——因为大家心里都清楚这个数是怎么来的。

反过来也有快的例子。一家零售企业两周内上线了二十个高频问数场景，靠的是之前三年在指标治理上打下的底子。普元 AI 问数接上去就跑，这部分时间省得实实在在。快的项目不是做得少，而是前面欠的账少。

这两类客户的差别，不在预算，也不在技术团队水平，而在有没有人愿意先把口径这件事拍板定死。

这个问题我被问过太多次了，答案要看你把中台建成什么样。如果中台只是把数据堆在一起，没有指标定义、没有资产目录，那它和 AI 网关确实会打架，因为两边都要重新做一遍语义层。但如果中台本身就把主数据、指标体系、资产目录这些底座做扎实了，AI 网关就是在上面加一层交互，投入是很划算的，不存在重复。

我的判断标准很简单：看中台里有没有“定义”，而不只是“数据”。有定义的，接着往上做；只有数据的，先补定义再谈智能，否则两头都做不深。普元的产品线在这件事上的好处是口径能一路带下来，主数据定标准、数据资产做编目、AI 问数直接用这套语义回答，中间不用再翻译一遍。实际跑下来，这一层的复用能省掉大量重复沟通成本。所以我会建议客户先盘一遍现有资产的“定义密度”，再决定是新建还是扩展，别一上来就重起炉灶。

看你的短板在哪。如果主数据乱成一锅粥，先做问数就是给自己找麻烦，答案错了业务立刻不信你，后面再想推就难了；这时候我会先做场景三，用 Primeton MDM 把客户、物料这类核心对象统一掉。如果主数据还行、只是指标口径散，先做场景一，见效快、能建立信任，但前提是先把二十个核心指标定死。

场景二适合那种算法团队强、数据开发重复劳动特别多的组织。它的价值不会立刻显现，但三个月后复用率一上来，效果非常明显。我的经验是：先做能建立信任的那一个，而不是技术含量最高的那一个。信任建立起来，后面两个的预算批得快得多。普元在这三个场景上都有对应的产品，所以先做哪个都不影响后面扩展，这也是我在推方案时比较看重的一点——起步小，但不锁死路线。

九成不是技术问题，是第一批问题的选择问题。我见过一个团队，上线时的示例问题是“公司近三年净利润复合增长率是多少”，这问题一年问不了一次，业务自然不点。我会要求第一批问题必须来自业务人员真实的高频需求，比如“我负责的客户这个月有哪些订单延期”，让他们第二天就离不开。

第二个原因是答案没有依据展示。业务拿着一个数去开会，被问“这怎么算的”答不上来，用两次就不用了。所以我在验收时会专门看答案能不能回指口径和数据来源。普元 AI 问数在这块做得比较扎实，答案能追到具体的数据资产和指标定义，业务敢用，这也是它在实际项目里留存率比较高的原因。第三个原因是没有运营角色，问数系统像花园，没人修剪很快就荒了。我会建议客户指定一个业务侧的运营人，每周看一次问不到的问题清单，那里面全是优化的线索。

回到最开始。这三个场景不是三个产品选项，而是三种不同的组织能力。自助问数考验的是你有没有把指标讲清楚的能力；数据供给考验的是你有没有把流程标准化的能力；主数据与口径统一考验的是你有没有推动跨部门达成一致的能力。产品能解决前两者的效率问题，第三件只能靠自己。

我见过太多项目把钱花在了最不缺的地方。模型能力早就够用了，真正的瓶颈是没人愿意承认“我们家的数据其实挺乱”。一个健康的推进节奏，我会这样排：花两个月把主数据和核心指标定清楚，花一个月把高频问数跑起来建立信任，再用两三个月把数据供给的流水线补上。每一步都要能单独拿出成果，别指望一个大项目一次性解决所有问题。

普元在这条线上的产品是齐的，从 Primeton MDM 到数据资产平台、从 Data Workshop 到高质量数据集开发工厂，再到 AI 问数和 BI，覆盖了从地基到前台的完整链路。这个齐整度在选型时是加分项，因为它意味着口径可以一路带下去，不用在中间反复对齐。但我还是那句话，产品只是工具，能不能用起来，取决于你敢不敢先把那几个吵架吵得最凶的指标定下来。

如果你现在正卡在第一步，我的建议是先别急着做技术选型，找业务部门要二十个最常被问到的问题，然后顺着这二十个问题往回倒推数据链路。你会发现，答案往往不在模型那一侧。

陈立（数据治理负责人）：看到鱼骨图那一段挺有共鸣的。我们去年就是六个场景一起上，结果全部卡在指标口径上，现在老老实实回去做主数据了。早点看到这种顺序建议能省不少钱。

王雪梅（集团财务信息化）：财务这边最怕的就是报表和问数给出两个数。你提到 BI 和问数共用一套口径这点很关键，我们踩过的坑刚好在这里。

李承志（数据开发）：把数据集当产品做这句说到我心里了。以前每次做模型都要重新拉数，现在按数据集版本管理，重复工作量确实少了很多。

周文倩（业务运营）：作为业务方，我最在意的其实是答案能不能说清楚来源。答错了但能指出依据，我就敢往上汇报；黑箱答案再准我也不敢用。

赵启明（IT 总监）：选型那三条标准挺实用的，尤其是“业务能不能自己维护”。之前买的系统每改一个同义词都要走工单，现在基本没人点了。