1. 选型评审会上那个没人答得上来的问题上周技术评审会我们定一套智能客服助手要用哪个模型底座。A方案是自研微调版本带一整套推理服务单次调用成本高出不少B方案是外部API单价很便宜但偶发抽风有一小部分请求会直接返回不可用内容。两边吵了一个多小时算法同学说A效果好、业务同学说B明显更便宜最后Leader问了一句——那到底哪个方案更划算全场安静了。这个问题看着简单却把很多人问住了。我们平时的模型评测关注点几乎全在准不准准确率、召回率、BLEU值、困惑度…… 竞品或者开源模型发布的时候也都在宣传分数多高。真正到了选型阶段价格对比又容易变成简单的单次调用多少钱。问题在于准确率不反映你为那部分不准付出了什么代价单价又不反映交易成功的概率。两套信息是断开的拍板就成了拍脑袋比的是谁嗓门大。后来在一次复盘里我们试着算了一个自己不常用的指标——cost-per-success单次成功成本。算完之后发现困扰团队一个多月的选型难题其实一页纸就能说清楚。这篇文章就是把这套方法论整理出来什么叫cost-per-success、它怎么算、怎么在半生产环境中跑通一次评测以及过程中最容易在哪些地方翻车。适合正在做模型选型、需要跟预算打交道、或者想摆脱夹在算法指标和成本报表之间局面的团队参考。2. 把成本和成功塞进同一个算式会发生什么2.1 定义一次成功到底花了多少钱cost-per-success的计算非常朴素不需要任何复杂统计学工具cost-per-success 总花费 / 成功次数也可以写成更直观的形式cost-per-success 单次调用成本 ÷ 成功率比如某方案每次调用花0.01元成功率80%那CPS就是0.01/0.80.0125——每次成功实际花0.0125元。另外一个方案单价0.02元成功率95%CPS是0.021。乍看之下方案A便宜得多但把成功视为核心交付物之后你会发现A只是每次成功省了不到一分钱却带来了大量的失败体验。如果这个场景是面向终端用户的那失败背后的流失和人工补偿会远大于账面差价。2.2 关键前提怎么定义成功决定指标有没有价值计算CPS最难的不是数学而是成功两个字。不同业务对成功的定义完全不一样把定义想清楚这个指标才有锚点。我的经验是分三层去定义完全成功任务在无人工介入的情况下走完了完整链路。客服场景里用户收到可采纳回答且未复问内容生成场景里生成文本通过合规和格式校验。部分成功任务完成了但花费了额外的隐性成本。比如回答需要人工复核修改、触发了一次用户重试、超时后走了降级链路。失败任务产出不可用或者直接报错业务链路断裂。实际计算CPS时你可以只按完全成功作为分子端但对于部分成功最好单独统计它的发生比例因为它本质上是隐性成本会在后期暴露。2.3 一个反直觉的观察单次成本低不意味着CPS低我以前也习惯直接比较每次调用多少钱。直到在某次含敏感意图识别的评测里外部模型单价便宜40%但成功率低了7个百分点——当时觉得差异不大算完CPS才倒吸一口凉气几乎打平外部方案的优势被失败率吃掉了但因为每次失败要流转到人工处理实际综合成本反而更贵。从这个角度看CPS真正反映的不是一个模型准不准而是整条链路稳定不顺。单次调用再便宜只要失败率往上走一点CPS就会快速恶化反之一个单价略高但稳定成功的模型很可能在CPS维度上是更经济的选择。方案单次调用成本成功率cost-per-success10000次调用总费用成功次数方案A0.01元80%0.0125元100元8000次方案B0.02元95%0.021元200元9500次方案C0.015元92%0.0163元150元9200次单纯看总费用A是绝对赢家看成功率B最好看单次成功成本反而是A表面占优但结合业务容忍度之后选哪个就得另说了。这个指标最大的价值就在于此它逼你把模型能力、产品链路、用户体验、预算约束放到同一条赛道上比较。3. 实际用cost-per-success做一次评测的完整流程接下来是我在团队里执行的完整流程用的是某客服助手项目的脱敏案例思路可以直接套用到大多数对话、内容生成和文档解析场景。3.1 先把业务目标翻译成可统计的机器指标这一步一定要业务方、算法、运营三方坐在一起。目标是回答一个问题我们的业务里什么样算一次成功 不能是抽象感受必须落到日志字段。用客服助手举例我们定了三条规则规则一用户提问后助手返回答案且用户在5分钟内没有追问同主题问题。规则二返回答案后用户没有点不满意或转人工按钮。规则三答案本身通过抽检规则关键词缺失检测、敏感词过滤。任何漏掉换业务视角的行为都会让CPS失真。你先别急着计算把这条规则写下来拿过去两周的日志跑一下覆盖率——如果一版规则覆盖不到80%的实际会话说明定义还不够清楚。3.2 用接近生产环境的数据采集而不是小规模测试集很多团队做模型评测喜欢拿几千条测试集跑准确率这个数据对CPS来说远远不够。原因在于CPS的低频差异需要足够多的样本才能体现出来。两个成功率分别为93%和95%的方案如果只测1000条样本结果波动就有±1.5个百分点很难区分谁真稳定。我们的建议是最少用5000条以上真实历史会话且最好是从生产日志里随机抽样的用户问题而不是志愿者编造的测试题。具体做法是把历史会话按天分桶每天随机抽10%-20%连续抽两周左右再合并到一起。这个做法的好处是覆盖工作日、周末、不同话峰期的真实分布。紧接着要做的事情是保证两套方案吃的是同一份输入。我们当时犯过一个错评测A方案用了上季度日志评测B方案用了当季度日志。结果B成绩好看起来完全是因为用户语言习惯变了这会让CPS对比彻底失去意义。注意同一份输入、同一个评判口径、同一个时间段这是CPS评估的铁律少一个都别往下走。3.3 统一计价口径别漏了电费、运维和等待损耗很多人的计价口径是这样的自研方案只算GPU一小时成本除以并发调用数外部方案只算API单价。这个口径偏乐观却忽略了三个大头自研方案的工程运维成本模型更新、推理优化、扩容监控都是有人在投入时间折算下来每月的固定开销并不低。外部方案的超时成本外部API在高峰期有时要2-3秒才能返回客服场景里用户等待每多一秒放弃率就上一个台阶。这部分的损失本质上也应该摊进单次调用成本。失败重试的叠加成本如果调用失败后系统自动重试一次用户请求可能产生两次计费调用。单次成本自然要乘以平均重试次数。在这个环节里不要用理想价要用真实账单。API按invoice里的平均单价自研方案用GPU月租加人力分摊再除以月调用总量。宁可高估不可低估这样选出来的方案才扛得住上线后的预算压力。3.4 计算CPS并生成决策矩阵把上面采集到的数据交给统计脚本算出来每个方案的总调用次数、总费用、成功次数、失败原因分布最终得到CPS。与此同时整理一张决策矩阵备忘后续向后汇报。决策维度方案A自研微调方案B外部API总调用次数评测集80008000成功次数73607440成功率92%93%总费用2400元1200元cost-per-success0.326元0.161元失败后人工处理成本高需专项客服跟进中部分失败可自动重试看起来很直观但还要回答差值能不能抵消风险B外部方案便宜但数据出境审核、供应方稳定性、限流风险怎么算这时CPS就不只是胜负判断了它变成一个基准——如果A想让CPS追平B要么把成本降下来要么把成功率提上去目标变得可谈判、可量化。3.5 上线前用最小流量验证CPS预测评测数据再漂亮也有局限性。我们当时在正式切换前做了一个双通道验证把5%的用户请求同时打到两个方案上跑了一周。重点不是再看一次谁胜出而是验证真实环境下的失败率、重试率和用户放弃率是否接近测试预判。结果出现了一个评测阶段没发现的坑外部API在夜间流量高峰时超时率比日间高出三倍。这个问题是离线评测完全测不出来的却直接影响它的成功率进而让CPS暴涨。所以我的强烈建议是任何结论在下发生产前都要经过一轮流量拼接验证。CPS相差不大的两个方案只有真实流量能帮你做最后裁决。4. 评测里最容易翻车的五个细节这套方法跑过一次之后我把踩过的坑分成五类基本覆盖了绝大多数团队会遇到的问题。4.1 拿测试集准确率冒充成功率准确率和成功率是两回事。准确率衡量的是模型输出和标注参考的匹配程度成功率衡量的是业务链路是否闭环。一个模型准确率95%但如果因为格式错误、超时、违反安全策略导致10%的请求无法使用它的成功率只有85%左右。拿准确率当成功率代入CPS算出来的数字必然乐观到失真。正确的做法是建设一套独立的业务链路标注将模型输出重放进下游环节让真实的生产逻辑而不是人类偏好判断它是否被接受。4.2 忽略重试机制对成本的影响很多系统做了自动重试调用失败、超时、返回空值都会重新请求。这样对用户体验好但对成本计算影响很大——如果你按用户请求次数算单价就会低估模型实际产生的账单金额。一个真实案例某方案表面上单次0.01元但平均每3次成功请求就要触发1次重试实际单次成本已经变成了0.0133元。如果不用账单总额除以成功次数反而看宣传单价CPS就会被低估近三成。解决办法很简单拿计费平台的实际账单金额除以成功次数而不是用标称单价估算。4.3 小样本评测导致CPS波动太大在小样本上成功率差异很容易是随机噪声。两套方案各测300条样本差出5个百分点看起来B完胜实际上置信区间一算两者可能根本没统计差异。CPS在这种噪音下的决策稳定性会非常差。我自己的经验是成功率预期在90%以上时至少准备5000条有效样本成功率更低的任务样本要超过1万条。多花时间准备数据比事后解释A/B分歧值得多。4.4 没把人工二次检验成本计入总成本有些场景模型生成的内容需要人来审核后才能用。这时候的人工成本必须折算进方案总成本。常常有人忽略这个只看模型调用价格结果CPS低得离谱上线后才发现审核团队的工作量吃掉了所有预算优势。做法是把人工检验每条耗时x分钟、对应人力成本x元加进总成本分母。不同方案的人工介入率可能差异巨大这个项往往会颠覆原先的成本对比结论。4.5 把不同业务场景的CPS拿来做跨场景比较CPS从来不是跨场景通用的数值。同一个模型做客服比做内容摘要的CPS高不代表它在客服场景比内容摘要方案差。每个场景的成功定义和业务容忍度不同横向比较没有意义纵向跟踪才是关键。所以不要给团队设一个全场景CPS必须低于0.1的荒唐目标。应该按场景维护CPS基线观察同一模型在一个场景内的趋势变化即可。5. 把cost-per-success作为选型语言内化进团队流程5.1 从指标到规则定一个可执行的替换门槛我们后来把CPS正式列入模型选型评审不再允许只凭PPT分数说话。机制很简单任何新模型想替换线上模型必须同时满足三条成功率不低于现行方案否则用户可感知的体验会回落cost-per-success比现行方案低15%以上否则无需冒替换风险有至少两周、每天都稳定的评测监控数据支撑避免单日波动带来的误判。这个门槛一设团队里我觉得新模型不错这类声音明显变少因为提这个意见的人需要先补齐数据和计算。5.2 不同角色协作时CPS是翻译器算法人员在讨论CPS时会更主动地解释为什么成功率看似高但业务侧流失率高业务人员则可以通过失败后人工介入成本来量化对模型能力的要求。两边不再各说各话。实际操作时我建议由算法或平台团队维护一份模型CPS周报每条模型或供应商一行记录调用量、成功率、账单金额、CPS以及最近一周的变化趋势。每周五下午花半小时过一遍团队的预算感知会变得极其敏锐——哪个模型长期CPS在升基本就是数据分布漂移或服务质量下滑的前兆。5.3 个人体会指标本身不神奇神奇的是它逼你面对真实世界经历过这次评测后我的感受是CPS不是一个用来选出唯一正确答案的神奇标尺。两套方案的CPS可能非常接近最终决定因素往往来自非功能性约束比如团队运维能力、供应商稳定度、数据合规偏好。但CPS真正改变的是团队内部的对话质量——它把哪个模型更好这种主观拉扯变成了在同样的一次成功标准下谁用更低的成本做到这让模型选型终于有了一个可复盘、可辩论、可继承的量化底座。最后分享一个快速启动的建议不需要一上来就搭复杂的评测平台。先拿出过去一个月日志让一位工程师用脚本统计出候选方案的成功率和账单总额在共享文档里算出各自的CPS。先做一次再迭代口径。你大概率会发现原本争论不休的事忽然变得无比具体。