如何用决策模型做评估

决策模型近来迅速兴起，最早是 TypeSafe 的 Jev，随后是 Perplexity 的 Decider、Liquid 的 d1、Cloudflare 的 Clef，以及 OpenAI 的 Decisions API1。

这些模型承诺提供快速且经济的分类能力。

对于自动化评估而言，决策模型是一种颇具吸引力的低成本替代方案，可作为 LLM 判官2的补充。但它们是否适合您的场景，取决于具体用例对成本、性能和延迟的要求。

我们也注意到，许多人直接使用默认的决策阈值 0.50，而未检验其是否适用于自己的任务。这可能导致大量性能潜力未能被充分挖掘。

在本文中，我们首先介绍如何调整阈值，以从决策模型中获得最佳效果。在完成阈值调优后，我们将比较各模型的成本与性能，帮助您判断哪种模型更适合您的应用场景。

最后，我们还将探讨在决定是否采取行动时如何解读模型得分，以及校准如何使其作为置信度估计更具参考价值。

测试内容

我们采用了一组来自公寓租赁代理的 100 条轨迹数据，即对话与操作的日志记录。任务是识别包含错误的轨迹，例如预订失败或未能及时转交至人工处理的情况3。

我们在之前的 自动化评估文章中也使用了同一数据集和类似的故障发现任务。在此，每种决策模型都会为每条轨迹输出一个故障概率。

我们测试了 Jev 1.13、Perplexity Decider 1.1 27B、Liquid d1 和 d1-ultra、Cloudflare Clef Flash，以及 OpenAI Decisions（GPT-6 Luna）1。

所有模型均采用相同的评估标准。附录中列出了用于 Jev 的提示模板及其结构化版本。

我们从两个维度比较各模型：

• 性能：我们将各模型的预测结果与经人工审核并标注为“通过”或“失败”的轨迹进行对比，以此衡量模型在准确识别故障的同时避免误报的能力。
• 成本：我们根据各提供商的定价及 token 使用量计算 API 费用4。

为简洁起见，我们暂不考虑延迟因素，因为它受实验之外的多种变量影响5。

理解决策阈值

我们为每条轨迹分配“通过”或“失败”两种标签。这是一种二元通过/失败评估,我们推荐这种方式，因为它有助于明确评判标准，并且更易于与人工偏好保持一致。

每种决策模型都会返回一个介于 0 到 1 之间的分数，用于估算某条轨迹包含故障的可能性。各 API 会基于这个分数，按照默认的决策阈值 0.50作出最终判定：凡分数达到或超过该阈值的轨迹均会被标记为故障。

若不经验证便直接采用此默认阈值，可能会导致效果不尽如人意。

举例来说，某个模型可能将所有故障轨迹的分数都设为 0.40，而将所有通过轨迹的分数设为 0.10。尽管该模型在阈值为 0.30 时能完美区分两类轨迹，但使用默认阈值 0.50 却完全无法检出任何故障。

在实际应用中，故障与通过轨迹的得分往往存在重叠。降低阈值可以检出更多故障，但也可能带来更多误报。选择阈值意味着要在以下两者之间权衡：

• 精确率：被标记为故障的轨迹中，实际包含已知故障的比例。
• 召回率：模型所检出的已知故障占全部已知故障的比例。

恰当的权衡取舍取决于您的业务目标。例如，刑事审判为了防止误判无辜者，会设定较高的定罪门槛，侧重于精确率；而癌症筛查则可能更注重召回率，宁可接受更多误报，也要尽量减少漏诊6。

在本次比较中，我们将采用两者的调和平均值——F1 分数——赋予精确率与召回率同等权重。F1 分数范围为 0 至 1，数值越高越好。

下方的曲线展示了各模型对故障轨迹（橙色）与通过轨迹（蓝色）的得分分布情况。曲线上方越高的部分，表示该区间内对应类别的得分数量越多。

位于虚线阈值之上或之上的得分将被标记为故障。您可以使用切换按钮比较默认阈值 0.50与针对每模型分别选取的最优 F1 阈值7。

就本任务而言，OpenAI 对两类轨迹的区分最为清晰，这也反映在其更高的 F1 分数上。

