英語版で読む
技術約13分で読めます

Jevクローン6種の判断モデルを公開コードで比較した

AILLM機械学習Qwen
いけさん目次

JevはTypeSafeがAPIで提供する判断用モデルで、問い合わせ本文と、請求担当・技術担当・その他といった候補を指定すると、担当部署の選択と候補ごとの確率を返す。返信用の文章は生成しない。

Latent.Spaceの「Here are 6 Clones of Jev in 2 days」では、同様の機能を作った6つのプロジェクトが紹介されている。ModernBERTで分類するものもあれば、文章生成用のQwenを転用するもの、拡散モデルの回答欄を使うものもある。
元記事はModernBERTと拡散モデルをJevの中身の有力な推測として挙げている。ただ、6つのプロジェクトには代替モデルを作るもの、推定した構造を実装するもの、仕組みを試す小型モデルが混ざっていて、目的もそれぞれ異なる。

2026年9月20日時点の公式資料と公開コードから、Jevのどの挙動を説明できる構造なのかを比べた。性能の数値は作者の測定報告を基にしている。

Jevについて公開されている範囲

Jevの入力では、判断対象の本文をstate、質問・選択肢をquestionsに指定する。問い合わせ本文から担当部署、緊急度、返金依頼の有無を調べるなら、同じ本文に3つの質問を添える形になる。

公式ドキュメントでは、候補を選ぶChoice、段階評価のScore、真偽の確率を返すNoulを用意している。同じ本文に対する複数の質問を並列に評価し、質問同士は分離するという説明もある。

比較する性質公式に説明されていることそこからは確定しないこと
出力文章を逐次生成せず、判断と確率を返すBERT系か、生成用モデルを転用したものか
複数質問同じ本文を対象に、質問ごとに独立して評価する本文の計算をどの層で共有するか
学習RLCDという、確率の校正を目的とする学習を使う具体的な損失関数、報酬、元モデル
実装新しいアーキテクチャと並列サンプラーを使うという説明層構成、モデル規模、重み

RLCDはReinforcement Learning for Calibrated Decisionsの略で、公式のAI入門（primer）では確率の校正を学習の目標にしている。たとえば「80%」と予測した事例を多数集めたとき、実際にも約80%が正しい状態に近づけることを指す。
クローンでも同じ目標は設定できるが、TypeSafeが使った具体的な学習手順は公開されていない。

公式発表の「確率を並列に出す」という説明にも、処理の単位を区別して見る必要がある。同ブログのWikipedia移動デモでは、候補数が多い場合に個別採点と選択の2段階を使っており、API呼び出し全体が常に1回の計算で終わると明言されているわけではない。

以前のJevの文体判定テストでは、改行やMarkdown記号、質問文を変えた場合の出力を比較した。この記事では、その入力を処理する側の構造を比べる。

6つの実装が選んだ方法

同じ並列処理でも、質問ごとに本文を再計算する方式と、本文部分を共有する方式がある。さらに、質問同士が互いの内容を参照できるか、候補同士を比較して採点するかも異なる。

モデルが文章から作った数値表現を、判断用の点数に変換する出力部分を「ヘッド」と呼ぶ。6つのプロジェクトでは、モデル本体に加え、この点数の取り出し方にも違いがある。

実装本体と出力方法Jevらしい挙動を説明できる点同じ仕組みとは言い切れない点
LayaModernBERT系＋候補採点ヘッド文章生成なしで、毎回変わる候補を評価できる質問ごとに本文を含む入力を作り、本文の計算は共有していない
Kev-0.5BQwen2.5-0.5B＋判断用ヘッド本文の計算共有、質問の分離、候補の比較を実装しているJevと同じ元モデル・学習データ・学習方法という根拠はない
DiffusionGemmaの改造拡散モデルの固定された回答位置を採点複数の回答位置をまとめて評価できる回答位置の並列性だけでは、質問同士の分離や確率の校正を説明できない
Bespoke NimbleQwen3.5-9B＋回答用トークンの点数既存LLMでも、長い文章生成を省いて判断できるMac版の共通入力には全質問の定義が入り、質問間の情報は遮断されない
SemIf（旧OpenJev）Qwen3.5＋3クラス分類本文が候補の主張を支持するかを直接判定できる支持確率は候補ごとの値で、全候補からの選択確率にはなっていない
Jevlike小型の数値表現＋候補ごとの採点候補数が変わる分類器を小さく作れる基本の採点器では候補同士が互いを参照しない

Laya: 質問ごとに本文と候補を別々に入力する構成

Layaの英語用モデルはModernBERT-largeを使っている。文章を数値表現に変換するエンコーダーで、各位置の前後にある文章を参照できる。

