Home › 
Blog › 
Datenzentriertes maschinelles Lernen: Maßgeschneiderte ML-Lösungen zur Produktionsreife bringen

Dieser Blogartikel wurde teilweise mit Hilfe von DeepL (deepl.com) übersetzt.

Datenzentriertes maschinelles Lernen: Maßgeschneiderte ML-Lösungen zur Produktionsreife bringen

Data Centric Ai
Machine Learning
Industry 4.0
Project Planning
Labeling

Geschrieben von David Berscheid

Veröffentlicht am 6. Oktober 2021

Im Jahr 2021 besteht kaum ein Zweifel daran, dass Machine Learning (ML) ein großes Potenzial für die heutige Welt bietet. In einer Bitkom-Studie geben 30 % der Unternehmen in Deutschland an, dass sie Versuche geplant oder zumindest diskutiert haben, den Mehrwert von ML zu nutzen. Doch während die Bereitschaft der Unternehmen, in ML zu investieren, steigt, schätzt Accenture, dass 80% - 85% dieser Projekte eine Machbarkeitsstudie bleiben und nicht in die Produktion überführt werden. Nach unseren Erfahrungen mit verschiedenen Kunden würden wir dieser Einschätzung zustimmen.

Deshalb haben wir es uns bei dida zur Aufgabe gemacht, die Lücke zwischen Machbarkeitsstudie und Produktionssoftware zu schließen, was wir u.a. durch den Einsatz datenzentrierter Techniken erreichen.

In diesem Artikel werden wir

  • sehen, warum viele ML-Projekte es nicht in die Produktion schaffen,

  • die Konzepte des modell- und datenzentrierten ML vorstellen, und

  • Beispiele geben, wie wir bei dida Projekte durch den Einsatz datenzentrierter Techniken verbessern.

Modellzentrierte ML: Warum viele Branchen Schwierigkeiten haben, das Potenzial von ML in der Produktion zu nutzen

Modellzentriertes ML beschreibt ML-Lösungen, die sich hauptsächlich auf die Optimierung von Modellarchitekturen und deren (Hyper-)Parametern konzentrieren. ML-Forscher arbeiten hart daran, immer bessere neuronale Netzwerkarchitekturen zu finden, um die Bewertungsmetriken für gängige Benchmark-Datensätze wie mnist oder ImageNet zu verbessern.

In vielen Branchen implementieren ML-Ingenieure leistungsstarke State-of-the-Art-Modelle in ihre Anwendungen und führen Experimente mit verschiedenen Architekturen und Hyperparametern durch. In Grafik 1 ist ein typischer modellzentrierter ML-Prozess dargestellt. Man beachte den iterativen Charakter der Modell- und Hyperparameteroptimierung, während die Datenerfassung, die Vorverarbeitung oder das Deployment einmalige Schritte bleiben.

Dieser modellzentrierte Ansatz eignet sich gut für einige Branchen, z. B. die Werbebranche. Dort verfügen Unternehmen wie Google oder Facebook über riesige Mengen an Nutzerdaten, die in der Regel in einem standardisierten Format vorliegen, mit unmittelbaren Feedback-Möglichkeiten und großen ML-Abteilungen.

In den meisten anderen Branchen ist dies jedoch nicht der Fall. Denken Sie an Branchen wie das verarbeitende Gewerbe, den Maschinenbau oder das Gesundheitswesen. Diese stehen in der Regel vor den folgenden drei Problemen:

1. Bedarf an hochgradig maßgeschneiderten Lösungen

Im Gegensatz zum Anzeigenszenario von Google kann ein Fertigungsunternehmen mit mehreren Produkten nicht nur ein ML-System zur Erkennung von Produktionsfehlern bei seinen verschiedenen Produkten einsetzen. Stattdessen bräuchte es für jedes hergestellte Produkt ein separat trainiertes ML-Modell.

Während Google es sich leisten kann, dass eine ganze ML-Abteilung an jedem noch so kleinen Optimierungsproblem arbeitet, kann ein Fertigungsunternehmen, das mehrere ML-Lösungen benötigt, in Bezug auf die Größe seiner ML-Abteilung nicht dem Vorbild von Google folgen.

2. Begrenzte Anzahl von Datenpunkten

