Auto Research

Exécutez des expériences NeMo-RL itératives dans ce repository selon l'objectif énoncé par l'utilisateur, tel que la précision, la récompense, le débit, la latence, la stabilité, ou une autre métrique spécifique à la recette, en utilisant git comme journal de recherche.

Traitez les dépendances comme prêtes, mais choisissez le runtime délibérément. Utilisez la métrique autoritative de la recette comme source de vérité. Gardez les changements petits, reproductibles et simples. Préservez les travaux utilisateur non liés.

Utilisez la skill session-memory pour chaque campagne auto-research. Démarrez ou reprenez un enregistrement de session avant de créer une branche, puis enregistrez après la formation du plan, avant et après les édits significatifs ou les lancements longue durée, quand l'utilisateur change de direction, et avant la passation ou le résumé final.

Après compactage du contexte, passation, déconnexion, ou une longue pause, rechargez cette skill et toute skill compagne déjà en cours d'utilisation, lisez la dernière passation session-memory, et réaffirmez l'objectif global, les règles d'arrêt, la branche courante, et le dernier résultat avant de continuer. Traitez les ajustements ultérieurs comme additifs sauf si l'utilisateur change explicitement l'objectif principal.

Workflow

Inspectez l'état git courant et identifiez les changements utilisateur non liés avant de créer une branche.
Utilisez un préfixe de branche partagé. Préférez un fourni par l'utilisateur ; sinon créez un défaut suggestif comme autoresearch/2026-03-24-dapo-qwen2p5.
Lisez la recette cible, ses parents, et les chemins de code pertinents dans examples/run_grpo.py, nemo_rl/models/, nemo_rl/algorithms/, nemo_rl/environments/, et docs/. Pour les recettes NeMo-gym, inspectez aussi les points d'entrée examples/nemo_gym/, les configs, et les scripts de lancement.
Traduisez toute règle d'arrêt utilisateur en valeurs explicites que vous pouvez monitorer, comme le nombre d'expériences demandé en tant que target_experiment_count, campaign_deadline, per_experiment_timeout, ou target_metric.
Vérifiez les données requises, les checkpoints, les entrées runtime, et le lanceur.
Créez un log TSV non suivi et un répertoire log par expérience.
Exécutez d'abord une ligne de base sur <prefix>/baseline si elle n'existe pas.

Pour les travaux GPU, CPU-intensive, distribués, ou longue durée, choisissez l'environnement d'exécution délibérément. Exécutez localement quand la machine courante a des GPUs et une capacité adaptés ; sinon suivez l'environnement demandé par l'utilisateur, utilisez launch-nemo-rl pour nrl-k8s/Kubernetes, utilisez le lanceur natif de l'environnement pour Slurm, ou clarifiez avec l'utilisateur avant de lancer. Utilisez les exécutions locales CPU-only uniquement pour l'inspection légère, les dry runs, et les vérifications courtes sans GPU.

Si l'utilisateur mentionne Brev, ou si /home/ubuntu/RL existe et /ephemeral est disponible comme volume, traitez la machine comme une instance Brev et utilisez brev-etiquette avant de créer des répertoires d'expérience, des caches, des logs, des checkpoints, ou un état runtime authentifié.

Branching

Mettez chaque expérience sur sa propre branche sous le préfixe partagé.
Conservez chaque branche, même pour les idées échouées ou faibles.
Mettez au moins un commit sur chaque branche pour l'hypothèse.
Ajoutez des commits de correction ultérieurs sur la même branche quand une réexécution est justifiée.
Ne cachez jamais, ne réinitialisez jamais, et n'écrasez jamais silencieusement les changements utilisateur non liés. Si les fichiers sales chevauchent l'expérience, utilisez un worktree séparé ou demandez avant de continuer.

Voir references/git-workflow.md pour le modèle exact.

Loop

Choisissez une hypothèse concrète.
Créez une branche comme autoresearch/2026-03-24-dapo-qwen2p5/prompt-compact-schema.
Éditez le plus petit ensemble de fichiers nécessaires.
Commitez l'hypothèse.
Avant de lancer l'exécution, vérifiez les conditions d'arrêt monitorées. N'arrêtez pas tôt sauf si l'une est déjà clairement satisfaite.
Identifiez la source de métrique autoritative depuis la recette ou le code de logging, puis exécutez avec un chemin log unique :

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