Layaは質問文と、その都度指定した選択肢を一緒に入力している。モデル定義では、エンコーダーの後ろに標準で2層のTransformerを配置し、候補の先頭に付けた目印トークンの位置から点数を算出している。
固定した分類名に限られず、利用者が毎回候補を変えられる作りになっている。

複数の質問の扱いは、推論コードに違いが出ている。質問ごとに本文を含む別々の入力を作り、それらを一括処理しているため、質問を増やすと同じ本文の計算量もかさむ。

flowchart TD
    S[同じ本文] --> I1[本文＋質問1と候補]
    S --> I2[本文＋質問2と候補]
    I1 --> B[別々の入力として<br/>モデルで一括処理]
    I2 --> B
    B --> O1[質問1の判断]
    B --> O2[質問2の判断]

一括処理でも各入力に本文が入っているため、本文部分の計算は質問ごとに独立して行われている。

Layaのコードでは、エントロピー（候補の確率の散らばり具合）から確信度を求めている。
候補のどれかに確率が偏っていれば高い確信度になるが、その予測が実際に何割当たるかは、正解付きの事例を集めて確かめる形になる。

Kev: アテンションマスクで本文共有と質問分離を両立

Kev-0.5Bは、Qwen2.5-0.5BにLoRAと判断用ヘッドを追加している。LoRAでは本体の全重みを更新する代わりに、少数の追加パラメーターを学習する。

Layaと比べると、同じ本文に複数の質問を指定したときの処理が異なる。

モデルのコードでは、本文と複数の質問を1本の入力列にまとめ、各位置が参照できる範囲をアテンションマスクで制限している。各質問から参照できるのは本文とその質問自身だけなので、別の質問にだけ書かれた答えは使えない。本文部分は1つにまとめて計算している。

flowchart TD
    S[本文部分の計算を共有] --> Q1[質問1と候補<br/>本文と自質問のみ参照]
    S --> Q2[質問2と候補<br/>本文と自質問のみ参照]
    Q1 --> O1[質問1の判断]
    Q2 --> O2[質問2の判断]

質問1と質問2の間には参照関係がない。各質問の最後にある判断用の位置は、その質問の候補一覧を参照できるため、候補同士の関係を使って点数を付けられる構造になっている。

KevはArcher Hume氏によるJevのAPI調査を設計の参考にしている。同氏は、ある質問だけに書いた情報を別の質問が使えるかなどを調べ、本文を共有して質問を分離する構造を推測した。
Kevはこの仮説を実装した例に当たる。ただし調査で確認できたのはAPIの入出力の挙動であり、Jev本来のマスクの細部や元モデル、学習データまでは判明していない。

DiffusionGemma: 固定した回答位置をまとめて採点

元記事のDiffusionGemmaへのリンク先は、モデルの推論を実行するソフトウェア、vLLMへの変更提案になっている。9月20日の確認時点では、vLLM本体にはまだ取り込まれていなかった。

拡散言語モデルは、未確定の文章を繰り返し更新して回答を作る。この提案では出力用の領域を先に用意し、質問ごとの回答位置をまとめて評価させている。
長い候補名はAやBなど、モデルが1トークン（文字列の処理単位）で表せる記号へ置き換える。回答位置における各記号の点数（ロジット）から、候補の確率を算出している。

更新を1ステップに制限して点数を取得する設定もあり、文章が完成するまで繰り返す処理を省ける。ただし入力処理の計算も別にあるため、この1ステップは回答位置の更新回数を指している。

この提案が扱っているのは、複数の回答位置をまとめて採点する仕組みまでにとどまる。質問同士の情報を分離するには、各位置から参照できる範囲も制限する設計が要る。
また、分布の散らばりに応じて追加評価する仕組みはあるが、予測確率と実際の正解率を合わせるRLCDの学習手順は示されていない。

Nimble: 生成ループを省いて次トークンのロジットで判定

Bespoke Nimbleは、Qwen3.5-9BをLoRAで追加学習している。

候補を1トークンの記号に対応させ、その記号のロジットを取り出す。ロジットは確率へ変換する前の点数で、softmaxという計算を使うと、候補の合計が1になる確率分布に変換できる。
モデル自体はこの点数までを出力し、JSON形式の返り値はPython側で組み立てている。生成用モデルを判断に転用し、回答文を1トークンずつ生成するループを省いた実装になっている。

学習データには、判断に関係する事実を1か所だけ変え、正解が反転する組を使っている。たとえば承認者を変えたら返金できるかどうかも変わる、といった対の例を用意している。
学習手順は候補の正解ラベルを使う方式で、作者はJevからの蒸留、つまりJevの回答を手本にした学習ではないと説明している。

また、並列採点の説明では、Mac向けは本文を含む共通部分の計算結果を使い回し、その後ろに項目ごとの入力を付けている。NVIDIA GPU向けのCUDA版では、項目ごとに全入力を処理しているので、同じNimbleでも本文の再計算が発生するかは実行方式によって違う。

