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

AIの試験は、論文、プログラム、データ、モデルの説明書などに散らばっています。そのため、目的に合う試験を見つけ、点数が出た条件まで続けて確認するのが難しい、という問題を扱います。

Benchmark Radarは、試験の候補、元の資料、使われた履歴、点数を共通の番号で結びます。たとえば模試の点を見る前に、問題の版、採点方法、受験条件をたどれる索引を作るイメージです。ただし、この仕組み自身が点数を比べられる状態にするわけではありません。

著者らが保存版の全記録を調べたところ、1,283件のソース記録のうち790件に計12,916個の数値がありました。しかし、百分率として最低限まとめられる条件を満たしたのは82件だけでした。しかも、その82件でも問題の版や使える道具などが同じとは限りません。

検索の正確さ、目的への合い方、調査時間が短くなるかは試されていません。言葉が違うだけの関連試験を見逃すこともあり、候補を見つけた後は人が元の資料を読む必要があります。

比べられる最低条件を満たす記録が82件に限られたという報告を見ると、順位を作る前に条件を点検する習慣が大切かもしれません。ただし、その手順で判断が良くなるか、作業が速くなるかはまだ分かりません。

AIの試験を選ぶ人は、候補だけでなく、元の論文、使うデータ、プログラム、過去にどのモデルが使ったか、どんな条件で点数が出たかを知る必要があります。ところが、それらは別々の場所にあります。論文は、この分断をどう減らし、後から根拠をたどれるようにするかを問います。

既存のサービスは順位表、試験を動かす仕組み、モデル分析を提供してきました。しかし、新しい試験から元の材料、後の採用例、採点条件まで追うには、複数の情報源を行き来する必要があると著者らは説明します。

中心となる考えは、候補を探す段階と、本当に目的に合うかを人が決める段階を分け、その間に確認できる証拠の道筋を置くことです。料理の一覧から献立を選ぶ場面なら、料理名だけでなく、元のレシピ、材料、作った条件、結果を一緒にたどれる索引に近いです。ただし、材料欄が似ていても同じ料理とは限らないように、尺度が同じだけで点数を直接比べることはできません。

仕組みは37の情報源を毎日調べます。各回は直近48時間を探し、未来の日付を除き、件数と失敗を記録します。カタログでは欠けた項目があっても記録を捨てません。同じ試験だと確認された記録も、出どころ別の点数や件数を保ちます。検索結果には、どの言葉が合い、どの言葉が見つからず、どの欄が一致したかを示します。保存したデータ版は、内容が変わっていないかを確認して、ネットにつながず検索し直せます。

著者らは保存版の1,283ソース記録を、日付や点数で絞らずに全件調べました。同じ観測を重ねて数えないよう、各項目の番号で整理しました。また、百分率としてまとめるには、百分率だと明記され、数字が大きいほど良いか悪いかが分かり、値が0から100に収まることを最低条件にしました。

著者らの報告では、790記録に12,916個の数値があり、493記録には数値がありませんでした。数値のない493記録でも464記録には論文、プログラム置き場、データの少なくとも一つがありました。790記録のうち百分率の最低条件を満たしたのは82記録で、708記録は別の尺度か、尺度を確かめられないものでした。

この仕組みは、新しい試験を設計する前の候補探し、点数の出典確認、保存版を使った検索のやり直しに向きます。数値がない候補も、元資料への道筋があれば残せます。一方、言い換えを漏れなく拾う必要がある探索や、異なる条件の点数をすぐ一つの順位へまとめる用途には向きません。

検索の正確さ、候補が仕事に合う割合、調査時間の短縮は測られていません。語句検索は言い換えや名前変更を見逃し得ます。論文の実例でも通常検索を補い、共著者が指摘するまで二つの研究を見逃しました。また、1,283件は情報提供元別の記録数であり、重複のない試験数ではありません。

