DecisionPivot：LLMの判断の一貫性と確信度を診断するベンチマーク

LLMシステムには、回答を生成する前後に判断を挟む場面がある。質問に答えられるかを見て振り分ける、ポリシーに照らして許可するかを決める、出力やツール呼び出しが条件を満たすかを確認する、といった役割だ。本論文は、こうした選択を担うモデルを「判断モデル」として評価する。

評価時の基本形は、状態、質問、有限の選択肢をモデルに渡し、各選択肢の確率を得ることだ。最も確率が高い選択肢を最終判断とする。対象には、回答可能性・ルーティング、ポリシー判定、出力検証、ツール検証・目標達成確認、推論分類、記録整合性、制約検索・照合の七つの役割がある。自由な文章の出来栄えより、条件に応じた選択の正しさが焦点になる。

従来の公開課題を使う評価は、モデル間の比較に役立つ。ただし、項目ごとの正解率をまとめるだけでは、関連する条件を変えたときにも正しく判断できるかは分からない。表面的な手掛かりや、訓練データとの重複が成績の解釈を難しくする問題もある。

本論文のfilter_matchという問題群を、業務上の照合に近い例として考えよう。送料だけを変え、総額が上限の1セント下にある事例と、1セント上にある事例を作る。必要なのは、送料の違いを読み取り、上限との関係に従って両方を正しく判定することだ。二つを別々に集計すると、この対応関係が評価から抜け落ちる。

DecisionPivotは、関連する問題を「対照グループ」にまとめて採点する。ただし、すべてが一つの条件だけを変える構造ではない。policy_caseは、共通ポリシーの下で異なる事例をまとめる。送料の例は主要な設計思想を表すが、全問題の作りを代表するものではない。

対照問題があるだけでも十分ではない。論文は、確率の順位、最終判断、確信度の信頼性を分ける。送料の例で、条件を満たす事例のyes確率が、満たさない事例より高ければ、確率順序は正しい。しかし二値判断で両方を正解するには、前者が0.5を上回り、後者が0.5を下回る必要がある。同点を除けば、順位だけではこの境界をまたぐことを保証しない。

さらに、選んだ答えにどれだけ自信があるかも別問題だ。本論文では、最大の選択肢確率を確信度とする。その値と実際の正解率との対応を調べるのが較正である。平均正解率が近くても、高い確信度で誤る頻度まで近いとは限らない。この三つの区別が、結果を読むための土台になる。

DecisionPivotは、合計48タスク・40,033問を二つのトラックに分ける。生成コアは、共通の生成規則を持つ13の問題群からなり、各600問、計7,800問を収める。各問題群には三段階の難度を設け、それぞれ200問ずつ配置した。構造化した事例から正解を計算し、架空の実体と異なる表現を使って文章にする。

著者らによれば、生成器を読んでいない別の著者が解法器を実装し、各問題群の600問すべてで正解が一致した。全7,800問を少なくとも二人の人間が個別に確認し、AI補助の審査や、選択肢・文章の特徴だけで解けないかの監査も行った。これは研究チーム内での正解確認であり、第三者による再現ではない。

もう一方の参照トラックは、35の公開タスクからなる32,233問だ。元の評価指標を保持し、人手、計算、両者を組み合わせたラベルを使う。生成コアで条件変更への対応を診断し、公開参照で既存課題上の成績も見るという補完関係にある。両者は同じ問題を異なる方法で採点した比較ではない。

中心指標のPairAccは、対照グループの全問を正解した場合だけ成功とする割合だ。名称にpairとあるが、二問より大きいグループも含む。送料の例なら、上限の上下で回答を変えるだけでなく、それぞれ正しい側に判断する必要がある。個別正解率と併記することで、一問ずつは解けても関連条件を通しては解けない状態を探る。

コアの主要値は、13の問題群を等しく扱って平均する。これをマクロ平均という。参照トラックでは、異なる指標を偶然に答えた場合の水準を基準に調整し、負の値をゼロに丸める。その後、役割内で平均し、七つの役割を平均する。したがって、参照集計スコアをそのまま正答率とは読めない。

著者らは、項目やグループを再抽出するブートストラップという方法で95%区間を求め、モデル同士の差には対応する再標本を使った。こうした集計方法の違いを踏まえ、同じ指標・同じ評価集合の中で比較することが重要になる。

確信度の評価には複数の見方を使う。まず、確信度0.90以上の回答がどれだけあり、その中でどれだけ正解したかを測る。次に、確信度を15の等幅区間に分け、確信度と正解率のずれを較正誤差として調べる。高確信度の回答の正解率と、その対象比率はセットで読む必要がある。

選択的カバレッジでは、問題群ごとに確信度の高い順に並べ、同点をまとめて扱う。その先頭からどこまでを選べば誤り率が5%以下になるかを調べ、条件を満たす最大の比率を報告する。これは、確信度を使って判断を選別できる余地を見る指標だ。

ただし、この計算は評価対象の正解ラベルを見て行い、問題群ごとに異なる境界を許す。将来の入力に対する自動処理率や誤り率の保証ではない。運用に結び付けるには、独立したデータによる較正が必要になる。また、15区間の較正誤差には不確実性の区間が報告されていない。