In den meisten Fällen verfügt die Industrie nicht über Millionen von Datenpunkten. Stattdessen müssen sie in der Regel mit kleinen Datensätzen arbeiten (etwa in der Größenordnung von 10^2 - 10^3 relevanten Datenpunkte), die - für Produktionsstandards - in der Regel zu unbefriedigenden Ergebnissen führen, wenn ihre ML-Lösung zu modellzentriert ist.

Stellen Sie sich einen Anwendungsfall vor, in dem ein Windturbinenhersteller eine prädiktive Wartungslösung entwickeln möchte, die in der Lage ist, Verschleiß an seinen Windturbinen durch die Analyse von Drohnenbildern zu erkennen. Neben Tausenden von Bildern mit "gesunden" Windturbinen könnte die Stichprobengröße der Bilder, die tatsächliche Abnutzungserscheinungen an der Oberfläche zeigen, bei etwa 100 liegen und damit vielleicht 0,0001 % der Stichprobengröße eines Anzeigenunternehmens betragen.

Es wird deutlich, dass ein modellzentrierter Ansatz, der sich auf die Optimierung der Modellarchitektur und nicht auf den Schwachpunkt - die begrenzte Anzahl relevanter Bilder - konzentriert, keine zufriedenstellenden Ergebnisse liefern würde.

3. Große Lücke zwischen Machbarkeitsstudie und Produktionssoftware

2019 wurden Forschungsarbeiten veröffentlicht, die behaupten, dass sie Tumore in einem frühen Stadium genauer diagnostizieren können als geschulte Radiologen es könnten. Aber warum nutzt nicht jedes Krankenhaus bereits solche großartigen ML-Systeme, um seine Diagnosen zu optimieren?

Das liegt an der großen Kluft zwischen der Machbarkeitsstudie und der Produktionssoftware im Krankenhaus. Wenn jedes Krankenhaus die gleichen Maschinen zur Erstellung der Lungenscans seiner Patienten verwenden würde und jedes Krankenhaus diese Bilder an einem zentralen und zugänglichen Ort speichern würde, dann würden die Produktionssoftware wahrscheinlich wie vorgesehen funktionieren.

In der Realität ist dies jedoch nicht der Fall. Die Krankenhäuser verwenden unterschiedliche Geräte, die von unterschiedlichen Herstellern gekauft wurden, aus unterschiedlichen Jahren stammen und folglich eine unterschiedliche Scanqualität aufweisen. Darüber hinaus ist die Datensicherheit ein sehr wichtiges Thema für Krankenhäuser und das Gesundheitswesen, so dass es nicht möglich ist, alle Scans einfach in ein zentral gespeichertes System hochzuladen.

Daher müssen Krankenhäuser in der Regel eine große Kluft überwinden, bei der jedes Krankenhaus sein eigenes ML-System verwenden muss, um die eigenen technischen und organisatorischen Anforderungen zu erfüllen. In diesem Fall ist modellzentriertes ML oft unzureichend.

Unternehmen, die mit einigen der oben genannten Probleme konfrontiert sind und bereits Versuche unternommen haben, ML für ihr Geschäft zu nutzen, würden wahrscheinlich zustimmen, dass rein modellzentrierte ML in der Regel nicht überzeugend genug ist, um in die Produktion aufgenommen zu werden, was uns zu datenzentrierter ML bringt.

Datenzentriertes ML: Chancen für Branchen mit individuellen Bedürfnissen

Datenzentrierte ML bezieht sich auf Techniken zur Optimierung von Daten in ML-Projekten. Obwohl die Verbesserung datenbezogener Aspekte für ML-Wissenschaftler nichts Neues sein sollte, wirbt Andrew Ng, ein führender ML-Technologe, für entsprechende Bemühungen.

In einem kürzlich gehaltenen Vortrag stellte er fest, dass bei einer Stichprobe der jüngsten ML-bezogenen Veröffentlichungen 99 % der Arbeiten modellzentriert waren und nur 1 % der untersuchten Arbeiten sich auf Daten konzentrierte.

