magicplan-AI, un voyage dans le monde merveilleux de l'apprentissage profond (Partie 2/3)

Itérer sur les données et le modèle pour atteindre des performances acceptables

Présentation des indicateurs de performance pertinents

Améliorer / augmenter l'ensemble de données d'entraînement

Jouer avec la fonction de perte

Explorer différentes architectures

Leçons apprises

À venir prochainement

Dans la première partie, nous avons vu comment les outils de Deep Learning d'aujourd'hui et les écosystèmes de données facilitent la création d'un prototype précoce pour évaluer la faisabilité d'une tâche courante de Deep Learning. Cela dit, il est d'une part possible d'avoir un prototype fonctionnel montrant le potentiel de l'approche, d'autre part il est nécessaire d'atteindre un niveau de détection suffisamment fiable pour permettre à la fonctionnalité d'être mise entre les mains de millions d'utilisateurs.

Itérer sur les données et le modèle pour atteindre des performances acceptables

Comme montré dans cette vidéo, l'objectif de magicplan-AI est de permettre à l'utilisateur d'ajouter une porte ou une fenêtre sur un mur donné, à la fois à la bonne position et avec la bonne taille en prenant simplement une photo de l'objet tout en capturant la pièce.

Cette capture doit être fiable en termes de localisation et de taille et en temps réel pour éviter de dégrader la qualité de la capture de la pièce déjà en production.

Par fiable, nous entendons plusieurs choses :

capacité à détecter l'existence d'une porte ou d'une fenêtre sur une image,
capacité à classer correctement comme fenêtre ou porte l'objet détecté,
capacité à fournir une boîte englobante précise pour l'objet détecté.

Cette capture doit être fiable en termes de localisation et de taille et en temps réel pour éviter de dégrader la qualité de la capture de la pièce déjà en production.

Par fiable, nous entendons plusieurs choses :

capacité à détecter l'existence d'une porte ou d'une fenêtre sur une image,
capacité à classer correctement comme fenêtre ou porte l'objet détecté,
capacité à fournir une boîte englobante précise pour l'objet détecté.

Présentation des indicateurs de performance pertinents

Pour mesurer la performance d'un tel système, nous utilisons une métrique appelée F1 , qui "résume" en une seule valeur la combinaison de la plupart des exigences ci-dessus (facteurs importants tels que les vrais positifs, les faux positifs et les faux négatifs).

Note : il existe d'autres métriques comme la mAP (moyenne de précision) qui sont plus complètes, mais par souci de simplicité, je resterai avec F1 dans cette histoire. Il est important de comprendre qu'en fonction du scénario d'utilisation pour un détecteur d'objet donné, des erreurs de nature différente peuvent avoir un impact très dissemblable.

Une illustration puissante de cela est un détecteur de cellules cancéreuses, pour lequel l'impact de ne pas détecter une réelle cellule cancéreuse a des conséquences catastrophiques par rapport à l'impact de classifier à tort une cellule saine.

La même asymétrie existe dans le scénario de capture de magicplan :

classer incorrectement une fenêtre correctement détectée et cadrée comme une porte est facile à corriger par l'utilisateur avec l'interface utilisateur appropriée (opération en un clic),
à l'opposé, mal ajuster la boîte englobante d'une fenêtre correctement détectée et classifiée obligera l'utilisateur à passer en mode édition et à saisir la bonne mesure obtenue par d'autres moyens (très chronophage et perturbant).

Cette asymétrie dans le coût des erreurs de détection d'objet doit être reflétée dans les métriques utilisées en traitant spécifiquement chaque type d'erreur. Une fois les métriques définies, nous pouvons nous fier à une approche quantitative pour évaluer les différentes itérations de notre détecteur d'objet :

notre modèle POC "SSD Inception V2" entraîné avec la base de données ImageNet avait un score F1 de 0.62,
qualitativement, le modèle POC ne parvenait pas à détecter certains types de portes et manquait de précision dans la boîte englobante.

Trois méthodes ont été utilisées pour améliorer le score F1 :

améliorer / augmenter le jeu de données d'entraînement, jouer avec
la fonction de perte,
explorer différentes architectures.

