Recettes de Récupération Nemotron

Invocation : $nemotron-retrieval-recipes.

Objectif

Utilise cette skill pour travailler avec les recettes publiques de récupération d'embedding et de reranking Nemotron dans une extraction de source ou un package installé. Préfère l'extraction actuelle à la mémoire, car la CLI de recette, les configs, les containers et les chemins de sortie évoluent activement. Traite chaque famille de recettes comme disponible uniquement après la présence de son répertoire de recettes et des fichiers CLI correspondants.

C'est une skill de produit public, pas une guidance réservée aux contributeurs. Sa valeur par rapport aux docs statiques est de permettre à un agent de router l'utilisateur vers la bonne famille de recettes en cas d'échec de récupération, de concilier les docs avec l'extraction actuelle, d'éviter les lancements accidentellement longs, de préserver les secrets, et de retourner des commandes de preview/exécution/rapport d'exécution concrètes.

Utilise-la uniquement pour des tâches liées au flux public de recettes Nemotron embed ou rerank. Si la requête concerne la théorie générale de la récupération, la sélection générique de bases de données vectorielles, des conseils de benchmarking génériques, ou la résolution de problèmes Docker/Slurm/NIM non liés aux recettes, arrête-toi avec une note de périmètre courte et n'inspecte pas les fichiers de recettes dans ce tour.

Notes de Sécurité

Utilise Bash pour l'inspection, l'aide, les dry-runs et les commandes d'exécution approuvées par l'utilisateur au périmètre du repo. Ne lance pas de travail API, GPU, Docker, Slurm, NIM ou autres travaux longs à moins que l'utilisateur ne le demande explicitement. Ne lance jamais de vidages d'environnement larges ou de commandes qui exposent des valeurs secrètes. Préfère les overrides dotlist et la revue de config à l'édition des valeurs par défaut des recettes.

Priorité des Sources

Résous les conflits dans cet ordre :

Fichiers de recette, CLI, config et source de l'extraction actuelle.
Références regroupées dans cette skill.
Docs ou snippets sauvegardés fournis par l'utilisateur.
Mémoire.

Pour les commandes exécutables, traite l'extraction actuelle comme autoritaire. Si un répertoire de recettes requis, une commande CLI, une config ou un profil env est absent, rapporte le blocage au lieu de deviner.

Prérequis

Environnement repo : uv sync --all-extras ou le plus petit extra pertinent documenté par l'extraction.
SDG Stage 0 : NVIDIA_API_KEY ; ne demande jamais aux utilisateurs de coller des valeurs secrètes.
Travail GPU Stage 1-4 : disponibilité CUDA/driver NVIDIA et VRAM suffisant.
Export Stage 4 : container NeMo Export-Deploy lors de l'utilisation de TensorRT.
Deploy Stage 5 : Docker, accès NGC et NGC_API_KEY.
Exécution distante : profil root env.toml pour --run ou --batch ; charge references/remote.md quand la planification distante, les logs ou le placement GPU comptent.

Instructions

Identifie la famille de recettes.
- Utilise references/embed.md pour embedding, embed, bi-encoder, recherche vectorielle, récupération de première étape, faible Recall@k, documents pertinents manquants, embeddings NIM ou nemotron embed.
- Utilise references/rerank.md pour rerank, reranker, cross-encoder, récupération de deuxième étape, recall acceptable mais mauvais ordonnancement des meilleurs résultats, faible nDCG avec bon Recall ou nemotron rerank.
- Utilise les deux références uniquement quand l'utilisateur demande à propos des deux familles ou demande laquelle choisir.
Choisis le modèle à tuner selon le mode d'échec de récupération.
- Préfère le fine-tuning d'embedding quand les documents pertinents sont absents du set de candidats.
- Préfère le fine-tuning du reranker quand les documents pertinents sont récupérés mais ordonnés mal en haut.
- Pour les stacks de récupération en production, souviens-toi que ce sont des compléments : embed d'abord, rerank des candidats ensuite.
Identifie l'intention : planifier une exécution, exécuter une étape, déboguer un échec, tuner les hyperparamètres, interpréter les métriques, exporter/déployer un modèle, inspecter les configs ou proposer des overrides dotlist.
Inspecte la surface publique actuelle avant d'agir :
- Fichiers de recette : src/nemotron/recipes/<embed|rerank>/
- Fichiers CLI : src/nemotron/cli/commands/<embed|rerank>/
- Configs par défaut : src/nemotron/recipes/<family>/stage*/config/default.yaml
- Aide et dry-runs : uv run nemotron <family> --help, uv run nemotron <family> <stage> -c default -d

Workflow Sûr

