Auto Research

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

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

Sécurité : Cette compétence crée des branches git, écrit des fichiers sur le disque et exécute des commandes shell incluant des travaux d'entraînement qui peuvent consommer des ressources GPU. Confirmez toujours le plan de campagne auprès de l'utilisateur avant de créer des branches ou de lancer des jobs. N'exécutez pas d'opérations git destructrices (reset, force-push) ni ne lancez de jobs gourmands en ressources sans approbation explicite de l'utilisateur.

Utilisez la compétence nemo-rl-session-memory pour chaque campagne auto-research. Lancez ou reprenez un enregistrement de session avant de créer une branche, puis faites un checkpoint après la formation du plan, avant et après les modifications significatives ou les lancements longue durée, quand l'utilisateur change de direction, et avant la passation ou le résumé final.

Après compaction de contexte, passation, déconnexion ou un long délai, rechargez cette compétence et toute compétence compagnon déjà en usage, lisez la dernière passation nemo-rl-session-memory, et réaffirmez l'objectif global, les règles d'arrêt, la branche actuelle et le dernier résultat avant de continuer. Traitez la direction de suivi comme additive sauf si l'utilisateur change explicitement l'objectif principal.

Workflow

Inspectez l'état git actuel 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 par défaut suggestif tel que 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, configs et scripts de lancement de examples/nemo_gym/.
Traduisez toute règle d'arrêt utilisateur en valeurs explicites que vous pouvez surveiller, telles que le nombre d'expériences demandé comme 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 launcher.
Créez un log TSV non suivi et un répertoire de log par expérience.
Exécutez d'abord une baseline sur <prefix>/baseline si elle n'existe pas.

Pour les travaux GPU, CPU-intensifs, distribués ou longue durée, choisissez l'environnement d'exécution délibérément. Exécutez localement si la machine actuelle dispose de GPUs et de capacité appropriés ; sinon suivez l'environnement demandé par l'utilisateur, utilisez launch-nemo-rl pour nrl-k8s/Kubernetes, utilisez le launcher natif de l'environnement pour Slurm, ou clarifiez avec l'utilisateur avant de lancer. Utilisez les exécutions locales CPU-seul seulement 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 en tant que volume, traitez la machine comme une instance Brev et utilisez nemo-rl-brev-etiquette avant de créer des répertoires d'expériences, 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é.
Gardez 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 de suivi sur la même branche quand une réexécution est justifiée.
Ne masquez jamais, ne réinitialisez jamais et ne remplacez jamais les changements utilisateur non liés silencieusement. Si les fichiers modifiés chevauchent l'expérience, utilisez une worktree distincte ou demandez avant de procéder.

Consultez references/git-workflow.md pour le motif exact.

Loop

Choisissez une hypothèse concrète.
Créez une branche telle que autoresearch/2026-03-24-dapo-qwen2p5/prompt-compact-schema.
Éditez le plus petit ensemble de fichiers nécessaires.
Committez l'hypothèse.
Avant de lancer l'exécution, vérifiez les conditions d'arrêt surveillées. N'arrêtez pas prématurément sauf si l'une d'elles est déjà clairement atteinte.
Identifiez la source de métrique autoritaire depuis la recette ou le code de logging, puis exécutez avec un chemin de 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 de la recette s'il existe déjà ; sinon enveloppez la commande avec un timeout externe. Si les deux existent, honorez la limite la plus stricte.
Extrayez la métrique primaire avec une commande appropriée pour le format de log réel. Si l'extraction est vide, inspectez les dernières lignes de 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 (Go), le temps écoulé (minutes), le launcher, l'ID du job, la commande, le chemin du log, le statut et la description dans le TSV, ainsi que suffisamment d'informations de timing ou de décompte pour évaluer la règle d'arrêt.
Imprimez périodiquement des mises à jour de progression orientées utilisateur pendant la campagne. Incluez la branche actuelle, 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é atteinte.
Revérifiez les conditions d'arrêt surveillées après que l'expérience soit complète et énoncez le résultat explicitement, par exemple condition d'arrêt non encore atteinte : 17/24 tentées, 6h12m restantes ou condition d'arrêt atteinte : 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 clairement été atteinte.

Pour les règles d'arrêt basées sur le compte, comptez les idées tentées, pas seulement les exécutions réussies ou complètement achevées.

Pour les budgets de 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 :

faire 50 expériences : arrêtez seulement après que 50 lignes d'expérience tentées existent dans le TSV
10h total, 1h chacune : appliquez une limite d'1 heure par exécution et arrêtez quand le budget de campagne de 10 heures est atteint, ou quand il n'y a pas assez de budget restant pour lancer une autre exécution d'1 heure
50 expériences ou 10h total, 1h chacune : surveillez les trois valeurs, ne jamais dépasser le plafond par exécution et arrêtez 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
formatage des prompts et rollouts
disposition batch, séquence et précision
réglage des optimiseurs et planificateurs
façonnage, clipping ou mise à l'échelle des récompenses
changements de mélange ou validation de dataset
exécution synchrone versus asynchrone basée sur le matériel

Toutes choses égales par ailleurs, préférez les victoires plus simples et évitez les hacks fragiles spécifiques au matériel.

Avoid

Ne concluez pas qu'une idée d'entraînement a échoué à partir d'une exécution de fumée insuffisamment puissante. Si une exécution utilise des tailles de batch très petites, très peu d'étapes d'optimiseur, ou d'autres paramètres non représentatifs, traitez-la comme validation de plomberie seulement ; mettez à l'échelle vers une taille de batch 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 configuration du planificateur batch pour des boucles étroites edit-run-debug. Si les jobs batch Slurm ont une grande taxe de démarrage et les défaillances nécessitent une itération rapide, utilisez le motif Slurm interactif documenté ou demandez à l'utilisateur avant de resoumettre plus de jobs batch.
Ne laissez pas la compaction de contexte ou les questions de direction de suivi effacer l'objectif de campagne original. Rafraîchissez nemo-rl-session-memory, rechargez les compétences 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 remplacent la règle générique. N'arrêtez pas parce que la recherche semble suffisante ; arrêtez seulement quand le compte, la date limite, le budget ou la condition cible demandés ont clairement été atteints.

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

Si l'utilisateur ne donne pas de conditions d'arrêt explicites, exécutez la baseline 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 transformer les symptômes en hypothèses concrètes.
references/experiment-log-template.md pour le schéma TSV et les champs de reproductibilité.

nemo-rl-auto-research