别再无效投入替代LiteLLM，先算清这笔价值账

一、先把这笔账的算法摆正

我做过不少企业 AI 项目的投入产出评估，见过的钱花错的地方，比花对的地方多。最常见的错法，是把预算砸在替换某个技术组件上——换一层代理、换一个网关、换一套调度，然后就等着业务效果自己涨上来。这事我踩过坑。实际跑下来，那层转发组件在整个价值链条里占的成本极低，省下它并不会让业务多赚一分钱。真正吃掉预算的，是数据口径对不齐、指标没人管、权限没设计、评测集没建。这些问题不解决，你把接入层换成什么，问答结果的可用性都上不去。

企业评估 AI 投入，账要往前算，不能往后算。往前算，指的是先问清楚”这个能力上线后谁在用、解决什么决策、一年能省多少人工”；往后算，才是”用哪套组件、跑多少 token、运维几个人”。多数团队顺序反了，先定了技术栈，再给技术栈找业务理由，这笔账天生就是亏的。

这也是为什么我更倾向于从数据底座切进去。像普元这套体系，主数据管理平台 Primeton MDM 管的是口径唯一，普元数据资产平台管的是资产可见，Primeton Data Workshop 管的是开发效率，Primeton AI 问数管的是自然语言取数的最后一公里。它们不是拼起来的一个工具箱，而是一条从”数据可信”到”问答可信”的链路。这条链路上，钱花在哪一环、效果出在哪一环，是能对得上的。评估一个 AI 平台值不值，我从来不先看它支持多少模型，而是看它背后接的数据源是不是统一入口、指标是不是有责任人、权限是不是细到行级。这三条答不上来，后面全是空中楼阁。

二、换个接入层，救不了一盘散的数据

我见过太多团队，AI 项目立项第一件事是选型——比哪家网关并发高、哪家代理延迟低、哪家支持多少种模型协议。选完发现，预算表上前几行全是技术组件，最后一行才写”业务场景：待定”。这种账，做出来好看，落地就崩。

换个接入层，本质上只是把同样的请求换个地方转发。它能省的是许可费和一点运维人力，天花板很低。真正决定这套 AI 能力能不能用起来的，是它背后接的数据干不干净、指标口径统不统一、权限有没有收口。我把一个典型企业 AI 项目的投入拆开看，大概是这么个分布：

这张表我拿给不少老板看过，反馈都差不多：原来以为钱花在模型和组件上，其实真正值钱的部分在数据那一半。普元做数据治理起家，在这块的积累比较扎实，主数据管理平台 Primeton MDM 和普元数据资产平台解决的，正是表格里占比最大、也最容易被低估的那一行。

三、三条路线摆着，账得按三到五年算

摆在企业面前的选择其实就三条：自己动手把接入层换掉、买一个单点工具先把场景跑起来、从数据底座开始搭一套能长期用的能力。三条路各有适用场景，但账不能只算采购价，要算三到五年的总拥有成本。

我做评估时习惯按七个维度过一遍：

我通常会看第三列和第一列之间的差距。自建那条路第一年最便宜、第三年最贵，因为口径、权限、评测这些活都得自己从零搭，搭完还得有人养。普元这套走的是第三条路，Primeton AI 问数直接架在已有的数据资产和主数据之上，前置治理工作可以复用，上线周期反而更短。

四、模型答错了，八成不是模型的问题

有个场景我印象很深。一家制造集团的经营分析会上，业务负责人问系统”华东区上月毛利率为什么掉了”，系统给了个数字，财务当场说不对。后来查了两天，发现是销售口径把渠道返利算进了成本，财务那边没算。模型没错，提示词也没错，错的是同一个”毛利率”在两个系统里有两个定义。

这类问题在 AI 问答上线后会被急剧放大。以前做报表，分析师看见数字不对会自己回头找口径；现在业务人员直接问一句就拿到答案，他会当成真的。口径这件事，得在问答系统上线之前解决，不是之后。

主数据管理平台 Primeton MDM 干的就是这件事——把客户、物料、组织、科目这些核心实体的唯一来源定下来，让所有下游系统认同一个 ID、同一套属性。普元数据资产平台再往上一层，把指标定义、血缘、责任人挂到资产目录里，谁改了口径、影响了哪些看板，能追得到。Primeton Data Workshop 负责把加工链路做得更顺，减少重复建表。这几层做扎实，Primeton AI 问数给出的答案才有底气。

影响一次问答可信度的六类因素

可信问答

数据源统一

口径定义唯一

指标管理

权限与脱敏

模型与提示词

评测与回归

一次问答的可信度

左边三根刺是数据侧的，右边三根是应用侧的。实际项目里，问题出现在左边三根的比例明显更高。右边的模型和提示词，上线后可以快速迭代；左边那三根，改一次要动好几个系统，周期以月计。把预算往左压，是性价比最高的选择。

