Hugging Faceがデシジョンモデルの共通インターフェースを提案：TransformersにDecisionPipelineと/v1/systemoneエンドポイント、llama.cppも同じAPIで提供し、choice・score・noulの3つのプリミティブが確率を返す。精度・キャリブレーション・遅延のベンチマークはなく、計算例の数字も完全には一貫しない

2026年11月10日、Hugging Faceは長文の記事「Decision Models in Hugging Face」を公開しました。著者はAritra Roy Gosthipaty、Lysandre、Pedro Cuenca、Tom Aarsenの4名です。記事は、文章を生成しない種類のモデルのための共通インターフェースを説明しています。デシジョンモデル（decision model）は、顧客のメッセージのような状態と、型付きで許可された回答を持つ質問の集合を読み取り、確率つきの構造化された判断を返します。記事によると、モデルはトークンを1つずつ生成するのではなく、アプリケーションがすでに理解している回答に確率を割り当てます。インターフェースは「State + Questions + Allowed Answers → Decisions + Probabilities」と書かれています。記事は、この考え方をTypeSafe AIがJevという名で導入し「System Oneモデル」と呼んだこと、その後コミュニティが、思考理論ではなくモデルの役割を表す「decision model」という呼称に落ち着いたことを述べています。

動機となる例はサポートへのメッセージです。「サブスクリプションで二重に請求された。今日中に返金してほしい」。アプリケーションはここから3つのことを知りたいと考えます。どのチームが対応するか、緊急度、顧客が返金を求めているかです。記事はまず、言語モデルにその回答を含むJSONを書かせる方法を示し、次に別の方法を主張します。言語モデルに構造化出力を頼む場合の問題として、3つを挙げています。モデルは要求されたスキーマに従う保証がなく、不正なJSON、想定外のキー、許可された選択肢の外の回答を返す可能性があります。OutlinesやXGrammarのような制約付きデコードのライブラリは文法を強制しますが、独自の処理が加わります。また、固定の回答から選ぶだけでよいときに、応答全体を生成するのは不要な作業です。記事はこれらを裏づける速度、コスト、精度の実測比較を示していないため、これらは論拠であり結果ではありません。

質問には3つの型があり、プリミティブと呼ばれます。choice（選択）は複数の回答から1つを選び、それぞれの確率を返します。score（スコア）は順序つきの尺度で評価し、レベル番号の期待値を返します。3つ目はベルヌーイ分布にちなんで「noul」と呼ばれ、はい/いいえの質問に、その文が真である確率で答えます。選択とスコアの質問には、結果にconfidence（信頼度）フィールドも付きます。K個の選択肢がある選択では、信頼度は最大確率から1/Kを引き、1から1/Kを引いた値で割ったもので、一様分布なら0、完全に集中していれば1です。記事の例では、部門の質問は「billing」を確率0.998、信頼度0.997で返します。緊急度のスコアは1.705、信頼度は0.558で、記事はこれを分布の期待値であり、「中」と「高」の中間のレベルではないと説明しています。

記事はデシジョンモデルを2つの従来手法と比較しています。従来の分類器は出力クラスが分類ヘッドに固定されているため、法務のような4つ目の部門を加えるには新しいデータと再学習が必要になることがあります。ゼロショット分類は推論時にラベルを与え、記事は請求、技術サポート、営業、そして変更後には法務についてスコアを返すモデルを示しています。記事は、デシジョンモデルの利点は実行時ラベルや確率を発明したことではなく、それらを1つのインターフェースにまとめたことだと述べます。同じ状態に対して型付きの複数の質問ができ、順序つきスコアとはい/いいえの判断をネイティブに扱えます。記事自身の表では、分類は選択肢の確率を返すものの推論時にラベルを定義できず、複数の型付き質問を持つのはデシジョンモデルだけです。

ツールに影響するのは、Hugging Faceのスタックでの対応です。Transformersには新たにDecisionPipeline、AutoModelForDecisionクラス、DecisionConfigクラスがあります。互換性のあるバージョンのTransformersで「transformers serve」を実行すると/v1/systemoneエンドポイントが公開され、記事は3つの質問を含む1回のリクエストが3つの型付きの回答を返す例を示し、使用量は入力148トークン、出力0トークンです。llama.cppも同じAPIでデシジョンモデルを提供します。例では「llama serve -hf ggml-org/Kev-4B-GGUF」を起動し、既定のサーバーポートは9931です。記事は、このインターフェースが互換性のある自己回帰型の言語モデルでも動くと補足しています。Transformersが判断用のプロンプトを組み立て、1回のバッチ前方計算で回答ラベルのロジットを読み、softmaxを適用し、文章は生成しません。そのため、新しいモデルを学習しなくてもこのインターフェースを試せます。

探索と学習について、Hubには新しい「decision-model」タグがあります。記事によると、デシジョンモデルは同じバックボーンを共有する必要はなく、ModernBERTのようなエンコーダーに基づくものもあれば、より大きな生成型の言語モデルに基づくものもあります。学習では、デシジョンモデルはTrainer APIで微調整できます。記事は意図的に小さな例を示しており、6件のサポートメッセージでautotrust/JEV-9Bを学習率1e-3で30ステップ微調整し、選択の質問には選択肢上の通常のクロスエントロピーを使います。TRLでの本格的な学習サポートは近日対応予定で、関連するプルリクエストhuggingface/trl#8040は記事執筆時点でまだ開いていたと記されています。また、LoRAとデシジョンスコアリングヘッドでQwenのようなモデルを微調整するUnslothのレシピも案内されています。

読者が念頭に置くべき限界があります。記事の本文では、名前の挙がったデシジョンモデルについて、精度、キャリブレーション、遅延のベンチマークが示されていないため、「信頼でき、キャリブレーションされた判断」は記事が述べる目標であり、発見ではありません。本稿は記事のリンク先の画像やページは開いていません。計算例も完全には一貫していません。ある表では緊急度の確率が0.10、0.26、0.72で、合計が1.08になるため、この表は有効な確率分布ではありません。一方、印刷された出力は0.0149、0.2648、0.7203です。ある文は勝つ確率を0.80としながら、その後0.99で計算しています。選択肢が3つの場合、式では0.80なら信頼度0.70、0.99なら0.985になり、記事は0.98と印刷しています。印刷された値のうち2つは、印刷された確率から再計算できます。choiceの信頼度は(0.99827 − 1/3) ÷ (1 − 1/3) ≈ 0.9974、scoreの期待値は0 × 0.0149 + 1 × 0.2648 + 2 × 0.7203 ≈ 1.705で、どちらも印刷された出力と一致します。scoreの信頼度の式は記事に示されていないため、上の0.558は記事が報告した値であり、本稿では検証していません。表と本文中の数字は例示として扱うべきです。名前の挙がったautotrust/GEV-26B-Decide、ggml-org/Kev-4B-GGUF、autotrust/JEV-9Bは本稿では試しておらず、記事には名前以外のライセンスや仕様は書かれていません。

現在、JSONを書く言語モデルでチケットの振り分け、リスクの採点、コンテンツのフィルタリングを行っているチームにとって、実務上の問いは狭いものです。固定された回答に確率を返すモデルがその判断に合うか、自分たちの言語と分野で十分なチェックポイントがあるか、ということです。記事が提供するのは、共通のAPI、通常の言語モデルで試す方法、小さな学習レシピです。デシジョンモデルが現在の方法に勝つ証拠は提供していません。その比較は、チーム自身のデータで行う必要があります。