Dieses extreme Verhältnis zeigt, dass sich die ML-Forschung stark auf die Optimierung von ML-Modellen konzentriert, während datenbezogene Aspekte oft vernachlässigt werden. Die Befürworter der datenzentrierten ML fordern daher mehr Lösungen für die Optimierung von Daten in ML-Workflows.

Wie in Abbildung 2 dargestellt, wird der frühere modellzentrierte ML-Ansatz erweitert, indem von der Bereitstellung zurück zur Datenerfassung und Datenvorverarbeitung iteriert wird. Insbesondere in Situationen, in denen maßgeschneiderte Lösungen benötigt werden, wenig Daten vorliegen und große Lücken zwischen Konzept und Produktion bestehen, können die folgenden Aspekte der datenzentrierten ML von Bedeutung sein:

1. Iterative Auswertungen

Während bei klassischen Softwareentwicklungsprojekten der Prozess mit der Bereitstellung einer Funktionalität endet (ohne Berücksichtigung von Aktualisierungszyklen), ist dies bei datenzentrierten ML-Projekten nicht der Fall. Während des Produktionseinsatzes wird die ML Daten sehen, die sie vorher nicht gesehen hat und die sich zwangsläufig von den Trainingsdaten des Algorithmus unterscheiden werden.

Daher sollte die Bewertung der Qualität des Modells ein iterativer Prozess sein und kein einmaliger Schritt. Rechtzeitige Rückmeldungen aus Produktionssystemen ermöglichen es beispielsweise, Abweichungen in der Datenverteilung zu erkennen und darauf zu reagieren, und stellen, falls gewünscht, eine Voraussetzung für das Online-Lernen dar.

2. Datensammlung

In einem datenzentrierten Ansatz ist auch die Datensammlung ein iterativer Prozess, insbesondere für Unternehmen, die nicht über Millionen von Datenpunkten verfügen. Dies ist eine offensichtliche Technik, um die Leistung von ML-Systemen zu erhöhen, wobei gleichzeitig zu beachten ist, dass die Qualität oft wichtiger ist als die reine Datenmenge.

3. Qualität des Labelings der Daten

Nicht nur die iterative Datenerfassung kann das Ergebnis verbessern, sondern auch die Qualität des Labelings der Daten. Datenzentriertes ML argumentiert, dass eine große Anzahl schlecht gelabelter Bilder oder Texte zu schlechteren Ergebnissen führt als wenige, aber korrekte.

Mehrere Labeler helfen außerdem dabei, Unstimmigkeiten in den Labels zu erkennen. Eine bewährte Praxis besteht darin, die inkonsistenten Labels zu finden und die Labelinganweisungen speziell für diese Fälle neu zu definieren. Der wichtigste Aspekt des Labelings ist jedoch die Einbeziehung von Fachwissen, das oft fehlt, wenn es von Dritten übernommen wird oder nicht mit der nötigen Sorgfalt erfolgt.

4. Augmentation von Daten

Die Datenaugmentation fasst Techniken zusammen, mit denen die Anzahl der Datenpunkte in Ihrer Stichprobe erhöht werden kann. Vorhandene Bilder können zum Beispiel gespiegelt, gedreht, gezoomt oder beschnitten werden, um zusätzliche Bilder zu erstellen. Ähnliche Techniken gibt es auch im NLP-Kontext. Beim datenzentrierten ML wird die Datenerweiterung insbesondere dazu verwendet, die Anzahl der relevanten Datenpunkte, d. h. z.B. die Anzahl der fehlerhaften Produktionsteile, zu erhöhen.

5. Integration von Fachwissen

In der datenzentrierten ML hat Fachwissen einen hohen Stellenwert. Oft können ML-Ingenieure, Labeler und andere "Fachfremde" subtile Unterschiede nicht erkennen, während Experten aus dem Fachgebiet dies können. Obwohl es intuitiv ist, diese Experten in die Entwicklungsprozesse einzubeziehen, fehlt dieser Austausch in der Realität oft. Das Ergebnis ist ein ML-System, das eine höhere Leistung erbracht hätte, wenn mehr Fachwissen zur Verfügung gestanden hätte, und eine höhere Wahrscheinlichkeit, dass es eine Machbarkeitsstudie bleibt, da die Ergebnisse in einer Produktionsumgebung nicht überzeugen würden.

Datenzentriertes ML bei dida: Beispiele und Erfahrungen