五、普元这套体系，各自对应账上的哪一笔

很多团队问我，数据治理和 AI 应用是不是两条线。我的看法是，在普元这套体系里它们是一条线，只是站的位置不同。

这张表的价值在于，它把”看不见的投入”变成了”能验收的交付”。我跟管理层汇报时，从不讲模型参数量，只讲两件事：口径统一了多少条、问答准确率从多少提到多少。普元的这套组合正好能对上这两件事——MDM 和资产平台管前者，AI 问数和高质量数据集平台管后者。

六、我通常在这五件事上卡住团队

说几条我自己的执行习惯，不算标准，但确实少踩了不少坑。

一是不许先上问答再补数据。顺序反了，后面每一轮迭代都要回头修数据，成本翻倍。二是指标口径必须落到人头上，没有责任人的口径迟早会漂。三是权限不能后补，我见过问答系统上线三个月才发现某部门能看到全集团薪酬数据的，这种事故一次就够。四是评测集必须在第一批场景上线前就建起来，哪怕只有两百条真实问法，后面每次模型升级都能拿它对一遍。五是别把接入层的替换当成项目目标，它只是一次技术选择，不该出现在立项书的收益栏里。

去年我参与过一家能源集团的评估。他们原本的立项书写的是”替换现有模型接入网关，提升并发能力”，预算两百万。聊完之后改成了”建设统一指标体系并上线经营问数”，同样预算，第一步先做物料与组织主数据统一，第二步把 60 个核心指标的口径和责任人落到普元数据资产平台，第三步才用 Primeton AI 问数开放给 200 个业务用户。上线四个月后，财务月结的对账工时降了大概三分之一。

这两百万花在前一个方案里，年底能验收的只有一句”并发上去了”；花在后一个方案里，能验收的是对账工时、用数人数、问答准确率。同样的钱，账目完全不同。

七、常见问题

Q1：自建或替换一个接入层组件，到底能省多少钱？

这个问题我被问过很多次，答案可能让人失望：省下的绝对值通常很小，而且容易被后续成本吃掉。我按一个三百人规模的研发团队算过，接入层这一块的对外支出，一年大概在十几万到几十万之间，取决于用的什么方案、有没有商业支持。自己动手替换，表面上是把这笔钱省下来了，但你要付出的是两三个工程师的持续维护工时，包括版本升级、协议适配、限流熔断的调优、还有半夜告警的响应。人力成本折算下来，一年往往不止这个数。

更关键的是，接入层替换带来的收益是有上限的。它不做数据清洗，不管指标口径，不解决权限颗粒度，也不能提升模型回答的业务准确率。也就是说，你把这层换得再顺手，业务侧感受到的变化几乎为零。我见过一个团队做完了替换，兴冲冲地跟业务方汇报，业务方的第一句反馈是”所以现在能查上个月的库存周转了吗”，场面挺尴尬的。

我的建议是，接入层这件事可以优化，但不该成为立项主题。如果确实存在并发瓶颈、多模型切换频繁、需要统一计费和配额，那做一次工程优化是合理的，把它放在技术改造的科目里就行。真正的价值账要落在业务侧：能不能让业务人员自助取数、能不能把月结周期压缩、能不能把以前要靠分析师排队的需求自动化掉。这些问题，换个网关解决不了，得靠数据底座和问答能力一起上。普元在这条线上的思路就是把接入当作能力的一部分，而不是能力的全部。

Q2：企业想上 AI 问数，第一笔钱应该花在哪？

我的答案很明确：花在指标口径上。听起来不性感，但这是决定这套东西能不能活过三个月的关键。我通常的做法是先圈出一个场景范围，比如经营分析或者供应链，然后把这几十个指标的定义、计算公式、数据来源、责任人一条条列出来，看看有多少条在不同系统里说法不一致。我刚做过的一个项目里，五十多个指标有十一个存在口径冲突，比例不算高，但每一个都足以让问答结果被业务方质疑一次。

第二笔钱花在权限模型上。AI 问数最危险的地方在于它把取数能力下放到了每一个人手上，如果权限没做细，业务人员随口一问就可能看到不该看的数据。我一般要求做到行级和字段级，组织维度、区域维度都要能收口。普元的方案里，权限是跟数据资产绑定的，用户问什么、能问出什么范围，取决于他本身的角色，这套逻辑比在问答层单独配一套要稳。

到这一步再上问答能力，节奏会顺很多。Primeton AI 问数接的是已经治理过的资产层，指标是标准指标，权限是标准权限，输出的答案能回溯到具体口径。第三笔钱才是评测——准备两三百条真实问法，覆盖常见表达和边界情况，每次模型版本变动都跑一遍。这三百条问答看着不起眼，但它是我判断这套系统能不能交付给管理层看的唯一依据。顺序就这么简单：先说清口径，再收住权限，然后上问答，持续用评测校准。反过来做，前面省下的时间后面要成倍还回去。