数値があっても、百分率として最低限まとめられたのは790記録中82記録でした。この結果から、先に順位を作るより、単位、問題の版、使える道具、日付の根拠を一件ずつ確認する流れが考えられます。料理名だけで献立を決めず、材料と手順を確かめるのと似ています。ただし、この流れが判断を良くするか、時間を減らすかは比べる実験が行われていません。

問題は、試験名を見つけるだけでは選定に足りないことです。元の論文やデータ、プログラム、モデルによる利用例、点数の条件が別々に置かれています。論文は、記録を一か所へ集めれば自動で正解が出るとは考えません。候補探しを助けた後、目的に合うか、点数を比べてよいかは人が元資料を読んで判断する、という前提です。

従来のサービスは順位表、試験を動かす仕組み、モデルの分析を提供してきました。しかし著者らによると、新しい試験、課題の材料、後の採用例、採点条件を続けて確認するには複数の場所を回る必要がありました。Benchmark Radarは順位表だけでなく、その裏の証拠をたどる台帳として設計されています。

全体の流れは、資料を毎日集める、出どころ別に保存する、共通の項目へ整理する、検索する、元資料を人が確認する、という順です。料理を探す例なら、料理名、元レシピ、材料、作った人の記録、結果を結びます。ただし、似た名前の料理を同じものと決めたり、同じ百点満点だから味を直接比べたりはしません。この境界が、単なる順位表との違いです。

収集先は13の直接接続先と24の研究・技術情報の配信元で、計37ソースです。検索は入力語が名前や説明などのどこに現れるかを見て順位を付け、名前やまとまった言い回しの一致を一定範囲で強めます。どの語が一致したか、欠けたか、順位がどう作られたかも表示します。情報提供元の種類そのものは順位を上げません。確認済みの同一性リンクは記録同士をつなぎますが、数値と件数を合体させません。

各収集は48時間分を探し、未来日付を除き、件数と失敗を記録します。中心となる三つの情報源が正常な場合だけ公開します。監査はv0.11.0の1,283記録を、画面上の絞り込みなしで読みました。発見用の別データには46個の保存時点、11,068観測、6,546成果物があり、四つの保存時点は過去を補う再現でした。この数はカタログの1,283件へ足しません。

監査では観測、モデル、文書に付いた番号を使い、同じものを二度数えないようにしました。百分率の要約を許す最低条件は、百分率と明記されていること、数字の良し悪しの向きが分かること、0から100の範囲であることです。ただし、ここを通っても、問題の版、入力文、使える道具、試した回数、採点者が同じとは判断しません。検索品質を測るための正解付き質問集や、作業時間を比べる相手は用意されていません。

著者らは、1,283記録中790記録から12,916個の有限な数値を確認し、493記録には数値がなかったと報告しました。その493記録のうち464記録には論文、プログラム置き場、データのいずれかが残っていました。採点済み790記録のうち百分率の最低条件を満たしたのは82記録で、708記録は別尺度か未確認でした。公開日は615記録で分かり、668記録で不明でした。数値に付くモデルや文書の公開日は、実際の試験日ではありません。

仕組みの一部を外して結果を比べる試験は報告されていません。失敗例として、語句だけの検索は別表現を拾いにくく、先行研究を探す実例では通常のWeb検索も使いました。それでも共著者の指摘まで二つの研究を見逃しました。また、意味の近さで探す方法が良いか判断するための、人が確認した正解データもありません。

多数の数値が集まったことは、多数の試験を公平に順位付けできることを意味しません。1,283件も重複のない試験数ではなく、情報提供元別の記録数です。反対に、数値のない記録も無価値とは限りません。464件には元資料へのリンクがあるため、設計を調べる入口にはなり得ます。ただし、その候補が利用者の目的に合うかは測られていません。

収集件数の上限、通信の失敗、番号の欠落、保存日の違いが、集められた範囲へ影響します。古い論文の後から出た版を遡って集めない経路もあります。能力別の分類は正しさを確かめておらず、発見経路から来た5,863トラックには分類が付きません。検索や監査にかかる時間、画面の応答時間も比較できる形では報告されていません。

