Hugging Faceの決定モデル – 構造化された確率的出力のための新しいインターフェース

TL;DR

Hugging Faceは、コンテキスト（状態）と構造化された質問を受け取り、選択肢、スコア、または信頼度付きの二値確率を返す決定モデル（decision-model） APIを導入しました。これにより、アプリケーションが構造化された決定のみを必要とする場合に、テキスト生成を行う必要がなくなります。

決定モデルとは

決定モデルは、状態（任意の入力データ）と、choice（選択）、score（スコア）、noul（二値）という3つのプリミティブで定義された一連の質問を消費し、選択された回答（または期待値）と完全な確率分布を含む決定オブジェクトを返します。

State + Questions + Allowed Answers → Decisions + Probabilities

このモデルは自由形式のテキストを生成しません。各回答候補のロジットを直接評価し、ソフトマックス関数を適用することで、アプリケーションがプログラム的に利用可能な、調整済みの確率を出力します。

なぜ汎用的なLLMプロンプトを置き換えるのか？

標準的なLLMを使用してJSONを出力させることには、3つの欠点があります。

  1. スキーマ違反 – モデルが不正なJSONや予期しないキーを生成する可能性があります。
  2. デコードのオーバーヘッド – 制約付き生成ツール（例: Outlines, XGrammar）はスキーマを強制しますが、計算コストが増加します。
  3. 不要な生成 – 自己回帰デコードは、離散的な決定のみが必要な場合でも、完全なトークンシーケンスを計算します。

決定モデルは、トークンレベルの生成を完全にバイパスすることで、これらの問題を回避します。

既存の分類アプローチとの比較

プロパティ 従来の分類器 ゼロショット分類器 決定モデル
選択肢に対する確率 ✅ ✅ ✅
推論時に定義されるラベル ❌ ✅ ✅
リクエストごとに複数の型付き質問 ❌ ❌ ✅
順序付きスコアと二値ベルヌーイ決定のネイティブサポート ❌ (タスク固有) ❌ (適応が必要) ✅

従来の分類器は固定されたヘッドを持っており、新しいラベルを追加するにはアーキテクチャの変更と再学習が必要です。ゼロショット分類器は実行時のラベル付けを可能にしますが、リクエストごとに単一の分類タスクに限定されます。決定モデルは、このパラダイムを単一の呼び出しにおける複数の型付き質問へと拡張します。

3つのプリミティブの詳細

Choice – 離散的な選択肢に対する確率分布

モデルは選択肢ごとにロジットを返し、ソフトマックスによって確率に変換されます。最も確率の高い選択肢が 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 – ベルヌーイ（はい/いいえ）確率

二値決定は、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。
  • 他のパイプラインと同じAPI。/v1/systemone HTTPエンドポイントをサポート。
  • curlリクエストの例では、3つの型付き回答とトークン使用統計を含む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 を使用した入力準備と、選択ロジットに対するクロスエントロピー損失の計算方法を示しています。
  • 今後のTRLサポート（huggingface/trl#8040）により、トレーニングパイプラインが簡素化されます。
  • Unslothは、生成LLM（例: Qwen）を決定モデルに変換するためのLoRAベースのレシピを提供しています。

開発者への影響

  • レイテンシの低減 – トークンごとの生成は不要。単一のフォワードパスですべての回答が得られます。
  • 信頼性の向上 – 構造化された出力によりスキーマ準拠が保証され、後処理の検証が不要になります。
  • 柔軟性 – 実行時に定義される回答セットと複数の質問タイプにより、複雑な意思決定ワークフロー（ルーティング、スコアリング、二値検証）を単一のリクエストで実現できます。
  • エコシステムの結束 – 共有インターフェースにより、推論サーバー、モデルハブ、トレーニングツールがモデル固有のアダプターなしで相互運用可能になります。

最終的な考察

決定モデルは分類の再発明ではなく、確率的な決定をソフトウェアのファーストクラスの出力にするための標準化された非生成的な契約です。Hugging Faceは、choice、score、および二値プリミティブを共通のAPIの下で統合することで、多様なモデルバックエンドとダウンストリームアプリケーション全体で、信頼性が高く調整された意思決定を可能にします。

Sources