決定モデルは、エージェントループのLLMを静かに置き換えつつある

Cloudflareは10月最初の数日で、何も書き出さない2つのモデルをリリースした。ClefとClef-flashは、入力と一連の型付き質問を読み取り、許可された各回答に対して確率を返す。文章も、思考の連鎖も、1トークンずつ生成されるトークンもない。あるのは構造化された選択だけだ。

それは後退に見えるかもしれないが、数字を見れば評価は変わる。標準的な意図分類ベンチマークであるBANKING77で、ClefはマクロF1が94.20、決定モデルというカテゴリを打ち出したJevは79.74だ。より小型の9B版であるClef-flashでも90.93を記録する。レイテンシの差はさらに大きい。Clef-flashの回答の中央値は38.8ミリ秒で、Jevは524.1ミリ秒かかる。Cloudflareによれば、Clefは10の決定ベンチマークのうち7つでJevを上回る。

両モデルはHugging Face上でApache 2.0の下に公開され、JevのAPIとも互換性がある。すでにJevを前提に構築しているチームは、統合部分を書き直すことなく乗り換えられる。Hacker Newsのスレッドは1日で602ポイント、200件を超えるコメントに達した。

より小さなモデルが、より狭い仕事で勝てる理由

決定モデルは、多くの開発者が手を伸ばすチャットボットとは形が違う。大規模言語モデルは自由形式のテキストを生成する。決定モデルは状態と許可された回答のリストを読み取り、それぞれをスコアリングする。このカテゴリを切り開いたのはTypesafe AIのJevで、エージェントのルーティングや分類タスクには400Bの汎用モデルは不要だと示した。必要なのは、範囲が限定され、安価で、高速な出力だ。

CloudflareのClefはQwen3.8-27Bをベースに、トークンを逐次生成する代わりにスキーマの選択肢を並列にスコアリングするprefill-onlyアーキテクチャを採用している。レイテンシはそこから生まれる。汎用モデルは回答をトークンごとに出力しなければならないが、決定モデルは問いを読んで確定するだけでよい。

注目に値するコンテキストの違いもある。Clefは64kトークンのウィンドウ内でマルチモーダル入力を受け付け、テキスト、JSON、画像、動画をカバーする。Jevは32kでテキストのみを扱う。スクリーンショットやPDFでルーティングするエージェントにとって、これは小さな利点ではない。

コミュニティの最初の反論は、正しいものだった

Hacker Newsでの議論で最も有用な反論は、ベンチマークに異を唱えるものではなかった。異を唱えたのはラベルだ。「オープンソースではなく、オープンウェイトだ」とあるコメント投稿者は書いた。重みには寛容なライセンスが付いているが、学習データとパイプラインは公開されていないため、モデルをゼロから再現することはできない。

この区別は、これをどこで動かすかを決める人にとって重要だ。ClefはプロプライエタリなQwenを出発点として学習されている。重みは自由にダウンロードしてホストでき、これは実際のコスト削減になるが、オープンソースソフトウェアのようには監査できない。厳格なサプライチェーン審査ポリシーを持つチームは、Apache 2.0というタグで話が済むと決めつける前に、ライセンスとモデルカードを読むべきだ。

同じ週、AmazonはそれをあなたのノートPCに載せた

動いたのはCloudflareだけではない。AWSのStrands LabsはStrands Decider 2Bを公開した。重みと学習スクリプトを伴うオープンな決定モデルで、ローカルで動作し、数十ミリ秒から数百ミリ秒の範囲で信頼度スコア付きの選択肢を返すよう設計されている。Cloudflareもまた、Workers AI上の決定モデル向けにRLファインチューニングサービスを追加した。

パターンは、小さなモデルが1つの仕事をうまくこなし、データの近くで動くというものだ。ツール呼び出しの可否を判断し、リクエストが根拠に基づいているかを検証し、エスカレーションすべきかを決める——それが2Bモデルで40ミリ秒でできるなら、エージェントのあらゆるステップをフロンティアモデル経由でルーティングする経済性は、無駄に見え始める。

Jevが持ち込んだパラダイムと、浸透に1年かかった理由

