exp-campaign

Exp Campaign: 観察 → 精査 → 列挙 → 削減 → 段階的実行 → 引き継ぎ → レビュー

実験のための Ponytail：キャンペーンは、証拠が許す限り小さく、主張が求める限り完全であるべきです。 最初から完全要因計画のマトリクスを展開してはいけません。また、次元を黙って削除してはいけません。すべてを列挙してから、結果によって削除を正当化できる低コストのプローブで、削除の妥当性を一つずつ確かめてください。

このスキルが適用される場合

• 複数の分岐、アブレーション、または条件付きの段階的実行が必要な方向性。設定が既知の限定的な分岐が 1 つなら exp-batch、欠けているデータポイントが 1 つなら exp-probe、まだ曖昧なアイデアなら exp-discuss を使います。
• 研究者が明示的に選択した場合は、その選択を優先します。黙って切り替えてはいけません。実験の実行時間ではなく、意思決定ツリーの深さと要因の数で判断します（プローブとバッチのどちらか迷った場合は、バッチを使います）。スキルの指示は英語ですが、成果物はユーザーの言語に従います（デフォルトは中国語です）。

1. 質問する前に観察する

• プロジェクトのメモリ、ダッシュボード、過去の実行、ログ、以前の結論を確認します。すでに分かっていること、存在するベースライン、標準となるメトリクス、現在の証拠がカバーしていない内容を把握します。
• 研究者のアイデアを 2～3 文で言い換えます。検証する主張、説得力のある最終図がどのようなものか、対象範囲外のものを示します。明示的な要件と未解決の質問を分けます。

2. 研究者に詳しく確認する

確定済みの判断によって明らかになった範囲に限り、質問を段階的に行います。それぞれの質問に推奨回答を添えます。調べられる事実は自分で確認し、研究者に尋ねてはいけません。各ラウンドの回答後に質問の範囲を再計算し、次のラウンドの質問をします。ラウンド数に上限はありません。追加の質問によって対象範囲、主張、または受け入れ基準が変わり得るかどうかで、終了するかを判断します。

次の事項を、質問の優先順位に沿って尋ね、明らかにします。

• 主張： 最終的なプロットや表では、具体的に何を示すべきですか？ どの比較結果が出れば、研究者の考えが変わりますか？
• 軸： どの要因が重要ですか（手法、モデル、データセット、精度、シード、lr など）。各要因にはどのレベルがありますか？
• 研究者が見落としている可能性のある詳細： 評価用データの分割、キャリブレーションデータと評価データのリーク、コールバックと再読み込み後のメトリクスの一貫性、シード間のばらつき、退化したベースライン（例：すべて同じ回答に収束する現象）、初期または後期のチェックポイントの選択、プラットフォームや数値演算の等価性。これらは研究者の指定が不十分になりやすいため、明示的に提案します。
• 予算： デバイスの稼働時間、実時間の期限、ストレージ。どの実行を正式なものとし、どの実行を探索的なものとしますか？
• 受け入れ基準： 何を成功、同等、または記録に残す価値のある否定的結果と見なしますか？

実行に不可欠な判断と受け入れ基準に不可欠な判断が確定したら、終了します。質問数のノルマを設けてはいけません。

3. 実験空間を最大限に列挙する

要因 × レベルの完全なマトリクスを表にします。各セルに、次のラベルを 1 つ付けます。

• must-run — 主張がその実行に直接依存します。
• probe-decidable — 低コストの実験で、その行、列、または分岐全体が必要かどうかを判断できます。
• prunable — 既存の証拠によってすでに答えが出ているか、冗長であることが証明されています（根拠を記載します）。

最大限のリストから始めるのは意図的です。削減の過程を見えるようにし、根拠を示すことで、レビュー担当者が検討対象を把握できるようにします。

4. 削減プローブを設計する

プローブで判断可能な各グループについて、最も多くのセルを削除できる最小の実験を設計します。

