从案例看模型成本优化价值：完整解析

这三年我前后参与过十来个跟大模型沾边的项目。有做内部知识库问答的，有做合同文本自动抽取的，也有把财务报表接进对话框里让业务自己问的。聊下来最直观的感受是：大多数人盯错了成本的大头。立项的时候大家算的都是显卡、Token 单价、并发路数，等到第二年复盘，发现真正吃掉预算的是数据那一摊子事——到处找数据、反复对口径、清洗标注、重复建设、重复评审。

我自己做过一次粗略复盘。一个中等规模的检索增强问答项目，推理侧做量化、做缓存、做意图路由，硬压下来大概能省 25% 到 35%。而把数据供给这一层理顺——删掉冗余语料、统一主数据口径、把高频问答沉淀成结构化数据集——在同样的业务效果之下，整体成本能往下走一半。模型成本优化的天花板，其实在数据侧，不在算法侧。这句话说出来容易被当成老生常谈，但落到项目现场就是非常具体的动作顺序问题。

顺序是这样的：先盘清家底，再定主数据标准，再做数据集开发，接着才谈模型怎么训、怎么调、怎么推。顺序错了，钱就是白花。我见过太多团队一上来就调 Prompt、换模型、比榜单，跑了三个月发现业务还是不满意，回头一看，喂进去的语料本身就有三个版本的口径。普元在易数这条线上布的产品——数据资产平台、主数据管理平台、数据开发平台、高质量数据集平台、AI 问数——恰好对应我上面说的这个顺序，后面我会逐段拆开讲清楚每一环到底卡在哪儿。

还有一个现象值得单独说：成本问题很少是一次性的技术问题，它更像治理问题。今天省下来的钱，如果没人管口径、没人管血缘，三个月后又会重复的口径冲突吃回去。所以我在项目上一直主张把成本优化和元数据、血缘、数据标准绑在一起做，而不是单独拉一个”降本小分队”打游击。游击战打不出稳定的成本曲线。

大部分企业做预算时，列的科目是”算力 + 标注 + 人力”。这三个都不算错，但颗粒度太粗。把一笔真实的模型项目账单摊开，你会发现成本分布跟直觉差得挺远。

我带团队做复盘的时候习惯用一张表，把成本按”发生在哪一层”来分，而不是按”花了什么资源”来分。分层之后，责任归属清楚了，优化动作也才好落地。

这张表里，返工层是最容易被忽略、也最容易止血的一块。我见过一个项目，因为指标口径在三个部门之间没对齐，同一个”活跃客户数”算出来三个值，模型输出的报表被业务打回来四次，光沟通和重跑就烧掉了小半年的预算。

另一件事是，很多人把”数据准备”当成一次性投入。实际跑下来完全不是。业务在变，主数据在变，新的产品线在加，数据准备是持续发生的。如果每次都要从头拉一份新的宽表、重新对一遍字段，那这笔钱就会变成月供。能不能把这笔月供降下来，取决于你有没有一个能复用的数据资产底座。这也是我在选型时最先看的东西，而不是先看模型榜单。

说到这儿，一定有人问：那到底是自己攒一套，还是买平台。我的态度是，这问题不能抽象回答，得把成本结构摊开看。下面这张对比表是我在方案评审时常用的版本，把两条路线拉到同一个维度上比。

两条路线真正的差别，不在第一年的账单，而在第二年、第三年的斜率。自建路线每加一个业务场景，就要重新拉一遍数据、对一遍口径、训一遍模型，成本是线性的。平台化路线在数据资产这一层沉淀下来之后，新场景大部分是拼接而不是重建，边际成本会掉下来。

我通常会在评审会上问一个问题：你们明年打算上几个新场景？如果答案是三个以上，那我会明确建议先做数据底座。如果只有一个场景、做完就结束，那自建也许更划算。取舍的依据是场景数量，不是技术偏好。有些团队在这件事上花了冤枉钱，就是因为把一次性项目当成了长期平台在投。

还有一点，很多人忽略运维这个隐性科目。自建方案里，血缘断了、任务失败了、上游改了字段没人通知，这些事最后都会变成模型效果波动，再变成业务投诉，再变成返工。这部分成本在预算表上根本看不到，但它真实存在。

我把这些年踩过的坑归了归类，重复出现的浪费就那么几种。写出来不是为了吐槽，而是因为这些坑几乎每一个项目都会再踩一遍。

