Benchmark Radar：AIベンチマークの出典・採用履歴・スコア推移を追跡する検索基盤

モデルやエージェントの評価を企画する担当者は、目的に合うベンチマークを探すだけでなく、元の論文、課題データ、コード、過去の採用例、報告スコアの条件まで確認する必要がある。ところが、これらは論文サイト、リポジトリ、データセット置き場、モデルカード、技術報告などに分散している。

たとえば、ある企業が顧客対応エージェントの評価を見直す場面を考える。検索で関連しそうな試験を見つけても、その名前だけでは、必要な能力を測るのか、どの課題版を使ったのか、ツール利用を許したのかは分からない。モデルカードに高い数値が載っていても、その数値が別の報告と同条件とは限らない。本稿ではこの場面を通して仕組みを説明するが、これは理解のための仮想例であり、論文が顧客対応業務で効果を測ったわけではない。

既存のサービスは、ランキング、評価実行の基盤、モデル分析を提供してきた。しかし著者らによれば、新しいベンチマークから、その課題素材、後続モデルでの採用、個々のスコアの評価条件まで一続きに確認するには、なお複数の情報源を横断する必要があった。

ここで難しいのは、情報を一か所へ集めれば解決するとは限らないことだ。同じベンチマークが複数のカタログに載れば、単純な統合は出典の違いを隠す。欠損項目のある記録を捨てれば、数値はなくても有用な論文やデータセットへの入口まで失う。反対に、集めた数字をそのまま並べれば、尺度や評価条件の異なる結果を同列に扱ってしまう。

この研究を読む鍵は、「同じ名前らしい」「同じ尺度らしい」「同じ条件で比較できる」を分けることにある。関連記録が同じベンチマークを指すと確認できても、各情報源の記録や観測は別々に残す。同じ0〜100の百分率でも、テスト版、プロンプト、利用可能なツール、試行回数、評価者が異なれば、直接比較できるとは限らない。

したがってBenchmark Radarは、最良のベンチマークを自動決定する仕組みではない。候補を検索し、その候補について原典へ戻れる証拠の経路を提示し、最後の適合性判断を人に残す。顧客対応エージェントの例なら、候補一覧を答えとせず、各候補が何を測り、どの条件で使われたかを調べるための台帳として扱う。

Benchmark Radarは、13の直接コネクタと24の一次研究・技術フィード、計37ソースを使って資料を日次発見する。各収集実行では48時間の範囲を調べ、未来日付の行を除き、取得件数とエラーを記録する。arXiv、Hugging Face Hub、GitHub Searchという中核ソースが正常な場合だけ結果を公開する。

カタログでは、寄与元ごとの一項目をソース記録として保存する。名称、識別子、成果物へのリンク、スコア観測、モデルID、引用文書を共通項目へ整理するが、スコアや日付、引用が欠けていても記録を削除しない。同じ実体だとレビュー済みの記録には関連リンクを付けるものの、件数と観測値は混ぜない。これは重複を消し切る設計ではなく、重複らしさと元の出典を同時に見せる設計である。

検索にはBM25Fを使う。入力語が名称や説明などのどの項目に現れるかを重み付きで評価し、名称やまとまったフレーズの一致には上限付きの加点を行う。結果には、一致した語、見つからなかった語、該当した項目、順位を構成する要素を示す。特定の情報源に属するという理由だけで順位は上がらない。

顧客対応エージェントの担当者なら、まず能力を表す語で候補を絞り、次に論文、リポジトリ、データセット、モデル報告をたどる。論文中の実例も同じ思想で、エージェント学習のcredit assignmentに関する候補をローカル検索し、成果物を確認し、別表現をWeb検索で補い、原典を読んで設計次元ごとの先行研究表を作った。検索は候補抽出であり、最終判断そのものではない。

Web、CLI、HTTP、エクスポートは同じベンチマークIDと応答形式を共有する。保存したアーカイブについては、SHA-256、スキーマ版、来歴をマニフェストで検証し、ネットワークなしでも記録済みのデータ版に対する検索を再実行できる。継続更新される「生きた」カタログでありながら、過去の判断に使った版を固定して再確認できるという組み合わせである。

ただし、固定版が保証するのは、同じ記録集合を参照できることまでだ。候補が業務に適していることや、元の評価が公平であることまで保証するわけではない。

