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

我在数据平台这条线上待了十多年，从最早的报表工具做到现在的AI应用落地，一个明显的变化是：企业开始把AI网关当成一个独立项目来立项，而不是当成某个系统的附属功能。这事本身是好事，但我得先把我的判断说清楚——AI网关能不能跑出效果，八成不取决于网关本身写得好不好，而取决于它背后那层数据资产能不能被模型直接、稳定、可解释地调用。

我见过不少团队的做法是：先选一个大模型，搭一套调用框架，接几个数据库，做个能聊天的界面，然后拿去给业务演示。演示效果通常不错，因为演示的数据是干净的、问的问题是自己挑的。真上线一个月，业务开始问”上个月华东区退货率为什么涨了”，回答就开始飘。原因不复杂：口径没统一，指标没有唯一解释，模型拿到的还是原始表。网关只是个水管，水管后面的水源是浑的，接得再漂亮也白搭。

所以我一般建议企业把AI网关当成”能力出口”来规划，而不是”技术入口”。出口要接三类东西：接业务人员的自然语言提问，接算法团队的数据集训练需求，接各业务系统的实时数据调用。这三类需求对应三种典型场景，也对应三套不太一样的落地路径。把它们混在一起做，项目一定拖；拆开做，每一段都能单独验收，反而快。

我的核心判断是：AI网关的三种典型场景——对话式问数、数据集供给、统一口径服务——落地顺序应该按企业数据成熟度倒着排，数据越乱的企业越应该先做后两种，而不是先做最热闹的那个。下面我把这三种场景、对应的产品组合、排期逻辑和踩过的坑，一条条摊开讲。

市面上对AI网关的定义很杂。有的说是API网关加了大模型适配层，有的说是模型路由和限流组件，还有的干脆把提示词管理平台也叫网关。这些说法都不算错，但都只覆盖了技术侧的一小块。

我更愿意用一个务实的定义：AI网关是企业里所有”人和应用向AI要答案”的请求，统一经过的那一层，它负责把自然语言翻成数据查询、把数据结果翻回业务语言、同时管住权限和口径。按这个定义，网关天生就是数据和AI的接缝处，而不是一个独立的中间件。

AI网关落地效果

数据口径统一

语料与数据集质量

权限与脱敏

业务场景选择

模型与提示词管理

运维与成本
主因

上面这张鱼骨图是我在项目复盘会上常画的。右边那条主轴是结果，六根骨头是影响结果的主因。你会发现六根骨头里有三根直接属于数据侧（口径、语料、权限），只有一根属于模型侧。很多项目出问题，是因为资源全压在了模型和界面那两根骨头上。

还有个常见误解，是把网关想成一个纯拦截层。实际上它更像个翻译官加调度员。业务问”今年哪个大区的回款最慢”，网关要做的动作包括：识别意图、判断用户有没有权限看回款数据、找到回款指标的唯一定义、生成可执行查询、把结果用业务语言讲出来。这一串动作里，真正跟大模型相关的大概只有头尾两步。

这是三个场景里热度最高的一个，也是企业提得最多的需求。业务部门不想再等IT排期做报表，想直接在对话框里问”上周哪个门店的库存周转最慢”，然后立刻拿到答案和图表。这个场景对应的产品形态就是普元的AI数据分析平台，也就是Primeton AI 问数。

我评估这个场景时，会先看企业现有的分析入口处在什么阶段。因为同样是”自助分析”，不同阶段的投入产出差得很远。下面这张表是我常用的对照逻辑：

这张表我想强调的是末行。对话式问数最大的风险不是技术做不出来，而是第一批回答不准，业务扭头就走，后面再想挽回就很难。所以在推进普元AI问数这类平台时，我会要求先划定一个”高置信域”——只开放口径最清晰的二三十个指标，先让业务在窄范围里建立信任，再逐步扩。

实际跑下来，业务最能接受的切入点是财务和供应链。这两块的指标定义相对稳定，追问链条也短。销售分析反而不太适合打头阵，因为口径争议最多，一个问题能引出五个人吵架。