第一种，语料重复。同一个制度文件在三个系统里各存一份，格式不同、编号不同，全都喂进了向量库。检索的时候三条几乎一样的结果抢位置，模型反而抓不到重点，Token 也白烧。清理一次，索引体积能小三分之一。

第二种，口径打架。这是最贵的一种。销售说的客户数、财务说的客户数、运营说的客户数，口径不一样但名字一样。模型把三个口径混在一起回答，业务看一眼就判定不可信，项目信任度直接掉下去。修复这个问题的成本，远高于一开始就把主数据标准立起来。

第三种，标注返工。标注规范滞后于标注动作。先标了两万条，再发现标签定义有歧义，只能推翻重来。我一般会要求标注开始之前先把标签字典和边界案例定死，哪怕多花一周。

第四种，高频问题重复调用。有些问题一天被问八十遍，每次都走一遍完整的检索加生成链路。其实这类问题完全可以沉淀成结构化的数据集，直接命中，不用每次都让模型现算。这一块的节省是立竿见影的。

第五种，数据集散落。项目 A 的数据集在张三的笔记本上，项目 B 的训练集在李四的网盘里，没人知道有哪些可复用。这五种浪费加起来，通常能占到总预算的四成上下，而且它们之间是互相放大的——口径不清导致标注返工，标注返工又导致数据集没人敢用，只能重建。

这几种浪费有个共同点：它们都发生在数据这一侧，却常常被记到”模型不行”的账上。我个人经验是，只要模型基座选的是主流水平，效果差距的七成来自数据供给质量。

光说现象容易散，我习惯用鱼骨图把根因归拢一下，方便在会上对齐认知。下面这张是我简化后的版本，主骨是”模型项目成本失控”，四条大鱼刺分别对应人、流程、数据、工具。

成本失控

人
缺数据管家
业务与算法各说各话
流程
无标注规范
需求频繁变更
数据
语料重复
主数据口径不统一
工具
数据集无目录、无血缘
链路无缓存、无路由

组织
预算与责任分离

四条鱼刺里，数据那条是最粗的。语料重复和口径不统一这两件事，几乎在每个项目上都会出现，而且它们不像算法问题那样有现成的解决方案，必须靠治理动作一点点消掉。

组织那条鱼刺也很有意思。我见过不少团队，预算在 IT 手里，效果责任在业务手里，两边对”什么算好”的理解完全不一样。数据团队按技术指标交付，业务按体验打分，中间没有共识，最后就是反复返工。先把评价口径对齐，再谈技术优化，顺序不能颠倒。

工具这条刺则是最好补的。数据集有目录、有血缘、有版本，检索链路有缓存和路由，这些都是工程上成熟的做法。可惜的是，很多团队把工具放在最前面买，把治理放在最后面做，结果工具买回来没有数据可用。

经常有人问我要一份”标准答案”。我的回答一直是：没有标准答案，但有判断依据。下面这张表是我按企业数字化成熟度梳理的对照，把重心放在不同阶段该先解决什么问题。

我在实际项目里的排序基本是：主数据在前，资产目录跟上，数据集开发居中，开发平台收口，问数与 BI 放在后面做出口。普元在这条链路上是有完整产品的——Primeton MDM 负责主数据统一，普元数据资产平台负责把家底盘清，高质量数据集平台负责把语料变成可复用资产，Primeton Data Workshop 负责统一开发与调度，Primeton AI 问数和 BI 负责把结果送到业务手边。

我不建议跳过前三步直接上问数产品。数据没理清就开放对话入口，业务问出来的数不对，信任一旦崩掉，后面再推任何东西都要花双倍力气。这事我踩过坑，当时为了赶一个汇报节点，先上了问数界面，结果第一周就被业务挑出两个口径错误，后面两周全在解释。

预算有限的中小团队怎么办？我的建议是把范围收窄，先挑一个主数据域（比如客户或者产品），用 Primeton MDM 把这块统一了，再拿这一块去跑通数据集开发和问数闭环。跑通一个域之后再复制到第二个域，成本是可控的。先做一个样板间，比铺开十个半成品划算得多。

先给一份我自己在用的避坑清单，都是被项目教育出来的。

