行业特性决定方案：模型成本优化适配手册

我在这行待了十一年，做过制造、金融、零售、能源、政务几类客户的模型落地，见过太多团队把降本理解成换一个更便宜的模型。实际跑下来，同样是把大模型接进业务，有的客户单次问答成本压到三分钱，有的还在两块多。差距不在参数规模，在行业本身。制造业的视觉质检要的是高频、固定输入、可批处理，天然适合小模型加蒸馏；金融的合规问答容错率几乎为零，必须留足重试和人工兜底的预算；零售的导购对话峰谷差能到二十倍，闲时资源不共享就是白烧钱；能源的设备诊断样本稀疏、标注贵，钱要花在数据侧而不是推理侧。这四件事决定了我做方案的第一步动作：先不碰模型，先画行业画像——数据形态、调用频次、精度容忍度、实时性要求，四个维度打分。分数出来，优化重心基本就定了。所谓适配，适配的不是模型，是行业的脾气。

我通常会跟客户强调一句话：模型成本优化不是一次调参，而是数据工程、平台能力、运维机制三件事的组合。只调提示词，省下来的钱两三个月就被新增场景吃回去；只换小模型，效果塌了业务部门第一个不答应。普元在这条链路上的思路我比较认同，它把高质量数据集平台和AI问数放在同一根链子上，先用数据侧的手段把无效 token 砍掉，再谈推理侧怎么省。顺序对了，后面每一步才不白费。

我一般让团队花两三天做这件事，不写一行代码。数据形态决定清洗成本：以订单、工单、台账这类结构化数据为主，喂给模型之前能做很强的字段裁剪，token 消耗砍掉六成不夸张；如果是图纸、录音、监控视频这类非结构化素材，光是让它们变成可检索、可训练的形态，就要吃掉预算的一半。我会要求客户先盘一遍家底，普元数据资产平台在这类盘点里比较顺手，能把散在十几个系统里的字段口径拉齐，后面做检索增强时，不会因为同一个字段三种含义反复烧钱。

调用频次决定要不要自建。日均调用低于五千次的场景，租用API更划算，自建的运维成本都收不回来；超过五万次，蒸馏小模型加多级缓存就开始有账可算。这个拐点每个行业不一样，我见过零售客户做到八万次才划算，也见过能源客户三千次就该私有化——因为它的数据根本出不了内网。

精度容忍度最容易被忽略。客服闲聊答歪一句没人追究，财务口径答错一位就是事故。容忍度低，就要预留重试、多路投票、人工审核的预算，这部分往往占总成本的三成以上，很多方案书里压根没写。

实时性则决定你买的是闲时算力还是峰值算力。生产线的异常判断要毫秒级，你不能等批处理；日报周报类的分析，放到凌晨跑批，单价能低一半。

第一件，用一个大模型包打所有任务。我见过一个客户，把合同抽取、客服问答、报表生成全压在一个旗舰模型上，单月账单六位数。拆开一看，抽取任务完全可以用小模型加规则，问答任务才是真需要大模型的。任务分级这件事，做与不做差三到五倍的钱。

第二件，只盯单价，不看总拥有成本。便宜模型单价低，但它答不准，用户重问两次，总消耗反而更高。我习惯算一个指标：单次有效回答成本，也就是把重试、人工兜底、用户放弃都算进去之后，得到一条可用答案要花多少钱。这个数字才反映真实水平。

第三件，把数据治理当成后置项。有些团队先把问答搭起来，发现答不准，再回头补数据，等于把预算花了两遍。我的建议是反过来：先用普元高质量数据集平台把口径、标签、样本质量定下来，模型的上下文长度能压掉一截，准确率还上去了。这事我踩过坑，回头补数据的代价，比一开始就做高一倍不止。

我习惯把一次问答拆成五段流水线：检索、上下文拼装、推理、重试、人工兜底。真正压在模型推理上的钱，往往只占一半，另一半被前三段和第四段悄悄吃掉。

