Wo liegen derzeit (noch) die Probleme beim Deep Learning?

Derzeit fehlt Anwendern meist noch die Erfahrung, welcher der zahlreichen KI-Lösungen für ihre Aufgabenstellung die Richtige ist. Daher hat inVISION bei Cubemos, EvoTegra, MVTec und Ruhlamat nachgefragt, worauf man bei der Auswahl der richtigen KI-Lösung achten sollte.

inVISION: Wo liegen die Unterschiede zwischen den verschiedenen Deep Learning Tools?

Tobias Manthey (EvoTegra): Für uns hängt die Auswahl von den folgenden Kriterien ab: welche Modelle werden unterstützt und welche Integrationsmöglichkeiten gibt es für den professionellen Einsatz (C++, TensorRT). Grundsätzlich muss man beachten, dass Open Source Deep Learning Frameworks aus der Forschung kommen und für die Forschung angedacht sind, d.h. Stabilität, Übertragbarkeit auf reale Anwendungen und Bedienbarkeit sind keine Kriterien für die Entwicklung. Die meisten Open Source Deep Learning Frameworks stellen im Prinzip Anwendungen im Alpha Status dar.

Dr. Christopher Schweubel (Cubemos): Wir nutzen primär TensorFlow und PyTorch. Beides sind gute Frameworks um neuronale Netze zu trainieren und auf der Zielhardware zu implementieren. Die Zielhardware bestimmt meist, welches Framework wir verwenden, jedoch wird die Interoperabilität immer besser.

Mario Bohnacker (MVTec): Wenn man die verschiedenen Deep Learning (DL) Produkte vergleicht, stellt man fest, dass sie sich in ihrer Performance hinsichtlich der reinen Klassifikationsergebnisse oftmals gar nicht allzu sehr unterscheiden. Allerdings gibt es einen immensen Unterschied bei den DL-Produktmerkmalen, wenn man sich nicht nur das reine Klassifikationsergebnis ansieht. Ein Beispiel hierfür ist, wie DL-Algorithmen in industrielle Applikationen integriert bzw. wie schnell neue DL-Methodiken mit bestehender BV-Algorithmik kombiniert werden können? Ein weiterer Aspekt ist, wie die DL-Funktionalität für die Anwendungserstellung nutzbar gemacht wird (Programmieren vs. Konfigurieren), sowie ob zwischen verschiedenen Open-Source-Tools hin und her gewechselt werden muss, oder ob es sich um eine Gesamtlösung aus einer Hand handelt. Letzteres bringt eine gewisse Nachhaltigkeit und Langzeitverfügbarkeit mit sich. Bisher werden für DL-Anwendungen hauptsächlich GPUs eingesetzt. Es besteht jedoch auch eine Nachfrage zum Einsatz von DL auf IPCs, die keine Grafikkarte haben oder auf Arm-basierten Systemen. Der Markt für spezifische DL-Hardware ist derzeit sehr schnelllebig und ausdifferenziert, weshalb wir aktuell an einer generischen Möglichkeit arbeiten, Hardware-Beschleuniger zukünftig schnell in Halcon nutzbar zu machen.

Florian Weihard (Ruhlamat): The various DL tools can be mapped on two axes – complexity versus flexibility. With a high degree of flexibility comes greater complexity, and hence requires a specialized skillset of a data scientist. With low complexity comes some rigidity in applications or unsuitability or inaccuracies in a model that is developed. There are DL tools – mainly ’no-code‘ model training environments – that provide an extremely simple user interface that can train a very generic model. This results in the pitfall that the model that is trained is not particularly useful for its actual application. In case of industrial applications, it is always more helpful to have a model that is trained for a specific purpose rather than a generic model. Our EaglAI uses models that were initially developed for identifying features in satellite imagery, to do defect detection on injection moulded parts. This is because the two applications have a similarity in that they are trying to find a very tiny feature in a large image. There are also model execution frameworks available, mainly on cloud which are trickier to use. In industrial applications, a cloud-based solution is more likely to be an unsuitable solution, often replaced by on premise and offline execution systems. The model execution frameworks also tend to be very specific to the model type that it is designed to use – the outputs can vary (e.g. between classification models and object detection models), the underlying dependencies can also vary (e.g. between TensorFlow and PyTorch), and their hardware / computational requirements can also vary.

inVISION: Wie sieht es mit den ’30 Bilder für das Training‘-Ansätzen aus, bei denen die Anzahl der Bilder dann doch oft weit darüber liegen?

T. Manthey: Wer mit solchen Versprechen an den Markt geht hat sich als ernsthafter Anbieter von Deep Learning Anwendungen bereits disqualifiziert. Der Informationsgehalt (Entropie) der Trainingsdaten kann grundsätzlich nicht kleiner sein, als der Informationsgehalt der zu erkennenden Objekte. Mit 30 Bildern lässt sich vielleicht ein weißer Würfel auf einem schwarzen Band bei konstanten Lichtbedingungen in einer definierten Position erkennen. Ernsthafte Anwendungen benötigen meist wesentlich mehr Daten. Dank einem hohen Grad an Automatisierung ist dies jedoch für spezialisierte Anbieter kein Problem.

C. Scheubel: Wir sehen in unseren PoC Projekten eher 1.000 Bilder. Für Produktivsysteme eher Richtung 10.000 Bilder. Mit 30 Bildern haben wir noch keine funktionalen Systeme bekommen.

