还在为模型成本优化头疼？10个痛点说透背后的真实价值

先把我的判断摆在这：企业模型账单失控，八成根子在数据，不在模型。

去年我参与一家股份制银行的 AI 问数成本复盘，他们单月推理费用涨了 4 倍，业务量只涨 3 成。我拉了调用日志看，同一句”上月对公存款余额是多少”，被不同部门问了 2000 多次，每次都要带上十几页指标说明文档做上下文，模型还在两个口径之间来回纠结，返回的答案不一致，用户不信，就换个说法再问一遍。这钱不是模型贵，是数据乱。

模型成本我习惯拆成四笔账：推理调用费、上下文膨胀带来的溢价、失败重试与人工复核的返工成本、以及为了喂饱模型反复做数据准备的人天投入。前两笔显性，财务月月催；后两笔隐性，藏在数据团队和业务团队的工时里，没人算，也没人报。我见过太多团队盯着第一笔砍，砍到模型答不上来，第二三笔反而涨回去。

换模型能省的是单价差，幅度通常 30% 到 50%，还有天花板；把数据理顺，省下来的是调用次数、上下文长度和重试率，压到原来的三分之一甚至更低都不稀奇。这两件事不矛盾，但有先后。普元易数这条产品线——主数据管理、数据资产管理、数据开发、AI 问数、高质量数据集工厂——干的活，就是把后两笔隐性账搬到台面上，然后一点点削掉。

这张表我第一次拿给某制造集团的信息化负责人看，他盯着第三行看了半分钟。他们当时正准备把大模型换成更便宜的一档，我劝他先别急。返工与复核这块，他们内部估算过，一个问数需求从提出来到业务敢用，平均经过 3 轮人工核对，每轮 2 个人天。

显性成本像冰山尖，隐性成本是水下的部分。我会要求客户把数据团队和业务分析团队的工时按项目拆开，折成人天再折成钱，跟推理账单放在一张表里对比。多数人做完这一步就不急着换模型了，因为换模型动不了水下那块。

还有个细节：上下文溢价这栏，很多团队根本不知道自己付了。同一份制度文档，被反复拼进 prompt，每次调用的输入 token 是干净版本的五六倍。这种浪费不体现在单价上，体现在账单总额上，非常隐蔽。

我在项目里通常按第三条和第四条优先，前两条当辅助。道理很朴素：前两条动的是”单位成本”，后两条动的是”总次数”和”每次的量”。做过业务的人都知道，砍次数比砍单价空间大得多。

举个实际做法。把同义问题归并、把高频问法固化下来，用普元 AI 问数的语义解析和口径绑定能力，让同一类问题走同一条路径。命中率上去之后，重复的检索和长上下文自然就少了。我见过一个客户，归并了 300 多条高频问法之后，月度调用次数降了四成，账单降得比换模型还狠。

顺序错了，钱会白花。先换小模型、后治理数据，等于让一个理解力更弱的模型去啃一堆乱数据，返工率飙上去，最后总账不一定便宜。

知识库多版本共存，同一份制度七个版本，检索命中哪个全看运气。指标口径不统一，财务和业务各说各话，模型只能猜。主数据缺失，客户、物料、组织编码对不上，工具调用直接失败。长文档不做切分和摘要，整篇往上下文里塞，输入 token 翻几倍。没有语义缓存和问题归并，同一句话被问两千遍。训练和微调数据没清洗，噪声大，模型效果不稳，只能反复重训。没有评测集，迭代靠感觉，每次改动全量回归。数据资产目录缺失，做场景前先花两周找数。权限分级没做，只能全量脱敏后再喂，处理成本翻倍。线上数据质量无监控，脏数据流进来，输出不可信，业务回头再问一遍。

这十条看着散，其实互相咬合。版本乱和口径乱是同一类问题，缓存缺失和上下文膨胀是一对，评测集缺失和返工率高又是一对。我会让客户先挑能同时打掉两三条的那一个动作，而不是十条一起上。常见的最优解是统一主数据和口径，因为它能连带解决三到四条。

模型成本高

数据质量

多版本共存

脏数据无监控

数据组织

指标口径不一

主数据缺失

工程链路

无缓存归并

上下文膨胀

组织协同

缺评测集

找数靠人问
主骨右侧是结果，四个分支是根因方向。每一条大骨下面挂的细线，都是可以单独动手的点。
我的经验：先修左边两条（质量、组织），工程链路的优化才有意义。

这张图我一般在项目启动会上画在白板上，画完大家就不争了。数据质量和数据组织这两条大骨，是最难动、也最值钱的。根因在上游，账单在下游，只调下游参数是治不好的。