此外，切忌盲目追求 F1 最大化，而忽视分类器实用性的最低要求。例如，若该分类器用于自动化告警系统，我希望其精确率与召回率均不低于 80%，以便在尽可能减少误报的同时，确保足够多的故障能够被检出。

下图展示了不同阈值下精确率与召回率的变化情况8。阴影区域标示了二者同时达到至少 80% 的区间。

Perplexity、Liquid d1-ultra 和 OpenAI Decisions 均满足我们的要求，但我们仍需为每种模型在该阴影区域内选定合适的决策阈值。

下一节我们将讨论如何调整这些阈值。

调整决策阈值

在本例中，我们将以 F1 最大化为目标进行优化。对于候选模型，我们尽可能将阈值调整范围限定在训练数据上同时满足 80% 最低要求的区间内。

其余模型则不做限制，以展示阈值调整的效果9。

有了已标注的轨迹数据和保存的模型得分，您可以委托编程助手来调整阈值。以下是可根据您的具体场景修改的示例提示：

利用我保存的模型分数和二元标签（1表示失败），调整决策阈值以最大化F1，同时要求至少80%的精度和80%的回忆率。采用分层五重交叉验证，选择训练样本的阈值，测量其余样本的性能。比较模型时，使用相同的分数。只选择满足训练样本两个最低标准的阈值。如果没有符合条件，报告该阈值，而非放宽任一要求。报告验证精度、回忆和F1，以及任何未被阈值限定或验证性能低于最低要求的分割。与默认阈值0.50进行比较。重复使用保存的分数，无需重新调用模型。

以下是调校F1如何改变每款车型性能的过程。我们将精确回忆表中的三个候选模型归为一组，其他型号则用灰色表示，以说明调校的效果。

我们的候选模型从F1调优中获得的收益低于Liquid d1和Clef Flash，后者低于我们的最低要求。然而，即使是精度和召回率的微小变化也可能影响业务成本或用户体验，因此请有意识地选择权衡。

实际上，精度和召回性不太可能同等重要（正如我们在这篇文章中假设的F1）。例如，F-beta 评分当β值低于1时，你可以赋予更高的精度权重，或者当β值大于1时回忆更多权重。

优化不同的指标可能导致不同的阈值和结果。

性能与成本的比较

下图比较了各车型调校后的F1性能与成本，重点关注剩余候选车型：

虚线表示帕累托边界在我们剩余的候选人中。对于任何给定的F1分数，它会识别出达到或超过该分数的最便宜候选人。这张图表有点傻，因为只有三个选项，但它为如何考虑成本与性能提供了有用的示例。

Perplexity是这些候选中最便宜的，每100次评估运行成本为0.82美分，F1为0.79。OpenAI Decisions的F1评分为0.87，每100次评估运行为3.72美分，成本约为其4.5倍。

我们能相信概率吗？

除了通过/不通过评估，你可能还想用决策模型的分数作为置信度估计。但你能字面理解这个数字吗？如果0.80分表示80%的失败概率，大约80%的相似分数痕迹应该包含失败。

下图显示了每个型号的概率校准：预测概率与观察结果的接近程度。10 每个点代表约20条分数相似的痕迹。对角线上的一点表示预测概率与该组的失败率匹配。

线上方，模型低估失败风险。线以下，模型高估该风险。

如果预测概率与观察结果不符，我们可以用另一个模型进行调整。第二块面板展示了一种方法，普拉特标度法，该曲线拟合一个简单的曲线以进行该调整。

11

校准后，Perplexity、Liquid d1和Clef Flash更接近对角线。例如，一组Clef Flash走线的平均预测失效概率约为8%，但60%包含失效。

Jev和Liquid d1-ultra在该数据集上已经校准良好，几乎不需要调整。

Platt 缩放并不总是最合适的。例如，OpenAI 在我们使用的 Platt 缩放版本中，概率略有下降。12 你可以用以下提示指示你的编码代理进行校准：

利用我保存的失败概率和二进制标签（1表示失败），测试Platt尺度是否提升了每个模型的概率。使用分层五重交叉验证，每个模型的分割相同。拟合每个训练分割的校准映射，并应用于剩余的痕迹。拟合对数赔率，先将概率从0和1剪裁。在校准前后绘制预测概率与观察到的失败率。报告Brier分数（较低为优），并说明哪些模型有所改善或更差。重复使用保存的分数，无需重新调用模型。

