magicplan-AI, eine Reise in die wunderbare Welt des Deep Learning (Teil 2/3)

In Teil 1 haben wir gesehen, wie die heutigen Deep-Learning-Tools und Datenökosysteme es einfach machen, einen frühen Prototypen zu erstellen, um die Machbarkeit einer gemeinsamen Deep-Learning-Aufgabe zu beurteilen. Das gesagt, es ist eine Sache, einen funktionsfähigen Prototyp zu haben, der das Potenzial des Ansatzes zeigt; es ist eine andere Sache, ein zuverlässig genuges Niveau der Erkennung zu erreichen, um das Feature Millionen von Nutzern zur Verfügung zu stellen.

Daten und Modelle iterieren, um akzeptable Leistung zu erreichen

Wie in diesem Video gezeigt, ist das Ziel von magicplan-AI, dem Benutzer zu ermöglichen, eine Tür oder ein Fenster an einer bestimmten Wand hinzuzufügen, sowohl an der richtigen Position als auch in der richtigen Größe, indem einfach ein Bild des Objekts aufgenommen wird, während der Raum erfasst wird.

Diese Aufnahme muss in Bezug auf Standort und Größe zuverlässig und in Echtzeit sein, um die Qualität der bereits in Produktion befindlichen Raumaufnahmen nicht zu mindern.

Unter zuverlässig verstehen wir mehrere Dinge:

Fähigkeit, das Vorhandensein einer Tür oder eines Fensters auf einem Bild zu erkennen,
Fähigkeit, das erkannte Objekt korrekt als Fenster oder Tür zu klassifizieren,
Fähigkeit, ein genaues Begrenzungsfeld für das erkannte Objekt bereitzustellen.

Diese Aufnahme muss in Bezug auf Standort und Größe zuverlässig und in Echtzeit sein, um die Qualität der bereits in Produktion befindlichen Raumaufnahmen nicht zu mindern.

Unter zuverlässig verstehen wir mehrere Dinge:

Fähigkeit, das Vorhandensein einer Tür oder eines Fensters auf einem Bild zu erkennen,
Fähigkeit, das erkannte Objekt korrekt als Fenster oder Tür zu klassifizieren,
Fähigkeit, ein genaues Begrenzungsfeld für das erkannte Objekt bereitzustellen.

Vorstellung relevanter Leistungskennzahlen

Um die Leistung eines solchen Systems zu messen, verwenden wir eine Metrik namens F1, die in einem einzigen Wert die Kombination der meisten oben genannten Anforderungen (wichtige Faktoren wie wahre Positive, falsche Positive und falsche Negative) zusammenfasst.

Hinweis: Es gibt andere Metriken wie die mAP (mean Average Precision), die vollständiger sind, aber der Einfachheit halber werde ich in dieser Geschichte bei F1 bleiben. Es ist wichtig zu verstehen, dass je nach Nutzungsszenario eines bestimmten Objektdetektors Fehler unterschiedlicher Art sehr unterschiedliche Auswirkungen haben können.

Eine eindrucksvolle Veranschaulichung dafür ist ein Krebszellen-Detektor, bei dem die Auswirkung, eine echte krebserregende Zelle nicht zu erkennen, katastrophale Folgen hat im Vergleich zu der Auswirkung, eine gesunde Zelle fälschlicherweise zu klassifizieren.

Die gleiche Asymmetrie existiert im magicplan-Erfassungs-Szenario:

einen korrekt erkannten und gerahmten Fenster falsch als Tür zu klassifizieren, ist für den Benutzer leicht durch die richtige Benutzeroberfläche (Ein-Klick-Operation) zu korrigieren,
im Gegensatz dazu zwingt eine schlecht angepasste Begrenzungsbox eines korrekt erkannten und klassifizierten Fensters den Benutzer, in den Bearbeitungsmodus zu wechseln und die richtigen Maße, die auf anderem Wege erhalten wurden, einzugeben (sehr zeitaufwendig und störend).

Diese Asymmetrie in den Kosten von Fehlern bei der Objekterkennung muss sich in den verwendeten Metriken widerspiegeln, indem speziell jeder Fehlertyp behandelt wird. Sobald die Metriken definiert sind, können wir uns auf einen quantitativen Ansatz verlassen, um die verschiedenen Iterationen unseres Objektdetektors zu bewerten:

unser POC “SSD Inception V2”-Modell, das mit der ImageNet-Datenbank trainiert wurde, hatte einen F1-Score von 0,62,
qualitativ war das POC-Modell nicht in der Lage, einige Türtypen zu erkennen und fehlte an Genauigkeit in der Begrenzungsbox.

Drei Methoden wurden verwendet, um den F1-Score zu verbessern:

