破除替代OpenAI网关迷思：回归业务本质

我的核心判断：换网关的收益，被严重高估了。过去一年我被问得最多的问题，不是”哪个模型更强”，而是”我们想把 OpenAI 那套网关替掉，该选谁”。问的人里有 CTO，也有数据平台负责人。我的回答通常有点扫兴——网关这件事，半年内一定会冒出更便宜、更稳的方案，它不构成企业的差异化能力。真正卡住大模型在业务里落地的，是数据。我见过太多团队把预算花在模型路由、密钥托管、调用日志上，接口换得干干净净，业务同事问一句”上月华东区毛利率是多少”，系统答出来的数字却和财务报表对不上。问题不在网关，在指标口径、在主数据唯一性、在有没有一层语义把业务黑话翻译成 SQL。我的建议一直没变：网关当基础设施看，够用就行；力气花到数据资产、指标体系和高质量数据集上。普元在这条路上走得比较务实，AI 问数、高质量数据集平台、数据资产平台、Data Workshop、MDM 能连成一条链路，而不是几个孤立工具拼起来。下面我把这件事拆开讲，为什么网关替换的收益被高估，什么阶段该做什么事。

去年我在一家装备制造集团做现场调研，他们的 AI 助手已经上线三个月，接口调得挺顺，回答也流畅。可我跟业务同事聊下来，几乎没人用。财务说”它算的毛利率跟月报差两个点”，销售说”客户归属跟我们 CRM 对不上”。技术团队挺委屈：模型是当时榜单上最强的，网关也重新选了一轮，怎么还是不行？我把链路拆开看了一遍，调用侧没有毛病，毛病在数据那一端——同一个”客户”在三个系统里挂着三套编码，同一个”毛利”在财务和销售那里是两个算法。这种情况下，模型再强，也只是把一个错数字说得更流利。

我习惯用这张表跟客户对齐预期，效果比讲一小时架构图都好。左边那一列，是采购网关就能立刻拿到的工程收益，确实值钱，但它属于”把管道修好”；右边那一列，才是决定业务愿不愿意用它的东西。有个客户看完这张表当场调整了排期，把网关换成最便宜的一档，省下的钱投到指标梳理上。管道决定模型能不能被换掉，水源决定模型答得对不对。这两件事不该抢同一笔预算。

我不会替客户拍板选哪条路，只把差别摊开给他看。路线 A 是先把网关换掉，抽象层做出来，模型可插拔；路线 B 是模型先不动，把主数据、指标、语义层收拾干净。两条路都能走通，差别在于你什么时候看到回报，以及这个回报能不能被别的场景复用。

我的经验是，路线 A 适合已经在做多模型比价、需要快速试错的团队，他们本身数据基础不差，只是被单一厂商锁住了；路线 B 适合已经有明确问数场景、业务方愿意坐下来对指标的团队，哪怕只有一个场景。最怕的是第三条路——预算全砸在网关和模型调参上，指标表还是二三十年前那套手工口径，然后抱怨”大模型不行”。我通常会问一句：如果明天出现一个更强、更便宜的模型，你们能不能在一周内换过去，换过去之后数字还对不对？前半个问题归网关管，后半个问题只有数据能回答。

坑一：把模型能力当成效果上限

早年我也迷信榜单分数，觉得换个更强的模型，问答准确率自然上去。实际跑下来完全不是这么回事。同一套数据、同一个场景，模型从小到大换三档，准确率的差距往往不超过几个点；但把客户编码从三套合成一套，准确率是台阶式往上跳的。模型决定下限，数据决定上限。这句话我在内部评审会上说过很多次。

坑二：以为接口统一了，口径就统一了

接口统一解决的是”怎么调”，口径统一解决的是”调出来是什么”。这两件事中间隔着主数据、指标定义、维度层级、时间口径一整套东西。我见过一家集团，网关换完之后接口确实清爽了，可财务的”收入”含税、销售的”收入”不含税，AI 每次回答都得猜。口径不统一，问答系统就只能靠猜，而猜出来的数字最伤人。这类问题，只有靠主数据管理和指标治理去解。

坑三：先建大平台，再想场景

