tournament-autoresearch

トーナメント型自動リサーチループ

単一の「仮説を立てる」ステップをアイデアトーナメントに置き換えた、ML 自動リサーチループです。 成果物は実験台帳であり、フィードバック信号はトーナメントで勝った変更の実測された <metric> の差分です。 各イテレーション <n> では、ResearchAgent が競合するアーキテクチャ変更を提案し、Judge が批評して順位付けを行い、提案者が改善し、Judge が実行する変更を1 つ選びます。Judge はオーケストレーターであり、自己調整します。実測結果をもとに予測を採点することで、実際に効果のあるアイデアの種類を学習します。実験の仕組み（スナップショット → 実行 → 必須の分析 → 維持／復元）は、関連する ml-autoresearch ループと同じです。

使用する場合

計算リソースを使う前に競合するアイデアを検証し、選択方法を時間とともに改善したい、自由度の高い ML 実験に使用してください。あなたが Judge です。roles/Judge.md の役割を採用し、提案者を roles/ResearchAgent.md で起動してください。デフォルトでは、競合する提案者を <n> 人、改善ラウンドを 1 回とします。アイデアが収束するのが早すぎる場合は、<n> を増やすか、ラウンドを追加してください。事前に決めた単一の実験の実行や、データセットのみを対象とする分析探索には使用しないでください。イテレーションごとに競合しない仮説を 1 つだけ試す場合は、関連する ml-autoresearch ループを使用してください。

登場する役割とファイル（すべてこのフォルダー内）：

• roles/Judge.md — あなたの動作：批評、順位付け、決定、自己調整。
• roles/ResearchAgent.md — 提案者の役割。各ラウンドで <n> 回起動します。
• rubrics/rubric.md — 採点基準（同梱のデフォルト。セットアップ時に作業用コピーを作成します）。
• schemas/idea.schema.json — 提案者が返す内容（提案された変更 1 つ）。
• schemas/verdict.schema.json — Judge が各アイデアについて記録する内容（スコア、順位、決定）。

セットアップ

バインディングを対話形式で解決します。作業ディレクトリに loop.run.yaml がある場合は読み込み、値を 1 行で確認してからループに進みます。ない場合は、Claude Code（AskUserQuestion ツールが利用可能な場合）では各バインディングの妥当な値を推測し、推奨案として提示します。それ以外の環境では、各項目を引用符で囲んだプレーンテキストのプロンプトで質問します。その後、loop.run.yaml（形式は examples/run.example.yaml）を書き込み、ほかのファイルを作成する前に値を確認します。

<host>（claude-code または other）は一度だけ記録します。この値で起動方法を決めます。Claude Code では、提案者ごとに実際の Agent サブエージェントをすべて 1 ターンで起動します。それ以外の場合は、ResearchAgent の役割をインラインで採用し、一度に 1 つずつ提案します。

バインディング	意味	デフォルト	推定方法
<metric>	最適化するスカラー指標	—	コード／README から推定し、方向を確認します
<metric_direction>	minimize または maximize	—	指標の意味から推定します
<run_cmd> / <entrypoint>	実験を最初から最後まで 1 回実行するコマンド	—	pyproject.toml／.venv／README
<editable_files>	ループで編集できるモデル／設定／学習ファイル。評価ハーネスは対象外です	—	モデルと学習スクリプトを探します
<sandbox_root>	スナップショットと台帳の保存場所	./sandbox	—
<iter_strategy>	branches または snapshots	snapshots	git がある場合は branches を提示します
<gate> / <budget>	time（分）または epochs と、その上限	epochs / —	スクリプトから epoch 引数を推定します
<n>	各ラウンドで競合する提案者の人数	3	群が多すぎず競争できる 3 人を推奨します
<refine_rounds>	Judge が決定するまでの提案→批評→改善ラウンド数	1	—

<iter_strategy> が branches の場合は、git checkout -b autoresearch/<run_tag> を実行してブランチを作成します（既存であってはなりません）。 <gate> が time の場合は、<sandbox_root>/run_with_timeout.sh を作成し （timeout $(( <budget> * 60 )) <entrypoint> "$@"）、<budget> の 2 倍の分数で強制終了します。epochs の場合は、編集可能なファイルで epoch 数を上限までに制限します。

サンドボックスを初期化します（確認後）：