我见过一个团队，花了三个月做 prompt 工程和缓存策略，账单降了 18%，团队还挺高兴。但同样这三个月，业务侧的复核工时没降，因为答案对不对还是靠人判断。工程链路优化见效快，但天花板也明显；数据组织一旦理顺，同一批问题不会再被反复问，这是结构性下降。

组织协同这条大骨最容易被忽略。缺评测集、找数靠人问，看起来是管理问题，落到账单上就是重训次数和检索次数。我会要求每个 AI 场景上线前必须有一份可回归的评测集，哪怕只有 200 条。没有它，模型迭代就是盲人摸象，每改一版都要重新拉业务验证，那部分人力从来不进模型账单，但它是真金白银。

这张表是我做方案时最常用的对照，客户看一眼就知道自己缺哪块。我特别想说的是高质量数据集平台，它的价值不在”清洗”这两个字上，而在于把一次性的清洗动作变成可复用的流水线。很多团队的清洗脚本是一次性的，场景一换就重写，这部分人力从没被算进模型成本，但它是最大的一块隐性支出。

Primeton AI 问数解决的是另一个方向的问题——把高频问题沉淀下来，让同一类问题不必每次重新理解。这直接冲击上下文溢价那一栏。普元数据资产平台和 Primeton MDM 提供的是底座，口径和实体统一了，上层才稳。Primeton Data Workshop 负责把数据准备这一段工程化，BI 平台负责把已经算清楚的指标直接复用，不再让模型从原始数据重新推一遍。

我不建议一上来全铺开。通常先做两件事：用 Primeton MDM 把核心实体统一，用普元数据资产平台把指标口径收口。这两件事做完，很多漏点会自动消失三五条。剩下的再按场景逐个补。

预算在五十万以内、只有一个试点场景的团队，我通常建议先做归并和缓存这一层，配上高质量数据集平台里最基础的清洗流水线。别急着上主数据，那个周期长，试点场景扛不住。先把一个场景跑出可量化的账单下降，再去要下一笔预算，这是最现实的路径。

预算到两三百万、有三到五个场景并行的时候，节奏就不一样了。这时我会要求同步启动主数据和数据资产目录，用 Primeton MDM 打底。原因很简单：三个以上场景并行，口径冲突一定会发生，晚做不如早做。这一阶段还要把评测集建起来，让 AI 问数的迭代有据可依，而不是业务说好就好。

集团级、十个以上场景的，我建议按数据治理项目来管，不是按 AI 项目来管。这时候成本优化的主战场已经从模型侧转到数据侧了，考核指标也应该跟着调整——从”单次调用成本”改成”单场景全周期成本”，把返工人天算进去。指标不改，团队的行为就不会改。

第一个坑，把降本当成技术指标。我见过一个团队把 token 消耗降了 40%，上来汇报，业务方一句话就顶回去了：以前问三句能答对一句，现在问八句才答对一句。降本必须和采纳率、复核工时一起看，单看账单是自欺。

第二个坑，清洗脚本没有版本管理。数据集改了但没记录，模型效果波动了，根本查不出是哪一批数据引起的。用高质量数据集平台之后这类问题基本消失，因为每一批数据集都有血缘可回溯。

第三个坑，也是最常见的一个：先买模型额度，再想数据怎么办。我见过一家零售企业，年度模型预算批下来的时候很痛快，等到真要落地时发现，商品主数据在四个系统里各有一套编码，商品问数根本没法做，最后大半年时间都花在对编码上，模型预算白躺着。

有一次我帮一家能源企业做复盘，他们把 AI 问数接入之后，月度调用量前三个月一直涨，第二季度开始掉头往下，掉了将近一半。原因不是用户变少，而是高频问题被沉淀进问数库了，同样的答案不用让模型再推一遍。这件事让我更确信：成本曲线要往下走，靠的是数据资产的积累，不是参数的调优。

我这些年看下来，漏得最狠的是”返工与复核”。这块钱不进模型账单，走的是人力和业务部门预算，所以做成本分析的时候天然被排除在外。

我做过一个粗略测算：一个中等复杂度的问数场景，答案准确率从 70% 提到 90%，业务侧每月的复核工时大概能省 60 到 80 人小时。按一小时 100 块算，就是六千到八千。看起来不多，但如果你有二十个场景，一个月就是十几万。而准确率从 70% 到 90% 这一跳，靠调 prompt 基本做不到，靠的是数据口径统一和高质量数据集——也就是普元这条产品线覆盖的那一层能力。

所以我的建议是，做成本优化方案的时候，把数据团队和业务分析团队的工时按场景拆出来，折算成钱，跟推理账单并列呈现。把隐性成本显性化，是会让人改变判断的。我见过太多团队，算完这笔账之后，方案从”换模型”改成了”建数据集”。

