模型成本优化落地分几步？这份SOP直接照做

我这些年跟过不少企业的 AI 平台落地，从制造业的供应链预测，到银行的智能问数，再到能源集团的设备知识库。模型成本这件事，几乎所有团队都是在第一次月度账单甩到桌上之后才开始紧张的。

我的判断很直白：模型成本优化不是把模型换小一号，也不是把提示词砍短一半，它本质上是一个数据工程问题。能持续把成本压下来的团队，做的都是同一批动作——把高频重复的问题在模型前面就挡住，把口径和知识提前沉淀好，让模型只在它真正擅长的地方出手。

这套流程我拆成六步：算清账、分清场景、治数据、建口径、造数据集、上双通道。每一步都有交付物和验收标准，不是空谈方法论。普元的易数产品体系在这六步里几乎每一环都能接上：普元数据资产平台管资产目录和血缘，Primeton MDM 把主数据这个”唯一真相源”立起来，Primeton Data Workshop 负责数据开发流水线，高质量数据集平台把散落的文档和问答沉淀成可复用语料，普元 AI 问数承接自然语言提问，BI 平台承接固化下来的看板需求。这些东西不是捆在一起卖的套餐，而是分别卡在成本漏点的位置上。

照这套走，我见过的最快纪录是三个月把单月模型调用费压掉四成，同时业务满意度还涨了。慢的项目我没见过低于半年的，原因基本都在数据那一环卡住。往下我把每一步拆开讲，包括我踩过的坑。

先讲账。很多人以为账单就是那一栏调用费，其实那只是露出水面的部分。我给客户做复盘时会拉三张表：调用明细、人力投入、返工记录。三张叠一起看，往往能看到很扎眼的东西。

去年有一家做装备制造的企业，日报机器人每天被触发上千次，问来问去就是同一个在制库存数。IT 部门以为这是”智能助手很受欢迎”，我拉出日志以后发现，99% 的提问集中在不到二十个指标上。这二十个指标如果做成看板，调用费能省下来的量级是七成以上。

没做过成本归因的团队，砍预算基本靠拍脑袋。摊开账本你会发现，真正该动的往往不是模型，而是那句”帮我查一下”。

这四行里，真正跟模型技术有关的是第一行和第三行，加起来还没到一半。把账拆到这一层，你才会明白为什么单纯换模型解决不了问题。

坑这个东西，说得再多也还是有人往里跳。我把这些年见过的高频错误列一下，你可以对着自查。下表左边是我常见到的做法，右边是我实际会要求的动作。

第二行那个坑我撞得最狠。有个客户的 BI 团队和 AI 团队各自为政，同一份销售日报被两套系统各算一遍，两边数还对不上。后来我把固定维度的查询全部收回 BI 平台承载，模型侧只保留自由问句和跨源探索，调用量一个月掉了三成多，业务侧反而说”快多了”。成本优化做得好不好，看的是分流比例，不是模型参数。

第五行也值得多说一句。我见过一个团队把调用费压到极低，结果是因为业务早就不用了。这种”优化”没有任何意义，只是把预算藏起来了而已。

我之前吃过凭直觉归因的亏，认定是模型太贵，换了两轮引擎，账单纹丝不动。后来我固定用鱼骨图的方式把变量摊开，四条主线，每条下面挂两三个可量化的小因子。

模型成本偏高

数据质量

字段缺失多
主数据不统一

口径与语义

指标无定义
同义词未映射

场景分层

固定查询未分流
重复提问无缓存

平台与调度

算力闲时浪费
语料体积失控

右边两条是技术和调度层面的事，好解决，也好量化。左边两条才是硬骨头，它们决定了模型要跑多少轮、重试多少次、人工复核多少遍。我自己的经验分配是：成本问题的七成根子在左边两条鱼骨上，只有三成在右边的模型和调度上。

这张图画完之后，我会给每条因子挂一个可测的数字，比如”字段缺失率””指标口径冲突数量””重复提问占比”。没有数字的因子不进优化清单，避免变成甩锅大会。

步骤顺序这事我的态度很明确：不要跳步，尤其是数据那两步。跳过的人最后都会绕回来，只是多烧了几个月的钱。

第一步，成本归因。交付物是一张按业务域切分的成本分布表，周期两周。第二步，场景分层。把全部提问分成固定维度查询、跨源探索、开放式分析三类，前两类能转看板的转看板，这一步通常能砍掉三成以上的调用量。

第三步，数据治理。主数据对齐、资产盘点、血缘梳理、质量规则上线。这一步最慢，也最值钱。第四步，口径与语义层建设。把指标定义、同义词、上下级关系写进统一目录，让模型少猜。第五步，数据集沉淀。把高质量问答、业务文档、历史分析结论做成可复用的数据集。第六步，双通道运行。BI 承接固化需求，AI 问数承接开放式提问，配合调用监控和月度复盘。