<sandbox_root>/
├── loop.run.yaml       ← resolved bindings (written now)
├── results.tsv         ← experiment ledger, header only
├── calibration.tsv     ← Judge predicted-vs-realized ledger, header only
├── judge_lessons.md    ← append-only Judge lessons (header only)
├── rubric.active.md    ← copy of rubrics/rubric.md; the Judge self-refines THIS, never the shipped one
└── iter1/              ← created at loop start

rubrics/rubric.md を <sandbox_root>/rubric.active.md にコピーします。ヘッダーを記述します（台帳を参照）。

ループ

<run_log> = あるイテレーションのトレーニング出力を記録するファイルです（デフォルトは <sandbox_root>/iter<N>/run.log）。<editable_files> 内のすべてのファイルが変更対象です。コードは <budget> 以内に実行を完了する必要があります。シンプルさの基準：メトリクスが同じなら、コードがよりシンプルなものを keep とします。トーナメントでは、各イテレーションで変更を必ず1つだけ選出します。イテレーション1は変更を加えていないベースラインです。トーナメントは行わず、実行と分析を行って、最初の分析サマリーを作成します。

このチェックリストをコピーし、項目にチェックを付けながら、中断されるまで繰り返します。

• 状態。 ブランチ：git log --oneline -5。スナップショット：iter<N>/ が新規作成されたことを確認します。
• トーナメント（iter 2 以降） — Judge として実行します（roles/Judge.md）：提案（<n> 個の ResearchAgent を起動）→ rubric.active.md に照らして批評・採点 → <refine_rounds> 回の改善 → 単独で最高順位の変更を選出します。
• スナップショット／コミット後、変更を適用。
• 分析計画 → iter<N>/analysis/plan.md：採用案の prediction と、却下案から有用な手順を網羅する成果物テーブルを作成します。未測定の観点を少なくとも1行含めます。
• 実行（リダイレクトし、tee は使わない）→ メトリクスを読み取ります。
• 分析 — plan.md の各行を実行 → iter<N>/results/ に保存します。採用案の prediction を検証し、3～8項目のサマリーを作成します。最後は次のラウンドに向けた実証的な根拠で締めくくります。
• 記録 — results.tsv の行と、実測差分および hit を calibration.tsv に記録します。
• 採用または差し戻し（discard を記録する前にシンプルさの基準を適用します）。
• 自己調整（roles/Judge.md）：judge_lessons.md を更新し、rubric.active.md を改善して、的中率を更新します。

各イテレーションの詳細：

1. 状態。 ブランチ：git log --oneline -5。スナップショット：iter<N>/ が新規作成されたことを確認します。
2. トーナメント（iter 2 以降）。 Judge として（roles/Judge.md）、roles/ResearchAgent.md、最新の分析サマリー、schemas/idea.schema.json を渡して <n> 個の ResearchAgent を起動します（<host> によって起動または縮退）。各案を rubric.active.md に照らして批評・採点します。まず条件で判定し（検証可能な prediction がない案は却下し、採点対象外とします）、次に学習シグナルとして各評価軸を個別に0～5点で採点し、バイアスを抑えたペアワイズ比較で順位付けします（各ペアを両方の順序で比較し、一貫した判定だけを採用します）。<refine_rounds> 回改善し、再採点してから、rank == 1 の変更を1つだけ選出します（統合はしません）。案は iter<N>/ideas/ に、各案の判定は1件ずつ iter<N>/verdicts/ に記録し、採用案についてJudgeが予測した結果を calibration.tsv に記録します。
3. スナップショット／コミット後、採用した変更を適用します。 スナップショット：<editable_files> を iter<N>/code_snapshot/ にコピーし、loop.run.yaml を iter<N>/ にコピーしてから、変更を適用します。ブランチ：変更を適用し、git commit -am "<idea_id>: <short description>" を実行します。
4. 分析計画 → iter<N>/analysis/plan.md：採用案の prediction と、却下案から有用な分析手順を含む成果物テーブルを作成します。未測定の観点を少なくとも1行含めます。
5. 実行（<run_log> にリダイレクトし、tee は使わない）→ メトリクスを読み取ります（grep '^<metric>:' <run_log> を実行します。出力が空の場合は tail -n 50 を実行して、簡単な修正を1回だけ試します。それでも解決しない場合は crash として記録します）。
6. 分析 — 実際の成果物が必須です。 plan.md の各行を実行し、iter<N>/results/ にファイルを作成します。不足がないことを確認し、結果を解釈して、採用案の prediction を検証します。3～8項目の分析サマリーを作成し、最後は次のラウンドに向けた実証的な根拠で締めくくります。
7. 記録。 results.tsv に行を追加します（クラッシュ時は 0.000000）。予測に照らして、実測差分と hit を calibration.tsv に追加します。
8. 採用または差し戻し。 改善した場合は keep とし、ベスト記録を更新します。同等、悪化、またはクラッシュの場合は discard／crash とします（ブランチでは git reset --hard HEAD~1 を実行し、スナップショットからは code_snapshot/ を復元します）。discard を記録する前にシンプルさの基準を適用します。
9. 自己調整（roles/Judge.md）：judge_lessons.md を更新し、実測結果に基づいて範囲を限定しながら rubric.active.md（重みと基準値）を改善し、選出の的中率を更新します。
10. ステップ1に戻ります。 決して停止しないでください。 実行を開始したら、「続けてもよいですか？」と尋ねるために一時停止しないでください。ループは手動で中断されるまで続きます。アイデアが尽きた場合は、提案の多様性を高め、results.tsv／calibration.tsv から未探索の方向性を探し、分析をさらに深めてください。

