用决策模型做评测，先调分类阈值

决策模型最近迅速涌现，先是 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 表示失败），调整决策阈值，在精确率和召回率均至少达到 80% 的前提下，最大化 F1。使用分层五折交叉验证，在训练样本上选择阈值，并在剩余样本上衡量性能。如果要比较多个模型，请为它们使用相同的数据划分。只能选择在训练样本上同时满足这两项最低要求的阈值。如果没有符合条件的阈值，请如实报告，不要放宽任何一项要求。报告验证集上的精确率、召回率和 F1，并列出没有阈值符合条件，或验证性能低于最低要求的所有划分。与默认的 0.50 阈值进行比较。复用已保存的分数，不要发起新的模型调用。

下面展示了针对 F1 调优后，各模型的性能变化。我们将精确率与召回率图中的三个候选模型放在一起，并将其他模型显示为灰色，以说明调优能带来多大改善。

与未达到最低要求的 Liquid d1 和 Clef Flash 相比，候选模型从 F1 调优中获得的提升较小。不过，即使精确率和召回率只有小幅变化，也可能影响业务成本或用户体验，因此应当有意识地做出权衡。在实践中，精确率和召回率很少同等重要，而本文使用 F1 时做出了这一假设。例如，F-beta 分数允许你在 beta 小于 1 时赋予精确率更高的权重，在 beta 大于 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 条分数相近的轨迹。点落在对角线上，意味着预测概率与该组轨迹的实际故障率一致。点位于对角线上方，表示模型低估了故障风险；位于下方，则表示模型高估了风险。

如果预测概率与实际观察结果不符，我们可以使用另一个模型来调整它们。第二幅图展示了其中一种方法：Platt 缩放，它通过拟合一条简单的曲线来完成这种调整。11

校准后，Perplexity、Liquid d1 和 Clef Flash 的结果更接近对角线。例如，Clef Flash 的一组轨迹，平均预测故障概率约为 8%，但实际有 60% 包含故障。

Jev 和 Liquid d1-ultra 在这个数据集上的概率原本就校准得较好，几乎不需要调整。

Platt 缩放并非总是最合适的方法。例如，使用我们采用的这个版本的 Platt 缩放后，OpenAI 的概率预测反而略有变差。12 你可以使用下面的提示词，让编程智能体执行校准：

使用我保存的失败概率和二元标签（1 表示失败），检验 Platt 缩放是否能改善各模型的概率估计。采用分层五折交叉验证，所有模型使用相同的数据划分。在每个训练集上拟合校准映射，并将其应用于该折剩余的运行轨迹。先将概率裁剪到远离 0 和 1 的范围，再基于对数几率拟合。绘制校准前后预测概率与实际观测失败率的对比图。报告 Brier 分数（越低越好），并解释哪些模型有所改善、哪些变差了。复用已保存的分数，不要发起新的模型调用。

提示词调优与评估器的范围

为了让模型之间的差异更容易显现，本文采用了范围较宽的评估任务。在实际应用中，我们建议针对每种失败模式构建独立的评判器。随着任务范围缩小、指导更加具体，我们预计模型之间的性能差距也会缩小。

我喜欢先选用一个在任务上表现达标的大模型，然后尝试更小的模型，看看它们能否以更低的成本达到大模型的表现。如果你有高质量的标签，提示词调优也会有所帮助。13 我在另一篇文章中讨论了如何编写好的评判器提示词。

将这些思路付诸实践

在这个特定的数据集上，OpenAI 表现突出，但成本也更高。Perplexity 和 Liquid d1-ultra 提供了成本更低、性能也较低的选择。我们观察到，模型在不同任务和数据集上的表现差异很大，因此，亲自测量很重要。

当你对评判器的提示词感到满意后，就为你的使用场景设定最低精确率和召回率要求，排除无法满足这些要求的模型。

在比较性能之前，先调优每个模型的决策阈值。选择符合业务目标的精确率与召回率权衡。要有意识地做出选择，不要仅仅因为本文使用了 F1 分数就照搬！

如果你想把分数用作置信度估计，就要检查这些概率是否与实际观测结果相符。校准可能有所帮助，但你需要测量它是否确实改善了概率估计。

结合你的工作负载，权衡性能、成本和延迟。

