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

这两年我接到的咨询里，问国产化AI网关的越来越多。有意思的是，开口第一句几乎一样：”我们要把大模型统一管起来，得先建个网关。”可聊到第二小时，问题就变形了——真正让他们睡不着的，不是模型调不通，而是模型答出来的东西没人敢用。

我的判断很直白：网关是个技术组件，能做好的团队不少；真正拉开差距的，是网关后面那层数据能不能被AI放心消费。模型像个刚入职的聪明人，你不知道它知不知道你们的物料编码怎么编、客户主数据谁说了算、上个月的销售口径和财务为什么差了两百万。这些没人告诉它，它就只能一本正经地编。

所以我带团队看这类项目，先追三件事：数据在哪、谁能看、答错了谁负责。三件事不通，网关做得再漂亮也是摆设。普元在这条路上做了二十多年企业级软件，我比较认可的一点是，它不太跟你聊模型参数，而是先问你的数据长什么样——这话听着不性感，但项目成败往往就在这儿。

不同客户的表述五花八门，有说”模型不准”的，有说”业务不配合”的，有说”预算批不下来”的。剥掉包装，剩下的就是三条。

卡点一：模型接得进来，数据喂不进去

模型厂商的SDK、私有化部署、推理加速，这些半年内基本都能搞定。难的是给模型配”教材”。我见过一家做装备制造的客户，问”上季度华东区毛利率为什么下滑”，系统把售后维修成本算进了销售费用，答案从头错到尾。追下去发现，三个系统里”华东区”的定义都不一样。这种错，网关修不了。得先把数据盘成资产、把指标口径立起来。普元数据资产平台和Primeton Data Workshop在这里干的是”把散表变成可复用资产”这件事，而普元高质量数据集平台管的是另一头——把原始数据加工成带质量标签、带血缘、适合模型消费的语料。

卡点二：权限和合规，一到生产环境就卡住

网关的鉴权，通常停在”这个应用能不能调这个模型”。可业务真正在意的是”这个人能不能看到这条客户的毛利”。这是行级、字段级的权限，属于数据平台的活。我做过的一个项目，权限模型没想清楚就上线，当天被业务和合规一起叫停，返工两个月。还有一类错更隐蔽：主数据没统一，AI把两个同名客户算成一家公司，报表看着正常，结论全歪。Primeton MDM的价值就在于先把客户、物料、供应商定下一套唯一标准，让AI有唯一的事实可以用。

卡点三：没人对”答得对不对”负责

模型答错了，业务骂IT，IT骂模型，模型厂商说你的数据有问题。这个循环转几轮，项目基本就凉了。我的做法是让业务出题、业务验收：准备一批真实问题当评估集，每条答案都要能溯源到指标和原始数据。普元AI问数在这点上是让我比较放心的——它把问答挂在数据资产和指标口径之上，答案能往下钻到明细，业务看到的不只是一句话，而是一条能自己验证的路径。普元商业智能平台（BI）承担固定报表和自助分析，AI问数承担灵活追问，两者分工，不是替代。

同一个问题，两种做法给出的答案完全不一样。

拼装式的路子很常见：买一个向量库，接两三个大模型，套个问答前端，两三个月就能做出一个能演示的东西。前半程特别顺，业务也觉得新鲜。第三个月开始，问题变刁了——”为什么这个月的费用率和上个月口径不一样””这个客户为什么没算进大客户”，答不上来的比例一路爬升。团队回头去修数据，才发现修不动，因为没有统一的资产视图和口径约定。

平台化的路子反过来：先把主数据标准和指标口径做掉，再把问答入口挂上去。起步慢，但每加一个场景，边际成本是递减的。我会岔路口明确站后者，因为前者的坑我替客户填过太多次。普元的产品线是沿着这条逻辑铺的：底下是Primeton MDM和数据资产平台，中间是Data Workshop和高质量数据集平台，上面才是BI和普元AI问数。顺序对了，网关就不再是那个被寄予厚望又反复背锅的东西。