• パターンの例：2 つの設定でメトリクス A ≈ メトリクス B となる場合（コールバックと再読み込み、dtype のバリエーション、キャッシュモードなど）、残りのマトリクス全体で低コストのほうを採用します。同等性の主張、その証拠、確信度を記録します。
• 各プローブでは、設定、予想コスト、観察内容、そして判断として記述した削減ルールを指定します：if <observed condition> then skip <cells>, else run <cells>。
• プローブ自体も、プロジェクトの実験規約（事前確認、実行 ID、出力レイアウト）に従わなければなりません。プロトコルに違反するプローブからは、安全に有用なことを学べません。

5. 段階的な計画を作成する

散文より表を中心にした、1つのMarkdownドキュメントを作成します。

1. 主張とスコープ — 最終成果物も含めます。メトリクステーブルのスキーマ（行＝実行、列＝メトリクス × サーフェス × 分割）と、図の一覧（各図の軸、曲線群、基準線、データセットごとのレイアウト）を記載します。計画内のすべての実行は、少なくとも1つのセルまたは曲線を埋める必要があります。図に変化をもたらさない実行には、正当な理由が必要です。
2. 現在のエビデンス — すでに測定済みの内容と、その参照先を記載します。
3. 最大規模のマトリクス — §3 のセルごとのラベルを付けます。
4. 観測ゲート付きの段階: Stage 0 のプローブ → 判断ポイント（どの分岐を継続するか）→ Stage 1 のコア実行 → Stage 2 の確認実行（全エポック、独立した再読み込み、正式なプロトコル）。各ゲートについて、正確なコマンド一覧、コストの見積もり、予想される観測結果、各実行におけるリソース／デバイスの指定方法（実行時に読み取った値から選び、明示的に渡し、デフォルトデバイスは使わない）、各結果に応じた分岐表を記載します。計画内のすべての実行は、開始前に exp-batch のプリフライトを通過する必要があります。
5. 枝刈り台帳 — 立てた仮定、それを裏付けるプローブ、確信度を記載します。
6. 失敗への対処 — OOM／NaN／結論が出ない場合／追い出し（近隣ジョブやマシンがカードを取得する）の場合に何をするかを記載します。エビデンスを収集し、最小限に切り分け、黙ってスキップしないでください。これらは想定される失敗のパターンとして挙げ、考えられる失敗をすべて列挙する必要はありません。予期しない失敗はその場で判断して逸脱として記録し、新たなプロセスには移行しません。
7. 成果物: 計画ファイル（プロジェクトの作業ドキュメントディレクトリ。デフォルトは docs/experiments/YYYY-MM-DD-<slug>.md）、各段階につき自己完結型のランチャープロンプト1つ（計画内にコードフェンスで記載し、チャットにも出力）、ゲートの判断を記録した枝刈り台帳、各段階で必須の実行者レポート（<slug>.stage<N>.report.md。exp-batch が作成）、結果を共有ダッシュボード／テーブルに統合する手順。

6. 引き継ぎとレビュー