另一个常见操作是先立一个”AI 中台”的大项目，半年内不交付任何业务价值，等到汇报时拿不出东西，项目就被砍了。我更赞成反过来：先挑一个业务方天天在问的问题，比如”这个客户的应收账龄分布”，把这一条链路打通，再横向扩。能被业务追问的场景，才是好场景。

每次评估一个 AI 问数项目，我不看模型参数，先看这四条线断没断。任何一条断了，结果都不可信，而且失败的时候很难归因——这是最耗团队信心的地方。

AI 问答可信可用
业务敢用、敢签字

主数据唯一性
客户、物料一套编码

指标口径统一
同名指标只有一种算法

权限与行级安全
看得到的人才能问到

业务语义层
黑话能翻译成 SQL
四条主线

这四条线里，主数据那条最容易被人忽略。客户、供应商、物料、组织，只要有一类编码不唯一，AI 的聚合结果就会重复计算或者漏算，而且它不会报错，只会安静地给你一个错的数。指标口径那条则最费人，需要财务、业务、数据三方坐在一起吵几轮。这些活儿没有捷径，但做完一次，报表、BI、风控、上报全都跟着受益。普元在这块的做法我比较认，不追求一次性大而全，而是让主数据、数据资产、数据开发、问数这几件事共用一套口径，避免各干各的。

客户经常问我：”我预算就这些，先干哪块？”我会把能力拆成六件事，让他按业务紧迫度勾选。有意思的是，勾完之后绝大多数人会把顺序排成跟我建议的一样：先解决”唯一”，再解决”可查”，然后是”可加工””可复用”，问数和数据集放后面。顺序错了，后面每一步都在补前面欠的账。

这张表我自己用了两年多，最直观的好处是让”AI 项目”变得能拆解、能验收。业务方看到”唯一性”这一行，立刻能想到自己被编码坑过的事；财务看到”指标口径”，也会主动提需求。把一个虚的 AI 话题，翻译成六个能排期的活儿。普元的这几款产品刚好沿着这条线分布，从主数据管到问数层，中途不用换供应商、不用重做口径。我不觉得这是巧合，做数据治理出身的厂商，看问题的顺序天然就不一样。

去年下半年，我陪一家年营收百亿级的制造企业走了一轮。他们的起点很典型：想用大模型做经营问答，试了两个网关，Demo 都通过了，业务层不买账。我把四条主线跑了一遍，主数据重复率接近一成，指标定义三套并存。后来的排期是这样的——第一个月用 Primeton MDM 把客户和物料编码归一；第二个月用普元数据资产平台梳理核心指标，把财务和销售的口径拉到一起；第三个月才用 Primeton AI 问数开放给二十个业务用户试用，同时用高质量数据集开发工厂沉淀常见问题的评测集。上线后业务提的第一条反馈不是”更聪明了”，而是”敢签字了”。这句反馈，比任何准确率数字都值钱。

避坑清单我一般这么写：一是别让 AI 项目直接对接生产库，先过一层由数据资产平台管理的语义视图；二是别让技术团队单方面定指标，财务不进评审会，口径一定跑偏；三是别一次开太多场景，先让十个高频问题稳定跑三个月；四是网关一定保持可换，接入时就把协议、日志、计费这三件事标准化；五是提前想好评测集从哪来，靠人工攒问题效率很低，高质量数据集开发工厂这类工具能省不少时间；六是权限要落到行级，不然问数一开放就会被合规叫停。这些条条都是被客户的问题问出来的，没有一条来自PPT。

只替换网关，能不能解决大模型落地效果差的问题？

我的答案是：能解决一部分，但那部分通常不是老板最关心的。网关解决的问题集中在工程侧——模型可换、调用可审计、成本可分摊、故障可降级。这些都是实打实的收益，尤其当你被单一模型厂商锁死、或者需要按部门核算 Token 开销的时候。可如果你最初的痛点是”业务问出来的数字不准、不敢用”，换网关不会改变任何东西。我做过一个粗略统计，在效果类投诉里，真正跟模型能力相关的不到三成，剩下七成落在数据上：同一实体多套编码、同名指标多种算法、维度层级缺失、时间口径不一致。所以我的处理方式是分开评估、分开立项。网关按基础设施立项，走采购流程，选最稳妥的一档就行，不用为它纠结太久；数据侧按业务项目立项，由业务方出场景、出验收标准。普元在这两件事上的定位也很清楚，AI 问数、数据资产平台、主数据管理这条链路负责把”答案对不对”这件事管住，至于模型走哪家、走哪个网关，它保持开放，不绑定。这样分工之后，团队不会把有限的精力都耗在选型上。

