ablation-planner

アブレーション計画

査読者が尋ねるであろう疑問に答えられるよう、アブレーション研究を体系的に設計します。Codex が査読者の視点で設計を主導し、CC が実現可能性を検討して実装します。

コンテキスト：$ARGUMENTS

使用するタイミング

• 主な結果が /result-to-claim を通過し、claim_supported = yes または partial である
• ユーザーがアブレーション計画を明示的に依頼する
• /auto-review-loop の査読者がアブレーションの不足を指摘する

ワークフロー

ステップ 1：コンテキストを準備する

CC は利用可能なプロジェクトファイルを読み、全体像を把握します。

• 手法の説明と構成要素（idea-stage/docs/research_contract.md、旧 docs/research_contract.md、またはプロジェクトの CLAUDE.md から）
• 現在の実験結果（EXPERIMENT_LOG.md、EXPERIMENT_TRACKER.md、または W&B から）
• 確認済みの主張と意図する主張（result-to-claim の出力またはプロジェクトのメモから）
• 利用可能な計算リソース（存在する場合は CLAUDE.md のサーバー設定から）

ステップ 2：Codex がアブレーションを設計する

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    You are a rigorous ML reviewer planning ablation studies.
    Given this method and results, design ablations that:

    1. Isolate the contribution of each novel component
    2. Answer questions reviewers will definitely ask
    3. Test sensitivity to key hyperparameters
    4. Compare against natural alternative design choices

    Method: [description from project files]
    Components: [list of removable/replaceable components]
    Current results: [key metrics from experiments]
    Claims: [what we claim and current evidence]

    For each ablation, specify:
    - name: what to change (e.g., "remove module X", "replace Y with Z")
    - what_it_tests: the specific question this answers
    - expected_if_component_matters: what we predict if the component is important
    - priority: 1 (must-run) to 5 (nice-to-have)

    Also provide:
    - coverage_assessment: what reviewer questions these ablations answer
    - unnecessary_ablations: experiments that seem useful but won't add insight
    - suggested_order: run order optimized for maximum early information
    - estimated_compute: total GPU-hours estimate

ステップ 3：アブレーション計画を解析する

Codex の応答を構造化形式に正規化します。

## Ablation Plan

### Component Ablations (highest priority)
| # | Name | What It Tests | Expected If Matters | Priority |
|---|------|---------------|---------------------|----------|
| 1 | remove module X | contribution of X | performance drops on metric Y | 1 |
| 2 | replace X with simpler Z | value of learned vs fixed | drops, especially on dataset A | 2 |

### Hyperparameter Sensitivity
| # | Parameter | Values to Test | What It Tests | Priority |
|---|-----------|---------------|---------------|----------|
| 3 | lambda | [0.01, 0.1, 1.0] | sensitivity to regularization | 3 |

### Design Choice Comparisons
| # | Name | What It Tests | Priority |
|---|------|---------------|----------|
| 4 | joint vs separate matching | whether joint adds value | 4 |

### Coverage Assessment
[What reviewer questions these ablations answer]

### Unnecessary Ablations
[Experiments that seem useful but won't add insight — skip these]

### Run Order
[Optimized for maximum early information]

### Estimated Compute
[Total GPU-hours]

ステップ 4：CC が実現可能性を検討する

何かを実行する前に、CC は以下を確認します。

• 計算予算：利用可能な GPU ですべてのアブレーションを実行できるか？
• コードの変更：コードの修正が必要なアブレーションと、設定のみの変更で済むアブレーションはどれか？
• 依存関係：どのアブレーションを並行して実行できるか？
• 削減案：予算が厳しい場合、優先度の低いアブレーションの削除を提案し、Codex に確認を求める

ステップ 5：実装して実行する

1. 各アブレーションの設定ファイル／スクリプトを作成します（まず設定のみの変更から）
2. 本実行の前に、各アブレーションのスモークテストを行います
3. 推奨された順序で実行し、説明的な名前を付けます（例：ablation-no-module-X）
4. 結果を EXPERIMENT_LOG.md に記録します
5. すべてのアブレーションが完了したら、insights を findings.md に反映します

ルール

• 設計は Codex が主導します。Codex が確認する前に、CC がアブレーションのリストを事前に絞り込んだり、偏らせたりしてはいけません。 Codex は査読者のように考え、CC はエンジニアのように考えます。
• すべてのアブレーションに、明確な what_it_tests と expected_if_component_matters を設定する必要があります。「とりあえず試す」だけの実験は禁止です。
• コードの変更が必要なアブレーションよりも、設定のみで行えるアブレーションを優先します（より速く、エラーも起きにくいため）。
• 合計計算量が予算を超える場合、CC は削減案を提示し、Codex に優先順位の見直しを求めます。アブレーションを黙って除外してはいけません。
• ハイパーパラメーターのスイープよりも、構成要素のアブレーション（削除／置換）を優先します。
• ベースラインと同一の構成要素について、アブレーションを生成してはいけません（効果のないアブレーション）。
• 効果のなかった結果も含め、すべてのアブレーション結果を EXPERIMENT_LOG.md に記録します（構成要素を削除しても効果がなかったことは重要な知見です）。