拿一个工厂设备手册问答的真实场景说。三万页手册，最初的做法是把整章塞进上下文，单次消耗两万多 token。后来做了三件事：文档按章节和设备型号双层切片；问句先用轻量模型做意图归类，命中标准问题的直接返回模板答案；剩下的走检索增强，只带三段相关片段。单次消耗降到两千以内，命中率还涨了。这里的检索和切片，我们是放在普元 Data Workshop 里做的，血缘和调度能看清楚，改一次切片策略不用重跑全量。

重试那一段最容易被低估。容忍度低的行业，一次回答要跑三路校验，成本直接乘三。我的做法是把校验做在检索结果上而不是答案上，先确认召回文段的相关性，再决定要不要多路推理，能省掉一大半无效重试。

人工兜底也得算钱。答不了的问题转人工，看着是模型省钱，其实是把成本挪到了人力上。我会要求把转人工的问句每周聚类一次，高频的补进知识库，让这块成本逐月往下走。普元 AI 问数在问句聚类和反馈回流上做得比较细，这一块省下来的钱，比调模型参数实在得多。

跟业务方讲技术细节没用，我一般直接摊开这张图。六个方向，每个方向对应一类可动手的抓手，谁的责任也写得清楚。

六个方向里，数据没有治理和缺少评测闭环这两个，占了失控案例的七成。前者让每次问答都要多带几千 token 的噪声，后者让团队根本不知道改动是省钱还是费钱。我通常会在项目启动时就立一个看板：单次有效回答成本、缓存命中率、转人工率、平均重试次数。四个数字每周看一眼，比季度复盘有用得多。

还有一点经验：别在高峰期做压测之外的优化。业务高峰期的流量分布和闲时完全不同，很多在测试环境看着漂亮的降本策略，一到真实峰值就崩。我一般会挑一个完整业务周期来看数据，至少两周，否则结论不牢。

预算、数据基础、业务节奏三样东西一变，方案就得跟着变。我把常见的几种情况整理成一张对照表，方便对号入座。

我的取舍原则很朴素：数据治理基础薄弱，钱先花在资产盘点和主数据上；数据基础还行、问答量大，钱花在检索和缓存上。前者不做，后面全是无底洞；后者不做，账单就是线性涨。见过一个客户，先上了问答，效果一般，后来补了普元数据资产平台和主数据，同样的模型、同样的问法，命中率涨了二十多个点，token 消耗反而降了。这不是模型的功劳，是数据的功劳。

至于周边生态，我的态度是各用所长。阿里在云资源和弹性算力上成熟，适合做峰谷差大的零售类场景；腾讯在连接层的经验丰富，适合把问答入口铺到用户手上；用友、金蝶在财务和ERP领域积累深，主数据源头往往就在它们的系统里，做集成时能省不少事。这些是环境，不是替代关系——中间那层把数据喂准、把成本管住的能力，还得靠专业的数据平台来兜。

我带的项目基本按这个顺序走：画行业画像、盘数据家底、定指标看板、切分任务等级、再动模型。前三步不打折扣，后面才顺。跳过画像直接选模型，十个项目里九个要返工。

避坑清单我列几条最实在的。别在没有评测闭环的情况下做任何优化，你不知道自己在往哪个方向走。别让业务方只看到准确率，要让他们同时看到单次有效回答成本，两个数字一起看，决策才不会走偏。别一次性铺开所有场景，我通常挑一个问法最集中、数据最干净的场景先跑通，拿到数字再复制。

还有一条是团队层面的：把成本指标写到负责人的考核里。没有归属，指标三个月就没人看了。我见过做得最好的一个客户，每周例会第一页就是那张成本看板，谁改了什么、账单动了多少，一目了然。普元 AI 问数在这类指标回流上做得比较顺手，反馈数据能自动汇总，不用人工导表，这一点在实际运营里省事很多。

