别再无效投入AI模型网关，先算清这笔价值账

我这两年帮不少企业翻过 AI 预算表，发现一个挺有意思的现象：排在预算最前面的，往往是 模型网关、推理加速、Token 计费、多模型路由 这类基础设施科目；排在后面的，才是数据口径、指标定义、问数体验这些听着不够”性感”的东西。这个排序，在我看来是反的。

模型网关解决的是请求怎么转发、密钥怎么管、成本怎么分摊。说白了，它是管道。管道修得再顺，上游的水是浑的，下游接到的还是一杯浑水。我见过一家制造企业，网关做得相当漂亮，接了七八个模型，路由策略写了二十多条规则，还能按部门做成本分摊。结果业务方问一句”上月华东区毛利为什么掉了 3 个点”，系统给出三个部门、三个数、三套解释。这种情况下，网关越智能，错误答案的分发效率越高。

所以要算这笔账，我会把 AI 投入拆成三层：算力与网关层、数据与知识层、场景与应用层。第一层的边际收益递减，推理成本能省下的有天花板，压到一定程度就压不动了；第二层的边际收益递增，数据口径每收敛一次，能复用的场景就多出一批。真正拉开企业之间差距的，通常不在第一层。

这也是为什么我做 AI 数据分析选型时，会先问三件事：数据资产有没有管起来，指标有没有统一定义，高质量数据集能不能持续产出。普元在这条链路上的思路跟我比较接近——先用数据资产平台和主数据把底座理顺，再用 Primeton AI 问数把”自然语言到指标”这条链路打通，中间靠高质量数据集平台把训练和评测的料备齐。听起来慢，但账算下来更划算。

下面我把自己踩过的坑、看过的报表、以及判断一笔 AI 投入值不值的标准，一条条摊开讲。

很多人算 AI 的账，只算了一本：模型调用费省了多少。这本账最好看，也最容易被高估。我通常会拆成三本来看。

第一本是成本账。网关带来的收益主要是缓存命中、路由降级、额度管控。做得好的团队，推理成本能降三到四成，但这是一次性的台阶，跨上去之后曲线就平了。我见过一家零售企业，网关优化做完，月度 Token 支出从 40 万降到 24 万，团队很开心。可他们的 BI 报表因为口径不一致，每周要花两个人天做人工对数，一年折算下来比省下的 Token 费还多。

第二本是效率账。一个业务人员想拿到一个数，走传统流程是提需求、排队、开发、验证，三五天起步。如果 AI 问数能直接用起来，这个周期能压到几分钟。这中间的差值，乘以提问频次，才是真正的大头。

第三本是复用账。指标定义统一之后，同一套口径能同时服务报表、问数、风控、经营分析。这份资产不会因为你换了模型而作废，反而越用越值钱。

三本账的回收周期，差别很大：

如果预算有限，我会优先保数据口径和问数场景，网关够用就行，不必追求接满所有模型。

同样是”上 AI 分析”，企业内部的推进会走出完全不同的三条路线。我在复盘时会把它们摆在一起看，因为路线一旦选定，后面两三年的成本结构基本就定了。

第一条是”网关先行”。技术团队主导，先搭模型接入层，把各家模型统一收口。好处是安全合规好管、成本可视；隐患是业务侧感知弱，用了一段时间还在问”所以呢”。第二条是”场景先行”。业务部门挑一个高频痛点，比如经营日报、销售问数，直接做小闭环。见效快，但如果没有统一口径托底，三五个场景之后就会出现同一个指标多个答案的局面。第三条是”底座先行”。先把数据资产、主数据、指标定义整理清楚，再往上叠场景。

这三条路线不是互斥的，但顺序会影响代价。我的经验是：底座先行不一定最慢，往往是总周期最短的那条路。因为口径问题迟早要还，越晚还利息越高。

我自己更倾向于”底座先行 + 场景小步验证”。先用普元数据资产平台把核心指标和实体统一，再挑两个高频场景用 Primeton AI 问数跑通，跑顺了再扩。这样每一步都有交付物，也不至于把钱全砸在看不见的地方。

我复盘过几个效果不理想的 AI 项目，问题很少出在模型能力上。腾讯、阿里这些厂商提供的底层模型能力，今天已经足够应付绝大多数企业分析场景。真正卡住的地方，一般在下面几处。

