企业官网建设流程全解析

1. 为什么要用 cost-per-success 重新审视模型评测

做模型选型评测这件事，我一直觉得行业内有个指标被严重低估了，就是 cost-per-success，直译过来是“单次成功成本”。这个词在海外团队的工作流里已经很常见，但国内技术社区聊得还不多。很多人选模型还在比 benchmark 分数、比推理速度，却忽略了真正该问的问题：跑通一条业务链路，平均每成功一次，到底要花多少钱。

先说清楚它解决什么问题。假设你有两个模型，A 便宜但准确率低，B 贵但准确率高。只看准确率，B 肯定赢；只看价格，A 肯定赢。但业务方真正关心的是“花出去的钱换回来了多少有效结果”。如果一个便宜模型在 70% 的情况下能给出可用的输出，每次成本 0.01 元，而贵模型 95% 的情况下都可用，每次成本 0.05 元，那么前者的单次成功成本是 0.014 元，后者是 0.053 元。前者反而更划算——前提是你愿意接受那 30% 的失败率带来的后续处理成本。这个权衡，就是 cost-per-success 存在的意义。

这篇文章适合谁看？适合正在做 LLM 应用落地、需要在多个模型之间做技术选型的人，尤其是负责 prompt 评测、成本治理、API 接入的工程师和团队负责人。我不打算讲太多理论，会直接把我踩过的坑、试过的方法、调整过的参数全部摊开来。

我自己是在一个模拟项目 X 里被逼着认真对待这个指标的。当时团队要上线一个批量信息抽取功能，候选模型有三四个，每个都宣称自己“效果不错”。如果只看人工抽检的准确率，贵的那个模型确实领先，但差距其实没有大到必须加钱的地步。后来我把所有开销拉通算了一遍——API 费用、失败重试的费用、人工复核的成本——才意识到按“单次成功成本”算，结论完全变了。这也是我写这篇文章的初衷：把一套可执行、可复现的评测流程分享出来，帮你在做模型选型时少走弯路。

这个指标本质上把三个维度捏在了一起：模型质量、推理成本、业务对失败的容忍度。它不是要替代准确率或延迟这类基础指标，而是把它们统一到一个业务语言里。接下来我会从指标拆解、评测集构建、实操流程、常见问题四个角度展开，每一步都会给出可以直接照抄的做法。

2. 核心指标拆解：成本怎么算，成功怎么定义

2.1 成本侧：不是只有 API 单价那么简单

很多人一听到 cost-per-success 就以为只是算 API 调用单价，这是最常见的误解。API 单价只是最表层的一部分。真正把成本拉通，至少要包含下面几项。

第一项是推理成本。对于按 token 计费的模型，就是输入 token 数乘以输入单价，加上输出 token 数乘以输出单价。但这里有个容易忽略的细节：不同模型的输入输出定价可能差异巨大，而且有的平台对缓存命中还有折扣，忽略这些会直接导致估算偏差。在模拟项目 X 里，我见过某个模型输入便宜得惊人，但输出价格是另一个模型的几倍，而抽取类任务往往输出 token 占比很高，最后总成本根本没有优势。

第二项是失败重试成本。模型返回的结果如果是空、是乱码、或者是不可解析的格式，业务脚本通常会自动重试一次甚至多次。每次重试都会消耗 token，这些消耗在预算报表里不显眼，但累积起来很可观。我在评测时会把“一次任务平均触发几次重试”这个参数单列出来，计入总成本。

第三项是人工复核成本。如果你做的是金融、医疗这类要求高可靠性的场景，机器输出的结果大概率还需要人工抽检或全检。这里的人工时间也需要折算成钱。即便不是全检，为了评估模型质量而做的抽检本身也是成本，只不过它发生在评测期间，而不是生产环境里。我建议把它分开记录，方便后期优化。

我常用的总成本公式长这样：

总成本 = 调用次数 × (输入 token 数 × 输入单价 + 输出 token 数 × 输出单价) + 重试次数 × 平均单次重试成本 + 人工复核工时 × 时薪折算