Rassemble uniquement le contexte pertinent à la tâche : chemin du corpus, données SDG/training/eval existantes, plage de stage cible, répertoire de sortie, chemin du checkpoint, mode d'exécution, IDs GPU et si les secrets requis sont configurés. Ne demande jamais aux utilisateurs de coller des valeurs secrètes.
Commence par des vérifications bon marché avant le travail coûteux :
- uv run nemotron <family> --help
- uv run nemotron <family> <stage> --help
- uv run nemotron <family> <stage> -c default -d
- uv run nemotron <family> run -c default -d --from <stage> --to <stage>
- run --help peut omettre les options héritées -c et -d même si run -c default -d ... fonctionne ; valide en lançant le dry-run si tu es incertain.
- Dans une extraction déjà préparée, uv run --no-sync ... --help ou uv run --no-sync ... -d peuvent éviter une synchronisation de dépendances inattendue pendant les vérifications en lecture seule.
Vérifie les prérequis pour l'étape demandée :
- Environnement repo : uv sync --all-extras ou le plus petit extra pertinent si documenté par le repo.
- SDG Stage 0 : NVIDIA_API_KEY.
- Travail GPU Stage 1-4 : disponibilité CUDA/driver NVIDIA et VRAM suffisant.
- Export Stage 4 : container NeMo Export-Deploy lors de l'utilisation de TensorRT.
- Deploy Stage 5 : Docker, accès NGC et NGC_API_KEY.
- Exécution distante : profil root env.toml pour --run ou --batch ; charge references/remote.md quand la planification distante, les logs ou le placement GPU comptent.
Utilise les overrides dotlist à la place d'éditer les valeurs par défaut sauf si l'utilisateur demande des changements de config réutilisables. Garde la longueur de séquence, les préfixes, le pooling/normalisation, les templates de prompt et les comptes de hard-negatives cohérents entre les étapes.
Évite de lancer des travaux API, GPU, Docker, Slurm, NIM ou longs à moins que l'utilisateur ne l'ait explicitement demandé. Propose ou lance d'abord les dry-runs, les revues de config et les petits pilots.
Si l'utilisateur spécifie des IDs GPU, étend chaque commande d'étape avec CUDA_VISIBLE_DEVICES=<ids>.
Pour les exécutions multi-étapes locales, préfère uv run nemotron <family> run -c default --from <stage> --to <stage>. La cible run par défaut s'arrête à eval ; export et deploy sont opt-in.
Lors de l'évaluation de la qualité, compare avec le modèle de base sur un set d'évaluation fixe en retrait avant de recommander le déploiement. Ne substitue pas une eval de benchmark public autonome à l'évaluation Stage 3 propre de la recette.
Pour les travaux longs SDG, prep, finetune ou eval, lance le processus d'une manière sûre pour la session et sonde à des intervalles à échelle humaine : environ 60 secondes pour les petits pilots et 120-300 secondes pour les exécutions plus grandes.
En cas d'échec, charge PITFALLS.md, localise l'étape défaillante, puis inspecte la config de l'étape, les entrées attendues, le répertoire de sortie et le wrapper CLI correspondant ou run_uv.py.

Références

references/embed.md : étapes de recette d'embedding, commandes, valeurs par défaut, chemins de sortie et patterns d'utilisation.
references/rerank.md : étapes de recette rerank, commandes, valeurs par défaut, chemins de sortie et patterns d'utilisation.
references/evaluation.md : interprétation des métriques, hygiène de comparaison et vérifications de readiness de déploiement.
references/remote.md : profils d'exécution distante, mode batch/run, scoping GPU, logs et polling.
PITFALLS.md : échecs courants et mouvements de récupération pour SDG, prep, training, eval, export, deploy et configuration CLI.

Exemples

L'utilisateur demande : « Le recall est décent, mais le nDCG est mauvais et le bon passage est autour du rang 40. Dois-je tuner embed ou rerank ? »

Charge references/rerank.md et references/evaluation.md, explique que le recall acceptable avec un mauvais ordonnancement des meilleurs résultats pointe vers le tuning du reranker, puis offre un preview bon marché avant l'entraînement.

uv run nemotron rerank run -c default -d --from prep --to eval

Résolution de Problèmes

En cas d'échec, charge d'abord PITFALLS.md. Localise l'étape défaillante, puis inspecte la config de l'étape, les entrées attendues, le répertoire de sortie et le wrapper CLI correspondant ou run_uv.py.

Limitations

Les références regroupées sont des snapshots condensés ; vérifie les commandes, les flags, les valeurs par défaut et les chemins de sortie par rapport à l'extraction active avant l'exécution.
Cette skill ne fournit pas de datasets, de checkpoints, de credentials, de capacité GPU, d'images Docker ou de services NIM.

Style de Sortie

Pour les recommandations de planification ou de débogage, utilise cette structure quand c'est utile : Decision, Why, Required inputs, Preview command, Execution command, Avoid et Next step. Omets les champs non pertinents pour une réponse courte.

Donne des commandes et des chemins de fichiers concrets. État les hypothèses, les entrées attendues, les sorties attendues et l'étape de validation la moins chère qui prouve que l'action suivante est prête. Pour les étapes longues, sépare les commandes de preview des commandes d'exécution pour que l'utilisateur choisisse délibérément.

Lors de la création d'un rapport de dry-run ou d'exécution réelle, inclus un rapport d'exécution compact : commande, mode, config, overrides dotlist, chemins d'entrée, chemins de sortie, signal de validation ou fichier de métrique et prochaine vérification la moins chère. Inclus le commit d'extraction quand il est disponible.