話題の Jev を調べてみた：RAG での活用とローカル実行の可能性

はじめに

最近、TypeSafe AI が9月15日に早期アクセスを開始した Jev というサービスが話題になっていて、よく耳にするようになりました。LLM を扱っている身としては、新しく RAG を構築する際に活用できるという話を聞いて気になっていたので、Jev とはどのようなものか、RAG でどう使えるのか、ローカルでも動かせるのか、を調べてみました。

Jev とは

Jev は、元 OpenAI の研究者が立ち上げた TypeSafe AI が開発した AI モデルです。一般的な LLM のように文章を生成するのではなく、事前に決めた選択肢の中から答えを選び、その確率とあわせて返す、という「判断」に特化しています。

想定されている用途は、リクエストのルーティング、LLM のツール呼び出しが妥当かどうかのチェック、検索結果の再ランキング、ルーブリックに沿ったスコアリングなど、「選択肢 → 答え」の形に落とし込める判断です。

例えば、Agentic な RAG を構築しようとした時に、

def score_relevance(query: str, document: str) -> float:
    prompt = (
        f"次のクエリと文書の関連度を0〜10の数値で採点してください。数値のみを返してください。\n"
        f"クエリ: {query}\n文書: {document}"
    )
    response = llm.invoke(prompt)
    return float(response.content)

のようにして、文章をバイナリで評価したり、もしくはスコアを出させるような使い方をして、それを元に LangGraph で複雑なワークフローを構築していたわけです。

しかしこの使い方では、LLM の出力が毎回同じ形式で返ってくるとは限らず、パースに失敗することがありました。数値のはずが「7点だと思います」のような文章になっていたり、同じ入力でも出力がわずかにブレたりします。候補が多いと、1件ずつ生成を待つ必要があるため、レイテンシも積み上がります。また、判断だけのために汎用の大きなモデルを都度呼び出すのは、コスト的にも割高でした。

出力がスキーマに固定され、判断だけを返すことに特化したモデルがあれば、こうした問題を避けられそうです。

TypeSafe AI が提供する Jev は、まさにこの「判断だけを返す」ことに特化したモデルです。料金は入力100万トークンあたり $0.042、出力トークンは無料で、応答時間は70〜500msとされています。文章を生成しない分、高頻度に呼び出す用途に向いた価格・速度になっています。

提供形態はクローズドウェイトの hosted API（POST /v1/systemone）のみで、モデルの重み自体は公開されていません。

Claude Code や Codex との連携もあります。jkudish/jev-mcp という MCP サーバーが、Jev の判断機能を MCP ツールとして公開しています。ブラウザ操作用の jev-browser という別の MCP サーバーもあり、LLM が操作の計画を立て、実際のクリックやキー入力の選択を Jev が担う、という使い方もできるようです。

Jev の技術的な仕組み

Jev は、LLM のように出力を1トークンずつ自己回帰的に生成するのではなく、あらかじめ定義された質問に対する確率を並列に出力します。TypeSafe AI はこれを「parallel sampling」と説明しており、複数の判断を1回のクエリでまとめて返せることが、低レイテンシにつながっています。内部アーキテクチャの詳細は公開されていません。

複数の出力を逐次生成する必要がなく、複数の質問を並列に処理できるため、自己回帰型 LLM と比べて低レイテンシで多数の判断を返せる設計になっています（ただし、選択肢が255択に近いような高 cardinality な Choice では、候補を個別に採点してから選択する2段階の処理が入り、レイテンシが伸びることもあるようです）。

質問には3つの型があります。

• Choice：順序のないカテゴリから選ぶ（最大255択）。チケットの振り分けや言語判定など
• Score：順序付きスケール上での判定（2〜10段階）。バグの重大度や満足度評価など
• Noul：ある命題が成り立つかどうかを、Yes/No の確率として返す判断。「この文書は関連していますか？」に対して確率をそのまま返す、といった使い方

確信度は、選択肢数を $n$、最大確率を $p_{max}$ として、次の式で計算されます。

$$\text{confidence} = \frac{n \times p_{max} - 1}{n - 1}$$

均等な確率分布なら確信度は0、1つの選択肢に確率が集中していれば1に近づきます。

学習には、RLHF（人間のフィードバックに基づく強化学習）ではなく、**RLCD（Reinforcement Learning for Calibrated Decisions）**という手法が使われています。TypeSafe AI は、RLHF で学習した LLM には、過信（overconfidence）や mode dropping（複数の妥当な選択肢を無視してしまう現象）など、確率的な判断の自動化に使う上での課題があると説明しています。RLCD は代わりに「予測した確率が、実際に的中する頻度と一致すること」を最適化します。理想的に校正されたモデルでは、0.8の確率を付けた予測群が実際にも約80%正解する、という状態を目指す、という考え方です。