今後確かめるべきなのは、検索結果のうち本当に役立つ候補がどれほどあるか、言い換えをどこまで拾えるか、利用者がより良い試験を選べるか、調査時間が変わるかです。点数比較では、実際の試験日と細かな条件をどこまで記録できるかも課題です。料理の索引を増やすだけでなく、選び方が良くなったかを、同じ課題を使った比較で試す必要があります。

最低限同じ百分率として扱えたのが790記録中82記録だけで、条件一致はさらに確認が必要でした。この観察は、「数値があるか」と「公平に比べられるか」を別々に表示する設計を後押しします。数値のない記録にも464件の元資料リンクがあったため、「未採点」と「証拠なし」も分けられそうです。ただし、こうした画面や手順が候補選びを改善するか、余計な手間を増やさないかは未評価です。

論文、リポジトリ、データセット、モデルカード、技術報告に分散した情報を、ベンチマーク選定時にどう検索し、スコアの条件と出典まで監査可能にするかを問う。

寄与元ごとのソース記録を統合せず保持し、共通IDで成果物、言及、引用、スコア履歴を接続する。検索はBM25Fを用い、一致フィールドと順位構成を提示する。候補抽出と最終的な関連性判断は分離される。

著者らのv0.11.0全件監査では、1,283記録中790記録に12,916数値観測があった。一方、百分率単位、方向既知、0〜100という最低条件を満たしたのは82記録だけであり、プロトコル一致は別途確認が必要だった。

検索精度、タスク適合性、調査時間短縮は評価されていない。語彙検索は言い換えや改名を見逃し得るほか、ソース記録数は重複のない実体ベンチマーク数ではない。

比較適格な百分率記録が限定的だったことは、ランキング生成前に尺度とプロトコルを検証するワークフローを示唆する。ただし、そのワークフローが選定品質や所要時間を改善するかは、管理された利用研究なしには判断できない。

ベンチマーク研究者やモデル開発者は、関連評価を検索した後、データとコードを見つけ、報告スコアの設定を確認する必要がある。既存情報が論文、リポジトリ、データセット、モデルカード、技術報告へ分散する中で、検索から証拠監査までを一貫した識別子で支えることが課題である。

LLM Stats、OpenCompass、Artificial Analysisなどはランキング、評価基盤、モデル分析を提供する。しかし著者らは、新規ベンチマークからタスク成果物、後続モデルでの採用、具体的な評価条件まで追跡するには複数資源の横断が必要だったと位置付ける。

Benchmark Radarは、ソース記録の来歴を失わずに共通フィールドへ正規化し、レビュー済み同一性リンクで関連記録を接続する。欠損値を理由に記録を除去せず、関連記録の観測値も合算しない。これにより、候補集合の取得と、人間によるタスク適合性・比較可能性の判断を分離する。

日次発見は13の直接コネクタと24の一次フィードを使う。各実行は48時間窓を検索し、未来日付を除外し、件数とエラーを記録する。中核三ソースが正常な場合のみ公開する。検索はBM25Fに上限付きの名称・フレーズ一致ブーストを加え、一致語、欠落語、一致フィールド、スコア構成を返す。Web、CLI、HTTP、エクスポートは同じIDと応答形式を共有する。CLIは保存データのSHA-256、スキーマ版、来歴を検証し、固定版をオフラインで再検索できる。

全件監査はv0.11.0の1,283ソース記録をフィルターなしで処理した。数値観測は観測IDごとに一度だけ数え、モデルと引用文書も記録内のソースIDで重複排除した。百分率尺度の要約は、単位が明示され、改善方向が既知で、値が0〜100内の場合に限定した。ただし、テスト版、プロンプト、ツール、試行回数、評価者の一致は、この尺度判定に含まれない。

著者らは790記録から12,916数値観測を確認し、493記録には数値がなかったと報告する。未採点493記録のうち464記録には論文、リポジトリ、データセットの少なくとも一つがあった。採点済み790記録中、百分率条件を満たしたのは82記録で、708記録は他尺度または未検証尺度だった。さらに公開日は615記録で既知、668記録で不明だった。スコアに付随するモデル発表日や文書公開日は評価実施日ではない。