Typesafe AIのJevは、登場当時は一蹴しやすい主張を掲げていた。エージェントがモデルに求めることの大半は生成ではなく分類だ、というものだ。このチケットを振り分け、このツールを選び、この操作に承認が必要かを決める。そうした仕事に対して、段落を書くモデルはタスクが必要とする以上の仕事をしている。

Jevは、狭いアプローチが自社ベンチマークで汎用モデルを上回り得ることを証明した。ただし、このカテゴリを喫緊のものに感じさせることはできなかった。単一のベンダーが決定モデルを1つ売っているだけでは、珍品にすぎない。JevのAPIと互換性のあるApache 2.0版をCloudflareが出荷するとなれば話は別で、誰もがホストし、ライセンスを確認し、書き直しなしで差し替えられる。同じ週にAmazonが独自のオープンなデサイダーを持ち込んだことで、珍品はカテゴリになった。

このタイミングは、エージェントが実際にどう作られているかと符合する。第一世代のエージェントフレームワークは、最も単純だという理由で、あらゆるステップを1つの大規模モデル経由でルーティングしていた。そうしたシステムが本番環境に移行するにつれ、チームが気づくのはルーティングコストだ。ループを、言語が必要な部分は言語モデルに、不要な部分はデサイダーに分割するのは明快な解決策であり、優れたデサイダーがオープンに公開されて初めて実用的になった。

ファインチューニングという観点

CloudflareはWorkers AI上の決定モデル向けにRLファインチューニングサービスも追加しており、これがこのカテゴリの次の行き先を示している。汎用のデサイダーは有用だ。自社のルーティング履歴、自社のエスカレーションルール、自社のスコープ感覚でファインチューニングされたデサイダーはさらに有用で、自社にとって重要な境界を学習する。

同時に、ここはチームが慎重になるべき部分でもある。ファインチューニングされたデサイダーは、悪い判断を含む過去の決定をそのまま符号化する。本来エスカレーションすべき返金を承認していたなら、モデルはそのパターンを学習し、人間には到底できない速さで適用する。キャリブレーションは諸刃の剣だ。

エージェントパイプラインのどこに収まるか

返金を処理するサポートエージェントを想像してほしい。返金ツールを呼び出す前に、何かが次のような問いに答える必要がある。このリクエストはスコープ内か、顧客のアカウントで許可されているか、人間の対応が必要か。これらは答えが固定された決定の問いだ。決定モデルは確率を返し、エージェントはしきい値に基づいて行動する。

要点はコスト構造にある。そうしたチェックの一つひとつを400Bモデル経由でルーティングすれば、呼び出しごとにお金がかかり、数百ミリ秒のレイテンシが加わる。それらをローカルの2Bまたは9Bのデサイダーにオフロードすれば、フロンティアモデルは本当に言語が必要な部分——返信の作成、長いスレッドの要約、曖昧なケースの処理——に取っておける。コスト予算もレイテンシ予算も縮む。

ただし落とし穴がある。決定モデルは確率を返すが、確率は自信たっぷりに間違えることがある。0.92というスコアで返金承認を自動化すれば、リスクはモデルの文言からあなたのしきい値へと移ったことになる。注目すべき指標は生の精度ではなくキャリブレーションだ。レイテンシとコストは測定しやすいが、よくキャリブレーションされた0.9はより難しい。

次に注目すべきこと

ツール群はすでにモデルを追いかけている。llama.cppは決定モデルのサポートを追加し、PerplexityとHugging Faceはいずれも同じ方向に賭けている。このカテゴリが定着するなら、興味深い問いは「どの決定モデルがベンチマークで勝つか」ではなく「どの決定を確率に委ねることを許容するか」になる。

エージェント開発者にとっての実践的な一手は、ループを監査し、流暢なテキストを必要としなかったステップを見つけることだ。分類、ルーティング、ツール選択、アクション前のチェックが典型的な候補になる。固定された選択肢に対する40ミリ秒の回答が、遅く高価な生成を置き換えられるステップだ。エージェントの残りの部分は、すでに使っているモデルのままでよい。