这个公式没有把固定成本算进去，比如评测脚本的开发时间、测试环境的维护成本，因为这些属于基础设施投入，不随模型选型变化。如果你想让数字更精确，也可以把 prompt 调优的人力成本摊进每一次调用里，但一般情况下没必要那么精细。

2.2 成功侧：业务定义比 LLM-as-Judge 更重要

cost-per-success 的难点其实不在 cost，而在 success。什么是“成功”？不同任务有完全不同的答案。拿分类任务举例，只要输出符合预设标签就算成功；拿抽取任务举例，关键实体必须全部命中、格式必须严格合法；拿开放性生成举例，成功与否往往需要人工判断，甚至需要业务方亲自参与定义标准。

在模拟项目 X 的第一个版本里，我们用了比较偷懒的标准：只要模型返回的 JSON 能解析就算成功。结果评测出来的 cost-per-success 很低，看起来很美，但实际上返回里有很多“看似合法、实则错误”的抽取结果，比如把时间字段提取成了地点信息。这个教训告诉我：成功定义必须落在业务结果层，不能落在格式层。

好的成功判定标准应该具备三个特点：

• 可自动化：能通过代码、规则或结构化比对来判断，减少人工成本
• 与业务目标对齐：业务系统真正依赖什么，评测就判断什么
• 有明确的失败分类：能区分“格式错误”“内容错误”“语义错误”“拒答”，这样后续才能针对性优化 prompt

我建议把成功标准写成一个打分表。满分 1.0，只要核心字段全部正确且格式合法就算 1.0；核心字段部分正确给 0.5，比如 5 个字段抽取对了 3 个；完全不可用给 0。这样算出来的 cost-per-success 更有弹性，也更能反映模型在真实场景下的表现差异。

3. 评测集设计与场景覆盖：别让一个小数据集决定你未来几个月的成本

3.1 评测集的数据来源与采样策略

评测集是整个 cost-per-success 评测流程的基石。数据太少，模型之间的差距可能压根不明显；数据太偏，得出的结论用在生产环境就会翻车。我一般建议评测集至少覆盖 200 条真实业务输入，而且必须要有标签或人工复核过的标准答案。如果业务本身就冷启动，没有历史标注数据，那就退而求其次：从已上线的规则系统中抽取结果，或者让标注团队先快速打一批启动数据。

数据来源上要做分层采样。如果你的任务按消息类型分 A、B、C 三种，每种类型实际占比是 70%、20%、10%，那评测集也应该按这个比例来采，而不是均匀分布。以模拟项目 X 为例，我们当时要做的是把用户工单里的“问题类型”“紧急程度”“涉及产品”抽出来，如果不做分层，而是随机从历史工单里抽 300 条，因为“问题类型”为“其他”的样本特别多，最终评测结果就会偏向那种简单样本，完全反映不出模型的真实能力。

还要加一点对抗样本。所谓对抗样本，就是那些正常情况下最让模型犯难的输入，比如长文本、混合语言、手写体 OCR 结果、带误导信息的输入、空字段占位符等。这些样本数量不需要多，占总量的 10% 左右就够，但必须存在。因为它们能暴露低端模型真正的短板。

我当时会在同一个评测集上跑三个模型，前两轮结果基本接近，差距就是在对抗样本那一小批上拉开的。如果不做对抗样本，会误以为便宜模型和贵模型差不多，从而选择一个在真实场景中频繁崩溃的模型。

3.2 评测集的标注与动态维护

标注是评测集里最肉疼的部分。300 条数据如果全部重新标注，按单条 2 分钟算，一个人也得干一整天。所以我的建议是：先让模型输出，再做人工校对，而不是从零开始纯人工标注。这样可以节省一半以上的时间。这种“人工校对模型输出”的做法还能顺带检查一下历史系统的输出质量，一举两得。