提示调优与评估器范围

我们保持了这篇文章中的评估任务范围较宽，以便更容易区分模型之间的差异。实际上，我们建议构建每个失败模式都有独立裁判.随着任务更精细和更具体的指导，我们预计模型间的性能差距将会缩小。

我喜欢先从一个在任务上表现可接受的较大模型开始，然后尝试较小的模型，看看它们是否能以更低的成本与大模型匹敌。如果你有高质量的标签，提示调整也很有帮助。

13 我会讨论如何打造一个好的评审提示词在本帖中.

将这些理念付诸实践

对于该数据集，OpenAI的突破性表现以更高的成本实现。Perplexity和Liquid d1-ultra则提供了成本较低但性能更低的选项。我们观察到模型性能在不同任务和数据集间差异显著，这意味着自己测量非常重要。

总结一下：

• 一旦你对你的情况感到满意评委提示为你的使用场景设定最低精度和召回要求。排除无法满足这些要求的型号。
• 在比较性能前，先调整每个模型的决策阈值。选择符合你业务目标的精度与召回权衡。要有意识地使用，不要像这篇帖子那样只用F1分数！
• 如果你想用分数作为置信度估计，检查概率是否与观察到的结果相符。校准可以帮忙，但你需要衡量它是否改善了概率。
• 权衡性能与成本和延迟，满足你的工作负载需求。

这个过程是迭代的。你可能会改进提示词，然后需要再次调整阈值或重新校准。在这篇文章中，我们重点讨论了阈值调优和校准，因为我们看到很多人使用现成的决策模型时没有考虑这些因素。

你可能还会好奇决策模型与大型语言模型相比如何。OpenAI Decisions 使用 GPT-6 Luna，它以最高成本交付了我们最高的 F1 分数，这表明更难的评估任务可能值得为 LLM 支付更高费用。

在更广泛的比较Randy Olson发现，决策模型能够以更低成本与LLM匹配分类和路由，而LLM在需要知识和推理的任务上则能领先。

本文讨论的这些想法都不是新内容。选择精度与召回权衡、调节阈值以及比较性能与成本，都是评估任何分类器时的一部分。想了解更多这些基础知识，我建议《带Python机器学习手册》第二版作者：凯尔·加拉廷和克里斯·阿尔本。

最后，如果你是数据科学家或机器学习工程师，正在思考自己在人工智能时代的定位，这些技能你已经具备。是时候开始了复仇🙂.

附录：评估提示

Perplexity、Liquid d1 和 d1-ultra、Clef Flash 以及 OpenAI Decisions 收到了以下提示。Jev 在结构化提示中获得了等效的标准，如下例所示。

该乐谱与标签图表中使用的代码以 JSON 形式提供。

Decide whether `messages` contains at least one substantive failure, risk, or quality problem in the AI assistant's behavior or tool use. This is one complete production trace from an AI that handles apartment-leasing customer support over phone or messaging. The trace includes the conversation plus any tool calls and tool outputs.

Evaluate the AI assistant and its tool use, not the customer. Treat system messages inside `messages` as the instructions governing the assistant's behavior and allowed capabilities. Inspect the full trace, including final turns and all tool calls and outputs. Base the judgment only on evidence visible in this trace. Do not assume external policies, channel behavior, or business requirements that are not present. Do not assume every trace failed. A short, ambiguous, or inconclusive trace is not an issue unless visible evidence establishes a substantive failure.

Return the probability that at least one substantive issue is present; the issue does not need to be named or clustered.

Count as an issue when supported by the trace: the assistant contradicts an applicable system instruction or tool result; makes an unsupported factual or operational claim; misses, misuses, repeats, or falsely claims completion of a required tool action, transfer, booking, cancellation, follow-up, or confirmation; materially misunderstands or leaves an explicit user request unresolved; or exposes internal actions, placeholders, or broken content to the customer in a way that materially harms the interaction.

Do not count as an issue: a minor stylistic preference with no meaningful effect; a failure caused only by the customer's behavior; internal tool metadata that was not exposed to the customer and did not cause an incorrect response; a hypothetical concern requiring information outside the trace; or insufficient evidence and inconclusive conversations.

注释示例：一个结构化的提示

这是我们为 Jev 的请求所设计的提示结构，其中包含用于说明和评估标准的独立字段。

