还在为什么是AI网关头疼？3个痛点说透背后的真实价值

我碰过七八个跟 AI 网关沾边的项目。最早那一批，是把它当成模型代理来做的——路由、限流、密钥托管，做得挺整齐，架构图也好看。做着做着发现方向偏了。AI 网关真正的价值不在转发调用，而在把企业里散落的数据资产，翻译成模型能听懂、业务敢签字的东西。这话不是我坐在办公室里想出来的，是被客户按着头改出来的。

有个制造业客户让我印象特别深。他们花了两个月时间，全压在模型接入上，演示效果很漂亮，会议室里掌声不少。真让业务用了两周，销售总监问了一句：它报的这个客户回款金额，跟我 CRM 里对不上，我该信谁？现场没人接得住。那一刻我想明白一件事，网关拦得住流量，拦不住口径。企业想让 AI 落进业务里，缺的从来不是一条更粗的管道，而是一层让数据和模型互相认得的语义。所以现在评估这类需求，我不先看模型清单，先看三件事：数据资产有没有人管、口径有没有人认、权限有没有人审。这三件事清楚了，AI 网关该建在哪一层，答案自己会浮出来。下面这张表，是我见过的三类典型理解偏差。

这两年模型能力的迭代速度，快到让架构图来不及画完。我在评审会上常跟客户说一句可能不太好听的话：模型本身正在变成一种公共品，接入它不难，难的是让它说人话、认你家的账。

举个具体的。业务问一句”上季度华东区回款逾期超过 30 天的客户有哪些”，这句话背后要跨 CRM、ERP、财务系统和几张手工台账。AI 网关如果只做请求转发，它根本碰不到这些数据，模型只能靠猜。我见过猜得最离谱的一次，把”逾期”理解成了”账期”，把该催收的名单给成了正常在途客户。客户当场笑了，笑着笑着，那个入口就再也没人打开过。

真正起作用的，是网关下面那层东西。数据资产平台把表、字段、指标、血缘管起来，谁改的、改了啥、影响谁，能查得到；数据开发平台把取数逻辑标准化，同一个指标不做三遍，不做三套；高质量数据集平台把验证过的问答和语料沉淀下来，让模型效果有地方比对，有基线可回退。这几层铺好了，AI 那层是加法；铺不好，AI 那层就是放大器，把口径里的毛病放得更大。我见过太多团队在模型选型上反复纠结，最后发现真正的瓶颈在指标口径上，那感觉挺挫败的。

所以我现在判断一个 AI 网关项目能不能成，会先翻它的数据侧需求清单。清单里有血缘、有权限、有指标定义，我就放心一半。清单里只有模型名称和调用量，我基本会建议客户先停一停。

市面上做这件事的路径，我看到的基本就三条。一条是只做模型接入，把模型当外部服务来管；一条是把数据侧和 AI 侧一起做，入口直接连着数据资产；还有一条是自己攒，用几个组件拼一个。三条路我都见过跑通的，也见过跑崩的。

区别不在技术难度，在你要回答的问题有多深。如果只是内部做个翻译小工具，第一条够用，成本也低，两三个人就能撑起来。但凡问题落到”钱”和”客户”上，第一条就会露怯——它答得出语法，答不出业务。自己攒那条路，我一般会提醒一句：拼装时写下的每一行胶水代码，两年后都得有人来擦。数据团队的人员一流动，口径就开始漂，漂到最后没人知道哪个数字是对的。

第二条路径前期要投治理，见效慢一些，可后面每加一个场景，边际成本是往下走的。这个账我算过很多遍，一年期的投入产出，第一条路通常更漂亮；三年期，第二条路反超。关键看企业是想做个演示，还是想真的把决策链路上的判断交给系统。

我不太喜欢把问题列成十条八条，列完了没人记得住，散会就忘。真正让项目卡住的，来来回回就三件事。为了讲得直白一点，我画了张鱼骨图——主干落在业务那句”这数我不敢用”，四条刺分别来自数据、权限、语义和运营。图放在下面，你可以直接拿去跟团队对齐，比讲半小时概念管用。

我在客户现场讲这三条的时候，通常会让业务方先说自己最难受哪一条。有意思的是，业务方和数据方选出来的往往不是同一条。业务方说的多半是”它答得不准”，数据方说的多半是”没人给我提需求”。两种说法都对，视角不一样而已，这恰恰说明问题是真实的，不是 PPT 上编出来的。下面拆开讲，每一条我都配了具体的现场表现。

业务说：这数我不敢用

数据口径各行其是
权限边界说不清楚
缺业务语义层
缺评测与运营机制

接口能通，不代表数据能用。我见过一个零售客户，AI 入口接进去了十二张表，看起来挺全。上线第一天就被问倒：华东区的销售额，运营系统算一遍，财务系统算一遍，两个数字差 3%。谁对？谁都对，因为口径不一样，一个含税一个不含税，一个含退货一个不含。