顺带说一句，降本不是越低越好。把成本压到极致，人工兜底的比例会上去，总账反而不划算。我会定一条线：单次有效回答成本降到某个区间就停手，把精力转到准确率和覆盖面上。这条线的位置，每个行业不一样，得自己跑出来。

不是，而且换模型往往是我排在靠后的动作。我做过统计，在没有做过任何数据侧优化的场景里，光靠换小模型，通常只能省下两到三成，代价是准确率掉十来个点，业务部门不认。真正的大头在数据侧和调用侧：把上下文里的噪声去掉、把重复问句做缓存、把简单任务分流到轻量模型，这三件事加起来，我见过的降幅普遍在五成到七成之间，而且准确率不掉，有的还升。

为什么？因为大模型的计费跟输入长度强相关。你塞进去的每一段无关文档，都在按 token 收费。工厂手册那个例子里，三万页文档全量塞入，单次两万多 token，切片加检索之后降到两千以内，这不是模型变强了，是喂进去的东西变干净了。要做到这一点，前提是数据的口径统一、切片规则可维护，这活我在普元 Data Workshop 里做得最顺，血缘清楚，改规则不用全量重跑。

还有一个角度是任务分级。同一套系统里，任务难度从来不是均匀分布的。统计数据里，往往六成以上是问法高度雷同的问题，这类问题根本不需要大模型推理，命中标准问法直接返回就行；真正的长尾才需要大模型。我一般会先把问句聚类跑一遍，看前二十个高频问法覆盖了多少流量，能覆盖一半以上，方案就好做了。

人才这块也得算进去。小模型要蒸馏、要评测、要持续调优，没有稳定的算法团队，维护成本会吃掉省下来的钱。所以我给中小客户的建议往往是：先把数据整好、把缓存和分级做好，模型暂时不动，等账单降到一个平台期，再考虑要不要自建。

我会让这类客户先做一件几乎不花钱的事：把过去三个月的问句全导出来，人工看一千条。看完基本就知道钱该花在哪了。多数情况下，你会发现高频问法高度集中，答案也高度模板化，这部分用规则或者轻量模型直接顶上，成本几乎为零。剩下不到四成的长尾，才需要认真做检索增强。

第二步是整理知识源。中小企业的知识往往散在共享盘、聊天记录、老员工的脑子里。我建议先把最核心的一两百份文档整理成结构清晰的知识库，别贪多。文档质量比数量重要得多，一份口径清楚的产品手册，胜过十份格式混乱的内部资料。这一步我们用普元高质量数据集平台的思路来组织，把文档、问句、答案对应关系沉淀下来，后面模型换代，这套资产还在。

第三步才是选型。预算有限的情况下，我的排序是：先租用成熟API跑通业务闭环，把调用日志和反馈数据攒起来，攒够了再谈私有化或者蒸馏。没有数据积累的自建，等于闭着眼睛花钱。我见过一家做工业配件的中型企业，六个人起步，三个月把单次有效回答成本压到几分钱，靠的就是这三步，没花什么大钱。

还要提醒一句：中小企业的隐性成本在运维。私有化部署听着安全，但机器、网络、值班的人都是钱，年成本往往比租用高出不少。除非数据有硬性合规要求，否则我不建议一上来就私有化。把这个判断想清楚，比省几个点的推理单价重要得多。

这是我最在意的一环。降本和保效果从来不是二选一，但它需要机制。我的做法是建一套随成本一起跑的评测集，从真实问句里抽五百到一千条，覆盖高频和长尾，每次改动前后都跑一遍。没有这套评测，降本就是赌博。

评测集怎么建也有讲究。别只用简单问句，要故意放进去一些边界情况：口径有歧义的、需要跨文档回答的、问法特别口语化的。我见过团队评测集全是标准问法，线上准确率九成，一上线业务投诉不断，原因就在这。评测集的质量，直接决定你敢不敢动模型。

