Alexander Hirner, der CTO & Co-Founder von MoonVision & Dishtracker, gibt im Gespräch mit Anthony Kelly von SODA in unserem 2. Teil weitere spannende technische Einblicke zu seinen Anfängen mit Computer Vision und Deep Learning, den häufigsten Fehlern bei Modellvorhersagen und dem Übergang von der Forschung in die Praxis.
Alex: Wir verwenden hauptsächlich Tracking, Objekterkennung und “few-shot” Klassifizierung. Um Qualitätsbereiche zu bestimmen, verwenden wir Segmentierung, die wir auch zu Instanz-Segmentierungs-Aufgaben kombinieren. All diese Techniken sind jetzt abstrahiert und generisch, aber sie lassen sich auf spezifische Anwendungsfälle herunterbrechen. “What goes with our DNA” ist die schnelle Erzeugung von qualifizierten Trainingsdaten günstiger Eingangssignale. Wir kommen sehr schnell vom Video zu geeigneten Trainingsdaten und zu passenden Algorithmen wie dem überwachten Training.
Alex: Jede Lösung besteht aus Zählungen oder einer qualitativen Beurteilung. Bei unseren Anwendungen kann es auch zu Meinungsverschiedenheiten bei Experten kommen. Ein Beispiel: Wenn Experte A in Irland auf eine Holzoberfläche schaut, könnte er sagen, “Hey, diesen Bereich kann ich im Innenraum meines Autos nicht verwenden, und diesen kann ich verwenden”, dann kann es andere Experten in Deutschland geben, die ihm hier nicht zustimmen und zu anderen Ergebnissen kommen würden. Daher ist dies die perfekte Umgebung für eine KI, da es sich um eine komplexe und subjektive Sehaufgabe handelt. Die Hauptbereiche liegen in der Qualitätsbeurteilung von natürlichen Oberflächen zum Beispiel bei Leder und Holz. Hier hatten wir viele erfolgreiche Projekte, um unsere Plattform mithilfe von Trainingsdaten und Algorithmen aufzubauen.
Alex: Bei der Erstellung eines Systems muss man die Datenerfassung-Pipeline, die Werkzeuge, die Art der Einrichtung, das rohe (unbearbeitete) Eingangssignal oder zumindest die Filterung von diesem Signal besitzen oder etwa kontrollieren. Man kann zum Beispiel immer mit einem beliebigen Signal beginnen. Softwaretechnisch muss man dann die relevanten Trainingsbilder auswählen. Im Laufe unserer Projekte haben wir viele verschiedene Kameras verwendet. Wir haben mit einer normalen Raspberry Pi V2-Kamera angefangen und sie an die Decke im Oktoberfestzelt montiert. Ich hab sie angeschraubt und einen kleinen TCP-Server geschrieben, der das Video in die GPU-Maschine streamte. Von da ausgehend haben wir die Video-Eingangsschichten abstrahiert, um mit Machine-Vision-Kameras, dem Genicam-Standard, USB-Kameras und IP-Kameras über verschiedene Protokolle sowie über das Web kompatibel zu werden
Alex: Man muss die Stärken und Schwächen des Algorithmus genau kennen, der einem schließlich die gewünschte Vorhersage liefert. Im Sinne der Objekterkennung möchte man eine vollständige Annotation mit allen Objekten, die von dieser Klasse sind, erreichen. Man sollte sich nicht auf bewegungsunscharfe Szenen verlassen, in welchen ein Mensch das Objekt erkennen kann, weil zwei Bilder zuvor nicht bewegungsunscharf waren. Man will also die Vorhersage auf Basis eines isolierten Bildes gewährleisten. So sollten die Trainingsdaten aussehen und so sollte das Tooling aufgebaut sein. Wir haben mit einem Rohvideo begonnen, dann wählt ein eigens entwickelter Algorithmus Szenen aus, in denen zwar viel bewegt wurde, aber mit Stellen wo ab und an wenig Bewegung herrschte. Von solchen Frames geht man aus. Des Weiteren haben wir haben einen Algorithmus zur Objekterkennung entwickelt, der Basiselemente ausgibt. Man muss die möglichen Formen gut an die Domain anpassen. Am Anfang waren es Kreise, weil das Essen rund ist und man weniger Klicks benötigt. Danach muss man die Annotationsarbeit parallelisieren. Wir haben es so gemacht, dass die Labels, die eine Person zur Verfügung stellt, augenblicklich zu Empfehlungen für die nächste Person werden. Dadurch vermeidet man ein Abdriften im Konzept dessen, was annotiert werden soll, weil es durch die Empfehlungen des Systems synchronisiert wird. Schließlich möchte man einen Feedback Kanal vom trainierten Modell haben. Was sind die falsch-positiven oder falsch-negativen Ergebnisse? Man findet Labeling Fehler, die man zuvor nicht erwartet hat. Schließlich wird man diese Fehler los und der Kreislauf setzt sich fort.
Alex: Wir haben eine Pipeline, welche Daten QA mit Modell-Introspektion kombiniert, was sehr wichtig ist. Die Quantifizierung der Unsicherheit jeder Vorhersage ist also der Heilige Gral. Und warum? Wenn man ein Modell hat, dass in der Lage ist zu sagen was es nicht weiß, kann man ihm durchaus etwas beibringen. Wenn es unmöglich ist mehr Vorhersagen zu bekommen, dann bekommt man wenigstens ein sicheres Ergebnis, schließlich hat man Fallback-Mechanismen. Das heißt Modell-Introspektion, was bedeutet, dass zu aller erst die richtige Annahme für das Erkennungsproblem getroffen werden sollte. Im Falle der Klassifizierung “in the wild” ist dies ein offenes Mengenerkennungsproblem. Man muss Modell-Unsicherheiten pixelgenau quantifizieren, um solche Unsicherheiten zu korrigieren und den Datenerfassungsprozess anzuleiten. Das ist im Grunde eine klassische Active-Learning-Denkweise. Man macht Vorhersagen, und fragt sich, ob es sich lohnt diese Daten als Trainingsdaten neu zu betrachten, um das Modell weiter zu verbessern. Es gibt einen Moment der Produktionsreife, und das passiert sehr oft in industriellen Anwendungen, in der Qualitätssicherung, bei Zählaufgaben, wie z.B. bei Containern, und Geschirrspülern, wo das Modell die durchschnittliche Intelligenz der Experten ist. In manchen Fällen bedeutet das, dass es genauer ist als die Experten. Dann kann man dem System wirklich vertrauen, dass, wenn man neue Daten zu Validierungszwecken etc. eingibt, dass jede falsche Vorhersage etwas Neues oder falsch Bezeichnetes ist. Dann hat man im Grunde schon gewonnen. Wenn man also alle diese Pipelines eingerichtet und eine gewisse Produktionsreife erreicht hat, dann ist es einfach, sich an kleine Veränderungen in einer Domain anzupassen. Und das ist es, was man erreichen will. Deshalb ist das Kaltstartproblem im Grunde das eigentliche Problem.
Alex: Fehler bei der Datenaufbereitung können sein, dass man versehentlich einige Annotationen herausfiltert und man dann falsch-negative Ergebnisse bekommt. Daher hat man diese Fehler, die man schlussendlich einfach auf einen Tippfehler zurückführen kann. Es gibt fehlerhafter Vorhersagen, die sich im Nachhinein nicht auf einen bestimmten Fehler in der Modellierung oder den Daten erklären lassen. Diese unerwarteten oder erweiterten Fehler sind etwas, an denen wir immer arbeiten und auf der Hut sein müssen, bis es wirklich ein stabiles System in einem angepassten System gibt. Im Allgemeinen sind diese Fehler auf eine Überanpassung zurückzuführen, von der man nichts weiß. Das Modell achtet also auf Features, von denen man nicht dachte, dass es eine Abkürzung gibt. Daher braucht man eine Art von qualitativen Antworten vom Modell, denn man hat keine Größen, auf die man sich verlassen kann, wenn das Ergebnis eine saubere Vorhersage ist. Hierzu sind Aufmerksamkeit Mechanismen sehr hilfreich.
Alex: Wir sind große Nutznießer der Forschung, sowohl in Bezug auf Bibliotheken und Open Source, angefangen von PyTorch und seinem Ökosystem bis hin zu Research Papers, die interessante Wege einschlagen, die wir mit einem praktischen Ansatz kombinieren können. Die Kombination aus Allem ist die Sache, die fehlt. In der Praxis kommen die Probleme also in einer kombinierten Form. In der Wissenschaft geht man diesen isoliert nach. Bei der Bildklassifikation gibt es Paper, die einem sagen wie man mit verrauschten Labels am besten umgeht. Dasselbe gilt bei ausgewogenen versus unausgewogenen Datensätze, feinkörnigen Klassifikations-Aufgaben, Domänen-Verschiebungen etc. Für diese relevanten Bereiche gibt es also einzelne Benchmarks und sehr intelligente Ansätze. Manchmal auch sehr komplizierte und sinnlose Ansätze. Aber immerhin gibt es messbare Fortschritte. In der Praxis hat man verrauschte Labels, unausgewogene Daten, Unstimmigkeiten zwischen der Feinkörnigkeit zwischen Tests und Training und Domänenverschiebungen, alles auf einmal. Das bedeutet, man wählt zB. einen Ansatz aus der Literatur der Beispiele sucht, um das Leichte mit dem Schwierigen auszugleichen. Man wird aber auch Beschriftungsfehler haben. Was man damit also tatsächlich lernt, sind schwere und falsche Beispiele, und man lernt sie sehr rigoros. Und das ist nicht die vollständige Lösung, denn man möchte ein schweres Beispiel nicht sehr rigoros lernen, wenn es falsch ist. Bis jetzt gibt es noch keine guten Antworten im akademischen Bereich, aber es gibt gute Antworten in der Praxis. In der Praxis würde man den Menschen in der Schleife haben und Daten zyklisch verbessern. Das ist normalerweise nicht die Art und Weise, wie der akademische Bereich hier aufgebaut ist. Es gibt Literatur zu Orakel, die aktives Lernen emulieren, aber das ist bei weitem ein weniger schwergewichtiges Feld als die Kombination dieser Probleme.
“Bis jetzt gibt es noch keine guten Antworten im akademischen Bereich, aber es gibt gute Antworten in der Praxis.“
Alexander Hirner
Alex: Mein erster Ratschlag wäre ein End-to-End-System zu erstellen, das einem am Herzen liegt, und das selbst für die Beschaffung und Umwandlung der Daten verantwortlich ist. Das wird einem Intuitionen und Ideen geben, die wahrscheinlich außerhalb dessen liegen, was man mit vorbereiteten Herausforderungen erreichen könnte. Oder in einem rein akademischen Kontext sich bei der Erstellung von Benchmarks zu engagieren. Also jene Bereiche heraussuchen, die vom Mainstream abzweigen und eine Rückkopplungsschleife zu den Daten enthalten bzw. zu jenen Bereichen, die mit unvollständigen Daten umgehen, wie sie in unserer Welt vorkommen.
0:26 Alexander Hirner – CTO & CoFounder von Moonvision/Dishtracker
5:02 Die Idee von Moonvision und Dishtracker
11:55 Einführung in CV und Deep Learning: Wie haben wir angefangen?
15:01 Feuerprobe – Oktoberfest: Größte Learnings & Takeaways
19:20 Daten-Annotation & Q&A für CV
29:05 Was macht den Schritt von der Forschung zur Produktion so schwierig?