M. Bohnacker: Die 30 Bilder für das Training sind oftmals ein Werbeversprechen, das bei einigen wenigen optimalen Beispielanwendungen oder einfachen Problemstellungen durchaus funktioniert. Diese Problemstellungen lassen sich aber oft auch mit herkömmlicher BV und geringem Aufwand realisieren. Echte Problemstellungen, die für klassische BV-Algorithmen schwer oder nicht zu lösen sind, werden auch zukünftig mit lediglich 30 Bildern nur schwer adressierbar sein. Allerdings gibt es einzelne Ansätze für spezielle Applikationsfälle, die mit sehr wenigen Bildern nachtrainiert werden können. Ein Beispiel hierfür ist Halcons Anomaly Detection (demnächst auch für Merlic verfügbar) oder Halcons Edge Extraction. Diese Modelle lassen sich mit wenigen Bildern auf spezifische Anwendungen anpassen. Allerdings sind sie vom Funktionsumfang jedoch eingeschränkt, z.B. rein auf die Erkennung von Kanten bzw. Anomalien, und können nicht so flexibel eingesetzt werden, wie z.B. vortrainierte Bildklassifikations- oder Object-Detection-Modelle.

F. Weihard: The number of images required for model training is in fact dependent on a variety of external factors including but not limited to the different ‚looks‘ or variations in the object / defect to be identified, the ambient lighting conditions, the variety in positioning and orientations of the parts, the variety in the parts itself such as prints or coloring differences. All of these contribute to a variation in the number of images required for different applications. While guidelines and intuition do help, in the end model training is definitely as much an art, as it is a science.

inVISION: Bei einer inVISION Umfrage haben 52,3% der Befragten das Training als das derzeit größte Problem bei Deep Learning bezeichnet, gefolgt von 33,8% bei der Bedienbarkeit. Ist Deep Learning nur etwas für Experten?

T. Manthey: Ich denke grundsätzlich geht es hier um die Übertragbarkeit auf neue Anwendungsfälle. Aber die Antwort ist: JA. Der professionelle Umgang mit Deep Learning Frameworks erfordert: a) ein grundlegendes (mathematisches) Verständnis der verwendeten Algorithmen, b) umfangreiche Erfahrung im Umgang mit Daten und c) sehr gute Entwicklerfähigkeiten in den verschiedensten Programmiersprachen. Welcher Anteil der Unternehmen, die Probleme mit dem Training haben, haben aber auch größere Investitionen in die Technologie vorgenommen? Ich denke wir kennen alle die Antwort. Würden wir als KI-Unternehmen versuchen morgen ein Flugzeug zu bauen? Sicher nicht. Aber warum sollte das umgekehrt anders sein? Dennoch betrachten wir die Entwicklung positiv. Wir freuen uns über Kunden mit dem Verständnis für die Herausforderungen im Umgang mit Deep Learning Anwendungen.

C. Scheubel: Man sollte schon etwas Erfahrung insbesondere beim Trainieren und Implementieren von neuronalen Netzen mitbringen. Wir sehen, dass eine der größten Herausforderungen im Erstellen des Datensatzes liegt. Nur wenn der Datensatz eine hohe Qualität hat, sind gute Ergebnisse vom neuronalen Netz zu erwarten.

M. Bohnacker: Das Training wird oft als sehr problematisch empfunden, da die Möglichkeiten der Einflussnahme sehr begrenzt sind. Entweder alles läuft gut und man bekommt recht schnell ein Modell, das sehr gut performt, oder es läuft schlecht und man weiß nicht so recht, woran es liegt. Allerdings verfolgt DL auch einen ganz anderen Ansatz als traditionelle BV-Algorithmik. Um Anwendungen traditionell zu lösen, stehen sehr viele verschiedene Parameter zur Verfügung, an welchen nachvollziehbar optimiert werden kann, und die einen sehr starken Einfluss auf das Endergebnis haben können. DL hingegen kommt von der Datenseite, d.h. die Qualität der Daten hat einen viel größeren Einfluss auf das Endergebnis als einzelne Parameter. Um einen qualitativ hochwertigen Bilddatensatz zu generieren ist es vor allem wichtig, dass man Experte für die zu realisierende Anwendung ist, um sicher zu stellen, dass sich alle für die Anwendung repräsentativen Aspekte auch im Datensatz wiederfinden. Zudem ist es wichtig, dass sich die verwendeten Tools einfach bedienen lassen, wie z.B. unser Deep Learning Tool, das sowohl für das Datenmanagement als auch für das Training verwendet werden kann, sowie dass alle nötigen Tools ideal aufeinander abgestimmt sind.

F. Weihard: The major difficulty that requires an expert input is the decision on choice of model to train. Once the architecture, framework of the model is decided upon, training can be a very routine and semi-automated operation that can be simplified for non-experts to handle as well. With a particular model framework chosen, the usability of the model can also be well defined – the software required to execute the model on images, the maximum size of defect (or rather defect size to image size ratio), the speed of model execution – all of these can be well defined, hence making the DL model extremely user friendly. When first developing a model for a new application, it is always useful to have experts make the tough choices; and once these choices are made, the next improvements, or additions of classes to the model are much more smooth sailing. Our EaglAI Train package actually is a no-code training environment so that the end users can themselves add defects or variants of the parts.