{
  "version": "nurtureboss-any-issue-v1",
  "question_id": "has_substantive_issue",
  "type": "noul",
  "instructions": {
    "task": "Does `messages` contain at least one substantive failure, risk, or quality problem in the AI assistant's behavior or tool use?",
    "context": "This is one production trace from an AI that handles apartment-leasing customer support over phone or messaging. The trace contains the complete conversation plus any tool calls and tool outputs.",
    "evaluation_rules": [
      "Evaluate the AI assistant and its tool use, not the customer.",
      "Treat system messages inside `messages` as the instructions governing the assistant's behavior and allowed capabilities.",
      "Inspect the full trace, including the final turns and all tool calls and outputs.",
      "Base the judgment only on evidence visible in this trace. Do not assume external policies, channel behavior, or business requirements that are not present.",
      "Do not assume every trace failed. A short, ambiguous, or inconclusive trace is not an issue unless the visible evidence establishes a substantive failure.",
      "Return the probability that at least one substantive issue is present. The issue does not need to be named or clustered."
    ]
  },
  "criteria": {
    "true": {
      "definition": "At least one substantive problem is supported by evidence in the trace.",
      "examples_of_qualifying_evidence": [
        "The assistant contradicts an applicable system instruction or a tool result.",
        "The assistant makes an unsupported factual or operational claim.",
        "A required tool action, transfer, booking, cancellation, follow-up, or confirmation is missing, incorrect, repeated, or falsely claimed as complete.",
        "The assistant materially misunderstands or leaves an explicit user request unresolved.",
        "Customer-facing text exposes internal actions, placeholders, or broken content that materially harms the interaction."
      ]
    },
    "false": {
      "definition": "No substantive assistant problem can be established from the visible trace.",
      "do_not_count_as_an_issue": [
        "A minor stylistic preference with no meaningful effect.",
        "A failure caused only by the customer's behavior.",
        "Internal tool metadata that was not exposed to the customer and did not cause an incorrect response.",
        "A hypothetical concern that requires information outside the trace.",
        "Insufficient evidence or an inconclusive conversation."
      ]
    }
  }
}

脚注

