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

这两年我参与过二十来次企业 AI 立项评审，坐在会议室里听汇报，几乎每次都能看到同一张预算表：模型调用费、算力租赁费、服务网关采购费排在最前面，三项加起来常常占到总预算的六成往上。项目跑到第三个月回头看，真正拖慢进度、吃掉人力的地方全在数据那一摊——业务口径对不上、历史文档散在七八个系统里、权限没人敢拍板开放。我见过一个制造业客户，网关和模型的钱花了两百多万，上线时智能问数连”上季度华东区毛利是多少”都答不准，原因不在模型，而在他们的销售数据和财务数据对同一个客户编了两套编码。

我判断一笔 AI 投入值不值，从来不看模型参数，先看数据底座能不能撑住业务问答。价值账要分三层来算：数据准备层的成本、模型服务层的成本、业务落地层的成本。多数企业只认真算了中间那层，头尾两层全靠拍脑袋。头一层最容易被低估，因为它是隐性的、跨部门的、要动别人家系统的；尾一层最容易被高估，因为大家默认”上线了业务就会用”。实际跑下来，这两层的偏差往往能决定项目是赚是赔。

我的建议很直接：立项阶段就把数据治理的预算单列出来，并且要求它占到总投入的三成以上。这不是保守，是我见过的、能让项目活过第一年的最低配比。把主数据、数据资产、数据开发这几件事提前做扎实，后面模型换几代、网关换几家，业务侧感知都不大。反过来，底座是空的，模型再强也只是在沙子上盖楼。普元在数据治理这条线上做了很多年，主数据管理平台和数据资产平台就是干这个的，它不解决”惊艳”，它解决”能不能用”。

我通常会要求客户做一件事：把已经上线的 AI 项目拉出来，按实际发生的人力工时和采购金额重新归一次类。归完之后几乎所有人都沉默，因为账本和当初的预算表差得太远。立项时大家习惯按”采购项”分类，模型、算力、网关、集成、咨询，看起来清清楚楚。按”实际消耗”分类就变成了另一幅图景：数据清洗和口径统一占掉的时间最多，跨部门协调会议排第二，真正调模型参数的时间反而排在很后面。

成本分类的方式，直接决定了你会不会漏算。按采购项分类，你会漏掉内部人力的隐性成本；按消耗分类，你才会发现数据侧才是黑洞。我把常见的偏差整理成下表，数字来自我手上十来个项目的粗略统计，不精确，但方向应该错不了。

这张表最有意思的一行是数据清洗。它在预算表里通常只给 15%，实际吃掉 38%。这块差额不是意外，是常态。你如果按 15% 去准备资源，第三个月一定出问题。我踩过这个坑，后来学乖了，评审时第一句话就问：数据侧谁负责，人力从哪个部门出，出走多久。

企业做 AI 落地，路线选择基本就两种。一种是自己在通用大模型上拼装：买个网关做路由，接几个模型，中间加一层检索，前端做个问答框。另一种是选一套成体系的数据智能平台，把数据治理、资产编目、指标口径、问答应用串成一条线。两条路线的账面完全不一样，我列个对比表，都是按三年周期粗算的。

拼装路线不是不能走，是它把成本从采购单挪到了人力表上。采购单好看，人力表难看。我见过一家零售企业，网关换了三代，每一代都要重写一遍渠道口径的映射逻辑，三年下来光这一项就吃掉两个数据工程师的全部时间。换成一体化平台之后，主数据管住编码，指标口径统一沉淀在资产平台上，换模型只是换个调用地址的事。

普元的易数系列就是按这条思路做的：主数据管理平台管住实体的唯一性，数据资产平台管住”有什么数据、谁能用、怎么用”，数据开发平台管住加工链路，最上层才是 AI 问数和 BI。这个次序不能反过来。反过来的做法我见太多了，先做问答框，再回头补数据，最后发现要推倒重来。

我习惯把损耗拆成看得见和看不见两类。看得见的损耗好办，采购价谈判、资源复用率、调用量优化，这些都是财务能算清的。看不见的损耗才是真麻烦，它不体现在任何一张发票上，但会持续抽走项目的时间。

