auto-research

自動リサーチ

このリポジトリで、ユーザーが指定した精度、報酬、スループット、レイテンシ、安定性、またはレシピ固有の別の指標などの目標に対して、NeMo-RL の実験を反復実行し、git を研究記録として使用します。

依存関係は準備済みとして扱いますが、実行環境は慎重に選択してください。信頼できる情報源として、レシピで正式に定められている指標を使用してください。変更は小さく、再現可能で、シンプルに保ってください。無関係なユーザーの作業は保持してください。

安全性： このスキルでは、git ブランチの作成、ディスクへのファイル書き込み、GPU リソースを消費する可能性がある学習ジョブを含むシェルコマンドの実行を行います。ブランチの作成やジョブの起動の前に、必ずキャンペーン計画をユーザーに確認してください。明示的なユーザーの承認なしに、破壊的な git 操作（reset、force-push）を実行したり、計算負荷の高いジョブを起動したりしないでください。

自動リサーチキャンペーンでは、必ず session-memory スキルを使用してください。ブランチを作成する前にセッション記録を開始または再開し、計画を立てた後、重要な編集や長時間実行の開始の前後、ユーザーが方針を変更したとき、引き継ぎまたは最終報告の前に、チェックポイントを記録してください。

コンテキストの圧縮、引き継ぎ、切断、または長い中断の後は、このスキルと、すでに使用している関連スキルを再読み込みし、最新の session-memory の引き継ぎ内容を確認してから、全体の目標、停止条件、現在のブランチ、最新の結果を改めて述べてください。ユーザーが主な目標を明示的に変更しない限り、追加の指示は既存の目標に加えるものとして扱ってください。

ワークフロー

1. 現在の git の状態を確認し、ブランチ作成前に無関係なユーザーの変更を特定します。
2. 共通のブランチプレフィックスを使用します。ユーザーが指定したものを優先し、指定がない場合は autoresearch/2026-03-24-dapo-qwen2p5 のような、内容がわかるデフォルト値を作成します。
3. 対象のレシピ、その親レシピ、examples/run_grpo.py、nemo_rl/models/、nemo_rl/algorithms/、nemo_rl/environments/、docs/ の関連コードパスを確認します。NeMo-gym レシピの場合は、examples/nemo_gym/ のエントリーポイント、設定、起動スクリプトも確認します。
4. ユーザーの停止条件を、監視可能な明示的な値に変換します。たとえば、要求された実験数を target_experiment_count、campaign_deadline、per_experiment_timeout、target_metric として設定します。
5. 必要なデータ、チェックポイント、実行時入力、ランチャーを確認します。
6. 未追跡の TSV ログと、実験ごとのログディレクトリを作成します。
7. 該当するブランチがない場合は、まず <prefix>/baseline でベースラインを実行します。

GPU、CPU 負荷の高い処理、分散処理、または長時間実行する作業では、実行環境を慎重に選択してください。現在のマシンに適切な GPU と空き容量があればローカルで実行します。そうでない場合は、ユーザー指定の環境に従い、nrl-k8s／Kubernetes では launch-nemo-rl を使用し、Slurm では環境標準のランチャーを使用します。それ以外の場合は、起動前にユーザーに確認してください。CPU のみを使うローカル実行は、軽量な調査、ドライラン、短時間の非 GPU チェックに限ります。

ユーザーが Brev に言及した場合、または /home/ubuntu/RL が存在して /ephemeral をボリュームとして利用できる場合は、このマシンを Brev インスタンスとして扱い、実験ディレクトリ、キャッシュ、ログ、チェックポイント、認証済みの実行時状態を作成する前に brev-etiquette を使用します。

ブランチ作成

• 各実験を、共通プレフィックス配下の専用ブランチで実行します。
• 失敗した案や効果の低い案も含め、すべてのブランチを保持します。
• 各ブランチには、仮説を記録するコミットを少なくとも 1 つ作成します。
• 再実行に正当な理由がある場合は、同じブランチに修正コミットを追加します。
• 無関係なユーザーの変更を、通知なしに stash、reset、または上書きしてはいけません。変更済みファイルが実験と重複する場合は、別の worktree を使うか、続行前にユーザーに確認してください。

正確な手順は references/git-workflow.md を参照してください。

ループ

1. 具体的な仮説を1つ選びます。
2. autoresearch/2026-03-24-dapo-qwen2p5/prompt-compact-schema のようなブランチを作成します。
3. 必要最小限のファイルを編集します。
4. 仮説をコミットします。
5. 実行を開始する前に、監視対象の停止条件を確認します。すでに明確に満たされている条件がない限り、早期に停止しないでください。
6. レシピまたはロギングコードから指標の正式な出典を特定し、一意のログパスを指定して実行します。

LOG_DIR=reports/auto_research/<campaign>/<experiment>
mkdir -p "$LOG_DIR"
uv run <entrypoint> > "$LOG_DIR/run.log" 2>&1

