AIに「先週の取引先ミーティングの予定をまとめて」と指示する。AIは使えるツールの一覧 — カレンダー照会、CRM照会、メール検索、ドキュメント生成 — の中から一つを選んで作業を始める。ところが、この四行をプロンプトにどの順番で並べたかによって、同じ依頼なのに昨日はカレンダーを、今日はメール検索を呼び出す。依頼もツールも同じだ。変わったのは行を並べた順番だけである。
ここで扱う対象は、長い説明を聞かせる類の仕事ではない。選択肢の中から一つを素早く選び、条件が真かどうかを判定し、点数をつける — 選択と判定が核心となる仕事だ。論文は、根拠を長々と展開せず結果だけを即座に出すこの種のモデルを「システム1モデル」と呼ぶ。人が直感で瞬時に判断する思考になぞらえた名前だ。そしてまさにその即答の瞬間に、冒頭の場面のように順番といった些細なものが答えを揺らす。シンガポール国立大学(NUS)の研究チームによるJevaは、その揺らぎを構造のレベルで取り除こうとする試みである。
近ごろ公開されているシステム1モデルは、たいていこう動く。依頼と候補(選択肢)を一つの文としてつなぎ合わせて言語モデルに入れ、モデルが各選択肢につけた点数や、専用の出力装置から答えを読み取る。ここでいう「点数」はロジット、つまり確率に変換する前の生スコアを指す。やり方は手軽だ。問題は、「決定」という仕事の性質とうまく噛み合わないところにある。
論文は、決定問題が暗黙に要求する四つの性質を一箇所に整理する。
四つの性質は、表面上はばらばらの要求に見えるが、根っこは一つだ。意味を表現する仕事、候補どうしを比べる仕事、答えが存在するかを判定する仕事が、すべて同じ予測プロセスの中に絡み合っている、ということ。Jevaの設計は、この三つを切り離すところから出発する。
まず一つの共有エンコーダが、依頼と各選択肢をそれぞれ別々にベクトルへ変換する。ベクトルとは、テキストの特徴を収めた数字の束だ。このとき選択肢をベクトル化する際には、今の質問も、進行状態も、ほかの選択肢も、選択肢の番号も入れない。だから一つの選択肢の表現は、依頼が何であろうと常に同じ値に固定される。まさにこの固定がキャッシュの前提になる。客が誰であろうとメニュー表は一度刷ったら使い続ける食堂を思い浮かべればよい。毎回刷り直す理由はない。
選択肢の表現を固定したのだから、選択肢ごとに別々に点数をつけて終わりにすればよさそうだ。だがそれでは選択肢どうしを比べる過程が消えてしまう。Jevaは軽量な「決定ブロック」を置き、固定された選択肢を読み流しながら「依頼側の状態」だけを少しずつ整えていく。依頼状態とは、候補を見ていきながら更新していく、依頼の内部表現である。
なぜこの整えが重要なのかは、二つの場面を比べると鮮明になる。ルーターが使えるツールがA(メール検索)とB(汎用ドキュメント生成)の二つだけで、「先日のミーティング議事録をまとめて」という依頼が来たとしよう。二つのうちではBのほうがよい。ここで二通りのことが起こりうる。一つ、AとBはそのままにしてプロンプトに書いた順番だけを入れ替える場合 — 判断は変わってはならない。二つ、C(議事録専用の要約ツール)を実際に新しく連携させる場合 — このときは話が違う。Cが入ってくると「この依頼を誰に任せるか」を見る基準そのものが「議事録を扱えるか」へと移り、その軸ではAとBの優劣さえ見直さなければならないかもしれない。候補集合の全体が変わったからだ。
選択肢を完全に独立して採点すると、二つ目が不可能になる。ほかの選択肢を入れても抜いても、二つの選択肢の相対的な優劣は決して変わらない。Jevaは依頼状態を「今の候補集合の全体」に合わせて調整するので、順番だけが変わったときは判断を保ち、集合が変わったときは優劣を見直す。
順序不変は集約の仕方で守る。決定ブロックが選択肢をまとめるとき、順序に影響されない対称集約を使うので、選択肢を入れ替えれば結果の確率も一緒に入れ替わるだけで、値そのものは変わらない。また、すべての選択肢を同じ採点方式で処理するので、選択肢の数が増えても出力側を大きくする必要がない。
「該当なし」は、はじめから別の装置として切り離す。選択肢どうしの相対的な優劣だけでは「では受け入れられる選択肢が一つでもあるのか」に答えられない。すべての点数に同じ値を足しても選択肢間の競争の構図はそのままだが、「正解があるかないか」は変わらなければならないからだ。Jevaは、学習で定めたしきい値と温度を使う「カバレッジゲート」で、まず「なし」と「候補集合」の間に確率を割り振り、そのうえで候補の内部で選択肢間の競争を解く。温度とは、確率分布をどれだけ尖らせるか、あるいは平らにするかを調節する値だ。こうして切り離した一つの構造が、選ぶ(Choice)、検証する(Noul)、点数をつける(Score)の三つの出力をすべて担う。
この問題を解く流れは大きく二つある。一つは、依頼と候補を一緒に文としてエンコードし、答えトークンや決定マーカーから読み取る系統。もう一つは、クエリと候補を別々にエンコードして、使い回しと効率を得る系統だ。Jevaの立ち位置はその中間にある。選択肢は別々にエンコードして使い回すが、採点の前に依頼状態を候補集合の全体に合わせて先に調整する。三つの軸で見ると違いが鮮明になる。
| アプローチ | 代表モデル | 候補の再利用 | 集合の相互作用 | 「なし」の分離 |
|---|---|---|---|---|
| 一緒にエンコード | SemIf・JevK5・InternDecision・Re・Flex・KEV・Laya | できない | できる | 限定的 |
| 別々にエンコード | DPR・ColBERT・CLM | できる | できない | 扱わない |
| Jeva | — | できる | できる | カバレッジゲートで分離 |
前者の系統が手放した再利用を、後者の系統が取りこぼした集合の相互作用を、Jevaがそれぞれ埋めるというわけだ。集合を順序なしで扱うニューラルネット系統(Deep Sets・Set Transformer・Perceiver)の対称集約のアイデアとも地続きである。「なし」の扱いは、回答可能性を問うSQuAD 2.0のようなタスクと問題意識が重なるが、Jevaは「なし」を「有効な候補の不在」と明確に定め、不確かさと切り離す点が異なる。
タイトルが掲げた約束から見よう。同じChoice 600件を原本・逆順・ランダムで回し、選択肢の同一性をそろえて整列したうえで順番だけを変えたとき、決定が揺れるかを測った。Jevaは一度も揺れなかった。順番を変えて生じた確率分布の差(TV距離、二つの分布の間の距離)が平均で約3.17e-08と、実質的に計算誤差だった。さらに注目すべきは二つの数字が一致している点だ。もとの正解率と、テストしたすべての順番で全部当てた割合がともに76.67%で同じである。順番が結果に何の情報も付け加えなかった、という意味だ。ただし正確に言えば、構造が数学的に保証するのは、正確な算術と固定された重みのもとで各選択肢の確率値そのものが順番に揺らがないということだ(だからTV距離は必ずしも0ではなく、浮動小数点誤差の水準にとどまる)。最終的な選択までそのままであるのは最高点の選択肢が唯一のときであり、点数が並んだとき先頭の選択肢を選ぶ実装や浮動小数点誤差では選択が分かれることがある(命題3・付録B.5)。この実験ではそうした逆転は一件もなかった。一方でほかのモデルは5件に1件の割合で決定が変わった。
| モデル | 逆転率 | 全順序正解率 |
|---|---|---|
| Jeva | 0.00% | 76.67% |
| Jev-1.13.0 | 17.00% | 66.67% |
| InternDecision-4B | 22.67% | 64.50% |
| JevK5 | 26.17% | 47.83% |
「なし」を見分ける能力も先頭だった。BANKING77で選択肢16個、正解がない588件を混ぜた3,080件で測ったところ、JevaのAUROC(高いほどよい)は98.66%で、KEV-BF16(93.61%)・InternDecision-4B(84.27%)・JevK5(79.44%)を大きく上回った。まともな選択肢を「なし」と誤って呼ぶ割合を5.02%に抑えたうえで、実際に不在の正解の93.88%を捉えた。間違ったツールを無理に呼ぶくらいなら「できない」と言うほうが大事な業務なら、この数字が核心になる。
拡張性は選択肢を増やしながら見た。ToolRet 500件でJevaは依頼をすべて処理し、集計正解率78.40%を出した。再帰的に選択肢を絞っていくJevK5は64.00%にとどまった。選択肢を32個から2,048個まで増やした83クエリでは、すべてのサイズで当て続けたクエリがJeva 58個に対しJevK5 48個で、CLMは7個だけだった。InternDecision系統は登録選択肢の上限に引っかかり、大きな束では一部の依頼しか処理できなかった。構造を組み直さなくても候補を増やせるという約束が、数字で裏づけられたわけだ。
再利用の速度は、候補の計算をキャッシュしたときに遅延がどれだけ減るかで測った(過去の答えはキャッシュしない)。MLDRではp50遅延が2,102.0msから75.1msへ下がり、候補を共有するTyped Decisionsでは93.1msから46.6msへ減り、候補エンコードの99.2%を省いた。それでも決定は変わらず、確率の最大差は0.00736だった。ただし、この遅延はすべてH200アクセラレータで出た値である。
正解率そのものは8スライス中7つで上回った。唯一負けたTyped Decisionsでわずかに押され、タイプ忠実度でもScore RMSEの一つだけが僅差で劣勢だ。詳細は下の補助表にまとめた。
| 項目 | Jeva | 比較 |
|---|---|---|
| BANKING77・MASSIVE(選択肢8・16個) | 90%以上 | — |
| Mind2Web cross-task / website / domain | 79.99% / 62.25% / 66.23% | — |
| Typed Decisions | 78.30% | InternDecision-4B 78.70% |
| Noul Brier / MAE(低いほどよい) | 0.0184 / 0.0939 | いずれも最低 |
| Score MAE / RMSE | 0.2315 / 0.3222 | RMSEのみInternDecision-4B 0.3208に劣勢 |
これらの数字は、それぞれ別の実験の別の指標なので、一つの成果としてまとめて読んではいけない。いずれも異なるデータと条件から出た値である。
著者が認める制約は、研究の範囲を測るうえで役立つ。各テキストは自分のエンコーダの長さ予算を別々に持つが、だからといって個々のテキストの長さの限界が消えるわけではない。集合に合わせて状態を調整する過程で点数が変わりうるため、選択肢を追加したときに(候補、なし)全体に対する最終的な選択がそのまま保たれるという保証はない(付録A.3)。再利用もタダではない。キャッシュされるのは候補側の計算だけで、状態のエンコードと決定の読み取りは依頼のたびにそのまま回る。だから選択肢の集合が毎回まったく新しく、再利用できるものがほとんどないサービスなら、キャッシュの利得は小さくなる。評価はQwen3.5-4Bバックボーンに決定ブロック一つで固定して報告したので、より大きい・小さいバックボーンで四つの性質と効率がどう変わるかは、この範囲では断言できない。Jevaの強みは、平均正解率で圧倒するところにあるというより、四つの性質をまとめて保証するところにあると読むほうが正確だ。
ONTLEは、AI PMが人の反復業務を軽くするサービスだ。冒頭の場面に戻ろう。ユーザーが「先週の取引先ミーティングの予定をまとめて」と言えば、PMは登録されたツール・連携の一覧から一つを選ばなければならない。この「どのツールがこの依頼を任されるか」こそがChoice決定である。
トークンの点数に頼るルーターは、ツール一覧を書いた順番が変わると同じ依頼に別のツールを選びうる。ただしこれは私たちが運用で測定した現象ではなく、そういう構造ならば現れうるリスクとして見るべきだ。Jeva式の分離は、このリスクを構造のレベルで防ぐ。順番が結果にそもそも入り込まないからだ。逆に、新しい連携を一つ付け足すのは順番の変更とは別の状況である。候補集合そのものが変わったのだから、選択が変わるのはむしろ正しく、Jevaはこのとき優劣を見直すよう設計されている。この二つのケースを混ぜないことが大切だ。
「なし」も、二つの判断を混ぜてはならない。一つは「この依頼を任せるツールがそもそもない」という判断だ。まだ連携していない外部システムのような場合である。もう一つは「そのツールを実際に実行してよいか」という承認の判断だ。カバレッジゲートが担うのは前者 — もっともらしいが間違ったツールを無理に呼ぶ代わりに「今はできない」と明示させる仕事である。実行の承認は、ONTLEの外部発信・実行前承認の原則が別に担う。
効果は、宣言ではなく数字で確かめる仮説として置くのが正しい。同じ依頼をツール一覧の順番だけ変えて(原本・逆順・ランダム)回し、逆転率と確率の差を測れば、順序感度が実際に問題なのか、Jeva式の分離がそれを取り除くのかがわかる。顧客ごとにほぼ固定のツール・文書一覧をキャッシュしたとき、決定はそのままで遅延が減るかも、同じやり方で測定する。連携を次々と付け足していく製品なら、選択肢が増えても出力構造を組み直す必要がないという点が特に値打ちを持つはずだが、これもまた実測で確かめるべき部分だ。
結局、Jevaを真っ先に検討するかどうかは二つで決まる。候補が依頼ごとに繰り返されて再利用できるものが多いか、そして「正解なし」を「迷い」と必ず区別しなければならないか。どちらも「そうだ」で、選択肢が増え続ける業務なら — ツールルーティングがまさにそれだ — 最初に俎上に載せるべき設計である。逆に、ラベルが固定で、選択肢ごとに安定した点数が必要な業務なら、順序不変や拡張性は大きな値打ちを出さない。
決定ブロックは、固定された選択肢を読み流しながら、依頼状態を残差方式で二度補正する。残差更新とは、値をまるごと新しく書き直す代わりに、既存の値に補正量を足していく方式だ。論文はこの設計が三つを数学的に保証することを命題として示す。決定ブロックが一つだけでも集合に応じて二つの選択肢の優劣が逆転しうること(Proposition 1 — 独立採点用のソフトマックスである式2は分母が約分されてこれが不可能になる)、カバレッジゲートの「なし」確率が「候補の個数で割る正規化」とは異なること(Proposition 2、式6 — 既存候補の最終点数が固定されている場合に限り、既存の最大値より低い選択肢を足しても「なし」確率が揺るがない。候補数を分母に使う平らなソフトマックスが、候補が増えるほど「なし」を薄めるのとは異なる。ただし実際のJevaでは候補を追加すると依頼状態と既存点数が一緒に変わるので「なし」確率も変わりうる — 付録A.3)、そして順序不変を構造が保証すること(Proposition 3)だ。ただしProposition 3が保証するのは、出力の確率分布が順序に不変だということであり、最終的な選択の不変は、正確な算術のもとで最高点の選択肢が唯一のときに従ってくる — 同点を先頭の選択肢で崩す実装や浮動小数点誤差では選択が変わりうる(付録B.5)。
学習はQwen3.5-4Bをバックボーンとし、決定ブロック一つとrank-64 LoRAで、二つの投影と決定ヘッド(1,337万パラメータ)だけを学習した。LoRAは、モデル全体ではなく小さな追加の重みだけを学習する軽量な方式だ。カリキュラムは、タイプ決定、意図選択、検証、読み取り・推論、大規模候補検索の順で進む。
オープン型(open-set)の評価で、そうしたモデルにも抜け道を用意しました。None選択肢を直接与えるか、「候補が存在するか」を問う補助質問で候補確率を補正させる方式です。モデル内部の比較はチェックポイントとクエリ順序を固定し、遅延はすべてH200で測定しました。
同じ構造を、解釈だけ変えています。Choiceは選択肢の中から一つを選び、Noulは真/偽を検証しますが、肯定側の選択肢の確率で答えます。Scoreは数値基準表(ルーブリック)に対する期待値として点数を出します。どの基準で読むかが違うだけで、エンコーダに入る入力が出力ごとに別々に増えることはありません。
いいえ。サービングのときはLoRAをマージして固定し、そのモデルで選択肢メモリを事前に計算しておきます。キャッシュが狙うのはこの事前計算した候補側であり、以前に出した答えはキャッシュしません。