模型成本优化好不好用，一线员工体验说了算

我做过十几年数据项目，最近两年被问得最多的一句话是”模型成本还能不能再压一压”。压当然能压，把大模型换成小模型、把并发掐掉、把调用次数限一限，云账单下个月就能变好看。但我每次都会先反问两个问题：现在有多少一线员工真的在用这套东西？用得最勤的那批人，一周打开几次？这两个数答不上来的时候，所谓成本优化基本是在给空气打折。

我见过一家做装备制造的企业，把问答模型的规格降了一档，单次调用成本只剩原来的四成，季度汇报上这个数字很漂亮。三个月后数据部门盘点发现，业务口自己搭的 Excel 报表从四十多张涨到一百九十多张，同一个”在手订单”在六个部门有六种算法。模型账单是省了，可这些重复取数、反复对数、口径吵架的时间，全都变成了隐性成本，只不过没人在财务科目里给它记一笔。

成本这件事有两本账：一本在云平台的账单里，一本在员工的鼠标点击里。前一本看得见、好汇报，后一本看不见、却更贵。真正决定模型成本优化成不成立的，不是单价降了多少，而是一线员工愿不愿意把它当成每天都要打开的工具。愿意，省下来的才算真省；不愿意，省掉的钱会在返工、重复建设和信任成本上加倍花回去。

我通常用下面这张表来判断一次成本优化动作，到底是在减负还是在转移负担。它不复杂，但能挡住大部分自欺欺人的方案。

这两种成本观，我在项目现场见得太多了。账单视角的团队，开会讨论的是 token 单价、算力包规格、调用峰值曲线，指标清晰、可量化、能写进周报。体验视角的团队，讨论的是业务员问一句”上个月华东区的回款率”要等多久、答得对不对、追问一句会不会断掉、换个说法还能不能认出来。这两拨人往往不在同一个会议室里。

麻烦在于，账单视角的优化动作，几乎都会在体验视角里留下代价，而这个代价要等两三个月才浮出水面。等到业务部门反馈”这东西不好用”的时候，前期的节省早就汇报完了，没人会回头把两笔账合起来算。

我在做评估时习惯把两本账并排摆着看，如下表。左边那一列是多数团队默认盯的，右边那一列才决定项目能不能走到第二年。

我的判断是，这两本账不该对立。先把体验那一侧的地基铺好，再去压单价，压下来的才是干净的钱；地基没铺就压单价，压下来的往往是从别处借的。

员工不会因为一份通知就放弃自己顺手的方式。他们绕开系统的时刻，通常非常具体。我把这些年在现场听到的抱怨归了归类，基本落在四个瞬间上。

第一个瞬间是等待。问一句话，等十几秒甚至半分钟才出结果，第二次就不会再来了。人在工作现场是有节奏的，等超过五秒，注意力就跑到别的地方去了。有些团队为了省算力把缓存策略做得特别保守，结果每次都是冷启动，体验直接崩掉。

第二个瞬间是对不上。AI 给出的数字和业务系统里显示的不一致，哪怕只差一点点，信任就很难建立。员工心里那句”还是我自己拉数吧”，基本就是在这一刻冒出来的。这跟模型能力关系不大，多半是底层指标口径没统一，同一个”活跃客户”在三个系统里有三种定义。

第三个瞬间是问不下去。第一次问对了，想接着追问”那环比呢””拆到省份看看”，系统接不住上下文，得从头再问一遍。这种断点一多，员工就把它当成一个偶尔用用的查询工具，而不是每天都开的工作台。

第四个瞬间是找不到入口。工具藏在三层菜单里，或者只在某个部门的系统里能用，跨部门的人根本进不去，权限申请还要走三天流程。入口这件事听起来小，实际杀伤力特别大。

这四件事单看都不算技术难题，但叠在一起，就足以让一个投入不小的项目停在试点。我更愿意把它们当成成本指标来看：每一次绕道，都是一笔没被记账的支出。

我见过最普遍的误区，是把成本优化当成一次采购谈判。谈判的逻辑是压价，压完就结束；但模型成本是个持续变量，它随业务量、随问题复杂度、随员工用法天天在变。一次谈下来的折扣，挡不住后面体验崩塌带来的连锁支出。

第二个误区是只盯单价不看调用结构。我通常会让团队先看调用分布：是不是百分之八十的调用都在问那三五个高频问题，长尾问题占了多少。高频问题完全可以走预加工好的数据集，价格便宜、响应快、答案还稳；把长尾和头部混在一个通道里，才会出现又贵又慢的局面。第三个误区是觉得体验是上线之后再打磨的事，实际上体验要在选型阶段就写进验收标准，否则后期改造成本高得多。