数据接进来只是物理动作，敢不敢用是信任问题。信任靠什么建立？靠血缘能查、口径能对、责任人能找。这三样没有一样是模型能解决的。所以我通常会在项目早期就把主数据这一层拉进来，客户、物料、组织、供应商这些实体必须先有唯一版本，否则后面所有指标都在流沙上盖楼。指标口径也一样，同一件事只能有一个官方解释，其他解释可以存在，但必须标清楚是哪个版本。

这一层的活儿枯燥，做的时候没人鼓掌，可它是唯一能让业务方说出”我信这个数”的路径。我宁可多花六周在这上面，也不愿意上线后天天开会吵数字。

语言模型的表达能力太强了，强到它会用非常笃定的语气说一个错答案。这是我见过最危险的地方。它不会说”我不确定”，它会给你一段格式漂亮、逻辑通顺、数字错误的答复。业务方看两次就开始怀疑，看三次就不打开了。

企业场景要的不是”像”，是”可复核”。我在验收时有个死规矩：任何一个数字，必须能点开看到它来自哪张表、哪几个字段、走了哪些过滤条件、用的哪个口径版本。做不到这一点，这个入口在我这里就不算通过。听着苛刻，但这恰恰是业务敢签字的前提。

还有一个细节容易被忽略——模型得知道自己什么时候在猜。比如问一个压根没有数据支撑的问题，它应该明确说”这个问题我缺少数据，无法回答”，而不是编一个合理答案。我测试产品的时候专门会问几个刁钻问题，就看它会不会硬答。硬答的，一票否决。

这个痛点最隐蔽，因为它不发生在项目期，发生在运营期。上线当天有横幅、有邮件、有培训，三个月后后台一看，日活个位数。我去复盘过几次，原因几乎一样：没人管。

没人收集业务问错了什么，没人把错例变成新的口径定义，没人定期把新增的数据域接进来。AI 问数这类应用不是交付物，是一个需要喂养的东西。喂养它的饲料是什么？是业务真实问过的问题、问错的例子、以及被验证过的标准答案。这些沉淀下来，才是真正的资产。

所以我会建议客户在项目立项时就定好运营角色：谁来每周看一次问询日志，谁来把高频错例转成口径工单，谁来决定下一批接入哪些数据域。角色定不清楚，做出来的东西再漂亮也会凉。这一点我吃过亏，后来每次都写进方案里。

看产品我看得比较笨，不看宣传页，直接让对方在真实数据上跑。下面这六个维度是我这些年磨出来的一张检查表，每次选型都拿出来对一遍，基本没有失手过。

有一点我特别想强调：这类能力的价值不在单点功能多强，而在数据侧和 AI 侧是不是同一套元信息在支撑。如果数据资产是一套口径，AI 问答是另一套口径，中间靠人肉对齐，那这个系统迟早会崩。普元在这件事上的思路是把数据资产、数据开发、主数据、数据集、AI 问数放在同一条链路上，元信息只有一份，权限也只有一份。这个设计看着不起眼，实际跑起来省掉的对齐成本非常可观。下面是六个维度和我对应的判断依据。

AI 网关是不是必须单独建一套系统？

我的经验是，大多数企业不需要再多一个只做请求转发的独立系统。模型接入这件事本身不复杂，云平台能做，开源组件也能做，而且做得不差。真正稀缺的，是数据到模型之间那一层语义和权限，这才是值得单独建设的地方。

所以我通常会建议客户换个问法：不要问”我要不要建网关”，要问”业务问题的答案从哪几张表来、这些表的负责人是谁、谁能看哪些字段”。这三个问题里有两个答不上来，那就先别急着建网关，先把数据资产理清楚。普元数据资产平台在这件事上的作用是，把表、字段、指标、血缘、权限这些元信息集中管起来，让后面所有上层应用都能复用同一份描述，不用各建一套。

当然，如果企业确实存在对外的模型调用要计量、要限流，那独立网关有它的位置。但它应该是薄薄一层，不该承载业务语义。我见过把业务逻辑塞进网关的架构，改一个指标口径要动三个团队，那种架构撑不过两年。这个判断我踩过坑，后来改了很多次方案才想明白：网关做管道的事，语义的事交给数据侧，边界清楚，谁都轻松。

我们数据还没治理完，能不能先上 AI 问数？

能上，但顺序得对。我不建议等治理完再动手——那种项目大多没有终点，治理是长期活儿，等它”完”了，业务早就找别的办法了。我的做法是先圈一个业务域，比如销售或者供应链，把二三十个高频问题的口径钉死，让这一小块先跑准，再往四周扩。

