feat(notebook-python,#18403): 4.2j -- second wrapper SOTA LibreYOLO, parite YOLOv9-tiny + fenetre sans-NMS E2E

MyIA.AI.Notebooks/ML/DataScienceWithAgents/04-Vision/4.2i-Detection-Ultralytics-Difficult-Scenes.ipynb

@@ -16,7 +16,7 @@
    "source": [
     "# 4.2h — Détection SOTA : YOLO sous ultralytics, scènes difficiles\n",
     "\n",
-    "[← Série 04-Vision](README.md) | [4.2g — YOLO SOTA (terrain de référence)](4.2g-Detection-SOTA-Ultralytics.ipynb)\n",
+    "[← Série 04-Vision](README.md) | [4.2g — YOLO SOTA (terrain de référence)](4.2g-Detection-SOTA-Ultralytics.ipynb) | [4.2j — second wrapper LibreYOLO](4.2j-Detection-SOTA-LibreYOLO.ipynb)\n",
     "\n",
     "**Acceptance issue #16337** : faire passer le pipeline ultralytics sur un **terrain plus hostile** que le 4.2g — occlusions partielles + multi-échelle — et mesurer comment les trois familles de modèles (YOLOv5nu, YOLOv8s, YOLO11m) réagissent à la dégradation.\n",
     "\n",

MyIA.AI.Notebooks/ML/DataScienceWithAgents/04-Vision/README.md

@@ -24,6 +24,7 @@ Cette série suit la **même discipline que 03** : *from scratch PUIS framework,
 | [4.2g — Détection SOTA : YOLO sous ultralytics](4.2g-Detection-SOTA-Ultralytics.ipynb) | Terrain et protocole du 4.2c inchangés, conversion au format YOLO imposé par le pipeline (images uint8 + labels normalisés + `data.yaml`, répertoire temporaire, décomptes imprimés sans chemin machine), YOLO11n et YOLO11s fine-tunés au budget exact du 4.2f (1 000 × 6, `imgsz=96`, `workers=0`), évaluation `ap_voc` maison à seuils 0,5/0,45 (jamais le mAP auto-rapporté seul), **tableau final bloc A vs B** (AnchorNet, 3 torchvision, 2 YOLO : mAP, latence, paramètres, GFLOPs à 96, lignes de code), 3 exercices | **Le wrapper est un choix d'ingénieur, pas un raccourci** : ~267 lignes effectives contre ~404 au from scratch pour le même terrain ; le nano signe le meilleur rapport latence/précision du comparatif — en échange : format de données imposé, hyperparamètres enfouis, mAP auto-rapporté à protocole interne (l'exercice 3 le confronte au nôtre) | YOLO11n 2,59 M · YOLO11s 9,43 M paramètres ; mAP@0.5 mêmes 400 images : 0,909/0,989 · 0,909/0,993 ; latence 10,3 / 10,8 ms/img GPU (les plus rapides du comparatif) ; GFLOPs à `imgsz=96` : 0,1 / 0,5 ; fine-tuning 57 s / 54 s (See #16057) |
 | [4.2h — Bench YOLOv5 sur ultralytics](4.2h-YOLOv5-Bench-Ultralytics.ipynb) | Mêmes terrain et protocole que le 4.2g, générateur et graines identiques (2 000 train / 400 val / 817 GT) — chunk 2/3 de l'EPF #16057 ; `yolov5nu.pt` fine-tuné au budget canonique 1 000 × 6 `imgsz=96` (la version « u » est la ré-implémentation Ultralytics unifiée de l'archi YOLOv5, pas l'archi 2020 d'origine) ; `ap_voc` maison à seuils 0,5/0,45, latence CPU mesurée (machine de référence CPU-only, voir §5 du notebook), tableau 3 lignes comparatif face à `yolo11n` et `yolo11s` | **Le retrofit d'une vieille architecture sur le pipeline moderne est un test d'écart de génération** : même budget, même protocole — `yolov5nu` sort dans le même ordre de VOC07 que les yolo11 mais perd dans le haut du rappel (VOC10 0,975 vs 0,989/0,993), au profit de la mêmefamille marketing. Le 4.2f livre le pattern d'usine torchvision, le 4.2g livre deux membres contemporains YOLO, ce notebook en ajoute un troisième — `yolov8s` manque encore pour la fratrie complète (chunk 3/3 sur issue #16346) | `yolov5nu` 2,51 M paramètres (vs 2,59 / 9,43 M pour yolo11n/s) ; GFLOPs 0,2 ; mAP@0.5 VOC07 0,909 / VOC10 0,975 ; latence 7,4 ms/img CPU ; fine-tuning 81 s sur machine CPU de référence `myia-po-2026` (torch 2.13.0+cpu) — latences non comparables aux 10,3 / 10,8 ms/img GPU du 4.2g (matériel différent) ; voir §5 du notebook (See #16346) |
 | [4.2i — Détection SOTA : YOLO sous ultralytics, scènes difficiles](4.2i-Detection-Ultralytics-Difficult-Scenes.ipynb) | **Générateur hostile** : 30 % d'images avec occlusion par grand rectangle sombre + multi-échelle (40 % petits 8-18 px, 60 % gros 30-60 px), 600 imgs train × 4 époques fine-tune, 3 modèles pré-entraînés comparés : **YOLOv5nu** (anchor-based, 2,5 M params), **YOLOv8s** (anchor-free + C2f, 11,1 M params), **YOLO11m** (C3k2, 20 M params), frise chronologique YOLO 2016-2024 dans la section "Récit YOLO", 3 exercices (taux d'occlusion, dominance petits, combiné) | **Le protocole de mesure peut masquer la dégradation** : à mAP@0.1, tous les modèles ≥ 0.94 ; le protocole COCO (mAP@0.5:0.95) révélé par `model.val()` capture les vraies différences (YOLOv8s 0,84 vs YOLOv5nu 0,73). Leçon de méthodologie d'évaluation : un seuil IoU trop tolérant (= 0,1 style VOC originel) cache les stresseurs. | YOLOv5nu 2,51 M · YOLOv8s 11,14 M · YOLO11m 20,05 M paramètres ; mAP@0.1 sur 200 imgs val difficiles : 0,946 / 0,987 / 0,949 ; recall : 0,957 / 0,993 / 0,968 ; latence 11,46 / 13,40 / 23,29 ms/img GPU ; fine-tuning 52 s / 30 s / 41 s — budget total mesuré : 3 min 14 s (26 cellules, GPU CUDA — mesure détaillée dans la ligne « mesure sur 4.2i » ci-dessous) (See #16337) |