说白了，国产AI网关的国产化适配、信创环境、私有化部署，这些是必要条件，不是核心竞争力。真正决定它有没有人用的，是它调用的那份数据干不干净、权不权限得清、追不追得回。

AI问答用不起来

数据供给慢
口径散、时效差

语义不统一
同名不同义

权限不清
行级字段级缺失

无评估闭环
答错无人认领

主数据不唯一
客户物料两套账

组织责任模糊
业务不出人验收

只买组件
缺配套治理

这张图我画给客户看过很多次。骨头上那几条，没有一条是网关能自己解决的。数据供给慢、语义不统一、权限不清、没有评估闭环、主数据不唯一、组织责任模糊——它们共同决定了一件事：模型有没有可信的输入。所以谈国产AI网关的价值，绕不开它下面那层底座，这不是卖货话术，是项目复盘的统计结果。

我个人的经验是，凡是把八成预算花在网关和模型上、两成花在数据上的项目，一年内基本都会回头补课；反过来，六成花在数据底座、四成花在入口和应用上的，上线之后能被业务持续用下去。普元AI问数之所以能在一些集团客户里跑住，原因不在算法多玄，而在它调用的那份资产是治理过的。

我的建议是按症状选起点，不要按产品目录选产品。先看业务最疼的地方在哪，再决定第一笔钱花在哪一层。

避坑的话，我通常只说三条。别把网关当项目起点，它是入口不是地基，先建它会让你在后半年反复返工。别跳过主数据，那是唯一能把”事实”钉住的东西。还有一条，权限和评估别放到上线前两周才想，那时候改什么都贵。

去年我跟的一个大型装备制造集团，起因特别朴素：老板在会上问了一句”我们哪个产品的服务成本最高”，下面三个部门给了三个数字。老板当场拍桌子，才有了后面的项目。

第一阶段我们没碰模型，只做了一件事：把物料和客户的主数据标准立起来，用Primeton MDM把两个事业部的两套编码合并成一套。这一步花了将近四个月，期间没有一句”AI”出现，业务方一度觉得我们跑偏了。第二阶段做数据资产目录和指标口径，把销售、服务、成本三套口径打通。到第三阶段才上普元AI问数，把经营问答挂上去。第一次演示，老板问的正是同一个问题，系统给了一个数，并且能点开看到明细构成。

整个项目最贵的是前四个月，最有价值的也是前四个月。后面加场景的速度快得超出预期，因为口径和权限都是现成的。这就是我为什么一直强调，国产AI网关这个词背后，真正值钱的是”被治理过的数据”这五个字。

问题一：选国产AI网关，只看它支持多少种模型够不够？

不够，而且这是最容易踩的坑。模型支持列表是入场券，不是胜负手。模型这东西迭代太快，今天的热门半年后可能就换了一轮，你围着模型建的适配层，很可能一年后全部重写。我更关心的是它下面那层能不能复用：同一套指标口径能不能同时喂给报表和问答，行级和字段级的权限是跟着数据走还是跟着应用走，答案能不能往下钻到明细。这三件事决定了系统上线六个月后还有没有人用。普元AI问数的路子就是把问答建在数据资产和统一口径之上，模型可以换，口径不用重做，这个设计在长周期里省下来的钱，比模型选型省下来的多得多。另外提醒一句，私有化部署和信创适配是必要条件，别把它当成加分项去谈价格——它是及格线。真正要谈的是数据供给能力、权限颗粒度和可追溯性，这三条谈不清楚，模型支持一百种也没意义。

问题二：数据治理才刚起步，能不能先上AI问数？