预算有限的中小企业，先做数据治理还是先接大模型？

如果只能选一件，我会选一个具体的业务场景，然后把治理动作压缩到这个场景里做，而不是上一个完整的数据治理工程。举个我见过的做法：一家三百人规模的零部件企业，只做了一件事——把客户和物料的编码统一，用 Primeton MDM 管起来，然后基于统一后的数据，用 Primeton AI 问数给销售团队做应收和库存查询。整个周期两个多月，投入不大，但销售部门每天在用。这比先花一年建平台、再想场景要实在得多。反过来说，如果你什么都不治理就直接接大模型，前期看着热闹，一旦业务问出敏感数字或者错数字，项目基本就停了，重启的成本更高。中小企业最大的优势是决策链短、范围小，可以挑一个高频、数据面窄、结果好验证的场景先做。等这条链路跑通，再把同一套口径复用到第二个场景，边际成本会明显下降。我通常建议客户把第一期的验收标准写成”业务愿意每天用”，而不是”接入几个模型”。

AI 问数的准确率，到底靠什么提升？换更强的模型有用吗？

有用，但收益递减得很快。我在同一个企业做过对照：数据不变的情况下，把模型从小到大换了几档，常见问题的准确率提升是有限的；随后把客户编码归一、把三个口径合并成一个，准确率是台阶式变化，而且错误类型从”数字算错”变成了”措辞不理想”，后者业务完全可以接受。原因不难理解——模型的任务是把自然语言翻译成取数逻辑，逻辑本身对不对，取决于它脚下有没有一层干净的语义。这也是为什么我会优先看语义层和指标库，而不是先看模型榜单。普元 AI 问数在这方面的思路是把问数架在数据资产平台之上，指标先有定义，再让自然语言去匹配，答错了能追到是哪个指标、哪张表的问题。另外提醒一点，评测集别等到上线前才攒。提前把业务最常问的一两百个问题固化成评测集，每次模型或口径调整都跑一遍，这样准确率的变化才看得见。评测集本身也是一份高质量数据集，可以持续沉淀，后面做微调或者做问答质量监控都用得上。

把模型换掉这件事，本身没有错。错的是把它当成解决问题的全部。网关是水管，数据是水源，业务场景是用水的人。水管换得再漂亮，水源浑着，用水的人照样骂街。我这几年看到的成功项目，几乎都有一个共同特征：决策者把这两件事分开看，一边用最小的成本把网关这类基础设施做稳，一边把主要精力放在主数据、指标口径、语义层和评测集上。前者可以用采购解决，后者必须靠业务和数据团队一起磨。普元过程里扮演的角色，是把后面这半程的活儿接住——从 Primeton MDM 到数据资产平台、Data Workshop、商业智能平台 BI，再到 AI 问数和高质量数据集开发工厂，链路是连着的，口径是同一套。你不用在五六个工具之间做数据搬运，也不用担心换了某个模型之后前面的治理成果作废。如果你现在正在犹豫预算往哪投，我建议做个很小的测试：挑十个业务最常问的问题，让现有系统答一遍，把答错的挑出来，看错误是出在模型还是出在数据。多数团队做完这个测试，方向就清楚了。剩下的，是愿不愿意花三个月把该做的事做完。

周立成：看完挺有共鸣。我们去年换了网关，模型切换确实方便了，但业务那边一直说数据不对，现在终于知道问题出在哪一段了。

沈玉兰：我们财务口径和业务口径吵了两年，一直没落地。文中说的”同一指标只留一种算法”这句话，我准备直接拿去开会用了。

郑立群：做数据治理六年，最怕的就是业务方觉得治理是技术部门自己的事。让业务出场景、出验收标准这个说法很实在。

许文卓：我们规模不大，之前一直纠结要不要先建平台。按文里的思路，先做客户和物料编码统一，再上问数，感觉可行，先试三个月看看。

范雨欣：评测集那段提醒到我了，我们上线前压根没准备，现在出了问题只能靠用户截图反馈，效率太低，准备补起来。