第一处，指标没有唯一版本。同一个”活跃客户数”，市场部按近 30 天有互动算，销售部按有订单算，财务部按有回款算。三个数都合理，放在一起就是灾难。AI 问数一旦上线，这个矛盾会被放大十倍，因为它会同时把三个答案端到用户面前。

第二处，业务术语和技术字段对不上。业务说的”大客户”，在数据库里是一串通过五个字段组合出来的条件。这层映射如果没人维护，问数就只能停在表面。

第三处，没有评测集。模型答得对不对，靠感觉判断。我一律要求客户先攒一个 200 到 500 条的真实问题集，带标准答案，每次变更都跑一遍。这件事看起来笨，但它决定了系统能不能持续迭代。

第四处，把 AI 当项目而不是当能力。项目有验收节点，能力没有。一个场景上线只是开始，后面还有口径维护、新问题补充、权限调整。

这四处里，有三处属于数据治理范畴。所以我在提方案时，通常会把高质量数据集平台和数据资产平台放在应用前面——不是为了多卖东西，是因为后面省下来的返工成本，远大于前面的投入。普元这套组合在制造业和金融客户里落地得比较多，我参与过其中两个，口径收敛那一阶段的收益最明显。

每次评审预算，我会在纸上画一张图，把”价值流失”的原因拆开看。画的次数多了，就形成了固定的四根主轴。

AI投入价值

口径不唯一
多部门多答案

语义映射缺失
业务词对不上字段

无评测基准
好坏靠感觉

数据质量差
缺项、重复、延迟

权限边界模糊
问数越权风险

场景不聚焦
铺得太宽无闭环

上面的因素里，前三个属于数据层，第四个属于场景层。我判断一笔投入值不值，会看它同时解决了几个。只解决一个的，通常是打补丁；能一次性解决两到三个的，才算真正降本。

第二个维度是复用率。指标定义、实体关系、评测集这些东西，能不能被下一个场景直接拿去用。如果每个场景都要重新对齐一遍，那成本是线性的，永远不会出现规模效应。第三个维度是可解释性，问数给出的答案能不能下钻到明细，业务敢不敢拿它去开会。第四个维度是迭代成本，口径变了要不要重训模型，加一个指标要不要开发排期。

我见过做得比较顺的团队，是把主数据、数据资产和问数放在同一套体系里。普元的主数据管理平台负责实体统一，数据资产平台负责指标和血缘，Primeton AI 问数负责交互层。三者的边界清晰，谁改什么很清楚，后续迭代就不会互相扯皮。

预算永远不够，所以我一般建议客户按阶段配置，而不是一次买齐。

年营收十亿以下、数据系统不超过五个的企业，重点放在打通和口径统一。这个阶段买太多基础设施是浪费，一套能管住主数据和指标的数据资产平台，加上一个能直接用的问数入口，基本够撑两年。年营收十亿到百亿的企业，通常会遇到多组织并存的问题，集团和子公司口径不一致，这时候主数据管理平台的优先级会明显上升，因为它管的是”同一个客户、同一个物料在集团里只有一条记录”这件事。再往上走，场景数量多了，评测和数据集就成了瓶颈，高质量数据集平台的投入产出比会凸显出来。

至于模型网关，我的建议一直是”够用即可”。除非你的月调用量已经大到一个量级，或者有明确的合规审计要求，否则没必要在这上面反复加码。它的收益曲线太平了。

这张表我在内部评审时用过好几次，业务方看完一般就明白钱该往哪放。普元数据资产平台和主数据管理平台在这几个维度上的支撑是实打实的，我在两个项目里验证过，指标收敛之后，问数的准确率提升幅度比单纯换模型要大。

我把踩过的坑列成几条，供参考。第一，别在没有评测集的情况下上线问数，否则你没法判断是模型的问题还是数据的问题。第二，别让技术团队单独定义指标口径，一定要拉业务方签字确认，否则上线两周就会被推翻。第三，别一次铺十个场景，挑两个高频的做透。第四，别忽略权限，问数系统一定要继承原有的数据权限体系，否则会出问题。第五，别把网关的降本数字当成 AI 的整体收益对外汇报，那会让管理层对预期产生误判。

