問い合わせをAIで振り分けるとき、「確率が高いものだけ自動処理し、迷ったものを人へ戻す」と設計したくなります。ただし、AIが一つの答えを強く選ぶことと、人も判断に迷わないことは同じでしょうか。今回扱うは、その違いを確かめるための公開です。
2026年10月5日朝、Hacker NewsにDoubtBenchが紹介されました。編集部はその朝に取得した固定版を使い、と3種、2つの参照条件の公開回答を再採点しました。各7,455問の集計は、公開された値と一致しました。新しくモデルを呼び出した試験ではなく、作者が公開した回答記録の再計算です。HNの紹介投稿・検証した固定版
この記事ではランキングよりも、自動化の入口で何を記録すべきかを見ます。「同じ答えを選んだが、確率の付け方は違う」という架空の小さな例と、社内で使える空の評価表も用意しました。日本語の問い合わせをDoubtBenchで試した結果ではありません。
答えの一致と、人の判断の割れ方を別に見る
例えば、ある申請を進めてよいかを5人に独立して尋ね、3人が「進める」、2人が「確認する」と答えたとします。これは説明用の架空の票です。AIが「進める」を選べば多数派には合っていますが、「進める97%・確認する3%」という分布は、3対2の割れ方とはかなり違います。
DoubtBenchは、NVIDIAのに収められた複数人の評定を利用します。一つの集約ラベルとの一致に加え、各人がどの値へ投票したかの割合も残しています。評定を一つの正解へまとめた段階で消えてしまう情報を、別の物差しで確認できる構成です。データの由来と変換内容
ここで、人の投票は現実の正しさそのものではありません。例えば全員が古い社内規定を読んでいたら、一致した判断も誤り得ます。一方、申請文に必要な情報がなく、担当者の判断が割れる場合もあります。「人の票に近い」「規定に照らして正しい」「情報が足りない」は別々に記録する必要があります。
公式の集約ラベルも、必ずしも最多票の値とは限りません。HelpSteer2では評定の平均などからラベルを作るため、誰も選ばなかった中間値がラベルになる場合があります。そのため人の投票分布をそのまま再生する参照条件でも、集約ラベルとの一致率は100%にはなりません。集約ラベルと投票分布の説明
7,455問は、四つの仕事を組み合わせたもの
検証したコードは0.1.0、評価設計の版は1.0です。固定コミットの記録時刻は10月5日05:56:54(日本時間)でした。これは今回調べた版の時刻であり、プロジェクトの世界初公開日時とは断定しません。記事の条件は2026年10月5日時点です。固定コミット
評価対象には、回答の役立ち方や正しさなどを段階で評価する問題、受け入れられる回答かを二択で決める問題、二つの回答を比べる問題が混ざっています。会社の部署分類だけを7,455件試したものではありません。次の件数は、同梱データを読み直して確認しました。質問形式の定義
| 評価する内容 | 問数 | 読むときの注意 |
|---|---|---|
| 回答の5属性を0〜4で評価 | 5,110 | 全体の約69%を占める |
| 回答を受け入れられるか | 1,022 | 役立ち度が一定以上かを判定 |
| 二つの回答の優劣・同程度 | 882 | 提示順を入れ替えた問題も含む |
| どちらがどの程度よいか | 441 | −3〜3の段階を評価 |
同じ回答から複数の質問を作り、比較問題には順序を入れ替えた対もあります。7,455問を「互いに無関係な7,455社の仕事」と捉えることはできません。集計は問題数の多い種類の影響を強く受けるので、総合値が自分の用途を代表するかを先に考えます。
追加APIなしで再採点し、公開値と照合した
編集部はソースと生の回答を一時フォルダへ取得し、元データのハッシュを公式の記録と照合しました。回答ファイルを別フォルダへコピーし、公式の validate と score を実行。macOS 27.0、 3.12.10の環境で、再採点中はOS側で通信を拒否しました。元の質問データや回答は変更していません。同じ問題IDの追記がある場合は、公式実装どおり最後の記録を採用しています。
6条件について、再生成された集計を公開版と比較し、値の差分はありませんでした。下表はその抜粋です。割合は公式集約ラベルとの一致率、人の迷いとの相関は「人の票が割れる問題で、モデルの分布も散らばるか」を表します。公開回答と集計・再採点処理
| 公開回答の条件 | 集約ラベルとの一致率 | 人の迷いとの相関 |
|---|---|---|
| Jev 1.13.0 | 48.24% | 0.140 |
| Claude Haiku 4.5 | 45.85% | 0.154 |
| Claude Sonnet 5.5 | 42.52% | 0.120 |
| Claude Opus 5.5 | 44.00% | 0.063 |
| 人の投票分布を再生 | 82.58% | 1.000 |
| 全候補へ均等に割り当て | 18.38% | 算出できない |
この結果から言えるのは、今回の公開記録では、人の判断の割れ方とモデルの不確かさの連動が弱かったということです。相関はモデルと人のを問題ごとに比べています。人が迷った全例を見逃した、という意味でも、日本語の社内判断で同じ結果になる、という意味でもありません。均等分布は変化しないため、この相関を計算できません。相関の対象と計算
再計算が一致しても、元のAPI呼出や収集手順を編集部が立ち会って確認したことにはなりません。今回の確認範囲は、公開されている入力・回答・採点コードの整合です。原記録に入った処理時間も作者側の観測であり、編集部が測ったJevの速度としては扱いません。
最大確率0.9でも、一致率90%の保証にはならない
DoubtBenchの採点で使う confidence は、候補のの最大値です。Jev が返す同名の confidence フィールドを、そのまま使っているわけではありません。製品ごとの値の意味は判断モデルの比較記事でも整理しています。採点内のconfidence定義
編集部は公式採点とは別の短いプログラムでも、Jevの回答から最大確率と一致件数を数え直しました。全7,455問では3,596問が集約ラベルに一致しています。最大確率に条件を付けて残すと、次のようになります。
| 残す条件 | 残る件数/全7,455問 | 全体に占める割合 | 残した中の一致件数 | 残した中の一致率 |
|---|---|---|---|---|
| 最大確率0.7以上 | 2,842 | 38.12% | 1,896 | 66.71% |
| 最大確率0.8以上 | 1,716 | 23.02% | 1,265 | 73.72% |
| 最大確率0.9以上 | 791 | 10.61% | 622 | 78.63% |
0.9以上に絞っても、791問のうち169問は集約ラベルと一致しませんでした。一方、残せる量は全体の約1割です。閾値を上げると、残した部分の一致率だけでなく、どれだけ人へ戻すかも変わります。数字を一つだけ出すと、運用の負担を見落とします。公式の絞り込み集計
これは閾値0.9を推奨する試験ではありません。公式が用意した0.7・0.8・0.9で、公開回答を数えたものです。自社で閾値を選ぶなら、調整に使う例と、最後に確認する別の例を分け、金額や送信先の誤りなど重要な失敗を別に数えます。
また、確率0.9という値と「その値の回答群が実際に9割正しい」という性質は別です。DoubtBenchは、そのずれを集計するも出します。一問の確率だけでは、この対応関係を確認できません。確率と一致割合を比較する実装
架空の3対2で、同じ答えでも分布が違うと確かめる
教材ZIPには、編集部作成の2択の数値例を入れました。EX01では、人の票を「進める3・確認する2」と置き、予測Aを97対3、予測Bを60対40にしています。どちらも「進める」を選びますが、人の票の割合と一致するのはBです。これらは説明用の設定値であり、JevやClaudeの実測出力ではありません。
分布の違いを測るは、この例ではAが0.168261、Bが0でした。0は分布が一致することを表します。ただし別のEX02で人の票を5対0に変えると、Aは0.015165、Bは0.236453になり、近いのはAです。弱気な予測なら常によいわけではないことも、同じ例で確かめられます。
ZIPを展開し、Pythonが使える端末で次のコマンドを実行します。標準ライブラリだけで計算でき、、追加モデル、通信は不要です。表示結果を expected-output.txt と照合してください。
python3 compare_distributions.pypython3 -B -m unittest test_compare_distributions.py -v同梱の8テストでは、分布が同じとき、完全に離れたとき、合計が1でない入力などを確認しました。この小さなコードは、公式ベンチマーク全体を置き換えるものではありません。仕組みの理解用であり、入力した投票が妥当かどうかを判定する機能もありません。
公開結果の再採点も試す場合は、教材READMEにある固定版の取得・準備手順を先に実行します。そこではソースやPython依存の取得に通信します。準備後の再採点は、コピー先へ集計ファイルを出力する次の操作です。回答を取り直す run は使いません。
# READMEの準備を終え、固定版ソースのフォルダ内で実行.venv/bin/doubtbench validatemkdir local-rescorecp -R results/jev-1.13.0 local-rescore/.venv/bin/doubtbench score local-rescore/jev-1.13.0このコマンド例はmacOS/Linux系シェル向けです。Windowsでの手順は今回検証していません。教材には集計値、固定版、元データのハッシュ、実行環境も収めました。公式の質問・回答本文は再配布せず、必要な人が元の公開元から取得する構成です。
自社で試すときは、曖昧な入力だけでなく曖昧な規定も残す
例えば経費申請の一次確認なら、「領収書がない」という文だけで提出先を決めず、例外規定や追加確認の条件を先にそろえます。複数人が判断する場合は、相談する前の個別の票を残します。合議後の一つの答えだけ保存すると、最初に判断が割れていたことが分からなくなるためです。
教材の evaluation-sheet.md は、そのための空欄表です。入力、各人の判断、規定に照らした確定ラベル、モデルの全候補の確率、API独自のconfidence、最終確認者を分けて記録できます。正解を確定できない例は無理に不正解へ押し込まず、規定不足や情報不足として残します。
最初から自動承認へつなげる必要はありません。担当候補を出し、人が直せる段階で記録を集めれば、モデルの誤りと運用ルールの不足を分けやすくなります。用途を絞って自分の正解例から分類器を作る方法は、Jeffyの問い合わせ分類検証でも扱っています。
価格や総合点だけで、モデルの優劣を決めない
今回の比較では、Jevが返した確率分布と、Claudeに文章の一部として出力させた確率を比較しています。確率を得る仕組みが同じではありません。Sonnet 5.5とOpus 5.5は低い推論強度で実行され、それぞれ30問・36問の拒否が誤りとして集計されています。条件を変えた再試験はしていません。実行条件の説明・Claude側の処理
費用も請求書の実額ではありません。Jevの記録では入力2,373,086相当と、実行設定の100万入力トークンあたり0.042ドルを使い、約0.10ドルと算出しています。これはその記録に対する推計で、読者の仕事が同額になる意味ではありません。Claude側は出力分を含む記録済み費用を使うため、入力料金だけを掛けて比較し直すと条件が変わります。また、最後の回答を採用した集計は、再試行を含む全呼出の請求合計を復元したものではありません。Jevの実行設定・費用の集計方法
公式コードの利用条件は、元のHelpSteer2と派生データはです。再利用時にはNVIDIAとDoubtBenchへの帰属、改変内容を示す必要があります。教材READMEにも出典と、編集部は公開結果を再採点したことを記しました。今回得られたのは「任せてよい数値」ではなく、答えの一致、確率の意味、人の判断の割れ方を分けて検収する手順です。公式のライセンスと帰属