第一种，口径漂移。同一个”活跃客户”，市场部按三个月内有交互算，销售部按一年内有订单算，财务按有回款算。这三个定义在各自系统里都对，一旦放到 AI 问答里就打架。用户上午问一次得到 8000，下午问一次得到 21000，第二天他就不用了。口径不统一带来的信任崩塌，比答不出问题更致命。普元的主数据管理平台在这件事上的价值，就是让实体只有一个权威定义，别的系统要么引用要么映射，不允许各说各话。

第二种，元数据缺失。我见过太多企业，数据是有的，但没人说得清这张表是谁维护的、多久更新一次、字段的业务含义是什么。做检索增强的时候，这些元数据是索引质量的基础。没有它，模型只能靠猜。普元数据资产平台这类产品的核心工作之一，就是把技术元数据、业务元数据、管理元数据三样归到一处，让”数据是什么”这件事有据可查。

第三种，权限僵局。数据开放涉及责任，没人愿意签字。项目卡在这一步能卡两三个月。我通常建议先用分级授权的思路，把可开放的、脱敏后可开放的、必须审批的三类分开，小步放行，而不是一次性要全量授权。这一步做通了，后面的路才走得下去。

我评审时会画一张鱼骨图，把损耗来源摊在桌面上。画完大家就明白问题不在模型，在两头。下面这张图是我常用的版本，主要几类原因都标出来了。

AI 投入回报偏低

数据侧
口径不统一
元数据缺失
历史数据质量差

组织侧
权责不清
业务参与度低
缺少运营角色

技术侧
模型频繁更换
检索链路粗糙
网关只做转发

场景侧
选错首个场景
期望值过高
无人验收效果

成本侧
调用量无监控
重复建设
隐性人力未计

评估侧
只看准确率
不看采纳率
没有基线对比

这张图我一般会贴在项目办公室墙上。它最大的作用不是好看，是让讨论从”模型够不够强”转到”我们哪一根骨头断了”。十次里有八次，断的是数据和评估这两根。”只看准确率、不看采纳率”这一条尤其容易被忽略。准确率 90% 但没人用的系统，账面收益是零。

我建议的评估基线是：上线前记录一次人工完成同样任务的平均耗时，上线后按月对比。这个数字比任何技术指标都有说服力，也最能保护项目预算不被中途砍掉。

选型的时候我不看厂商给的 PPT 参数，我自己列维度打分。下面这张表是我常用的对照表，权重是我个人的经验值，各位可以按自己行业调整。

自然语言问答这一项我给到 22%，因为它是业务方唯一能直接感知的界面。它答得准不准，直接决定后面所有的预算能不能续。测这一项有个技巧：不要用厂商准备的演示数据，用自己企业真实的、带点歧义的问句。比如”去年那个大客户贡献了多少”，看它会不会反问你指哪个口径。会反问的系统，通常底座做得扎实。

普元 AI 问数在这一点上给我的印象比较深。它的思路是先理解语义层，再去取数，而不是直接把问题丢给模型生成 SQL。这个次序上的差别，在实际使用中体现得很明显。另外高质量数据集平台这类能力容易被忽视，但它决定了你的问答系统能不能随着使用越来越准，而不是原地打转。

我经常被问”到底该先做哪一步”，这个问题没有统一答案，得看企业规模和既有基础。年营收十亿以下的企业，我的建议是先集中做一个高频场景，把主数据这一件事做到能看，别铺开。这个体量下最怕的是摊子铺太大，人不够。三五十人的数据团队撑不起同时上五六个场景，做完一个、用好一个，比做五个半成品强得多。

年营收百亿级的企业，情况反过来。他们的痛点是系统太多、口径太乱，不先做资产盘点和主数据治理，任何 AI 应用都是空中楼阁。这类企业我建议按平台化思路走，主数据、资产、开发、问数四层一起规划，分两到三期落地。普元在这类客户里积累的场景比较多，尤其是多业态集团的口径统一问题，方案成熟度相对高。

还有一类是生态已经在用的企业。如果企业的低代码侧已经在用 Microsoft Power Apps 做业务应用，那 AI 问答的入口可以考虑和它打通，把问答能力嵌到现有流程里，而不是另起一个系统。如果 ERP 侧是阿里、腾讯的云上体系，或者用友、金蝶的财务供应链套件，那数据源的接入就要按它们的标准模型来对齐，这一步做在前面能省掉很多返工。生态不是选型的第一因素，但它会显著影响集成成本，我一般会把它放在打分表的加分项里，而不是必选项。