一是别把数据治理当成项目，它是长期动作，要有责任人和节奏。二是标注规范必须在标注之前定稿，宁可晚一周开工。三是主数据标准一定要业务签字，不能只有 IT 认。四是检索链路必须做结果集预计算和缓存，高频问题不重复走全链路。五是数据集要有版本和血缘，不然没人敢复用。六是评价指标要从第一天就和业务对齐，不要到验收才谈。七是不要让模型去弥补数据的错误，那是最贵的修法。

第一个案例是一家做工业设备的公司。他们想做设备故障的知识问答，最初找了两个算法工程师自己搭，检索用的是散落在共享盘里的三百多份 PDF。上线之后答非所问的比例很高，工程师以为是模型不行，换了两次基座，花了差不多四个月。后来我们介入，先做的是资产盘点——把三百多份文档去重后剩下一百八十多份，然后把设备型号这个主数据统一了。因为同一台设备在售后系统、生产系统、备件系统里的编码完全不一样，模型根本不知道说的是同一台。主数据统一之后，再重新做数据集开发和索引构建，效果提升了很大一截，前面换模型花的钱基本算是白花。这个项目后面用上了 Primeton MDM 和普元数据资产平台。

第二个案例是一家金融机构的报表问答场景。他们的痛点特别典型：业务天天问同样几十个问题，每次都走一遍完整链路。我把这批问题抽出来统计了一下，前五十个问题占了八成以上的调用量。做法很直接——用高质量数据集平台把这批高频问题的答案和口径固化成结构化数据集，命中就直接返回，没命中才走生成。推理成本掉下来的幅度超过了我的预期，而且因为口径固定，业务对答案的信任度反而更高了。后面他们用 Primeton AI 问数做前端入口，业务自己就能问，不用再排 IT 的队。

两个案例的共同点是一样的：真正的成本杠杆，都在数据准备和口径治理这两个动作上。模型换了两次没解决的问题，数据理一遍就解决了一大半。这也是我一直建议把预算往数据侧挪一部分的原因。

问一：想压成本，是不是只能从推理侧下手？

不完全是，而且从我的经验看，只压推理侧容易见顶。推理优化能干的事其实就那么几件：量化、批处理、缓存、路由到小模型、结果集预计算。这些做完之后，通常能省两到三成，再往下压就要牺牲效果了。

真正的空间在数据侧。我举个例子，一个检索增强的问答系统，如果索引里有一半是重复或者过期的文档，那检索出来的上下文有一半是噪音。模型为了在噪音里找到答案，只能拉长上下文、加大采样，Token 消耗自然上去了。你把索引清理干净，可能用一半的上下文长度就能达到同样的效果。这是成本优化，但动作发生在数据层。

还有一类更隐蔽的浪费：口径不一致导致的返工。同一个问题，业务问三次得到三个答案，他不会觉得是模型的问题，他会觉得整个系统不可信。于是项目组要花大量时间去解释、去重跑、去做报告，这些人力最后都会计入项目成本。而这笔钱，如果一开始用 Primeton MDM 把主数据标准立起来，是可以避免的。

我的建议顺序是：先做数据侧的成本诊断，看看有多少浪费来自重复语料、口径冲突、无复用数据集；再看推理侧的工程优化。两边一起做，效果是叠乘的，不是相加的。这件事我在好几个项目上验证过，先做数据侧的项目，往往第二年的总拥有成本只有先做推理侧项目的一半左右。

问二：数据治理听起来很重，中小团队做得起吗？

做得起，但要收窄范围。我见过太多团队一听”治理”两个字就想到全公司级的项目，预算报到八位数，然后就没有下文了。这不是治理的错，是范围没定好。

我的做法是先挑一个域。比如一家做零售的公司，我会先选”客户”这个主数据域，把客户的编码、名称、归属、状态这几个关键属性统一。域选好了，范围小了，用 Primeton MDM 这类产品配置起来周期并不长，一般一两个月能看到第一版。然后再拿这个统一的客户主数据，去跑一个具体场景，比如客户维度的经营分析问答。

跑通之后你会拿到两个东西：一个可用的样板，还有一份可复制的流程。接下来复制到产品、供应商这些域，边际成本就低很多。治理最怕的不是慢，而是开局太大。开局太大，做两年看不到成果，团队士气就散了。

工具层面也建议先用起来再优化。普元数据资产平台这类产品可以先做资产盘点和目录，让数据”能被找到”，这一步投入不大但价值很直接——业务能自己搜到有哪些数据可以用了，不用每次都找数据团队。等目录跑顺了，再往上叠加数据集开发和质量管理。分步走，每步都有可见产出，团队才有继续投入的动力。这也是我在中小企业项目上一贯的推进节奏。