Verbesserung / Erweiterung des Trainingsdatensatzes, indem man mit
der Verlustfunktion spielt,
verschiedene Architekturen erkundet.

Die gleiche Asymmetrie existiert im magicplan-Erfassungs-Szenario:

einen korrekt erkannten und gerahmten Fenster falsch als Tür zu klassifizieren, ist für den Benutzer leicht durch die richtige Benutzeroberfläche (Ein-Klick-Operation) zu korrigieren,
im Gegensatz dazu zwingt eine schlecht angepasste Begrenzungsbox eines korrekt erkannten und klassifizierten Fensters den Benutzer, in den Bearbeitungsmodus zu wechseln und die richtigen Maße, die auf anderem Wege erhalten wurden, einzugeben (sehr zeitaufwendig und störend).

unser POC “SSD Inception V2”-Modell, das mit der ImageNet-Datenbank trainiert wurde, hatte einen F1-Score von 0,62,
qualitativ war das POC-Modell nicht in der Lage, einige Türtypen zu erkennen und fehlte an Genauigkeit in der Begrenzungsbox.

Drei Methoden wurden verwendet, um den F1-Score zu verbessern:

Verbesserung / Erweiterung des Trainingsdatensatzes, indem man mit
der Verlustfunktion spielt,
verschiedene Architekturen erkundet.

Verbesserung / Erweiterung des Trainingsdatensatzes

In der Welt des Deep Learning sind Daten der Schlüssel, und es gibt viele identifizierte Techniken zur Verbesserung der Trainingsdatenbank. Das Erste ist offensichtlich, die Größe des Trainingsdatensatzes zu erhöhen, indem man weitere Bilder hinzufügt oder Techniken zur Datenaugmentation anwendet. Aber überraschenderweise kam für uns die bedeutendste Verbesserung durch die Bereinigung der annotierten ImageNet-Datenbank.

Es gibt mehrere Gründe dafür:

1. Nicht alle Bilder mit Türen oder Fenstern sind für die Nutzungsszenarien von magicplan-Innenräumen relevant — wir nennen dies ein Problem des Domänenwechsels,

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

Nicht der Türtyp, der uns interessiert!

2. Türen und Fenster sind generische Wörter, die man in Situationen finden kann, die nichts mit einem Hausinneren zu tun haben — wir nennen dies ein Problem des semantischen Wechsels,

magic plan object detection applied to an aircraft on a runway

Ein Flugzeugfenster ist kein Fenster eines Hauses!

3. Crowdsourcing-Annotationen haben ihre Grenzen und Fehler können in die Annotation integriert werden — wir nennen dies ein Problem der Fehlannotation,

magic plan object detection highlighting bathroom fixtures in an indoor scene

Falsche Annotation!

4. Während es in Ordnung ist, nur ein Fenster in einem Bild mit mehreren Fenstern für eine Klassifikationsaufgabe zu annotieren, ist es nicht in Ordnung, sichtbare Fenster bei einer Objekterkennungsaufgabe zu vergessen — wir würden dies ein Problem der Teil-Annotation nennen,

magic plan object detection highlighting a door inside an interior room

Jemand hat vergessen, die Fenster zu annotieren!

5. Wir haben festgestellt, dass Türen, wenn sie offen gefilmt werden, problematisch für die magicplan-AI sein können, da wir tatsächlich nach dem Türrahmen suchen, nicht nach dem beweglichen Teil — wir nennen dies ein Problem der Aufgaben-Annotation.

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

Nicht der Teil der Tür, den wir erkennen wollen!

Für jede Art von Problem wurde eine Lösung identifiziert und angewendet.

Probleme und Lösungen im Trainingsdatensatz

Ein erneutes Überprüfen des Trainingsdatensatzes und das Entfernen, Neuannotieren oder Neuwiegen von Bildern verbesserten den F1-Score um mehr als 23 %, was einen interessanten Wert von 0,85 erreichte.

Es gibt mehrere Gründe dafür:

1. Nicht alle Bilder mit Türen oder Fenstern sind für die Nutzungsszenarien von magicplan-Innenräumen relevant — wir nennen dies ein Problem des Domänenwechsels,

Nicht der Türtyp, der uns interessiert!

2. Türen und Fenster sind generische Wörter, die man in Situationen finden kann, die nichts mit einem Hausinneren zu tun haben — wir nennen dies ein Problem des semantischen Wechsels,

Ein Flugzeugfenster ist kein Fenster eines Hauses!

3. Crowdsourcing-Annotationen haben ihre Grenzen und Fehler können in die Annotation integriert werden — wir nennen dies ein Problem der Fehlannotation,

Falsche Annotation!

Jemand hat vergessen, die Fenster zu annotieren!

Nicht der Teil der Tür, den wir erkennen wollen!

