Skill TAO AutoML

Exécutez l'optimisation automatique des hyperparamètres (HPO) pour tout réseau TAO. L'agent utilise AutoMLRunner — une interface unique qui gère la boucle complète : générer des recommandations, lancer des jobs d'entraînement, extraire les métriques et renvoyer les résultats à l'optimiseur.

Le runner est indépendant de la plateforme — il accepte tout objet implémentant la forme SDK standard (create_job, get_job_status, get_job_logs, get_failure_analysis) et appelle ces méthodes. Choisissez le SDK correspondant à l'endroit où vous voulez que les jobs s'exécutent :

Le multi-nœud par rec fonctionne sur Lepton, SLURM et K8s (chaque rec est un job d'entraînement distribué N-nœuds). Brev et Docker local sont single-host par rec — multi-GPU sur un seul host fonctionne toujours (gpu_count > 1), mais une rec ne peut pas s'étendre sur plusieurs hosts.

Workflow : (1) parser l'intention utilisateur + vérification préalable, (2) sélectionner l'algorithme, (3) configurer et exécuter, (4) surveiller/reprendre/interroger le statut, (5) interpréter les résultats. Chaque étape ci-dessous renvoie vers la référence contenant ses détails complets. Modes d'échec : references/pitfalls.md. Exemples d'échanges : references/examples.md. Détails de configuration : references/prerequisites.md.

Vérification préalable

Ce skill nécessite nvidia-tao-automl (qui tire nvidia-tao-sdk transitivement). Les deux sont sur PyPI public ; les versions épinglées vivent dans versions.yaml (wheels.tao_automl_*), résolues via scripts/resolve_versions_key.py. Choisissez l'extra de plateforme que vous voulez :

python -c "import tao_automl" 2>/dev/null || {
  SB="${TAO_SKILL_BANK_PATH:?}"
  echo "MISSING: nvidia-tao-automl not installed. Pick the platform extra you need:"
  echo "  pip install \"$($SB/scripts/resolve_versions_key.py wheels.tao_automl_lepton)\"      # DGX Cloud / Lepton"
  echo "  pip install \"$($SB/scripts/resolve_versions_key.py wheels.tao_automl_slurm)\"       # on-prem SLURM cluster"
  echo "  pip install \"$($SB/scripts/resolve_versions_key.py wheels.tao_automl_kubernetes)\"  # K8s (EKS / GKE / on-prem)"
  echo "  pip install \"$($SB/scripts/resolve_versions_key.py wheels.tao_automl_docker)\"      # local Docker daemon"
  echo "  pip install \"$($SB/scripts/resolve_versions_key.py wheels.tao_automl_brev)\"        # Brev GPU instances"
  echo "  pip install \"$($SB/scripts/resolve_versions_key.py wheels.tao_automl_all)\"         # all 5 platforms"
  echo "  (append ,llm or ,wandb to the extra for agentic-search or experiment-tracking deps)"
  exit 1
}

(Développement local sur une checkout : pip install -e '~/tao-run-automl[lepton]'.) S'il est manquant, l'agent demande à l'utilisateur d'autoriser l'installation via Bash, puis relance la vérification préalable avant de continuer.

Prérequis

Avant d'exécuter AutoML, satisfaites tous les éléments suivants — le détail complet (filtrage des credentials par plateforme, formats d'URI de dataset, arborescence de la banque et commandes d'installation) est dans references/prerequisites.md :

1. Vérification préalable de lancement partagée — exécutez d'abord le pattern d'intake tao-launch-workflow. AutoML ne doit pas créer de fichiers runner, workspaces, fichiers d'état, logs, shims de compatibilité ou installer de dépendances jusqu'à ce que les credentials de la plateforme sélectionnée, la vérification d'accès, la visibilité du dataset, les credentials du modèle, la confirmation de l'image conteneur et la forme de calcul soient satisfaites. Cela empêche de gaspiller le budget sur des échecs de recommandation factices causés par des problèmes SSH, stockage, image ou credentials.
2. Credentials SDK — variables d'env sourced depuis ~/.config/tao/.env (auto-chargées par le hook SessionStart de la skill bank). Filtrez les variables requises par plateforme avec scripts/list_tao_platforms.py --platform <platform> --format text et ne demandez que ce qu'il énumère (S3 seulement quand les URIs utilisent s3:// ; NGC_KEY pour les pulls de conteneur). L'agent ne lit jamais les valeurs — seulement vérifie la présence avec [ -n "$VAR_NAME" ]. Construisez le SDK sans arguments, par exemple LeptonSDK().
3. Dataset — accessible depuis le backend de calcul ; le format d'URI dépend de la plateforme (s3://... pour Lepton, un chemin partagé absolu pour SLURM, azure://... pour Azure, un chemin local pour Docker ; ne générez jamais aws://...). Acceptez les racines de dataset ou les chemins de spec-key exacts, préservant les clés fournies par l'utilisateur telles que custom.train_dataset.annotation_path= sans forcer les fichiers à partager un répertoire parent.
4. Skill bank disponible — le runner prend un explicit skill_dir (chemin absolu vers <bank-root>/models/<network>, pas de secours env-var). Utilisez la même racine de banque que celle dont l'agent a chargé le workflow. CRITIQUE : AutoML nécessite un <bank-root>/models/<network>/schemas/train.schema.json packagé et valide — c'est la barrière de support AutoML (définit les params automl_enabled, defaults, ranges, options, weights, métadonnées populaires). Le runtime ne doit pas s'attendre à ce que ~/tao-core existe ; si le schema d'entraînement packagé est manquant, ne lancez pas AutoML pour ce modèle. references/spec_template_<action>.yaml est requis pour les modèles non-TAO-Core (cosmos-rl, clip) et optionnel pour les modèles TAO Core / basés sur Hydra (DINO, BEVFusion).
5. nvidia-tao-automl installé avec l'extra de plateforme que vous voulez (PyPI public ; épinglez dans versions.yaml). Utilisez les commandes d'installation du bloc Vérification préalable ci-dessus ou references/prerequisites.md ; ajoutez ,llm à l'extra pour les algorithmes agentiques.

Vérifiez la configuration :

python3 -c "from tao_automl.runner import AutoMLRunner; print('OK')"
python3 -c "from tao_automl.brain.llm_brain import LLMBrain; print('LLM OK')"   # optional, LLM features
python3 -c "import wandb; print('WandB OK')"                                    # optional, WandB

Concepts : Qu'est-ce que TAO AutoML ?

TAO AutoML automatise la boucle « essayer différentes valeurs d'hyperparamètres → entraîner → comparer les résultats → répéter ». Vous lui dites quel réseau (network_arch), quels hyperparamètres chercher (depuis le skill du modèle et le schema), quelle métrique optimiser (depuis le skill du modèle ou la requête utilisateur), et combien de trials (budget). Il choisit ensuite les valeurs d'hyperparamètres avec un algorithme de recherche (Bayésien, Hyperband, LLM, etc.), lance un vrai job d'entraînement sur le backend que le SDK cible, lit la métrique de résultat depuis les logs d'entraînement, la renvoie à l'algorithme pour qu'il apprenne ce qui fonctionne, répète jusqu'à épuisement du budget, et retourne la meilleure configuration trouvée.

Chaque « trial » s'appelle une recommandation (rec). Une rec = un entraînement complet avec un ensemble spécifique d'hyperparamètres.

Requêtes de Support Rapide

Quand l'utilisateur demande quels modèles/réseaux sont supportés pour AutoML, exécutez l'helper de liste-modèles packagé en mode AutoML. L'activation AutoML est au niveau du modèle (skills/models/<network>/references/skill_info.yaml a automl_enabled: true), pas au niveau du workflow. L'helper lit ces métadonnées, puis valide si le modèle a aussi un schema dataclass d'entraînement packagé et analysable :

${TAO_SKILL_BANK_PATH:-~/tao-skills-external}/scripts/list_tao_models.py \
  --skill-bank ${TAO_SKILL_BANK_PATH:-~/tao-skills-external} --scope automl --format text

Le wrapper de compatibilité ci-dessous est aussi valide et délègue à la même logique :

${TAO_SKILL_BANK_PATH:-~/tao-skills-external}/scripts/list_automl_support.py \
  --skill-bank ${TAO_SKILL_BANK_PATH:-~/tao-skills-external} --format text

Retournez les deux sections de cette sortie : modèles AutoML exécutables et modèles activés pour AutoML toujours bloqués sur le packaging du schema. La règle de support : AutoML est activée au niveau du modèle ; runnable AutoML nécessite aussi que skills/models/<network>/schemas/train.schema.json soit packagé et valide.

Étape 1 : Parser l'intention utilisateur

Optez par défaut pour une exécution rapide à moins que l'utilisateur ne demande explicitement de personnaliser AutoML ou n'accepte une offre de personnalisation. Ne présentez pas les choix d'algorithme, budget ou espace de recherche comme des inputs obligatoires pour une demande normale « exécuter AutoML ».

Tout workflow/application qui atteint un skill de modèle capable d'entraînement doit consulter les métadonnées automl_enabled du modèle sélectionné. Si c'est true, utilisez ce workflow AutoML comme chemin d'entraînement par défaut sauf si le paramètre de run/workflow a automl_policy: off ou si l'utilisateur demande explicitement un seul run d'entraînement simple. Cela garde l'activation AutoML scalable sur tao-train-single-step, DEFT et les futurs workflows sans dupliquer les listes blanches dans chaque skill d'application.

Extrayez les inputs du run par défaut et appliquez les defaults du quick-start. La table des champs obligatoires complète (network_arch, platform, dataset URIs / chemins spec directs, image, metric, direction, skill_dir, long_running_enabled, status_interval_minutes, credentials, shape de calcul et le trio endpoint/model/key LLM), les defaults du quick-start (bayesian, 10 recs, hyperparamètres/ranges None, monitoring 5-minute), la checklist friendly launch-intake prompting, les champs customization-only, la shape du runner quick-start et les best practices de choix de métrique vivent tous dans references/intake-and-inputs.md.

Policy de gating clé qui s'applique toujours :

• Si un champ obligatoire est manquant, demandez à l'utilisateur. Ne deviné PAS les chemins de dataset, chemins de skill bank, credentials ou hardware que le skill du modèle marque comme obligatoire.
• image : résolvez le default, montrez-le à l'utilisateur et nécessitez la confirmation ou image=<override> avant de créer le runner AutoML.
• direction : seulement nécessaire quand le nom de la métrique est en désaccord avec la règle implicite « contient 'loss' → minimiser, sinon maximiser ».
• llm_endpoint, llm_model, llm_api_key : DOIT demander pour llm/hybrid/autoresearch ; le default du code https://integrate.api.nvidia.com/v1 retourne 404, donc passez toujours llm_endpoint explicitement.

Avant de générer un script AutoML, vérifiez l'accès à la plateforme et la visibilité du dataset en utilisant la vérification préalable de lancement partagée. Pour SLURM, cela signifie SSH sans mot de passe vers au moins un hôte de connexion et vérifications test -e distantes pour chaque chemin d'annotation/média obligatoire. Vérifiez la confirmation de l'image de conteneur de la même façon — l'image d'entraînement confirmée doit être passée dans AutoMLRunner.run(..., image=chosen_image, ...) ou l'adaptateur SDK create_job(..., image=chosen_image, ...) ; ne comptez pas sur un default implicite. Exécutez aussi toutes les vérifications de contenu d'annotation spécifiques au modèle documentées par le skill du modèle. Si la vérification préalable échoue, arrêtez avec les étapes de remédiation au lieu de créer un runner qui échouera immédiatement. Les champs d'annotation obligatoires manquants sont une failure de vérification préalable, pas une failure de recommandation AutoML.

Gate de personnalisation : Après résolution des champs rapides obligatoires, vous pouvez brièvement offrir une personnalisation. Si l'utilisateur décline, procédez avec les defaults. Si l'utilisateur choisit la personnalisation, présentez les champs customization-only depuis references/intake-and-inputs.md.

OBLIGATOIRE : Lire le schema dataclass généré avant de configurer AutoML. Pour l'action/modèle sélectionné, lisez ${TAO_SKILL_BANK_PATH:-~/tao-skills-external}/models/<network>/schemas/train.schema.json et .../schemas/manifest.json. AutoML ne peut s'exécuter que quand train.schema.json est packagé et valide. Ne tombez pas en arrière sur des notes écrites à la main, vieux scripts de runner ou une checkout locale ~/tao-core. Si le schema est manquant, arrêtez et rapportez qu'AutoML est activé mais non exécutable jusqu'à ce que le schema soit généré et envoyé. Utilisez le schema JSON comme source de vérité pour automl_default_parameters, automl_disabled_parameters, defaults par-paramètre, ranges, enums, option_weights, math_cond, depends_on, parent_param et popular. Quand automl_hyperparameters=None, le runner découvre tous les params marqués automl_enabled=True dans le schema ; chaque réseau a son propre ensemble, ne les hardcodez donc jamais ici.

Les règles OBLIGATOIRES suivantes gâtent chaque run — texte complet, patterns de code et rationale dans references/mandatory-rules.md :

• Demande OBLIGATOIRE pour les algorithmes basés sur LLM (llm, hybrid, autoresearch) — résolvez llm_endpoint, llm_model et llm_api_key avant de générer le script (chaînes de précédence dans la référence). Sans paramètres LLM valides, le brain tombe silencieusement en arrière sur l'échantillonnage aléatoire et gaspille le budget GPU.
• OBLIGATOIRE : Lire le skill du modèle avant de générer le script — lisez <bank-root>/models/<network>/SKILL.md et appliquez ses sections Training Requirements, Per-Action Dataset Requirements, Typical Spec Overrides, AutoML / HPO Notes et Error Patterns. Ne hardcodez pas la connaissance spécifique au modèle.
• OBLIGATOIRE : Pas de constantes spécifiques au modèle dans ce skill AutoML — noms d'hyperparamètres, ranges, defaults, noms de métriques, layouts de dataset, clés d'override spec, images et regex de métriques appartiennent au schema et au skill du modèle, pas ici.
• OBLIGATOIRE : Dossiers de workspace horodatés — suffixez toujours workspace_path avec datetime.now().strftime("%Y%m%d_%H%M%S") ; ne jamais utiliser un chemin plat.
• OBLIGATOIRE : Runner frais par nouvelle requête AutoML, après passage de la vérification préalable — chaque nouvelle requête crée un nouveau script de runner, log, fichier PID, SDK state_file et workspace_path avec un timestamp unique ; seulement reprendre quand l'utilisateur demande explicitement de reprendre/continuer/récupérer/inspecter.

Best-practice sur le choix de métrique : préférez la métrique de validation ou de task recommandée du skill du modèle sur la loss d'entraînement bon marché (qui overfitte sur les petits sets d'affinage) ; quand vous utilisez un proxy de validation, appliquez aussi les spec_overrides obligatoires liés à la validation du skill du modèle pour que la métrique soit émise ; une vraie task metric via eval_fn est la plus honnête mais ajoute du coût par rec. Détails dans references/intake-and-inputs.md.

Étape 2 : Sélectionner l'algorithme

Optez par défaut pour bayesian. Les tables complètes d'algorithmes classiques et LLM/agentiques (use-when, typical budget, how it works), les règles de default/caveat et l'arbre de décision sont dans references/algorithms.md. Présentez le guide d'algorithme seulement en mode personnalisation ou quand l'utilisateur en nomme un.

Étape 3 : Configurer et exécuter

Construisez le runner à partir des formes génériques dans references/automl-settings.md — exemple minimal, exemple complet avec toutes les options, exemple alimenté par LLM, l'API programmatique AutoML, la table de clé automl_settings complète, résolution de métrique kpi, toggles d'environnement analyseur LLM et règles spec_overrides.

• Contraignez l'espace de recherche avec custom_param_ranges : references/custom-param-ranges.md (table de format, exemples, règles d'espace de recherche spécifiques au modèle).
• Opt-in aux hooks metric_extractor / eval_fn et tracking WandB : references/hooks-and-wandb.md.
• Deep dive LLM/agentique — NLConfigGenerator, le LLMAnalyzer standalone, les cinq composants d'agent autoresearch et les programmes de recherche multi-phase : references/nl-config-and-research.md.