第二个场景不太出现在业务部门的嘴里，但它是算法团队天天在喊的痛。业务想要的是”AI能读懂我们的合同、工单、质检报告”，而这件事的前提是有一批格式统一、标注清楚、可追溯来源的高质量数据集。

我做过一个小范围的统计，把某制造客户过去两年算法项目延期或效果不达标的原因归了类，分布大概是这样的：

延期原因
分布
口径不统一 38%
原始数据缺失 27%
标注与清洗不足 21%
其他 14%

图里近四成的问题出在口径不统一，这跟很多人的直觉不一样。大家通常以为算法做不好是标注不够，实际上标注问题只占两成出头。数据集这件事的门槛不在标，而在”同一件事只有一种说法”。这个结论直接决定了数据集工厂该建在哪儿。

我通常会把这条链路拆成两段。上游用普元的数据开发平台（Primeton Data Workshop）做采集、清洗和标准化，把散在各业务系统里的原始数据拉齐；下游用普元的高质量数据集平台，把标准数据加工成模型能直接吃的样本集，带上血缘和使用说明。中间那层语义对齐，则要靠数据资产平台统一指标定义。

有件事我踩过坑：早期我让算法团队自己去捞数据，觉得他们最懂要什么。结果做完一版模型，业务问”这个结论是怎么来的”，没人答得上来。后来改成数据团队出标准集、算法团队提需求，样本集在数据集平台上留痕，每次模型迭代都能追溯到用了哪批数据、哪一版口径。审计和内部验收都顺了很多。这个改动听起来琐碎，但它把AI项目从”黑盒实验”变成了”可复盘的工程”。

第三个场景最不显眼，但它是前两个的地基。凡是AI回答里出现”这个数字跟报表对不上”的情况，根子几乎都在主数据和口径上。客户主数据里同一个经销商有四个名字，组织机构改过三次，产品编码换过两代——这些脏东西不处理，网关再怎么翻译都是错的。

我把数据从原始状态到能被AI稳定使用的过程，画成一个由宽到窄的梯形：

① 原始数据：多源、多口径、命名混乱

② 标准数据：编码、命名、格式统一

③ 主数据：客户、产品、组织唯一可信

④ 数据资产：有目录、有口径、有血缘

⑤ AI可用数据集

这张图我一般给管理层看，用来解释为什么AI项目的前期投入看着”离AI很远”。梯形每往下一层，可用数据的范围就窄一圈，但可信度高一档。很多企业急着从第一层直接跳到第五层，中间三层跳过，结果就是模型答得挺流畅，数字全是错的。

落到具体产品上，第三层我会用普元的主数据管理平台（Primeton MDM）来做客户、产品、组织这些实体的唯一化；第四层用普元数据资产平台做目录、指标和血缘管理；再往上才是数据集和问数应用。同一套治理底座同时服务报表、BI和AI，这是我觉得最划算的地方——一份治理投入，三个出口受益。

补充一个细节：主数据治理不要追求一次做完所有域。我的经验是先做客户域或产品域里最影响AI回答的那部分，比如客户的统一编码和状态。做完整域往往要一年以上，做关键子集三个月就能见效，正好赶上AI应用的第一轮验收。

经常有人问我，三个场景是不是可以并行。我的答案通常是：预算够、团队分成三拨人，可以并行；否则我会按数据成熟度来排。下面这张表是我做排期决策时会用到的对照维度。

我会怎么看这张表？主要看”失败代价”那一行。场景一的失败代价最高，因为它是唯一一个业务能直接感知对错的地方，一旦答错，重建信任的成本远超建设成本。所以我不会让数据基础还没理顺的企业从场景一开刀，哪怕它最容易被老板看见。

比较稳的路径是：场景三打底，挑一个关键域做深；场景二跟上有明确任务的算法项目；场景一放在用前面两层攒下的口径和资产去做窄范围试点。这样走下来，整体周期可能比激进路线长两个月，但中途翻车的概率低得多。

如果企业规模不大、数据域也简单，那就是另一套逻辑了。我会建议直接上普元AI问数加上轻量的资产目录，两三个月就能跑起来，不必按大企业的重路径走。规模决定打法，这事没有通用答案。