著者らはv0.11.0の再構築済みカタログにある1,283ソース記録を、日付、スコア、画面上のフィルターで絞らず全件監査した。数値観測は観測IDごとに一度だけ数え、モデルと引用文書も各記録内のソースIDで重複排除した。

スコアを百分率として要約する際は、百分率単位が明示されていること、数字の増減のどちらが良いか分かること、値が0〜100に収まることを最低条件とした。この検査は尺度上の入口にすぎず、テスト版やプロンプトなどの評価条件まではそろえない。

この評価は、カタログに何が記録され、どの程度欠損し、どれだけのスコアが最低限同じ尺度として扱えるかを記述する監査である。検索結果の正確さ、関連候補を拾う割合、業務への適合性、担当者の調査時間を、別の手法と比較する試験ではない。検索方式や名称・フレーズ加点を一つずつ外すアブレーションも報告されていない。

著者らの報告では、1,283ソース記録のうち790記録に計12,916件の有限な数値観測があり、493記録には数値スコアがなかった。ところが、790記録のうち、百分率単位、既知の方向、0〜100の値という最低条件を満たしたのは82記録だけだった。残る708記録は別の尺度か、尺度を検証できない記録である。

この結果は、12,916件の数字を共通ランキングへ投入できることを意味しない。82記録も、あくまで同じ百分率尺度として要約する入口を通っただけである。その内部でテスト版、プロンプト、ツール、試行回数、評価者が一致するかは別途確認しなければならない。また、1,283という数は情報源別のソース記録数であり、重複のない実体ベンチマーク数ではない。

数値のない493記録のうち464記録には、論文、リポジトリ、データセットの少なくとも一つへのリンクが残っていた。したがって、未採点の記録を検索対象から除くと、評価設計や課題内容を調べる入口を失う可能性がある。

顧客対応エージェントの例でも、まだモデルスコアが登録されていない候補が、目的に合う課題や設計を含む可能性はある。ここから導けるのは、数値の有無と資料の有無を分けて表示することの合理性までだ。その候補が本当に業務に適する割合は測られていない。

日付にも同様の注意が要る。ベンチマーク公開日は1,283記録中615記録で既知、668記録で不明だった。12,594件の観測にはモデル発表日、322件には文書公開日が付いているが、どちらも実際に評価した日を直接示さない。これらを評価日とみなして、スコアの停滞や飽和を論じることはできない。

BM25Fは語彙の一致を使うため、同じ概念を別の言葉で表した研究や、改名された課題を見逃し得る。論文の先行研究探索例でもWeb検索を併用し、それでも共著者が指摘するまで2件の研究を見逃した。意味検索が改善策になる可能性はあるが、それを判断するには、既知と未知のベンチマークを含むクエリごとの正解判定が必要であり、本研究には用意されていない。

収集範囲にも限界がある。取得上限、失敗した要求、識別子の欠損、異なるスナップショット日が網羅性へ影響する。arXivの経路は新規投稿を収集するが、収集窓より前に初版が出た論文の後続版を遡って集めない。日次発見コーパスは46スナップショットに11,068観測と6,546成果物を含むものの、4スナップショットはシミュレーションによる過去の補完である。この発見観測はソース記録とは別単位であり、1,283件へ加算できない。

この仕組みが合うのは、新しい評価を設計する前の先行研究調査、スコアの尺度・方向・引用・日付根拠の確認、固定データ版による検索の再確認である。数値のない候補も成果物への経路を残したい場合にも意味がある。

一方、言い換えを高い再現率で拾う必要がある探索、検索性能の保証が必要な意思決定、条件の異なるスコアを追加確認なしで統合する用途には向かない。能力分類は1,283記録中1,279記録に付いたが、その分類自体は未検証である。検索や監査の処理時間、対話レイテンシについても比較可能な結果は報告されていない。

次に必要な証拠は、専門家が関連性を判定した同一の質問集合を使い、語彙検索と別の検索法を比較する評価である。加えて、利用者が選んだベンチマークの妥当性、見逃し、調査時間を管理条件下で比べる必要がある。そこまで確認されて初めて、証拠をたどれる設計が実務上の判断を改善するかを評価できる。