评测集不是静态的。大模型迭代快，prompt 也在不断调，数据集如果一直不变，会出现一个很微妙的问题：模型可能已经在评测集上过拟合了。这里的过拟合不是传统机器学习意义上的参数过拟合，而是某种“评测集记忆效应”——模型或 prompt 在反复调试中对特定样本产生了偏向。这种偏向会让评测结果虚高，但放回真实场景就失效。

我习惯每两周做一次评测集增量扩充，每次增加 30 到 50 条新鲜样本，并手动剔除那些质量问题数据。这个做法让 cost-per-success 指标长期保持可信度，而不是沦为一个数字游戏。

3.3 评测集大小与置信度计算

评测集大小直接影响结果的可靠性。300 条数据看起来不少，但如果成功率的差异只在 3 个百分点以内，统计学上根本无法判定两个模型谁更强。这里有一个简单的估算方法：假设成功率 p=0.9，样本量 n=300，那么 95% 置信区间大约是 p ± 1.96 × sqrt(p(1-p)/n)，算出来是 ±0.034，也就是 ±3.4 个百分点。两个模型成功率差距在 3 个点以内，结论基本是“无法区分”。

所以如果你的评测集只有 50 条，就别指望能准确区分“成功 45 条”和“成功 47 条”之间的差别。真实业务里模型之间的差距往往比想象中小，这时候要么扩大评测集，要么引入更精细的成功评分体系，让区分度从“成功/失败”变成 0 到 1 之间的连续值。我在实操中会把成功率细粒度化，比如按字段得分加权平均，用这种方式提高统计辨识度。

4. 从单次成本到成功成本：手把手搭建评测流程

4.1 明确评测流程的五步框架

专门做一次 cost-per-success 评测，不一定需要一个多么复杂的平台。我用一个脚本加一张电子表格就能跑通整个流程，关键在于步骤要完整。下面是我跑过多轮评测后固定下来的五步法，供你参考。

• 第一步：定义业务场景与成功标准。写清楚“通过模型输出的哪个字段，业务系统能完成什么操作”，然后据此确定打分规则。
• 第二步：搭建评测集。按业务分层采样，加上对抗样本，完成标注或校对。
• 第三步：跑模型推理。在统一环境下，保持同一套 prompt，只换模型，记录 token 用量、耗时、输出结果。
• 第四步：判定成功并计算成本。对每条输出打分，同时把 token 成本、重试成本、人工复核成本全部折算进去。
• 第五步：汇总对比，做决策。计算每个模型的 cost-per-success、成功率、平均成本、失败后重试成本，形成选型建议。

这个五步流程看起来不复杂，但每一步都有不少细节。下面我重点展开第三步和第四步，因为这两步直接决定了评测数据的可信度。

4.2 模型推理时的环境控制

跑评测时最怕变量不统一。一个常见错误是，测试 A 模型时用的是 prompt 版本 v1，测试 B 模型时 prompt 被顺手调整成了 v2，结果评测出来的差异根本不知道是模型带来的还是 prompt 带来的。所以正规做法是：同一个任务、同一套 prompt、同一个温度参数，只改模型名称。如果某个模型对 prompt 格式特别挑剔，可以在评测前做单独记录，但仍要在相同基础 prompt 上跑一轮“公平赛”。

有的模型平台还有各自的默认参数，比如 temperature 是 0.7 或者 1.0，top_p 是 0.9 或者 1.0。这些参数会直接影响输出的随机性，从而影响成功判定结果。评测时我一般把温度固定为 0，如果平台不允许 0，就用一个较低值如 0.1，并记录下来，防止后期换模型时因为参数不一致导致结果失真。

还要注意并发问题。评测脚本如果用并发请求来提高速度，实际上会在不同模型间引入隐藏变量：某些平台并发高时延迟增加，甚至可能触发限流，导致输出截断或重试，进而影响成功率和成本。我在模拟项目 X 的评测里吃过这个亏，后来强制让每个模型每批次只跑 10 个并发，并且记录了最高延迟时间和 95% 延迟分位数，用来辅助判断生产环境下的延迟成本。

