Reproduce Pipeline Deep Dive

再現スコア 0.5 から始まった Reproduce Pipeline を強化し、5 論文で再測定した結果

結果ページの §3 Reproduce Pipeline の続編 — 「徹底的に強化したい」という方針で 4 つのコード改善 + 5 論文での再評価を行いました。

§0 はじめに — このページが何を見せるのか

このページを 1 文で: 論文 PDF から AI が再現コードを自動生成する仕組み (Reproduce Pipeline) を強化し、 5 論文で再測定して、さらに 同じタスクを自律研究エージェント (ARA) にも並行で解かせた 結果をまとめたものです。 結果ページの §3 Reproduce Pipeline の続編で、 §3 が「1 論文で再現スコア 0.5 だった」と報告したのに対し、本ページは「ではどう強化したか」「強化はどう効いたか」「agent はもっと深い改善を見つけたのか」を扱います。

§0.1 前提となる用語 (背景知識ゼロでも読めるように)

Reproduce Pipeline
arXiv URL を渡すと、論文 PDF の取得 → 再現コード生成 → 環境構築 → 実行 → 数値検証 の 5 stage を全自動で回すツール。本日強化対象。
5 stage の内訳
①Paper Fetching ②Code Finding (= Claude が再現コードを 1 発生成) ③Env Building ④Execution ⑤Verification (論文の数値主張と実行結果の照合)
PaperBench
OpenAI が公開する「論文再現の自動評価ベンチマーク」。23 論文それぞれに rubric.json という採点ツリー (例: 94 〜 2551 ノード) が付属し、各ノードに 0–100 スコアと重みが付く。
hierarchical_score
PaperBench の最終スコア。rubric ツリーの葉ノード (実装すべき各要件) のスコアを、重み付きで親に伝播させて root に集約した値 (0–100)。本ページでの主要 metric。
Code-Dev mode / Full mode
Code-Dev = 生成コードを judge に読ませて静的に採点 (GPU 不要・低コスト)。Full = 実際にコードを実行して数値が論文と一致するか確認 (GPU 必要)。本日の評価は Code-Dev のみ。
SimpleJudge
PaperBench 公式の評価器。GPT-4o-2024-08-06 を使って rubric ノードを採点する。我々はコストの都合で claude-sonnet-4-20250514 で代替。絶対値は公式と直接比較できないが、改善前 vs 改善後の 差分 は意味がある。
untested ノード
実行出力に該当 metric が無く、judge が「該当する数値主張を確認できなかった」と判定したノード。本日の verifier は untested に 0.25 の partial credit を与える設定 (改善前は 0.5)。
ARA (自律研究エージェント)
Claude を Researcher / Evaluator / Reviewer / Improver の 4 役で回す自律研究 harness。研究テーマを 1 つ与えると、cycle を回しながら仮説生成・実装・検証を繰り返す。本日 §4 で並行実験に使った相手。

§0.2 出発点: 1 論文で再現スコア 0.5 だった

結果ページ §3 で見せた最初の実走 (論文: Stochastic Interpolants) では、3 件の数値主張 (FID 系) のうち 3 件全てが untested でした。Pipeline は最後まで完走しているのに、生成コードが論文の Table の数値を出さない構造に なっていたためです。 hierarchical_score 0.5 という数字は、untested の partial credit (当時 0.5) で底上げされた値で、 実質的には「動いたが何も検証できていない」状態に近い。これを起点に Reproduce Pipeline を本格的に強化することにしました。

§0.3 4 つの改善 — 何をどう直すか

上記の 5 stage のうち、ボトルネックになっていた 3 つの Stage に対する 4 件のコード改善を入れました。各改善が 「どの Stage の、何を直すか」「改善前は何が起きていたか」「改善後どう変わるか」を簡潔に:

改善対象 Stage改善前 → 改善後
① metric alias 拡張 Stage 5 (Verification) 論文の "FID-50k" を捕捉できる metric 名の辞書を 12 → 40+ に拡張。改善前は "FID" としか書かれていない数値主張を取りこぼしていた。
② success 厳密化 Stage 4 (Execution) 「returncode=0 だが silent failure (RuntimeError スルー、shape mismatch 等)」を success と誤判定する問題を修正。
③ pdfplumber 導入 Stage 1 (Paper Fetching) PyPDF2 → pdfplumber に切替えて Table 抽出を可能にした。改善前は本文 text のみ、改善後は Table の数値も Claude に渡る。
④ max_tokens 緩和 Stage 2 (Code Finding) Claude のコード生成上限を 8192 → 16384 tokens に拡張。改善前は複雑な論文で生成コードが途中で切れていた。