7. ユーザーが実験ごとの実時間制限を指定した場合は、明示的に適用します。レシピにタイムアウトがすでに設定されている場合は、レシピレベルのタイムアウトを優先してください。そうでない場合は、外部タイムアウトでコマンドをラップします。両方が設定されている場合は、より厳しい制限に従います。
8. 実際のログ形式に適したコマンドで主要指標を抽出します。抽出結果が空の場合は、実行結果を記録する前に、ログの末尾とレシピのロギングパスを確認します。
9. インデックス、ブランチ、親コミット、コミット、レシピ、指標名、指標値、メモリ（GB）、経過時間（分）、ランチャー、ジョブ ID、コマンド、ログパス、ステータス、説明を TSV に記録します。停止ルールを評価するのに十分な時間または件数の情報も記録してください。
10. キャンペーン中は定期的に、ユーザー向けの進捗状況を表示します。現在のブランチ、直近の既知の結果、試行済みの実験数、該当する場合は残りの実験数、該当する場合はキャンペーンの残り時間、停止条件が満たされているかどうかを含めてください。
11. 実験の完了後に、監視対象の停止条件を再確認し、結果を明確に伝えます。たとえば、stop condition not yet met: 17/24 attempted, 6h12m remaining または stop condition met: 24/24 attempted のように記載します。
12. 結果を keep、discard、crash のいずれかとして記録し、ユーザー指定の停止条件が明確に満たされていない限り、次のブランチに進みます。

件数ベースの停止ルールでは、成功した実験や完了した実験だけでなく、試行したアイデアを数えます。

キャンペーンの時間予算については、キャンペーン開始時にユーザーの制限を絶対期限に換算し、残り時間を継続的に確認します。

実験ごとの予算については、実行ごとにタイムアウトを適用し、制限時間を超えた場合は失敗として扱います。

例：

• do 50 experiments：TSV に試行済み実験の行が50行記録されてから停止します
• 10h total, 1h each：実行ごとに1時間の制限を適用し、10時間のキャンペーン予算に達した場合、または次の実行を開始するだけの予算が残っていない場合に停止します
• 50 experiments or 10h total, 1h each：3つの値すべてを監視し、実行ごとの上限を超えないようにします。キャンペーンレベルの停止条件のいずれかが明確に満たされるまで停止しないでください

優先事項

期待できる目標値の向上が大きく、複雑さのコストが低いアイデアを優先します。

• 正確性とバックエンド互換性
• プロンプトとロールアウトの形式
• バッチ、シーケンス、精度のレイアウト
• オプティマイザーとスケジューラーの調整
• 報酬の形成、クリッピング、スケーリング
• データセットの構成または検証の変更
• ハードウェアに応じた同期実行と非同期実行の選択

他の条件が同じなら、よりシンプルな改善を優先し、壊れやすいハードウェア固有のハックは避けます。

避けるべきこと

• 実行規模が小さいスモークテストだけを根拠に、学習アイデアが失敗したと結論づけないでください。バッチサイズが極端に小さい、オプティマイザーのステップ数が非常に少ない、またはその他の理由で代表的でない設定の実行は、配線確認のみとして扱ってください。仮説を検証する前に、意味のあるバッチサイズに拡大し、十分な時間学習させてください。その後で discard として記録します。
• タイトな編集・実行・デバッグの繰り返しで、バッチスケジューラーのセットアップコストを何度も負担しないでください。Slurm バッチジョブの起動コストが大きく、迅速な反復が必要な場合は、ドキュメントに記載されたインタラクティブな Slurm の手順を使うか、バッチジョブをさらに再投入する前にユーザーに確認してください。
• コンテキストの圧縮や追加の方向性に関する質問によって、元のキャンペーンの目標を失わないでください。session-memory を更新し、有効なスキルを読み込み直し、ユーザーが明示的に変更しない限り、主な目標を維持してください。

停止条件

ユーザーが明示的な停止条件を指定した場合は、一般的なルールよりも優先されます。検索が十分だと感じても停止せず、指定された件数、期限、予算、または目標条件が明確に満たされた場合にのみ停止してください。

キャンペーン中は、停止条件を満たしたかどうかをユーザーに明示的に伝えてください。満たしていない場合は、残りの件数、残り時間、またはその他の残りのしきい値を具体的に報告してください。

ユーザーが明示的な停止条件を指定していない場合は、ベースラインの実行に加えて、リスクの低い実験を最大3件行い、その後、最良の結果を要約して、続行する前に確認してください。

参考資料

• ブランチ、ダーティなワークツリー、親コミット、ベースラインのルールについては、references/git-workflow.md を参照してください。
• 症状を具体的な仮説に変える方法については、references/exploration-ideas.md を参照してください。
• TSV のスキーマと再現性に関する項目については、references/experiment-log-template.md を参照してください。