La même asymétrie existe dans le scénario de capture de magicplan :

classer incorrectement une fenêtre correctement détectée et cadrée comme une porte est facile à corriger par l'utilisateur avec l'interface utilisateur appropriée (opération en un clic),
à l'opposé, mal ajuster la boîte englobante d'une fenêtre correctement détectée et classifiée obligera l'utilisateur à passer en mode édition et à saisir la bonne mesure obtenue par d'autres moyens (très chronophage et perturbant).

notre modèle POC "SSD Inception V2" entraîné avec la base de données ImageNet avait un score F1 de 0.62,
qualitativement, le modèle POC ne parvenait pas à détecter certains types de portes et manquait de précision dans la boîte englobante.

Trois méthodes ont été utilisées pour améliorer le score F1 :

améliorer / augmenter le jeu de données d'entraînement, jouer avec
la fonction de perte,
explorer différentes architectures.

Améliorer / augmenter l'ensemble de données d'entraînement

Dans le monde de l'apprentissage profond, les données sont essentielles et il existe de nombreuses techniques identifiées pour améliorer la base de données d'entraînement. La première est évidemment d'augmenter la taille de l'ensemble de données d'entraînement en ajoutant plus d'images ou des techniques d'augmentation de données. Mais étonnamment, pour nous, l'amélioration la plus significative est venue du nettoyage de la base de données annotée ImageNet.

Il y a plusieurs raisons à cela :

1. toutes les images avec des portes ou des fenêtres ne sont pas pertinentes pour les cas d'utilisation des intérieurs magicplan — nous appelons cela un problème de décalage de domaine,

magic plan example showing object detection highlighting a warehouse door in an image

Ce n'est pas le type de porte qui nous intéresse !

2. porte et fenêtres sont des mots génériques que l'on peut trouver dans des situations n'ayant rien à voir avec un intérieur de maison — nous appelons cela un problème de décalage sémantique,

magic plan object detection applied to an aircraft on a runway

Une fenêtre d'avion n'est pas une fenêtre de maison !

3. l'annotation par crowdsourcing a ses limites et des erreurs peuvent être incluses dans l'annotation — nous appelons cela un problème de mauvaise annotation,

magic plan object detection highlighting bathroom fixtures in an indoor scene

Mauvaise annotation !

4. il est acceptable d'annoter seulement une fenêtre dans une image contenant plusieurs fenêtres pour une tâche de classification, mais il n'est pas acceptable d'oublier d'annoter les fenêtres visibles pour une tâche de détection d'objets — nous appellerions cela un problème d'annotation partielle,

magic plan object detection highlighting a door inside an interior room

Quelqu'un a oublié d'annoter les fenêtres !

5. nous avons réalisé que les portes lorsqu'elles sont ouvertes peuvent poser problème pour magicplan-AI car nous cherchons en fait le cadre de la porte, et non la partie mobile — nous appelons cela un problème de décalage d'annotation de tâche.

magic plan object detection identifying an open door in an indoor environment

Pas la partie de la porte que nous voulons détecter !

Pour chaque type de problème, une solution a été identifiée et appliquée.

Problèmes et solutions de l'ensemble d'entraînement

La révision de l'ensemble de données d'entraînement et la suppression, la réannotation ou le rééquilibrage des images ont amélioré le score F1 de plus de 23 %, atteignant un intéressant 0,85.

Il y a plusieurs raisons à cela :

1. toutes les images avec des portes ou des fenêtres ne sont pas pertinentes pour les cas d'utilisation des intérieurs magicplan — nous appelons cela un problème de décalage de domaine,

Ce n'est pas le type de porte qui nous intéresse !

Une fenêtre d'avion n'est pas une fenêtre de maison !

3. l'annotation par crowdsourcing a ses limites et des erreurs peuvent être incluses dans l'annotation — nous appelons cela un problème de mauvaise annotation,

Mauvaise annotation !

Quelqu'un a oublié d'annoter les fenêtres !

Pas la partie de la porte que nous voulons détecter !

Pour chaque type de problème, une solution a été identifiée et appliquée.