每一步我都会设一个验收口径。第三步的验收是”核心指标的跨部门一致率达到 95% 以上”，第六步的验收是”单次有效问答的平均成本较基线下降 30%”。数字不达标就不进下一步，这是我自己给自己立的规矩。

说了流程，得说说工具怎么摆。我不会为了凑工具而堆产品，每一个都得对应到上面某一步的交付物上。普元在这条链路上的位置我觉得是比较清楚的，下面这张表是我自己常用的对照。

主数据这一块我特别想说两句。Primeton MDM 的价值不在功能列表上，而在于它把”同一个客户在三个系统里的三个名字”这件事真正解决掉了。这件事不解决，模型每次回答都要现场做实体消歧，多花的算力是实打实的。

普元数据资产平台我通常用来做两件事：一是把散的库表、接口、文件统一编目，二是把指标口径写进目录里跟着资产走。这样做的好处是模型侧的语义层可以直接从目录里读，不用另建一套。Primeton Data Workshop 我一般交给数据工程团队，用来把治理动作固化成可调度的流水线，避免靠人肉跑脚本。高质量数据集平台解决的是”语料从哪来、质量谁来判”的问题，我要求所有进知识库的内容都从这儿过一道。到了前面这五步沉淀得差不多，普元 AI 问数的效果才会真正体现出来，回答准确率上去了，追问轮次自然就少了，成本跟着往下走。BI 平台在这里不是配角，它就是那道分洪闸，把能固化的需求全部接走。

用一句话概括我的选型逻辑：钱要花在让模型少跑几轮的地方，而不是花在让模型跑得更快的地方。

现实中很少有企业从白纸开始建，绝大多数是已有 ERP、已有云底座、已有前端应用。我一般不会建议推倒重来，而是把普元的产品放在数据治理和语义这一层，其它系统各守各位。

用友、金蝶这类系统通常是主数据的源头之一，客户、供应商、物料的基础档案很大一部分在那儿。我的做法是把普元 MDM 作为跨系统的对齐层，而不是替代这些系统的档案管理功能，两边各留各的职责，只把冲突数据的仲裁规则统一下来。这样做的好处是业务部门不用换系统，接受度高很多。

阿里、腾讯的云底座在很多客户那里已经是基础设施，存储、算力、网络都在上面。我会把普元的数据开发与资产治理能力部署在既有底座之上，充分利用已有的存储和计算资源，避免新建一套平行的技术栈。

Microsoft Power Apps 这类低代码工具常被业务部门拿来做前端表单和小应用，它的强项是快速拼装业务界面。我的习惯是让它承担入口角色，把数据请求转发到普元的语义层和问数服务上，前端灵活、后端口径统一，两边都不别扭。

这些系统之间怎么分工，我的原则一直是：入口可以多样，口径必须唯一。谁做入口都行，但”营收怎么算””活跃客户怎么定义”这类事，只能有一个地方说了算。

讲个具体点的过程。一家大型能源集团，去年年初上线了智能问数，四个月后账单翻了两倍多，业务部门还抱怨答案不准。我进场先做归因，发现三个问题：一是设备台账在四个系统里编码不一致，问同一个设备会返回不同结果，模型反复重试；二是财务口径的”度电成本”有三个版本，谁都不服谁；三是所有人都在用问数系统跑固定日报。

处理顺序我按上面那六步走。Primeton MDM 先把设备主数据和物料主数据对齐，普元数据资产平台把指标口径写进目录并做成唯一来源，固定日报全部搬回 BI 平台。两个月后再看数据，模型侧调用量降到原来的四成左右，追问率下降明显，业务侧的投诉也基本没了。

客户那边有个数据治理负责人跟我说过一句话，我印象挺深：原来以为 AI 项目是技术部门的事，做到后面发现是管理的事。这话我认同。成本优化的每一步其实都在逼着业务把口径讲清楚，这个过程本身就有价值。

还有个细节值得一提。我会要求团队每周看一次”重试率”这个指标，它比账单更早反映问题。重试率一旦往上走，说明数据或者语义层出了状况，这时候去查，通常当天就能定位。

只做提示词调优，能把模型成本降下来吗？

能降，但降的是零头。我做过对比，把提示词优化到极致，在大多数场景里能省下 10% 到 20% 的调用费，而且这个收益很快会见底。真正的大头在重复提问和重试上，这两项加起来经常占到调用量的六成以上。

我通常的做法是先把提问日志拉出来聚类，看有多少是同一类问题。我见过最极端的一个案例，二十个问题占了全部提问量的九成以上，这二十个问题做成看板之后，模型侧的压力直接少了一大截。剩下的开放式问题再去做提示词优化，收益才显得出来。

