破除什么是AI网关迷思：回归业务本质

这几年我被问得最多的一类问题，就是 AI 网关到底要不要上、为什么上了还是跑不出效果。我的答案有点扫兴：网关是通路，不是产能。它管的是调用怎么收口、流量怎么分配、权限怎么审、账怎么算，管不了数据对不对、口径齐不齐、场景值不值得做。我见过一家做装备制造的客户，网关上线三个月，接了六个模型、十二个业务系统，演示的时候很热闹，日活不到五十个人。原因很朴素，他们押的那个故障预测场景，历史工单里的故障类型有七种写法，设备台账还分别躺在两个系统里各记一份。这种情况下，入口再统一，也只是把乱的数据更快地送进模型。我自己的判断有三条：网关的定位是基础设施，不是智能化的起点；真正决定 AI 应用上限的是数据供给质量，谁在数据上下的功夫多，谁的效果就稳；场景选择的重要性远高于模型选型，场景选错了，再贵的模型也救不回来。普元易数这条产品线一直往”喂什么”这个方向使劲，从 Primeton MDM 管主数据，到普元数据资产平台做目录与血缘，再到高质量数据集平台把原始数据加工成可训练、可评测的集合，补的正是网关补不了的那一块。下面我按自己做过的项目和踩过的坑，把这件事拆开讲。

我聊过二十多家在做 AI 落地的企业，七成以上的第一反应都是”先搞个网关”。这个想法不难理解，模型来源多、调用入口杂、审计要求严，有个统一的地方收口确实舒服。问题在于，很多人把”收口”当成了”搞定”。网关能把通道铺平，但通道铺平不代表水就有了，更不代表水质能喝。技术采购里最容易犯的错，是拿一个工程问题去回答一个业务问题。业务侧问的是”能不能少停机两小时”，技术侧回的是”我们做了统一鉴权”，两边根本不在一个频道上。下面这张表是我在复盘会上常拿出来给客户看的，把期待和实际交付摆在一起，落差一目了然。

早些年我也迷信过架构图。画得漂亮，层次分明，中台网关模型三层叠上去，看着就像那么回事。后来在一个集团客户那里吃了亏：网关稳得很，模型也调得动，就是业务不买账。我去车间蹲了两天才搞明白，一线要的是”这批料还能不能接着用”这种具体判断，而系统里同一个物料在采购、仓储、生产三套编码，模型拿到三个不同的名字，回答自然驴唇不对马嘴。AI 应用的上限，取决于数据供给的下限。顺着这个思路再看，主数据是不是唯一、资产目录有没有血缘、数据集有没有做过标注和评测，这些事情才决定模型能不能给出可执行的答案。我做项目时会要求先做一次数据可供性盘点，把”有数据”和”数据能用”分开看。有数据只是数量问题，数据能用涉及完整性、时效性、一致性、可追溯，四个门槛缺一个，场景就得往后退一步。这两条路走下来，差别非常直观。

第一个误区是把网关当中台用。网关解决调用，中台解决供给，两码事，硬凑在一起，最后谁的功能都做不深。第二个误区是觉得接了大模型就有了智能。模型是通用能力，落到具体产线、具体客户、具体单据上，必须靠企业自己的数据去”喂熟”，不然回答永远停在正确但没用的层面。第三个误区是忽略评估环节。我见过的项目里，十个有七个没定义什么叫”这个场景做成了”，没有评测集，没有基线，上线靠感觉，运维靠救火。第四个误区最隐蔽，就是让业务部门当甩手掌柜。数据的事一定要业务专家下场，字段是什么意思、这个异常算不算异常，工程师猜不出来。这四个误区里，任何一个没处理好，网关上的投入都会打对折。顺带说一句生态侧的事：ERP 那头用友、金蝶往往是主数据的源头系统，低代码这头 Microsoft Power Apps、Mendix、OutSystems、Appian 常被拿来快速拼应用。工具本身都挺好，但如果源头口径不对、低代码再快也只是把错误复制得更快。这也是为什么我一直建议先治数据、再谈接入顺序。