4.3 成本核算的具体演示

为了让你更直观地理解 cost-per-success 的计算过程，我模拟一个具体场景。假设我们要评测 300 条工单抽取任务，候选模型有两个：模型 A 和模型 B。价格和表现如下：

• 模型 A：输入单价 0.002 元/千 token，输出单价 0.006 元/千 token，平均每条输入 800 token，输出 200 token，成功率 85%，其中失败重试率 30%（每次重试同样消耗 token），重试一次后的成功率为 40%。
• 模型 B：输入单价 0.005 元/千 token，输出单价 0.02 元/千 token，平均每条输入 800 token，输出 220 token，成功率 95%，失败重试率 10%，重试一次后的成功率为 60%。

先算模型 A 的单次推理成本：

0.002 × 800 / 1000 + 0.006 × 200 / 1000 = 0.0016 + 0.0012 = 0.0028 元

那 300 条直接全部跑一次的成本是 0.84 元。但因为有 30% 的失败重试，45 条会触发重试，每条重试额外花费同样的 0.0028 元，45 × 0.0028 = 0.126 元。最终成功条数：255 + 18 = 273。总成本 0.966 元，cost-per-success 约为 0.0035 元。

再看模型 B 的单次推理成本：

0.005 × 800 / 1000 + 0.02 × 220 / 1000 = 0.004 + 0.0044 = 0.0084 元

重新跑一遍的成本是 2.52 元。失败率 5%，15 条触发重试，每条重试成本同样 0.0084 元，15 × 0.0084 = 0.126 元。成功条数：285 + 9 = 294。总成本 2.646 元，cost-per-success 约为 0.009 元。

从 cost-per-success 角度看，模型 A 大约是模型 B 的三分之一。但别急着选 A，因为上面的计算还没有考虑人工复核成本。如果业务要求 100% 正确输出，A 有 27 条失败，每一条都需要人工介入修复；B 只有 6 条。假设人工修复一条需要 0.1 元，A 的总成本要再加 2.7 元，B 加 0.6 元，最终 A 的 cost-per-success 是 0.013 元，B 是 0.011 元。结论直接反转。

这就是 cost-per-success 和单纯看 API 单价最大的不同：它会逼你把后处理的账也算进去，算完才发现便宜模型可能并没有真正便宜。

4.4 成功率之外的辅助指标：P50 延迟与失败分布

cost-per-success 是核心决策指标，但我不建议只看这一个数。辅助指标至少还要看两个：一个是延迟分布，一个是失败分布。

延迟分布用 P50 和 P95 两个值就够了。P50 代表一般情况下的响应速度，P95 代表最差情况下的体验。如果两个模型的 cost-per-success 差不多，P95 延迟短的那个通常更适合生产环境，因为长尾延迟会带来超时、重试、排队等一系列连锁反应，这些反应最终又会反馈到成本里。

失败分布要看失败类型是不是集中在某类样本上。如果失败全部发生在对抗样本或长尾样本上，处理起来会比较危险，因为这种失败在生产环境里几乎不可预知。如果失败均匀分布在普通样本上，反而更好优化——调整 prompt 或加 few-shot 示例能快速见效。在模拟项目 X 的评测里，我们发现模型 A 的失败样本里有 70% 都是“混合语言输入”，后来单独给这类样本加了预处理逻辑，成功率立刻提高，成本也顺势下降。

5. 模型选型评测中我踩过的坑，和对应的排查思路

5.1 评测集太小的坑，怎么判断才算“够”

有一段时间为了赶项目进度，我们只用 60 条测试数据跑了一轮评测，结果临时选了一个便宜模型上线。上线后真实成功率比评测结果低了整整 10 个百分点，排查了很久才发现是评测集太小，且恰好偏简单。从那以后我定了一个规矩：任何选型评测少于 150 条数据，不做决策，如果业务更复杂，建议 300 条起步。

