Skill d'Opérateur Curator PAIDF

Curation vidéo et image accélérée GPU via NVIDIA Cosmos Curator dans Physical AI Data Factory — Curation et Retrieval (paidf-curation-and-retrieval). Ce skill est un index Curator court. Les limites de transmission d'embedding se trouvent dans data-mining.md et curation-retrieval-workflow.md ; l'exécution du mining est make help et les cookbooks du repository.

• Vidéo : split, dedup, shard.
• Image : annotate (load → filter → embed → caption → write).
• Handoff : Parquet Curator IV2 ou CE1 que le mining en aval peut consommer. Voir data-mining.md et curation-retrieval-workflow.md.

Objectif

Transformer les collections vidéo et image brutes en datasets curés et prêts pour l'entraînement. Ce skill configure et exécute des pipelines cosmos-curator (fractionnement de clips, filtrage, captionnage, embeddings, vérification d'événement SAM3, déduplication, WebDataset sharding, annotation d'image) et supporte la curation pilotée par KPI, consciente de la distribution, et restrictive.

Instructions

1. Classifiez la demande en advisory, config, run, ou TAO handoff. Ne mélangez pas ces routes.
2. Pour du travail de config, complétez le pre-flight obligatoire ci-dessous avant d'écrire du YAML.
3. Pour une exécution explicite, chargez running-pipelines.md, validez la config, obtenez les credentials uniquement via injection approuvée, puis exécutez après autorisation.
4. Pour un handoff TAO, validez la sortie Curator et la famille d'embedding déclarée en utilisant data-mining.md avant le mining.
5. Retournez le format de sortie ci-dessous. Ne printez jamais les valeurs secrètes.

Exemples

• Advisory : « Quelle SHM dois-je définir ? » → lisez running-pipelines.md et rapportez les conseils. N'exécutez pas Docker.
• Config sans KPI : complétez l'entretien de calibration dans calibration-config.md, puis émettez du YAML.
• Run : après la mise en scène des clips d'exemple, make run-pipeline avec la recette cookbook traffic split-minimal uniquement après pre-flight et autorisation utilisateur.
• FFmpeg manquant dans le container : installez le sidecar hôte (make ffmpeg-install) selon ffmpeg-sidecar.md.

Entrées

Les entrées requises dépendent de la route :

• Demande advisory : la question plus le repository pertinent et le contexte config.
• Demande config : emplacements d'entrée et de sortie, domaine et objectif, sortie KPI disponible ou exemples représentatifs, et contraintes matérielles. Si ni sortie KPI ni exemples n'existent, complétez l'entretien de calibration avant d'écrire du YAML.
• Demande run : chemin config révisé, chemins données et modèles, runtime, GPU, et contraintes SHM, et autorisation explicite d'exécution.
• Handoff TAO : chemins d'artefacts validés et famille d'embedding déclarée.

Les entrées optionnelles incluent distributions cibles, taxonomie d'événement, choix de prompt, métadonnées de sortie existantes, et contraintes opérationnelles approuvées par l'utilisateur.

Résolvez les entrées dans cet ordre : configuration du repository et artefacts d'exécution validés ; arguments de prompt explicites et corrections ; contexte d'agent disponible ; puis le large prompt utilisateur. Les instructions utilisateur explicites restent autoritaires sauf si dangereuses ou incompatibles, auquel cas arrêtez et expliquez le conflit. Ne déduisez jamais les valeurs secrètes : les credentials ne viennent que de l'injection runtime approuvée.

Prérequis

• Hôte GPU avec drivers NVIDIA + nvidia-container-toolkit ; Docker. SHM dimensionné à partir de la RAM hôte (SHM_SIZE, par défaut 24gb).
• Image cosmos-curator : make pull utilise l'épingle configurée par le fichier env d'exemple et Make. Aucune image de moteur produit séparé. Les builds source sont réservés aux développeurs ; voir cosmos-curator.md.
• Sidecar hôte FFmpeg pour les images distribuables (make ffmpeg-install) — elles ne bundlent pas FFmpeg. Voir ffmpeg-sidecar.md.
• Credentials si nécessaire : injectez les clés S3 et API de captionnage au runtime via un gestionnaire de secrets approuvé ou mécanisme de déploiement d'opérateur. Ne mettez jamais les valeurs secrètes dans les fichiers du repository, les commandes, les logs, ou les exemples. Le fichier env est pour les overrides de profil image et CDS non-secrets copiés depuis le fichier env d'exemple.