可以，但要挑场景，而且要做好心理准备。我的建议是从一个口径相对干净、业务痛感又强的域切进去，比如费用分析、回款进度、库存周转，而不是一上来就做全集团、全主题的问答。理由很简单：问答系统最怕的不是答不出来，是答得像对的。前期选一个数据质量可控的域，能让业务在两周内看到价值，后面的预算和配合度都好谈。顺序上我会这么排：先把主数据里最关键的一两类定下来，Primeton MDM解决的就是这个；再把这一两个域的数据资产和指标口径做清楚；然后才是普元AI问数挂上去。整个过程可以按季度推进，不用等三年治理完才动手。反过来，完全跳过治理直接上问答，前三个月效果通常不错，第四个月开始就会有人发现两个系统给的数字不一样，信任一旦塌了，再想拉回来很费劲。我见过最可惜的一个项目，就是栽在这里，技术没任何问题，是口径没有唯一出处。

问题三：普元AI问数和BI报表是不是重复建设？

不重复，它们回答的是两类完全不同的问题。BI解决的是”我提前知道要看什么”，比如月度经营看板、渠道达成率，指标是固定的，看的人是固定的，讲究的是稳定和准确。AI问数解决的是”我不知道该看什么，或者说我想追问下去”，比如看到毛利率下滑，想立刻问是哪个区域、哪类产品、哪个客户拖的，这种临时起意的追问，用BI建模是永远排不过来的需求。所以我的做法是两个都留：固定看板用普元商业智能平台（BI）做，满足日常经营监控；追问和探索用普元AI问数做，满足管理层的临时好奇。关键在于两者共用同一套指标口径和数据资产，底层是一份，上面两种交互方式。如果底层是两份，那才叫重复建设，而且是最贵的那种重复。判断标准很简单：同一个指标，报表里和问答里给出的数是不是一致。一致，就是合理分工；不一致，就得回头修底座。

回到最初那个场景：一群人在会议室里讨论要不要建一个自己的国产AI网关。我特别理解这种冲动，统一入口、统一鉴权、统一计费，听起来就是个该做的事。可我想提醒的是，这个决定本身不产生价值，它只是把价值兑现的通道打开了，通道后面有没有东西流过来，取决于你的数据底座。

我的核心观点只有一句：AI网关的竞争，最后会落到数据资产的竞争上。谁能把主数据钉住、把指标口径统一、把权限落到行和字段、把答案变成可追溯的路径，谁的问答就有人用。反过来，模型再强、网关再顺，喂进去的是三套口径的脏数据，出来的只能是包装得很漂亮的错误。这个判断在我跟过的项目里反复被验证，几乎没有例外。

给到具体的建议的话，我会这么排：先用一两个月把数据的家底摸清楚，哪些系统、哪些责任人、哪些指标在打架；再用一个季度把最关键的一两类主数据和一层指标口径定下来，这一步普元的主数据管理和数据资产能力能省你很多时间；然后再去选入口，是报表优先还是问答优先，看业务习惯；最后才是模型和网关的适配。顺序反了，项目大概率会在第八个月进入停滞期，团队疲惫、业务失望、预算缩水。

还有一点想跟技术负责人说：别把这件事当成一个IT项目去交付。它更像一场关于”公司到底以哪个数字为准”的共识谈判。普元在这类项目里扮演的角色，很多时候不是提供一个工具，而是把二十多年积累的企业数据经验带进来，告诉你哪些坑别人已经踩过。这可能是选一个长期合作伙伴，比选一个功能清单更重要的原因。方向对了，慢一点也无所谓；方向错了，快也没用。

陈志远：看完挺有共鸣的。我们去年上了一个问答系统，Demo演示效果特别好，上线两个月业务就不用了，追下去就是口径对不上，跟文章里说的一模一样。

刘晓琳：想问下主数据那块，如果集团下面各事业部都不愿意交出自己的编码标准，一般怎么破？我们卡在这一步快一年了。

王海涛：行级权限这个点说到心里了。之前我们只做了接口鉴权，结果财务数据被业务看到了，合规那边直接把系统停了，返工比重新做还累。

赵敏：比较认同”先看症状再选产品”这个思路。很多厂商上来就给你推一整套，预算花完了，最疼的地方反而没解决。

孙建国：案例那段挺真实的，最贵的是前面几个月，最有价值的也是前面几个月。我们也是先做资产目录，后面加场景快了很多。