+| [4.2j — Détection SOTA : un second wrapper, LibreYOLO, et la leçon comparative](4.2j-Detection-SOTA-LibreYOLO.ipynb) | Terrain et protocole du 4.2c inchangés (générateur verbatim, mêmes graines, mêmes 817 GT), convertisseur YOLO du 4.2g réutilisé (split canonique de 1000 images matérialisé sur disque — pas d'option `fraction` dans ce paquet), deux modèles au budget 1000 × 6 `imgsz=96` : **YOLOv9-tiny** (parité directe avec les lignes YOLO du 4.2g) et **YOLOv9-tiny End-to-End** (sans NMS, appariement un-pour-un — l'idée centrale de DETR au gabarit identique : un seul facteur varie), `ap_voc` maison aux seuils 0,5/0,45, GFLOPs mesurés par `FlopCounterMode` (builtin PyTorch), **cellule licence** lisant licence + SHA de chaque checkpoint à la source (API Hugging Face) avant usage avec refus assertif des non-permissifs, tableau final étendu (lignes committées 4.2c/4.2f/4.2g + deux nouvelles, colonnes licence code et checkpoint), 3 exercices | **Le portage d'un wrapper à l'autre est quasi gratuit** (même format YOLO, même API à trois lignes) — c'est le format qui est le standard, pas l'enseigne ; la fenêtre « détection sans NMS » s'ouvre à variables égales via YOLOv9E2E, les DETR-family modernes restant derrière un plancher de résolution mesuré (topk sur carte 3×3 : crash à 96 comme à 128 px, DETR classique livré inférence-seule) ; **la licence est une colonne du tableau** : AGPL côté ultralytics, MIT + checkpoints permissifs vérifiés à la source côté LibreYOLO | YOLOv9t 2,76 M params · 0,17 GFLOPs@96 · mAP@0.5 (mêmes 400 images / 817 GT) VOC07 0,909 / VOC10 0,986 · latence 86,9 ms/img ; YOLOv9t-e2e 2,60 M · 0,17 GFLOPs@96 · VOC07 0,817 / VOC10 0,897 · 92,2 ms/img ; fine-tuning 156 s / 119 s (See #18403, EPIC #16057) |
 | [4.3 — Transfer learning : réutiliser un ResNet18 pré-entraîné](4.3-TransferLearning-ResNet.ipynb) | Charger ResNet18 pré-entraîné ImageNet, greffer une tête (5 130 params), comparer gelé vs fine-tuné sur EuroSAT (Sentinel-2, 10 classes d'occupation du sol, 80+30 imgs/classe), 3 graines appariées + test de permutation des signes | **Le feature extractor pré-entraîné est réutilisable — et le prix de ne pas l'adapter se mesure** : le gelé fait déjà ~89 % ; le fine-tuné ajoute ~6 points, mais seulement avec un taux décroissant (à taux constants, l'optimiseur oscille et finit sous le gelé) | backbone gelé 11,18 M params (99,95 % du réseau) ; gelé 89,3 % ± 1,3 (5 130 params entraînés) vs fine-tuné 95,6 % ± 0,8 (Adam différencié 3e-4/3e-3, décroissance x0,3/époque, batch 64, 5 époques) ; écart apparié +6,2 pts sur 3 graines (rapport signal/bruit 3,2, p = 0,250 au test de permutation — plancher 0,125 à n = 3) |
 
 ## Frontières 4.2g / 4.2h — verdict de l'audit #16834 (v2)
@@ -54,6 +55,8 @@ pip install numpy matplotlib torch torchvision pillow
 
 L'entraînement des deux notebooks concernés (4.2 et 4.3) reste **borné CPU** (sous-ensemble CIFAR-10 pour 4.2 ; EuroSAT ~94 Mo au premier run pour 4.3 — cache partagé `~/.cache/coursia-datasets` ; < 10 min/notebook). Les seuils d'entraînement sont calibrés pour la démonstration pédagogique, pas pour la performance ImageNet — voir les notebooks pour les budgets exacts par époque et par taille de sous-ensemble. Mesure sur 4.2 : exécution complète des 48 cellules en 2 min 20 s sur CPU ; mesure sur 4.3 : exécution complète des 35 cellules en 6 min 29 s sur CPU (dont 4 min 45 s d'entraînements) ; mesure sur 4.2c : exécution complète des 33 cellules en 3 min 02 s sur GPU CUDA (dont 1 min 19 s d'entraînement principal + l'ablation), le même budget restant exécutable sur CPU en quelques dizaines de minutes ; mesure sur 4.2f : exécution complète des 30 cellules en 5 min 51 s sur GPU CUDA (dont 4 min 49 s de fine-tuning des trois familles + évaluation sur 400 images), CPU exécutable pour l'inférence mais l'entraînement passe en dizaines de minutes par modèle ; mesure sur 4.2g : exécution complète des 27 cellules en 2 min 19 s sur GPU CUDA (dont 1 min 51 s de fine-tuning YOLO11n + YOLO11s, plus la conversion du dataset au format YOLO) — le nano reste entraînable sur CPU en quelques minutes ; mesure sur 4.2i : exécution complète des 26 cellules en 3 min 14 s sur GPU CUDA (dont 2 min 03 s de fine-tuning YOLOv5nu + YOLOv8s + YOLO11m sur terrain hostile 600×4 — 52 s / 30 s / 41 s par modèle). 4.2e : **mesure CPU dédiée re-mesurée (issue #16241)** — exécution complète des 20 cellules (8 code + 12 markdown) en **10 s** sur CPU (papermill wall-clock via `batch_reexecute.py`), dont **1,3 s** pour les 2 entraînements × 30 époques du MLP 2→32→1 (cellule focal11, mesure `time.time()`) ; aucune cellule ne requiert de GPU dédié. Note : la mesure GPU locale CUDA 3,6 s citée précédemment dans la file de revue #16165 reflète l'overhead de kernel-launch sur un MLP aussi petit (8080 samples, 113 paramètres) — pour cette taille de workload, le CPU est plus rapide que le GPU (1,3 s vs 3,6 s, ratio 0,36×) ; sur des entraînements plus lourds (notebook 4.2c, mAP complet), le GPU reprend l'avantage Mesure sur 4.2d : exécution complète des 34 cellules en ~24 s sur GPU CUDA (dont 9 s d'entraînement, cuDNN déterministe).
 
+Mesure sur 4.2j : exécution complète en 6 min 25 s sur GPU CUDA (dont 156 s + 119 s de fine-tuning YOLOv9t + YOLOv9t-e2e au budget canonique 1000 × 6 `imgsz=96`, GFLOPs et évaluation compris).
+
 ## Lien avec les autres séries
 
 - **`03-DeepLearning` ↔ 04-Vision** : la résiduelle du 4.2 est exactement le bloc pré-norme du mini-GPT du 3.4. C'est cette convergence qui justifie le titre de la série parente *DataScienceWithAgents* : du MLP tabulaire au Transformer en passant par le CNN, **les mêmes primitives** (forward, backward, résiduelle) se réécrivent sans surprise.
@@ -73,6 +76,6 @@ La famille **détection d'objets** poursuit sur l'Epic #16057 (même terrain, m
 
 - 4.2b — [Lean : le gradient qui meurt](4.2b-Lean-GradientFlow-Vanishing.ipynb), 4.2c — [la détection from scratch à la grille d'anchors](4.2c-Detection-Anchor-From-Scratch.ipynb) (livrés)
 - 4.2d — [la détection anchor-free from scratch](4.2d-Detection-AnchorFree-From-Scratch.ipynb) (livré — bloc A.2 de #16057, See #16145) ; 4.2e — [la Focal Loss dédiée](4.2e-Detection-FocalLoss-From-Scratch.ipynb) (livré — bloc A.3, See #16165)
-- 4.2f — [la détection SOTA torchvision fine-tunée](4.2f-Detection-SOTA-Torchvision.ipynb) (livré — bloc B.1 de #16057) ; 4.2g — [YOLO sous ultralytics + tableau final bloc A vs B](4.2g-Detection-SOTA-Ultralytics.ipynb) (livré — bloc B.2) ; [4.2h — Bench YOLOv5](4.2h-YOLOv5-Bench-Ultralytics.ipynb) (livré, #16346) ; 4.2i — [YOLO sur scènes difficiles (occlusions + multi-échelle)](4.2i-Detection-Ultralytics-Difficult-Scenes.ipynb) (bloc B.3 : extension scènes difficiles, leçon méthodologie, See #16337)
+- 4.2f — [la détection SOTA torchvision fine-tunée](4.2f-Detection-SOTA-Torchvision.ipynb) (livré — bloc B.1 de #16057) ; 4.2g — [YOLO sous ultralytics + tableau final bloc A vs B](4.2g-Detection-SOTA-Ultralytics.ipynb) (livré — bloc B.2) ; [4.2h — Bench YOLOv5](4.2h-YOLOv5-Bench-Ultralytics.ipynb) (livré, #16346) ; 4.2i — [YOLO sur scènes difficiles (occlusions + multi-échelle)](4.2i-Detection-Ultralytics-Difficult-Scenes.ipynb) (bloc B.3 : extension scènes difficiles, leçon méthodologie, See #16337) ; 4.2j — [second wrapper LibreYOLO + fenêtre sans-NMS E2E](4.2j-Detection-SOTA-LibreYOLO.ipynb) (bloc B.4 : parité inter-enseignes, colonne licence, See #18403)
 
 Chaque notebook est atomique (1 sujet vérifiable, < 3000 lignes, ≤ 15 fichiers), avec outputs commités (C.2) et ≥ 3 exercices par notebook (C.1, jamais `raise NotImplementedError`).