Hugging Face 中的决策模型 – 用于结构化概率输出的新接口

TL;DR

Hugging Face 引入了一个 decision‑model API，它接受上下文（状态）和结构化问题，然后返回选择、分数或带有置信度的二元概率——当应用程序仅需要结构化决策时，无需进行文本生成。

什么是决策模型

决策模型消耗一个 state（任何输入数据）和一组由三个原语定义的 questions——choice、score 和 noul——并返回一个包含所选答案（或期望值）以及完整概率分布的 decision 对象。

State + Questions + Allowed Answers → Decisions + Probabilities

该模型不生成自由格式的文本；它直接评估每个可能答案的 logits 并应用 softmax，从而产生应用程序可以以编程方式使用的校准概率。

为什么要取代通用的 LLM 提示词？

使用标准 LLM 输出 JSON 存在三个缺点：

  1. 模式违规 – 模型可能会产生格式错误的 JSON 或意外的键。
  2. 解码开销 – 约束生成工具（例如 Outlines, XGrammar）强制执行模式，但增加了计算成本。
  3. 不必要的生成 – 自回归解码即使在只需要离散决策时也会计算完整的 token 序列。

决策模型通过完全绕过 token 级生成来避免这些问题。

与现有分类方法的比较

属性 传统分类器 Zero‑shot 分类器 决策模型
选择的概率分布 ✅ ✅ ✅
在推理时定义标签 ❌ ✅ ✅
每个请求支持多个类型化问题 ❌ ❌ ✅
原生支持有序分数和二元 Bernoulli 决策 ❌ (特定任务) ❌ (需要适配) ✅

传统分类器具有固定的头部；添加新标签需要架构更改和重新训练。Zero‑shot 分类器允许运行时标签，但每个请求仅限于单个分类任务。决策模型将此范式扩展到单次调用中的 多个类型化问题。

三个原语详解

Choice – 离散选项上的概率分布

模型为每个选项返回一个 logit，并进行 softmax 处理得到概率。概率最高的选项被报告为 choice，而 confidence 指标量化了分布的峰值程度。

{
  "department": {
    "type": "choice",
    "choice": "billing",
    "confidence": 0.9974,
    "probabilities": {
      "billing": 0.9983,
      "technical": 0.0010,
      "sales": 0.0007
    }
  }
}

Score – 有序量表的期望值

对于序数问题（例如紧急程度），模型返回每个级别的概率，并将 期望索引 计算为分数。

{
  "urgency": {
    "type": "score",
    "score": 1.70,
    "legend": {"0":"low","1":"medium","2":"high"},
    "confidence": 0.558,
    "probabilities": {"0":0.015,"1":0.265,"2":0.720}
  }
}

Noul – Bernoulli (是/否) 概率

二元决策返回一个代表 P(yes) 的单一概率 noul。

{
  "refund": {"type": "noul", "noul": 0.995}
}

置信度指标

对于 choice 和 score 问题，confidence 衡量最高概率超过均匀基线的程度：

$$C = \frac{p_{\text{max}} - \frac{1}{K}}{1 - \frac{1}{K}}$$

其中 K 是选项的数量。均匀分布产生 C = 0；确定性分布产生 C = 1。

生态系统集成

1. 使用 🤗 Transformers 进行服务

  • 新类：DecisionPipeline, AutoModelForDecision, DecisionConfig。
  • 与其他 pipeline 相同的 API；支持 /v1/systemone HTTP 端点。
  • 示例 curl 请求返回一个包含三个类型化答案和 token 使用统计信息的 JSON 对象。

2. 使用 llama.cpp 进行服务

  • llama.cpp 实现了相同的 /v1/systemone API，允许在不更改代码的情况下服务 GGUF 决策模型（例如 ggml-org/Kev-4B-GGUF）。
  • 展示了跨后端的真正 接口兼容性。

3. 在 Hub 上发现模型

  • 一个专门的 decision-model 标签聚合了所有架构的模型（仅编码器、生成式 LLM、多模态变体）。
  • 用户可以通过 Hub UI 浏览热门决策模型。

4. 训练决策模型

  • 决策模型是 Transformers 库中的一等公民；可以使用标准的 Trainer API 进行微调。
  • 一个玩具示例在小型路由数据集上微调了 JEV-9B，展示了如何使用 model.decision_config.prepare_inputs 准备输入并计算选择 logits 上的交叉熵损失。
  • 即将推出的 TRL 支持 (huggingface/trl#8040) 将简化训练流水线。
  • Unsloth 提供了一个基于 LoRA 的配方，将生成式 LLM（例如 Qwen）转换为决策模型。

对开发者的影响

  • 降低延迟 – 无需逐个 token 生成；单次前向传递即可得出所有答案。
  • 更高的可靠性 – 结构化输出保证了模式合规性，消除了后处理验证。
  • 灵活性 – 运行时定义的答案集和多种问题类型使得在单个请求中实现复杂的决策工作流（路由、评分、二元验证）成为可能。
  • 生态系统凝聚力 – 共享接口使推理服务器、模型中心和训练工具能够在没有特定模型适配器的情况下互操作。

结语

决策模型不是对分类的重塑；它们是一种 标准化的、非生成式的契约，使概率决策成为软件的一等输出。通过在通用 API 下统一选择、分数和二元原语，Hugging Face 实现了跨不同模型后端和下游应用程序的可靠、校准的决策制定。

Sources