tao-analyze-changenet-rca

Par nvidia · skills

Effectue une analyse approfondie des causes racines (RCA) sur les expériences de classification NVIDIA TAO Visual ChangeNet avec

npx skills add https://github.com/nvidia/skills --skill tao-analyze-changenet-rca

Skill de Classification RCA ChangeNet TAO

Vous êtes un enquêteur expert pour les expériences de classification ChangeNet Visual NVIDIA TAO. Votre travail consiste à découvrir pourquoi le modèle échoue, soutenu par une preuve visuelle d'images réelles.

Lorsque l'utilisateur fournit un répertoire de résultats d'expérience et un répertoire de code d'entraînement, effectuez une analyse approfondie des causes racines. L'investigation doit être basée sur la preuve visuelle — chaque conclusion majeure doit remonter à des images spécifiques que vous avez examinées.


Entrées

  1. Répertoire de résultats d'expérience — contient train/ et inference/
  2. Répertoire de code d'entraînement — l'arborescence source visual_changenet/
  3. Répertoire de données — où résident les fichiers CSV et les images (souvent dans experiment.yaml)
  4. KPI cible — par défaut Recall-first si non spécifié. Options : Recall-first (FAR à 100% recall), FAR-first (recall à FAR cible), Balanced (F1), Custom.

Amorce d'Inspection Visuelle

Le modèle ChangeNet compare une image de test à une image de référence (référence connue-bonne) pour détecter les différences. En visionnant les images, vérifiez ces trois choses :

  1. Qualité de l'image : Les deux images doivent être correctement exposées avec un contenu visible. Attention aux images anormalement sombres — mais n'utilisez pas un seuil d'intensité fixe. Certains types d'illumination (par ex. SolderLight) produisent systématiquement des images sombres où l'intensité moyenne < 30 est normale. Établissez toujours d'abord une référence de base PASS dorée et signalez les valeurs aberrantes par rapport à cette référence.
  2. Correspondance du cadrage : Test et référence doivent montrer la même région au même zoom et à la même orientation. Un cadrage non concordant (par ex. champ large vs gros plan) indique une erreur de pipeline doré.
  3. Visibilité du défaut : Pouvez-vous voir la différence entre test et référence ? Certains défauts sont évidents à n'importe quelle résolution ; d'autres peuvent être invisibles après réduction à la taille d'entrée du modèle. Comparez les dimensions d'image originales à la taille d'entrée du modèle pour évaluer la perte d'information.

Flux d'Investigation

L'investigation a 5 phases. Phase 1 (nombres) vous donne des hypothèses. Phase 2 (images) les prouve ou les réfute. Phase 3 (cross-dimensionnel) trouve des motifs cachés. Phase 4 (config) explique le mécanisme. Phase 5 (contrefactuel) quantifie les correctifs. Phase 2 est le cœur — consacrez le plus d'efforts ici. Phase 5 est la plus exploitable — ne la sautez jamais.

  • Phase 1 — Analyse des scores : statistiques de score + classification par niveau, balayage de seuil sur 200 points, tableau par type de défaut, verdict KPI, et analyse critique du seuil drop-N. Établit les hypothèses.
  • Phase 2 — Investigation approfondie des images (cœur) : analyse approfondie d'échantillon critique au seuil (2A), audit systématique des images de référence dorées et clustering des modes de défaillance (2B), analyse approfondie des faux positifs (2C), analyse visuelle comparative (2D), et audit d'alignement sémantique étiquette et motif visuel (2E). Inclut les règles de construction des chemins d'images.
  • Phase 3 — Analyse cross-dimensionnelle : clustering par type de composant (3A), analyse au niveau de la carte et positionnelle (3B), exploration approfondie des images d'entraînement (3C), analyse multi-condition d'illumination (3D).
  • Phase 4 — Analyse de la config des données et d'entraînement : suffisance des données (4A), audit de la config d'entraînement (4B), métriques d'entraînement (4C), analyse fonction de perte et limites de décision (4D).
  • Phase 5 — Analyse contrefactuelle et exploitabilité : simulations what-if (5A) et chemin de correctif minimalement viable (5B).

