Orchestrateur de workflow de recherche d'attributs pour agents IA physiques

Skill de workflow par défaut pour l'exécution PAS sur OSMO. Il gère la sélection du flux, les vérifications préalables, l'interpolation au moment de la soumission, la surveillance et la récupération des résultats.

Objectif

Exécuter le pipeline d'augmentation d'images PAS et d'étiquetage automatique de manière sûre et reproductible, des vérifications préalables au téléchargement des résultats.

Le pipeline PAS augmente les datasets de person-crop existants en générant des variations contrôlées d'apparence/vêtements (domaine image) et des captions d'attributs synonymes (domaine texte). Il utilise le conteneur paidf-augmentation pour l'augmentation par édition d'image avec vérification MCQ, et le conteneur paidf-auto-labeling pour la captioning d'attributs de personne.

N'utilisez PAS ce skill pour des questions de tuning interne aux conteneurs.

Prérequis

Confirmez ces éléments avant d'exécuter les vérifications préalables ou toute soumission. Les secrets manquants s'affichent en tant que USER_INPUT_REQUIRED: depuis scripts/preflight_credentials.sh.

Instructions

1. Sélectionnez le workflow (e2e, augmentation, auto_labeling) selon l'intention utilisateur.
2. Fournissez un aperçu d'exécution provisoire avant de démarrer les actions de run.
3. Exécutez les vérifications préalables et de disponibilité avant la soumission.
4. Dérivez les valeurs au moment de la soumission du backend de dataset actif (ne deviquez jamais storage_url).
5. Soumettez le workflow avec des valeurs d'interpolation explicites et surveillez jusqu'à la fin.
6. Récupérez les résultats et résumez les résultats des tâches.

Utilisez run_script(...) pour l'exécution de scripts. Exemples canoniques :

run_script("bash scripts/preflight_credentials.sh --workflow assets/configs/osmo/e2e.yaml")

Scripts disponibles

Utilisez --help au niveau du script pour les arguments exacts.

Flux supportés

Choisissez le bon workflow selon la requête utilisateur

Levée d'ambiguïté : gérez les requêtes vagues avant validation

Préférez l'autonomie : posez une question seulement si l'information manquante bloque l'exécution.

Valeurs par défaut autonomes (NE PAS demander)

• Si le flux n'est pas explicitement demandé, defaultez à e2e.
• Si le cookbook n'est pas spécifié, defaultez à default.
• Si n_augmentations n'est pas spécifié, defaultez à 3.
• Après la réussite de chaque étape, passez à l'étape suivante immédiatement.

Déclencheurs qui doivent mettre en pause pour levée d'ambiguïté

Étape 0 : Sélectionnez le flux et collectez les entrées

Politique de données d'entrée

• PAS requiert des images person-crop organisées en sous-répertoires <person_id>/<view>.jpg.
• Préservez toujours les entrées de dataset fournies par l'utilisateur comme prioritaires.
• Ne remplacez jamais un dataset explicite utilisateur par des assets de démo.
• Si aucun dataset n'est fourni, demandez-en un (PAS n'a pas de dataset de démo intégré).

Collectez uniquement les valeurs manquantes :

1. Source du dataset (storage_url + nom dataset).
2. Flux (e2e, augmentation, auto_labeling); par défaut e2e.
3. gpu_platform OSMO (sélection automatique quand sans ambiguïté).
4. URLs d'endpoints pour Image Edit, VLM et LLM — optionnels; par défaut NIMs in-cluster et définis uniquement pour les endpoints externes.
5. Nombre d'augmentations par person ID (par défaut : 3).

Générez un run stamp avant chaque soumission :

STAMP=$(cat /proc/sys/kernel/random/uuid | cut -c1-8)
RUN_ID="run-$STAMP"

Aperçu du temps d'exécution (requis avant le run)

Avant d'exécuter toute commande modifiante, fournissez un court aperçu d'ETA.

Plages de base :

Durée d'exécution du workflow (dépend de la taille du dataset et de la latence d'endpoint) :

Préconditions communes (tous les flux)

