ソフトウェアの中でAIが担う仕事の多くは、書くことではなく選ぶことです。このサポート依頼はどのチームに回すか、どれほど急ぐか、顧客は返金を求めているか、といった判断です。新しい種類の判定モデルは、テキストを生成する代わりに確率でこうした問いに直接答えます。Hugging Faceは、自社のツール全体でこれらに共通のインターフェースを用意しました。開発者にとっては、ある判定モデルで作ったルーターや分類器を、接続部分のコードを書き直さずに別のモデルに差し替えられるようになるということです。
インターフェースは単純です。判断の材料となる「状態」をテキストか構造化されたJSONで送り、名前を付けた質問を添えます。各質問は三つの基本型のどれかを使います。choiceは選択肢から選び、それぞれの確率を返します。scoreは順序のある尺度で評価し、期待される段階を返します。nounは、はい・いいえの質問に「はい」である確率で答えます。choiceとscoreの回答には信頼度も付き、選択肢に均等に分かれている場合が0、完全に確信している場合が1になるよう調整されています。Hugging Faceの請求の例では、モデルはbillingに0.998を付け、信頼度にすると0.997になりました。
ニュースは基盤の部分にあります。TransformersにはDecisionPipeline、AutoModelForDecision、DecisionConfigが加わり、transformers serveは/v1/systemoneというエンドポイントを提供します。私たちがレビューしているllama.cppも同じエンドポイントで判定モデルを提供するため、Hugging Face上のモデル向けに書いたリクエストがローカルのGGUFモデルでもそのまま動きます。Hubにはdecision-modelタグができ、モデルは通常のTrainerで微調整でき、choiceの質問は選択肢に対する単純な交差エントロピーで学習します。記事によれば、このインターフェースの背後にあるモデルはさまざまで、ModernBERTのようなエンコーダーから大型の生成モデルの上に読み出し部分を載せたものまであります。
背景も重要です。私たちがレビューしているTypeSafe AIのJevは、System Oneモデルという呼び名でこの考え方を広めました。GoogleもちょうどGemini Decisions APIを公開し、同じ三種類の質問形式を採用しています。共通のオープンな形式があれば、それらを互いに比べたり、チャットモデルにJSONを出力させる方法と比べたりしやすくなります。記事が指摘するように、後者はスキーマを崩したり、許された選択肢の外で答えたりすることがあります。
限界は実務的なものです。標準のインターフェースがあっても、モデルが正確になったり較正されたりするわけではなく、信頼度は確率を尺度変換したもので保証ではありません。あるコメント投稿者が指摘するように、本番運用で難しいのはしきい値を選び、後から届く実際の結果と照らし合わせて確かめることです。他のモデル開発者が独自のAPIを守るのではなくこの形式を採用するかどうかで、その意義が決まります。