適用先は、評価設計前の先行研究探索、スコアの尺度・方向・引用・日付根拠の監査、固定データ版による再現検索である。未採点記録も成果物探索に利用できる。一方、意味的な言い換えを高再現率で取得する用途、検索性能の保証が必要な意思決定、異質な評価設定のスコアを追加確認なしで統合する用途には適さない。

クエリ単位の関連性判定がないため、検索精度と意味検索の改善幅は不明である。実例はWeb検索を併用し、管理されたベースラインを持たない。収集上限、要求失敗、識別子欠損、スナップショット日の差が網羅性へ影響する。能力分類は未検証であり、実行時間や対話レイテンシの比較測定も報告されていない。

790の採点済み記録のうち百分率尺度の最低条件を通過したのは82記録で、通過後もプロトコル確認が必要だった。したがって、検索システムの出力を即座にランキングへ変換せず、単位、方向、版、プロンプト、ツール、試行回数、評価者、日付根拠を検査する段階を設ける設計が合理的である。ただし、その段階が判断品質を高めるか、調査時間とのトレードオフに見合うかは未評価である。

対象問題は、関連ベンチマークの検索と、評価証拠の監査が分断されていることである。名称が一致しても同一実体とは限らず、同じ尺度でも評価プロトコルは一致しない。設計は、共通スキーマで検索可能性を得つつ、原ソースの識別子、欠損、観測単位を保存する必要がある。最終的なタスク適合性は自動判定せず、人間が原典を確認する前提を置く。

既存資源はリーダーボード、評価実行基盤、モデル分析を提供してきた。Benchmark Radarの位置付けは、それらを単一順位表へ吸収することではなく、新規ベンチマーク、タスク成果物、後続報告での採用、スコア設定を横断検索できる証拠層を作ることにある。Harborなどの共通実行基盤とは焦点が異なり、本研究は発見と来歴保持を中心に扱う。

処理は日次発見、ソース別カタログ化、フィールド正規化、レビュー済み同一性リンク、語彙検索、証拠閲覧、固定版のエクスポートから成る。名称、識別子、成果物リンク、スコア観測、モデルID、引用文書を共通フィールドへ写像するが、スコア・日付・引用が欠ける記録も保持する。検索で候補を絞り、成果物と原典を点検して関連性を確定する。

検索ランキングはBM25Fを基礎とし、フィールド重み付き語一致に、名称一致とフレーズ一致の上限付きブーストを加える。結果は一致語、欠落語、該当フィールド、スコア構成を提示するため、利用者は順位の語彙的根拠を確認できる。寄与元はランキング要因にしない。同一性リンクは参照関係であり、ソース記録、観測、集計件数の併合規則ではない。比較適格性も固定のレコード属性ではなく、百分率要約など個々の計算に対して判定される。

日次発見は13直接コネクタと24一次研究・技術フィードの計37ソースを対象とする。実行ごとに48時間窓を検索し、未来日付を除去し、件数とエラーを記録する。arXiv、Hugging Face Hub、GitHub Searchが正常な場合にのみ公開する。カタログ監査は再構築したv0.11.0の1,283ソース記録を日付・スコア・UIフィルターなしで読む。別系統の発見コーパスは46スナップショット、11,068観測、6,546成果物を含み、うち4スナップショットはシミュレーションによるバックフィルである。

全件監査では数値観測を観測ID単位で一度だけ数え、モデルと引用文書を各記録内のソースIDで重複排除する。百分率尺度の適格条件は、単位の明示、方向の既知性、0〜100の範囲である。この判定はテスト版、プロンプト、ツール、試行回数、評価者の同一性を保証しない。検索評価については、既知・未知ベンチマークを含むクエリ集合とレビュー済み関連性判定が用意されておらず、精度や再現率に相当する結果は報告されない。

