A Practitioner’s Guide to Machine Learning

Garbage in, Garbage out!

Vergiss nie: Daten sind unser Rohstoff, um mit ML etwas Wertvolles zu schaffen. Ist die Qualität oder Quantität der Daten nicht ausreichend, haben wir ein “Garbage in, Garbage out”-Szenario und egal welche Art von ausgefallenem ML-Algorithmus wir verwenden, wir werden kein zufriedenstellendes Ergebnis erreichen. Im Gegenteil, je aufwändiger die Algorithmen (z.B. Deep Learning), desto mehr Daten werden benötigt.

Nachfolgend findest du eine Zusammenfassung einiger allgemeiner Risiken im Zusammenhang mit Daten, die die Anwendung von ML erschweren oder sogar unmöglich machen:

Rohdaten können sehr chaotisch sein:

Relevante Daten sind auf mehrere Datenbanken/Excel-Tabellen verteilt, die zusammengeführt werden müssen. Worst Case: Datenpunkte haben keine eindeutige ID, anhand derer sich die verschiedenen Einträge verknüpfen lassen. Stattdessen muss man auf eine fehleranfällige Strategie zurückgreifen, wie den Datenabgleich anhand von Zeitstempeln.
Manuell eingegebene Werte enthalten Fehler, z.B. falsch platzierte Dezimalkommas.
Fehlende Werte können nicht korrigiert werden. Worst Case: Fehlende Werte sind nicht zufällig. Beispielsweise versagen Sensoren genau dann, wenn während des Produktionsprozesses etwas schief geht. Oder im Rahmen einer Umfrage zum Einkommen verweigern reiche Personen im Vergleich zu armen oder mittelständischen Personen häufiger die Antwort. Dies kann zu systematischen Verzerrungen im Datensatz führen.
Der Datensatz besteht aus verschiedenen Datentypen (strukturiert und/oder unstrukturiert) mit unterschiedlichen Skalierungen.
Der Prozess ändert sich im Laufe der Zeit, z.B. aufgrund externer Bedingungen wie dem Austausch eines Sensors oder einem anderen Wartungsereignis, was bedeutet, dass die über verschiedene Zeiträume gesammelten Daten nicht kompatibel sind. Worst Case: Diese externen Veränderungen wurden nirgends dokumentiert und wir bemerken erst am Ende der Analyse, dass die verwendeten Daten unsere Annahmen verletzten.

→ Preprocessing von Daten dauert sehr lange.
→ Der resultierende Datensatz (nach der Bereinigung) ist viel kleiner als erwartet — möglicherweise zu klein, um eine sinnvolle Analyse durchzuführen.

⇒ Bevor du mit ML anfängst, überlege erst, ob du die Datenerfassungspipeline und Infrastruktur verbessern kannst!

Nicht genug / nicht die richtigen Daten für ML:

Ein kleiner Datensatz und/oder zu wenig Variation, z.B. werden nur sehr wenige defekte Produkte produziert oder ein Prozess läuft die meiste Zeit im stationären Zustand, d.h. es gibt nur wenig oder keine Variation bei den Inputs.
→ Auswirkung verschiedener Eingangsgrößen auf die Zielvariable kann aus wenigen Beobachtungen nicht zuverlässig abgeschätzt werden.
⇒ Führe gezielt Experimente durch, bei denen verschiedene Inputs systematisch variiert werden, um einen aussagekräftigeren Datensatz zu generieren.
Daten sind inkonsistent / unvollständig, also es gibt Datenpunkte mit gleichen Inputs aber unterschiedlichen Labels, z.B. zwei Produkte wurden unter den gleichen (gemessenen) Bedingungen produziert, eins ist in Ordnung, eins fehlerhaft.
Dies kann zwei Gründe haben:
- Die Labels sind sehr verrauscht, z.B. weil die menschlichen Annotatoren nicht dieselben klaren Regeln befolgten oder einige Beispiele mehrdeutig waren (z.B. ein QA-Experte sagt ein kleiner Kratzer ist noch in Ordnung, der andere sortiert das Produkt aus).
  ⇒ Etablierung klarer Regeln nach welchen Kriterien Daten gelabelt werden sollen und Daten durch Neuannotation bereinigen. Dies kann einige Zeit dauern, lohnt sich aber! Siehe auch dieser tolle MLOps / data-centric AI Vortrag von Andrew Ng darüber, wie ein kleiner sauberer Datensatz wertvoller sein kann als ein großer verrauschter Datensatz.
