1. 为什么传统的模型评测指标正在失效做过模型选型的人大概都有过这种体验花了两周时间跑完一轮评测准确率、F1、AUC 各项指标都列得整整齐齐团队开会一看A 模型比 B 模型高了 1.2 个百分点于是拍板选了 A。结果上线跑了三个月账单出来傻眼了——A 模型的调用成本是 B 模型的四倍而那 1.2 个百分点的提升在业务侧几乎感知不到。这不是个例。我参与过好几次模型选型的评审发现一个很普遍的问题大家习惯用学术 benchmark 的思维来做工程决策。学术评测关心的是模型在固定数据集上的表现上限但工程选型关心的是在给定预算下这个模型能不能稳定地把事情办成。这两个目标之间的差距就是 cost-per-success 这个指标要填的坑。先说清楚它是什么。Cost-per-success直译过来就是“每次成功成本”核心公式很简单Cost-per-success 总投入成本 / 成功完成的任务次数这里的“成功”不是模型输出了一个看起来像样的回答而是这个回答在业务链路上真正被采纳、被消费、产生了预期效果。比如客服场景里用户没有转人工、没有二次追问、对话正常结束这才算一次 success。内容生成场景里生成结果直接可用、不需要人工返工修改才算一次 success。它解决的核心问题是把模型的语言能力指标翻译成业务侧能算清楚账的经济指标。适合谁来用三类人最需要一是做 AI 应用落地的工程负责人二是需要向管理层汇报选型依据的技术管理者三是自己搭产品、每一分 API 费用都要精打细算的独立开发者。哪怕你只是偶尔调几个模型做对比理解这个思路也能帮你少花冤枉钱。2. 拆解 cost-per-success 的构成要素2.1 成本侧到底该算哪些账很多人一算成本就只盯着 API 的 token 单价这是最容易踩的坑。真实的成本结构至少包含四层我按从显性到隐性的顺序列一下成本层级具体内容是否常被忽略直接调用成本输入/输出 token 费用、图片/音频处理费否大家都会算重试与纠错成本失败重试、格式修复、二次调用经常被忽略后处理成本结果校验、人工审核、格式转换经常被忽略机会成本延迟导致的用户流失、并发受限的扩容费几乎没人算直接调用成本最好算按官方定价乘以实际消耗量就行。但重试成本往往被低估得厉害。我实测过一个结构化抽取任务某模型首次输出 JSON 格式正确的概率只有 70% 左右剩下 30% 需要重试或者用规则修补。这意味着它的实际成本是标称价格的 1.4 倍以上而另一个格式稳定性更好的模型虽然单价贵 20%综合下来反而更便宜。后处理成本更隐蔽。如果模型输出需要人工抽检那这部分人力成本必须摊进去。我一般会用一个粗略系数需要人工介入的比例乘以单次人工处理的时间成本再除以总任务量。机会成本则要看业务场景实时对话场景里延迟每增加一秒用户放弃率可能上升几个百分点这部分损失很难精确量化但选型时至少要有个定性判断。2.2 成功侧怎么定义才算合理“成功”的定义是整个指标里最需要和业务方对齐的部分定义错了后面算得再精确都是白搭。我通常把成功判定分成三个层次硬性成功结果完全符合预期可直接使用无需任何人工干预。这是最严格的定义。软性成功结果基本可用但需要轻微调整比如改个措辞、补个字段人工介入时间在可接受阈值内。业务成功从最终业务结果倒推比如用户满意度达标、任务闭环完成中间可能有多次模型调用。选哪个层次取决于你的场景容忍度。做批量数据处理我建议用硬性成功因为人工返工的成本会吃掉所有收益。做创意辅助类工具软性成功更合理因为本来就需要人来把关。做端到端的自动化流程业务成功才是唯一有意义的定义。这里有个实操心得定义成功时一定要写清楚判定规则最好能自动化判定。我见过团队用“感觉还行”来标注成功结果两个人标同一批数据一致率不到 60%这种数据算出来的 cost-per-success 完全没有参考价值。能自动判定的就写脚本判定不能自动判定的就制定明确的评分卡把主观判断压缩到最小。2.3 为什么这个指标比单一维度更有决策力单看准确率你会选那个分数最高的。单看成本你会选那个最便宜的。但现实决策往往是在两者之间找平衡点而 cost-per-success 天然就是这个平衡点的量化表达。举个我实际遇到的例子。三个模型做同一批工单分类任务各跑 1000 条模型单价相对值准确率格式合规率综合成功率总成本Cost-per-success模型甲1.092%95%87.4%1000.114模型乙2.595%98%93.1%2500.268模型丙0.688%90%79.2%600.076单看准确率模型乙最好。单看成本模型丙最便宜。但 cost-per-success 告诉你模型丙每成功处理一个工单只要 0.076 个单位成本是模型乙的三分之一不到。如果业务对准确率的要求不是极端苛刻模型丙显然是更理性的选择。这个结论用单一指标是得不出来的。3. 搭建一套可复现的评测流程3.1 评测集的设计原则评测集的质量直接决定结论的可信度。我的经验是遵循三个原则代表性、分层性、可判定性。代表性指的是评测样本要覆盖真实流量的分布。很多人图省事从网上找一个公开数据集就开始跑但公开数据集的分布和你的业务分布可能差很远。我一般会从真实业务日志里随机抽样如果历史数据不够就人工构造一批贴近真实场景的样本。样本量不用特别大200 到 500 条通常就能看出趋势但一定要覆盖主要的使用模式。分层性是指把评测集按难度或类型分层。比如对话任务可以分成简单问答、多轮推理、边界情况三层分别统计各层的成功率。这样你不仅知道哪个模型整体更好还知道它在哪类任务上更强选型时可以针对性取舍。可判定性是最容易被忽视的。每条样本都要有明确的预期输出或者判定标准能自动判定的优先自动判定。对于开放式生成任务可以设计一个评分卡从相关性、完整性、格式合规等维度打分设定及格线。我通常会把判定脚本和评测集一起维护这样换模型重跑时不需要重新标注。3.2 成本数据的采集方法成本采集要做到颗粒度足够细才能支撑后续分析。我一般会记录每次调用的以下字段# 单次调用成本记录结构示例 call_record { task_id: task_001, model_name: model_a, input_tokens: 850, output_tokens: 320, retry_count: 1, # 重试次数 latency_ms: 2400, # 延迟 is_success: True, # 是否成功 post_process_time: 0, # 后处理耗时秒 timestamp: 2024-01-15T10:30:00 }有了这些原始记录成本计算就是简单的聚合。直接成本按 token 单价算重试成本把重试次数乘上去后处理成本按人工时薪折算。延迟数据单独统计用于评估机会成本。注意不同模型的计费方式可能不一样有的按 token 计费有的按调用次数计费有的对输入输出分别定价。采集前一定要把计费规则搞清楚否则算出来的成本会失真。3.3 成功判定的自动化实现成功判定能自动化就自动化这是保证评测可复现的关键。对于结构化输出任务判定逻辑很直接解析输出检查字段是否齐全、类型是否正确、值是否在合理范围内。对于文本生成任务可以用规则加模型结合的方式判定。我常用的一个模式是“规则初筛 模型复核”。先用规则快速过滤掉明显不合格的输出比如格式错误、长度异常、包含禁用词剩下的用一个小模型或者评分脚本做质量打分。这样既保证了效率又比纯规则判定更准确。def judge_success(output, expected, task_type): 成功判定示例 if task_type structured: try: parsed json.loads(output) # 检查必需字段 for field in expected[required_fields]: if field not in parsed: return False, missing_field # 检查字段值范围 if not validate_ranges(parsed, expected[ranges]): return False, out_of_range return True, ok except json.JSONDecodeError: return False, invalid_json elif task_type open_ended: score quality_score(output, expected[criteria]) return score expected[threshold], fscore_{score}判定脚本要跟着评测集一起版本管理每次修改判定逻辑都要记录否则不同时间跑出来的结果没法对比。4. 实操中的关键细节与避坑经验4.1 样本量不足时的处理策略理想情况下评测集越大越好但现实中经常面临样本不够的问题。我的做法是先跑小样本看趋势再决定是否扩大。如果两个模型的 cost-per-success 差距在 20% 以上200 条样本通常就能稳定区分。如果差距在 5% 以内那可能需要上千条样本才能确认差异是否显著这时候就要权衡评测成本了。另一个技巧是用置信区间代替单点估计。不要只报一个 cost-per-success 数值而是报一个区间。比如“模型甲的 cost-per-success 在 0.10 到 0.13 之间”这样决策者能直观看到不确定性。计算方法可以用 bootstrap 重采样跑个几百次就能得到比较稳定的区间。4.2 模型版本漂移的应对模型是会变的。服务商可能悄悄更新模型权重或者调整默认参数导致你上个月测的结果这个月就不准了。我踩过这个坑一个模型连续三个月评测都是最优第四个月突然成功率掉了 8 个百分点排查半天才发现是服务商更新了版本。应对方法有两个。一是在评测记录里固定模型版本号如果服务商支持指定版本就指定不支持就在评测时记录调用日期方便追溯。二是建立定期复测机制重要的选型决策不要一测定终身每隔一段时间用同一套评测集重跑一次监控指标变化。如果发现明显漂移及时重新评估。4.3 多模型组合的成本优化有时候最优解不是选一个模型而是组合使用。比如用便宜模型处理简单任务用贵模型处理复杂任务整体 cost-per-success 可能比单用任何一个都低。这个思路叫“模型路由”或“级联”。实现方式很简单先用一个轻量分类器或者规则判断任务难度简单任务走便宜模型复杂任务走贵模型。关键是找到合适的分流阈值。我的做法是画一条曲线横轴是分流比例纵轴是整体 cost-per-success找到曲线的最低点对应的分流比例。分流策略简单任务占比整体成功率整体成本Cost-per-success全用便宜模型100%79.2%600.076全用贵模型0%93.1%2500.268分流阈值A60%85.3%1360.159分流阈值B75%82.1%1080.132这个例子里分流策略 B 的 cost-per-success 是 0.132虽然比全用便宜模型的 0.076 高但成功率从 79.2% 提升到了 82.1%。如果业务对成功率有底线要求这个组合就是更合理的选择。具体选哪个点取决于你对成功率的容忍下限。4.4 常见问题速查表问题现象可能原因排查方向解决建议成本算出来远高于预期重试成本未计入检查重试日志把重试次数纳入成本公式成功率异常高判定标准太宽松复核判定脚本收紧成功定义增加校验维度不同模型对比结果不稳定样本量不足或分布偏差扩大样本、分层统计增加样本量按任务类型分层评测结果与线上表现不符评测集与真实流量分布不一致对比评测集和线上日志分布重新采样贴近真实分布模型表现突然下降模型版本更新检查版本号和调用日期固定版本建立复测机制提示评测过程中遇到任何异常数据先别急着删掉。异常样本往往藏着最有价值的信息比如某个模型在特定类型的输入上系统性失败这种发现比整体指标更有指导意义。5. 从评测结果到选型决策5.1 如何解读 cost-per-success 的差异算出数值只是第一步关键是解读。我的经验是分三步走看绝对水平、看相对差距、看业务容忍度。绝对水平告诉你这个方案在经济上是否可行。如果 cost-per-success 换算成实际货币后已经超过了业务能承受的上限那这个方案直接出局不用再比了。相对差距告诉你模型之间的优劣是否显著。如果两个模型差距在 10% 以内我一般会认为它们在经济性上属于同一档这时候可以引入其他因素比如延迟、稳定性、生态支持来做决策。业务容忍度则是最后的调节阀如果业务对成功率极其敏感那就不能只看 cost-per-success还要设一个成功率的下限门槛。5.2 多维度决策矩阵的构建Cost-per-success 是核心指标但不应该是唯一指标。我通常会构建一个简单的决策矩阵把几个关键维度都列进去给每个维度赋权重最后算加权得分。维度权重模型甲模型乙模型丙Cost-per-success40%0.1140.2680.076平均延迟20%1.8s1.2s2.5s格式稳定性20%95%98%90%生态与文档10%好很好一般服务稳定性10%高高中权重的设定没有标准答案取决于你的业务特点。实时交互场景延迟权重要高批量处理场景成本权重要高。关键是把权重和理由写下来这样决策过程可追溯后续复盘也有依据。5.3 决策后的持续监控选型不是终点而是起点。上线之后要持续监控实际运行数据验证评测结论是否成立。我一般会关注三个指标实际 cost-per-success 与评测值的偏差、成功率的变化趋势、成本结构的变化。如果实际值比评测值差很多说明评测环境和真实环境有差距需要回头检查评测集和判定逻辑。如果成功率持续下降可能是模型漂移或者业务场景变化需要重新评测。如果成本结构变化比如重试率上升说明模型的稳定性在下降也要引起注意。监控数据积累多了之后你甚至可以建立一个预测模型根据历史数据预估不同模型在未来流量下的表现让选型决策从一次性动作变成持续优化的过程。6. 一些实操中的个人体会这套方法我用了挺长时间踩过的坑也不少分享几个印象比较深的。第一个体会是评测集的质量比评测方法的复杂度重要得多。我早期花了很多精力设计复杂的评分算法结果发现评测集本身就有偏差算出来的结论自然不准。后来我把重心放到评测集的构建上从真实日志里采样、分层标注、定期更新结论的可信度一下子就上来了。第二个体会是成本核算要保守一点。我倾向于把能算进去的成本都算进去宁可高估也不要低估。因为选型时低估成本上线后超支的代价更大。特别是重试成本和后处理成本很多人不算但这两块在实际运行中占比可能很高。第三个体会是不要追求一次评测就找到最优解。模型在变业务在变最优解也在变。把评测当成一个持续的过程建立好基础设施定期复跑比一次性投入大量精力做完美评测更实际。最后一个建议把评测结果和决策理由文档化。我当时选某个模型的时候把评测数据、决策矩阵、权重理由都写进了一个文档。半年后业务方问为什么选这个模型我直接把文档翻出来省了很多解释成本。而且后来模型更新时这份文档也成了重新评估的基线非常有用。这套方法不复杂但需要耐心和细致。真正跑通一轮之后你会发现模型选型从“凭感觉”变成了“看数据”决策质量会有明显提升。 
长河君 · 2026/10/22 23:46:05 · 阅读 1.2k 模型选型新指标：用cost-per-success替代传统评测
1. 为什么传统的模型评测指标正在失效做过模型选型的人大概都有过这种体验花了两周时间跑完一轮评测准确率、F1、AUC 各项指标都列得整整齐齐团队开会一看A 模型比 B 模型高了 1.2 个百分点于是拍板选了 A。结果上线跑了三个月账单出来傻眼了——A 模型的调用成本是 B 模型的四倍而那 1.2 个百分点的提升在业务侧几乎感知不到。这不是个例。我参与过好几次模型选型的评审发现一个很普遍的问题大家习惯用学术 benchmark 的思维来做工程决策。学术评测关心的是模型在固定数据集上的表现上限但工程选型关心的是在给定预算下这个模型能不能稳定地把事情办成。这两个目标之间的差距就是 cost-per-success 这个指标要填的坑。先说清楚它是什么。Cost-per-success直译过来就是“每次成功成本”核心公式很简单Cost-per-success 总投入成本 / 成功完成的任务次数这里的“成功”不是模型输出了一个看起来像样的回答而是这个回答在业务链路上真正被采纳、被消费、产生了预期效果。比如客服场景里用户没有转人工、没有二次追问、对话正常结束这才算一次 success。内容生成场景里生成结果直接可用、不需要人工返工修改才算一次 success。它解决的核心问题是把模型的语言能力指标翻译成业务侧能算清楚账的经济指标。适合谁来用三类人最需要一是做 AI 应用落地的工程负责人二是需要向管理层汇报选型依据的技术管理者三是自己搭产品、每一分 API 费用都要精打细算的独立开发者。哪怕你只是偶尔调几个模型做对比理解这个思路也能帮你少花冤枉钱。2. 拆解 cost-per-success 的构成要素2.1 成本侧到底该算哪些账很多人一算成本就只盯着 API 的 token 单价这是最容易踩的坑。真实的成本结构至少包含四层我按从显性到隐性的顺序列一下成本层级具体内容是否常被忽略直接调用成本输入/输出 token 费用、图片/音频处理费否大家都会算重试与纠错成本失败重试、格式修复、二次调用经常被忽略后处理成本结果校验、人工审核、格式转换经常被忽略机会成本延迟导致的用户流失、并发受限的扩容费几乎没人算直接调用成本最好算按官方定价乘以实际消耗量就行。但重试成本往往被低估得厉害。我实测过一个结构化抽取任务某模型首次输出 JSON 格式正确的概率只有 70% 左右剩下 30% 需要重试或者用规则修补。这意味着它的实际成本是标称价格的 1.4 倍以上而另一个格式稳定性更好的模型虽然单价贵 20%综合下来反而更便宜。后处理成本更隐蔽。如果模型输出需要人工抽检那这部分人力成本必须摊进去。我一般会用一个粗略系数需要人工介入的比例乘以单次人工处理的时间成本再除以总任务量。机会成本则要看业务场景实时对话场景里延迟每增加一秒用户放弃率可能上升几个百分点这部分损失很难精确量化但选型时至少要有个定性判断。2.2 成功侧怎么定义才算合理“成功”的定义是整个指标里最需要和业务方对齐的部分定义错了后面算得再精确都是白搭。我通常把成功判定分成三个层次硬性成功结果完全符合预期可直接使用无需任何人工干预。这是最严格的定义。软性成功结果基本可用但需要轻微调整比如改个措辞、补个字段人工介入时间在可接受阈值内。业务成功从最终业务结果倒推比如用户满意度达标、任务闭环完成中间可能有多次模型调用。选哪个层次取决于你的场景容忍度。做批量数据处理我建议用硬性成功因为人工返工的成本会吃掉所有收益。做创意辅助类工具软性成功更合理因为本来就需要人来把关。做端到端的自动化流程业务成功才是唯一有意义的定义。这里有个实操心得定义成功时一定要写清楚判定规则最好能自动化判定。我见过团队用“感觉还行”来标注成功结果两个人标同一批数据一致率不到 60%这种数据算出来的 cost-per-success 完全没有参考价值。能自动判定的就写脚本判定不能自动判定的就制定明确的评分卡把主观判断压缩到最小。2.3 为什么这个指标比单一维度更有决策力单看准确率你会选那个分数最高的。单看成本你会选那个最便宜的。但现实决策往往是在两者之间找平衡点而 cost-per-success 天然就是这个平衡点的量化表达。举个我实际遇到的例子。三个模型做同一批工单分类任务各跑 1000 条模型单价相对值准确率格式合规率综合成功率总成本Cost-per-success模型甲1.092%95%87.4%1000.114模型乙2.595%98%93.1%2500.268模型丙0.688%90%79.2%600.076单看准确率模型乙最好。单看成本模型丙最便宜。但 cost-per-success 告诉你模型丙每成功处理一个工单只要 0.076 个单位成本是模型乙的三分之一不到。如果业务对准确率的要求不是极端苛刻模型丙显然是更理性的选择。这个结论用单一指标是得不出来的。3. 搭建一套可复现的评测流程3.1 评测集的设计原则评测集的质量直接决定结论的可信度。我的经验是遵循三个原则代表性、分层性、可判定性。代表性指的是评测样本要覆盖真实流量的分布。很多人图省事从网上找一个公开数据集就开始跑但公开数据集的分布和你的业务分布可能差很远。我一般会从真实业务日志里随机抽样如果历史数据不够就人工构造一批贴近真实场景的样本。样本量不用特别大200 到 500 条通常就能看出趋势但一定要覆盖主要的使用模式。分层性是指把评测集按难度或类型分层。比如对话任务可以分成简单问答、多轮推理、边界情况三层分别统计各层的成功率。这样你不仅知道哪个模型整体更好还知道它在哪类任务上更强选型时可以针对性取舍。可判定性是最容易被忽视的。每条样本都要有明确的预期输出或者判定标准能自动判定的优先自动判定。对于开放式生成任务可以设计一个评分卡从相关性、完整性、格式合规等维度打分设定及格线。我通常会把判定脚本和评测集一起维护这样换模型重跑时不需要重新标注。3.2 成本数据的采集方法成本采集要做到颗粒度足够细才能支撑后续分析。我一般会记录每次调用的以下字段# 单次调用成本记录结构示例 call_record { task_id: task_001, model_name: model_a, input_tokens: 850, output_tokens: 320, retry_count: 1, # 重试次数 latency_ms: 2400, # 延迟 is_success: True, # 是否成功 post_process_time: 0, # 后处理耗时秒 timestamp: 2024-01-15T10:30:00 }有了这些原始记录成本计算就是简单的聚合。直接成本按 token 单价算重试成本把重试次数乘上去后处理成本按人工时薪折算。延迟数据单独统计用于评估机会成本。注意不同模型的计费方式可能不一样有的按 token 计费有的按调用次数计费有的对输入输出分别定价。采集前一定要把计费规则搞清楚否则算出来的成本会失真。3.3 成功判定的自动化实现成功判定能自动化就自动化这是保证评测可复现的关键。对于结构化输出任务判定逻辑很直接解析输出检查字段是否齐全、类型是否正确、值是否在合理范围内。对于文本生成任务可以用规则加模型结合的方式判定。我常用的一个模式是“规则初筛 模型复核”。先用规则快速过滤掉明显不合格的输出比如格式错误、长度异常、包含禁用词剩下的用一个小模型或者评分脚本做质量打分。这样既保证了效率又比纯规则判定更准确。def judge_success(output, expected, task_type): 成功判定示例 if task_type structured: try: parsed json.loads(output) # 检查必需字段 for field in expected[required_fields]: if field not in parsed: return False, missing_field # 检查字段值范围 if not validate_ranges(parsed, expected[ranges]): return False, out_of_range return True, ok except json.JSONDecodeError: return False, invalid_json elif task_type open_ended: score quality_score(output, expected[criteria]) return score expected[threshold], fscore_{score}判定脚本要跟着评测集一起版本管理每次修改判定逻辑都要记录否则不同时间跑出来的结果没法对比。4. 实操中的关键细节与避坑经验4.1 样本量不足时的处理策略理想情况下评测集越大越好但现实中经常面临样本不够的问题。我的做法是先跑小样本看趋势再决定是否扩大。如果两个模型的 cost-per-success 差距在 20% 以上200 条样本通常就能稳定区分。如果差距在 5% 以内那可能需要上千条样本才能确认差异是否显著这时候就要权衡评测成本了。另一个技巧是用置信区间代替单点估计。不要只报一个 cost-per-success 数值而是报一个区间。比如“模型甲的 cost-per-success 在 0.10 到 0.13 之间”这样决策者能直观看到不确定性。计算方法可以用 bootstrap 重采样跑个几百次就能得到比较稳定的区间。4.2 模型版本漂移的应对模型是会变的。服务商可能悄悄更新模型权重或者调整默认参数导致你上个月测的结果这个月就不准了。我踩过这个坑一个模型连续三个月评测都是最优第四个月突然成功率掉了 8 个百分点排查半天才发现是服务商更新了版本。应对方法有两个。一是在评测记录里固定模型版本号如果服务商支持指定版本就指定不支持就在评测时记录调用日期方便追溯。二是建立定期复测机制重要的选型决策不要一测定终身每隔一段时间用同一套评测集重跑一次监控指标变化。如果发现明显漂移及时重新评估。4.3 多模型组合的成本优化有时候最优解不是选一个模型而是组合使用。比如用便宜模型处理简单任务用贵模型处理复杂任务整体 cost-per-success 可能比单用任何一个都低。这个思路叫“模型路由”或“级联”。实现方式很简单先用一个轻量分类器或者规则判断任务难度简单任务走便宜模型复杂任务走贵模型。关键是找到合适的分流阈值。我的做法是画一条曲线横轴是分流比例纵轴是整体 cost-per-success找到曲线的最低点对应的分流比例。分流策略简单任务占比整体成功率整体成本Cost-per-success全用便宜模型100%79.2%600.076全用贵模型0%93.1%2500.268分流阈值A60%85.3%1360.159分流阈值B75%82.1%1080.132这个例子里分流策略 B 的 cost-per-success 是 0.132虽然比全用便宜模型的 0.076 高但成功率从 79.2% 提升到了 82.1%。如果业务对成功率有底线要求这个组合就是更合理的选择。具体选哪个点取决于你对成功率的容忍下限。4.4 常见问题速查表问题现象可能原因排查方向解决建议成本算出来远高于预期重试成本未计入检查重试日志把重试次数纳入成本公式成功率异常高判定标准太宽松复核判定脚本收紧成功定义增加校验维度不同模型对比结果不稳定样本量不足或分布偏差扩大样本、分层统计增加样本量按任务类型分层评测结果与线上表现不符评测集与真实流量分布不一致对比评测集和线上日志分布重新采样贴近真实分布模型表现突然下降模型版本更新检查版本号和调用日期固定版本建立复测机制提示评测过程中遇到任何异常数据先别急着删掉。异常样本往往藏着最有价值的信息比如某个模型在特定类型的输入上系统性失败这种发现比整体指标更有指导意义。5. 从评测结果到选型决策5.1 如何解读 cost-per-success 的差异算出数值只是第一步关键是解读。我的经验是分三步走看绝对水平、看相对差距、看业务容忍度。绝对水平告诉你这个方案在经济上是否可行。如果 cost-per-success 换算成实际货币后已经超过了业务能承受的上限那这个方案直接出局不用再比了。相对差距告诉你模型之间的优劣是否显著。如果两个模型差距在 10% 以内我一般会认为它们在经济性上属于同一档这时候可以引入其他因素比如延迟、稳定性、生态支持来做决策。业务容忍度则是最后的调节阀如果业务对成功率极其敏感那就不能只看 cost-per-success还要设一个成功率的下限门槛。5.2 多维度决策矩阵的构建Cost-per-success 是核心指标但不应该是唯一指标。我通常会构建一个简单的决策矩阵把几个关键维度都列进去给每个维度赋权重最后算加权得分。维度权重模型甲模型乙模型丙Cost-per-success40%0.1140.2680.076平均延迟20%1.8s1.2s2.5s格式稳定性20%95%98%90%生态与文档10%好很好一般服务稳定性10%高高中权重的设定没有标准答案取决于你的业务特点。实时交互场景延迟权重要高批量处理场景成本权重要高。关键是把权重和理由写下来这样决策过程可追溯后续复盘也有依据。5.3 决策后的持续监控选型不是终点而是起点。上线之后要持续监控实际运行数据验证评测结论是否成立。我一般会关注三个指标实际 cost-per-success 与评测值的偏差、成功率的变化趋势、成本结构的变化。如果实际值比评测值差很多说明评测环境和真实环境有差距需要回头检查评测集和判定逻辑。如果成功率持续下降可能是模型漂移或者业务场景变化需要重新评测。如果成本结构变化比如重试率上升说明模型的稳定性在下降也要引起注意。监控数据积累多了之后你甚至可以建立一个预测模型根据历史数据预估不同模型在未来流量下的表现让选型决策从一次性动作变成持续优化的过程。6. 一些实操中的个人体会这套方法我用了挺长时间踩过的坑也不少分享几个印象比较深的。第一个体会是评测集的质量比评测方法的复杂度重要得多。我早期花了很多精力设计复杂的评分算法结果发现评测集本身就有偏差算出来的结论自然不准。后来我把重心放到评测集的构建上从真实日志里采样、分层标注、定期更新结论的可信度一下子就上来了。第二个体会是成本核算要保守一点。我倾向于把能算进去的成本都算进去宁可高估也不要低估。因为选型时低估成本上线后超支的代价更大。特别是重试成本和后处理成本很多人不算但这两块在实际运行中占比可能很高。第三个体会是不要追求一次评测就找到最优解。模型在变业务在变最优解也在变。把评测当成一个持续的过程建立好基础设施定期复跑比一次性投入大量精力做完美评测更实际。最后一个建议把评测结果和决策理由文档化。我当时选某个模型的时候把评测数据、决策矩阵、权重理由都写进了一个文档。半年后业务方问为什么选这个模型我直接把文档翻出来省了很多解释成本。而且后来模型更新时这份文档也成了重新评估的基线非常有用。这套方法不复杂但需要耐心和细致。真正跑通一轮之后你会发现模型选型从“凭感觉”变成了“看数据”决策质量会有明显提升。