1. 测试版本：耶利米书 1.13(2026年9月15日宣布),困惑判定器 1.1 27B,液体d1和d1-ultra,云焰 谱号闪光， 和OpenAI决策.OpenAI Decisions 使用 GPT-6 Luna。该 API 返回已输入的答案，包括对真/假问题的概率 0 到 1。这是与结构化输出不同的 API，后者生成匹配自定义 JSON 模式的回答。我们包含它，因为它执行相同的分类任务。︎ ↩
2. 一个LLM 评审使用提示词来评估AI系统的输出或行为。我们建议它请求二元通过/失败决策关于特定的失败模式。这鼓励明确的标准，并使得与人为标签更容易比较评委的判决。︎ ↩
3. 在排除两个内部质量保证示例后，我们从100条跟踪数据集中剔除了98条生产痕迹。冻结的参考包含61个已知失败和37条无标记失败的痕迹：39个来自原始人类审查的失败，加上22个我们手动验证的Braintrust和Arize发现。模型收到了无人工标签或审稿人注释的掩蔽痕迹。Perplexity、Liquid、Clef Flash和OpenAI获得了相同的指令和序列化输入;Jev通过其结构化API获得了等效的标准。原始对话为私密。︎ ↩
4. API成本涵盖100次评估运行，每个痕迹一次。我们使用Liquid截至2026年10月17日的价格d1 每百万输入代币为 0.02 美元，d1-ultra 为 0.042 美元。实验记录 d1 为 0.04 美元;我们已重新定价其保存的代币使用量。其他模型在实验的操作指标中使用速率。性能排除了两个内部质量保证跟踪。阈值调优使用保存的分数，无需额外的模型调用。︎ ↩
5. 延迟取决于你如何批处理或并行处理请求、与供应商的合作情况以及你与其基础设施的距离等因素。批处理和并发还可能改变成本和吞吐量。参见TypeSafe指南多问请求以及客户绩效指导.它的启动讨论还注明了其延迟测试相对于其服务的位置。平均响应时间为：Jev 4.33 秒，Perplexity 7.85 秒，Liquid d1 7.38 秒，Liquid d1-ultra 1.56 秒，Clef Flash 2.09 秒，OpenAI 2.77 秒。这些数据来自独立运行，无法建立吞吐量或尾部延迟的比较。 ↩
6. 这些例子说明了错误的后果如何影响权衡。在美国刑事审判中，超越合理怀疑的证据定罪门槛很高。在癌症筛查中，漏诊病例可能导致治疗延迟，虚惊则可能导致焦虑和不必要的检查。阳性筛查结果通常需要进一步检测。该NCI解释了这两种风险;适当的平衡取决于筛查测试和人群。︎ ↩
7. 密度图显示了不受约束的F1调优，随后引入最低精度和回忆要求。后续比较图在可行的情况下将这些要求应用于候选模型。所有图均使用相同的五重交叉验证分割。阈值在训练痕迹上选择，精度、回忆和F1分别测量在不同痕迹上。我们对这些测量值在重复拆分间取平均值。在优化后的密度图中，虚线显示了所选的平均阈值。显示的分数来自单个分割，而非将该平均阈值应用于整个数据集。密度曲线采用带宽为0.07的高斯平滑，反射为0和1。每个类别的面积为1。平滑仅影响显示部分。︎ ↩
8. 随着决策阈值的变化，精确度-回忆曲线绘制了精确度与回忆的关系。它展示了模型在不同阈值间可采取的权衡。Scikit-learn 的精确回忆指南解释如何读取和绘制这些曲线。︎ ↩
9. 我们从全样本的精度-回忆曲线中识别候选者。在每个训练分段中，我们从达到至少80%精度和80%回忆率的样本中选择最高的F1阈值。当无阈值符合条件时，使用无约束的F1最优值，并将分段记录为不可行。在Perplexity的100个训练分段中，有36个发生了这种情况，Liquid d1-ultra有29个，OpenAI则从未发生过。非候选者始终使用无约束的F1调优。我们保留所有验证预测，包括备份拆分的预测，都保留在报告的平均值中。最低要求适用于选择阶段，不保证新样本的同样性能。该阈值选择审计每个记录在没有痕迹ID的情况下分割。︎ ↩
10. 校准后的故障概率为0.80，意味着在众多得分接近0.80的样本中，约有80%包含故障。Platt缩放和等距回归利用标注样本，从模型得分学习到概率的调整。Platt缩放拟合一条S形曲线；等距回归则拟合一种更为灵活的映射，能够保持得分的顺序，但在数据集较小时更容易过拟合。两者均不能保证在新样本上取得改进。scikit-learn的概率校准指南详细介绍了这两种方法及其评估方式。↩︎
11. 可靠性图将每个模型的得分分为五组，每组包含19或20条轨迹，并按概率排序。调整后的得分是每条轨迹在保存的交叉验证结果中得到的平均留出概率。我们对原始概率的对数几率进行Platt缩放拟合，且每次拟合时均不使用该模型所预测的轨迹。该图表仅对这一小样本进行了汇总，并不能确定未来某条轨迹的确切故障率。绘制的校准结果以JSON格式提供。↩︎
12. 在保存的留出概率汇总上，Jev的Brier分数在调整前为0.187，调整后为0.188；Liquid d1-ultra分别为0.173和0.172；OpenAI分别为0.159和0.164。Brier分数衡量的是平均平方概率误差，数值越低越好，它同时反映了模型的区分能力和校准程度。这些结果对应于图表中所示的对数几率Platt拟合。我们在相同的折叠上直接对概率进行了一次探索性重新拟合，得到OpenAI的Brier分数为0.154，这说明其对拟合方法较为敏感，但并不能确定哪种方法在新数据上表现最佳。↩︎
13. GEPA利用模型运行的反馈来提出提示修订方案，并在标注样本上对其进行测试。它会保留具有不同优势的候选方案，因此即便某个提示仅对某一困难样本有效，仍可能被纳入考虑。错误的标签可能会使这一搜索过程偏离正确的方向。请在提示开发之外保留一个单独的测试集，用于最终验证。在我们规模较小的手动Jev实验中，默认阈值下的F1分数由简单提示的0.78提升至包含故障类型清单后的0.80。该实验未使用GEPA，也未能确定系统性优化能带来多大帮助。我们的关于选择评估模型的FAQ讨论了提示优化与模型比较的问题。↩︎