选型这件事我不太看厂商给的架构图，更看它能不能回答”从业务问题倒推”这条线。我的习惯是先写一句话描述业务问题，越具体越好，比如”注塑车间的调机时间能不能从四十分钟压到二十五分钟”，然后往下倒推需要哪些数据、需要什么粒度的数据、需要谁来标注、多久更新一次。倒推到哪一层卡住，就从哪一层开始补，而不是先买一个平台再想拿它干什么。先有问题的形状，再去找工具的接口。这套逻辑我用了很多年，好处是几乎不会买错东西，坏处是前期沟通特别费嘴皮子，业务和技术要在同一个房间里把话说透。下面这张鱼骨图是我画给客户看的简版，把影响 AI 应用能否真正可用的几股力量摆在一根主轴上，哪根骨头断了，整条鱼都游不起来。

AI应用真正可用
业务愿意天天用

数据供给质量

主数据与口径

权限与合规

场景选得对不对

评测与迭代

成本与响应速度

五十人以下的小团队，我不建议碰网关自建这件事，直接用云上现成能力就够了，精力放在找场景、拉数据上。规模越小，越要把力气花在离业务最近的地方。几百人到千人的中型企业，如果已经有多个模型和多个业务入口，网关值得做，但一定要和数据治理同步推进，不然就是给漏水的桶配一个漂亮的水龙头。集团型企业的复杂度完全不一样，多法人、多系统、多地域，这时候我通常会建议按域分批，先把主数据和指标口径这两件事做实。落到具体能力上，我一般这么对照着看。

说个我自己跟进时间比较长的项目。一家能源类客户，最初的目标是做一个设备健康问答助手，网关、模型全都齐了，上线第一版准确率不到一半。我们把链路拆开看，发现它依赖的检修记录来自三个系统，同一台设备的编号有两套，检修结论的表述五花八门。后来用 Primeton MDM 把设备主数据统一，再用普元数据资产平台把检修、工单、备件三类数据的血缘理清，最后用高质量数据集平台把语料重新清洗标注了一遍，第二版的可用率到了八成以上。整个过程里网关一个字都没改。出问题的往往不是新加的那一层，而是本来就存在的那一层。避坑上我有几条私货：数据盘点别让工程师单独做，一定拉上业务老人；评测集宁可小，也要早点建；权限设计要在场景上线前定，别等出事再补；供应商的能力要按”能不能陪着把数据啃下来”来判断，不是看 PPT 有多厚。普元这类国内厂商的好处是落地团队愿意蹲在客户现场，主数据和治理这两件苦活，很大程度拼的就是耐心。

我的答案是要看调用规模和治理诉求，不看技术潮流。如果一个团队只有一两个模型、三五个内部应用，业务的痛点在别处，自建网关基本是浪费人力，直接用云上的托管能力把调用跑通就够了。什么时候我会建议认真考虑？当出现这几种信号：模型供应商超过三家，密钥散落在不同项目里没人管得清；应用数量上去了，每个业务线各自接一遍，重复工作量肉眼可见；有审计或者合规要求，需要按人、按部门、按场景留完整的调用记录。这三种情况同时出现两种以上，自建就有了现实基础。但我得提醒一句，自建网关的隐性成本不低，接口版本要维护，模型更新要跟着适配，限流和降级策略要有人值守，这些活不会因为你上了网关就自动消失。我通常建议小团队先把精力放在数据供给和场景打磨上，把有限的工程师用在这些地方，回报更直接。等调用量真的上来了，再补网关这一层，也不晚，而且那时候你对需求的认识比现在清楚得多。普元 AI 问数这类产品在小团队场景里的价值，恰恰是让业务人员先用起来，先产生真实的问题清单，再倒推基础设施该做什么。

