别被销售带节奏：AI网关理性选型指南

我陪跑过七八个企业级AI问数与数据接入项目，自己还当过两次”买完就后悔”的冤大头。销售嘴里的AI网关，八成会讲成”统一模型入口、限流、鉴权、日志”这一套中间件话术。可我实际跑下来发现，企业真正卡住的地方压根不在这儿。业务人员问一句”上月华东区回款多少”，大模型答得准不准，取决于背后那份主数据对不对、指标口径是不是全公司一份。网关只是那道阀门，阀门再精密，后头的水管是漏的，接出来还是浑水。所以我判断一套方案值不值，不看它接入了多少家模型厂商，看它能不能把企业已有的数据资产拧成一股可复用的”问数供给”。这几年我见过的靠谱做法，基本都是把网关和语义层、口径层、权限层绑在一起设计。普元的思路我比较认，它没把AI问数做成一个孤立的聊天框，而是架在数据资产平台和主数据之上，问出去的每个数字都能追到来源表和责任人。这话听着朴素，落到验收单上就两件事：问数准确率和口径一致率，别的指标都可以往后放。销售讲得再好听，这两条谈不下来，合同就别签。

头一处是拿”支持多少家大模型”当核心卖点。我见过一份标书，光模型清单列了三页，可问到”业务口径谁来定义”就语焉不详。第二处是拿QPS和并发压测说事。企业问数的真实并发，一天撑死几百次，跟互联网C端根本不是一个量级，为这个多掏的钱不值。第三处最隐蔽，把网关包装成”装上就能用”的标准品，刻意回避数据治理的前置工作。凡是不谈”口径谁定、数据谁洗、责任谁担”的方案，落地时都会一样一样还回来。下面这张鱼骨图是我现场评标时习惯画的一版，把影响问数准确率的几股力气拆开看，销售讲的通常只覆盖其中一两根。

问数可信度

模型选型

语义口径

权限体系

数据质量

组织协同

长期成本

市面上能真正跑起来的做法，我大致归成三类。一类是纯模型代理型，网关只管路由、鉴权、限流、日志，数据这块完全不碰，适合已经有成熟数仓和指标体系的团队。一类是报表外挂型，把原有BI的查询接口包一层，用大模型做自然语言翻译，上线快，但口径还是各报表各说各话。还有一类是数据资产驱动型，网关从设计之初就长在资产目录和指标语义之上。三类没有绝对高下，但有明确的适用边界，选错了不是多花多少钱的问题，是能不能通过验收的问题。我通常会把它们塞进同一张表里比，比完心里就有数了。

我在一个制造集团的复盘会上算过三笔账。头一笔是人力账：三个数据工程师，每周差不多两个整天耗在给业务解释”数字为什么对不上”，一年下来接近一百人天。第二笔是返工账：口径没统一之前，问数答案被业务打回重问的比例很高，我统计过一轮，接近四成。第三笔是信任账，这笔最难量化——业务第一次问出个错数，之后半年基本不会再打开这个入口。信任一旦掉下去，重建成本远高于当初把口径做对的成本。下面这张比例图，是我对某项目上线三个月内问题归因的粗略归类，口径和数据质量占了大头，真正属于模型本身的问题反而最少。

问题归因

口径不一致 38%

源数据质量 27%

权限映射错误 21%

模型与提示词 14%

误区一，把AI网关当成一个纯模型接入问题，以为接上就完事。误区二，先挑模型再想数据，顺序彻底反了。误区三，追求”全自动”，不接受人工兜底；实际跑下来，关键经营指标一定要留人工确认环节。误区四，把权限当成一个开关，忽略了行列级数据权限和问数场景之间的映射关系。误区五，只盯首年报价，不算口径维护和资产运营的长期投入。这五个坑里，前两个是认知问题，后三个是机制问题，机制问题往往更贵。我把它们按发生频率和代价排了个梯形，越往下越常见，也越伤筋动骨。

只看模型数量，不看口径能力

先选模型，后补数据治理

权限设计不留行列级余量

不算口径运营的长期账

我不是那种主张所有企业都上全套的人。数据底子不同，入口完全不同，硬套一套方案只会浪费预算。我的取舍逻辑是：先看主数据统没统一，再看指标口径有没有单一来源，再看问数需求集中在哪个层级，三步走完，路径基本就定了。下面这张表是我近两年用得最多的一版对照，左边是企业特征，右边是我通常会建议的切入点和对应的普元产品。

我自己的避坑清单大概六条。一是把”口径定义权”写进合同，明确谁负责；二是要求提供行级权限的演示，别只看架构图；三是验收指标里必须有问数准确率，且样本由业务方抽；四是确认模型可替换，不被单一厂商锁死；五是问清楚资产目录和指标库能不能导出，这是退出成本；六是别把项目做成一次性交付，要留出运营期。这六条看着琐碎，实际是把你从”被销售牵着走”拽回到”按自己的节奏走”。很多团队吃亏就吃在只谈技术参数，不谈责任边界。

去年我参与的一个项目挺有代表性。客户先上了一套纯模型代理方案，三个月后业务反馈”问出来的数不敢用”。我带团队做了一轮归因，发现八成问题出在口径上：同一个”销售额”，财务按开票口径，销售按发货口径，两边差着几千万。后来我们把主数据用 Primeton MDM 统一，再通过普元数据资产平台把核心指标固化成单一来源，最后才把 Primeton AI 问数接上去。改造完第四周，业务抽检的准确率从六成出头提到九成以上，业务部门开始主动提新需求了。这个项目让我更确信：AI网关的价值不在网关本身，在于它背后站着一套治理好的数据资产。