Während die oben genannten Aspekte in der Theorie vernünftig und vielleicht sogar offensichtlich klingen, lassen Sie uns einen Blick auf einige Beispiele aus früheren Projekten bei dida werfen, um zu sehen, wie wir typischerweise die Leistung durch datenzentrische Techniken verbessern. Sie werden schnell feststellen, dass es oft nicht so trivial ist, wie es zunächst scheint.

Iterative Auswertungen erkennen Datendrifts

Für Enpal, einen Hersteller von Solarmodulen, haben wir eine ML-Lösung entwickelt, mit der die Anzahl und Position der auf einem bestimmten Dach angebrachten Solarmodule anhand von Satellitenbildern geschätzt werden kann. Durch iterative Auswertungen waren wir in der Lage, Datendrift in der Produktion zu erkennen: die Bilder, die in das Produktionssystem eingespeist wurden, fingen an, sich von den Trainingsdaten (statistisch) zu unterscheiden.

Grafik 3 zeigt vier Situationen, die zu einer schlechten Leistung geführt hätten, wenn wir keine ständige Auswertung gehabt hätten, wie z. B. schlechter Kontrast der Dachseiten, sehr kleine Objekte auf dem Dach (die es nicht erlauben würden, dort ein Solarpanel zu platzieren), geringe räumliche Auflösung oder seltene Dachformen (wie zusammenhängende Dächer). Alle diese Sonderfälle waren in den Trainingsdaten ursprünglich kaum präsent, d.h. die erste Version der Lösung war auf sie nicht vorbereitet und musste (und konnte) angepasst werden.

Kontrolle über den Annotationsprozess sichert die Qualität der Labels

Am Beispiel der Solarpanels lassen sich Unterschiede im Labeling der Daten und ihre Auswirkungen leicht aufzeigen. Wenn Sie Bild 1 und 2 vergleichen, sehen Sie, dass die Person, die Bild 2 gelabelt hat, beschlossen hat, das kleine Hindernis auf dem mittleren Dach nicht zu markieren und das dreieckige Hindernis auf dem unteren Dach nicht. In Bild 3 sieht es so aus, als hätte die Person die Labels von Hand gezeichnet, was zu ungleichmäßigen Linien und runden Formen anstelle von klaren Kanten führt. Und dann ist da noch Person 4 - wir haben keine Ahnung, was diese Person gemacht hat ;)

Spaß beiseite, man kann sehen, dass die Qualität der Labels sehr unterschiedlich sein kann. Wie soll ein ML-Modell eine gute Leistung erbringen, wenn die Eingabedaten schwach oder sehr inkonsistent sind? Ist den Labelern klar, wie ein qualitativ hochwertiges Label im Gegensatz zu einem durchschnittlichen Label aussieht?

Aus diesem Grund lagern wir bei der dida diesen Schritt in der Regel nicht aus, sondern lassen die Daten in unseren Projekten von unseren eigenen Mitarbeitern labeln (zumindest so lange, bis wir davon überzeugt sind, dass das Labeling-Schema gut erprobt ist und transparente Anleitungen und Qualitätsstandards für die Labeling definiert wurden). Auf diese Weise haben wir mehr Kontrolle über den Prozess und können das Labeling-Schema bei Bedarf anpassen.

Pedanterie zahlt sich aus

Am Beispiel eines früheren Projekts mit einem großen Chemiekonzern, dessen Namen wir nicht nennen können, möchten wir zeigen, dass die Erstellung von Labels nicht immer eine triviale Aufgabe ist. Grafik 5 zeigt einen Ausschnitt aus einer Rechnung. Ziel war es, die relevanten Informationen automatisch zu erkennen und in strukturierter Form in das jeweilige ERP-System zu importieren.

Nicht trivial bei den Labels ist die Entscheidung, wie viele Informationen ein Label enthalten soll. Ist 'Inhalt 500g' oder einfach '500g' das bessere Label? Noch komplizierter ist die Entscheidung, ob 'Anzahl 1' und 'Menge 2' als dieselbe Klasse gelabelt werden sollen, da sie als Synonyme für Menge angesehen werden können, oder als zwei verschiedene Klassen? Aufgrund der Erfahrungen aus unseren früheren NLP-Projekten und den von uns durchgeführten Experimenten waren die Ergebnisse am überzeugendsten, als wir uns für das Label-Schema entschieden, das Sie in der Grafik sehen können - aber die Entscheidung war nicht trivial oder sogar irrelevant.

