mcpField
E
experiment-design

experiment-design

github.com/jurgendnデータ・データベース1172 回インストール6 週間前に更新
リポジトリ

experiment-design について

experiment-design は、実験の計画と問題の切り分けを支援するスキルで、仕組みが機能するかを検証し、次の判断を行う研究者向けです。仮説、ベースライン、指標、判断基準の事前定義を求め、スケーリング則のフィッティングスクリプトも備えます。

主な機能

  1. 01仮説を反証可能な形で記述
  2. 02ベースライン、指標、交絡要因を定義
  3. 03健全性チェックと判断基準を設定
  4. 04コスト順に実験を並べる
  5. 05調整前にデータ経路を監査
  6. 06スケーリング則をフィットして外挿

活用シーン

  1. 01研究上の主張を検証する最小実験の計画
  2. 02学習や検証結果の異常の診断
  3. 03データ量や計算量の変更効果の比較
  4. 04事前基準に基づく継続・中止の判断

インストール

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

$npx skills add https://github.com/jurgendn/agent-skills --skill experiment-design

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

同梱ファイルreferences/experiment-design-checklist.mdscripts/fit_scaling_law.py

詳細

実験設計

不確実性を意味のある形で減らせる、最小の実験を設計します。目標はベンチマークで最高の性能を達成することではなく、主張されているメカニズムが機能するかどうかを判断することです。

詳細なチェックリストについては、references/experiment-design-checklist.md をご覧ください。

ワークフロー

  1. 仮説を反証可能な形で述べます。
  2. 仮説を検証できる最小限の実験を定義します。
  3. 公平なベースラインを定義します。
  4. 主要指標と副次指標を定義します。
  5. 交絡要因と対照条件を特定します。
  6. 必須の妥当性チェックを追加します。
  7. 実行前に判断基準を定義します。
  8. 最も低コストなものから最も高コストなものへ、実行順を推奨します。

必須の設計項目

  • 仮説： 何が、何と比べて、どの条件で変化し、どのように測定されるのか。
  • データセット／環境： 出典、分割、データ漏洩の防止、サンプルサイズ。
  • 介入： 提案手法によって何が変わり、何が固定されるのか。
  • ベースライン： 最も強力で公平な比較対象と、単純な下限。
  • 指標： 主張に結び付いた主要指標、トレードオフを測る副次指標。
  • 交絡要因： 計算量、パラメーター数、データ漏洩、前処理、プロンプト／テンプレートの影響。
  • 判断基準： 継続／修正／中止のしきい値。

妥当性チェック

  • 小さなバッチや単純なケースに過適合させます。
  • 指標の実装を検証します。
  • 確率性が影響する場合は、シードによる安定性を確認します。
  • ベースラインで既知の動作を再現できることを確認します。
  • 代表的な成功例と失敗例を調べます。

実行がうまくいかないとき

設計で扱うのは、これから計画する実行です。ここでは、すでに問題が発生した実行を扱います。 チェックリストよりも、順序のルールのほうが重要です。モデルを疑う前にデータの経路を確認し、ハイパーパラメーターに手を加える前に症状を分類してください。

  1. 症状を分類します — 発散、過学習、未学習、崩壊、学習停止、または検証のばらつき。曲線の形状を設定とデータに照らし合わせるまでは、診断とはいえません。
  2. まずデータの経路を監査します。 分割、重複、汚染、ラベルの意味、前処理、データ拡張、学習／テスト間の不一致を確認します。疑わしい損失よりも、疑わしい改善のほうがデータ漏洩の確認を優先する価値があります。出来すぎている結果は、たいてい実際に出来すぎています。確認されたデータ漏洩と、データ漏洩の可能性があるものは区別してください。
  3. その後にのみ調整し、メカニズムごとに調整します — 最適化、正則化、モデル容量、データ／サンプリング、スケジュールのうち、一度に変更するのは1つのメカニズムだけにします。手当たり次第のグリッド探索より、知見に基づく限定的な探索を優先してください。
  4. 採用する数値すべてについて、来歴を記録します。 設定の異なる実行結果をまとめて1つの結論にせず、実行結果で裏付けられるまでは、印象は印象として明記してください。
スケーリングに関する問い

（データ、パラメーター、計算量を）増やすことが望ましい結果につながるかどうかを問う場合は、両対数プロットを目視するのではなく、モデルを当てはめてください。 scripts/fit_scaling_law.py は、べき乗則と下限付きべき乗則（Kaplan／Chinchilla）を当てはめ、指数と R² を報告し、外挿を行って、収益逓減の転換点を示します。

python scripts/fit_scaling_law.py \
  --x 1e6 2e6 4e6 8e6 1.6e7 --y 3.10 2.84 2.63 2.48 2.37 \
  --metric "val loss" --lower-better --extrapolate 6.4e7
python scripts/fit_scaling_law.py selftest   # verify the install

軸は一度に1つだけ変え、アーキテクチャファミリーと評価条件は固定してください。また、最大規模の実行を約10倍超える外挿は、測定結果ではなく、より大きな実行を1回行って検証する仮説として扱ってください。R² が約0.9を下回る場合は、べき乗則が成り立たない可能性を述べ、遠くまで外挿しないでください。

ルール

  • 判断基準のない大規模な実験は、設計された実験とはいえません。
  • ベースラインは、それを上回ることに意味があるほど強力でなければなりません。
  • 事後的にテストに関する主張を定義するために、検証結果を使わないでください。
  • 実験で仮説を反証できない場合は、設計し直してください。
  • データの経路を確認する前に、モデルを脆弱だと決めつけないでください。
  • ハイパーパラメーターを手当たり次第に試すのではなく、まず症状と原因を切り分けてください。

出力

以下を返してください。

  • 仮説
  • 最小限の実験
  • ベースライン
  • 指標
  • リスク／交絡要因
  • 妥当性チェック
  • 実行順
  • 判断基準
  • 適用範囲の限界

コメント

Markdown 対応