Pre-flight obligatoire : N'émettez PAS une config pipeline sans contexte

Avant d'écrire toute config pipeline *.yaml, l'agent DOIT vérifier que l'une des suivantes est vraie :

1. La sortie du run KPI existe -- lisez-la et utilisez distribution-analysis.md, distribution-aware-curation.md, et configuration-decision-tree.md.
2. Des vidéos d'exemple KPI sont disponibles pour inspection / discovery -- suivez context-understanding.md Phase 1.
3. Aucun KPI d'aucune sorte -- aucune baseline n'existe. Lisez calibration-config.md et complétez son entretien Phase 1 (Inputs / Domain / Goal / Hardware / Calibration) AVANT d'émettre une config. L'entretien est contraignant, non advisory.

Si l'utilisateur demande une config avec seulement une description d'une ligne (« configure cosmos-curator pour mes vidéos »), supposez le workflow de calibration et posez les questions d'entretien Phase 1 en un seul message groupé. Émettez la config uniquement après le retour des réponses, et incluez toujours la table de divulgation de calibration qui signale chaque champ par défaut.

Flux Canonique

Choisissez une route ; ne collapasez pas les branches advisory et exécution :

1. Advisory uniquement (dimensionnement, monitoring, dépannage, commandes attendues) : inspectez le repository, la config, et l'evidence d'exécution, chargez running-pipelines.md, et rapportez les conseils. Ne préparez pas les credentials ni n'exécutez.
2. Créer ou modifier une config :
   • La sortie KPI existe → analysez-la, choisissez la curation standard, consciente de la distribution, ou restrictive, puis émettez une config révisée.
   • Des exemples représentatifs existent → inspectez-les ou exécutez la discovery avant de sélectionner les defaults.
   • Ni l'un ni l'autre n'existe → complétez l'entretien de calibration contraignant ; émettez la config et la divulgation uniquement après les réponses. Arrêtez si les chemins requis, l'intention, ou les contraintes matérielles restent non résolus.
3. Demande d'exécution explicite : préparez le runtime → obtenez les credentials via injection approuvée → validez la config et le runtime → demandez l'approbation si pas déjà accordée → exécutez → validez les sorties. Arrêtez avant l'exécution sur tout pre-flight échoué.
4. Handoff TAO en aval : validez la sortie Curator et la famille d'embedding, puis préparez les entrées compatibles pour Data Mining. Minez uniquement après le succès de la validation d'artefact précédente.

Les configs sont du YAML plat avec pipeline: split|dedup|shard|annotate et noms d'arguments snake_case en amont. Les recettes first-run d'opérateur vivent sous l'arborescence cookbook (split-minimal puis full split, dedup, et shard YAML). Le répertoire configs est la full flag reference et le default Makefile quand CONFIG_FILE est omis. split écrit les clips, métadonnées, et embeddings ; dedup consomme les embeddings ; shard écrit les archives WebDataset ; annotate traite les images fixes (YAML de flag-reference image annotate ; pas de image cookbook).

Exécution & Dépannage

Pour une exécution explicite, demande de dépannage, ou question opérationnelle, lisez running-pipelines.md. Les commandes locales préférées sont :

make run-pipeline CONFIG_FILE=<split-config>
make run_image_pipeline IMAGE_CONFIG_FILE=<image-config>

La validation de config est obligatoire avant l'exécution. Rejetez les enable_sam3 et enable_event_captioning dépréciés ; utilisez les canoniques sam3 et event_captioning. PAIDF v1.1 valide les deux layouts config supportés par Curator (paramètres plats ou paramètres imbriqués sous args) avant de construire le runner Docker. Les échecs de validation utilisent la sortie d'erreur lisible par humain de Click, donc l'automatisation doit gérer une sortie non-zéro et ne pas supposer d'enveloppe d'erreur JSON.

