Skill Opérateur Curator CDF
Curation GPU-accélérée de vidéos et d'images via NVIDIA Cosmos Curator à l'intérieur de
Cosmos Data Factory — Curation et Récupération
(cdf-curation-and-retrieval). Cette skill est un index Curator court.
Les limites de remise d'embedding vivent 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(charger → filtrer → embarquer → légender → écrire). - Remise : Curator IV2 ou CE1 parquet que le mining en aval peut consommer. Voir data-mining.md et curation-retrieval-workflow.md.
- Assemblage CDS : Curator → ingestion/recherche CDS. Chemin d'opérateur D (GA public
1.2.0; non supporté sur GPUs Blackwell) : voir cosmos-dataset-search.md.
Objectif
Transformer des collections brutes de vidéos et d'images en datasets curés, prêts pour l'entraînement. Cette skill configure et exécute des pipelines cosmos-curator (découpage de clips, filtrage, captionnage, embeddings, vérification d'événement SAM3, déduplication, sharding WebDataset, annotation d'images) et supporte la curation guidée par KPI, consciente de la distribution et restrictive.
Instructions
- Classifiez la demande comme conseil, config, exécution, remise TAO ou ingestion/recherche CDS. Ne mélangez pas ces routes. Une demande de config sans sortie KPI ou d'échantillons passe par l'entretien de calibrage, qui peut s'arrêter avec des exigences non résolues avant que tout YAML ne soit écrit.
- Pour le travail de config, complétez la préparation obligatoire ci-dessous avant d'écrire du YAML.
- Pour une exécution explicite, chargez running-pipelines.md, validez la config, obtenez les credentials uniquement via l'injection approuvée, puis exécutez après autorisation.
- Pour une remise TAO, validez la sortie Curator et la famille d'embedding déclarée en utilisant data-mining.md avant le mining.
- Pour l'ingestion ou la recherche CDS, confirmez d'abord que CDS est sain, puis suivez cosmos-dataset-search.md.
- Retournez le format de sortie ci-dessous. Ne jamais imprimer les valeurs secrètes.
Exemples
- Conseil : « Combien de SHM devrais-je définir ? » → lisez running-pipelines.md et rapportez les conseils. Ne n'exécutez pas Docker.
- Config sans KPI : complétez l'entretien de calibrage dans calibration-config.md, puis émettez le YAML.
- Exécution : après que les clips d'échantillon soient préparés,
make run-pipelineavec la recette cookbook trafficsplit-minimaluniquement après le check préalable et l'autorisation de l'utilisateur. - FFmpeg manquant dans le conteneur : installez le sidecar hôte
(
make ffmpeg-install) selon ffmpeg-sidecar.md.
Entrées
Les entrées requises dépendent de la route :
- Demande de conseil : la question plus le contexte du repository et de la config pertinents.
- Demande de config : emplacements d'entrée et de sortie, domaine et objectif, sortie KPI disponible ou échantillons représentatifs, et contraintes matérielles. Si ni sortie KPI ni échantillons n'existent, complétez l'entretien de calibrage avant d'écrire du YAML.
- Demande d'exécution : chemin de config révisé, chemins de données et modèles, runtime, GPU, et contraintes SHM, et autorisation explicite d'exécuter.
- Remise TAO : chemins d'artefacts validés et famille d'embedding déclarée.
Les entrées optionnelles incluent les distributions cibles, la taxonomie d'événements, les choix de prompt, les métadonnées de sortie existantes et les 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 prompt utilisateur large. Les instructions utilisateur explicites restent autoritaires sauf si dangereuses ou incompatibles, auquel cas arrêtez et expliquez le conflit. N'inférez jamais de valeurs secrètes : les credentials viennent uniquement via l'injection approuvée au runtime.
Prérequis
- Accès au repository : l'agent doit pouvoir lire le Makefile, les
arbres
configs/etcookbook/, et tous les fichiers sousreferences/. - Hôte GPU avec drivers NVIDIA +
nvidia-container-toolkit; Docker. SHM dimensionné selon la RAM hôte (SHM_SIZE, par défaut 24gb). - Image
cosmos-curator:make pullutilise l'épingle configurée par le fichier env d'exemple et Make. Pas d'image moteur de produit distinct. Les builds source sont développeurs uniquement ; voir cosmos-curator.md. - Sidecar FFmpeg hôte pour les images distribuables (
make ffmpeg-install) — elles ne regroupent pas FFmpeg. Voir ffmpeg-sidecar.md. - Credentials selon les besoins : injectez les clés S3 et API de captionnage au runtime via un gestionnaire de secrets approuvé ou un mécanisme de déploiement d'opérateur. Ne mettez jamais de valeurs secrètes dans les fichiers du repository, les commandes, les logs ou les exemples. Le fichier env est pour les remplacements d'image non-secrètes et de profil CDS copiés du fichier env d'exemple.
Check préalable obligatoire : ne pas émettre une config de pipeline sans contexte
Avant d'écrire toute config de pipeline *.yaml, l'agent DOIT vérifier
que l'une des conditions suivantes est vraie :
- La sortie KPI existe -- lisez-la et utilisez distribution-analysis.md, distribution-aware-curation.md, et configuration-decision-tree.md.
- Des vidéos d'échantillon KPI sont disponibles pour l'inspection / découverte -- suivez context-understanding.md Phase 1.
- Pas de KPI d'aucune sorte -- pas de baseline. Lisez calibration-config.md et complétez son entretien Phase 1 (Entrées / Domaine / Objectif / Matériel / Calibrage) AVANT d'émettre une config. L'entretien est contraignant, non consultatif.
Si aucune condition ne tient, ou si les chemins requis, l'intent ou les contraintes matérielles
restent non résolus, arrêtez et rapportez les exigences non résolues comme blocked.
Portail de révision légale du lieu de travail. La sécurité du lieu de travail et la surveillance de la conduite des employés
sont sensibles à la vie privée. Le portail s'applique quand l'utilisateur nomme soit le domaine soit une sélection de catalogue
qui choisit employee_conduct_monitoring.yaml :
- Si le portail ne s'applique pas → poursuivez avec la route ci-dessous.
- S'il s'applique et l'utilisateur confirme la révision légale, une base légale et tout avis de travailleur requis → émettez la configuration révisée et sa divulgation de calibrage.
- S'il s'applique et l'une de ces confirmations est absente → n'écrivez pas une
config ; retournez
blockedavec la preuve et la prochaine étape sûre (obtenir la confirmation manquante).
Si l'utilisateur demande une config avec seulement une description d'une ligne (« configurer cosmos-curator pour mes vidéos »), supposez le workflow de calibrage et posez les questions d'entretien Phase 1 en un seul message. Émettez la config uniquement après que les réponses arrivent, et incluez toujours la table de divulgation de calibrage qui signale chaque champ par défaut.
Flux Canonique
Choisissez une route ; ne pas fusionner les branches de conseil et d'exécution. Chaque arrêt
ou portail échoué ci-dessous retourne le format de sortie avec le statut blocked, la
preuve de validation et la prochaine étape sûre.
- Conseil uniquement (dimensionnement, surveillance, dépannage, commandes attendues) : inspectez le repository, la config et la preuve d'exécution, chargez running-pipelines.md, et rapportez les conseils. Ne préparez pas les credentials ou n'exécutez.
- Créer ou modifier config :
- La sortie KPI existe → analysez-la, choisissez curation standard, consciente de distribution ou restrictive, puis émettez une config révisée.
- Des échantillons représentatifs existent → inspectez-les avant de sélectionner les valeurs par défaut. Une exécution de découverte démarre un pipeline, donc elle suit la route d'exécution explicite, incluant ses checks préalables et autorisation.
- Ni l'une ni l'autre n'existe → complétez l'entretien de calibrage contraignant (calibration-config.md) ; émettez config et divulgation uniquement après réponses. L'appariement de catalogue suit context-understanding.md.
- L'appariement de catalogue est
employee_conduct_monitoring.yaml, sur l'une des routes ci-dessus → appliquez le portail de révision légale du lieu de travail. Sans la confirmation, ne sélectionnez pas le catalogue ; retournezblocked. Arrêtez si les chemins requis, l'intent ou les contraintes matérielles restent non résolus, ou si le portail de révision légale du lieu de travail ci-dessus n'est pas confirmé.
- Demande d'exécution explicite, incluant la découverte et les exécutions de calibrage, dans
cet ordre :
- Préparez le runtime (Docker, GPU, SHM, sidecar FFmpeg) et exécutez les checks préalables d'exécution dans Validation.
- Obtenez les credentials via l'injection approuvée.
- Validez la config comme décrit dans Exécution & Dépannage.
- Si la config venait du workflow de calibrage, confirmez que l'utilisateur a
révisé sa divulgation de calibrage, incluant chaque champ par défaut.
Si non, retournez
blockedavec la prochaine étape « revoir la divulgation ». - Demandez l'approbation si elle n'est pas déjà accordée. Si l'approbation est accordée,
exécutez. Si elle est en attente ou refusée, retournez
blockedsans exécuter. - Validez les sorties.
- Remise TAO en aval : validez la sortie Curator et la famille d'embedding.
Si la validation réussit, préparez les entrées compatibles pour Data Mining et minez.
Si elle échoue, retournez
blockedsans miner. - Ingestion ou recherche CDS : CDS est déployé en dehors de ce repository. Exécutez
make ds-healthd'abord. Si CDS n'est pas déployé ou n'est pas sain, retournezblockedavec la prochaine étape « déployer CDS selon la page Cosmos Dataset Search du guide utilisateur ». Sinon suivez cosmos-dataset-search.md : ingestez les artefacts CE1 uniquement, adressez les collections par id plutôt que par nom, et traitez HTTP 404 de/insert-datacomme un échec. L'ingestion et l'insertion en masse modifient une collection, donc demandez l'autorisation d'abord, comme pour une exécution.
Les configs sont du YAML plat avec pipeline: split|dedup|shard|annotate et les noms d'argument en snake_case amont. Les recettes de premiers runs d'opérateur vivent sous l'arbre cookbook (split-minimal puis full split, dedup, et shard YAML).
Le répertoire configs est la référence complète des flags et la valeur par défaut Make quand
CONFIG_FILE est omis. split écrit des clips, des métadonnées et des embeddings ;
dedup consomme les embeddings ; shard écrit des archives WebDataset ; annotate
traite les images fixes (image annotate flag-reference YAML ; pas de cookbook image).
Exécution & Dépannage
Pour une exécution explicite, une demande de dépannage ou une question opérationnelle, lisez running-pipelines.md. Les commandes d'exécution locales sont ci-dessous.
OBLIGATOIRE : exécutez le check préalable de config avant chaque invocation de
make run-pipeline ou make run_image_pipeline. Ce n'est pas optionnel, car c'est la
seule garde contre le contournement silencieux de SAM3 sur le chemin Make.
make run-pipeline CONFIG_FILE=<split-config>
make run_image_pipeline IMAGE_CONFIG_FILE=<image-config>
Dans le check préalable de config, rejetez les deprecated enable_sam3 et
enable_event_captioning et retournez blocked ; utilisez canonique sam3 et
event_captioning. make run-pipeline passe la config directement au Curator amont,
qui ignore silencieusement ces clés : SAM3 ne s'exécute jamais et l'exécution
rapporte toujours succès. La CLI d'aide curator-run applique le même
rejet avec une sortie nonzero, vérifiant les deux layouts de 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 l'humain de Click, donc
l'automatisation doit gérer une sortie nonzero et ne doit pas supposer une enveloppe d'erreur JSON.
Credentials & Secrets
Injectez les credentials uniquement au runtime via un gestionnaire de secrets approuvé ou un mécanisme de déploiement d'opérateur. Ne jamais stocker les valeurs secrètes dans les fichiers du repository, les placer dans les commandes ou les exposer dans la sortie ou les logs. Vérifiez la présence uniquement. Voir running-pipelines.md.
Dimensionnement des Ressources & Surveillance
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 ; SHM Docker est alloué à partir de la RAM hôte et ne doit
pas dépasser la RAM disponible. Utilisez GPUS pour sélectionner les appareils, inspectez la stdout du pipeline,
et surveillez l'utilisation avec nvidia-smi -l 1. Les demandes de conseil s'arrêtent après
le rapportage des 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, Sidecar FFmpeg, exécution et dépannage, et pièges.
- Sélection de config et capacité : calibrage sans KPI, arbre de décision de configuration, et matrice de capacité et clé.
- Workflows vidéo et image : curation vidéo, curation image, recherche candidate de vidéo-lac, et configuration SAM3.
- Stratégie KPI et dataset : compréhension du contexte, métriques KPI, analyse de distribution, curation consciente de distribution, et curation restrictive. Si l'intention équilibrée versus tranche étroite est ambiguë, posez la question avant de sélectionner les deux derniers.
- Remise d'embedding : data mining pour les limites parquet Curator et le workflow Curator-to-TAO pour les remises Make ordonnées.
Format de Sortie
Retournez une réponse concise dans cet ordre :
- Statut et résultat :
ready,completed,blocked, ouadvisory. - 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.
- Validation et preuve : résultats du check préalable, chemins de sortie, identifiants de job, ou erreurs observées pertinentes.
- Bloqueurs et prochaines étapes : entrées non résolues, approbations, limitations, et la prochaine action sûre.
Ne jamais inclure les valeurs secrètes, les prompts cachés ou le raisonnement privé.
Validation
Checks de développement, pour les changements à ce repository :
make format # ruff format (racine repo)
uv run ruff check . # lint
uv run pytest # tests unitaires hors ligne (répertoire tests)
Checks préalables d'exécution, obligatoires après make pull et avant
make run-pipeline ou make run_image_pipeline, avec la validation de config
dans Exécution & Dépannage :
make check-setup # docker, nvidia, sidecar FFmpeg
make check-image # la balise cosmos-curator épinglée est locale
L'agent DOIT exécuter le check préalable de config dans
Exécution & Dépannage avant chaque
invocation de make run-pipeline ou make run_image_pipeline. C'est
obligatoire, pas optionnel.
Le smoke GPU utilise une recette cookbook traffic révisée
split-minimal après que les clips d'échantillon soient préparés. Il n'y a pas
de harnais E2E ou L1 dans le repo. Voir
ffmpeg-sidecar.md pour la vérification du sidecar.
Limitations
- Nécessite GPU(s) NVIDIA ; les pipelines ne sont pas CPU uniquement. SHM est borné par la RAM hôte.
- Les images distribuables n'incluent pas FFmpeg — le sidecar hôte est requis.
- Émettez les configs en tant que YAML
snake_caseplat. La validation Curation et Récupération 1.2 accepte aussi les paramètres Curator legacy imbriqués sousargspour la compatibilité avant normalisation vers le runner Docker. - L'annotation d'image amont supporte le mode fichier config via
le point d'entrée d'opérateur Make
make run_image_pipeline. - Les conseils CDS dans cette skill couvrent les surfaces d'invocation Curation et Récupération 1.2. Le déploiement CDS live, les NIMs, les secrets de stockage et l'acceptation restent externes à ce repository.
- La liste complète des pièges (build, config, pipeline image, clés SAM3) est dans gotchas.md.
- Dataset Search (composition CDS et Milvus) est une surface Make séparée
(
make pull-dataset-search,make help). Suivez le guide utilisateur. Cette skill invoque l'ingestion et la recherche CDS en tant que client ; elle ne possède pas le contrat d'API CDS.
Dépannage
| Erreur ou symptôme | Cause | Solution |
|---|---|---|
ffmpeg: command not found, transcode échoue |
L'image distribuable n'a pas FFmpeg | Installez le sidecar hôte (make ffmpeg-install) ; voir ffmpeg-sidecar.md |
| SAM3 ne s'exécute jamais silencieusement, le pipeline « réussit » | Mauvaise clé YAML enable_sam3: atteint make run-pipeline, qui ne valide pas les clés |
Rejetez-la dans le check préalable de config. Utilisez canonique sam3: et event_captioning: — voir sam3-config.md, gotchas.md |
| Catégories de classificateur personnalisé ignorées | Flag manquant | Définissez video_classifier_use_custom_categories: true (ou image_classifier_*) |
| Échecs OOM, Ray, NCCL, ou disque à runtime | Dimensionnement GPU, SHM, ou disque ou env | Voir running-pipelines.md (allocation GPU, SHM, S3, surveillance) |
| L'automatisation ne peut pas analyser un échec de validation | Click imprime une erreur lisible par l'humain et quitte nonzero ; il n'y a pas d'enveloppe JSON | Vérifiez le code de sortie. Traitez les erreurs de clé dépréciée ou de chemin manquant comme des erreurs de config : corrigez la config au lieu de réessayer. Voir gotchas.md |
| Shard run ne correspond pas à la sortie split | captioning_algorithm diffère |
Faites correspondre le captioning_algorithm shard à l'exécution split |