04-Vision — Vision par ordinateur : du neurone convolutif au transfer learning

← DataScienceWithAgents (série parente) | 03-DeepLearning (prérequis) | Track2-GoogleADK (autre série)

Kernel : Python 3 (coursia-ml-training compatible) · Bibliothèques : NumPy (implémentations from scratch), PyTorch (parité), matplotlib, Pillow · Niveau : intermédiaire (post 03-DeepLearning) · CPU : oui

Pourquoi cette série

03-DeepLearning a ouvert la rétropropagation sur des vecteurs tabulaires : MLP, gradient vérifié, parité NumPy ↔︎ torch. Le passage à l’image demande une primitive nouvelle — le neurone convolutif — qui partage ses poids spatialement, et la question se pose immédiatement : quand on empile 20 couches convolutives, pourquoi le gradient s’effondre-t-il ? Et comment ResNet résout-il ce problème avec une addition résiduelle ?

Cette série suit la même discipline que 03 : from scratch PUIS framework, parité epsilon machine. Chaque mécanisme est d’abord implémenté en NumPy pur (sans autograd), vérifié (gradient numérique par différence finie, parité pas-à-pas avec l’équivalent PyTorch), puis relié à l’API PyTorch que consomment les autres séries.

Vue d’ensemble

Notebook Sujet Concept-phare Validation
4.1 — Le neurone convolutif from scratch Conv2d NumPy pur (single + multi-canal), gradient vérifié par différence finie, parité epsilon machine avec torch.nn.Conv2d, pooling et invariance par translation La convolution n’est pas magique : un produit scalaire local, partagé spatialement, parité NumPy/torch à epsilon machine gradient analytique vs numérique : écart max 1e-10 ; multi-canal (3 in, 4 out) float64 : 5,33e-15 ; float32 : 1,91e-06 (précision BLAS CPU) ; invariance par translation mesurée pixel-à-pixel sur image réelle
4.2 — ConvNet profonde : pourquoi les résiduelles 20 conv2d empilées nues (effondrement du gradient), skip naïf (gradient réparé mais passe avant qui dérive), bloc pré-norme (les deux réparés), même protocole transposé à 20 blocs d’attention, puis accuracy CIFAR-10 sur 3 graines Le skip-connection n’est pas un détail architectural : c’est le mécanisme qui rend les réseaux profonds entraînables. C’est le même bloc que l’attention pré-norme dans 3.4 rapport de gradients g_0/g_19 : plain 2,16e-08 contre prenorm 1,01 ; effondrement exponentiel en la profondeur (D = 4 → 28 : 1,47e-01 → 2,02e-12) ; res_naif répare le gradient mais \\|h\\| dérive d’un facteur 88 et la perte initiale monte à 17,4 au lieu de ln 5 ; attention nue : rapport plat (0,92) alors que \\|h\\| est divisé par 2,1e+07 ; CIFAR-10 (5 classes, 3 graines) : prenorm 62,0 % ± 2,8 contre plain 34,0 % ± 10,0, soit +28,0 points pour un bruit de ±10,4 (rapport 2,7)
4.2b — Lean : le gradient qui meurt, le gradient qui survit Companion kernel lean4-wsl du lake learning_theory_lean : la paire plafond/plancher c ^ n (pile plain) vs (1-c) ^ n (pile résiduelle) #checkée depuis le lake, anti-triangulaire au pire cas t = ±2/5, ancres numériques norm_num, balayage en profondeur rejoué en Float, 3 exercices La mesure du 4.2 devient un théorème : abs_deriv_plainStack_le majore, abs_deriv_residualStack_ge minore — le raccourci identité garantit un plancher géométrique là où la pile nue a un plafond qui s’effondre table boundTable 0.4 [5,10,15,20] : c^n 0,010240 → 0,000000 contre (1-c)^n 0,077760 → 0,000037 ; à n = 24 le plancher résiduel tient encore à 5e-06 ; exécution 19 cellules kernel lean4-wsl, 0 erreur (See #13106)
4.2c — Détection d’objets from scratch : la grille d’anchors Terrain synthétique contrôlé (1-3 objets, largeurs 14-44 px, ratios 0,35-2,9, bruit gaussien + blobs de fond), grille d’anchors 5 184 (3 tailles × 3 ratios, stride 4), IoU vectorisée + garde-fous, assignation 0,5/0,35 + zone d’ombre + meilleur anchor par GT forcé, échantillonnage 1:3, encode/decode (dx, dy, dw, dh), loss BCE + 2×SmoothL1, NMS gloutonne, mAP VOC07/VOC10 calculé à la main, ablation grille carrée, 3 exercices Le réseau ne devine pas des boîtes, il corrige des hypothèses : la détection anchor-based réduit la localisation à une régression de petits décalages contre des priors géométriques — et l’ablation mesure que la diversité des ratios y est absorbée par l’assignation forcée et la plage log ±3 aller-retour encode/decode à 7,63e-06 px près ; 1,2 % des anchors ≥ 0,5 (le déséquilibre que le 1:3 compense) ; AnchorNet 74 717 paramètres ; 12 époques en 79 s GPU, loss 13,1 → 1,12 ; mAP@0.5 (400 images / 817 GT) : VOC07 0,853 / VOC10 0,914 ; ablation : grille carrée 0,864/0,926 contre complète 0,853/0,914 — écart de l’ordre du point (See #16057)
4.2d — Détection anchor-free : le renversement CenterNet CenterNet-like à la main sur le terrain du 4.2c : cible gaussienne (rayon canonique CornerNet, 3 cas de recouvrement, garde-fou causal IoU ≥ 0,7 sur grille exhaustive 30×30), offset sous-cellulaire, régression de taille, focal loss modifiée (facteurs (1−p)², p², (1−y)⁴) avec garde-fous analytiques, décodage par max-pool 3×3 + top-K, NMS, mAP VOC07/VOC10 au même harnais que 4.2c, ablation de l’offset, mesure des collisions de centres, 3 exercices Prédire un point, pas une boîte : l’anchor-free supprime la grille et ses cinq hyperparamètres — la contrepartie mesurée est la quantification (l’offset vaut 6,3 points de mAP07 et 10,0 de mAP10) et une capacité mono-échelle qui rend 18 points de mAP07 aux anchors sur ce terrain de tailles étalées 83 621 paramètres contre 74 717 au 4.2c (léger avantage de capacité côté anchor-free : l’écart mesure la méthode) ; 12 époques en 9 s GPU, cuDNN déterministe (chiffres reproductibles d’une exécution à l’autre) ; focal loss vérifiée au garde-fou (faux positif confiant sur un voisin à y = 0,6 puni à 2,56 % du fond pur, théorie (1−0,6)⁴) ; mAP@0.5 (mêmes 400 images / 817 GT) : VOC07 0,673 / VOC10 0,707 contre 0,853 / 0,914 aux anchors ; ablation sans offset : 0,610 / 0,606 ; collisions de centres : 0 sur 817 GT, contrôle positif forcé détecté (See #16057)
4.2e — Détection d’objets from scratch : la Focal Loss Dérivation mathématique de \(FL(p_t) = -\alpha_t (1 - p_t)^\gamma \log p_t\) depuis la BCE pondérée, implémentation PyTorch vectorisée sans lib, preuve numérique sur le régime 1000:1 (950 easy negatives + 50 hard negatives + 1 positif) que la contribution des easy negatives passe de 29 % du total BCE à 0,0 % en FL (γ=2), comparaison d’entraînement BCE vs focal sur classifieur binaire pathologique (80 positifs vs 8000 négatifs), 3 exercices (gradient analytique vs autograd, focal multi-classe, mini-détecteur avec focal) Le déséquilibre pos:neg n’est pas qu’un problème de ratio — c’est un problème de loss : la BCE pondère tous les exemples pareillement, et les easy negatives continuent d’accumuler leur contribution. Le modulateur \((1-p_t)^\gamma\) écrase les easy examples et préserve les hard — c’est la troisième voie après le sous-échantillonnage (4.2c) et la heatmap gaussienne (4.2d anchor-free). sur batch pathologique 1000:1, BCE = 64,8 (29 % easy neg / 70 % hard neg / 0,2 % pos) vs FL(γ=2) = 8,2 (0,0 % easy neg / 99,9 % hard neg / 0,0 % pos) — easy neg entièrement éliminés ; entraînement 30 époques sur MLP 2→32→1 (2 entraînements, workload stable : batch 80 positifs / 8 000 négatifs, MLP 2→32→1, BCE vs FL(γ=2, α=0,5), torch 2.14.0+cu126, lr 1e-2, Adam, mesure cellule focal11 post-c.1165 incluant grad_class_metric + loss_share_per_class — mesure exacte voir cellule focal11 du notebook) : BCE → rappel sur positifs = 0,00 (classifieur prédit tout comme négatif), FL(γ=2, α=0,5) → rappel = 0,84 — la loss seule, sans aucun sous-échantillonnage, suffit à détecter la classe rare (See #16057)
4.2f — Détection SOTA : fine-tuner torchvision Le terrain exact du 4.2c (générateur et graines repris verbatim : mêmes images, mêmes 817 GT de validation), trois familles torchvision.models.detection fine-tunées (Faster R-CNN two-stage, RetinaNet one-stage anchors, FCOS anchor-free) via le pattern d’usine uniforme (num_classes=2, weights=None, weights_backbone=ImageNet, seuils 0,5/0,45 posés à la construction, min_size=320 commun), gris → RGB, cibles xyxy/labels, ap_voc et matching glouton repris verbatim, comparatif final contre AnchorNet (nombres committés), 3 exercices Le pré-entraînement transfère hors domaine : sur des images grises synthétiques jamais vues d’ImageNet, la moitié du budget du from scratch (1 000 img × 6 ép. contre 2 000 × 12) achète un mAP essentiellement complet — le vrai livrable est le pattern d’usine, vocabulaire de tout pipeline réel Faster R-CNN 18,9 M · RetinaNet 32,2 M · FCOS 32,1 M paramètres (contre 75 k) ; mAP@0.5 sur les mêmes 400 images : 0,909/0,997 · 0,997/1,000 · 0,909/0,998 contre AnchorNet 0,853/0,914 ; latence 17,7-36,3 ms/img GPU ; fine-tuning 73 s / 109 s / 107 s (See #16057)
4.2g — Détection SOTA : YOLO sous ultralytics 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 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 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 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é 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)

Question initiale (#16834, candidat 1) : faut-il fusion 4.2g et 4.2h (deux benches Ultralytics livrés à deux jours d’écart) ?

Verdict : frontières nettes, pas de fusion. Les deux notebooks se recouvrent sur le modèle (yolov5nu) et le terrain (générateur du 4.2c verbatim, graines identiques), mais se distinguent sur trois axes mesurables qui justifient le split. Note importante : les axes 2 et 3 sont conditionnels à la fusion de la PR #16715 — sur main à l’instant de cette re-mesure, 4.2h est encore GPU comme 4.2g, et ni 4.2g ni 4.2h n’exposent ap_coco_per_image. Le verdict projette l’état post-#16715, qui est l’état où les frontières sont nettes.

  1. Couverture de la fratrie (axe solide sur main). 4.2g §4bis (« YOLOv5nu et YOLOv8s : la famille historique et son upgrade ») inclut déjà yolov5nu dans la cellule 16 (RESULTS = {} itère sur yolo11n, yolo11s, yolov5nu, yolov8s) avec mAP VOC07/VOC10 dans son tableau final §6. Sur main, 4.2g tabule yolov5nu à 0,909 / 0,986 (VOC07 / VOC10). 4.2h tabule le même modèle à 0,909 / 0,972 (cellule 9). La valeur ajoutée de 4.2h sur main n’est ni le modèle (déjà couvert) ni son mAP (déjà tabulé) : c’est la profondeur du bench sur ce modèle unique (fine-tune + AP COCO si #16715 merge), pas la complétude d’une fratrie.

  2. Dispositif CPU reproductible (axe projeté, conditionnel à #16715). Sur main, 4.2h est aussi GPU que 4.2g (mêmes machine et seed). PR #16715 bascule 4.2h vers CPU-only (myia-po-2026, torch 2.13.0+cpu, 7,4 ms/img yolov5nu) — la valeur ajoutée post-#16715 est cette baseline CPU reproductible sur machine non-GPU, ce que 4.2g ne prétend pas mesurer. Tant que #16715 n’est pas mergée, cet axe n’existe pas sur main.

  3. Protocole AP COCO intégré (axe projeté, conditionnel à #16715). Sur main, ni 4.2g ni 4.2h n’exposent ap_coco_per_image. PR #16715 l’ajoute en 4.2h §4bis (boucle ap_voc 11-points × 10 seuils IoU ∈ {0.50, 0.55, …, 0.95}) avec la liste explicite des trois écarts au COCO canonique (101-points, seuil de confiance, domaine de détection). Cette cellule est référencée par l’issue #16666 comme prérequis pour promouvoir mAP50-95 en protocole principal de la famille. Tant que #16715 n’est pas mergée, cet axe n’existe pas sur main.

Conclusion : la duplication apparente est une complémentarité conditionnelle — elle n’est mesurable comme frontière nette qu’après la fusion de #16715. Une fusion de 4.2g et 4.2h effacerait la baseline CPU (axe 2) et supprimerait le prérequis #16666 (axe 3). Acceptance #16834 candidat 1 livrée en PR : verdict rendu, frontières documentées, ordre de merge dépendant de #16715.

Prérequis

Environnement

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.
  • Track2-GoogleADK ↔︎ 04-Vision : les notebooks de Track2 chargent des modèles pré-entraînés via des outils ADK ; le 4.3 est la version from scratch de la même idée (ResNet18 pré-entraîné, sans orchestration agentique).

Feuille de route

L’Epic #12422 « Série Vision 04 (à décider) — Évolution des architectures CNN » est livrée par cette série : - 4.1 — le neurone convolutif from scratch (livré) - 4.2 — pourquoi la profondeur échoue sans résiduelles (livré) - 4.2b — companion Lean : le gradient qui meurt, le gradient qui survit (livré) - 4.2c — détection anchor-based from scratch (livré, See #16057) - 4.2e — détection from scratch : la Focal Loss (livré, See #16057 — bloc A.3 trilogie anchor / anchor-free / focal) - 4.3 — transfer learning ResNet (livré)

La famille détection d’objets poursuit sur l’Epic #16057 (même terrain, même protocole d’évaluation) :

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).

Retour au sommet