这是一个迭代过程。你可能改进了提示词，随后又需要重新调优阈值，或重新检查校准效果。本文重点讨论阈值调优和校准，是因为我们看到许多人直接使用现成的决策模型，却没有考虑这些因素。

你可能还想知道，决策模型与 LLM 相比表现如何。OpenAI Decisions 使用 GPT-6 Luna，在我们的测试中取得了最高的 F1 分数，成本也最高。这表明，对于更难的评估任务，花更多钱使用 LLM 可能是值得的。在一项范围更广的比较中，Randy Olson 发现，决策模型能以更低的成本，在分类和路由任务上达到与 LLM 相当的表现；而在需要知识和推理的任务上，LLM 则更胜一筹。

本文讨论的思路都不是什么新东西。选择精确率与召回率之间的权衡、调优阈值，以及比较性能与成本，都是评估任何分类器时需要做的工作。如果想进一步了解这些基础知识，我推荐 Kyle Gallatin 和 Chris Albon 合著的《Machine Learning with Python Cookbook, 2nd Edition》。

最后，如果你是一名数据科学家或机器学习工程师，正在思考自己在 AI 时代的位置，那么这些技能你早就具备了。是时候扳回一局了 🙂。

附录：评估提示词

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."
      ]
    }
  }
}

测试版本：Jev 1.13（于 2026 年 9 月 15 日公布）、Perplexity Decider 1.1 27B、Liquid d1 和 d1-ultra、Cloudflare Clef Flash，以及 OpenAI Decisions。OpenAI Decisions 使用 GPT-6 Luna。该 API 返回带有明确类型的答案，其中包括针对真／假问题给出的 0 到 1 之间的概率。这是一个独立于 Structured Outputs 的 API，后者用于生成符合自定义 JSON schema 的响应。我们将其纳入比较，是因为它承担了相同的分类任务。↩︎

测试版本：Jev 1.13（于 2026 年 9 月 15 日发布）、Perplexity Decider 1.1 27B、Liquid d1 和 d1-ultra、Cloudflare Clef Flash，以及 OpenAI Decisions。OpenAI Decisions 使用 GPT-6 Luna。该 API 返回带有明确类型的答案，包括针对判断题返回一个介于 0 到 1 之间的概率。它与 Structured Outputs 是两个独立的 API，后者生成符合自定义 JSON schema 的响应。我们将其纳入测试，是因为它能完成相同的分类任务。↩︎

LLM 评判器通过提示词评估 AI 系统的输出或行为。我们建议让它针对某一种具体的失败模式，给出通过或不通过的二元判断。这有助于明确评判标准，也更容易将评判器的判断与人工标签进行比较。↩︎

LLM 评判器通过提示词评估 AI 系统的输出或行为。我们建议让它针对某一种具体的失败模式，给出通过或不通过的二元判断。这有助于明确评判标准，也更容易将评判器的判断与人工标签进行比较。↩︎

我们从包含 100 条轨迹的数据集中排除了两个内部 QA 示例，对剩余的 98 条生产环境轨迹进行了评分。固定的参考标注集包含 61 条已知失败轨迹和 37 条未标注失败的轨迹：其中，39 条失败来自最初的人工审核，另外 22 条由 Braintrust 和 Arize 发现，并经我们人工验证。模型收到的是经过脱敏、不含人工标签和审核备注的轨迹。Perplexity、Liquid、Clef Flash 和 OpenAI 收到了相同的指令和序列化输入；Jev 则通过其结构化 API 接收了等效的评判标准。原始对话不公开。↩︎

我们从包含 100 条轨迹的数据集中排除了两个内部 QA 示例，对剩余的 98 条生产环境轨迹进行了评分。固定的参考标注集包含 61 条已知失败轨迹和 37 条未标注失败的轨迹：其中，39 条失败来自最初的人工审核，另外 22 条由 Braintrust 和 Arize 发现，并经我们人工验证。模型收到的是经过脱敏、不含人工标签和审核备注的轨迹。Perplexity、Liquid、Clef Flash 和 OpenAI 收到了相同的指令和序列化输入；Jev 则通过其结构化 API 接收了等效的评判标准。原始对话不公开。↩︎