台帳

<sandbox_root> の下にある追記専用ファイルは3つで、すべてタブ区切りです。自由記述にカンマは使わないでください。

results.tsv — 実験台帳（ml-autoresearch と同じ形式）。ヘッダー：

iter	<metric>	status	analysis_summary	description

status は {keep、discard、crash} のいずれかです。例：

iter	val_acc	status	analysis_summary	description
1	0.6320	keep	baseline; grad norms even, no pathologies	baseline
2	0.6890	keep	layer-2 activations near-saturated; BN helped	iter2-a1: add BatchNorm after conv2

calibration.tsv — Judge の実績記録（予測値と実現値）。ヘッダー：

iter	idea_id	grounding	impact	feasibility	pred_direction	pred_magnitude	confidence	realized_delta	hit

例：

iter	idea_id	grounding	impact	feasibility	pred_direction	pred_magnitude	confidence	realized_delta	hit
2	iter2-a1	5	4	4	improve	+2%	high	+0.057	1

judge_lessons.md — 追記専用の説明文で、1回の反復につき1～3個の箇条書きです。どの軸が向上を捉えたか、どのようなアイデアが過大／過小評価されたか、また rubric.active.md を改訂する理由をそれぞれ記録します。例：

## iter 2
- grounding tracked the gain (BN tied to the dead-unit finding hit +0.057, as predicted).
- bumped grounding weight 0.40 → 0.45; tightened the impact anchor (impact=5 picks over-promised).

最後とは限らず、keep のメトリクスが最も高い最良の反復と、累積の選択的中率を報告してください。results.tsv、calibration.tsv、judge_lessons.md、rubric.active.md、iter*/ は未追跡のままにしてください。

制約

• <editable_files> 内のファイルのみ編集してください。編集のたびに事前確認してください。それ以外はすべて（特に評価ハーネス）読み取り専用のグラウンドトゥルースであり、<metric> を定義しています。
• 1回の反復につき変更は1つだけ（トーナメントの勝者）にしてください。アイデアを組み合わせてはいけません。そうすることで、各メトリクスの変化を単一の変更に帰属させられます。
• 検証可能な prediction のないアイデアは、スコアリング前に却下されます。順位は、点単位のスコア（校正にのみ使用）ではなく、バイアスを除去したペアワイズ比較で決定します。
• Judge が編集できるのは作業コピーの rubric.active.md のみです。配布版の rubrics/rubric.md は編集しないでください。
• トレーニングの出力は必ず <run_log> にリダイレクトしてください。出力がコンテキストにあふれるため、tee は使わないでください。
• パッケージをインストールしたり、プロジェクトにない依存関係を追加したりしないでください。ヘルパーコードは標準ライブラリのみを使用してください。
• 評価ハーネスを変更しないでください。また、方向性を尋ねるためにループを一時停止しないでください。
• サンドボックスは自己完結している必要があります。../ による脱出は禁止です。