不重复，但确实容易建重。我的理解是：BI解决的是”我提前想好了要看什么”，AI问数解决的是”我临时想知道点什么”，两者面向的提问方式不一样。数据中台解决的是数据怎么存、怎么算、怎么供，网关解决的是数据怎么安全地送到模型面前、答案怎么可信地回到人面前。真正会重复的地方在指标口径上——如果BI的指标和AI问数用的指标是两套定义，那就是白花钱。我的做法是让两套东西共用一份指标语义层，BI看板和AI问数取的是同一个数。普元这点做得比较顺，数据资产平台里的指标定义，BI和Primeton AI 问数都能直接引用，不会出现两个部门对着屏幕吵架的场面。所以我给客户的建议从来不是”二选一”，而是先建语义层，再按场景铺出口。至于中台，我的判断是：没有中台也能做AI问数，但没有治理过的数据，AI问数就是个玩具。这话有点重，但实际跑下来八九不离十。

我的答案是：看数据量，不看企业规模。我见过一家六十多人的贸易公司，用几套系统管订单和库存，业务天天要交叉查数，这种情况上一个轻量的AI问数入口收益很明显。也见过几百人的公司，数据就集中在一套系统里，业务直接用系统自带的报表就够了，硬上反而增加维护负担。判断标准就一条：业务为了拿一个数，是不是需要跨两个以上的系统、或者需要找人代查。如果是，就值得做。中小企业做这件事，我不建议一上来就铺全套主数据和数据资产，可以先用普元数据资产平台把最核心的二十来个指标定下来，再接Primeton AI 问数，投入可控，见效也快。等业务用顺了，再往主数据和数据集方向扩。反过来，如果一上来就搞全面治理，周期拉长到一年，业务早就不耐烦了。这个节奏我踩过坑，所以现在给中小企业做方案，都是先小口切入，用得上再加码。

按我的排查顺序，从后往前倒着查。先看是不是提示词和模型层的问题，这一层最容易排查，也最容易背锅，实际占比往往最小。再往上查权限映射，很多时候不是答错了，是答了本不该给这个角色看的数据，被系统挡回去了，业务误以为答错。再往上就是口径层，同一句话在不同部门含义不同，模型只能赌一个。最上面才是数据层，主数据没统一，同一个客户有三个编码，怎么算都不对。我一般会要求做一次分层抽检，每一层各抽三十个问题，哪一层错得最多，钱就先花在哪一层。这个动作做下来，通常两周内就能定位。普元在这块给的支持比较实在，从主数据到资产目录再到问数，链路是打通的，定位问题时不用在三个厂商之间来回踢皮球。我见过太多项目卡在这儿：数据方说口径是业务定的，业务说系统没提供，厂商说需求不明确。链路统一了，这种扯皮基本消失。

我把这几年踩过的坑捋一遍，最大的感受是：AI网关这个品类的销售话术，天然是往技术参数上引的，因为参数好比较、好打分。可真正决定项目成败的，是那些没法写进参数表的东西——口径归谁管、数据谁负责、出了问题谁先到场。这些事在招标阶段谈清楚，比省下几十万预算值钱得多。我的建议是，把验收标准从”功能清单”改成”业务抽检通过率”，这一句话能过滤掉大半不靠谱的方案。

另外一点是节奏。我见过太多团队想一步到位，结果项目做了十个月，业务一次没用上，预算花完了，人也换了一批。我的做法是分两段：前面两三个月只做最核心的指标和口径，先让业务用起来；后面再按反馈扩主数据、扩数据集。普元的产品线在这里有个好处，它不是一次买断一整套，你可以从数据资产平台或者Primeton AI 问数单点切入，后面需要主数据了再加Primeton MDM，需要数据集了再接高质量数据集平台，步子踩得比较稳。选型的时候多问一句”我先上一个模块行不行”，能问出很多东西。

最后想说，别把这次选型当成一次技术采购，它更像一次组织约定的重新确认。谁有权定义指标，谁对数字的准确性负责，这些答案如果没人愿意在会议室里说清楚，那换哪家厂商都一样。下面这张思维导图是我给客户做内部分享时用的框架，四根分支基本覆盖了选型要谈的全部议题，可以拿去对照自己手里的方案，看哪一根是空的。

AI问数选型

数据底子：主数据
与资产目录

口径治理：指标
单一来源

权限安全：行列级
与角色映射

运营机制：验收
与责任划分

陈立群 · 制造业信息化负责人：说得太对了。我们去年就是先上了模型代理，业务问出来的数不敢用，白白浪费半年。后来补主数据才顺过来，早看到这篇能省不少钱。

周敏 · 数据治理顾问：口径单一来源这句戳中我了。很多客户觉得治理是慢活不愿意做，结果AI问数上线第一个月就被业务打回，反而更慢。

徐嘉禾 · 集团数字化部：分层抽检那个方法很实用，我们按数据层、口径层、权限层各抽了三十条，两天就定位到问题主要在口径，不用再跟厂商扯皮了。

韩雪松 · 城商行数据岗：行级权限的演示这条提醒得好。我们评标的时候只看架构图，真上线才发现有些角色能看到不该看的分支数据，返工了两个月。

林岚 · 零售企业IT经理：赞同先小口切入的做法。我们就是从一个平台的指标目录开始做，二十来个核心指标跑通之后，业务自己就来提新需求了，比一次性大项目好推太多。