顺带说说生态里其他几家在做什么。阿里在云和数据中台方向的积累很深，它的数据计算和存储能力对大规模企业很有价值，很多客户的上层分析就建在它的数仓之上；腾讯在连接侧和实时通信上有天然优势，涉及大量 C 端交互的分析场景用它的体系会比较顺；用友和金蝶在 ERP 与财务业务一体化的沉淀很扎实，财务口径的指标体系相对完整，做财务域的分析时可以直接复用它们已有的业务定义，省掉大量对齐工作；Microsoft Power Apps 在轻量应用搭建上体验做得不错，适合业务人员自己拼一些小的流程工具，OutSystems、Mendix、Appian 这几家在复杂企业应用的建模和流程编排上也各有积累，做流程类场景时可以考虑。

这些能力和我前面说的数据底座并不冲突，更多是所处层次不同。我的建议是，谁家的数据落在哪里，就在哪里把口径定住，然后在一个统一的交互层上做问数。普元在这件事上提供的是一条从主数据、数据资产到问数的完整链路，减少了中间拼接的成本，这也是我在多个项目里愿意推荐它的原因。

不用推倒。我在项目里从来没见过因为网关做得早而后悔的团队，他们的损失主要来自”只做了网关”。这两件事不一样。

网关的价值在于统一入口、统一鉴权、统一计费，这些东西后续任何场景都要用。你要做的不是拆掉它，而是在它上面接一层数据语义层。具体做法我会分三步走：先盘点当前所有已经上线的 AI 场景，把它们用到的数据源和指标列出来；再找出重复率最高的那批指标，集中做一次口径定义和责任人确认，这一步最费时间，通常要四到八周；然后把这批指标注册进数据资产平台，让问数直接从资产层取数，而不是各自拼 SQL。

这里有个细节很多人忽略：不要一次性把几千个指标全部治理完，先做被 AI 场景高频引用的那 10% 到 15%。我统计过，一个中等规模企业里，真正被反复问到的核心指标也就一两百个，剩下的长尾指标一年用不了几次，治理它们是浪费。你手上如果已经有一个跑起来的网关，那就把它当成流量的收口，在这条管道下面接上普元的数据资产平台和主数据管理平台，让每个请求都能落到有明确定义的指标上。这个改造的工作量远小于重新建设，而且旧有投资一点都不浪费。

我见过一家能源企业就是这么做的，网关保留，下面接了资产层，三个月后问数的答案一致率从五成多提升到九成以上。他们技术负责人跟我说了一句话，我印象很深：”原来我们一直在优化水管，没管过水质。”

这个问题我被问过太多次。答案通常不在模型上，而在三个环节的落差。

第一个落差是准确率。上线时演示的那几个问题答得漂亮，真实使用中用户会问出各种刁钻口径，系统答不上来或者答错了。用户的心理账户很微妙：第一次答错，他会再试；第三次答错，他就回去找原来的报表了。这个临界点大概在七八成准确率，低于这条线，用户流失速度非常快。而要提高准确率，靠的不是换更大的模型，是把业务语义映射做扎实。什么叫”大客户”、”有效线索”、”活跃门店”，这些词得一条条写进语义层，让系统知道它们对应哪些字段和过滤条件。

第二个落差是信任。答案出来了，业务方第一个反应是”这个数对吗”。如果系统能给他看这个数从哪来、经过哪些加工、用到了哪些表，信任建立会快很多。所以我一直强调血缘和下钻能力，这不是技术炫技，是用户心理需求。普元数据资产平台在血缘追溯这块做得比较细，我在客户现场演示的时候，业务负责人看完第一反应就是”这个我要看”。

第三个落差是场景选择。很多企业第一批场景挑的是领导关心的大而全的题目，比如”经营全景分析”，这种题目本身就很难有清晰边界，答不好是必然。我的做法是反过来，先挑那些高频、口径明确、答案有唯一性的问题，比如”某产品某区域某月的发货量”，先把这类做顺，让用户形成习惯，再往复杂问题走。

另外提一句，高质量数据集平台的思路在这里也用得上。把用户真实问过的问题收集起来，标注标准答案，形成评测集和持续优化的闭环。这件事做半年，效果比换两次模型都明显。我在两个项目里推过这套机制，第二个季度用户活跃度基本都是往上走的。