全件監査で、著者らは1,283記録中790記録に12,916の有限数値観測を確認し、493記録を未採点とした。未採点493記録のうち464記録は論文、リポジトリ、データセットのいずれかを持つ。採点済み790記録のうち百分率尺度条件を満たしたのは82記録で、708記録は他尺度または未検証尺度だった。能力分類は1,279記録へ付与され、4記録は根拠フィールド欠損のため未分類だった。1,208の異なる引用文書が1,278記録に付いたが、1,171文書では組織名メタデータが不明だった。公開日は615記録で既知、668記録で不明である。

検索方式、ブースト、フィールド重みを除去して比較するアブレーションは報告されていない。関連研究探索の実例は、ローカル検索、成果物リンク確認、別表現を拾うWeb検索、原典読解を組み合わせたが、共著者の指摘まで2研究を見逃した。arXiv経路は収集窓以前に初版が出た論文の後続版を遡及収集しない。CI用の決定論的null extractorは5,863の発見由来トラックへ能力ラベルを付けない。

12,916観測という規模は、広い比較可能性の証拠ではない。百分率尺度の最低条件を通過した記録は82件であり、その内部でもプロトコル差が残る。また、1,283ソース記録を実体ベンチマーク数と解釈できない。一方、未採点記録の大半に成果物リンクがあるため、数値の欠如を探索価値の欠如とみなすのも不適切である。ただし、その成果物が特定タスクへ適合する割合は測定されていない。

収集上限、失敗要求、識別子欠損、スナップショット日の差が網羅性へ影響する。能力分類は未検証である。モデル発表日付き12,594観測と文書公開日付き322観測のいずれも評価実施日を直接表さず、飽和や停滞の時間分析を制約する。検索精度、候補適合性、調査時間短縮、処理時間、対話レイテンシには比較可能な測定がない。実例も管理されたベースラインを持たない。

必要な追試は、レビュー済み関連性判定を持つクエリ集合でBM25Fと意味検索を比較すること、既知・未知ベンチマークを分けて再現性を測ること、利用者が選ぶ評価の妥当性と調査時間を管理条件下で比較することである。スコア分析では、テスト版、プロンプト、ツール、試行回数、評価者、実評価日をどこまで回収できるかが残る。分類体系の妥当性と、未採点記録を含めることの実際の便益も未解決である。

監査結果は、数値の存在、尺度上の適格性、プロトコル上の比較可能性を別変数として扱う必要性を示す。特に790記録中82記録しか百分率尺度条件を満たさず、その82記録にも設定差が残り得るため、ランキング生成を証拠監査の後段へ置く設計が妥当である。ただし、これはデータ構造から導く設計上の含意であり、選定品質や作業時間の改善を示す因果的証拠ではない。

分散した論文、コード、データセット、モデルカード、技術報告から関連ベンチマークを発見し、報告スコアの来歴と評価条件まで追跡可能にすることが課題である。

37ソースの日次発見と1,283件のカタログを共通IDで接続する。BM25F検索は一致根拠を表示し、レビュー済み同一性リンクは関連記録を結ぶが集計単位を併合しない。

v0.11.0の全件監査で、著者らは790記録から12,916数値観測を確認した。百分率単位、既知方向、0〜100という条件を満たしたのは82記録であり、尺度適格後も評価プロトコルの一致確認が必要である。

検索精度、タスク適合性、調査時間短縮は未評価である。語彙検索は言い換えを見逃し得て、ソース記録数は異なる実体ベンチマーク数ではない。

82件という比較適格記録の限定性は、リーダーボード統合より先にプロトコル監査を置く設計を支持する。ただし、これが選定品質や調査効率を改善するという実証結果はなく、管理された利用研究が必要である。

研究者・開発者が評価を選ぶ際、候補発見に加えてデータセット、コード、後続モデルでの採用、スコア設定、引用根拠を追跡する必要がある。これらが複数資源へ分散する状況で、検索可能性と監査可能な来歴を両立することが研究課題である。

LLM Stats、OpenCompass、Artificial Analysisなどはリーダーボード、評価実行、モデル分析を担う。一方、著者らは、新規ベンチマークからタスク成果物、採用例、条件付きスコアまでを連結して確認するには資源横断が必要だったとする。

