著者: @eddiedzhou, @mr_cheu, @MatZhao, @CosmicPegasis19, @manav_ai
Jev は、型付きの意思決定を行うためのモデルです。コンテキストとあらかじめ決まった質問・選択肢のセットを送ると、テキストを生成する代わりに選択結果、スコア、確率を返します。まさに「システム 1」モデルなのです！
しかし、分類自体は目新しいものではありませんし、構造化出力や小型モデル、logit から確率を読み取る手法も同様です。この歴史的背景が、Jev に対する賛否両論の理由の一部を説明しています...
懐疑派の指摘にも一理ありますが、Jev にはこのエコシステムにおいて確かな居場所があります。それを理解するために、まずは解決策の全体像を整理してみましょう。
他にどんな選択肢があるのか？
システムがラベル、スコア、あるいは Yes/No の回答を必要とする場合、現実的な選択肢は 4 つあります。
アプローチ
採用する理由
トレードオフ
汎用 LLM
ゼロショットで柔軟性が高く、根拠や説明の生成も可能。推論時の計算（推論）によって「より高い知能」を発揮できる arguably。
小さな意思決定のために、自己回帰型モデルのレイテンシとコストを支払うことになる
オープンなゼロショット分類器
低コストでローカル実行でき、制御しやすい
品質にばらつきがある。モデル選定とサービングは自分で管理する必要がある
ファインチューニング済み分類器
ラベルが充実した安定かつ大量処理のタスクでは、通常これが最善手
データ収集、学習、デプロイ、ドリフトへの対応が必要で、タクソノミーの変更がしにくい
Jev
クリーンなホスト型 API の裏側でゼロショットの柔軟性を提供
タスクによって品質が変わる、テキスト生成ができない、プロバイダーに依存する
Jev を選ぶ理由：チームは新たな学習データを集めることなく質問や選択肢を変更でき、しかもモデルをうまくサービングする手間を省けます。これを軽視すべきではありません。「自分たちでも作れる」というのは、ほとんどのインフラ製品に当てはまることです。
オープンな再現実装によって、新規性に関する主張は適度に抑えられています。Qwen と SGLang、DiffusionGemma と vLLM、そして Kev を使った実装が、API やモデルの構造の大部分を再現しています。
n=764 で Jev が 85.7%、Kev-8B が 79.6%
同様に、Parallel による外部テストでも、Jev はリランキングにおいて競争力があることが示されました。ただし、2 つの分類タスクでは依然として特化型モデルが勝利しています。
Glean での検証結果
ここで残るのは実践的な疑問です。ゼロショットの柔軟性とホスト型推論を組み合わせた Jev は、いつ他の選択肢を上回るのでしょうか？私たちは Glean 内で、すでにベースラインが存在し、実際のエンタープライズ品質と比較できる 4 つの限定された意思決定タスクでテストを行いました。これらのベースラインの多くは LLM ベースのシステムであるため、実験においてはコストとレイテンシで 2 桁の改善が見込めると予想していました。結果は、本番環境より明らかに劣るものから、LLM ベースのルーターよりも高速かつ高精度なものまで様々でした。
クエリ分類
クエリ分類は、リクエストを下流システムが利用する大まかなタスクにマッピングする処理です。リクエスト単位ではラベル空間があらかじめ分かっているものの、タクソノミーの変更はファインチューニング済み分類器の再学習よりも速く起こり得るため、これは Jev にうってつけのワークロードです。
この実験では、LLM ベースである本番環境／ベースラインの予測に対する Jev の一致率を測ることに注力しました。Jev によってオフラインのスループットが大幅に向上することは予想通りであり、実際に確認できたため、ここでは品質の分かりやすい指標として一致率を報告します。また、オープンウェイトの意思決定モデルである Laya、およびファインチューニング済みの Laya もベースラインとして比較しました。このファインチューニングはローカル環境で数時間で完了し、モデルも開発者のマシンでサービングできるほど軽量です。
実験
大まかなタスクの一致率
パフォーマンス
Jev ゼロショット
66.8%
~
12 分（同時実行数 4
）
ベース Laya
35.9%
~
90 秒（ローカル開発マシン）
ファインチューニング済み Laya
74.5%
~
90 秒（ローカル開発マシン）
手軽で学習不要な既製モデルとして、Jev は明らかに Laya を上回ります。しかし驚くべきことではありませんが、ファインチューニングによって Laya は真価を発揮します。特にパフォーマンスの数値を考慮するとその差は明白です。トレードオフは、良質なラベルを用意し、学習環境を構築する手間です。タスクが新しい場合やラベルが頻繁に変わる場合は、やはり Jev の方が魅力的でしょう。
モデルルーティング：エキスパート転送
モデルルーティングはクエリ分類と関連する課題です。ここでは、モデルルーティングを「エキスパート転送」として捉え、システムがどのエキスパート／モデルにリクエストを処理させるかを選択します。現在の本番ベースラインでは、ハーネスのエージェントループ内で LLM がネイティブにこの判断を行っています。これは、Jev が生成呼び出しを限定された意思決定に置き換えられるかを試す自然なテストですが、重要な技術的制約として、転送しないケースでは Jev が厳密に呼び出しを追加してしまう点が挙げられます。一方、本番ベースラインでは転送しないケースでも、同じ最初の 1 回の LLM 呼び出しでツール呼び出しの処理を開始できます。
エキスパート 3 つのみを使った簡易版の本番ルーティングを用い、751 件の同等なゴールデンエントリーを更新された Jev ルーターで再生し、既存のプロンプトベースのルーター（従来の LLM を使用）が選択したルートと比較して、ゴールデンラベルに対する精度を測定しました。
また、既存のパスで実際にエキスパート転送の呼び出しが行われた 40 件（n は小さめ）を抽出し、同じエントリーにおける呼び出しレイテンシを比較しました。
エントリーあたりの中央値での高速化は 8.1 倍でした。これはこれまでの社内 Jev 検証の中でも最も優れた結果の一つです。この限定されたルーティングタスクにおいて、Jev はより高精度かつ大幅に高速でした。この差の大きさから、非エキスパート転送リクエストで発生する「ブロッキング」のコストは、許容できるトレードオフだと考えられます。なお、これはあくまでオフラインのゴールデンセット比較であり、レイテンシのサンプルには正例の転送が 40 件しか含まれていないため、リスクの洗い出しとさらなるテストが必要です！
リランキング
Glean にとって非常に身近な課題です！以下の実験では、本番ベースラインを Glean の既存検索スタックが生成した順序としています。そして Jev に最大 50 件の結果の並べ替えを依頼しました。
Jev の型付き出力を通じて関連性を表現する 4 つの方法を試しました。
定式化
関連性の表現方法
Pointwise Noul
各結果に対して個別に Yes/No の関連性質問を行い、「Yes」の確率でソートする。
Shared-state Noul
候補セット全体を共有コンテキストとして Jev に提示し、各結果に対して同じ Yes/No 質問を行う。
Score
各候補に数値の関連性スコアを割り当てるよう Jev に依頼する。
Choice
すべての候補を 1 つの意思決定における選択肢として扱い、得られた確率でランク付けする。
ユーザーがすべての正規表現（canonicals）にアクセスできない内部評価セットで実行したため、絶対値は本番環境のランキングを反映していません。しかし、相対的な数値には注目すべき点があります。
Jev の「Choice」が最も優れた定式化でした。4,855 件の取得済み検索クエリを用いたペア比較コントロールにおいて、本番ベースのタイブレーク除去を行った結果は次の通りです。
Jev Choice のコストはクエリあたり約 $0.00044 で、オフラインテストにおける p50 レイテンシは 0.195 秒でした。しかし、平均的なクエリの 41 個の候補のうち約 37 個に同一のスコアを割り当ててしまいました。これらの同順位の解決に本番環境の順序を使用することで Recall@6 が 40.2% から 44.3% に上昇し、補正なしの結果が Jev のスコア単体で期待される以上に良く見えてしまいました。いつものように多くの注意点がありますが、方向性として言えるのは、Jev は安価で効率的なベースラインであり、Glean の本番ランカーの代替ではないということです。
引用サポートの判定
引用の判定では、関連する 2 つの問いを立てます。証拠が必要な主張に十分な引用があるか（引用再現率）、そして引用元のソースが実際に帰属されている主張を裏付けているか（引用適合率）です。一見すると、出力／ラベル空間が限定されているため（多くのジャッジ設定と同様）、Jev に最適と思えます。しかし、評価基準は複雑で、複数の主張に分解する必要があるかもしれません。さらに、Jev はエラー分析でよく使う根拠（rationale）を生成しないため、品質と使いやすさの両方にリスクがあります。
応答と引用証拠を固定した状態で、本番評価用の実際の 1,448 語の応答を使って Jev をテストしました。推論なしおよび xhigh 推論を使用した GPT-5.6 Luna と、適合率と再現率を共有するパスを比較しました。分散を抑えるため、各ジャッジを 3 回実行しました。
ジャッジ
応答あたりの当初計測時間
応答あたりの当初計測コスト
Jev
6.6 秒
$
0.014
GPT-5.6 Luna、推論なし
81.3〜85.5 秒
$
0.030〜
$
0.047
GPT-5.6 Luna、
xhigh
227.4〜259.7 秒
$
0.047〜
$
0.060
なお、計測時間はエンドツーエンドではなく傾向を示すものです。Jev はクライアント側の逐次ウォールタイムを報告する一方、Luna の行はモデル呼び出し時間の合計です。コストには観測されたキャッシュが含まれています。
また、同じ 28 段落における一貫性も比較しました。「変更あり」とは、同一入力で 3 回実行したうち少なくとも 1 回で、段落の引用カバレッジが十分かどうかの判定が変わったことを意味します。ペアワイズの不一致は、3 つの実行ペアにわたって各段落をカウントし、ジャッジごとに 84 回の比較を行いました。
ジャッジ
再現率の判定が変わった段落数
ペアワイズの再現率不一致数
Jev
28 中 1 (3.6%)
84 中 2 (2.4%)
GPT-5.6 Luna、推論なし
28 中 7 (25.0%)
84 中 15 (17.9%)
GPT-5.6 Luna、
xhigh
28 中 5 (17.9%)
84 中 10 (11.9%)
Jev で変わったのは、ある 1 段落が引用を必要とするかに該当するかどうかだけで、生の再現率カテゴリ自体は変化しませんでした。したがって、段落レベルでの引用カバレッジ判定において、Jev は Luna のどちらの設定よりも再現性が高いと言えます。
これをもって Jev の方が正確なジャッジであると結論づけるわけではありません（システム間でサポート基準やスコアの分母が異なり、独立した人間によるラベリングを行う時間がなかったため）。しかし、xhigh 推論（Luna のモデル時間を約 3 倍に増加）を使っても、一貫性は Jev に及びませんでした。この結果は、限定的な引用ポリシーを実装するための、高速で安価、かつ比較的再現性の高い手段としての Jev を支持するものです。
実験からの学びと実践ガイド
ケースによっては、Jev は従来の LLM やファインチューニング済み分類器の代わりとなる、摩擦の少ない選択肢として輝きます。ベースラインが強力な場合（リランキング）や、小型モデルのファインチューニングが容易な場合（クエリ分類）は、メリットが薄れます。一部のタスク（モデルルーティング）ではより高い品質を示す兆候があり、一貫性と安定性（引用ジャッジ）の向上も見られました。私たちが手がける最も重要なワークロードの一部では、従来の LLM に対して期待通りのコストとレイテンシの優位性を発揮しています。
上記の結果は良い方向性を示しており、Glean では Jev に大きな期待を寄せています。あと数ステップ（主にデータレジデンシーや保証といった運用面の準備）を経て、これらのユースケースの一部に Jev を導入する予定です。また、今週の社内ハッカソンでも Jev が大きな役割を果たす予定で、さらなる結果を共有できるのが楽しみです！
最後に一般的なアドバイスをまとめます。出力を事前に列挙できるなら、Jev をベンチマークしましょう。タスクとラベルが安定していて処理量が多いなら、ファインチューニング済み分類器も併せてベンチマークしてください。呼び出し時にクエリや説明などの動的テキストを生成する必要がある場合は、生成モデルをループ内に残しましょう。ツール呼び出しが良い例です。Jev はツールの選択を支援できますが、Glean のツールのほとんどは依然として動的に生成された引数（検索クエリなど）を必要とします。
Jev は、分類器がすでに存在していたという事実を変えるものではありません。優れたゼロショット分類器を、はるかに使いやすくしてくれるのです。あらゆる AI システムの新たな基盤とは言えなくても、十分に堅実なプロダクトです。