判断“够不够”的方法，除了用置信区间估算，还有一个更实操的手段：把评测集切分成“普通样本”和“对抗样本”两部分来看，如果两部分模型表现的差距稳定，说明评测集样本量已经能反映出稳定的模型水平；如果每一轮跑的结果波动都很大，比如同一模型成功率忽高忽低，那大概率是样本量不足。

5.2 成功标准的主观性，怎么从评分表里挤掉水分

成功标准如果只靠“我看一下结果，觉得行就行”，成本核算必然失真。因为不同评估者会觉得“行”的标准不一样。为了尽量挤掉水分，我建议做两件事：

一是把评分标准量化。核心字段必须全部吻合才给满分，每个字段都给权重，比如“问题类型”权重 0.4、“涉及产品”权重 0.3、“紧急程度”权重 0.3。模型输出和标准答案完全一致，得 1.0；漏了一个字段，按权重扣分；完全偏离，得 0。这样我就有了可计算的分数，而非“好”“坏”两个模糊字眼。

二是让两个人同时评估同一批样本，做一致性校验。人工评估本来就是有噪声的，两个人的标准有差异很正常，但如果差异大到总分相差超过 0.2，说明评分标准还写得太含糊，需要继续拆细。这种做法不完美，但能把主观性控制在一个可以接受的区间内。

5.3 价格波动与缓存命中，如何让成本对比更公平

模型价格不是一成不变的。有些平台会在一定时间段内调整价格，有的还会习惯性用“首月优惠”“限时折扣”来吸引用户。评测时要特别注意：价格永远以“当前的正式商用价格”为准，而不是拿优惠价格去算成本。我曾经在评测时用了一个平台的新用户体验券，算出来的 cost-per-success 非常诱人，但项目真正上线之后，成本直接翻倍。

缓存命中也是一个隐形变量。很多平台对输入前缀做缓存，如果评测脚本反复使用相同的前缀 prompt，会得到缓存折扣价，从而低估实际成本。为了评测公平，我会故意在每条输入前加一个随机变化的用户 ID 占位变量，把缓存的影响消除，或者分别在“有缓存”和“无缓存”两种模式下记录成本，然后按照生产环境中可能的缓存命中率做折算。

5.4 随机性与可复现性，怎么判断两次答案的不同不是bug

大模型输出有随机性，即便温度设为 0，某些平台仍可能因为负载均衡或模型版本不同，给出不一样的结果。评测中最让人头疼的，就是模型表现一会儿高一会儿低，不知道是模型本身的问题，还是随机波动。

我的排查思路是：当成功率出现明显波动时，对同一批数据至少跑 3 轮，观察波动范围。如果 3 轮结果的成功率波动超过 5 个百分点，说明模型随机性太大，不适合做高稳定性业务。这种情况下，需要检查是不是温度参数没设对、或者是网络超时导致半截输出被判断为成功/失败。自动脚本里我会打印每次调用的 HTTP 状态码和响应长度，方便定位这类问题。

6. 进阶玩法：把 cost-per-success 变成动态监控指标

6.1 从一次性评测变成线上定期巡检

如果团队有稳定的评测集，完全可以把这个流程从“选型时跑一次”升级为“每周自动跑一次”，用来监控已上线模型的健康度。尤其在生产环境中，模型版本被平台悄悄升级、某个预设参数被改动、或者输入分布发生偏移，都会导致 cost-per-success 明显上升。一旦这个数字超过预设阈值，就触发告警，让负责人介入调查。

我实践下来的做法是：每周日凌晨通过定时任务跑一遍 300 条数据的完整评测，把得到的 cost-per-success 和成功率、P95 延迟汇总到一张表里。连续 3 轮对比如果都呈上升趋势，即使还没有超过阈值，也会主动去排查一下原因，而不是等到线上出现异常再处理。

6.2 多任务加权：不同业务线的 cost-per-success 怎么汇总