システムは寄与元別エントリをソース記録として保持し、共通フィールドへ正規化する。レビュー済み同一性リンクは関連記録を接続するが、観測と集計件数を統合しない。欠損レコードも保持することで、スコアの有無と証拠の有無を分離する。

日次発見は13直接コネクタと24一次フィードを対象とし、48時間窓、未来日付除外、件数・エラー記録、中核三ソースの公開ゲートを用いる。検索はBM25Fに名称・フレーズ一致ブーストを加え、一致語、欠落語、フィールド、スコア構成を返す。Web、CLI、HTTP、エクスポートは同一IDと応答形式を共有する。CLIはSHA-256、スキーマ版、来歴を検証して固定アーカイブをオフライン検索する。

v0.11.0の全件監査は1,283ソース記録をフィルターなしで読み、観測ID、モデルID、文書IDにより重複計数を抑えた。百分率集約の適格条件は単位明示、方向既知、0〜100内である。尺度適格性は、テスト版、プロンプト、ツール、試行回数、評価者の一致を含意しない。

著者らは790記録に12,916数値観測、493記録に数値なしと報告した。未採点493記録のうち464記録には論文・リポジトリ・データセットの少なくとも一つがある。採点済み790記録中、百分率条件を満たすのは82記録で、708記録は他尺度または未検証尺度だった。公開日は615記録で既知、668記録で不明であり、付随するモデル発表日・文書公開日は評価実施日を直接示さない。

本システムは、評価設計前の先行研究検索、証拠付き候補集合の構築、スコア来歴の監査、固定データ版での再現に適する。高再現率の意味検索、検証済みのタスク適合性、異質な設定を横断する自動ランキングは対象外である。

検索精度、タスク適合性、調査時間短縮について管理された評価がない。語彙検索は言い換え・改名を見逃し得る。収集上限、要求失敗、識別子欠損、スナップショット日の差が網羅性へ影響する。能力分類は未検証で、処理時間と対話レイテンシの比較結果もない。

採点済み790記録のうち百分率尺度の最低条件を満たすものが82記録に限られ、さらにプロトコル確認が必要という結果は、集約前監査を第一級の設計要件にする根拠となる。ただし、その監査フローが実際に誤選択を減らすか、追加コストに見合うかは本研究の評価範囲外である。

ベンチマーク選定には、候補検索、成果物取得、採用履歴確認、スコア条件の監査が必要だが、それらは異なる情報源に分散する。さらに、名称同一性、実体同一性、尺度同一性、プロトコル同一性は別問題である。本研究は、自動的な最終選定ではなく、候補抽出から原典確認へ至る証拠経路の構築を目標とする。

既存のランキング、評価基盤、モデル分析サービスに対し、本研究は発見・来歴・採用・スコア履歴を横断する検索層として位置付けられる。関連する共通実行基盤が評価実行を標準化するのに対し、Benchmark Radarは異質な既存記録を保持しながら検索・監査可能にする。論文の主張は統一リーダーボードの完全性ではなく、証拠へ戻れるカタログ設計にある。

パイプラインは日次発見、寄与元別のソース記録化、共通スキーマへの正規化、同一性リンク、BM25F検索、証拠閲覧、アーカイブ配布で構成される。正規化対象は名称、識別子、成果物リンク、スコア観測、モデルID、引用文書である。欠損を持つ記録も除外せず、関連レコードをリンクしても観測単位を保持する。先行研究探索の実例では、ローカル検索後に成果物を点検し、Web検索で別表現を補い、原典から設計次元別の表を作る。

ランキングはフィールド重み付きBM25Fを基礎とし、名称完全一致とフレーズ一致に飽和する追加ブーストを与える。検索応答は一致・欠落クエリ語、ヒットフィールド、スコア構成を返し、寄与元カテゴリ自体は順位へ寄与しない。同一性リンクはレビュー済み関係として表現され、集計時のレコード縮約には用いない。比較適格性はレコードの恒久属性ではなく分析固有の述語であり、百分率要約では単位、方向、値域を検査する。