Mac版の共通部分には、本文だけでなく全項目の説明や選択肢も含まれている。そのため、ある項目を採点するときに別の項目の説明も参照できる。
各項目の回答は別々に計算するが、質問の文章は共有されている。本文の計算を共有する点ではKevと似ていても、質問間の情報もそのまま参照できる構造になっている。

SemIf: 自然言語推論（NLI）による候補の3値分類

元記事がSemIf、旧OpenJevとして紹介するモデルの説明ページでは、Qwen3.5の4Bと35B-A3Bを使ったモデルが公開されている。NLI、自然言語推論と呼ばれる分類を使う。

本文と主張を組にして、「本文からその主張が導ける」「矛盾する」「どちらとも言えない」の3種類を判定する。たとえば本文に「同じ請求が2回来た」とあれば、請求の問題だという候補が支持されるかを調べる。
実装では、入力の最後の位置にある数値表現を小さな分類ヘッドに渡し、3種類の点数を計算している。

候補を選ぶrerankの実装は、本文と候補の組を個別に評価し、「導ける」の確率が最大の候補を選んでいる。この確率は各組の3分類の中で求めた値なので、全候補の数値を足すと100%を超えることもある。

説明用に、候補Aを本文が支持する確率が80%、候補Bが70%だったとする。両方とも支持される内容なら、合計が100%を超えてもおかしくない。rerankは80%と70%を比べてAを選ぶが、この80%を「全候補の中からAを選ぶ確率」と解釈すると意味が変わる。

なお、現在のSemIfのブラウザデモでは、選択肢トークンの点数を使う方式も扱っている。上の比較はリンクしたNLIモデルとそのコードが対象で、デモサイトでは別の方式も併用されている。

Jevlike: 候補ごとに独立して計算する小型実装

Jevlikeは、本文と可変個数の候補を受け取り、候補ごとの確率を返す研究用の小型実装。標準では文字列をバイト単位の数値表現に変換し、候補ごとに本文のどこを参照するかを計算している。文章を数値表現に変える部分には、学習済みモデルを使う設定もある。

基本の採点器は、その候補と本文だけを参照する。本文と候補A・Bを固定してCを追加しても、AとBそれぞれの点数は変わらない。

確率はsoftmaxで全候補の合計を1にするので、Cを加えるとA・Bに割り当てる割合は減る。説明用の点数で計算すると、次のようになる。

候補点数（ロジット）A・Bだけの確率Cを追加した後の確率
A273.11%24.47%
B126.89%9.00%
C3候補にない66.52%

丸める前のA/Bの確率比は、どちらも約2.718で変わらない。この性質は公開コードの採点式から分かるもので、「上の候補すべて」「他の候補にはない」といった候補同士の関係を判定するには、他の候補も参照する仕組みがいる。

正解率の近さと内部構造の推測限界

Nimbleの作者による比較では、同じ324例について、作者が用意した正解ラベルとの一致数と一致率を報告している。

モデル一致数一致率
Qwen3.5-9B215 / 32466.36%
Bespoke-Nimble-9B292 / 32490.12%
Jev 1.13.0302 / 32493.21%

追加学習で、この評価の一致率はJevに近づいている。ただし評価用の問題と正解は合成データで、324例は互いに近い162組、元になる題材も6系統に限られる。未知の業務や日本語の長文での精度、Jevが使っている元モデルまでは、この比較からは分からない。

確率の評価には、正解を選んだ割合に加えて、何%と予測していたかも確かめる必要がある。Jevの公式Confidenceの説明でも、confidenceは確率分布から計算する要約値と説明されている。校正を確かめるには、80%と予測した事例で実際に約80%が正解するかのように、予測確率と実際の正解率を照合する。

構造の違いが出そうな入力条件

公開コードの違いから、質問や候補を増やしたときに差が出そうな比較条件を整理した。

入力の変え方確認する変化比較できる設計上の違い
長い本文を固定して質問だけ増やす処理時間とメモリの増え方本文の計算を共有するか、質問ごとに繰り返すか
答えの手掛かりを隣の質問へ移す対象の質問がその情報を使うか質問同士を分離しているか
A・Bを固定して別の候補Cを追加するAとBの確率比が変わるか候補の独立採点か、候補一覧を参照した判断か
候補の順番を入れ替える選択と確率が変わるか入力順にどれだけ依存するか
未知の業務で正解付きの例を集める80%と予測した事例で約80%当たるかその用途でも確率が校正されているか

ただし、候補数に応じた確率の補正でもAとBの確率比は変わり得る。質問追加時の処理時間も、本文の再計算だけでなくサーバーの負荷やバッチ処理のまとめ方に左右されるため、これらの観測値には複数の要因が重なる。