Vision par ordinateur
Des pixels à une caméra qui marche dans une vraie pièce mal éclairée.
Toutes les démos de vision par ordinateur marchent. C’est bien le problème. Le notebook affiche des boîtes nettes autour de piétons sur une image de test bien éclairée, tout le monde applaudit, puis on pointe le même modèle vers la vraie caméra du vrai entrepôt — montée trop haut, braquée sur une porte qui sature à midi, observant des gens majoritairement masqués par des palettes — et il s’effondre. Rien dans le tutoriel n’y préparait, car le tutoriel entraînait et testait sur la même distribution, la seule dans laquelle vous ne déploierez jamais. Ce parcours est construit à l’envers de cette logique. Vous commencez par l’image elle-même, car un nombre stupéfiant de bugs en production sont un canal de couleur dans le mauvais ordre ou un redimensionnement qui a effacé l’objet que vous cherchiez. Viennent ensuite les labels, votre vrai plafond : deux annotateurs sont en désaccord sur un cinquième des boîtes, et aucune architecture ne récupère une information que les labels n’ont jamais contenue. Puis les trois tâches qui composent le domaine — classification, détection, segmentation — et le tracking, qui constitue l’essentiel de ce que les clients achètent et presque rien de ce qu’on enseigne. Vous terminez sur l’edge : quantisation, budget d’images, et cette vérité sans gloire selon laquelle un modèle à quinze images par seconde sur l’appareil bat un meilleur modèle qui en fait trois.
Ce que vous allez apprendre
Prérequis
- Python et NumPy solides
- Fondamentaux du deep learning : boucles d’entraînement, CNN, fine-tuning
- Accès à un GPU pour l’entraînement et, idéalement, un petit appareil edge
- De la patience pour l’annotation — vous en ferez plus que prévu
Débouchés
- Ingénieur vision par ordinateur
- Ingénieur perception
- Ingénieur IA embarquée
- Applied scientist (vision)
Phases
Phase 1 — L’image et ses labels
Maîtriser ce que vous donnez réellement à manger au modèle, et accepter que vos labels sont votre plafond.
Durée estimée · 6-8 semainesCe qu’une image est réellement
Le bug de production le plus fréquent du domaine est un décalage de prétraitement : vous avez entraîné en RGB et la librairie caméra vous rend du BGR, ou vous avez normalisé avec certaines statistiques à l’entraînement et d’autres à l’inférence. Le modèle ne plante pas. Il devient juste discrètement moins bon, et vous passez deux semaines à accuser l’architecture. Apprenez le pixel, l’espace colorimétrique, et surtout ce que le redimensionnement détruit : le petit objet lointain qui intéresse le plus votre client est précisément celui qu’un resize naïf transforme en quatre pixels gris.
Sujets couverts
Ce que vous allez construire
- Prendre un modèle fonctionnel et le casser de trois façons — ordre des canaux, mauvaises stats de normalisation, rotation EXIF — et noter la chute d’accuracy exacte pour chacune
- Écrire un module de prétraitement utilisé à l’identique par l’entraînement et l’inférence, et un test qui échoue si les deux divergent
- Mesurer la dégradation de votre détecteur à mesure que vous réduisez la résolution d’entrée, et choisir la plus petite taille qui satisfait encore l’exigence
Datasets, annotation et votre vrai plafond
Donnez à deux annotateurs compétents les mêmes mille images et ils seront en désaccord sur une part non négligeable des boîtes — où finit exactement le camion, si cette ombre est une personne, si un objet à moitié visible compte. Ce désaccord est votre plafond : le modèle ne peut pas être plus cohérent que ses labels. Le travail à plus fort levier de tout ce parcours n’est donc pas architectural : c’est écrire un guide d’annotation assez précis pour que deux inconnus produisent le même fichier. Presque aucune équipe ne le fait, et presque toutes se demandent pourquoi leurs métriques stagnent.
Sujets couverts
Ce que vous allez construire
- Annoter 200 images vous-même, faire annoter les mêmes 200 par quelqu’un d’autre, puis calculer et rapporter votre score d’accord
- Réécrire votre guide d’annotation après cette mesure et prouver que l’accord s’améliore sur un nouveau lot
- Construire un split par caméra et par jour, et montrer de combien votre score annoncé chute face à un split aléatoire
Phase 2 — Détection, segmentation, tracking
Couvrir les trois vraies tâches, et la quatrième qui paie : suivre un objet dans le temps.
Durée estimée · 10-12 semainesLa détection, et la métrique qui cache l’échec
La détection est là où vit l’essentiel des produits de vision, et la mAP est là où l’essentiel des produits de vision se ment à eux-mêmes. C’est une métrique de recherche qui moyenne sur des seuils et des classes : très bien pour classer des articles, catastrophique pour répondre à la seule question de votre client — a-t-il raté une personne ? Apprenez comment un détecteur est assemblé — backbone, tête, suppression des non-maxima — mais consacrez au moins autant de temps à savoir rapporter le rappel par classe au point de fonctionnement que vous livrerez réellement, car c’est ce chiffre qui clôt le débat en réunion.
Sujets couverts
Ce que vous allez construire
- Fine-tuner un détecteur sur votre propre jeu annoté et rapporter le rappel par classe à un point de fonctionnement fixé, pas seulement la mAP
- Construire une scène dense où la suppression des non-maxima supprime un vrai positif, puis montrer la courbe de compromis en réglant son seuil
- Découper votre jeu de test par taille d’objet et prouver où votre détecteur échoue réellement
Segmentation et tracking dans le temps
Une boîte dit à peu près où ; un masque dit exactement quoi, ce qui compte dès qu’il faut mesurer une surface ou séparer des objets qui se touchent. Mais ce que les clients achètent vraiment, c’est le tracking : non pas « il y a une personne » mais « c’est la même personne qu’il y a trois secondes ». Cette identité, c’est là que se trouvent l’argent et la difficulté — à travers les occlusions, les croisements, les sorties de champ suivies d’un retour. Les tutoriels s’arrêtent à la détection parce que c’est au tracking que ça devient dur : raison précise pour laquelle le maîtriser vous rend employable.
Sujets couverts
Ce que vous allez construire
- Utiliser un modèle de segmentation promptable pour pré-annoter un dataset, puis mesurer le temps d’annotation réellement gagné après correction humaine
- Construire un tracker par-dessus votre détecteur et compter les changements d’ID sur un clip de deux minutes avec de vraies occlusions
- Prendre les dix pires changements d’ID de votre log, regarder les images, et noter la cause de chacun
Phase 3 — Jusque sur l’appareil
Sortir le modèle du notebook et l’amener sur un matériel avec un budget d’images fixe et aucune excuse.
Durée estimée · 8-10 semainesBackbones pré-entraînés et le domaine sur lequel vous n’avez pas entraîné
Vous n’entraînerez jamais un backbone depuis zéro et vous devriez cesser de culpabiliser : ni le compute ni la donnée n’arriveront. Fine-tunez, et mettez votre effort là où est le levier : l’écart entre les photographies d’internet dont votre backbone a appris et la caméra, l’angle et l’éclairage précis dans lesquels vous déployez. C’est cet écart, pas l’architecture, qui fait perdre quinze points à votre modèle sur site. Le remède est presque toujours plus de la bonne donnée plutôt qu’un modèle plus malin, et l’accepter tôt épargne un trimestre de travail perdu.
Sujets couverts
Ce que vous allez construire
- Évaluer un modèle entraîné sur données publiques face aux images d’une vraie caméra, et chiffrer l’écart de domaine en points
- Annoter 300 images de cette caméra, fine-tuner, et montrer quelle part de l’écart cela comble
- Extraire des hard negatives d’une semaine d’images de déploiement et démontrer la baisse des faux positifs
Déploiement edge et le budget d’images
Décidez vos images par seconde avant de choisir une architecture, pas après — les équipes qui choisissent le modèle d’abord passent le mois suivant à essayer de faire entrer l’impossible. Sur du vrai matériel, le modèle n’est souvent même pas le goulot : décoder la vidéo, copier vers l’accélérateur et dessiner la sortie peuvent manger plus de millisecondes que l’inférence. Apprenez à profiler tout le pipeline, apprenez ce que la quantisation vous coûte réellement en accuracy, et apprenez à dire tout haut qu’un modèle à quinze images par seconde bat un meilleur modèle à trois.
Sujets couverts
Ce que vous allez construire
- Écrire un budget d’images pour un cas d’usage réel, puis justifier votre choix d’architecture face à lui en une page avant d’écrire la moindre ligne de code
- Quantiser un détecteur entraîné, mesurer l’accuracy exacte perdue et la latence exacte gagnée, et dire si l’échange en valait la peine
- Profiler un pipeline caméra de bout en bout sur un appareil et produire une répartition en millisecondes montrant où passe réellement le temps
Questions
Ai-je encore besoin du traitement d’image classique, ou le deep learning l’a-t-il remplacé ?
Il vous en faut quelques semaines, pas un semestre, et la raison est pratique et non nostalgique. Chaque pipeline que vous construirez fera des opérations classiques que vous les compreniez ou non — un resize, une conversion de couleur, une normalisation — et c’est précisément là que vivent les bugs silencieux. Au-delà, il reste des problèmes où un seuillage et une opération morphologique résolvent en vingt lignes ce qu’un réseau de neurones approcherait avec dix mille labels : caméra fixe, éclairage contrôlé, pièces très contrastées sur un convoyeur. Y dégainer un modèle n’est pas de la sophistication, c’est du gaspillage. Les ingénieurs qu’on veut embaucher savent quel outil le problème mérite.
De combien de données annotées ai-je réellement besoin ?
Bien moins que vous ne le craignez, et de bien meilleure qualité que ce que vous prévoyiez. Fine-tuner un backbone pré-entraîné pour une tâche étroite sur une caméra fixe fonctionne souvent avec quelques centaines d’images bien choisies, et quelques centaines d’images de la vraie caméra de déploiement battront plusieurs milliers d’images ramassées sur internet, à chaque fois. L’erreur est d’optimiser le volume : les équipes annotent dix mille images faciles du cas évident et aucune de la porte à midi, puis s’étonnent que le modèle échoue précisément là où ça compte. Annotez les cas durs, annotez les échecs que votre modèle produit sur le terrain, et réannotez tout ce sur quoi deux annotateurs ont divergé. Deux cents images difficiles valent mieux que cinq mille faciles.
Mon détecteur a un bon score sur mon jeu de test mais échoue sur site. Que s’est-il passé ?
Presque certainement l’une de ces trois choses, par ordre de probabilité décroissante. Votre jeu de test n’en est pas un : si vous avez splitté au hasard, des images du même clip se sont retrouvées des deux côtés, et le modèle est noté sur des images qu’il a de fait déjà vues. Ou votre prétraitement diffère entre entraînement et inférence — ordre des canaux, resize, constante de normalisation — ce qui vous coûte de l’accuracy sans jamais lever d’erreur. Ou le site ne ressemble tout simplement pas à votre donnée : autre angle, autre lumière, autre objectif, et le modèle n’a jamais eu sa chance. Vérifiez dans cet ordre. Ce n’est presque jamais l’architecture, et le mois passé à essayer un modèle plus gros est la façon la plus répandue de gâcher un trimestre dans ce domaine.
Parcours liés
Envie de suivre ce parcours avec un coach et une cohorte ?
Découvrir la 212AY Academy →