baseline-selection-audit

ベースライン選定監査

主張、手法、実験計画案、または文献マップを、査読に耐えるベースラインセットと公平性台帳に変換します。

次のような場合にこのスキルを使用します。

• 実験を計画しているものの、適切なベースラインが明確でない
• 文献レビューで競合手法が見つかったものの、比較対象として整理されていない
• 論文にSOTA、直接的な競合手法、古典的手法、アブレーション用ベースライン、または対照ベースラインが不足している可能性がある
• チューニング、規模、データ、計算量、プロトコル、または指標の違いが不公平だと査読者に指摘されるおそれがある
• 反論書や改訂にあたり、追加で実施する価値のあるベースライン実験を決める必要がある
• 比較可能でないためベースラインを除外する理由を説明する必要がある

引用メタデータの確認にはこのスキルを使用しないでください。BibTeXとLaTeXの正確性には citation-audit を使用してください。主な問題が比較対象の不足ではなく参考文献の不足である場合は、citation-coverage-audit を使用してください。

このスキルは次と組み合わせてください。

• 競合論文のマップが不完全な場合は、このスキルの前に literature-review-sprint を使用します
• 最も近いベースラインによって手法の設計が変わる場合は、algorithm-design-planner を使用します
• 選定したベースラインを具体的な実験マトリクスに落とし込むため、このスキルの後に experiment-design-planner を使用します
• ベースラインの範囲、公平性のルール、中止条件が明確になってから、run-experiment を使用します
• ベースラインの結果が予想外、不安定、または提案手法より優れている場合は、result-diagnosis を使用します
• ベースラインのリスクを論文の主張、図、セクションに関連付ける必要がある場合は、paper-evidence-board を使用します
• ベースラインに関する決定、リスク、アクションをセッション間で保持する場合は、research-project-memory を使用します

スキルディレクトリの構成

<installed-skill-dir>/
├── SKILL.md
└── references/
    ├── baseline-taxonomy.md
    ├── fairness-ledger.md
    ├── memory-writeback.md
    ├── report-template.md
    └── reviewer-risk.md

段階的な読み込み

• 必ず references/baseline-taxonomy.md、references/fairness-ledger.md、references/reviewer-risk.md を読みます。
• 最終監査を作成する前に references/report-template.md を読みます。
• プロジェクトに memory/、コンポーネントの .agent/ フォルダーがある場合、またはユーザーが永続的なプロジェクトメモリを求めている場合は、references/memory-writeback.md を読みます。
• ベースラインセットが現在のSOTA、最近の競合研究、または分野の期待に左右される場合は、ウェブ検索、OpenReview、proceedings、arXiv、PMLR、ACL Anthology、CVF、DBLP、Semantic Scholar、またはユーザー提供の論文を通じて、最新の情報源を確認します。
• 最新情報を確認できない場合は、ベースラインの状況を暫定的なものとして示し、最終的な実験計画の前に必要な追加調査を特定します。

基本原則

• ベースラインは主張を裏付けるためにあり、表を飾るためのものではありません。
• 最も近い概念上の競合手法、最も強い実証的ベースライン、標準的なベンチマークのベースライン、アブレーション用ベースライン、対照ベースラインを区別します。
• ベースラインが不足している理由は、引用のため、比較のため、またはその両方の場合があります。どれに該当するかを明記します。
• 公平性では、データ、モデルサイズ、計算量、チューニング、指標、プロトコル、コードの利用可能性、報告方法を考慮します。
• 考えられるすべてのベースラインを実行するようユーザーに求めてはいけません。査読への影響度と意思決定上の価値に基づいて順位付けします。
• ベースラインを除外するには、根拠を示せる理由が必要であり、多くの場合、引用や制約事項の記述も必要です。
• 強力なベースラインが提案手法を上回ることは、単なる実験の失敗ではなく、プロジェクトにとって重要な情報です。
• 出力は、そのまま experiment-design-planner に引き継げる内容にします。

ステップ1 - 主張と比較対象の範囲を把握する

次の情報を収集します。

• 論文の主張または実験に関する主張
• 提案手法と、分かっている場合は最も近いベースライン
• 対象タスク、データセット、ベンチマーク、指標、プロトコル
• 対象とする投稿先または研究コミュニティの期待
• 既存の結果、論文の表案、または計画中の実験
• 利用可能な場合は、文献レビューの成果
• コードの利用可能性と計算予算
• CLM-###、EVD-###、RSK-###、ACT-### などのプロジェクトメモリID

主張を次の形式に書き換えます。

We need to show that [method] improves [property] over [comparison set] under [task/protocol], without the result being explained by [confound].

これを書けない場合は、research-idea-validator、algorithm-design-planner、または paper-evidence-board に引き継ぎます。

ステップ 2 - 候補ベースラインプールを構築する

以下を使用します。

• 文献レビューの成果
• 引用されている関連研究
• ベンチマークのリーダーボードまたは公式ベースライン
• 対象とする学会・ジャーナルで最近採択された論文
• コードリポジトリまたはモデルのリリース
• 査読者コメント（リバッタルモードの場合）

references/baseline-taxonomy.md を使って、各候補を分類します。

プールには、次を含めます。

• 直接の競合手法
• 現時点で最も強力な手法
• 標準的なベンチマークベースライン
• 古典的なベースライン
• ユーザーの手法の以前のバージョン、または最も近いアブレーション
• 手法なし、または自明な対照ベースライン
• 適切な場合は、オラクル、上限、または診断用ベースライン
• リソースを揃えたベースライン
• 対象分野で期待される分野固有のベースライン