一个公司往往有不止一个模型场景。内容审核做一个评测，智能客服做一个评测，信息抽取又做一个评测。不同任务的“成功”定义不同，成本结构也不同，简单加总没有意义。我建议用业务比例加权来汇总：假设内容审核占业务量的 60%，智能客服占 40%，那整体 cost-per-success = 内容审核的 cost-per-success × 0.6 + 智能客服的 cost-per-success × 0.4。

这个加权的价值在于：它可以帮助评估“使用同一个大模型统一处理所有任务”是否比“不同任务用不同模型”更经济。有些场景会用分开的模型各自达到最优的 cost-per-success，但维护成本上升；有些场景用一个大模型虽然单项不是最优，但统一维护和缓存命中率更高，总账反而划算。这个决策用加权的 cost-per-success 来衡量，比凭感觉判断靠谱得多。

6.3 联动 prompt 优化：以 cost-per-success 为核心指标迭代

prompt 优化的目标也应该围绕 cost-per-success，而不是单纯提升准确率。举个例子，在二元分类任务中，加上一段 few-shot 示例，准确率从 90% 提升到了 93%，但输出 token 数量增加了 40%。算下来成本上升，成功率的提升又不足以抵消成本，这种情况下优化后的 prompt 反而更差。如果不看 cost-per-success，只看准确率，很容易做出反向优化。

我自己一般会记录每一个 prompt 版本的 cost-per-success，建立一条“优化曲线”。曲线右移代表效果提升但成本增加，曲线下移代表在更低的成本下取得了更好的效果。只有当成本侧和效果侧同时优化，或者单侧改善而另一侧不劣化的时候，我才会确认这一版 prompt 优化是有效的。

7. 评测报告的呈现方式与决策建议

7.1 单页报告该有的几个模块

评测做完后，需要给团队或上级一个直观的呈现，而不是丢出一堆原始数据。我的建议是单页报告，包含四个模块就够了：

• 评测说明：评测集规模、采样方式、成功判定标准
• 成本对比表：每个模型的总成本、成功率、cost-per-success、重试率、延迟分位数
• 细分场景分析：普通样本与对抗样本的分别表现，各失败类型的占比
• 推荐结论：基于 cost-per-success 和风险分析，给出“建议优先”“可以考虑”“不建议”三个档位的结论，并附上原因

7.2 一张对比表说清楚问题

我在模拟项目 X 的评测报告里，做过下面这样一张表，效果非常好：

看完表的第一个感觉是模型 C 最划算，因为它的 cost-per-success 最低。但我们在报告下面还会写一行字：如果业务量达不到一定规模，选 C 的绝对成本优势可能不足以覆盖团队切换 SDK、更新配置文件、重写部分适配逻辑的成本。也就是说，最终决策还要考虑迁移成本，不能完全只看 cost-per-success。

8. 从评测到长期监控：一些个人心得

做模型选型评测这几年，我有一个很深的体会：指标本身不会替你决策，但它能帮你把模糊的争论变成清晰的对比。以前团队里争论“A 模型效果好，B 模型便宜”，永远吵不出结果，因为比较维度不在一个平面上。自从大家都用 cost-per-success 说话，讨论就变得非常高效——每个模型的优劣变成了可量化的数值，争议自然就少了。

还有一个实用的技巧是：每次评测把原始结果存一份快照，包括模型版本号、评测脚本版本、prompt 版本号。因为同样的模型，今天和三个月后的版本可能完全不同。如果没有这些快照，机器上只会留下“当时跑过一次，结果找不到了”的尴尬记录。我在模拟项目 X 里吃过这个亏，后来养成了把评测元信息写进结果的表头或文件名的习惯。

最后再分享一个小建议：不要一开始就追求完美的评测体系。第一次做评测，哪怕只拿 100 条数据、用简单的“JSON 可解析”作为成功标准，先跑通整个流程。跑通之后再逐步增加对抗样本、细化评分规则、加入人工复核成本。评测体系的完善是迭代出来的，不是一蹴而就的。只要 cost-per-success 这个核心指标能从数字上反映出模型之间的真实差距，这个体系就已经在为你创造价值了。