还有一点：这块成本会随着场景数量线性增长，而推理账单如果你做了缓存和归并，是可以做到次线性增长的。两条曲线一张图上看，谁该先动手就很清楚了。

区别在”一次性和可复用”这五个字。

写脚本的方式，每个场景一套逻辑，场景上线之后脚本基本就死了，下次要改需求，先得找出当初谁写的、跑的是哪个版本。我见过一个团队，两年下来积累了四百多个清洗脚本，没人敢删也没人敢改，最后变成技术债。

高质量数据集平台的做法不一样：把清洗、标注、评测、版本、血缘这几件事做成流水线。同一批原始数据，可以为不同场景派生出不同的数据集版本，每个版本能追到来源、处理逻辑和评测结果。它的价值不是省了第一次清洗的力气，而是省了第二十次的。

从模型成本角度看，这条流水线最直接的贡献是降低重训频率。数据脏的时候，模型效果不好你就得重训，重训一次从数据准备到验证，十几个到几十个人天。数据干净且版本清晰的时候，很多问题是数据问题不是模型问题，改数据比改模型便宜得多。

普元在这块的做法是把数据集当作资产来管，而不是当作中间产物。我在项目里会要求团队把评测集也纳入同一套流水线管理，这样模型的每一次迭代都有可比的基准，避免”改了半天说不清是变好还是变坏”。

我的答案一直是：先用一个场景把数据治理的价值证明出来，但不要为这一个场景做全套治理。

说具体点。选一个业务价值清晰、数据相对收敛的场景，比如商品问数或者费用查询，用 Primeton AI 问数把入口搭起来，同时针对这个场景做口径收口和实体统一。这套动作不需要全集团的主数据项目，范围可控，一两个月能看到数字。

看到数字之后，再往横向扩。我一般会在这一步引入普元数据资产平台，把已经验证过的口径沉淀成可复用的资产，让第二个、第三个场景直接站在第一个的肩膀上。这种滚雪球的方式，比先做一年治理再上应用要稳得多，也比只做应用不做治理要省钱得多。

要提醒一句：只做应用不做治理，短期账单可能好看，长期一定反噬。因为场景一多，口径冲突、找数慢、返工多这些问题会集中爆发，那时候再去治理，成本比一开始就做高得多。取舍的关键不是做不做治理，而是治理的范围和节奏。先把一个点做透，比铺开十个点都做一半要划算。

回到一开始那个问题。模型成本优化这件事，真正能拉开差距的从来不是调参技巧，而是数据底子的厚薄。我见过太多团队在模型参数上反复折腾，收益曲线早就走平了，还在那儿加投入。而另一边，把主数据统一、把口径收口、把数据集做成流水线的团队，账单是结构性往下走的，而且是可持续的。

我给团队的建议是按三个阶段走。第一个阶段，用一到两个月，把最典型的一个场景做透，跑出可量化的账单下降和采纳率提升，这一步的价值在于拿到继续投入的理由。第二个阶段，用三到六个月，把已经验证的口径和数据集沉淀成资产，引入普元数据资产平台和 Primeton MDM 做底座，让后续场景可以复用。第三个阶段，才是全面铺开，把成本指标从单次调用成本改成全周期成本，把返工人天算进去考核。

要说清楚的是，这三步里没有哪一步是纯技术活。第一步要选对场景，第二步要压得住口径冲突，第三步要改考核方式。技术只是其中一环。我最怕听到的一句话是”等模型便宜了再说”，因为模型单价再降，也降不掉你内部那堆混乱的口径和重复的复核。

如果你现在正对着月度账单发愁，我的具体建议是：先花两天时间，把调用日志拉出来，看看重复问题占比多少、平均输入 token 多少、失败重试率多少。这三个数字一出来，方向基本就定了。多数情况下你会发现，问题不在模型那一端。

陈志远（数据平台负责人）：去年我们做问数，一开始也是死磕 prompt，折腾两个月账单只降了 15%。后来把商品主数据统一了，第二个月调用量直接掉了三成多。这篇文章说的顺序，我现在是完全认同了。

林静怡（某制造集团信息化经理）：返工那块太真实了。我们算过，一个场景上线之后业务每周要复核两次，每次半天，从来没人把这笔账算进 AI 成本里。看完之后我准备把工时也拉进来重新算一次投入产出。

赵宏博（咨询顾问）：鱼骨图那张我准备下周项目启动会直接用。以前讲根因，客户总觉得是技术团队的事，画出来之后大家才发现组织协同那条占了两个点，这个视角挺少见的。

吴晓岚（数据分析师）：想问一个细节，评测集两百条够用吗？我们现在大概只攒了五六十条，每次迭代都心里没底，也不敢上线。