§0.4 §1 で出てくる「改善前 (baseline) / 改善後 (improved)」とは何か

用語の定義 — §1 以降を読む前にここを押さえてください:
  • baseline (改善前) = 上記 4 改善を入れる前の reproduce repo (main branch) で、同じ論文・同じ rubric を採点した hierarchical_score
  • improved (改善後) = 4 改善を入れた branch (reproduce/strengthen-2026-04-30) で、同じ論文・同じ rubric を採点した hierarchical_score
  • 同じ論文 × 同じ judge × 同じ rubric.json で測るので、改善前 / 改善後の 差分 (Δ) が「4 改善が hierarchical_score をどれだけ動かしたか」を直接表す
  • 1 論文だけだと偶然の可能性があるので、PaperBench から 5 論文を選んで × 2 variants = 10 evaluations を回した

§0.5 このページの構成

§1 改善前 / 改善後 — 5 論文での比較

§0.3 で挙げた 4 改善を入れる前 (baseline) と入れた後 (improved) の hierarchical_score を、PaperBench から選んだ 5 論文で並べて比較します。 ※ baseline / improved の定義は §0.4 を参照。

評価設定 (§0 と重複しますが再掲):
  • Mode: PaperBench Code-Dev (生成コードのみを採点、実行不要、GPU 不要)
  • Judge model: claude-sonnet-4-20250514 (公式 SimpleJudge は GPT-4o だが、コスト的に Sonnet を使用)
  • baseline: 改善前のコード (main branch)
  • improved: 4 改善を適用したコード (reproduce/strengthen-2026-04-30 branch)
  • 選んだ 5 論文: PaperBench 23 論文のうち、rubric ノード数が比較的小さい 5 件 (stochastic-interpolants 94 / semantic-self-consistency 100 / sequential-neural-score-estimation 123 / mechanistic-understanding 128 / robust-clip 146)。今回のラウンドのスコープでは全 23 論文を回しきらず、まず代表 5 件で baseline と improved を 1:1 比較できる体系を作ることに絞った。

進行状況

① 改善前/後 スコア比較（チャート）

5 論文の hierarchical_score（改善前 vs 改善後）

② 詳細表

論文 nodes baseline improved Δ 状態

§2 4 つのコード改善 — 何をどう直したか

再現スコア 0.5 の主な原因 4 つに対する具体的な対策。各改善のファイル変更とロジックを示します。

§3 失敗ケースの正直な開示

改善後でもスコアが伸びなかった論文・ノードがあれば、その原因と理由を開示します。

改善が効くドメインと効かないドメインを正直に切り分けることが、次の一手の設計を可能にします。 スコアが伸びなかったケースは「改善が効かない構造的な理由」を示すデータとして重要です。

事例 1: arxiv_id の取り違え（バッチ第 1 回時の発覚）

バッチ第 1 回（2026-04-30 17:58 起動）で、5 論文中 2 件で arxiv_id を推測値で hardcode していたために別の論文を fetch していたことが判明しました。 paperbench-data/ 配下の config.yaml に arxiv_id が含まれていなかったため、title から推測したのが裏目に出ました。

発覚後 WebSearch で正しい arxiv_id を取得し、第 2 回バッチで再走。これは「測定インフラの完成度を上げないと改善効果が見えない」典型例。

事例 2: PaperBench Code-Dev mode の評価特性

今回の評価は Code-Dev mode（生成コードを judge にかける、実行不要）で行いました。この mode では：

つまり 4 改善のうち Code-Dev mode で効くのは ③ と ④ の 2 件。①② を効かせるには Full mode（実際に実行して数値検証）が必要で、これは GPU + 環境構築コストが跳ね、明日の発表 scope 外としました。

事例 3: Claude 生成の確率性

Stochastic Interpolants の smoke test（improved 1 回目）= 36.49%、本番バッチ（improved 2 回目）= 49.53% と、同じ prompt でも結果が大きく変動します。これは Claude が確率的にコードを生成するため。 絶対値の比較ではなく、baseline と improved の差分を見ることに意味があります。バッチでの差分は +0.94 で、5 論文中で最も小さい改善幅でした。

本日測定での個別ケース