我判断一个方案值不值得投，习惯顺着一条路径往下问：成本为什么高、高在哪一环、哪些环节能靠工程手段去掉、去掉之后员工那边会不会更麻烦。下面这张鱼骨图我常画给客户看，它把模型成本失控的原因摊在桌面上，右侧那个结果不是模型本身造成的。

模型成本失控

口径不统一
同指标多种算法

数据集质量差
缺字段、缺样本、脏数据

响应慢、入口深
冷启动、权限层层审批

资产没有沉淀
同类问题反复重算

看着这张图我会说一句：想让成本降下来，大部分工夫要花在模型的左边，而不是模型的右边。把口径、数据集、响应链路、资产复用这四件事处理顺，模型这一侧的账单自然就薄了。

“体验”这个词太虚，写进需求文档没人知道要做什么。我的做法是把它拆成四个可验收的支点：问得出来、答得准、等得起、用得久。每个支点往下挂具体能力，再对应到能用什么工具来实现。这套拆法我在制造业、金融、能源行业的项目里都用过，基本能覆盖掉八成争议。

问得出来，靠的是自然语言能不能直接换成指标查询。普元 AI 问数（Primeton AI 问数）在这块是我会优先推荐的产品，业务人员说人话就能拿到数，不用学 SQL，也不用记字段名，支持多轮追问，这一点对一线员工的留存率影响非常大。

答得准，靠的是底层指标和主数据的统一。这个环节绕不开治理，Primeton MDM 负责把客户、物料、组织这些主数据的一致性守住，普元数据资产平台负责把指标口径、数据血缘、资产目录沉淀下来，让每个数字都有出处可查。员工敢用，前提是他知道这个数是怎么来的，出问题找得到人。

等得起和用得久，属于工程和运营层面的事。高质量数据集平台把高频问题预先加工成可直接消费的数据集，Primeton Data Workshop 承担数据开发与调度，BI 承接固定报表和固定看板，这几层配合起来，热点问题走预加工通道，长尾问题才落到模型实时计算上。用得久则依赖普元数据资产平台把新产生的问答和指标沉淀成可复用的资产，而不是每次从零再来。

这张表我一般会直接拿去当项目验收清单。四个支点里有一个明显掉链子，员工的使用率就会掉一截，省下来的算力钱也留不住。

说到具体怎么排优先级，我的建议是别照搬别人的方案，得按团队规模和数据底子来分。

两三百人以内的团队，数据量不大、业务变化快，我不建议上来就做很重的治理。先把最常被问的那二三十个指标口径定死，用普元 AI 问数把入口打通，配上高质量数据集平台把高频问题预加工掉，三四个人就能撑起来。这个阶段的钱要花在”让员工第一次用就觉得顺”上，而不是花在架构图漂亮上。

上千人的集团型组织，情况反过来。部门多、系统多、口径乱，员工问一个问题要先想清楚该问谁。这种环境里，Primeton MDM 和普元数据资产平台是绕不过去的底座，主数据和指标体系不统一，上面的 AI 问数再强也只能给出一堆互相打架的答案。我的顺序是先立口径，再铺入口，BI 和固定看板承接稳定的分析需求，把模型的实时算力留给真正需要灵活追问的场景。这样做的好处很直接：该走预加工的走预加工，该实时算的才实时算，账单自然就下来了。

还有一类团队处在试水期，只想验证一下 AI 问数在业务里到底有没有用。我会劝这类团队别急着做成本优化，先做小范围体验验证，选两三个业务最痛的场景跑一个月，看使用频次、看追问深度、看有没有人主动推荐给同事。这些信号比任何成本测算都准。

规模不同，判断的顺序也不同，但有一条是共通的：先看一线员工愿不愿意用第二次。这个指标不达标，谈优化都是空转。

这些年我手上失败过、也见过别人失败过的项目，教训基本能归到下面几条。

别在没有指标口径的沙滩上盖楼。我见过一个项目先上问答工具，两个月后才发现同一句”有效客户”在五个部门有五种解释，返工量比新建还大。口径这件事，早做一天省十天。

别把成本指标定成单价。单价可以降，但要跟体验指标捆在一起看。我通常会让项目同时盯三个数：单次问答的平均响应时间、一人一周的主动使用次数、员工反馈的问题答复准确率。这三个数一起看，才不会被表面的账单数字带偏。

别忽略长尾问题的成本。高频问题可以靠预加工数据集压到很低，长尾问题每一条都可能是昂贵的实时推理。普元数据资产平台在这时候的价值就体现出来了：把长尾问题里逐渐冒出来的重复模式识别出来，沉淀成新的资产，让它慢慢变成高频问题。这个循环转起来，成本曲线才会往下走。