評価対象は判断モデル40種と汎用モデル14種だ。判断モデルと公開汎用モデル11種を両トラックで、API経由の汎用モデル3種をコアで評価した。モデルごとの公式方式を使い、公開汎用モデルでは一回の処理で選択肢キーの確率を読み、APIモデルでは自己申告の確率を使う。欠損や失敗は誤答とし、確信度の採点では各選択肢が等確率の分布を与える。

この設計は各モデルの利用方式を尊重する一方、入力上限、確率の取得法、推論設定がそろうわけではない。とりわけ自己申告確率を、他の方式で得た確率と直接比較することには制約がある。多くの評価は単一実行でもある。

推論設定の比較には、難度を均等にし、完全な対照グループを残した別の1,296問を使った。ただしGLM-5.3の高低設定では、サンプリングと出力上限も変わる。最低設定でも隠れた推論を行うため、推論の有無だけを比べた実験ではない。

以下はすべて著者らの報告結果である。Perplexity Decider v1.1 27BとJEV-27Bは、参照35タスクの集計スコアが57.0と54.4で、差は2.6ポイントだった。一方、コア7,800問のPairAccは70.1%と44.2%で、差は25.9ポイントに広がった。

公開課題で近い成績でも、対照グループを通して正解する力は大きく違い得る。ただし、両トラックは問題内容も採点方法も異なる。この差を、グループ採点を導入した効果だけに帰すことはできない。

八つの二値問題群の2,400ペアでは、Perplexity Deciderの確率順序が正しい割合は92.3%だったが、両問正解率は74.1%だった。同じ評価ペア上で最良の単一判断閾値を選んでも74.2%にとどまる。Clef 27Bでも、順に78.6%、25.0%、30.6%だった。順位が合うことと判断が合うことの隔たりは、単一の境界調整だけでは埋まらなかった。この閾値調整は評価データを使った楽観的な診断で、未知データでの較正性能ではない。

コアの個別正解率は、Kev 27Bが70.6%、JEV-27Bが70.3%と近かった。しかし、確信度0.90以上の回答に限ると、Kevの正解率は93.8%、JEVは88.9%だった。該当する回答の比率は、それぞれ34.1%と47.4%である。JEVの方が高確信度の回答を多く出す一方、その範囲の正確さは低かった。

ここでは集計方法にも注意が要る。個別正解率は問題群ごとのマクロ平均、高確信度の正解率と対象比率は全項目をまとめた値だ。同じ重み付けの指標ではないが、平均的な正しさだけでは、確信度による選別の性質が分からないことを示す比較になる。

別標本の1,296問では、GLM-5.3の高推論設定のPairAccは93.5%、95%区間は91.7～95.3%だった。最低設定は81.5%、区間は78.4～84.6%で、差は12.0ポイントである。平均推論トークン数は265対121だった。改善は観測されたが、サンプリングと出力上限も変わっており、推論量だけの因果効果とは言えない。

確信度が0.9未満の場合に推論するSL-27B AutoThinkも、コアでは86.9%と、Instantの75.4%を上回った。一方、参照集計スコアは58.9対59.4で上回らず、個別の問題群でも劣る例があった。条件を制御した問題での改善が、公開課題全体の改善と一致するわけではない。推論トークン数から速度や費用の優劣を判断するための測定値も、本記録にはない。

入力のわずかな変更も、平均値だけでは見えにくい。旧コアv1.0の12問題群でKev 27Bの選択肢順序を変えると、予測の4.9%が変化したが、個別正解率の低下は0.5ポイントだった。正答から誤答への変化が2.0%、逆が1.5%あり、互いに打ち消していた。ただし、この実験は改訂後のv1.1の頑健性を確立するものではない。

別の検査では、判断モデル34種を七つの既存生成器による新規4,200問で評価した。順位の一致度を測るSpearman相関は0.994で、561モデル対のうち550対が順序を保った。標本を作り直しても順位が概ね安定する証拠だが、同じ生成器の設計内での確認に限られる。独立に設計された問題にも同じ順位が通用するかは残る。

正解の検算と人手確認を重ねても、近道をすべて排除できたわけではない。ツール呼び出しの妥当性を問うtoolcall_validでは、形式上のスキーマだけを見る部分情報の方法でも、個別正解率91.7%を得た。参照ラベルにも、量が分かっていない残存誤りがある。他モデルの訓練時の項目露出も十分には確認できていない。

また、難度を上げる際には事例のサイズと推論の複雑さを同時に増やすため、長い文脈の影響と推論負荷を切り分けられない。実トラフィック、システム全体の運用、多言語性能、推論効率、標準化した費用は評価範囲外である。

DecisionPivotとStartLux-Decisionは同じチームが開発した。次に見るべき証拠は、第三者による独立評価、別設計の問題、自分の運用分布での再評価だ。現時点では、ルーティングや検証の候補モデルについて、平均点に隠れる失敗を調べる補完的な診断として位置付けるのが妥当だ。