収集面では13直接コネクタと24一次研究・技術フィードを用い、各実行で48時間窓を検索する。未来日付を除去し、取得件数とエラーを記録し、arXiv、Hugging Face Hub、GitHub Searchが正常な場合のみ公開する。監査対象はv0.11.0の再構築済み1,283ソース記録で、日付・スコア・画面フィルターを適用しない。発見コーパスは46スナップショット、11,068観測、6,546成果物を含み、4スナップショットはシミュレーションによる過去バックフィルである。

数値観測は観測IDごとに一回数え、モデルと引用文書も各記録内のソースIDで重複排除する。百分率要約への包含条件は、百分率単位が明示され、改善方向が既知で、値が0〜100内にあることである。この条件はテスト版、プロンプト、ツール、試行回数、評価者の同一性を検証しない。検索側にはクエリ別のレビュー済み関連性判定、既知・未知ベンチマークを分けたテスト集合、管理ベースラインがなく、検索精度を定量化できない。

著者らの監査では、1,283ソース記録中790記録に12,916の有限数値観測があり、493記録は未採点だった。未採点記録の464件は少なくとも一つの成果物リンクを持つ。採点済み記録中、百分率尺度条件を満たしたのは82件で、708件は他尺度または未検証尺度だった。能力分類は1,279記録を11上位・63下位領域へ割り当て、4記録を未分類とした。文書レジストリは1,208文書を含み、1,278記録に文書が付く一方、1,171文書は組織名が不明だった。公開日は615記録で既知、668記録で不明だった。

BM25F、フィールド重み、各ブースト、同一性リンクの寄与を分離するアブレーションは報告されていない。実例ではローカル検索とWeb検索を併用したにもかかわらず、共著者の指摘まで2件の関連研究を見逃した。arXiv収集は窓以前に初版が出た論文の後続版を遡及取得しない。能力分類は未検証であり、CIのnull extractorは5,863発見由来トラックを未分類にする。したがって、検索漏れと分類欠損はいずれも観察されている。

カタログ規模はカバレッジの完全性を示さず、1,283ソース記録は重複排除済み実体数ではない。12,916数値観測も直接比較可能なモデル・ベンチマーク対の数ではない。82件という百分率適格集合は共通headroom分析の入口にすぎず、プロトコル差を除去しない。他方、未採点493記録中464記録が成果物を持つため、スコア欠損を探索価値欠如と解釈することもできない。いずれの解釈も、タスク適合性の利用者評価を必要とする。

収集上限、失敗要求、欠損識別子、異なるスナップショット日が網羅性を制約する。モデル発表日付き12,594観測と文書公開日付き322観測は評価実施日の代理であり、時間軸上の飽和・停滞推定を直接支えない。尺度一致もプロトコル一致を保証しない。検索精度、候補適合性、調査時間、処理時間、対話レイテンシには比較測定がないため、製品効果や効率改善は結論できない。

今後は、専門家が判定したクエリ単位の関連性集合で語彙検索と意味検索を比較し、名称変更・言い換え・未知ベンチマークに対する再現性を測る必要がある。利用研究では、選択された評価の妥当性、見逃し、調査時間を管理ベースラインと比較すべきである。スコア分析には、テスト版、プロンプト、ツール、試行回数、評価者、実評価日の取得率を明示する必要がある。未採点記録の保持と分類体系が意思決定へ与える効果も未検証である。

本監査が示す最も実務的な含意は、スコア存在、尺度適格性、プロトコル比較可能性を同一フラグへ縮約しないことである。790採点済み記録から百分率尺度条件を通過したのは82記録に限られ、通過後も版・プロンプト・ツール・試行回数・評価者・日付根拠を監査する必要がある。このため、証拠監査をランキング生成の前段へ置くデータモデルは合理的である。ただし、その設計が誤った比較を減らし、利用者成果を改善するかは、管理された評価なしには確定できない。