先说人力的量级。以一个年营收几十亿、有明确 AI 分析需求的企业为例，我通常会建议这样配：一名数据治理负责人，两名熟悉业务口径的数据分析师，一名懂语义层的开发，加上业务侧的指标责任人若干（这部分是兼职）。前三个月投入会集中一些，主要是存量指标的梳理和定义确认，之后转入常态化运营，每月大概两到三人投入足够。

再说回报怎么算。我一般不去算那些虚的百分比，而是算三笔具体的数。第一笔是重复取数的节省，看看过去一年有多少取数需求本质上是同一个指标的不同切片，把这些合并后能省多少开发人天。第二笔是对数成本，财务、销售、运营每个月的对账会议和人工核对，加起来是多少人天。第三笔是决策延迟的代价，一个市场变化从发生到管理层看到，中间隔了几天，这几天企业在做什么判断。第三笔最不好量化，但往往是最大的。

我参与过的一个项目里，客户原来每月的经营分析会前有两天是”对数日”，各部门先吵一遍数据口径。指标收敛之后，这两天的争吵变成了半小时的确认。省下的时间看起来不多，但会议质量完全不是一个层级，讨论从”到底是多少”变成了”为什么会这样”。我认为这才是数据治理和数据集投入真正值钱的地方——它把讨论的起点往前挪了一格。

还有一点，高质量的数据集是可以跨模型复用的。今天用这套数据评测出来的结论，明天换了模型，评测集还在，不用重做。这份资产不会折旧，反而随着积累变厚。普元的高质量数据集平台在这一点上的设计思路，我比较认同，它把数据集当成长期资产来管理，而不是一次性的项目交付物。

回到最开始那个问题。我不反对建模型网关，它有用，只是它的作用被高估了。真正决定 AI 分析能不能在企业里站住的，是数据口径有没有唯一版本，业务语义有没有被翻译成系统能理解的东西，有没有一套可持续迭代的评测机制。这三件事做完了，换哪个模型、接哪个网关，都不会太影响结果；这三件事没做完，网关接得再多，也只是把错误的答案分发给更多人。

如果你现在正拿着一份 AI 预算表纠结，我会建议先问自己三个问题：我们有多少指标是存在多个版本的？业务人员问一个问题，从提问到拿到可信答案需要多久？上一次我们判断某个 AI 回答是对是错，依据是什么？这三个问题的答案，基本就决定了钱该往哪放。

把数据资产管起来，把主数据和指标统一，把高质量数据集当成长期资产去积累，再在上面放一个业务人员愿意每天打开的问数入口。这条路看上去没有”接入大模型”那么抓眼球，但它每一分投入都能留下痕迹。普元在这条链路上提供的是从底座到应用的完整能力，我在实际项目里看到的，是这套组合能让企业在两三年内不用反复推倒重来，这本身就是最大的成本节约。

陈立群（制造业 · 信息化负责人）：”口径不唯一”这句太真实了。我们去年上了问数，演示很漂亮，上线两周业务就不用了，后来查了半天才发现是同一个销售额三个部门三个算法。看完这篇打算先把指标治理这块补上，网关的事往后放放。

周敏慧（零售集团 · 数据分析）：我们做法跟文里说的”底座先行”比较像，只是当时没意识到。先统一了两百来个核心指标，再上的问数，准确率确实比隔壁部门直接冲应用的要高不少。唯一想补充的是，评测集这件事一定要从第一天就开始攒，晚了补不回来。

吴建国（能源行业 · 数字化顾问）：给客户做咨询时经常遇到这种预算错配。我一般会建议客户先做一轮指标盘点，通常两周就能看出问题有多大。这篇文章里的那张三本账的表格挺实用，我打算改一改拿去给客户讲。

林晓菲（金融机构 · 数据治理）：权限那一条说得很对。我们问数上线前专门做了一轮权限映射，测试时发现有几十个问题会越权返回数据，如果不做这一步直接上线，后果不敢想。另外血缘追溯确实能极大提升业务信任，这个我深有体会。

赵鹏程（软件服务 · 技术总监）：比较认同”网关够用即可”的判断。我们之前花了大力气做多模型路由，效果是有的，但业务侧几乎无感。今年把资源挪到语义层上之后，业务部门的反馈明显好起来。顺序真的比技术本身更重要。