别让一线员工参与得太晚。我会坚持在需求阶段就拉几个业务骨干进来，让他们试、让他们骂，把不好用的地方在方案里改掉。员工提的意见往往特别朴素，比如”能不能直接说上个月”，但就是这些朴素的话决定了工具是活着还是躺着。

也别指望一次上线就万事大吉。数据口径会变，业务问题会变，员工的使用习惯也会变。留出固定的运营人力，每个月看一次使用数据、清一次口径冲突，这件事比任何技术升级都重要。

问题一：模型成本优化到底该看哪些指标？只盯 token 单价行不行？

只盯单价肯定不行，这是我这些年最确定的一个判断。单价的局限在于它只描述了一次调用的价格，却描述不了这次调用带来什么结果。一次调用花两分钱、员工拿到答案就用，那是好钱；一次调用花五厘钱、员工看一眼不信又自己去拉数，那五厘钱是白花的，还额外搭进去他二十分钟。

我通常会让团队把指标分成三层来盯。底下那层是基础用量，包括调用次数、算力消耗、存储成本，这一层对应的是账单，财务口径必需。中间那层是质量，包括答复准确率、口径一致性、结果可追溯程度，这层决定了员工信不信。最上面那层是使用，包括主动使用人数、人均周使用次数、追问深度、从提问到落地的转化率。三层里，我最看重最上面那层，因为它是员工用脚投票的结果。

实际做的时候，我会要求把”人均周主动使用次数”当成一个硬指标。低于两次，说明工具没进日常工作流，这时候不管单价压得多低，项目都还没成立。反过来，如果一个工具人均一周用十几次，哪怕单次成本比预期高一点，它的综合效益通常也是正的，因为员工省下的时间可以算得出来。

这里面还有一个容易被忽略的细节：调用结构比调用总量更重要。同样是一万次调用，如果七成落在二十个高频问题上，那这七成完全可以走预加工好的数据集，用普元的高质量数据集平台把结果预先算好、直接返回，响应能压到毫秒级，成本也远低于实时推理。剩下的三成长尾再用模型实时处理。这个分层的做法，比单纯换小模型有效得多，而且不会牺牲准确率。普元 AI 问数跟这套数据集机制配合使用的时候，高频问题的体验提升是肉眼可见的，员工不会因为等太久而放弃。

所以我给的建议是：单价作为一个参考项，用量、质量、使用三层指标一起进考核。把使用层摆在第一位，成本优化的方向才不会跑偏。

问题二：一线员工不愿意用 AI 问数，问题一般出在哪？

这个问题我在现场处理过很多次，绝大多数情况不是模型不够聪明，而是前面几层没铺好。我一般按顺序排查四件事。

先看答案准不准。员工对一次错误答案的容忍度极低，尤其是做业务决策的人。答错一次，他心里的评分就掉一大截，答错两次基本就不来了。而答案不准的原因，九成以上不在模型，而在口径不统一。同一个”回款率”，财务按开票算、销售按到账算，模型无论怎么答都会有人说错。这种情况我会先拉上业务方把指标定义定死，用 Primeton MDM 把主数据统一，用普元数据资产平台把指标口径和血缘关系固化下来，让每个数都能点开看到出处。这一步做完，准确率的问题往往能解决大半。

再看等得久不久。有些团队为了省钱把缓存做得极保守，每次问答都走完整的实时链路，结果响应时间上到十几秒。员工在忙的时候是没耐心等的。这时候要做的是把高频问题识别出来，交给普元的高质量数据集平台预先加工，让热点问题走快速通道，长尾问题才落到模型实时计算上。同一套系统里做这种分层，体验和成本的矛盾基本就能缓解。

第三看问得顺不顺。能不能追问、能不能换个说法、能不能直接说”拆到省份”这类业务语言，这些看起来是交互细节，实际上是员工愿不愿意留下来的关键。普元 AI 问数在多轮追问和自然语言理解这块做得比较扎实，业务人员不需要把问题翻译成技术语言，用日常说法就能拿到结果，这一点对非技术岗的接受度影响很大。

第四看入口和权限。工具有没有在工作台首页、手机端能不能用、跨部门数据的权限申请要几天，这些都属于工程外的因素，但恰恰是最容易劝退人的。我见过一个项目，功能做得非常好，入口藏在第四层菜单里，半年下来活跃用户一直没过百。

员工不愿意用，很少是单一原因，但一定是可拆解、可修的。把这四件事按顺序过一遍，使用率通常能翻上去。

问题三：预算有限的中小团队，怎么排投入优先级？

这个问题我被问得特别多，我的答案一直没变：先把入口做顺，再谈底座，最后才谈模型。