- Relevante Input Features fehlen: Menschen können zwar relativ einfach beurteilen, ob alle relevanten Informationen in unstrukturierten Daten enthalten sind (z.B. Bilder: entweder sehen wir eine Katze oder nicht), strukturierte Daten haben dagegen oft zu viele verschiedene Variablen und komplexe Interaktionen, um sofort zu erkennen, ob alle relevanten Eingangsgrößen gemessen wurden.
  ⇒ Sprich mit einem Fachexperten darüber, welche zusätzlichen Features hilfreich sein könnten und nimm diese in den Datensatz mit auf. Worst Case: Es muss ein neuer Sensor in die Maschine eingebaut werden um diese Daten zu sammeln, d.h. alle in der Vergangenheit gesammelten Daten sind im Grunde nutzlos. ABER: Der Einsatz des richtigen Sensors kann das Problem immens vereinfachen und der Einbau lohnt sich!
  Bei vielen Anwendungen ist unser erster Gedanke oft, die Eingabedaten mithilfe einer Kamera zu generieren, da wir Menschen hauptsächlich auf unser visuelles System angewiesen sind, um viele Aufgaben zu lösen. Auch wenn Bilderkennungsalgorithmen mittlerweile sehr ausgereift sind, kann die Verwendung eines solchen Setups anstelle eines spezialisierteren Sensors die Lösung komplizierter machen.
  Willst du überreife Erdbeeren erkennen? Machs wie Amazon Fresh und verwende einen Nahinfrarotsensor (NIR) anstelle einer normalen Kamera. Dabei wird immer noch maschinelles Lernen verwendet um die resultierenden Daten zu analysieren, aber in den NIR-Bildern sind die vergammelten Teile der Früchte viel besser sichtbar als auf normalen Fotos.
  Versuchst du zu erkennen, ob eine Tür geschlossen ist? Mit einem einfachen Magneten und Detektor lässt sich diese Aufgabe ohne aufwändige Analyse oder Trainingsdaten lösen! (Du kennst bestimmt das Sprichwort: “Wenn du einen Hammer hast, sieht alles aus wie ein Nagel”. → Vergiss nicht, auch Lösungen außerhalb deiner ML-Toolbox in Betracht zu ziehen! ;-))

→ Wenn der Datensatz nicht entsprechend aufgewertet wird, wird kein ML-Modell eine gute Performance liefern!

Beobachte wenn möglich wie die Daten erfasst werden, im Sinne von: Stehe tatsächlich physisch da und beobachte, wie jemand die Werte in ein Programm eingibt oder wie die Maschine arbeitet, wenn die Sensoren etwas messen. Sicherlich werden dir einige Dinge auffallen, die man direkt bei der Datenerhebung optimieren könnte. Dies erspart in Zukunft viel Preprocessing Arbeit.

Best Practice: Datenkatalog

Um Datensätze leichter zugänglich zu machen, sollten diese dokumentiert werden. Für strukturierte Datensätze sollte es für jede Variable Zusatzinformationen geben wie:

Name der Variable
Beschreibung
Einheit
Datentyp (z.B. numerische oder kategorische Werte)
Datum der ersten Messung (z.B. falls ein Sensor erst später eingebaut wurde)
Normaler/erwarteter Wertebereich (→ “Wenn die Variable unter diesem Schwellwert liegt, dann ist die Maschine ausgeschaltet und die Datenpunkte können ignoriert werden”)
Wie werden fehlende Werte aufgezeichnet, d.h. werden sie tatsächlich als fehlende Werte aufgezeichnet oder stattdessen durch einen unrealistischen Wert ersetzt, was passieren kann, da einige Sensoren kein Signal für “Not a Number” (NaN) senden können oder die Datenbank es nicht zulässt, dass das Feld leer bleibt.
Anmerkungen zu sonstigen Vorfällen oder Ereignissen, z.B. eine Fehlfunktion des Sensors während eines bestimmten Zeitraums oder ein anderer Fehler, der zu falschen Daten geführt hat. Diese sind sonst oft schwer zu erkennen, z.B. wenn jemand stattdessen manuell Werte eingibt oder kopiert hat, die auf den ersten Blick normal aussehen.

Weitere Empfehlungen, was bei der Dokumentation von Datensätzen speziell für Machine Learning Anwendungen wichtig ist, findest du im Data Cards Playbook.

Neben der Dokumentation von Datensätzen als Ganzes ist es auch sehr hilfreich, Metadaten für einzelne Proben zu speichern. Bei Bilddaten können dies beispielsweise der Zeitstempel der Bildaufnahme, die Geolokalisierung (oder wenn die Kamera in einer Fertigungsmaschine verbaut ist, dann die ID dieser Maschine), Informationen zu den Kameraeinstellungen etc. sein. Dies kann bei der Analyse von Modellvorhersagefehlern sehr hilfreich sein, da sich beispielsweise herausstellen kann, dass Bilder, die mit einer bestimmten Kameraeinstellung aufgenommen wurden, besonders schwer zu klassifizieren sind, was uns wiederum Hinweise liefert, wie wir den Datenerfassungsprozesses verbessern könnten.

Daten als Asset: Mit den richtigen Prozessen (z.B. Etablierung von Rollen wie “Data Owner” und “Data Controller”, die für die Datenqualität verantwortlich sind, und Aufbau einer konsistenten Dateninfrastruktur, inkl. eines Monitoring-Prozesses zur Validierung neuer Daten) ist es für eine Organisation möglich, von “Garbage in, Garbage out” zu “Daten sind das neue Öl” zu kommen:

Mit (Big) Data kommt große Verantwortung!: Einige Daten erscheinen auf den ersten Blick manchmal nicht sehr wertvoll, können aber für andere (d.h. mit einem anderen Anwendungsfall) von großem Nutzen sein!

Ein Fitness-Tracker-Startup hielt es für eine coole Idee, beliebte Joggingrouten basierend auf den von ihren Nutzern generierten Daten zu veröffentlichen. Da aber auch viele US-Soldaten den Tracker benutzten und häufig um ihre Militärstützpunkte joggten, hat dieses Startup dadurch versehentlich einen geheimen US-Armeestützpunkt in Afghanistan geoutet, der auf ihrer interaktiven Karte als heller Punkt in einem Gebiet auftauchte, wo sonst nur wenige andere Nutzer joggten. Auch wenn deine Daten erstmal harmlos erscheinen, denk bitte darüber nach, was bei einer Veröffentlichung (auch in aggregierter, anonymisierter Form) schief gehen könnte!