API 费用涵盖 100 次评估运行，每条轨迹运行一次。我们采用 Liquid 截至 2026 年 10 月 17 日的价格：d1 每百万输入 token 为 0.02 美元，d1-ultra 为 0.042 美元。实验中记录的 d1 单价为 0.04 美元；我们已根据保存的 token 用量重新计算费用。其他模型采用实验运行指标中记录的费率。性能指标排除了两条内部 QA 轨迹。阈值调优使用已保存的评分，无需额外调用模型。↩︎

API 费用涵盖 100 次评估运行，每条轨迹运行一次。我们采用 Liquid 截至 2026 年 10 月 17 日的价格：d1 每百万输入 token 为 0.02 美元，d1-ultra 为 0.042 美元。实验中记录的 d1 单价为 0.04 美元；我们已根据保存的 token 用量重新计算费用。其他模型采用实验运行指标中记录的费率。性能指标排除了两条内部 QA 轨迹。阈值调优使用已保存的评分，无需额外调用模型。↩︎

延迟取决于多种因素，包括你如何批处理或并行发送请求、你与供应商的服务约定，以及你与其基础设施之间的距离。批处理和并发也会影响费用与吞吐量。可参阅 TypeSafe 的多问题请求和客户端性能指南。其发布讨论中也说明了延迟测试地点相对于服务部署位置的情况。平均响应时间分别为：Jev 4.33 秒、Perplexity 7.85 秒、Liquid d1 7.38 秒、Liquid d1-ultra 1.56 秒、Clef Flash 2.09 秒，以及 OpenAI 2.77 秒。这些数据来自不同的运行，无法据此比较吞吐量或尾延迟。↩︎

延迟取决于多种因素，包括你如何批处理或并行发送请求、你与供应商的服务约定，以及你与其基础设施之间的距离。批处理和并发也会影响费用与吞吐量。可参阅 TypeSafe 的多问题请求和客户端性能指南。其发布讨论中也说明了延迟测试地点相对于服务部署位置的情况。平均响应时间分别为：Jev 4.33 秒、Perplexity 7.85 秒、Liquid d1 7.38 秒、Liquid d1-ultra 1.56 秒、Clef Flash 2.09 秒，以及 OpenAI 2.77 秒。这些数据来自不同的运行，无法据此比较吞吐量或尾延迟。↩︎

这些例子说明，错误造成的后果如何影响取舍。在美国刑事审判中，“排除合理怀疑”的证明标准为定罪设置了很高的门槛。在癌症筛查中，漏诊可能延误治疗，而误报可能引发焦虑，并导致不必要的医疗操作。筛查结果呈阳性通常需要进一步检查。美国国家癌症研究所（NCI）解释了这两类风险；如何取得适当平衡，取决于筛查方法和受检人群。↩︎

这些例子说明，错误造成的后果如何影响取舍。在美国刑事审判中，“排除合理怀疑”的证明标准为定罪设置了很高的门槛。在癌症筛查中，漏诊可能延误治疗，而误报可能引发焦虑，并导致不必要的医疗操作。筛查结果呈阳性通常需要进一步检查。美国国家癌症研究所（NCI）解释了这两类风险；如何取得适当平衡，取决于筛查方法和受检人群。↩︎

密度图展示的是引入最低精确率和召回率要求之前，不受约束的 F1 调优结果。后面的对比图则在可行的情况下，对候选模型应用这些要求。所有图表均使用相同的五折交叉验证划分。阈值在训练轨迹上选定，精确率、召回率和 F1 则在另一组独立轨迹上测量。我们对多次重复划分得到的测量结果取平均值。在优化后的密度图中，虚线表示所选阈值的平均值。图中展示的分数来自各次划分的结果，而不是将这个平均阈值应用于整个数据集得到的结果。密度曲线采用带宽为 0.07 的高斯平滑，并在 0 和 1 处进行反射边界处理。每个类别的曲线下面积均为 1。平滑处理仅影响显示效果。↩︎

密度图展示的是引入最低精确率和召回率要求之前，不受约束的 F1 调优结果。后面的对比图则在可行的情况下，对候选模型应用这些要求。所有图表均使用相同的五折交叉验证划分。阈值在训练轨迹上选定，精确率、召回率和 F1 则在另一组独立轨迹上测量。我们对多次重复划分得到的测量结果取平均值。在优化后的密度图中，虚线表示所选阈值的平均值。图中展示的分数来自各次划分的结果，而不是将这个平均阈值应用于整个数据集得到的结果。密度曲线采用带宽为 0.07 的高斯平滑和反射处理