ステップ 3 - ベースライン要件レベルを割り当てる

各候補に、次のいずれかを1つだけ割り当てます。

• must-have：これがないと論文を擁護するのが難しい
• should-have：査読者の信頼を大きく高めるが、省略しても正当化できる場合がある
• optional：有用な参考情報だが、採択への影響は小さい
• not-comparable：関連性はあるが、直接比較には不公平または無効
• citation-only：議論・引用すべきだが、実験は不要

すべての must-have ベースラインに、担当者、実験形式、公平性の制約、および実施できない場合の代替策を設定します。

すべての not-comparable ベースラインについて、理由を示します。

• タスクまたはデータが異なる
• 評価指標に互換性がない
• コードを入手できず、再現に費用がかかりすぎる
• リソースの条件が異なる
• 追加の教師信号またはデータを使用している
• 忠実に再現するのに十分な公開情報がない
• 異なる主張を評価している

ステップ 4 - 公平性を監査する

references/fairness-ledger.md を読みます。

各 must-have および should-have ベースラインについて、次を確認します。

• データ分割と前処理が同じである
• 学習データと追加データの方針が同じである
• モデル規模が同等である、または明示的に規模を統制している
• 計算量が同等である、または計算量で正規化した評価指標を明示している
• チューニングの予算が同等である
• 評価指標とデコーディング／サンプリングのプロトコルが同等である
• 正式なコード、または忠実な再実装を使用している
• 十分な数のシード、信頼区間、または分散の報告がある
• 報告単位が同じである：トークン、例、画像、FLOPs、実時間、NFE、パラメーター数、またはメモリ

公平性を確保できない場合は、次のいずれかを決めます。

• 主張を変更する
• 条件を揃えたサブセット比較を追加する
• 小規模な診断用比較を実施する
• 明確な制約事項を添えて、ベースラインを引用のみとする
• リバッタル時のリスクとして先送りする

ステップ 5 - 査読者からの指摘を予測する

references/reviewer-risk.md を読みます。

欠落している、弱い、または公平でないベースラインごとに、想定される査読者の異議を書きます。

Reviewer could say: [attack].
Severity: fatal / major / medium / minor
Mitigation: run / cite / justify / narrow claim / move to appendix / accept risk

採択への影響に基づいて優先順位を付けます。

• 新規性や比較に関する致命的な懸念
• 必須ベンチマーク／SOTAの欠落
• 不公平なチューニングや計算量
• 弱いアブレーションベースライン
• 不明確なプロトコル
• 対照実験の欠落

ステップ 6 - 実験の引き継ぎ資料を作成する

experiment-design-planner 向けに、次を出力します。

• 選定したベースラインと要件レベル
• 比較表の正確な行
• 記録する公平性台帳の項目
• 評価指標とプロトコルの制約
• アブレーション／対照ベースライン
• 中止条件
• 各ベースラインが答えると想定される査読者の質問
• ベースラインを実施できない場合の代替策

計算リソースに制約がある場合は、段階的な計画を提案します。

1. 査読に最低限耐えうるセット
2. 影響の大きい任意の追加項目
3. 付録に回す、または先送りするベースライン

ステップ 7 - ベースライン監査レポートを作成する

references/report-template.md を読みます。

プロジェクト内に保存する場合、パスが指定されていなければ、次を使用します。

docs/experiments/baseline_selection_audit_YYYY-MM-DD_<short-name>.md

init-python-project / new-workspace によって作成されたコードリポジトリまたはコードワークツリー内で作業する場合は、次を優先します。

docs/reports/baseline_selection_audit_YYYY-MM-DD_<short-name>.md

レポートには、次を含める必要があります。

• 監査対象の主張
• 候補ベースラインプール
• 要件レベルの表
• 公平性台帳
• 査読者からの指摘の予測
• 選定した実験マトリックスの引き継ぎ内容
• 除外したベースラインとその理由
• メモリ更新セクション

ステップ 8 - プロジェクトメモリへの書き戻し

メモリがある場合は、references/memory-writeback.md を読みます。

必要最小限の有用な項目を更新します。

• memory/risk-board.md：ベースラインが不足している、不公平である、利用できない、または比較できないリスク
• memory/evidence-board.md：計画中のベースライン比較とアブレーション
• memory/action-board.md：実装、実行、引用、または正当化に関するアクション
• memory/claim-board.md：ベースラインの実現可能性を踏まえて限定された主張
• memory/decision-log.md：ベースラインを含める、除外する、または段階的に導入するという、長期的に有効な決定
• worktree の .agent/worktree-status.md：ベースライン実装の目的と終了条件
• paper/.agent/：草稿がある場合の表やセクションへの影響

確実性ラベルを使用します。

• verified：一次資料または公式コードに照らして確認済みのベースライン
• user-stated：ユーザーが提示した制約
• inferred：査読者の懸念と公平性に関する判断
• unverified：まだ確認されていない候補

最終確認

最終決定の前に、次の点を確認します。

• 論文中のすべての主張に、直接比較または対照実験が少なくとも 1 つある
• 概念的に最も近い競合手法と、実証的に最も強力なベースラインを混同していない
• must-have のベースラインが明示されている
• 除外したベースラインに、妥当な理由がある
• 公平性に関する制約が、実行できるほど具体的である
• 査読者からの指摘が、査読者の言葉で書かれている
• 出力を experiment-design-planner に直接渡せる
• プロジェクトメモリがある場合は更新されている