Auto-Labeling PAIDF

Utilisez cette compétence quand un utilisateur souhaite lancer l'Auto-Labeling PAIDF sur ses propres données, domaine ou cas d'usage, ou quand la demande correspond à une tâche de cookbook, stage, authoring ou migration livrée. Ceci est un routeur : ordonnez les références spécialisées plutôt que de dupliquer leurs détails.

Routing (À lire d'abord)

Références de stages : super-resolution, detection-and-tracking, captioning, visual-qa, reasoning, person-attribute-search, grounding-2d, referring-expressions, training-export.

Instructions

1. Confirmer les entrées critiques de l'exécution avec l'utilisateur avant tout, et poser une question concise chaque fois qu'une information manque ou est ambiguë — ne pas deviner ni inventer silencieusement une valeur par défaut. Au minimum confirmer : chemin des données d'entrée, chemin de sortie, URLs des endpoints VLM/LLM et noms des modèles, chemin du cache modèle, IDs GPU, et (pour les modèles capables de raisonnement) la limite max_tokens. Reformuler les valeurs confirmées à l'utilisateur avant la première exécution.
2. Vérifier l'environnement : repository cloné, cibles make disponibles, chemin du cache modèle existe, endpoints VLM/LLM joignables, GPU disponible. Exposer tout prérequis manquant comme un bloqueur au lieu de l'assumer.
3. Exécuter d'abord un exemple livré pour confirmer que la stack fonctionne de bout en bout avant de personnaliser. Choisir le pipeline opérateur le plus proche — augmentation de données vidéo, recherche d'attributs événement-et-personne, ou raisonnement de vérification d'événement — et exécuter son cookbook commité. Utiliser la référence opérateur correspondante.
4. Planifier le scénario cible : définir modalité, domaine, consommateur prévu, annotations requises, et obtenir un sous-ensemble de stages minimal. Utiliser scenario-planning.
5. Adapter le cookbook livré le plus proche au nouveau domaine plutôt que de créer à partir de zéro. Utiliser cookbook-authoring.
6. Rédiger les prompts de domaine et les banques de questions. Utiliser prompt-authoring.
7. Configurer les paramètres par stage pour le domaine (classes de détecteur ou prompts SAM3, endpoints, windowing, max_tokens). Utiliser la référence de stage pertinente, en commençant par detection-and-tracking.
8. Exécuter le cookbook adapté en mode test, puis exécuter et valider les sorties. Utiliser workflow-runner-debugging.

Adopter un repository d'annotation externe existant ou de génération de dataset dans PAIDF plutôt que de commencer par un cookbook livré est une tâche de migration ; utiliser pipeline-migration pour ce chemin.

Exemples

Nouvel utilisateur, nouveau domaine : « J'ai cloné le repo et j'ai ma propre vidéo de sécurité en entrepôt. Comment produire des auto-labels pour mon domaine ? »

Chemin guidé :

• Confirmer l'env (cache modèle, endpoints VLM/LLM, GPU), puis prouver la stack sur un exemple livré avant de personnaliser :

make run SCRIPT=workflow-runner:main \
  ARGS='--cookbook-file cookbooks/video_data_augmentation/configs/pipeline_video.yaml --container-dry-run'

• Planifier le domaine (scenario-planning) -> sous-ensemble detection_and_tracking -> captioning -> visual_qa -> reasoning -> training_export (ajouter grounding_2d pour caption→boxes ou referring_expressions pour boxes→phrases ; utiliser grounding-2d / referring-expressions).
• Copier le cookbook le plus proche vers cookbooks/warehouse_safety/configs/pipeline.yaml et adapter entrées, classes de détecteur/prompts SAM3, prompts et banques de questions.
• Exécuter le nouveau cookbook en mode test, puis en réalité et valider sorties :

make run SCRIPT=workflow-runner:main \
  ARGS='--cookbook-file cookbooks/warehouse_safety/configs/pipeline.yaml --container-dry-run'

Garde-fous

• Ne pas deviner ou inventer les entrées critiques énumérées à l'étape 1 ; si une manque ou est ambiguë, demander à l'utilisateur et confirmer avant d'exécuter.
• Ne pas personnaliser un cookbook avant qu'un exemple livré s'exécute sans problème ; une base cassée rend le débogage de domaine ambigu.
• Garder le premier pipeline personnalisé minimal — uniquement les stages nécessaires aux annotations demandées — et étendre ensuite.
• Vérifier que le paquet de service et l'image de chaque stage sélectionné existent dans la branche courante avant de promettre une exécution de bout en bout.
• Ne pas mettre de secrets, tokens ou chemins absolus home dans les cookbooks commités ; utiliser des placeholders comme <model-cache> et des variables d'env pour les clés d'endpoint.
• Pour les modèles capables de raisonnement (par exemple Gemini 3 Flash), augmenter max_tokens sur les substages LLM visual_qa et reasoning pour éviter le coût des tokens de pensée ; garder la limite par défaut pour les modèles non-raisonnement.
• Ne pas compter sur des pipelines, commandes ou emplacements de fichiers hors-PAIDF. Une première exécution doit être reproductible via workflow-runner:main dans ce repo.