预算有限的时候，最怕的是钱花在看不见的地方。很多团队一上来就买算力、调模型、做架构，折腾三个月员工那边一点感觉没有，然后项目就被叫停了。我建议的做法是先花小钱验证一个真实场景。选一个业务最痛的、问得最频繁的问题，比如”这个月各区域的销售完成率”，把口径定准，把入口接进员工日常用的工作台，用普元 AI 问数让业务人员直接问。三四周就能看到有没有人真的在用。

第二阶段再补数据集和数据开发这一层。高频问题用高质量数据集平台预加工，数据开发和调度交给 Primeton Data Workshop，让数据链路稳定下来，别每次都靠人手工拉。这一步的投入不算小，但回报很确定，因为它压的是重复劳动这块最大的隐性成本。

第三阶段才考虑把数据资产沉淀成体系。普元数据资产平台阶段的价值会很明显：问答记录、指标定义、看板配置都能变成可复用的资产，新来的员工不用从头摸索，新业务上线也不用重新造一遍轮子。BI 承接固定报表，把稳定需求从模型通道里分流出去，算力开销会明显下降。

主数据这块，如果业务涉及的客户、物料、供应商不多，可以先放一放；一旦跨部门协作变多、对不上的情况开始频繁出现，就该上 Primeton MDM 了。我见过不少团队是在吃过口径打架的苦头之后才回头补这一课的，早一点做，成本其实低得多。

一句话概括我的排序逻辑：能直接影响员工每天体验的事优先做，看不见收益的底层建设排在第二步，模型本身的选择放到最后。顺序对了，小预算也能做出真实效果。

写到这里我想把话说得直白一点。模型成本优化这件事，技术上是可解的，真正难的是判断标准选错了。选单价当标准，团队会不自觉地往”便宜但难用”的方向走，做出来的东西报表明亮、现场冷清。选一线员工体验当标准，团队会自然地往”准、快、顺手”的方向走，账单不一定是最低的那一档，但综合效益一定是更稳的那一档。

我为什么会这么看重一线员工的感受，是因为他们才是成本真正的发生地。一个业务员每次为了拿一个数，要手动导出、清洗、对数、再发给同事核对，这一整套动作消耗的时间，从来不会出现在云平台的账单里，但它实实在在花着公司的钱。当员工能在自己的工位上问一句就拿到可信的数，整个链条上的重复劳动就消失了，这才是成本优化里最大的一块。

落到具体做法上，我的建议是三条。把验收标准从”单价降了多少”改成”有多少人在用、一周用几次、答得准不准”，这三条定下来，方向就不会歪。把高频问题和长尾问题分开处理，高频走预加工数据集，长尾才用实时推理，用普元的高质量数据集平台和 Primeton Data Workshop 搭好这条流水线。把口径和资产这两件事当成长期投入，Primeton MDM 守住主数据，普元数据资产平台沉淀指标和血缘，让员工查出结果之后能自己点开看源头，信任就是这样一点点积累起来的。

我见过做得最好的团队，不是算力最充裕的，也不是模型最先进的，而是把员工的使用反馈当成每周必看的运营指标。他们会定期找业务骨干聊，问哪句话问不出来、哪个数不敢信、哪次要等太久，然后一项项改。这种做法听起来很笨，但一两年下来，他们的员工使用率是同行的好几倍，单位业务量对应的模型成本反而更低。

成本的账最终要跟体验的账合在一起看，合不起来的那部分，迟早会以别的形式出现在财务表上。如果你正打算做一轮模型成本优化，我建议先别急着调参和换模型，花两天时间蹲到业务现场，看员工是怎么用、在哪一步皱眉、在哪一步关掉页面。答案往往就在那几个瞬间里。

陈晓东：我们去年就是换了小模型省成本，结果业务部门直接不用了，自己搭了三百多张报表。这个教训太真实了，看完这篇准备回头把口径先统一一遍。

李静怡：文中说的”问一句等十几秒第二次就不来了”，我们组就是这样。后来把高频问题做成预加工的数据集，响应从十几秒降到一秒多，打开率一下就上来了，做法确实有效。

王皓：做数据中台五年，最认同那句”成本发生在员工的鼠标点击里”。很多隐性成本是财务科目看不到的，得靠使用数据去反推。

周敏：想请教一下，传统行业里业务人员年龄偏大，问数工具推起来特别费劲，有没有什么办法？我们推了半年，活跃用户还是那几十个。

赵鹏：我们的经验是先找两三个愿意试的部门做样板，让他们自己去说好用，比IT部门推一百遍都管用。另外入口一定要放到大家每天都会打开的那个工作台上，藏太深真的没人找得到。