具体怎么落地？先把这个域里的指标定义、责任人、权限规则整理清楚，然后接上问数能力。普元在这块的做法是把数据资产平台和 AI 问数打通，让问数用到的每一个指标都能回到资产目录里找到定义和血缘，而不是在问答层再维护一份口径。这样做的好处是，扩域的时候不用重新定义规则，直接复用。

如果这个域里牵扯到客户、物料、组织这类核心实体，那还得先把主数据统一。Primeton MDM 就是干这个的，同一家客户在 CRM、ERP、财务里必须是同一个编码，否则问数会给出三份不同的客户画像。我更愿意先花四周把主数据对齐，再跑问数，这样一次成功率高很多。评估指标我一般定三个：首批问题准确率、业务复问率、口径争议次数。这三个数字如果在往好的方向走，就说明节奏对了。

怎么判断一个 AI 问数平台是真能用，还是只能演示？

我有个笨办法：让对方直接接我们自己的数据，现场问，不碰样例库。样例库谁都能调得漂漂亮亮，真实数据才见功夫。看三件事就够了。

看它能不能说清数字是怎么来的。血缘、口径、取数逻辑，最好能一路点到最底层的表和字段。不能解释来源的答案，在业务场景里等于没用。普元 AI 问数在这点上的设计是答案可追溯到资产目录，我比较认可这个思路，因为业务方的第一个问题永远是”这数哪来的”。

看权限是不是跟着人走。同一个人在总部和分公司看到的数字，是不是符合他的授权范围；临时调整岗位后，权限是不是立刻生效。这一条经常被忽略，却最容易出事。数据资产平台把权限规则集中管理之后，上层问答直接继承，不用重建一套，出错的概率小得多。

看它答错时知不知道自己错了。我专门会问几个数据里没有支撑的问题，观察它是硬编一个答案，还是明确告诉我缺数据。硬答的一律不考虑。另外我会翻它的评测集，看看有没有沉淀下来的错例库和回归测试，高质量数据集平台在这方面的价值就在这里——把评测集当成资产攒起来，模型换了、口径改了，效果不会一夜之间塌掉。演示看的是流畅度，能不能用看的是这三条。三条过两条，我就敢签字往下推。

回到那个最初的问题：企业花钱做 AI 网关，到底买的是什么。我的看法很直接，买的是”业务敢用”这四个字。技术圈容易陷进参数和架构里，可业务方判断一个系统好不好，标准朴素得很——它说的对不对，我能不能查到依据，出了事找谁。

这三个问题，转发层一个都回答不了。能回答的是数据资产、主数据、数据开发规范、评测集这一整套底层能力。所以我在预算规划上通常这样建议：数据侧的投入要占大头，模型和接入层控制在三成以内。这个比例听着反直觉，但跑过三年的人都会同意。AI 应用的护城河不在模型里，在你自己的数据描述体系里。

还有一个建议，别追求一次做全。挑一个业务域、二三十个高频问题，做到业务方主动用、且愿意拿它的问题作决策依据，再往下一个域扩。我见过一步到位的大项目，投入很大，验收会开得很风光，真正每天打开的人寥寥。反过来，从小切口进去、三个月见效、半年扩一次的那种项目，活下来的概率高得多。

这事还有个隐性的收益，很多人一开始没算进去。为了做 AI 问数，你得把指标口径理清楚、把主数据对齐、把权限规则定下来。这些活儿即便不做 AI 也该做。等于说，AI 项目顺手把数据治理往前推了一大截。我有个客户后来跟我说，他们内部最大的变化不是多了个问答入口，而是开会时不再吵”到底哪个数字是对的”了。这句话我记了很久，比任何验收报告都有分量。

如果你现在正卡在这件事上，我的建议是：先别急着选网关，把这三个问题写下来交给团队——我们有哪些数据资产？口径谁负责？答错了怎么办？能给出让人信服的答案，这个项目就成功了一半。剩下的，是把它做扎实。这条路不快，但它走得远。

陈志远：我们去年就是先做的模型接入层，限流计费做得挺完善。结果业务问数一直推不动，回头补数据治理补了半年。早点看到这种讲法能省不少事。

林晓雯：主数据那段说到我了。客户编码三个系统三个样，问数出来的客户画像根本对不上。我们后来先统一了主数据，问数才真正有人用。

周立群：权限跟着人走这条太重要了。我们之前是问答层单独配了一套权限，跟数据平台不同步，出过两次越权看到敏感数据的事，后来被审计盯上了。

吴敏：三个痛点的第三条最真实。上线那天全公司发邮件，三个月后后台日活个位数。现在老老实实定了个运营角色，每周看一次问询日志，情况才开始好转。

郑海涛：评测集这个点很少有人提。我们每年模型升级一次，没有回归测试根本不敢动，生怕效果塌了没人知道。