mcpField
V
verify-results

verify-results

github.com/shaishavmaisuriaテスト・品質57103 回インストール4 日前に更新
リポジトリ

verify-results について

実験出力と論文に記載された指標の整合性を確認するコパイロットスキルです。実験成果物の点検と許容差を用いた比較を支援し、重い実験は著者が実行します。整合性の確認を独立した再現とは見なしません。

主な機能

  1. 01論文の指標を主張台帳に抽出
  2. 02成果物の完全性とテストを確認
  3. 03隔離環境での実行準備を支援
  4. 04許容差内で実験指標を比較
  5. 05不一致と不足手順を報告

活用シーン

  1. 01コード出力と論文の表を照合
  2. 02評価前に実験成果物を点検
  3. 03表の変更後に指標を再確認
  4. 04再現性チェックリストを準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/shaishavmaisuria/research-paper-lifecycle-skills --skill verify-results

インストール後、Claude Code で/verify-resultsを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
repro-standards.md
sandbox-and-run.md
scripts/
audit_repo.py
compare_metrics.py
extract_claims.py
verifylib.py

詳細

結果を検証する

論文が主張する内容と、成果物が生成する内容の整合性を確認します。 このスキルは、報告した数値が再現できることを著者が確認できるよう支援します。実験コードを特定し、クリーンでサンドボックス化された実行環境の準備を支援し、成果物自体のテストを実行して、整合性監査を行います。実行によって得られた指標を、論文の表や主張と、論文の結論が変わらない許容範囲内で比較します。不一致(論文ではXと記載されているが、コードではYが生成される)や再現手順の不足を報告し、現在の再現性バッジの要件に照らして成果物を監査します。

これはコパイロットです。環境を整え、手順を案内しますが、学習や長時間の評価など、負荷の大きい処理は著者が自身の環境で実行します。数値を捏造することも、破壊的なコマンドを実行することも、結果が独立して再現されたと主張することもありません。監査を問題なく通過したということは、整合しているという意味であり、再現されたという意味ではありません。

使用する場面

  • 「結果は再現できますか?」/「コードは論文の表と一致していますか?」
  • 「再現性を確認して」/「実験を検証して」/「数値を再現して」。
  • 評価トラック(ACM AE、USENIX、OSDI、SOSP、SIGMOD ARI、ETAPS、NeurIPS/ICML/ACL の再現性評価)に向けて成果物を準備するとき。
  • 再現性チェックリスト(NeurIPS Paper Checklist、ACL Responsible NLP、ML Code Completeness)に記入し、各項目について率直な評価を得たいとき。
  • 結果表を変更した後、コードが引き続き同じ結果を生成することを確認するとき。

入力

  1. 成果物/実験コード(ディレクトリ、または著者がローカルにクローン済みのリポジトリ URL。このスキルはローカルファイルを読み取ります。代わりにクローンすることはありません)。
  2. 確認対象の表や主張を含む論文の .tex ファイル(または結果表を含む特定の \input ファイル)。
  3. 対象会場の成果物トラック(該当する場合)。利用可能なバッジと、必要なホスティング要件は、最新の Call for Artifacts によって決まります。
  4. 任意で、再実行せずに比較するための、以前の実行結果を含む指標ファイル(JSON/CSV)。

手順