Problèmes et solutions de l'ensemble d'entraînement

Jouer avec la fonction de perte

Entraîner correctement un modèle en Deep Learning dépend autant du bon ensemble de données que de la bonne correction lorsqu'une erreur est trouvée pendant l'entraînement.

Heureusement pour nous, une vaste littérature est disponible sur l'identification de la bonne fonction de perte à utiliser. Encore mieux, dans le cas particulier de la détection d'objets, le projet Facebook Detectron a identifié des améliorations clés dans la manière d'appliquer la bonne fonction de perte, appelée Focus Loss, qui étaient très faciles à implémenter pour nous.

En conséquence, en combinant l'amélioration de la qualité de la base de données d'entraînement avec l'introduction d'une fonction de perte mieux adaptée, nous avons pu améliorer significativement le score F1 comme l'illustre ci-dessous.

Évolution du score F1 en fonction des corrections de l'ensemble d'entraînement

Explorer différentes architectures

La recherche académique a été assez active dans le domaine de la Détection d'Objets et plusieurs architectures sont disponibles pour l'Apprentissage Profond de la Détection d'Objets. Elles peuvent être regroupées selon deux axes :

A — le type d'extracteur de caractéristiques qui traite l'image d'entrée :

Plusieurs architectures allant de légères (MobileNet) à lourdes (Inception, VGG, ResNet)…
plus l'extracteur de caractéristiques est grand en termes de paramètres, meilleurs sont les descripteurs mais plus cela prend de mémoire et de temps pour effectuer

B — le nombre d'étapes pour effectuer la détection complète :

approche directe en avant (YOLO, SSD) où un seul réseau détectera les boîtes englobantes et les classera en même temps,
approche en deux étapes (Faster RCNN, R-FCN) où un premier réseau détecte les candidats aux boîtes englobantes rugueuses tandis que le second effectue la classification et le réglage fin des boîtes englobantes.

Comme prévu, plus l'architecture est complexe, meilleure est la performance (voir graphique ci-dessous).

magic plan performance comparison chart showing object detection models by accuracy and processing speed

Architectures de Détection d'Objets et performances (ensemble de données COCO) — Source

Cependant, ce que nous avons découvert assez tôt, c'est que même pour la tâche d'inférence (la tâche de faire fonctionner le modèle pour effectuer la détection d'objets sur une image — pas la tâche d'entraînement qui nécessite beaucoup plus de ressources), toutes les architectures ne s'adaptent pas aux contraintes de fonctionnement sur un appareil mobile.

Deux raisons à cela :

contrairement aux cartes GPU modernes avec plus de 10 Go de RAM, même le dernier iPhone X n'a que 3 Go de RAM,
la contrainte en temps réel signifie que nous ne pouvons pas nous permettre qu'une reconnaissance d'objet dure plus de 1,0 seconde sans créer un décalage vraiment ennuyeux dans l'expérience utilisateur.

Certaines architectures ne tiennent pas en mémoire sur l'appareil. D'autres le font MAIS cela prend plusieurs secondes pour traiter une détection d'objet, ce qui n'est pas acceptable dans le scénario de capture en temps réel de magicplan.

Évaluation de plusieurs architectures

Leçons apprises

Contrairement à la première étape « rapide et facile », pouvoir jouer avec toutes les options des modèles « prêts à l’emploi » nécessite plusieurs conditions :

une bonne méthodologie pour mesurer objectivement le progrès,
une bonne compréhension de ce qui rend une convergence d’entraînement réussie et ce qui peut la rompre,
une bonne compréhension de l'architecture et des nœuds sous-jacents des réseaux neuronaux,

Dans notre cas, cela n’aurait pas pu se produire sans la présence de deux doctorants à plein temps en intelligence artificielle / apprentissage profond dans l'équipe qui maîtrisent ces défis.

À venir prochainement

À ce stade, nous avons un modèle de pointe qui fait un bon travail en détection d'objets mais qui est trop grand pour fonctionner sur un smartphone moderne. Dans la dernière partie, nous décrirons plus en détail le travail nécessaire pour passer d'une solution basée sur PC à une solution intégrée dans un smartphone.