nemo-rl-auto-research

自动研究

在此仓库中，针对用户说明的目标（例如准确率、奖励、吞吐量、延迟、稳定性或其他特定配方指标），迭代运行 NeMo-RL 实验，并以 git 作为研究记录。

将依赖项视为已就绪，但要审慎选择运行时环境。以配方指定的权威指标作为事实依据。保持改动小、可复现且简单。保留无关的用户工作。

**安全：**此技能会创建 git 分支、将文件写入磁盘，并执行 shell 命令，包括可能消耗 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。

分支管理

• 每项实验都要在统一前缀下的独立分支上进行。
• 保留所有分支，包括失败或效果不佳的实验分支。
• 每个分支至少提交一次，用于记录假设。
• 如果有充分理由重跑，则在同一分支上添加后续修复提交。
• 切勿在未告知的情况下暂存、重置或覆盖无关的用户更改。如果未提交文件与实验改动重叠，请使用独立工作树，或先征求用户同意。

确切操作模式请参见 references/git-workflow.md。

循环

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. 在 TSV 中记录索引、分支、父提交、提交、配方、指标名称、指标值、内存（GB）、耗时（分钟）、启动器、作业 ID、命令、日志路径、状态和描述，并附上足够的计时或计数信息，以便评估停止规则。
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：监控这三项限制，绝不超过单次运行上限；仅在明确达到某个活动级停止条件时停止

优先事项

优先考虑预期目标收益高、复杂度成本低的想法：

• 正确性和后端兼容性
• 提示词和 rollout 格式
• batch、sequence 和 precision 布局
• 优化器和 scheduler 调优
• 奖励塑形、裁剪或缩放
• 数据集混合或验证变更
• 根据硬件选择同步或异步执行

在其他条件相同的情况下，优先选择更简单有效的改进，避免脆弱的硬件专用变通方案。

避免

• 不要因一次规模不足的 smoke run 就认定某个训练想法失败。如果运行使用了很小的 batch size、极少的优化器步数或其他非代表性设置，应将其视为仅用于验证基础流程；应将规模扩大到有实际意义的 batch size，并进行足够长的训练，再将其标记为 discard。
• 对于紧凑的编辑—运行—调试循环，不要反复承担 batch scheduler 的设置成本。如果 Slurm batch 作业启动开销很大，且失败需要快速迭代，请使用文档中说明的交互式 Slurm 模式，或在重新提交更多 batch 作业前询问用户。
• 不要让上下文压缩或后续引导问题抹去原始活动目标。刷新 nemo-rl-session-memory，重新加载当前启用的技能，并保留主要目标，除非用户明确更改目标。

停止

如果用户给出了明确的停止条件，则这些条件优先于通用规则。不要因为搜索感觉已经足够就停止；只有在明确满足所要求的数量、截止时间、预算或目标条件后才能停止。

在整个活动期间，明确告知用户是否已满足停止条件。如果尚未满足，请具体说明剩余数量、剩余时间或其他剩余阈值。

如果用户没有给出明确的停止条件，请先执行基线测试，再进行最多三次低风险实验，然后总结最佳结果并询问是否继续。

参考资料

• references/git-workflow.md，用于了解分支、工作区脏状态、父提交和基线规则。
• references/exploration-ideas.md，用于将症状转化为具体假设。
• references/experiment-log-template.md，用于了解 TSV 架构和可复现性字段。