Tous les hyperparamètres spécifiques au modèle, extracteurs de métrique et spec_overrides proviennent du skill du modèle.

Étape 4 : Surveiller la progression

runner.run() se bloque jusqu'à ce que toutes les recommandations se terminent ; utilisez les callbacks on_recommendation / on_result pour rapporter la progression. Chaque rec prend 10–90 minutes — ne supposez pas un échec pendant les longs téléchargements. Si l'orchestrateur meurt en milieu de run, relancez avec le workspace_path suffixé complet et resume=True. Vérifiez la progression depuis un processus séparé avec query_status(). Callbacks, comportement de reprise et usage complet de query_status() / get_status() : references/monitoring-and-resume.md.

Étape 5 : Interpréter les résultats

runner.run() retourne un dict simple avec clés best, progress et history ; les valeurs de métrique sont toujours dans l'échelle originale de l'utilisateur. Rapportez la meilleure config, une table de comparaison classée, des insights, le lien WandB s'il est activé, et les prochaines étapes. Forme complète de dict de résultat, checklist de rapportage et triage all-recs-failed : references/results.md.

Notes spécifiques au modèle

Les notes spécifiques au modèle ne appartiennent pas ici. Pour chaque network_arch demandé, lisez <bank-root>/models/<network>/SKILL.md et utilisez ses sections Training Requirements, Per-Action Dataset Requirements, Typical Spec Overrides, AutoML / HPO Notes et Error Patterns comme source de vérité.

Pièges courants

Les 15 modes d'échec récurrents — incluant skill_dir mauvais/manquant, mauvais endpoint LLM (404), failures d'entraînement spécifiques au modèle, collisions de workspace, faibles métriques proxy, le piège de la direction implicite, typos d'override spec, mort de l'orchestrateur en milieu de sweep, configs LLM aléatoires silencieuses, openai manquant, WandB ne loggant pas et buffering conda run — sont documentés avec fixes dans references/pitfalls.md. Examinez-les avant et pendant tout run.

Conversations d'exemple

Représentatives échanges agent/utilisateur pour optimiser un réseau, demander une vraie task metric, recherche guidée par LLM, autoresearch complètement autonome, reprendre, passer à ASHA avec WandB et générer une config à partir d'une description d'objectif : voir references/examples.md.