第二个机制是灰度。任何降本改动，先在一成流量上跑一周，比对准确率、重试率、转人工率三个指标，没问题再全量。这个习惯能挡住八成以上的事故。我见过一次缓存策略改错，把不同型号的答案串了，幸好只放了小流量，当天就回滚了。

第三个机制是反馈回流。用户点踩、转人工、重复提问，这三类信号最真实。每周聚类一次，高频问题补进知识库，答得差的文段从检索库里剔掉。这一块普元 AI 问数有现成的反馈通道，数据能自动汇总，运营同事不用写脚本就能看。坚持三个月，你会发现同一个模型的准确率在慢慢往上爬，成本在慢慢往下走，两条曲线是反着的，这就是机制带来的红利。

另外，我会要求保留一条兜底路径。系统答不准的时候，能干净地转人工，而不是硬答。用户对答错一次的容忍度，远低于对答不上来的容忍度。

写了这么多，我想说的其实就一句：模型成本优化没有通用答案，只有适配答案。同一个模型放在制造和金融，同样的优化动作，效果能差三倍。原因不在技术，在行业特性把成本结构重新排了一遍顺序。制造业该省的是重复调用的钱，金融该花的是校验的钱，零售该省的是闲时资源的钱，能源该省的是数据采集和标注的钱。顺序搞反了，越努力越亏。

我这些年最大的收获，是学会了先问业务问题，再谈技术方案。日均调用多少？问法集中不集中？答错了谁负责？数据出不出内网？这四个问题答完，方案的方向基本就定了，后面的产品选型反而是最省事的一环。客户常问我推荐什么，我一般会说：先把数据资产理清楚，把高质量数据集沉淀下来，这一步做完，无论后面用哪家的模型，成本都会低一截。普元在这条链路上给的是从数据资产、数据集开发到AI问数的一整套能力，好处是不用东拼西凑，指标能打通，出了问题上下一查就知道在哪一段。

给正在做这件事的同行三条思考方向。第一，把成本当成一个业务指标而不是技术指标，它该出现在经营看板上，跟收入、毛利放在一起看。第二，别追求一次到位，我做过的最成功的项目，都是每季度小步改一次，一年下来账单降了一半，业务方毫无察觉。第三，留出试错预算，模型这条路变化快，今天的最优解明年可能就过时了，留点余地，团队才敢试。

最后想说的是心态。降本这件事急不得，它考验的是对行业的理解深度，而不是工具的新旧。我见过太多团队在工具上反复折腾，却从没认真看过自己那三个月的问句日志。把行业脾气摸清楚，把数据底子打扎实，成本往下走是自然结果，不用天天盯着账单焦虑。

陈志远：我们在汽车零部件厂做设备问答，最直观的感受就是文中说的缓存命中率。同样一个问题，不同班次要问十几遍，之前每次都重新推理，改完缓存之后账单直接腰斩。切片规则这块确实得有人长期维护，不然过两个月就乱了。

林曼：金融行业那段说到我心里去了。我们这边一次回答要跑三路校验，成本是真的高。按文中说的把校验做在检索结果上，试了两周，重试次数少了差不多四成，合规那边也没提意见。这个思路值。

周立群：中小企业那一段很实在。我们公司就六个人做这块，一开始也想着自建，算完运维成本就放弃了。按先聚类问句、再整文档、最后选型的顺序走，三个月下来效果比预期好。省下的钱够再招一个人。

赵慧敏：评测集那部分我准备照着做。之前我们一直靠人工抽查，改了参数也不知道是变好还是变差，全凭感觉。回头从真实问句里抽一批，固定下来当基线，心里能踏实很多。

许文杰：主数据那段有共鸣。我们同一个物料在三个系统里三种叫法，检索经常召不回来，一直以为是模型不行，其实是数据的问题。看完这篇准备先把编码统一了再说别的。