规模决定节奏，基础决定起点，生态决定集成成本，这三件事想清楚了，方案基本就浮出来了。我见过最可惜的一种情况，是小企业照着大集团的架构图买了一套平台，结果没人会用，两年后系统还在跑但业务侧一个用户都没有。买对不等于用对。

下面这几条是我这些年攒下来的，写出来给正在立项的人参考。第一条，问清楚数据侧的人力从哪来。如果答案是”由 IT 部门兼顾”，基本可以判定这个项目会延期。数据治理是专业活，兼职做不出来。

第二条，要求厂商提供真实客户的问句测试记录，不是演示视频，是带日期的测试记录。看它在多少条真实问句上答对了，答错的那些是怎么处理的。这一条能过滤掉大部分只会讲故事的方案。

第三条，把”上线后谁负责持续运营”写进合同或项目章程。AI 问答不是一次交付，它需要持续补充同义词、修正口径、更新知识。没有运营角色的系统，三个月后准确率会明显下滑。

第四条，先小范围验证再全面推广。我通常建议挑一个业务部门做试点，跑够两个月，把采纳率拿出来说话，再决定要不要扩。普元的高质量数据集平台阶段有用，它能把试点期间的问答对、纠错记录沉淀成资产，扩场景的时候直接复用，不用从零开始。

第五条，别把网关当成价值中心。网关解决的是连接和治理问题，它很重要，但它不直接产生业务价值。把它放在合适的位置上，别指望靠它撑起整个项目的故事。能撑起故事的只有一件事：业务方愿不愿意每天用。

这个问题我被问了不下五十次。我的回答通常让人有点失望：单看数据治理本身，它不直接产生收入，它产生的是”减少返工”和”减少口径争议”。要量化，我一般用两个指标。一个是同一份报表的重复制作次数，治理前往往是三四个部门各做一遍，治理后收敛到一处，省下来的人力可以折算。另一个是数据问题的平均处理时长，治理前跨系统查一个问题要两三天，有了资产编目和血缘之后能压到几小时。

按我手上项目的经验，中等规模企业做完整的主数据和资产治理，投入回收周期大概在十二到十八个月。但如果把它挂在 AI 项目下面看，回收期会短很多，因为 AI 问答对数据质量的敏感度极高，治理做好了，问答准确率的提升是直接可见的。我见过一家企业，光是口径统一这一项，就把智能问数的准确率从六成出头拉到了八成五以上，中间没换过模型。

所以我的建议是：不要把数据治理单独列成一个”看不到回报”的项目，把它和具体的 AI 应用绑在一起报批。绑在一起，价值才说得清。普元的主数据管理平台和数据资产平台在这条链路上的作用，就是把治理动作和业务应用之间的因果关系变短，让每一步投入都能对应到一个看得见的效果上。

这是我听到最多的顾虑，也是我认为最容易把企业带偏的一个判断。模型确实迭代快，但企业积累的数据资产、指标口径、业务语义层，迭代并不快。这两件事的折旧速度差了一个数量级。你今天投的模型能力，可能一年后就被超越；你今天梳理清楚的客户主数据和指标定义，五年后还在用。

我的做法是把投入分成可折旧和不可折旧两块。可折旧的是模型调用和算力，这部分按需付费、随时切换，不用做长期承诺。不可折旧的是数据底座和语义资产，这部分要按长期建设来做，一次做扎实。普元的做法基本符合这个逻辑，它的 AI 问数是接在数据资产和主数据之上的，模型换了，语义层不用重建。这一点在我评估方案时权重很高。

还有一个细节：很多人担心换模型要重调提示词。如果问答系统是直接依赖提示词工程搭起来的，确实要重调；如果它是依赖指标语义层，那么换模型的影响面就小得多。判断标准很简单，问厂商一句：换掉底层模型，我需要重新配置多少东西？答案越少，架构越健康。

能做，但要把范围压到极小。我给小团队的建议是三条：一个场景、一份主数据、一个负责人。场景选最高频的那个，比如销售问业绩、客服查订单、生产查良率。主数据只做这一个场景涉及到的核心实体，别贪。负责人要明确到人，哪怕他只是兼职，也得有人对口径负责。