• 実行はステージまたはブランチごとに、個別のエージェントセッションで行います。 plan-brief と同様に、キャンペーンではステージごとに自己完結したランチャープロンプトを用意します。新しいセッションで計画を読み、exp-batch を採用して、そのステージを実装・実行します。計画セッション内でキャンペーンを実行してはいけません。
• 各ランチャープロンプトには、このステージで埋めるセル、正確な設定とコマンド、メトリクスの契約、停止条件、報告するゲートの観測結果を記載します。実行担当者は、確定済みの判断を再検討せず、計画に従います。証拠によって計画が無効になった場合は、停止して確認を求めます。
• すべてのランチャープロンプトに、待機の取り決めを明記します。 研究者がすでに実行を委任している場合は、その旨を明確に伝えます（「実行を開始し、later ツールを使って無人で待機してかまいません」）。そうでない場合、実行担当のエージェントはステージ開始時に委任を求めます。委任があり、ホストが later ツールを提供している場合、実行担当者は時間のかかるジョブをバックグラウンドで実行し、約10％の余裕を持たせた再開時刻を設定します（プロンプトは次の手順を完全に記述したものにします）。その後、ターンを終了します。ステージのゲート観測結果が揃うまで再開を繰り返し、実行が予定を超過した場合は元の計画を当てにせず、観測された進捗に基づいて見積もり直します。これにより、数時間かかるステージも無人で進められます。これがなければ、実行担当者は長時間の実行のたびに人間の待機が必要になります。
• 正式な実行を誰が開始するかは、計画ではなく研究者が決めます。 実行担当者はコードを実装して事前確認を行います。研究者は正式なコマンドを自分で実行するか、明示的に実行権限を付与します。計画には、どのコマンドが正式なものかを明記する必要があります。
• ステージの報告が戻ったら、次の対応はこのセッションが担います。 報告を運ぶのは研究者なので、自動通知を待ってはいけません。<slug>.stage<N>.report.md を読みます（チャットの記憶ではありません）。すべてのゲートで予測と観測を比較し、プルーニング台帳に判断を記録します（gate N: observed X → keep / skip cells …）。失敗したプローブの前提によって正当化されるセルを再検討し、そのことを明確に伝えます。その後、上書きする事前記述済みのブランチ案を置き換えて、ステージ N+1 のランチャープロンプトを出します。
• 終了： 生き残ったすべてのセルが共有テーブルに行を持ち、図の一覧にある各図をそこから作成できるようになったら、キャンペーンを終了します。計画の冒頭に Status: done (stages: N) と記録し、何をどの証拠に基づいてプルーニングしたかを示し、否定的な結果を研究者に引き渡して、ブランチの追加を停止します。確認ステージ後もゲートで主張が未解決のままなら、ステージを追加せず、未解決の問いを研究者に返します。
• 最終レビュー：メトリクステーブルと図のセットで、当初の主張に答えられていますか？ 否定的な結果や設定の逸脱は明示されていますか？ コールバックと再読み込みの両方のインターフェースがある場合は、それらを使って共有ダッシュボードに公開します。

7. コード構成（ここで計画し、exp-batch で実装）

計画では、後続の各ブランチで一貫性を保てるように、コードをどこに配置するかを決めます。

• モジュールの配置は決定事項として明記します： 各要素が既存のどのモジュールに属するか、実験専用ディレクトリに何を残すかを示します。単一の利用者のために新たな共有抽象化を設けることはしません。一方、2つのブランチが異なる方法で同じファイルを編集することになる場合は、関心事を別々のモジュールに分割します。
• 実験ディレクトリの分離： 各実験に、予測可能なレイアウトの専用ディレクトリを用意します。これにより、名前だけで実行内容を見つけられます（スクリプト、設定、出力は互いに対応する構成にします）。実験が別の実験のディレクトリに立ち入ることはありません。
• 利便性より疎結合： 実験では、既存のインターフェースを通じて安定した共有ライブラリを利用します。実験の都合に合わせて共有ライブラリの内部を変更してはいけません。また、共有ライブラリに実験固有の分岐を追加してはいけません。共有インターフェースに本当に不足がある場合、そのギャップは計画段階で決める事項であり、その場しのぎの編集で済ませてはいけません。
• ポニーテール式の研究コード： 実験を正しく実行するために必要な最小限のコードにします。防御的プログラミングはしません。推測に基づく入力検証、「念のため」の分岐、エラーの握りつぶしは行いません。エラーが発生したら、実際のエラーを出して終了します。事後分析で、修正すべきなのがコードか環境か（デバイスの競合、ディスク容量不足、古いキャッシュ）を判断します。多くの場合、コードはすでに正しく動作しています。

厳守すべき境界

• 削減されたスペースを「実行して失敗した」として示してはいけません。削減とは、「プローブ P により X が判明したため、未実行」を意味します。
• 測定による比較なしに、設定が同等であると計画で主張してはいけません。
• キャンペーン計画は正式な実行を開始する許可ではありません。誰が何を実行するかについて、プロジェクトのルールに従ってください。