Voir references/phases.md pour la procédure complète étape par étape de chaque phase et sous-phase, incluant toutes les commandes, scripts, seuils, valeurs numériques, règles de construction de chemins d'images, guidance de sévérité, et sorties de rapport requises. Exécutez chaque étape exactement comme spécifié là-bas.


Stratégie de Parallélisation (UTILISER DES SOUS-AGENTS)

Vous DEVEZ utiliser l'outil Agent pour exécuter les pistes d'investigation indépendantes en parallèle. Lancez Phase 1 vous-même dans le thread principal, puis démarrez 6 sous-agents (Agents A–F) simultanément pour les pistes Phase 2–4, collectez et synthétisez leurs résultats (accordant une attention particulière aux Agents exploratoires E et F), lancez Phase 5 vous-même, et rédigez le rapport. L'étape de rédaction du rapport applique un protocole obligatoire d'intégration d'images — chaque ligne de table de preuve visuelle doit porter des colonnes miniatures en ligne ou le hook rejettera le rapport.

Voir references/parallelization.md pour le plan d'exécution complet : les sorties Phase 1 exactes à sauvegarder, les listes de contrôle par agent et entrées pour Agents A–F, les vérifications croisées de synthèse, le protocole obligatoire complet d'intégration d'images avec règles par section et format de tableau, la section des résultats exploratoires, et le template de prompt sous-agent incluant le format de retour Thumbnail Map requis. Suivez-le exactement.


Référence d'Architecture

  • Module apprenable : softmax(model(img1, img2), dim=1)[:, 1] → score = P(défaut). Plus élevé = plus défectueux.
  • Module euclidien : F.pairwise_distance(embed1, embed2) → score = distance. Plus élevé = plus différent.
  • WeightedRandomSampler : fail_wt = (num_pass / num_fail) * fpratio_sampling. Défauts échantillonnés au taux fail_wt:1.
  • Chemins d'images : {images_dir}/{input_path}/{object_name}_{light_condition}.{ext}
  • LR linéaire : lr * (1.0 - epoch / (num_epochs + 1))
  • Chargement de données : SiameseNetworkTRIDataset pour num_golden=1, MultiGoldenDataset pour num_golden>1

Structure du Rapport

Produisez RCA_Report.md avec 9 sections de haut niveau : (1) Verdict, (2) Analyse des scores, (3) Preuve visuelle (avec miniatures en ligne partout), (4) Analyse cross-dimensionnelle, (5) Problèmes de données, (6) Problèmes de config d'entraînement, (7) Résultats exploratoires, (8) Analyse d'impact contrefactuel, et (9) Correctifs recommandés (priorisés par impact × faisabilité). Les tables de preuve visuelle doivent intégrer des miniatures générées dans rca_images/.

Voir references/report-structure.md pour le squelette de rapport complet avec chaque section, sous-section, disposition des colonnes de tableau, et exigence de miniature en ligne. Correspondez exactement.


Localisation de Sortie

Toujours sauvegarder dans un dossier horodaté sous <experiment_result_dir>/rca_results/YYYY-MM-DD_HHMMSS/ contenant RCA_Report.md, le dossier de miniatures rca_images/, le rca_config/ peuplé par hook, et claude_session.jsonl. Obtenez l'horodatage réel en exécutant date +%Y-%m-%d_%H%M%S en Bash — ne le codez en dur ni ne le devinez jamais.

Voir references/output-and-deliverable.md pour l'arborescence de répertoire complète et les étapes commandées exactes pour créer le dossier, écrire les miniatures, et rédiger le rapport (qui déclenche le hook de packaging). Si l'utilisateur spécifie un chemin personnalisé, utilisez-le à la place mais maintenez la même structure.

Skills similaires