Für jede Art von Problem wurde eine Lösung identifiziert und angewendet.

Probleme und Lösungen im Trainingsdatensatz

Spielen mit der Verlustfunktion

Ein Modell im Deep Learning korrekt zu trainieren, hat ebenso viel mit dem richtigen Datensatz zu tun wie mit der richtigen Korrektur, wenn während des Trainings ein Fehler gefunden wird.

Glücklicherweise steht uns eine große Literatur zur Verfügung, die dabei hilft, die richtige Verlustfunktion zu identifizieren, die verwendet werden soll. Noch besser ist, dass im speziellen Fall der Objekterkennung das Facebook Detectron-Projekt einige wichtige Verbesserungen in der Anwendung der richtigen Verlustfunktion, die als Focus Loss bezeichnet wird, identifiziert hat, die für uns sehr einfach umzusetzen waren.

Infolgedessen konnten wir, indem wir die Qualität des Trainingsdatenbankverbesserung mit der Einführung einer besser angepassten Verlustfunktion kombinierten, den F1-Score deutlich verbessern, wie unten veranschaulicht.

F1-Score-Entwicklung according to Training set fixes

Unterschiedliche Architekturen erkunden

Akademische Forschung war im Bereich der Objekterkennung ziemlich aktiv, und es sind mehrere Architekturen für Deep Learning zur Objekterkennung verfügbar. Sie können entlang zweier Achsen gruppiert werden:

A — die Art des Merkmals-Extractors, der das Eingabebild verarbeitet:

Mehrere Architekturen von leicht (MobileNet) bis schwer (Inception, VGG, ResNet)…
je größer der Merkmal-Extractor in Bezug auf die Parameter, desto besser die Beschreibungen, aber desto mehr Speicher und Zeit benötigt es zur Durchführung

B — die Anzahl der Schritte, um die vollständige Erkennung durchzuführen:

direkter Vorwärtsansatz (YOLO, SSD), bei dem ein einzelnes Netzwerk die Begrenzungsrahmen erkennt und sie gleichzeitig klassifiziert,
Zwei-Schritte-Ansatz (Faster RCNN, R-FCN), bei dem ein erstes Netzwerk potenzielle grobe Begrenzungsrahmenkandidaten erkennt, während das zweite die Klassifikation und Feinabstimmung der Begrenzungsrahmen durchführt.

Wie erwartet, desto komplexer die Architektur, desto besser die Leistung (siehe Grafik unten).

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

Architekturen zur Objekterkennung und Leistungen (COCO-Datensatz) — Quelle

Was wir jedoch ziemlich früh entdeckten, ist, dass selbst für die Inferenzaufgabe (die Aufgabe, das Modell auszuführen, um die Objekterkennung auf einem Bild durchzuführen — nicht die Trainingsaufgabe, die viel mehr Ressourcen erfordert) nicht alle Architekturen den Anforderungen entsprechen, auf einem mobilen Gerät ausgeführt zu werden.

Zwei Gründe dafür:

Im Gegensatz zu modernen GPU-Karten mit mehr als 10Gb RAM hat selbst das neueste iPhone X nur 3Gb RAM,
Echtzeitbeschränkungen bedeuten, dass wir uns keine Objekterkennung leisten können, die länger als 1,0 Sekunden dauert, ohne eine wirklich lästige Verzögerung im Benutzererlebnis zu erzeugen.

Einige Architekturen passen nicht in den Speicher des Geräts. Einige andere tun dies, ABER es dauert mehrere Sekunden, um eine Objekterkennung durchzuführen, was im Szenario der sofortigen Erfassung von Magicplan nicht akzeptabel ist.

Bewertung mehrerer Architekturen

Gelerntes aus Erfahrungen

Im Gegensatz zur ersten „schnellen & einfachen“ Phase erfordert das Spielen mit all den Optionen in den „regalverfügbaren“ Modellen mehrere Bedingungen:

eine gute Methodik, um den Fortschritt objektiv zu messen,
ein gutes Verständnis dafür, was eine gute Trainingskonvergenz ausmacht und was sie brechen kann,
ein gutes Verständnis der zugrunde liegenden Architektur der neuronalen Netze und Knoten,

In unserem Fall hätte dies ohne die Anwesenheit von zwei Vollzeit-PhDs in künstlicher Intelligenz / Deep Learning im Team, die diese Herausforderungen beherrschen, nicht stattfinden können.

Kommende nächste

An diesem Punkt haben wir ein erstklassiges Modell, das gut bei der Objekterkennung arbeitet, aber zu groß ist, um auf einem modernen Smartphone ausgeführt zu werden. Im letzten Teil werden wir die erforderliche Arbeit detaillierter beschreiben, um von einer PC-basierten Lösung zu einer eingebetteten Smartphone-Lösung überzugehen.