11月10日、Hugging Faceが「Decision Models in Hugging Face」と題した記事を公開した。LLMにJSON形式のテキストを生成させることなく、分類・スコアリング・二値判定を1回の推論でまとめて取得できる「Decision Models」の概念と、transformersへの統合について紹介している。
LLMに「テキスト生成」をさせる必要はあるか？
LLMを使った構造化データの抽出はここ数年で広く普及したが、コスト・信頼性の両面で課題が残っている。選択肢が事前に決まっているルーティングや分類タスクにも、自己回帰的なトークン生成を走らせなければならないからだ。OutlinesやXGrammarのような制約付きデコードライブラリを導入してスキーマ強制を行っても、追加の処理オーバーヘッドが発生し、それでも無効なJSONや仕様外のキーが返ることがある。LLM APIコストが意思決定ループのボトルネックになっているケースで、この問題は特に顕在化する。
Decision Modelsはこの問題に対する別のアプローチだ。モデルが選択肢ごとのロジットを直接評価し、テキストを一切生成せずに確率分布を返す。カスタマーサポートで「サブスクリプションで二重請求された。今日中に返金してほしい」というメッセージを受け取ったとき、判断すべきことは「どの部門が対応するか」「緊急度はどの程度か」「返金を求めているか」の3つだ。これらをまとめて1回の推論で取得できる。
from transformers import pipeline
decide = pipeline("decision", model="autotrust/GEV-26B-Decide")
decision = decide(
{
"state": "I was charged twice for my order and want a refund.",
"questions": {
"department": {
"type": "choice",
"instructions": "Which team should handle this?",
"criteria": {
"billing": "Payments and refunds",
"technical": "Bugs and technical issues",
"sales": "Pricing and subscriptions"
}
},
}
}
)
# {
# 'department': {
# 'type': 'choice',
# 'choice': 'billing',
# 'confidence': 0.9974000453948975,
# 'probabilities': {
# 'billing': 0.9982666969299316,
# 'technical': 0.0010246571619063616,
# 'sales': 0.0007087149424478412
# }
# }
# }
Decision Modelsの3つのプリミティブ
Decision Modelsの入出力は以下のように整理できる。
State + Questions + Allowed Answers → Decisions + Probabilities
State（状態）は文字列でもJSON構造体でもよく、マルチモーダル対応モデルであれば画像等の他のモダリティも扱える。Questions（質問）には3種類のプリミティブがある。
1. Choice：選択肢上の確率分布
複数の選択肢に対してソフトマックスで確率分布を返す。上の例では「billing: 0.998」と高い確信度で分類している。ラベルは推論時に自由に定義できるため、モデルを再学習することなく用途に合わせた分類器として機能する。
2. Score：順序スケールの期待値
「緊急度は低・中・高のどれか」のような順序付きスケールに対応する。モデルは各レベル（0=低、1=中、2=高）への確率分布を返し、その期待値をスコアとして報告する。
# urgency の出力例
# {
# 'urgency': {
# 'type': 'score',
# 'score': 1.7053890228271484, # 期待値
# 'probabilities': {
# '0': 0.015, # low
# '1': 0.265, # medium
# '2': 0.720 # high
# }
# }
# }
score: 1.7は「中と高の間に存在する架空のレベル」ではなく、確率分布の期待値だ。0×0.015 + 1×0.265 + 2×0.720 ≒ 1.705 という計算になる。段階数を増やしても同じロジックで動作するため、5段階評価や10段階評価にも対応できる。
3. Noul：二値のベルヌーイ確率
「返金を求めているか？」のようなyes/no質問に対して、trueである確率を単一の値で返す。「noul」という名称はTypeSafe AIによる造語で、no/nullの意味合いを含む独自の命名だ（詳細は後述する）。
# refund の出力例
# {
# 'refund': {
# 'type': 'noul',
# 'noul': 0.9947046637535095
# }
# }
従来手法との比較
Decision Modelsは、Zero-shot Classificationと似た面を持つが、明確な違いがある。ゼロショット分類は推論時にラベルを指定できる点で従来の固定ラベル分類器より優れているものの、1つの質問に対して1つのカテゴリを返すことを前提としている。Decision Modelsはこれを拡張し、同一のStateに対して異なる型（Choice・Score・Noul）の質問を一度に投げられる点が本質的な差別化ポイントだ。ルーティング・緊急度判定・二値フラグの取得を1回のAPIコールで完結できる。
| 特性 | 分類器 | ゼロショット分類 | Decision Model |
|---|---|---|---|
| 推論時にラベル定義 | No | Yes | Yes |
| 複数の型の質問を同時処理 | No | No | Yes |
| 順序スケール・二値のネイティブ対応 | タスク依存 | 要アダプテーション | ネイティブ |
「Decision Model」という名称の経緯
この概念はもともとTypeSafe AIが「Jev」として発表し、「System One Model」と呼んでいた。カーネマン（Kahneman）の著書「Thinking, Fast and Slow」における「System 1（直感的・高速）」と「System 2（論理的・低速）」の区分けに着想を得た命名だ。「Noul」という造語もこの文脈で生まれたものである。
しかしコミュニティでの議論を経て、特定の認知科学理論を持ち込まず、モデルの計算的な役割を素直に表す「decision model」という用語に統一された。
transformersへの統合と利用方法
pipeline("decision", model="autotrust/GEV-26B-Decide") として利用できる。現時点で動作が確認されているモデルは autotrust/GEV-26B-Decide だ。複数の質問（Choice・Score・Noul）を同時に投げることも可能で、ルーティング・緊急度判定・二値判定を1回の推論でまとめて取得できる。
対応するtransformersのバージョンや詳細な使い方は公式ドキュメントを参照されたい。
詳細はDecision Models in Hugging Faceを参照していただきたい。