Si l'utilisateur a donné une limite de temps mur par expérience, appliquez-la explicitement. Préférez un timeout au niveau recette quand il en existe déjà un ; sinon enveloppez la commande avec un timeout externe. Si les deux existent, respectez la limite plus stricte.
Extrayez la métrique primaire avec une commande appropriée au format log réel. Si l'extraction est vide, inspectez les dernières lignes du log et le chemin de logging de la recette avant de marquer l'exécution.
Enregistrez l'index, la branche, le commit parent, le commit, la recette, le nom de la métrique, la valeur de la métrique, la mémoire (GB), le temps écoulé (minutes), le lanceur, l'ID du job, la commande, le chemin log, le statut, et la description dans le TSV, ainsi que suffisamment d'information de timing ou de compte pour évaluer la règle d'arrêt.
Imprimez périodiquement des mises à jour de progression destinées à l'utilisateur pendant la campagne. Incluez la branche courante, le dernier résultat connu, le nombre d'expériences tentées, le nombre d'expériences restantes le cas échéant, le temps de campagne restant le cas échéant, et si une condition d'arrêt a déjà été satisfaite.
Re-vérifiez les conditions d'arrêt monitorées après que l'expérience soit terminée et énoncez le résultat explicitement, par exemple condition d'arrêt non encore satisfaite : 17/24 tentées, 6h12m restantes ou condition d'arrêt satisfaite : 24/24 tentées.
Marquez le résultat comme keep, discard, ou crash, puis passez à la branche suivante sauf si une condition d'arrêt spécifiée par l'utilisateur a été clairement satisfaite.

Pour les règles d'arrêt basées sur le compte, comptez les idées tentées, non seulement les exécutions réussies ou entièrement terminées.

Pour les budgets temps de campagne, convertissez la limite utilisateur en une date limite absolue au début de la campagne et continuez à vérifier le temps restant.

Pour les budgets par expérience, appliquez un timeout sur chaque exécution et traitez les dépassements comme des échecs.

Exemples :

do 50 experiments : n'arrêtez que après 50 lignes d'expérience tentées dans le TSV
10h total, 1h each : appliquez une limite d'1 heure par exécution et arrêtez-vous quand le budget de campagne de 10 heures est atteint, ou quand il n'y a pas assez de budget restant pour commencer une autre exécution d'1 heure
50 experiments or 10h total, 1h each : monitorez les trois valeurs, ne dépassez jamais le cap par exécution, et arrêtez-vous seulement quand un déclencheur d'arrêt au niveau campagne est clairement atteint

Priorities

Préférez les idées avec un gain objectif attendu élevé et un coût de complexité faible :

correction et compatibilité backend
format du prompt et du rollout
disposition batch, séquence et précision
tuning de l'optimizer et du scheduler
façonnage, clipping, ou mise à l'échelle de la récompense
changements de mélange de dataset ou de validation
exécution synchrone versus asynchrone selon le hardware

Toutes choses égales, préférez les gains plus simples et évitez les hacks hardware-spécifiques fragiles.

Avoid

Ne concluez pas qu'une idée d'entraînement a échoué à partir d'une smoke run sous-alimentée. Si une exécution utilise des batch sizes minuscules, très peu d'étapes optimizer, ou d'autres paramètres non représentatifs, traitez-la comme une validation de plomberie seulement ; montez à l'échelle vers une batch size significative et entraînez assez longtemps pour tester l'hypothèse avant de la marquer discard.
Ne payez pas répétitivement les coûts de mise en place du batch-scheduler pour les boucles edit-run-debug serrées. Si les jobs batch Slurm ont une taxe de démarrage importante et les échecs nécessitent une itération rapide, utilisez le pattern Slurm interactif documenté ou demandez à l'utilisateur avant de resoumetttre plus de jobs batch.
Ne laissez pas le compactage du contexte ou les questions de suivi d'ajustement effacer l'objectif de campagne original. Rafraîchissez session-memory, rechargez les skills actives, et préservez l'objectif principal sauf si l'utilisateur le change explicitement.

Stop

Si l'utilisateur donne des conditions d'arrêt explicites, elles prévalent sur la règle générique. N'arrêtez pas parce que la recherche semble suffisante ; arrêtez seulement quand le compte demandé, la date limite, le budget, ou la condition cible a été clairement satisfait.

Pendant la campagne, informez explicitement l'utilisateur si la condition d'arrêt a été satisfaite. Si non, rapportez le compte restant, le temps restant, ou un autre seuil restant en termes concrets.

Si l'utilisateur ne donne pas de conditions d'arrêt explicites, exécutez la ligne de base plus jusqu'à trois expériences à faible risque, puis résumez le meilleur résultat et demandez avant de continuer.

References

references/git-workflow.md pour les règles de branche, dirty-worktree, parent-commit, et baseline.
references/exploration-ideas.md pour traduire les symptômes en hypothèses concrètes.
references/experiment-log-template.md pour le schéma TSV et les champs de reproductibilité.