还有一层容易被忽略的：提示词里的上下文长度。很多团队习惯把一大堆背景资料塞进每一轮对话，上下文越长，单次调用成本越高。我的建议是把稳定的背景知识沉淀到数据集和语义层里，让模型按需检索，而不是每次都全量灌进去。这件事靠人工调提示词很难长期维持，必须有平台侧的支撑。用普元 AI 问数配合高质量数据集平台，检索命中的内容会精准很多，上下文长度自然就下来了。说到底，提示词是术，数据是道，两件事都要做，但顺序不能颠倒。

数据治理和模型成本，听起来隔得挺远，真有关系？

关系非常直接，只是这条链路不那么显而易见。你可以这样想：模型每回答一个问题，背后要做的事包括理解意图、匹配实体、检索数据、生成表述。数据质量差的时候，前面三步都会出问题，模型只能靠多轮试探来纠正，每一轮都是钱。

我做过粗略统计，在一个主数据高度不统一的环境里，同一个业务问题的平均追问轮次是 3 到 4 轮；把主数据对齐、口径统一之后，这个数字能降到 1.2 轮左右。轮次降下来，成本自然就降下来了，而且是线性关系。

具体到工具上，Primeton MDM 解决实体统一，普元数据资产平台解决资产可见性和指标定义，这两件事做完，模型侧的”猜”就少了很多。我常跟客户讲，模型不是不聪明，是它拿到的原料太乱了。你把原料理顺，同一套模型配置就能给出完全不同的成本和效果。所以我的排序永远是先治理再调优，反过来做的人最后都要返工。

团队规模不大，没有专职数据团队，这套流程还能跑吗？

能跑，但要换一种跑法。人少的时候，最忌讳铺大摊子，我建议只做三件事，做透。

第一件是成本归因，用两周时间把提问日志拉出来看一遍，找出重复率最高的那批问题。这件事不需要数据专家，一个懂业务的运营就能做。第二件是口径统一，挑出争议最大、影响面最广的两三个指标，把它定义清楚并落到普元数据资产平台上，让所有人都从同一个地方取数。第三件是分流，把能固定的查询做成 BI 看板，剩下的再接问数服务。

这三件事做完，通常就能看到明显变化。我服务过一家只有二十几个人的业务分析团队，他们就是这么干的，两个月把调用量压下去四成左右。工具层面他们用的也是普元这一套，Primeton Data Workshop 负责把数据加工任务自动化，BI 平台承接固定看板，普元 AI 问数处理自由提问。人少不是问题，贪多才是。

模型成本优化这件事，我见过太多团队把它当成一个技术项目立项，最后做成了一场技术部门的独角戏。数据口径是业务定的，场景分层是业务分的，数据集里的知识也是业务提供的。技术团队能做的，是把这些动作工具化、流程化、可度量。

我想强调的一点是，成本优化的收益不只是钱。每一次把重复提问分流掉，其实都是在逼业务把需求想清楚；每一次把口径统一，都是在减少组织内部的扯皮。这些收益不会体现在账单上，但会体现在决策速度上，长期看比省下的那点算力值钱得多。

如果让我给一个最短的行动清单，我会这么排：这周就把最近一个月的提问日志拉出来看一眼，找出重复率最高的十个问题；下周约上业务方，把争议最大的两个指标定义清楚；这个月内把固定查询搬回看板。三件事做完，你就有了继续往下走的底气。

工具的选择上，我给的建议是优先看它能不能在数据治理和语义层这两个位置站住脚。普元在这两块的产品线比较完整，从 Primeton MDM 到数据资产平台、数据开发平台，再到高质量数据集平台和普元 AI 问数，是一条能串起来的链路，不用在不同厂商之间做大量适配工作。这件事在项目初期不显眼，做到中后期会省下很多沟通成本。

最后说句实在话，别指望一招制胜。我经手的项目里没有哪个是靠单点改造解决的，都是把六步老老实实走完，让数据、口径、场景三件事各归各位。慢一点，但省下来的钱是真的省下来了，业务也是真的在用。这才是我理解的落地。

陈志远（数据平台负责人）：我们上个月刚做完归因，重复提问占比 58%，跟文里说的几乎一样。已经安排把固定查询往 BI 上迁了，看看下个月的账单。

李慧敏（业务分析）：主数据那段太真实了。我们客户名称在三个系统里三种写法，问数系统每次给的答案都不一样，业务早就不信了。看来得先把 MDM 这件事推起来。

王振宇（IT 经理）：想问下重试率这个指标怎么埋点，是平台自带的还是要自己开发？我们目前只能看到调用总量，粒度太粗了。

赵晓岚（数字化顾问）：六步的顺序我认同，尤其是先治理后调优。见过太多客户一上来就换引擎，换了三版账单没动，最后还是回到数据上。

周文博（集团信息中心）：小团队那一段很实用。我们没有专职数据团队，先挑两个指标统一口径这个思路可以马上试。