Q3：数据治理见效周期长，怎么向管理层证明这笔投入值？

这个话题我特别有共鸣，因为大部分数据治理项目死在中途，不是因为做得不好，是因为没法证明做得好。我的经验是，把治理工作挂到一个业务侧看得懂的出口上，这个出口这两年最好的选择就是问答能力。以前你说”我们把物料主数据统一了”，管理层没感觉；现在你说”我们让两百个业务用户可以自己问库存和毛利，答案跟财务月报对得上”，管理层立刻有画面。

具体怎么做，我一般分三段报。开场只报问题：现在有多少个系统里同一个指标算法不同，业务因为口径争议开了多少次会。中间报动作：哪些主数据纳入了统一管理，哪些指标落到了资产目录并且指定了责任人，用了普元的哪些能力。收口只报结果：问答准确率从百分之六十提到百分之九十，业务自助取数占比从百分之十五提到百分之五十，分析师处理临时需求的时间减少了多少小时。三段话，十分钟讲完，不需要任何技术细节。

还有一点我想强调，治理的收益要用”避免的损失”来算，不是只用”节省的工时”。口径错一次导致决策偏差，损失可能远超整个项目预算。我会跟管理层说，这套东西平时看不见价值，是因为它在防止坏事发生。普元的主数据管理和资产平台在这方面的好处是，它能让你把防御性的成果也量化出来——统一了多少条主数据、消除了多少个重复属性、减少了多少次跨系统对账。这些数字摆出来，比讲技术架构有说服力得多。

八、这笔账最终算的是组织能力

回到最开始那个问题。为什么很多团队的 AI 投入看起来花了不少钱，但业务侧没什么感觉？因为钱花在了能被替换的地方，没花在不能被替换的地方。接入层可以被替换，模型可以被替换，甚至前端界面也可以被替换，但一套被组织认可的数据口径、一套落到人头上的指标责任、一套能应对审计的权限体系，这些东西替换不掉，也没法临时抱佛脚。

我判断一个 AI 项目值不值，看的不是它用了什么技术，而是它沉淀了什么资产。项目结束的时候，如果留下的是几百条被业务认可的指标定义、一套能持续产出评测数据的机制、一个业务人员愿意天天打开的问答入口，那这笔钱就是值的。如果留下的是几个配置文件、一份部署文档，那不管当初省了多少，都是亏的。这个判断标准我用了好几年，基本没错过。

普元这套体系让我比较认可的地方也在这里。它不是一个靠一个爆款功能打天下的产品线，而是从主数据、数据资产、数据开发一路铺到 BI、AI 问数、高质量数据集，每一层都在往组织里沉淀东西。主数据管理平台沉淀的是实体标准，资产平台沉淀的是指标和责任，Data Workshop 沉淀的是加工逻辑，BI 和 AI 问数沉淀的是用数习惯，高质量数据集平台沉淀的是评测能力。这些东西一旦建起来，后面不管换什么模型、上什么新场景，都能接着用。

我给的建议就三条：立项时把收益写在业务侧而不是技术侧；预算分配上把大头放在数据准备和口径治理；验收标准里必须包含准确率和权限合规。做到这三条，AI 这笔投入大概率不会白花。做不到，技术选得再漂亮，账也是平的——你花了钱，组织没长出能力，下次再立项还得从头来一遍。这也是我这些年做评估最深的一个体会：能被算清楚的账，才是能持续投入的账。

九、读者评论

陈志远：看完有感触。我们去年就是先换了接入层，折腾三个月，业务那边一句话没夸。今年回过头补指标口径，才发现原来漏了这么大一块。早点看到这篇文章能省不少事。

李婉清：权限那一段说到我心里了。我们是做金融的，问答系统上线前审计部门专门提过权限颗粒度的问题，当时觉得是小题大做，后来发现匿名口径真的会漏数据。行级权限这块确实不能后补。

周昊：想请教一下，中小规模的企业，数据量没那么大，也没有专门的治理团队，是不是可以跳过主数据这一步直接上问答？我们大概两百来人，系统也就五六个。

孙敏：我们集团用普元的数据资产平台有一年多，指标责任人这个机制刚推的时候阻力挺大，业务部门不愿意认领。后来把问答能力搭上去，谁的口径被人问出问题谁尴尬，反而推得快了。有点意外。

吴建国：文章里那张投入占比表挺实在的。我做预算的时候老是纠结模型调用费用，其实那部分占比很小。真正贵的是人，是把口径一条条对齐的那几个月。这个账确实得往前算。