未着手の改善: Stage 2 (Code Finding) の生成コード品質改善（prompt + few-shot example）と Stage 3 (Env Builder) の堅牢化（conda/uv hybrid）は今回のラウンド外。 Stage 2 が改善されれば、現状 untested に落ちている FID 計算コードが正しく入って、 数値主張の検証が一気に通る可能性があります。

§4 並行実験 — agent に同じ問題を解かせる

「Reproduce Pipeline を強くする」というタスクを、人間の手作業 (上記 §1〜§3) と並行して、 自律研究エージェント (ARA) にも独立に解かせました。 同じ問題を 3 つの主体に並列で投げる 構図で、結果を比較します。

§4.1 実験構図

同じ research question に対して、3 主体が独立に取り組みます。主体 A は人間が Claude と一緒に Reproduce Pipeline 本体を改善する流れ。 主体 B / C は scripts/new-research.sh で runs/<name>/ に完全コピー scaffold (.claude + skills + workspace + 独立 git) され、元 repo (autonomous-research-agent, research-prime, autores/reproduce) は読み取りのみ。 改善案は ARA project 内 experiments/ に閉じます。

graph LR Q[Research Question:
PaperBench Code-Dev で
hierarchical_score を上げる] Q --> A[主体 A
人間 + Claude
強化ラウンド] Q --> B[主体 B
ARA harness × ARA 15 skills
自律 2 cycle] Q --> C[主体 C
ARA harness × research-prime 123 skills
cycle 1 半 で harness 早期 exit] A --> RA[5 論文バッチ再測定
mean +3.6 pt] B --> RB[既存バグ 4 件発見
+ H4 仮説 +24.3 pp on subset] C --> RC[failure 4 クラスタ分類
+ Layer 0 validator 2 件
CLIIntrospector F2 実証] RA --> M[メタ比較
同じ問題、別の解き方、別の答え] RB --> M RC --> M classDef question fill:#fff8e1,stroke:#f9a825,stroke-width:2px; classDef human fill:#e8f0ff,stroke:#3a7; classDef agent fill:#f0fff4,stroke:#0066cc; classDef meta fill:#fce4ec,stroke:#c2185b,stroke-width:2px; class Q question class A,RA human class B,C,RB,RC agent class M meta

§4.2 出てきたものを並べる — 改善幅 / 既存バグ発見数 / Claim 数

3 主体が同じ research question に対して何を返してきたかを 3 つの軸で並べます。 改善幅は 単位が主体ごとに異なる ことに注意 — 主体 A は 5 論文 mean の pt 差分、 主体 B は 1 論文 rubric subset での pp 差分。絶対値の比較ではなく、 「人間は測定インフラを底上げした」「agent は人間が見落としたバグと深い改善仮説を出した」 という質の違いを見るためのプロットです。

改善幅 (単位は主体ごとに異なる)

発見した既存バグ件数

登録された Claim 数 (Belief Store)

§4.3 ARA が見つけた既存バグ 4 件

主体 B (ARA 15 skills) が、人間 + Claude の強化ラウンドが見落としていた既存 reproduce repo のコード問題を 4 件発見しました。すべて Belief Store の Claim として記録され、対応する Evidence が ledger に紐付いています。

§4.4 H4 仮説の per-node breakdown — どこが効いたか

主体 B が立てた H4 仮説 (Stage 2 prompt から "simplify" / "standard datasets" の指示を除き、論文固有の dataset と すべてのタスクを明示する) を、stochastic-interpolants の rubric subset 7 ノードで実機検証した結果です。 生成は anthropic.Anthropic() で実コード生成、judge は claude-sonnet-4-6。 各ノードのスコア (0〜100) を baseline (現行 prompt) と H4 (修正 prompt) で対比します。

baseline vs H4 — 7 ノードのスコア

§4.5 ARA-p が抽出した failure taxonomy 4 クラスタ

主体 C (research-prime 123 skills) は cycle 途中で harness 早期 exit したため数値結果には届きませんでしたが、 Researcher セッションが 5 論文 baseline の生ログ (_master.json, report.json, stderr) を直接精読し、 失敗パターンを 4 クラスタに自動分類しました。これは「次にどこに介入すべきか」の優先順位付けに直結します。

クラスタ別頻度

クラスタの内訳

§4.6 CLIIntrospector が捕えた具体例 (主体 C の F2 実証)

Layer 0 validator の 1 つ。--help の出力を parse して subcommand 構造を学習し、 argparse の文法に合った形で実行コマンドを組み立て直す。robust-clip の実コードで動作確認済み:

§4.7 Self-Evaluator が flag した誇張 — 信頼性の自己校正

ARA は Researcher → Evaluator → Reviewer → Improver の 4-phase ループ。 同じセッション内で Evaluator が Researcher の主張を読み直し、誇張・未検証の項目を flag します。 これは「agent が自分の出力を盛らない」ための内蔵 mechanism で、今夜の run でも以下が flag されました:

メタな結論: 人間 + Claude が今回の強化ラウンドで出した +3.6pt / バグ 0 件 よりも、 ARA が並行で出した +24.3pp (subset) / 既存バグ 4 件 のほうが、定量的にも定性的にも大きい。 人間側は「測定インフラを底上げした」(5 論文で正しく測れるようになった) ことが本質、 agent 側は「生成コード本体の質的改善に直接効く介入を見つけた」ことが本質、と読めます。 「Reproduce Pipeline を強くする」というタスクは、 人間が改善案を考えるより、agent にループを閉じさせる方が深い改善が出る 可能性が高いことを部分的に実証しました。 ただし主体 B の +24.3pp は 1 論文 × 7 ノード subset の結果 であり、5 論文 × 全 rubric ノードでの再現はまだです。 次の一手は §5 へ。

§6 パイプラインレベル改善実験 — 「再現はどうあるべきか」を実装で問い直す

§1〜§3 の改善は「細かい修正」レベル (metric alias / pdfplumber / max_tokens など) でした。 §4 で並行実験した ARA は人間が見落としていた既存バグを 4 件指摘してくれましたが、 これだけでは「再現とは何をすることか」というパイプラインレベルの設計が問われていません。 §6 では ARA-提案 fix を実際に reproduce repo に取り込み、 さらに 「再現はこうあるべきだ」を実装に落とした新 mode (rubric-aware Stage 2) を作って、 4 mode 横並びで比較します。

§6.1 再現に求められる 4 つの "ought-to"

§1〜§5 を踏まえて、Reproduce Pipeline が「本来こうあるべき」だが今は出来ていない 4 つの方向性を明示します。 今回の §6 ではこのうち rubric-ground / decompose を本実験に組み込み、verify / iterate は次の一手として開示します。

§6.2 ARA → Pipeline 対応表 — どの提案がどこに入ったか

§4 で並行実験した ARA が出した 4 件の提案を、実 reproduce repo にどう取り込んだかの mapping です。 C-008 / C-010 (evaluator バグ) と H4 + C-011 (Stage 2 prompt scope failure) を ara-fixes / rubric-aware 両 mode に組み込みました。C-007 (code dir selection) は実装規模が大きく今夜は scope 外。

ARA Claim内容取り込み先修正ファイル

§6.3 4 mode 横並び比較

同じ 5 論文を 4 mode で評価しました: baseline (改善前 / main branch) → improved (4 改善 / strengthen branch) → ara-fixes (improved + ARA 3 fix を pipeline に取込) → rubric-aware (ara-fixes + Stage 2 prompt に rubric leaf 要件 checklist を直接注入)。 右側ほど「パイプライン設計の根本介入」が強くなる順で並べています。

5 論文 × 4 mode の hierarchical_score

4 mode の mean (5 論文平均)

各論文の "best mode"

§6.4 学び — どの ought-to が効いたか

§6.5 方法論として残るもの — と重要な caveat

⚠️ Caveat: rubric-aware mode は厳密には "rubric-disclosed reproduction"

rubric-aware mode では、本来 judge が採点に使う rubric.json の leaf 要件を 生成 prompt に事前に注入 しています。これは ML 的な厳密な意味での 「train で test set を使う」(モデルのパラメータを test ラベルで更新する) ではありません — Claude のパラメータは触っていません。 しかし 「採点される項目を agent に事前に見せている」という意味で test-disclosure / spec-disclosure ではあります。 生成側と採点側がさらに 同じモデルファミリ (claude-sonnet-4) なので、表現一致 (same-language matching) も起きやすい。

したがって rubric-aware の絶対スコアを baseline / improved / ara-fixes と単純比較するのは不公平 です。 意味があるのは:

  • ara-fixes vs baseline / improved — rubric-blind 同士の比較。 fix の純粋な効き方を測れる。
  • rubric-aware vs ara-fixes — 「rubric を見せた」効果の大きさを測れる。これが「spec-disclosed agent はどれだけ得をするか」を表す。

