Hugging Faceは、回答を書き出さず、事前定義された選択肢を評価し、それらの選択肢に対する確率分布を返すモデル群である「意思決定モデル」を紹介している。同社は、単一のアーキテクチャを強制することなく、これらのモデルのための共通インターフェースを定義しようとしている。
トークン単位、つまりテキストの断片単位で回答を生成する大規模言語モデル（LLM）は、文章作成、プログラミング、推論において非常に効果的だ。しかし、すべての問題がテキスト生成を必要とするわけではない。例えば、次のようなメッセージを受け取るカスタマーサポートシステムを考えてみよう：「私のサブスクリプションが二重に引き落とされました。今日中に返金が必要です。」このシステムは、どのチームがリクエストを処理すべきか、その緊急度はどの程度か、顧客が返金を求めているかどうかを判断しなければならない。
LLMにこれらの回答をJSONオブジェクトとして返すよう依頼することは可能だ。このアプローチは分類やルーティングですでに広く使われているが、いくつかの制限がある。モデルが要求されたスキーマを守る保証はない。無効なJSONを生成したり、予期しないキーを追加したり、許可された選択肢以外で回答したりする可能性がある。OutlinesやXGrammarのような制約付きデコードライブラリは、各ステップで許可されるトークンを制限することでこのリスクを低減するが、追加の作業が発生する。最後に、アプリケーションが既知の回答の中から選択するだけでよい場合、完全なテキスト生成は冗長になり得る。
確率に基づくインターフェース
意思決定モデルは、評価すべき情報である「状態」と、「質問」のリストを受け取る。そして、確率を伴った決定を返す。ソースは質問のタイプを3種類に分類している。「choice」タイプは複数の選択肢から1つを選ぶ。「score」タイプは何かを順序付けられた尺度で評価する。「noul」タイプは、確率的な形式でYes/No質問に答える。
提示された例では、モデルautotrust/GEV-26B-Decideは、サービス質問に対して以下の確率を割り当てている：Billing 0.998、Technical support 0.001、Sales 0.001。緊急度については、low、medium、highのレベルがそれぞれ0.10、0.26、0.72を受け取っている。返されるスコアは、この分布の期待値、すなわち1.7であり、中間のレベルが選択されるわけではない。「顧客は返金を求めているか？」という質問に対して、モデルは直接、肯定的な回答の確率、ここでは0.92を返している。
「choice」および「score」タイプの質問に対して計算される「信頼度」の概念は、これらの確率の集中度を要約するものだ。この概念は完全に新しいものではない。TypeSafe AI社は、かつて「System One」モデルと称されるJevを紹介していた。「意思決定モデル」という用語は最終的にコミュニティで採用された。これは、特定の認知理論に言及することなく、モデルの計算上の役割を説明するためだ。
構築中のエコシステム
新しいフォーマットはすでに複数のツールでサポートされている。Transformersライブラリは、DecisionPipeline、AutoModelForDecisionクラス、DecisionConfigクラスを提供し、ローカルサーバー起動後の/v1/systemoneエンドポイントも提供する。推論エンジンllama.cppも、同じAPIを介してこれらのモデルを受け入れる。ソースは、ポート9931で提供されているモデルggml-org/Kev-4B-GGUFを引用している。Hubは専用タグdecision-modelを提供している。これらのモデルは必ずしも同じアーキテクチャを共有しないためだ。ModernBERTのようなエンコーダーに基づくものもあれば、より大きな生成モデルに基づくものもある。
推論の設定が済むと、ソースは学習に話題を移す。デモ例では、Trainer APIを用いて、モデルautotrust/JEV-9Bをサポートリクエストのルーティング用にファインチューニングしている。TRLでのネイティブ学習サポートは、マージリクエスト（PR #8040）の対象となっており、本記事執筆時点ではまだオープンだ。また、Unslothは、LoRAとスコアリングヘッドを用いて、Qwenのような生成LLMを意思決定モデルに変換するレシピを提供している。