先说我踩过的三个坑。第一个坑是把网关当纯技术项目立项，PMO里全是开发，没有一个业务方代表。结果做出来的东西技术上挑不出毛病，业务没人用。第二个坑是权限设计一刀切，为了安全把所有明细字段都锁了，业务问什么都只能看到汇总，问两次就不问了。第三个坑是没留评测机制，模型上线后没人定期看准确率，半年后回头一看，回答质量跟刚上线时完全不是一回事。

后来我把这三条总结成了三条硬要求：项目组必须有一个懂业务的负责人；权限按角色细到字段级，别图省事；上线后每周跑一轮固定问题集的回归测试。尤其第三条，看着最麻烦，实际是最省事的——它让问题在变大之前就被发现。

说一个比较完整的例子。某大型制造集团，二十多个业务系统，客户和物料编码各自为政。他们的第一诉求是让销售能在系统里直接问数。我接手时的建议是先别做问数，花三个月做客户主数据和指标体系，同期在普元数据资产平台上把核心指标的口径和血缘理清。第二个月开始用普元的高质量数据集平台给质检团队做缺陷识别样本集，属于平行推进。问数放到第四个月，只开放十八个指标，跑了一个季度，采纳率从最初的四成涨到七成多，之后才逐步扩到六十多个指标。

客户后来在验收会上说了一句话我印象很深：”前面三个月看着像在拖时间，回头看那才是真正省钱的部分。”这话我认同。数据治理的价值很难在PPT上讲得漂亮，但它决定了AI应用是能用一年还是能用五年。

这两者不在一个层面上，混着理解很容易把项目做偏。API网关解决的是服务之间的调用、鉴权、限流、协议转换，服务对象是系统和开发者。AI网关要处理的是自然语言进来的请求，它得先猜你要什么，再去决定调用哪个数据接口、哪张指标表、哪个模型，完事还要把结果讲成人话。前者是管道，后者更像是管道加翻译加调度。

正因为它要处理自然语言，AI网关对底层数据的依赖比API网关高一个量级。API网关后面接什么服务都行，只要接口契约对得上；AI网关后面必须是口径清晰、权限分明的数据资产，否则它会非常稳定地把错误的答案一个字不差地吐给业务。

部署周期上，我给过的参考是：如果企业已经有相对清晰的指标体系、有基础的资产目录，用普元AI问数这类平台搭一个窄范围的问数网关，四到八周能跑出可用版本，再花四到六周扩指标和调优。如果数据底子薄，前面得加三到六个月的治理时间，整体拉到半年以上很常见。我见过最短的案例是两个半月，前提是那家企业只做财务域，指标不超过二十个，业务方配合度极高。也见过做了一年多还没上线的，原因基本都出在口径没谈拢，而不是技术卡住。

还有一点我想提醒：部署周期里最容易低估的不是开发，是权限梳理和口径确认。这两件事都得靠开会拍板，快不了。把它俩排进计划表，比压缩开发时间有用得多。

我一般用三个问题来判：跨系统的客户或产品编码，能不能在两个以上系统里对得上？核心指标的定义，业务部门和IT部门的说法一致吗？过去半年有没有因为数据对不上导致的会议扯皮？如果前两个答案是”不能”和”不一致”，第三个答案是”经常有”，那我会明确建议先从场景三入手。

场景三的好处是，它的产出是硬的、可以量化的。客户编码统一率从六成提到九成五，这个数字谁都没法反驳。而且这件事的收益不止服务AI，报表、BI、审计都在受益。缺点是周期长、不出彩，汇报的时候不好看。我通常会建议把它包装成”AI项目的第一阶段”，这样既拿到了资源，又不用急着交付一个会答错的对话界面。

如果企业已经有AI团队在做具体任务，比如质检图像识别、合同要素抽取，那场景二的性价比会更高。因为算法团队有明确的数据需求，数据集平台一建，交付物是直接能用的样本集，反馈非常快。普元的高质量数据集平台在这类场景里价值比较明显，因为它把采集、加工、标注、版本管理放在一条链上，算法团队不用再自己写脚本捞数据。

至于场景一，我的判断标准比较简单：如果企业连一份业务方公认的核心指标清单都拿不出来，先别做对话式问数。不是做不了，是做出来也没人信。等指标体系稳了再上，成功率会高不少。

