cdf-curation-and-retrieval

Par nvidia · skills

Curation et récupération NVIDIA CDF. Pipelines vidéo et image Cosmos Curator (split, dedup, shard, annotate) avec filtrage, captioning et embedding. Ingestion, recherche et qualification des capacités Cosmos Dataset Search. Embeddings TAO data mining et correspondance par voisinage. Fournit des catalogues d'événements de domaine, notamment la surveillance du comportement des employés en milieu de travail, qui nécessite une révision juridique avant utilisation. À utiliser lorsqu'une requête mentionne Cosmos Curator, Cosmos Dataset Search, CDF, ou leurs interfaces Make et CLI. Non destiné à l'entraînement de modèles, à l'orchestration, ou aux questions sans rapport avec les datasets.

npx skills add https://github.com/nvidia/skills --skill cdf-curation-and-retrieval

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

  1. 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.
  2. Pour le travail de config, complétez la préparation 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 l'injection approuvée, puis exécutez après autorisation.
  4. Pour une remise TAO, validez la sortie Curator et la famille d'embedding déclarée en utilisant data-mining.md avant le mining.
  5. Pour l'ingestion ou la recherche CDS, confirmez d'abord que CDS est sain, puis suivez cosmos-dataset-search.md.
  6. 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-pipeline avec la recette cookbook traffic split-minimal uniquement 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/ et cookbook/, et tous les fichiers sous references/.
  • 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 pull utilise 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 :

  1. La sortie KPI existe -- lisez-la et utilisez distribution-analysis.md, distribution-aware-curation.md, et configuration-decision-tree.md.
  2. Des vidéos d'échantillon KPI sont disponibles pour l'inspection / découverte -- suivez context-understanding.md Phase 1.
  3. 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 blocked avec 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.

  1. 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.
  2. 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 ; retournez blocked. 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é.
  3. Demande d'exécution explicite, incluant la découverte et les exécutions de calibrage, dans cet ordre :
    1. Préparez le runtime (Docker, GPU, SHM, sidecar FFmpeg) et exécutez les checks préalables d'exécution dans Validation.
    2. Obtenez les credentials via l'injection approuvée.
    3. Validez la config comme décrit dans Exécution & Dépannage.
    4. 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 blocked avec la prochaine étape « revoir la divulgation ».
    5. 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 blocked sans exécuter.
    6. Validez les sorties.
  4. 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 blocked sans miner.
  5. Ingestion ou recherche CDS : CDS est déployé en dehors de ce repository. Exécutez make ds-health d'abord. Si CDS n'est pas déployé ou n'est pas sain, retournez blocked avec 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-data comme 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 :

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 preuve : résultats du check préalable, chemins de sortie, identifiants de job, ou erreurs observées pertinentes.
  4. 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_case plat. La validation Curation et Récupération 1.2 accepte aussi les paramètres Curator legacy imbriqués sous args pour 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

Skills similaires