TAO DEFT OD AOI

Installation autonome ? Si cette session n'a pas été initialisée par le plugin de skill bank TAO, exécutez d'abord la skill tao-setup (précontrôle de l'hôte, identifiants, découverte inter-skills).

Cette application est une boucle RT-DETR sauvegardée sur disque pour une seule classe de premier plan, defect. Son cœur est réservé aux données réelles uniquement ; la synthèse AnomalyGenNext est une route optionnelle avec préparation, génération et portails d'admission distincts.

Références

Lisez uniquement les références nécessaires à l'étape actuelle :

entrée et lancement : references/defaults.md, references/data-contract.md, references/source-manifest.md et references/preflight.md ;
orchestration : references/pipeline.md et references/scripts-and-agents.md ;
lacunes et récupération : references/gap-routing.md et references/tao-analyze-gaps-od-map.md ;
entraînement et sélection : references/training-policy.md ;
synthèse optionnelle : references/anomalygen-pool.md.

Démarrage

Sélectionnez une plateforme installée, lisez sa skill, puis invoquez tao-launch-workflow. L'examen de lancement unique doit inclure les quatre rôles COCO normalisés, le point de contrôle RT-DETR de base entraînable, le nombre maximal d'itérations, les conteneurs images et Data Services, la forme GPU et le runtime attendu. Après approbation, préparez les fichiers COCO source si nécessaire :

scripts/prepare_deft_od_aoi_sources.py \
  --manifest /data/dataset_sources.json --check-only

scripts/prepare_deft_od_aoi_sources.py \
  --manifest /data/dataset_sources.json \
  --output-dir /new/results/normalized

--check-only s'exécute sans conteneur. La matérialisation doit s'exécuter dans l'image TAO Data Services épinglée car elle délègue la fusion COCO canonique de chaque rôle à l'action annotations merge existante. L'application valide ensuite les contrats de rôle fusionnés avant d'émettre sources.json. Incluez --gpus lors du lancement du conteneur de matérialisation, comme documenté dans references/source-manifest.md.

Le manifeste orienté utilisateur appelle l'entrée retenue benchmark. La deuxième commande la mappe au rôle interne existant kpi et émet sources.json avec le mappage canonique kpi, test, real et clean. Copiez assets/default_policy.yaml, utilisez ce mappage pour sources, remplissez les autres valeurs requises et initialisez une seule fois :

Les COCO sources doivent déjà satisfaire le contrat de métadonnées KPI canonique dans references/data-contract.md. Le préparateur source générique préserve ces champs ; il ne déduit pas les chemins d'identité ou de masque spécifiques aux données.

scripts/init_deft_od_aoi.py \
  --config /workspace/deft_policy.yaml \
  --output-dir /new/results/deft_contract

Ne réinitialisez jamais un résultat existant. Le validateur exige des rôles KPI, test, defective-real et verified-clean disjoints ; chaque COCO doit déclarer uniquement defect. KPI et test peuvent mélanger des images encadrées et sans cadre car elles n'entrent jamais en entraînement. Le rôle defective-real doit être non vide et a besoin d'au moins une boîte sur chaque image. Les images nettes restent des entrées COCO avec zéro annotation explicite ; un rôle clean vide est accepté comme capacité de récupération indisponible avec un avertissement au démarrage.

Limite de la boucle

La boucle compose les actions de banque existantes :

Initialisation de lacune de base en mode cold_start ou checkpoint explicite ; les mesures ultérieures utilisent l'inférence tao-train-rtdetr sur KPI et test.
Deux actions tao-analyze-gaps-od-map : confiance lâche pour le routage FP et confiance stricte pour le routage FN.
tao-generate-image-embeddings avec un encodeur SigLIP figé, suivi de tao-mine-od-images appariement de voisins uniques contre le rôle réel ou clean.
Admission application-owned et assemblage COCO binaire cumulatif.
Entraînement direct tao-train-rtdetr depuis le même point de contrôle de base figé, puis sélection de point de contrôle KPI uniquement. Test reste report uniquement.

Tous les specs sont des dictionnaires YAML imbriqués. Chaque action GPU/Data Services utilise le contrat submit/status/logs/cancel de la plateforme sélectionnée et un enregistrement de travail. Arrêtez en cas d'artefacts manquants ou invalides, chevauchement de rôles, dérive de classe ou entraînement échoué. N'inférez jamais l'état en direct à partir du seul enregistrement JSON.

Préparation de la récupération

Construisez le cache de candidats réutilisable une fois, puis préparez les requêtes après chaque paire de travaux de lacune lâche/stricte :

scripts/prepare_deft_od_aoi_retrieval.py candidates \
  --policy "$RESULTS/deft_od_aoi_policy.yaml" \
  --output-dir "$RESULTS/candidates"

scripts/prepare_deft_od_aoi_retrieval.py queries \
  --policy "$RESULTS/deft_od_aoi_policy.yaml" \
  --strict-gaps "$ITER/strict/box_gaps.parquet" \
  --loose-gaps "$ITER/loose/box_gaps.parquet" \
  --previous-coco "$PREVIOUS/train.json" \
  --iteration 1 --candidate-root "$RESULTS/candidates" \
  --output-dir "$ITER/retrieval"

Le manifeste de candidats enregistre un nombre zéro et n'émet aucun parquet candidat ou spec d'embedding pour un rôle source clean vide.

Exécutez chaque spec d'embedding émis via tao-generate-image-embeddings. Pour max_similarity, exécutez chaque spec d'exploitation émis via tao-mine-od-images. Pour round_robin_similarity, matérialisez les artefacts sélectionnés après l'embedding de requête à la place :

scripts/deft_od_aoi_round_robin_selection.py \
  --policy "$RESULTS/deft_od_aoi_policy.yaml" \
  --candidate-root "$RESULTS/candidates" \
  --retrieval-root "$ITER/retrieval" \
  --previous-coco "$PREVIOUS/train.json"

Omettez --previous-coco pour l'itération 1. Les itérations ultérieures excluent les cultures de candidats dont l'image source figure déjà dans le COCO d'entraînement cumulatif, tandis que l'admission reste le portail de déduplication au niveau source faisant autorité. Les deux stratégies doivent produire le mine_<role>/final_unique_files.parquet d'un rôle activé avant de valider iteration_retrieval ; round-robin valide également round_robin_selection_report.json comme selection_report et round_robin_admission_index.npy comme admission_index. Les candidats défectueux et les requêtes de lacune utilisent le retrieval.preprocessing.profile indépendamment sélectionné : le square_context par défaut remplit et redimensionne à 224×224, tandis que tight_context préserve une culture de taille native consciente du rapport d'aspect. Les candidats clean utilisent le même profil sur la grille gelée. Les FN strictes et les FP proches lâches routent vers des données réelles. Les FP lâches ressemblant à l'arrière-plan routent uniquement vers le rôle verified-clean. Transmettez le COCO cumulatif antérieur en tant que --previous-coco ; les parquets d'exclusion optionnels spécifiques aux rôles utilisent --real-exclusions et --clean-exclusions. Les rôles vides ou entièrement exclus émettent des preuves d'épuisement auditées et aucune action d'exploitation. Si chaque producteur est épuisé et la synthèse n'est pas en attente, l'étape enregistre la convergence. Le retrieval.selection.strategy indépendant par défaut à round_robin_similarity, qui équilibre les candidats entre les tours de rang stables par requête et les quotas de poche. max_similarity conserve le chemin de similarité maximale global.

Admission et COCO cumulatif

Après que chaque rôle activé ait un artefact de sélection validé, admettez ses cultures de candidats sélectionnées à des images sources uniques et publiez le prochain ensemble de données cumulatif :

scripts/admit_deft_od_aoi_coco.py \
  --policy "$RESULTS/deft_od_aoi_policy.yaml" \
  --candidate-root "$RESULTS/candidates" \
  --retrieval-root "$ITER/retrieval" \
  --previous-coco "$PREVIOUS/train.json" \
  --output-dir "$ITER/training_data"

Omettez --previous-coco seulement pour l'itération 1. Pour max_similarity, l'assistant recalcule la similarité cosinus maximale à partir des embeddings candidat/requête gelés. Pour round_robin_similarity, il consomme la sélection par requête validée, les boîtes dépistées, le rapport d'audit et l'index d'admission sans réexécuter la sélection, puis publie admission_index.npy pour l'itération suivante. Les deux chemins appliquent la similarité minimale en amont, dédupliquent les cultures de hits aux images sources, excluent les sources antérieures et bouchent les négatifs clean cumulatifs contre les défauts réels cumulatifs. Il conserve chaque image et boîte antérieure et émet un COCO binaire avec des images clean explicites avec zéro annotation. Utilisez --link-mode hardlink uniquement quand source et sortie partagent un système de fichiers ; le staging portable doit conserver la copie par défaut.

Specs de mesure

Pour la base de référence, passez --baseline. Le mode cold_start par défaut crée un fichier de prédiction vide pour chaque image KPI, rendant toutes les boîtes de vérité terrain KPI des faux négatifs initiaux sans charger un point de contrôle multiclasse incompatible dans la tête d'inférence binaire. Il émet également des preuves de prédiction test vides appairées en cardinalité pour que le manifeste de mesure conserve le même contrat d'accomplissement KPI/test sans exécuter l'inférence. Le mode checkpoint explicite émet les specs d'inférence KPI/test normaux et nécessite donc un point de contrôle compatible binaire. Aucun mode ne change l'initialisation de l'entraînement.

scripts/prepare_deft_od_aoi_measurement.py \
  --policy "$RESULTS/deft_od_aoi_policy.yaml" \
  --checkpoint "$CHECKPOINT" \
  --kpi-predictions "$MEASURE/kpi/inference/labels" \
  --results-root "$MEASURE" --output-dir "$MEASURE/specs" \
  --baseline

Soumettez uniquement les specs d'inférence énumérés dans measurement_manifest.json ; une base de référence cold-start liste aucun spec d'inférence. Puis soumettez gap_loose.yaml et gap_strict.yaml via tao-analyze-gaps-od-map. L'assistant projette le COCO KPI gelé vers KITTI, conserve la carte de classe d'inférence deux lignes durable, et émet uniquement des specs imbriqués. L'inférence de test est report uniquement et sa sortie ne peut pas influencer le routage ou la sélection de point de contrôle.

Après l'entraînement, omettez --baseline ; chaque mesure d'itération utilise le point de contrôle binaire sélectionné et émet l'inférence KPI/test indépendamment du mode de base de référence.

Specs d'entraînement RT-DETR

Construisez des specs imbriqués à partir du COCO cumulatif actuel :

scripts/prepare_deft_od_aoi_training.py \
  --policy "$RESULTS/deft_od_aoi_policy.yaml" --iteration 1 \
  --train-coco "$ITER/training_data/train.json" \
  --train-images "$ITER/training_data/images" \
  --results-root "$ITER/training" --output-dir "$ITER/train_specs"

Invoquez la feuille RT-DETR comme entraînement direct avec automl_policy: off ; l'application AOI possède déjà sa politique de sonde gelée. Les itérations 1–2 utilisent 36 epochs. Les itérations ultérieures utilisent le budget adaptatif à la taille clipée. Quand les sondes sont activées et l'itération atteint le training.probes_start_iteration gelé, l'assistant émet des specs indépendants incumbent, data-growth-scaled et déterministes jitter, tous initialisés à partir du même point de contrôle de base gelé. Exécutez les trois avant de sélectionner et matérialiser train.yaml ; ne réinitialisez jamais l'itération suivante à partir d'un point de contrôle d'itération antérieure.

Sélectionnez les trois sondes avant l'entraînement principal :

scripts/select_deft_od_aoi_training.py probes \
  --manifest "$SPECS/training_manifest.json" \
  --main-template "$SPECS/main_template.yaml" \
  --status "$P0/status.json" --status "$P1/status.json" --status "$P2/status.json" \
  --output-dir "$SPECS/selected"

Après l'entraînement principal, sélectionnez le point de contrôle KPI-meilleur à partir de lignes de statut structurées. Répétez --status pour les phases reprises. Si la meilleure epoch se situe dans la fenêtre tardive gelée, le premier appel émet un extension.yaml de même itération à partir du point de contrôle terminal ; soumettez-le, puis resélectionnez avec --extension-applied. Le point de contrôle porté à la mesure est toujours le val_mAP50 KPI maximal, jamais le dernier point de contrôle ou le résultat test.

Après chaque étape réussie, validez au moins un artefact d'accomplissement avec commit_deft_od_aoi_stage.py. Il accepte uniquement l'étape gelée suivante, vérifie et hache chaque fichier nommé, met à jour atomiquement deft_state.json et ajoute loop_log.jsonl. L'itération finale devient COMPLETE seulement après que ses artefacts de lacune sont validés. Interrogez les backends natifs pour l'état en direct ; ce enregistrement est l'historique du workflow durable, pas un substitut du planificateur.

Synthèse optionnelle avec poids de tâche existants

Activez synthesis uniquement quand chaque échantillon KPI conserve son dataset_id réel non vide ; un ID manquant est une métadonnée KPI malformée et n'est jamais un opt-out. synthesis.routes est la liste blanche de synthèse. Les ID de dataset absents ne la traversent pas la synthèse mais restent dans le chemin DEFT réel normal séparé. Chaque FN dans une route configurée doit également porter texture_id, defect_class et un masque pixel fn_mask_source, et la route doit fournir un point de contrôle AnomalyGenNext existant et une recette correspondante. Après l'analyse des lacunes strictes, normalisez les correspondances exactes FN/annotation :

scripts/prepare_deft_od_aoi_synthesis.py \
  --policy "$RESULTS/deft_od_aoi_policy.yaml" \
  --strict-gaps "$MEASURE/gap_strict/box_gaps.parquet" \
  --iteration 1 \
  --real-coco "$ITER/admission/train.json" \
  --output-dir "$ITER/synthesis_request"

Le mode synthesis.fn_selection.mode: generated_per_type_plan par défaut borne le travail à partir du COCO réel actuellement admis. Il dérive un plan par type déterministe de cumulative_fraction_of_total_defects, écrit et hache le plan, et enregistre le calcul d'allocation complet. Une fraction de 0,25 signifie que les images synthétiques représentent 25 % du pool de défauts réels plus synthétiques combinés. Définissez explicitement le mode à all_eligible pour conserver chaque FN routé sans budgétisation de pré-génération.

Le planificateur dérive le rendement finalisé comme 2 * max_neighbors_per_fn : le finaliseur émet deux branches de masque fixe et demande une image à chaque branche pour chaque voisin conservé. candidate_topn fournit uniquement des candidats voisins de secours et n'entre pas dans ce calcul. C'est synthèse uniquement et indépendant à la fois de l'overfetch de similarité maximale et du remplissage round-robin. La valeur dérivée est enregistrée comme images_per_fn dans la preuve de plan gelée ; ce n'est pas une entrée de politique. candidate_topn est le bouton de calcul AMP : la préparation émet deux demandes AMP par candidat éligible, donc un FN coûte jusqu'à 2 * candidate_topn tentatives de placement pour conserver 2 * max_neighbors_per_fn images finalisées. Pour la compatibilité rétroactive, l'initialisation copie un retrieval.candidate_overfetch hérité fourni explicitement dans la synthèse quand candidate_topn est omis, et les politiques déjà gelées sans le nouveau champ conservent ce recours. Définissez les deux champs explicitement pour les configurer indépendamment.

Transmettez le YAML de filtrage émis via tao-prepare-anomalygennext-inputs, montant la racine du point de contrôle complet pour son action run_amp, puis transmettez son plan de génération finalisé via tao-generate-od-defects avec la même racine du point de contrôle montée au même chemin canonique. Validez iteration_synthesis avant l'entraînement. Lisez le contrat d'action tao-generate-od-defects sélectionné et résolvez actions.generate.outputs.binary_coco.relative_path contre le répertoire de résultats de cette action. Réexécutez l'admission avec le fichier résolu passé via --synthetic-coco et le répertoire de résultats de génération passé via --synthetic-images ; l'admission ne localise jamais une skill compagne elle-même. Les catégories synthétiques sont repliées à defect, et le plafond de fraction cumulatif gelé est appliqué contre les défauts réels admis. Validez l'admission initiale avant de demander la synthèse. Le contrôleur d'étape utilise sa capacité synthétique calculée : une pièce zéro enregistre un skip no_synthetic_budget et contourne la synthèse d'itération. Entraînez-vous uniquement quand cette itération a admis de nouvelles images ; sinon converge. Une capacité positive peut rester des admissions réelles antérieures même sans nouvelles correspondances réelles. Le plafond post-génération et les vérifications de qualité s'appliquent toujours quand la synthèse s'exécute ; fournissez l'admission réelle de même itération en tant que --previous-coco et définissez --synthetic-only pour que les entrées synthétiques ne réexécutent pas implicitement l'admission d'exploitation. SYNTHETIC_ADMISSION_CAPPED signale les images générées éligibles exclues par le plafond. Voir references/pipeline.md pour les preuves de skip de budget. Un nombre cumulatif réel zéro permet zéro admissions synthétiques.

Les boîtes ne remplacent jamais le masque pixel requis. Si la demande n'a aucun FN routé, ou que la préparation signale aucun FN eligible au masque, validez ce contrat de skip typé comme iteration_synthesis et continuez l'entraînement sans exécuter AMP ou fabriquer le succès de génération/admission. Les pools de référence clean AnomalyGen manquants ou vides ignorent de même uniquement les FN/types affectés avec no_clean_reference_images ; les types éligibles et la récupération réelle/clean continuent. L'initialisation rejette la synthèse quand le pool de référence configuré complet n'a aucune image prise en charge sous aucun répertoire TEXTURE/clean_image. Si aucun FN ne reste éligible, la raison au niveau de la préparation est no_eligible_false_negatives tandis que les preuves par FN conservent la cause spécifique. Si chaque producteur est indisponible, la validation de skip typée enregistre la convergence à la place de l'entraînement sur une itération inchangée.

Poids de tâche AnomalyGenNext manquants

Une route de synthèse peut remplacer checkpoint et recipe par un bloc finetune contenant dataset_root, validation_testcase gelé, base base_checkpoint Cosmos3-Nano, vae_path, checkpoint_root, result_handoff futur, et recipe_template/defect_spec utilisateur optionnel. Ce sont des entrées AnomalyGenNext ; la politique application n'est pas une recette d'entraînement en amont.

Exécutez resolve_deft_od_aoi_synthesis.py avant le cache candidat. Si un handoff est absent, il émet finetune_requests.json ; exécutez chaque demande via tao-finetune-anomalygennext une fois. Résolvez à nouveau dans un nouveau répertoire, vérifiez le handoff lié au hash, validez synthesis_bootstrap, et utilisez le resolved_synthesis_policy.yaml émis pour toute la préparation de synthèse ultérieure. Ne démarrez ni ne reprenez jamais l'entraînement AnomalyGenNext à l'intérieur d'une itération DEFT.

tao-run-deft-od-aoi