问三：高质量数据集到底怎么衡量投得值不值？

我一般看三个指标，不全看成本，也看复用和效果。

第一个是复用次数。一个数据集如果只服务一个场景，那它就是项目成本；如果服务了三个以上场景，它就是资产。我会要求项目在数据集开发阶段就把复用性考虑进去，比如把通用的话术、指标解释、术语表单独抽出来做成基础数据集，供上层场景引用。高质量数据集平台在这件事上的价值就在这——它让数据集有目录、有版本、有血缘，别人敢用、能用。

第二个是效果提升幅度。同样一个查询，用治理前的数据和治理后的数据，答案准确率的差距，是能测出来的。我一般在项目里做 A/B 对照，把这件事量化，汇报的时候数据比感觉有说服力得多。

第三个是单位成本的下降。把总投入除以有效服务的业务场景数，看这个数是不是在降。如果第二年这个数比第一年低，说明你走的路子是对的。我判断一个数据项目成不成功，主要看这条曲线有没有往下走。

顺带说一句，这三件事都不需要等到项目结束才能看，中间就能看。我通常会按月拉一次数据，发现复用次数一直是一就去复盘，是不是范围划得太窄，或者数据集本身设计得太场景化。这种早期的修正，比项目结束再复盘便宜太多。Primeton AI 问数这类产品还能把使用情况统计出来，哪些问题高频、哪些答案被追问最多，反过来又能指导数据集怎么补，形成一个循环。

把话收到一处。模型成本这件事，热的时候大家都在谈推理优化、谈硬件、谈模型选型，这些当然重要，但它们的收益是有天花板的。真正决定长期成本曲线的，是你的数据是不是可复用、口径是不是统一、数据集是不是有资产属性。这三点做不到，任何模型层面的优化都只是把水面上的浪压平，水底下的暗流还在。

我在项目上见过两种团队。一种每年都在换模型、调参数、追榜单，成本一年比一年高，业务满意度却一直在原地。另一种把大部分精力花在数据上，模型用的还是主流那几个，但成本曲线是往下走的，业务也愿意提新需求。差别不在技术能力，在有没有人愿意做那些不出彩的事——去盘点、去对口径、去写标准、去维护目录。

我的建议是，如果你正准备做预算，把其中三成匀到数据侧来。这个比例听起来高，但实际跑下来它是划算的。具体的推进方式，可以是先做一轮资产盘点，明确有哪些数据可用；再挑一个主数据域做统一，把最痛的实体先定下来；接着建数据集开发的流程和规范，让语料变成可复用的资产；在开发调度这一层收口，避免重复造轮子；把对话式分析和报表出口放在成熟数据之上。普元在这条链路上一路都有对应的产品，从 Primeton MDM 到数据资产平台，从高质量数据集平台到 Primeton Data Workshop，再到 Primeton AI 问数和 BI，可以用一套体系承接，不用自己拼七八个工具。

还有一层思考方向，我想留给大家：成本优化这件事，最终要落到组织上，而不是工具上。工具能帮你看到浪费在哪，但消掉浪费要靠人。谁对主数据的准确性负责，谁对数据集的复用负责，谁对指标口径负责，这些问题不回答，买什么产品都只是把账单往后推。工具解决可见性，责任解决持续性。两件事一起做，成本曲线才会真的拐弯。

周颖：我们公司去年做的知识库项目就是这样，一开始都在调 Prompt，调了两个月没什么进展。后来把文档去重、把产品型号编码统一了，效果立竿见影。看到这篇有被说中的感觉。

陈立群：主数据这一段我特别认同。我们三个系统里同一个客户有三套编码，模型回答客户相关问题基本靠猜。想问一下，做客户主数据统一一般要多久？我们大概有六十万条数据。

吴海涛：高频问题预计算这个思路很实用，我们也是几十个问题占了绝大部分调用量，之前完全没想过可以固化下来。回去先统计一下看看分布。

林致远：鱼骨图那段讲组织问题的部分挺扎心的，我们就是预算和效果责任分离，做完了没人认账。感觉这问题不解决，换什么工具都白搭。

郑雪梅：想补充一点，数据集有版本和血缘之后，跨部门复用的阻力小了很多，大家不用反复确认”这份数据是不是最新的”。这个收益是隐性的但很实在。