Credentials & Secrets

Injectez les credentials uniquement au runtime via un gestionnaire de secrets approuvé ou mécanisme de déploiement d'opérateur. Ne stockez jamais les valeurs secrètes dans les fichiers du repository, ne les placez pas dans les commandes, et ne les exposez pas dans la sortie ou les logs. Vérifiez la présence uniquement. Voir running-pipelines.md.

Dimensionnement des Ressources & Monitoring

Voir running-pipelines.md pour la sélection GPU vérifiée-source, le dimensionnement SHM, les logs, le profiling, et le dépannage. Cette branche définit par défaut SHM_SIZE à 24gb ; la SHM Docker est allouée à partir de la RAM hôte et ne doit pas dépasser la RAM disponible. Utilisez GPUS pour sélectionner les appareils, inspectez le stdout du pipeline, et monitoring l'utilisation avec nvidia-smi -l 1. Les demandes advisory s'arrêtent après le rapport de conseils.

Divulgation Progressive

Chargez uniquement les références directement liées nécessaires pour la route sélectionnée :

• Runtime, image, et framework : Cosmos Curator, FFmpeg sidecar, exécution et dépannage, et gotchas.
• Config et sélection de capacité : calibration sans KPI, arbre de décision de configuration, et matrice de capacité et clés.
• Workflows vidéo et image : curation vidéo, curation image, recherche de candidat video-lake, et configuration SAM3.
• Stratégie KPI et dataset : compréhension du contexte, métriques KPI, analyse de distribution, curation consciente de la distribution, et curation restrictive. Si l'intention balanced versus narrow-slice est ambiguë, demandez avant de sélectionner les deux dernières.
• Handoff d'embedding : data mining pour les limites parquet Curator et workflow Curator-vers-TAO pour les handoffs Make ordonnés.

Format de Sortie

Retournez une réponse concise dans cet ordre :

1. Statut et résultat : ready, completed, blocked, ou advisory.
2. Actions et artefacts : commandes proposées ou exécutées et fichiers créés ou modifiés ; omettez les sections qui ne s'appliquent pas.
3. Validation et evidence : résultats de pre-flight, chemins de sortie, identifiants de job, ou erreurs observées pertinentes.
4. Blockers et prochaines étapes : entrées non résolues, approbations, limitations, et l'action sûre suivante.

Ne jamais inclure les valeurs secrètes, prompts cachés, ou raisonnement interne.

Validation

make format                    # ruff format (racine du repo)
uv run ruff check .            # lint
uv run pytest                  # tests unitaires offline (répertoire tests)
make check-setup               # docker, nvidia, FFmpeg sidecar
make check-image               # la balise cosmos-curator épinglée est locale

Après make pull, exécutez ces preflights. Le smoke GPU utilise une recette cookbook traffic split-minimal révisée après la mise en scène des clips d'exemple. Il n'y a pas de harness E2E ou L1 dans le repo. Voir ffmpeg-sidecar.md pour la vérification du sidecar.

Limitations

• Requiert GPU(s) NVIDIA ; les pipelines ne sont pas CPU-only. SHM est borné par la RAM hôte.
• Les images distribuables ne bundlent pas FFmpeg — le sidecar hôte est requis.
• Émettez les configs en YAML plat snake_case. La validation PAIDF v1.1 accepte aussi les paramètres Curator hérités imbriqués sous args pour la compatibilité avant normalisation au runner Docker.
• L'upstream image annotate supporte le mode fichier-config via l'entrypoint d'opérateur Make make run_image_pipeline.
• La liste complète des pièges (build, config, image pipeline, clés SAM3) est dans gotchas.md.
• Dataset Search (CDS et Milvus compose) est une surface Make séparée (make pull-dataset-search, make help). Suivez le guide utilisateur. Ce skill ne possède pas l'ingest CDS ni les requêtes de recherche.

Dépannage