Jev LLM ルーター：各プロンプトを、処理できる最も安いモデルへ

このルーターがチェックすること

上の例は 1 件のユーザーリクエストです。センサー測定値を収めた 2GB の CSV 向けにストリーミングパーサーを書き、デバイスごとの欠損を検出しつつ、メモリ使用量を 500MB 未満に抑えるというものです。Jev は 1 回の呼び出しでこれについて 3 つの質問に答えます。

route が判定そのもので、残りの 2 つはログに記録するシグナルであり、ルーティングにも使えます。このリクエストはあえて境界線上のものを選んでいます。作業自体はごく普通の Python ですが、メモリ制限とストリーミングの要件があるため、単純な調べものでは済みません。そのため注目すべき出力は、確率が medium と frontier にどう分かれるか、そしてその分かれ方に Jev がどれだけ確信を持っているかです。

短いプロンプトに対する 3 つの質問は 1 クレジットで、Jev はリクエスト内のすべての質問を並列に評価するため、追加の 2 つによるレイテンシの増加はほとんどありません。

うまく機能するルーティング用の質問の書き方

ティアはモデル名ではなく作業内容で説明する。 Jev は、あなたの「small」モデルに何ができるかを知りません。「高速で安価なモデルで十分」は出発点になりますが、LangChain のルーター例にある「明確な対象がある直接的な調べもの、抽出、局所的な変更」のような表現のほうが、タスクの種類を名指ししているので優れています。

{
  "type": "choice",
  "instructions": "Which model tier should handle this request?",
  "criteria": {
    "small": "Lookups, extraction, rewording and short edits with an explicit target",
    "medium": "Multi-step tasks and ordinary code with clear requirements",
    "frontier": "Novel reasoning, architecture, or code with hard constraints"
  }
}

判定を直接尋ねる。 route の Choice なら、行動に使える分布が 1 つ得られます。difficulty だけからティアを導こうとすると、Score に対して区切りを自分で作らなければならず、調整が難しくなります。

必須要件ごとに Noul を追加する。 コード関連のタスクを必ずコード用モデルに送る必要があるなら、ティアの説明でカバーされることを期待するのではなく、needs_code を尋ねてください。「個人データを含む」や「長いコンテキストが必要」なども同様です。

数え上げを質問に含めない。 TypeSafe は数値の精度を弱点として文書化しています。「入力は 10,000 トークンを超えるか？」はコードで判定すべきもので、Jev の質問にするものではありません。

質問の書き方について詳しくは、Jev が答えられる質問の設計 をご覧ください。

1 回のチェックからルーティング層へ

1. 最初の生成の前にルーティングする。 受け取ったプロンプトで Jev を呼び出し、route を読み取り、そのティアのモデルにリクエストを送ります。TypeSafe のドキュメントでも、モデルルーティングがまさにこの形でユースケースとして挙げられています。意図とドメインを分類し、難易度とリスクを見積もり、より強力なモデルが必要なものをエスカレーションする、というものです。
2. 信頼度を 2 つ目の軸として使う。 TypeSafe の信頼度ゲート型ルーティングのパターンでは、選択を「何を するか」、信頼度を「実行するかどうか」として扱います。ルーターの妥当なデフォルトは、信頼度が低いときは 1 つ下ではなく 1 つ上のティアに送ることです。簡単なプロンプトを大きなモデルに送っても少し費用がかさむだけですが、難しいプロンプトを小型モデルに送ると、失敗した回答と再試行のコストが発生します。
3. 選択と一緒に分布も記録する。 想定より費用がかかった実行があったとき、確率を見れば、ルーターが確信していたのか当て推量だったのかがわかります。
4. モデルバージョンを記録する。 すべてのレスポンスには jev-1.13.0 のような model フィールドが含まれます。判定ごとにこれを記録し、変わったときはしきい値を見直してください。JevStation がモデルを固定するため、リクエストごとに選ぶ必要はありません。
5. コードやフレームワークから呼び出す。 同じ評価を API Key を使って System One API からも実行できます。LangChain では、ModelRouterMiddleware（実験的）が最新のユーザーメッセージからモデルを選び、実行全体でそのモデルを使います。

ルーティング、ゲーティング、エスカレーションを 1 つのエージェントループにまとめる、より広いパターンについては Jev でハーネスを構築する で解説しています。

信頼する前に確かめる

• 自前のプロンプトのサンプルにラベルを付ける。 Classmethod のエンジニアは 4 つのティアにまたがって 40 回呼び出し、各ティアで 10 回中 10 回期待どおりのティアを得ました。中央値は約 0.65 秒、1 回あたりの費用はおよそ $0.000025 でした。この記事では、各ティアのプロンプトが 1 つずつであり、精度ベンチマークではないことが明記されています。あなたのトラフィックこそがベンチマークです。
• 中間のティアに注目する。 同じテストでは、両端のティアは信頼度 1.0 で返った一方、中間のティアは 0.57〜0.67 にとどまりました。境界線上のプロンプトこそ、ルーターがコスト削減を生むか失うかの分かれ目なので、まずそこを確認してください。
• 単純なベースラインと比較する。 LiteLLM が公開したベンチマークでは、ルールベースの複雑度スコアの AUC は 0.524 で、ほぼランダムでした。10 行で書けるルールに Jev のティアが勝てないなら、そのルーターは元が取れていません。
• 精度だけでなく節約額も確認する。 small が選ばれた回数と、それらの回答で再試行が必要になった回数を数えてください。ほぼ常に frontier を選ぶことで一度も間違えないルーターは、何も節約していません。

Jev がルーターに向かない場面

• 判定が数値に依存する場合。 トークン数、コンテキスト長、価格の計算は分類ではなくコードの仕事です。
• ルーターに説明させる必要がある場合。 ユーザー向けや監査ログ向けの説明が必要なケースです。Jev が返すのは確率であり、理由ではありません。
• 判定だけでなくゲートウェイそのものが必要な場合。 Jev はティアを選びますが、リクエストのプロキシ、再試行、フェイルオーバーは行いません。すでに使っているゲートウェイやクライアントライブラリと組み合わせ、Jev にはリクエストをどのモデルに送るかの判断だけを任せてください。
• どのみち全リクエストが同じモデルに送られる場合。 1 つのモデルで全トラフィックを賄えるほど安価なら、ルーターは呼び出しを 1 回増やすだけで何も節約しません。

自分のプロンプトとティアを プレイグラウンド で試すか、大量利用時のルーティング判定の費用を 料金ページ で確認してください。