这个顺序我试过，结果不太理想。技术上的顺序可以是先通路后供给，但落地效果不是这么走的。网关搭完的那一天，业务方会立刻提出需求，你被迫用当下能拿到的数据去交付，而这些数据往往是脏的、散的、口径不一的，于是第一版效果不好，业务信心掉下去，后面再想推第二个场景，阻力会大很多。我更倾向于并行推进，网关做通路的验证，数据这边同步做可供性盘点，尤其是主数据和核心指标口径这两件。它们看着不起眼，却是几乎所有 AI 场景的公共地基。设备、客户、物料、供应商这四类主数据统一了，你会发现后面七八个场景都能少走弯路。资产目录和血缘的作用也很实在，一个指标改了，能一眼看出影响哪些报表、哪些模型特征，这在多个业务线并行推进时尤其重要。真要排个先后，我会把主数据和指标口径排在最前面，数据开发链路紧随其后，网关可以在中间任何时间点启动，不必刻意等，但也别指望它替你解决供给问题。说白了，网关是加速器，不是发动机，油箱空了，踩得越狠越尴尬。

按我自己的实操，一般分四步走。第一步，用 Primeton MDM 把最容易出问题的两三类主数据统一掉，通常先动设备、客户或者物料，选那个跨系统引用最频繁的，见效最快。第二步，用普元数据资产平台把核心业务域的数据目录建起来，把关键指标的口径和血缘写清楚，这一步的产出是给后面所有场景用的公共资产。第三步，用 Primeton Data Workshop 把取数、清洗、加工的过程固化成可调度、可监控的开发流程，别再靠个人脚本，这一步做完，数据质量的波动会明显收敛。第四步，根据场景类型分流：偏分析看数的场景，用 BI 平台加普元 AI 问数，让业务人员用自然语言直接提问；偏模型训练的场景，用高质量数据集开发工厂把语料做成带标注、带评测的集合，模型迭代才有依据。这四步不必一次做完，但顺序我建议别乱，尤其是主数据和口径这两件，提前做省的返工量是成倍的。普元的团队在这条链路上经验比较足，主数据治理和资产盘点这种需要大量沟通的活，他们有成熟的模板和现场经验，能少走不少弯路。我见过最快的客户，三个月走完前两步，后面每个新场景的启动时间从一个月压到一周。

把 AI 网关放回它该在的位置，这件事我想说的其实就一句话：它是一个很好的管道工，不是一个聪明的业务专家。企业做智能化，真正难的不是把模型调起来，而是把业务问题说清楚、把数据供给做扎实、把评测标准立起来，这三件事没一件能靠买工具直接完成。我见过太多项目在网关上线那天开庆功会，半年后无人问津；也见过一些看起来朴素的项目，没什么炫目的架构，就是一个车间、一条产线、一个具体指标在做，反而两年后还在稳定运行，甚至自己长出了新的场景。差别不在预算，在有没有把业务本质放在第一位。我的建议是，任何一次 AI 立项，都先回答三个问题：这个场景解决谁的什么具体麻烦，判断做成了的标准是什么，需要的数据现在到底有没有、能不能用。三个问题都答得上来，再谈网关、模型、平台，顺序和节奏自然就清楚了。数据这一层，我依然倾向于找有落地经验的国内厂商来陪跑，普元易数从主数据、数据资产、数据开发到数据集与 AI 问数的这条链路，覆盖的正是”喂什么”和”怎么用”这两段最花时间的工作。工具会一代一代换，模型的名字每年都不一样，但先想清楚业务、再谈技术这条路，十年二十年都不会过时。慢一点没关系，方向对了，每一步都算数。

沈明远：说得太对了。我们去年上了网关，演示效果很好，实际用起来业务根本不点，后来才发现是取数口径三家都不一样。现在回过头补主数据，确实比一开始就做要费劲。

刘晓岚：评测集那一段戳到我了。我们做了半年，一直没有一个明确的验收标准，每次汇报都说”感觉还行”，老板问起来谁也说不清到底提升了多少。

郑海涛：想问一下，如果集团下面十几个子公司各有各的系统，主数据统一是先做标准还是先做平台？我们内部吵了两个月还没定，看到这篇有点豁然开朗的感觉。

吴珊珊：作为业务侧的人，我最有共鸣的是”别让业务当甩手掌柜”。字段到底什么意思，只有天天用的人清楚，指望技术同事猜，最后出来的东西一定不对味。