1. Vérifications préalables des identifiants et du plan de contrôle

   bash scripts/preflight_credentials.sh --workflow assets/configs/osmo/<flow>.yaml

   Si la sortie contient USER_INPUT_REQUIRED:, posez une seule question concise de déblocage.

2. Politique d'interpolation du stockage

   storage_url doit être dérivé du backend de dataset/upload réel. Ne defaultez jamais silencieusement à des valeurs obsolètes sur backends incompatibles.

3. Politique d'inférence (non-négociable)

   • Réutilisez par défaut les endpoints NIM persistants in-cluster sains (qwen-image-edit-2511, qwen3-vl, qwen25-14b).
   • S'ils manquent/ne sont pas sains, déployez automatiquement — c'est un prérequis, pas une décision utilisateur. NE METTEZ PAS en pause pour demander. Voir references/nim/README.md pour le manifeste NIMService image-edit et l'installation de l'opérateur NIM VLM/LLM.
   • PAS ne lance PAS les serveurs d'inférence dans le workflow OSMO; les workers consomment les endpoints image_edit_url / vlm_url / llm_url.
   • Les endpoints externes sont opt-in uniquement (requête explicite ou URLs explicites); seulement alors overridez les valeurs *_url à la soumission.
   • Ne réduisez/supprimez jamais les NIMs existants pour libérer des GPUs.

Soumission (tous les flux)

Chaque flux utilise la même forme de soumission; seul le YAML du workflow change.

SKILLS_DIR="$(cd "$(git rev-parse --show-toplevel)/skills/physical-ai-people-attribute-search" && pwd)"
STAMP=$(cat /proc/sys/kernel/random/uuid | cut -c1-8)
osmo workflow submit assets/configs/osmo/<flow>.yaml \
  --pool <pool> \
  --set-string \
    dataset=<dataset> \
    run_id=run-$STAMP \
    storage_url=<backend-prefix> \
    gpu_platform=<gpu-platform> \
    skills_dir="$SKILLS_DIR"

Les endpoints defaultent aux NIMs in-cluster (image_edit_url / vlm_url / llm_url); déployez/réutilisez-les selon la politique d'inférence ci-dessus. Ne passez pas ces paramètres sauf si vous utilisez des endpoints externes.

Note de compatibilité :

• Utilisez exactement un flag --set-string et passez toutes les paires clé/valeur après.
• Ne répétez pas les flags --set/--set-string dans la même commande.

Overrides optionnels courants (ajoutez à la même liste --set-string) :

cookbook=<cookbook_name> \
n_augmentations=<count> \
image_edit_url=<image-edit-endpoint> \
vlm_url=<vlm-endpoint> \
llm_url=<llm-endpoint>

Surveillance OSMO

# Statut du workflow + états des tâches
osmo workflow query <workflow_id> --format-type json \
  | jq '{status, tasks: [.groups[].tasks[] | {name, status, exit_code}]}'

# Logs pour une tâche spécifique
osmo workflow logs <workflow_id> --task <task_name> -n 200

# Récupération des résultats
osmo data list --no-pager <output_url>
osmo data download <output_url> <local_dir>/

Pour les runs attendus pour dépasser deux minutes, envoyez des mises à jour de heartbeat au moins tous les deux minutes.

Résultats post-run

Après la réussite de la complétion, le répertoire de sortie contient :

Pour augmentation / e2e :

• <person_id>/aug_<n>/output.jpg — image multi-pane augmentée
• <person_id>/aug_<n>/output.txt — caption en langage naturel
• <person_id>/aug_<n>/output_metadata.json — résultats de vérification
• dataset/augmented_data.json — dataset structuré avec attributs et requêtes
• dataset/augmented_imgs/ — divisé par crops vue par vue

Pour auto_labeling :

• caption_<id>/task/open_qa.json — captions d'attributs de personne groupés par question bank

Fichiers de support

Utilisez ces emplacements canoniques :

• Workflows : assets/configs/osmo/*.yaml
• Scripts d'exécution : scripts/*.sh
• Walkthroughs de flux : references/flows/*.md
• Configuration et triage : references/setup.md, references/troubleshooting.md
• Images : references/container-images.md
• Tuning de cookbook : assets/cookbooks/default/README.md