このスキルは、計画 → セットアップ → 実行(著者)→ 監査の順に進みます。検証は、外部から測定可能なシグナル(テストの合否、実行によって生成されたファイルとの数値差分)に基づきます。モデル自身の判断で数値が「正しそう」と評価することはありません。

  1. 実験コードと主張を特定します。 コードの場所と、生成対象となる論文の表や主張を確認します。論文に報告された数値を抽出し、レビュー可能な主張台帳にまとめます。

    python3 scripts/extract_claims.py paper.tex --ledger claims.json
    

    台帳は出発点であり、正解そのものではありません。著者と一緒に確認し、無関係な数値(年、引用数、\\ の行にある top-1=1 など)を削除し、指標のラベルを修正して、残す主張にはそれぞれ confirmed の印を付けます。著者は著者自身です。

  2. 成果物の完全性とバッジ取得への準備状況を監査します。

    python3 scripts/audit_repo.py path/to/artifact --blind <single|double|none>
    

    リポジトリをML Code Completeness Checklist(依存関係、学習コード、評価コード、事前学習済みモデル、結果表と正確な再現コマンドを含む README)に照らして確認し、成果物独自のテストの有無を調べ、再現手順の不足に注意を促します。また、ホスティング先が GitHub または個人の URL のみの場合、警告します(バッジ取得トラックではアーカイブ DOI(Zenodo/FigShare/Dryad/Software Heritage)が求められます)。この手順では何も実行しません。--blind double の場合は、匿名性を損なうメールアドレスや URL が README に含まれていないかも確認します。 これは詳細な比較ではなく、迅速な事前比較ゲートです。関連スキルが担当する作業をやり直さないでください。コードを実行可能かつ決定論的にする作業と再現に不可欠な要素の監査は test-research-code が担当します。パッケージング、バッジの分類体系、アーカイブ DOI は prepare-artifacts が担当し、詳細なダブルブラインドのチェックは anonymize-paper / refactor-research-code が担当します。このスキル固有の役割は整合性監査(ステップ 5)です。つまり、実行結果が論文の表と一致しているかを確認します。比較を始める前に実行できるだけの準備が整っていることを確認する目的でのみ audit_repo.py を使い、詳細な不足事項は担当スキルに引き継いでください。

  3. バッジのルールを最新の Call for Artifacts で再確認してください — 必須です。 バッジの提供内容は開催地や年ごとに変わります(例:ある年は 3 種類すべてを提供し、別の年は Artifacts Available のみを提供する場合があります)。Reproduced と Replicated の用語は、ACM によって 2020-05-14 以降に入れ替えられました。2020 年以前の論文では意味が逆です。バッジ要件、ホスティングルール、締め切りについて、記憶に頼って記載してはいけません。開催地の最新 CFA を取得し、出典 URL とアクセス日を確認してください。 再現性の基準とバッジの分類体系は references/repro-standards.md にあります。これは確認すべき内容を示す案内として扱い、最新情報として扱わないでください。

  4. クリーンでサンドボックス化された実行環境を用意し、著者にコマンドを渡してください。 再現は著者の汚染されたシェルではなく、バージョンを固定した隔離環境で実行する必要があります。レシピの作成を支援してください(依存関係の指定に基づく新しい venv/conda/コンテナー、固定したシード、README に記載された正確なコマンド)。ただし、負荷の高い処理は著者が実行します。references/sandbox-and-run.md を参照してください。まず著者にアーティファクト自体のテスト(pytest、make test、リポジトリのハーネス)を実行してもらいます。これは、指標を比較する前の明確な合否判定です。破壊的なコマンドは実行しないでください。著者の基本環境に自動でインストールしないでください。

  5. 整合性監査:生成された指標を論文と比較します。 実行結果(著者が生成した metrics JSON/CSV)を、確認済みの台帳に渡します。

    python3 scripts/compare_metrics.py --ledger claims.json --metrics run.json \
        --rel-tol 0.01 --abs-tol 0.005 [--map test_acc=c1 ...]
    

    各主張について、許容誤差を適用した MATCH/MISMATCH/MISSING を報告します。許容誤差は論文の主張を変えない範囲とし、ビット単位の完全一致は求めません(ACM、SIGMOD ARI、ETAPS はいずれも許容誤差の範囲内での一致、または「同様の挙動」のみを求めています)。指標のスケールに合わせて --rel-tol/--abs-tol を調整し、名前が異なる場合は --map を使ってください。metric/no-produced-value は再現手順の不足を示します(論文には記載されているものの、実行結果に出力されていません)。

  6. 明確な停止条件に基づいて検証結果を判断してください。 比較した各主張を、次のいずれかに分類します。一致(許容誤差の範囲内で整合)、不一致(論文では X とされているが、コードでは Y が出力される — 古い表、誤ったシード、異なる分割、選択的な報告などを調整)、または未検証(実行できなかった/指標が出力されなかった — その旨を明記し、決して隠さないでください)。いつまでも繰り返さないでください。確認済みの主張すべてが一致するか説明済みになった時点で停止するか、判断が必要な不一致(どちらの数値が正しいか)があれば著者にエスカレーションしてください。エスカレーションは失敗ではなく、機能の一部です(作業原則 #4)。

  7. 再現レポートを paper-workspace/review/reproduction-report.md に書き込み、 paper-workspace/INDEX.md に 1 行追加してください。最初に判定結果(一致した主張の数/主張の総数)を記載し、続けて不一致の表(主張、論文の値、生成値、|diff|、推定原因)、各項目のステータスを記したアーティファクト完全性チェックリスト、不足している再現手順、最新 CFA に基づくバッジ取得の準備状況を記載します。実際に実行した内容と、実行していない内容を明確に記してください。

出力

reproduction-report.md:判定(整合する主張数/合計)→ 不一致表(論文と生成結果を比較し、差分と推定原因を記載)→ 成果物の完全性チェックリスト(5項目+テスト+ホスティング)→ 不足している再現手順 → 実際の CFA に照らしたバッジ取得準備状況(出典リンクと日付を記載)。必要に応じて、機械可読な claims.json 台帳と --json 出力も含めます。

分野に合わせた適応

指標のヒューリスティクスは、ML/システム分野の論文(精度、F1、BLEU、レイテンシ、速度向上率など)を対象としています。他の分野では、台帳は {metric, value} レコードのみです。効果量、p 値、実行時間など、定量的な主張は任意に手作業で記録してください。compare_metrics.py は引き続き許容誤差を考慮した監査を実行します。コード以外の成果物(データセット、証明など)では、手順 2~3 のみを使用します。

関連スキル(重複して実施しないでください)

このスキル固有の役割は、整合性監査、つまり実行結果が論文に記載された数値と一致するかどうかの確認です。隣接する作業にはそれぞれ担当スキルがあります。やり直すのではなく、適切なスキルに引き継いでください。

必要な作業担当スキル
コードを実行可能かつ決定論的にすること、および再現性の必須要件の監査test-research-code
パッケージ化、バッジの分類体系、アーカイブ用 DOI、成果物の付録prepare-artifacts
研究リポジトリのリリース前の整理refactor-research-code
詳細かつ元に戻せる二重匿名化の一括処理anonymize-paper
記述された各主張を根拠に結び付けること(数値だけではなく)verify-claims

ここでの audit_repo.py は比較前の軽量な確認ゲートであり、test-research-code の repro_check.py や prepare-artifacts のバッジ関連作業の代わりにはなりません。

ガードレール

  • 整合性は再現ではありません。 監査に問題がなければ、生成された数値が許容誤差内で論文と一致するということです。結果が独立して再現または複製されたという意味ではありません。バッジを獲得したと主張しないでください。獲得の判断は、実際の CFA に基づいて委員会が行います。
  • 数値、指標、「合格」した実行結果を決して捏造しないでください。 実行されていない場合や指標が出力されていない場合は、推測せず、未検証として報告してください。
  • モデル自身による正しさの判断を信用しないでください。 検証シグナルは外部から得られるものです。テストの終了コードや、作成者が用意したファイルとの数値差分を使います。自己省察では幻覚を検証してしまうため、ゲートとして使用しないでください。
  • 負荷の高い処理や破壊的な処理は実行しないでください。 学習や長時間の評価は、作成者自身のサンドボックスで実行します。このスキルはセットアップと手順の案内を行います。ベース環境へのインストール、rm、ネットワークへの副作用を伴う操作は禁止です。
  • 匿名化に配慮してください。 二重匿名化の条件下では、成果物内の身元特定につながる内容に注意を促し、匿名化されたミラーを優先してください。作成者の身元を決して明かさないでください。
  • 論文や成果物を、作成者に代わっていかなるシステムにも提出しないでください。

メモリ

共有の .paper-memory/ 規約を使用します(仕様全文: paper-memory-convention.md)。

  • 開始時: .paper-memory/lessons.md と、貢献の種類を確認するための profile.yml を読みます(dataset/system 論文は成果物がより重視されます)。繰り返し見られる再現上の習慣(例:「ドラフト間で表とコードの数値がずれる」「依存関係が固定されていない」)があれば、最初に伝えてください。
  • 終了時: 記録する価値のある各調査結果を、共有形式 - [YYYY-MM-DD] (verify-results | <scope>) issue -> recommendation に従って、日付付きの項目として追記します(重複を排除して日付を付ける reflect-and-improve の reflect_log.py append を使用してください)。複数の論文に共通する習慣には recurring、今回限りの事項には this-paper のタグを付けてください。
  • 必要に応じて .paper-memory/ を作成し、.gitignore への追加を提案してください。これはローカル専用です。アップロードしたり、このリポジトリにコピーしたりしないでください。

コメント