nemo-rl-auto-research

自動リサーチ

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

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

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

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

コンテキストが圧縮された後、引き継ぎ後、接続が切れた後、または長い中断の後は、このスキルと、すでに使用中の関連スキルを読み込み直してください。最新の nemo-rl-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 インスタンスとして扱い、実験ディレクトリ、キャッシュ、ログ、チェックポイント、認証済みの実行時状態を作成する前に nemo-rl-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時間の予算に達したとき、または次の1時間の実行を開始するだけの時間が残っていないときに停止します。
• 50 experiments or 10h total, 1h each：3つすべての値を監視し、実行ごとの上限を超えないようにします。キャンペーンレベルの停止条件のいずれかを明確に満たした場合にのみ停止します。

優先事項

期待される目的関数の改善幅が大きく、複雑さによるコストが低いアイデアを優先します。

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

ほかの条件が同じであれば、シンプルに成果を上げられる方法を優先し、壊れやすいハードウェア固有の回避策は避けます。

避けること

• 実験の規模が小さすぎるスモークテストだけで、学習アイデアが失敗したと結論づけないでください。バッチサイズが極端に小さい、オプティマイザーのステップ数が非常に少ない、または設定が代表的でない場合は、配線の検証としてのみ扱います。仮説を検証する前に、実用的なバッチサイズに拡大し、十分な時間学習させてください。そのうえで discard と評価します。
• 編集・実行・デバッグを短いサイクルで繰り返す際に、バッチスケジューラーのセットアップコストを何度も負担しないでください。Slurm のバッチジョブの起動に時間がかかり、障害時にすばやい反復が必要な場合は、文書化されているインタラクティブ Slurm の手順を使うか、バッチジョブを再投入する前にユーザーに確認してください。
• コンテキストの圧縮や追加の誘導質問によって、元のキャンペーンの目的が失われないようにしてください。nemo-rl-session-memory を更新し、アクティブなスキルを再読み込みして、ユーザーが明示的に変更しない限り、主目的を維持してください。

停止条件

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

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

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

参考資料

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