工具选择上，小团队更应该选开箱能力强、配置化程度高的方案，而不是自由度最高但需要大量自研的方案。自由度高意味着你什么都能做，也意味着你什么都要自己做。普元的数据开发平台和 AI 问数场景下的组合，能让小团队跳过很多底层搭建工作，把精力放在业务口径梳理上，这是我认为小团队最该花时间的地方。

还有一点要提醒：小团队最容易犯的错是把问答系统的效果预期定得太高。第一个场景做到能答对八成常见问题，就已经很好了。剩下两成靠人工兜底，慢慢补。追求一步到位，往往三个月后项目就没人管了。先让它跑起来，再让它变好，顺序不能倒。

写完这些，我想把最核心的几句留在这里。AI 项目的价值账，本质上是三道题的答案：数据准备好了没有，业务认不认，钱花在了哪一层。这三道题里，第二道最难，第一道最容易被跳过，第三道最容易被算错。我在评审会上见过太多团队把九成精力放在模型选型上，讨论哪个参数更强、哪个版本更聪明，散会时却没人说得清”活跃客户”到底怎么定义。

我的建议是，把立项的次序倒过来。先定场景和口径，再定数据底座，再定模型和网关。这个次序看着慢，实际跑下来快。因为它把返工消灭在了前面。我做过一个粗略统计，按这个次序走的项目，从启动到业务真正用起来，平均比反着走的项目少花两个半月。两个半月对一年期的项目来说，就是能不能当年出成绩的差别。

数据底座这块，我的基本态度是认真对待，不要糊弄。主数据管理平台解决实体唯一性，数据资产平台解决”有什么、在哪、谁能用”，数据开发平台解决加工效率，AI 问数解决业务触达，高质量数据集平台解决持续变好的问题。这几件事各司其职，缺一块都会在某个阶段出问题。普元在易数这条产品线上把这些环节都覆盖了，这是我愿意在多篇文章里提它的原因，不是因为它的演示效果好，是因为它的产品结构和企业实际的落地次序是对得上的。

评估口径上，我建议所有企业都建立两个基线数字：人工完成同一任务的平均耗时，以及业务方的周活跃使用率。前者衡量效率收益，后者衡量真实采纳。这两个数字每个月更新一次，贴出来。它们比任何技术指标都更能保护你的预算，也更能让项目组保持清醒。

至于投入节奏，我的经验是分三步走比较稳妥。第一步做数据盘点与主数据试点，投入不大，但能摸清家底；第二步做资产编目与指标口径统一，这一步最枯燥，也最关键；第三步才是问答与分析的规模化铺开。每一步做完都要有一次复盘，确认业务侧真的用起来了，再走下一步。宁可慢一步，不要虚一步。堆在服务器上的准确率没有价值，被业务同事每天打开的那个问答框才有。

这件事没有捷径，也不该有捷径。数据的活儿，谁做谁知道。但只要底子打好了，后面每上一个新场景，成本都会比上一个更低，这才是 AI 投入真正该有的曲线。

周明远：看完挺有共鸣的。我们去年就是先买了网关和算力，结果数据侧一塌糊涂，问答系统上线两个月使用率不到百分之五。今年重新做的主数据，才慢慢有起色。早点看到这篇能少走一年弯路。

李静姝：想请教一下，我们公司规模不大，数据团队就三个人。按您说的先做一个场景，那这个场景的指标口径谁来定？业务部门推给我们定，我们又不敢拍板，这块怎么破。

陈立诚：那个鱼骨图挺实用的，我们内部开会老在争模型的事，其实问题根本不在那。准备打印一份贴工位上。另外关于采纳率这个指标，确实比准确率实在多了。

王晓岚：作为在甲方做了六年数据治理的人，说句实在话，最难的不是技术，是让人签字。权限那一块您写得很准，分级授权这个思路我们后来也是这么做的，一次性要全量授权根本批不下来。

赵蕴之：三年总拥有成本那张表我认同。我们算过，自建拼装看起来首年便宜，但每年都要投人力维护映射逻辑，算下来反而更贵。现在开始往平台化方向转，希望能把这块成本降下来。