何が新しいのか

「文章ではなく判断だけを返す」という発想自体は、実は目新しいものではありません。BERT にクラス分類ヘッドを載せて、文章を入力しラベルごとのスコアを得る、という手法は以前からあります。Jev の違いは、タスクごとに専用の分類器を学習・ファインチューニングする必要がなく、リクエスト時に質問と選択肢を文章で指定するだけで使える点です。

検索の関連度スコアリングという点では、既存の cross-encoder 型の reranker とも役割が重なります。Jev は「関連しているか」だけでなく「クエリの前提と矛盾していないか」のような自由な形式の判断も同じ枠組みで扱える、という違いがあるとされています。

なお、TypeSafe 自身も、独立した研究者による XGBoost やファインチューニング済み BERT との厳密な比較実験は公開していません。実際に reranker として試した事例では、候補ごとに1問ずつ質問するより、候補群全体に対して1回で質問した方が効果的だった、という報告もあります。

RAG への活用

前述の、文章を評価して Agentic な使い方をする以外にも、RAG との相性が良い使い方があります。

例えば、RAG では、検索で取得した候補を、質問との関連度が高い順に並べ替える「rerank」という処理がよく使われます。

Jev には、複数の選択肢から1つを選ぶ Choice 型（top-1 selection）と、個々の対象について Yes/No の確率を返す Noul 型があります。rerank は候補全体の並び順を保つ必要がある処理なので、Choice で「最も関連する1件」だけを選ばせるのではなく、候補ごとに Noul で「この文書はクエリに関連していますか？」と問い、その確率でソートする、という使い方が実際の reranker 実装では採られているようです。

先ほどの score_relevance のように候補を1件ずつ LLM に投げるのではなく、候補ごとの質問をまとめて1回のリクエストで送る、というイメージです（Jev の実際のレスポンス形式は公式ドキュメント参照）。

# イメージ: 候補ごとに Noul で関連性を判定し、確率でソートする
questions = {
    f"doc_{i}": {"type": "noul", "question": f"この文書はクエリに関連していますか？\n{doc.text}"}
    for i, doc in enumerate(candidate_docs)
}
response = jev.decide(state=f"query: {query}", questions=questions)
ranked_docs = sorted(candidate_docs, key=lambda doc: response[f"doc_{candidate_docs.index(doc)}"].probability, reverse=True)

候補ごとに LLM を1件ずつ呼び出していた score_relevance のフローを、1回のリクエストにまとめられそうです。rerank は1回のクエリで何度も呼び出される処理なので、応答が速く（70〜500ms）、出力トークンが無料という Jev の料金体系も、この用途と相性が良さそうです。

ただし、これは公式が挙げているユースケースからの推測であり、実際に RAG パイプラインに組み込んで効果を確認したわけではありません。導入を検討する場合は、自分の用途で実際に試してみる必要があります。

ローカルでの実行は可能か

私はクローズドな環境を前提とした RAG 運用を考えることが多かったので、これが一番気になっていました。

結論から言うと、公式の Jev 自体をローカルで動かすことはできません。TypeSafe AI はクローズドウェイトの hosted API としてのみ Jev を提供しており、モデルの重みは公開されていません。

ただし、Jev の発表後、「OpenJev」などの名称で、同様の decision interface をローカルモデルで再現しようとするコミュニティ実装がいくつか登場しています。ただし「OpenJev」という名前を使ったプロジェクトは1つではなく、拡散モデルを使うもの、Hugging Face 上の通常の instruct モデルを使うものなど、それぞれ別の作者による別々の実装が複数存在するようです。導入を検討する場合は、名前だけで判断せず、リポジトリごとに中身を確認する必要があります。

これらはいずれも TypeSafe AI 公式との提携がない独立したコミュニティプロジェクトです。品質や校正の精度は公式の Jev とは別物である点に注意が必要です。

おわりに

Jev は、文章を生成せず判断だけを返す、という発想が新しい AI モデルでした。RAG の rerank のような、選択肢から答えを選ぶタイプの処理には向いていそうです。公式はクローズドウェイトの hosted API のみですが、OpenJev のようなコミュニティ実装を使えば、同じ発想をローカルでも試せそうです。

今回は調べるだけに留めましたが、機会があれば実際に触ってみたいと思います。