Dies berührt einen sehr allgemeinen Punkt, der bereits oben erwähnt wurde: Bei den meisten ML-Projekten in der realen Welt sind die Daten, die zum Trainieren und Testen verwendet werden sollen, nicht "einfach da", wie es bei Kaggle-Wettbewerben oder Benchmarking-Datensätzen der Fall ist, sondern hängen von einer Reihe von Entscheidungen ab, die zuvor getroffen werden müssen. Obwohl es bei einigen von ihnen (wie möglicherweise beim obigen Beispiel) pedantisch erscheint, sie überhaupt in Betracht zu ziehen und zu diskutieren, haben wir festgestellt, dass viel von diesen Details abhängt.

Hilfe von Fachleuten ist unverzichtbar

Für unseren Kunden Mieterengel, einen Online-Mieterschutzverein, haben wir eine ML-Lösung entwickelt, die in der Lage ist, Mietverträge zu analysieren, zu prüfen, ob bestimmte Paragraphen rechtsgültig sind, und eine Antwort vorzubereiten, die ein Anwalt von Mieterengel dann an seine Mitglieder schicken kann. Dieses Projekt ist ein sehr gutes Beispiel dafür, warum Fachwissen in ML-Projekten benötigt wird.

Bei dida sind wir Experten für ML, haben aber wenig Wissen über rechtliche Fragen. Deshalb haben wir regelmäßig gemeinsame Workshops mit Mietrechtsanwälten veranstaltet, um unser Labeling-Schema zu entwickeln und ständig zu evaluieren. Mehrfach konnten uns die Rechtsexperten in unseren gemeinsamen Workshops auf kleine Aspekte in den Labels der Verträge hinweisen, die noch verbessert werden könnten, um sich so nah wie möglich an die gängige juristische Logik zu halten.

Schlussfolgerung

Datenzentrierte ML-Techniken sind ein Weg, um die Leistung von ML-Lösungen zu steigern. Sie stellen eine wertvolle Ergänzung zu den beliebten und anspruchsvollen Optimierungen von Algorithmen, Architekturen und Hyperparametern dar.

Für uns bei dida ist datenzentriertes Arbeiten zwar nicht der neue Trend, als der er von einigen Mitgliedern der ML-Gemeinschaft bezeichnet wird, sondern gängige Praxis, aber wichtig ist es allemal. Techniken zur Verbesserung der Datenqualität in Projekten haben sich für die dida oft als essentiell erwiesen, weshalb wir das steigende Bewusstsein für datenzentrierte Techniken begrüßen und uns auf neue Ansätze freuen, die sich aus dieser neuen Aufmerksamkeit ergeben könnten.

Wenn Sie mehr über datenzentriertes ML erfahren möchten oder herausfinden wollen, welche maßgeschneiderten Lösungen für Ihr Unternehmen relevant sein könnten, kontaktieren Sie uns hier oder senden Sie uns eine Mail an info@dida.do.

Über die Autorin/den Autor

David Berscheid

Seit seines Masterstudiums in BWL an der HU Berlin machte sich David die Arbeit mit technologischen Produkten und Dienstleistungen zu seinem Schwerpunkt. Typischerweise an der Schnittstelle von Entwicklung und Management, sammelte er Erfahrung als Data Scientist, Frontend-Entwickler und Mitbegründer von eventasy, bevor er zur dida kam. Jetzt unterstützt er das Machine Learning-Team, um mehr Sichtbarkeit und spannende Projekte zu erhalten.

KI-News jedes Quartal

Erhalten Sie Nachrichten über Machine Learning und Neuigkeiten rund um dida.

Erfolgreich angemeldet.

Gültige Email-Adresse benötigt.

Email-Adresse bereits registriert.

Etwas ist schiefgelaufen. Bitte versuchen Sie es nochmal.

Mit dem Klick auf "Anmelden" erklären Sie sich mit unserer Datenschutzerklärung einverstanden.

dida Logo