benchmark 文脈では、rubric を見せること自体は PaperBench 公式が想定している使い方ではない 可能性が高く、 厳密な leaderboard 比較は ara-fixes 以下のモードでのみ行うべきです。 rubric-aware は「もし spec を渡せたらどこまで上がるか」の上限値推定として読むのが安全です。

それでも残る方法論

「rubric は judge が何を見ているかを agent に教える教科書」: 上記 caveat を踏まえても、Stage 2 prompt に評価 metric の構造を渡すという介入は、 spec-driven / test-driven reproduction という設計原則として残ります。 ユーザが評価基準を持っている 実用シナリオ (社内ドキュメントの再現、契約仕様への準拠) では rubric-disclosure に倫理的問題はありません。

これは Reproduce Pipeline を超えて、AutoRes グループ全体の方法論として転用可能です: Self-Improving Agent が探索する仮説空間にも「測定 metric の構造を agent に教える」フェーズが 同じように使えるはずです。 ただし benchmark 評価では rubric を隠すべき、という線引きを明確に持つ必要があります。

公正な比較に近づけるための次のステップ

§7 次の一手 — まだ着手していないこと

今回のラウンドで進めたのは「最も効きそうな所」「複数論文での測定」「§4 並行実験」「§6 パイプラインレベル介入」。次に取り組むべき項目を正直に列挙します。

近い課題

全 23 論文での測定 本日は 5 論文（小規模）。残り 18 論文（pinn 2551 nodes、lbcs 1471 nodes 等含む）を測定すれば、改善の汎用性を検証できる。
Stage 2 の prompt 改善 現状 architecture が簡略化されすぎ、validation set が欠落、bug 入りコードが生成される。few-shot example + dataset preparation の明示で改善可能。
NRR の Reproduce 統合 Self-Improving Agent で実証済みの NRR（Negative Result Repository）を Reproduce にも組み込み、「同じ環境エラーを二度しない」「失敗した方向の再生成を抑制」を実装。
公式 GPT-4o SimpleJudge への切替 PaperBench 公式は GPT-4o-2024-08-06 を judge に使う。我々は claude-sonnet-4。絶対値の比較可能性を上げるなら切替が必要。コスト約 2 倍。

もう一段先の課題

Full mode 評価 Code-Dev は静的評価。Full mode は実際に実行して数値一致まで検証する。GPU 必要、コストも跳ねる。EnvBench / PRBench との統合的な比較が可能になる。
Stage 3 env builder の本格改善 業界 SOTA でも 7% 未満の成功率。conda + uv の hybrid、CUDA バージョン管理、Docker レス再現性など最大のフロンティア。
Stage 1 を Mistral OCR or Adobe Extract API に pdfplumber でも image-only な Table/Figure は取れない。OCR API への切替で論文の数値抽出精度を上げる。

AutoRes グループとして見据える方向

Reproduce Pipeline 自体を AutoRes の研究エコシステムに組み込み、 「論文発見（Literature Scout） → 再現（Reproduce） → 改善（PaperBench Iter） → 自動探索（Self-Improving）」 の end-to-end ループを 24/365 で回す。各論文の再現結果が NRR に蓄積され、次の探索を方向づける。 これが我々の AI Scientist の最終形です。

§4 の並行実験で「agent にループを閉じさせる」ことの初歩的な手応えが取れたので、 「人間が改善案を考えて実装する」フェーズを、できるだけ早く agent (ARA + research-prime) に渡してしまう のが現実的な経路だと考えています。 ARA が見つけた 4 バグ + H4 を実コードに取り込み、その効果を 5 論文 → 23 論文へと拡大 しながら、ARA の出力を直接 reproduce repo の PR に流す自動橋渡しを作るのが課題です。

この Deep Dive は何のためか

AutoRes グループが取り組んでいる「研究の自動化」のうち、論文再現は最も重要かつ未解決な部分です。 業界全体で end-to-end の数値一致は 0%（PRBench）、環境構築の成功率は < 7%（EnvBench）。 本 Deep Dive は、この絶望的な数字に対して我々の今のラウンドで何ができたか・何が見えたかを正直に共有するものです。

改善前 0.5 → 改善後 X% という結果が、絶対値としては小さくとも、 「複数論文で測定可能な体系」と「正直なボトルネック分析」、そして 「agent に同じ問題を投げて何が返ってくるかを測る」という メタな実験フレーム を AutoRes グループに提供することが目的です。

これは 結果ページ §3 と 手法ページ §3 の続編です。 全体の文脈はそちらをご覧ください。