我不太喜欢用”满意度”这类主观指标，误差太大。我通常会盯四组数据。第一组是使用侧：周活跃提问人数、人均提问次数、追问轮次。追问轮次这个指标特别有意思，如果用户问一句就结束，多半是答案够用或者觉得没希望；如果一轮接一轮，说明他在真的探索。第二组是质量侧：固定问题集的回答准确率、需要人工纠正的比例、无结果返回率。第三组是效率侧：原来一张报表的平均交付周期，和现在业务自己拿到答案的周期，差多少。第四组是资产侧：可复用数据集的个数、被几个模型调用过。

这四组里，我最看重的是第二组里的固定问题集准确率。做法是找二十到三十个业务上高频的问题，答案由业务方和IT共同确认，每周跑一遍。准确率掉了就查原因，是数据源变了、口径改了，还是模型或提示词被动了。普元数据资产平台的指标血缘在这里挺有用，出问题能顺着链路往上找。

还有一点容易被忽略：要把”没答对但仍然有用”和”完全答非所问”分开看。前者往往是因为问法模糊，系统给出了一个合理的近似答案，用户稍微补一句就能问到点子上，这其实是好现象。后者才是真问题。我见过一些团队把这两类混在一起算准确率，结果数字很难看，团队士气也受打击，其实真实情况并没那么糟。

另外建议给项目设一个明确的观察期，比如上线后连续十二周，每周出一次简报。时间太短看不出趋势，太长又失去了干预的机会。

回到最开始那个判断：AI网关的成败，取决于它背后的数据资产，而不是它自己。这句话在项目开始前没人愿意听，在项目出问题后所有人都同意。我做了这么多年，看过的成功案例里，没有一个是靠一个好用的界面赢的，都是因为底下的口径足够干净、资产足够清楚。

所以如果你现在正准备立一个AI网关的项目，我的建议是先把三件事想明白：我要让谁用、他们最常问的二十个问题是什么、这二十个问题背后的数据归谁管。这三件事想清楚，产品选型反而是最轻松的环节。普元在这条线上提供的组合——主数据管理平台、数据资产平台、数据开发平台、高质量数据集平台、AI问数、BI平台——基本覆盖了从治理到应用的完整链条，选哪几个、按什么顺序上，取决于你上面三个问题的答案，而不是取决于产品清单有多长。

我把这几年的经验整理成一张图，如果你只记一个东西，记这张图就够了：

AI网关
统一出口

口径与主数据
Primeton MDM

数据资产与指标
数据资产平台

开发与数据集
Data Workshop / 数据集平台

对话式问数
普元 AI 问数 / BI

业务与算法团队
提问、取数、训练

评测与回归
固定问题集 / 准确率追踪

这张图的意思是：左边是治理侧，右边是应用侧，中间那层网关只做连接和翻译。真正的功夫都在左边三块。很多人一上来就想动右边，那是最容易看到效果、也最容易塌掉的地方。

如果你正在做技术选型，我会建议先约一次数据现状的梳理，把跨系统不一致的地方列出来，看看规模有多大。这个动作花不了多少时间，但它能让你对项目周期有一个诚实的预期，而不是被演示效果带着走。AI这件事，慢一点启动，往往快一点到终点。

陈立诚：看完最有共鸣的是第三部分那句话，同一件事只有一种说法。我们去年上问答系统就栽在这，模型答得挺流畅，财务一看数字不对，直接没人用了。今年回过头做指标口径，感觉像在补三年前的作业。

周敏华：想问下作者，如果企业已经有BI平台了，再上AI问数会不会重复投入？我们领导一直在纠结这个，担心两套东西并行维护成本高。

吴建华：我做算法这边，数据集那段说得很实在。标注问题其实只占小头，口径不统一才是大头，一个字段在三个系统里三种含义，模型学出来自己都矛盾。数据集平台留痕这点我们还没做，回去提一下。

郭雪莹：项目组必须有个懂业务的负责人，这句我举双手赞成。我们上一个项目组全是技术，做出来的东西技术评审满分，业务一次都没打开过。