Ahoi! Ihr seid ja immer noch da!  Alle, die nach den ersten beiden Etappen unserer Reise noch nicht von Bord gegangen sind, können sich die Sauerstoffflasche umschnallen, denn diesmal tauchen wir tief in die Daten ein. Wer die ersten beiden Teile dieser Serie noch nicht kennt, darf sie hier selbstverständlich gerne nachlesen:

Einführung MLOps: Woran scheitern die meisten ML-Projekte, und wie kann MLOps helfen?

Machine Learning mit MLOps – Teil 2: Scoping. Wie umfahren wir die Untiefen im ML-Gewässer?

In den letzten beiden Artikeln dieser Serie haben wir gelernt, wie wir ein Projekt richtig einschätzen lernen. Und es ging darum, wie wir Ressourcen richtig planen und möglichen Problemen früh vorgreifen.

In diesem Artikel geht es eher darum, zu verstehen, was wir mit unseren Daten überhaupt vor uns haben. Wie diese uns helfen können, um unseren Kurs, also die Richtung unseres ML-Projekts, zu überprüfen:

• Woran erkennen wir, ob unser „Datenschatz“ ausreicht?
• Wo bekommen wir unsere (und gegebenenfalls noch weitere) Daten her?
• Wie können wir mithilfe unserer Daten früh prüfen, ob wir überhaupt auf Kurs sind?

Warum sind Daten für MLOps wichtig?

Vielleicht fragst du dich, warum es in dieser Artikelreihe zum Thema Machine Learning in zwei Teilen ausschließlich um Daten geht. Die Antwort ist einfach: Daten entscheiden darüber, ob ein Projekt durchführbar ist. Unter uns ML-Engineers gelten die Daten deshalb als „First Class Citizen“. Sie sind für uns noch wichtiger als das Training eines Modells oder das Anpassen von dessen Parametern. Kleinste Unterschiede in Qualität, Menge oder Aufbereitung von Daten können sich auf die Trefferquote eines ML-Modells auswirken. Oder um bei unserem Seefahrtsgleichnis zu bleiben: Ein ML-Modell ohne Daten ist wie ein Schiff ohne Wasser.

Daten: Welche und wieviel brauche ich?

Fast jedes Projekt beginnt mit dieser Frage. Und sehr häufig treten Kunden an mich heran und sind überzeugt, die nötigen Daten für das geplante Unterfangen zu haben. Und dann, bereits nach ein paar Fragen meinerseits sehen sie ihr Projekt ins Schwanken gebracht. Ddenn Daten können in unzähligen Formen vorliegen. Und: „Viele Daten“ nicht automatisch „gute Daten“. Wie auch die Seeleute unseres ML-Schiffs ihre Gewässer bestens kennen müssen, um die richtige Route einzuschlagen, müssen wir tief in die Materie unserer Kunden „eintauchen“, um unser Vorgehen zu bestimmen. Das dies nicht immer reibungslos klappt, kannst du dir sicher denken.

3 typische Hindernisse:

1. Daten an verschiedenen Orten: Gut und effektiv können wir in der Regel mit Daten arbeiten, die für uns an einer Stelle verfügbar sind. Hier trennt sich leider oft schon die Spreu vom Weizen. Viele Projektverantwortliche schwören mir, alle nötigen Daten zu haben. In der Realität kann das aber bedeuten, dass diese auf zehn verschiedenen Systemen verteilt sind und unterschiedliche Definitionen die gleichen Parameter besitzen. Das Zusammenführen kann zu einem Alptraum werden. Ich habe schon erlebt, dass „Wir haben alle Daten“ bedeutete, dass ich mich durch eine 20 GB große händisch ausgefüllte Excel Tabelle kämpfen musste. Natürlich hatte kein Mensch zuvor festgelegt, wie ihre Felder auszufüllen sind.
2. Unterschiedliche Sprachen: Noch schlimmer wenn die Systeme alle unterschiedliche „Sprachen sprechen“ also die Daten auf unterschiedliche Arten durch diese Systeme verfügbar gemacht werden, das eine vielleicht über eine API, das andere mittels CSV Download.
3. Privacy: Weitere Schwierigkeiten können auftreten, wenn Datenschutzrichtlinien beachtet werden müssen. Enthält der Datensatz Informationen über Privatpersonen? Welche Auflagen des Gesetzgebers und welche Firmenpolicys müssen beachtet werden? Welchen Teil der Daten können wir überhaupt verwenden? Was wenn wir nichts verwenden dürfen?

Keine Sorge! Keins dieser Probleme sorgt dafür, dass unser KI-Schiff auf dem Trockenen liegt. Aber es müssen ausreichende Vorkehrungen getroffen werden. Und als projektverantwortliche Person ist es möglich, bereits beim Scoping einige Fragen durchzugehen:

• Welche Daten werden für mein Vorhaben vermütlich nötig sein?
• Habe ich diese?
• Falls nein, weiß ich, woher ich sie beschaffen kann?
• Falls ja, in welcher Form liegen diese vor?
• Habe ich Zugriff auf diese Daten?
• Gibt es bezüglich der Daten Sicherheits- oder Datenschutzbedenken?

Die 3 genannten Hindernisse lassen sich auf vielerlei Art beseitigen:

1. Data Warehouse: Idealerweise wollen wir, dass unsere Daten aus einer Quelle kommen. Z. B. aus einem Data Warehouse. Dieses kann für die Integrität und Verfügbarkeit sowie Konformität unserer Daten Sorge tragen. Haben wir wie im ersten Beispiel viele unterschiedliche Quellen und vielleicht auch Protokolle oder Formate, wirkt sich das vor allem auf die Entwicklungszeit aus. Wir müssen Data Scientists beschäftigen, die sich eingehend mit den Daten beschäftigen und diese zu einem Data Warehouse oder auch einfach erstmal einer gemeinsamen Datenbank zusammenführen. Auch Dynamische Modelle exisiteren.
2. Mit den Fachleuten sprechen: Schildere deinen Data Scientists die Problemdomäne ausführlich und verlasse dich auf ihre Empfehlung hinsichtlich einer robusten Lösung zur Datenbereitstellung! Data Scientists sind wie Unterwasserbewohner. Daten sind ihr Meer. Darin kennen sie sich bestens aus und können uns schnell Aufschluss geben, wie wir navigieren müssen. Selbst aus der chaotischsten Excel Tabelle kann eine sinnvolle Struktur gewonnen werden. Aber das hat seinen Preis und gegebenenfalls ist es günstiger zu prüfen ob die Daten in anderer Form verfügbar gemacht werden können.
3. Datenschutz klären: Im Falle der ungeklärten Datenschutzbedenken müssen wir abschätzen wie relevant der personenbezogene Teil der Daten für unser Projekt ist. Eventuell können wir diese Einträge komplett ausklammern. Falls nicht sind Anonymisierung oder Pseudonymisierung die Werkzeuge unserer Wahl. Falls dies nicht ausreichend möglich ist, empfehle ich unbedingt, Datenschutzbeauftragte heranziehen. Auch dies wirkt sich natürlich auf die Kosten aus. Selbst wenn die vorher genannten Schritte möglich sind, ist es oft sinnvoll, sich kurz beraten lassen. So verhindern Sie, versehentlich gegen Auflagen zu verstoßen, die Sie später das ganze Projekt kosten können.

Den Kurs festlegen: Baseline etablieren

Wenn Kund: innen mich fragen, ab wann es sich lohnt, mit dem Training von Modellen zu beginnen, antworte ich gerne „sofort“. Damit ist aber nicht gemeint, dass wir uns direkt eine 200 TeraFLOPS Compute-Instanz in der Cloud reservieren oder uns ein Server Rack voller GPUs ins Office stellen und anfangen, am „großen Modell“ zu arbeiten. Nein. Aber wir können kleine „Testtraings“ mit reduzierter Genauigkeit, Ressourcen und Daten machen. Diese sollen kein Modell optimieren. Vielmehr schauen wir uns an ob unsere Änderungen an den Daten(quellen) oder in der Konfiguration einen positiven Einfluss auf die Genauigkeit haben. Oder ob ein einfaches Modell einigermaßen zufriedenstellend Zusammenhänge aus den Daten beziehen kann. Daran erkennen wir früh, ob es sich lohnt so weiterzumachen wie bisher oder ob wir Faktoren ändern müssen. Wir testen sozusagen „die Gewässer“.

Aber worauf achten wir eigentlich? Und wie definieren wir „gut“ oder zumindest „zufriedenstellend“?

Das hängt von unserer Aufgabe ab: Auf Machine Learning basierte KIs werden für sehr unterschiedliche Aufgaben eingesetzt. In der Regel wollen wir etwas klassifizieren, etwa: Ob Produkte auf einem Fertigungsband Schäden aufweisen. Oder: Welchen Gesichtsausdruck eine Person hat, die in die Kamera schaut. In den anderen Fällen sind es meist Vorhersagen, wie die Fortentwicklung eines Aktienkurses oder der Zeitpunkt an dem ein Bauteil wahrscheinlich wegen seiner Vibrationen versagen wird.

Eine gute Nachricht, für alle, die aufgrund meiner vorangegangenen Aussagen etwas pessimistisch auf ML-Projekte blicken: Wir können in Jedem Fall sagen, dass wir prinzipiell jede Aufgabe in den vorher genannten Bereichen auch von einer KI übernehmen lassen können, wenn ein oder mehrere Personen sie bisher ausüben konnte und wir zu allen Informationen Zugang erhalten, zu denen diese auch diese Personen Zugang haben. (Achtung! Wie erwähnt kann es hier selbst bei alten Hasen zu massiven Fehleinschätzungen kommen.) Oder wenn wir wissen, dass es in dem was wir vorhersagen wollen eine Regelmäßigkeit oder Kausalität gibt.

Aha! Erleichterung! Leinen Los! Grünes Licht für das Projekt! Alles lässt sich mit KI lösen! Nicht so schnell … „möglich“ heißt noch nicht „machbar“!

Selbst wenn wir das Problem, das bisher eine Person gelöst hat, perfekt verstehen und wirklich sämtliche Informationsquellen zur Entscheidungsfindung identifiziert haben, könnte es sein, dass das was der Mensch intuitiv entscheidet, für einen Algorithmus ein derart großes Datenaufkommen darstellt, dass wir so viele Ressourcen aufbringen müssten, dass es günstiger wäre, hier einen Menschen einzusetzen. KI ist nach wie vor eine hochspezialisierte Technologie und je unspezifischer und „breiter“ unsere Aufgabe wird, desto schwieriger oder teurer wird es auch, sie mittels KI zu lösen:

• Tierarten auf Fotos erkennen? Mittlerweile eine Standardaufgabe.
• Besucherzahlen anhand von Wetter, Saison, Nachrichten und Ausfallzeiten abschätzen? Etwas kniffliger, aber wohl noch im Rahmen.
• Eine Projektstruktur entwerfen nur basierend auf verbalen Input: Möglich? Mit Sicherheit!  Aber auch machbar? Mit einem dreistelligen Millionen schweren Investment und einigen Jahren Forschung könnte es gehen.

Haben wir aber ein Problem identifiziert, dessen Domäne wir gut durchblicken und das spezifisch genug ist, um im Rahmen unserer Möglichkeiten von einer KI automatisiert zu werden, dann können wir uns Gedanken über Erfolgskennzahlen machen.

In der MLOps ist die Baseline oft ein einfaches Modell oder eine Heuristik, die den aktuellen Stand der Technik oder den bisherigen Ansatz für das zu lösende Problem darstellt. Dies kann ein einfaches statistisches Modell sein, eine regelbasierte Logik oder sogar menschliche Leistung. Die Idee ist nicht, das komplexeste oder leistungsfähigste Modell zu wählen, sondern eins, das robust, verständlich und leicht zu implementieren ist.

Diese Baseline dient vor allem drei Zwecken.

1. Sie bietet einen realistischen Maßstab für Verbesserungen. Wenn ein neues, komplexes Modell entwickelt wird, gibt die Baseline Aufschluss darüber, wie viel besser das neue Modell im Vergleich zu einfacheren Ansätzen ist. Es ist wie das Wissen um die Geschwindigkeit und Stabilität eines alten Schiffes, bevor ein neues, modernes Schiff gebaut wird.
2. Sie hilft, die Erwartungen zu kalibrieren. In der Welt der MLOps ist es leicht, sich von den Versprechungen neuester Technologien mitreißen zu lassen. Doch nicht immer führen komplexere Modelle zu besseren Ergebnissen. Die Baseline erdet uns und stellt sicher, dass wir die Vorteile neuer Ansätze objektiv bewerten.
3. Sie ermöglicht eine schnelle Iteration. Anstatt sofort mit komplexen Modellen zu beginnen, können Entwickler: innen mit der Baseline beginnen und schrittweise Verbesserungen vornehmen. Dies ist wie das schrittweise Aufrüsten eines Schiffes, anstatt ein neues von Grund auf zu bauen.

Und wo wir zuvor gerade von Aufgaben gesprochen haben, die zuvor von Menschen gelöst wurden: eine weitere bewährte Methode, die Performance einer KI bei einer gegebenen Aufgabe zu messen, ist der Vergleich zum Menschen …

Mensch versus Navigationssystem: Human Level Performance

Wenn wir eine Aufgabe mittels KI automatisieren wollen, die zuvor ein Mensch übernommen hat, kann die Leistung von Menschen eine gute Metrik sein, um herauszufinden, wie gut sich unsere KI macht. Idealerweise lassen wir diese auf exakt die gleichen Daten los, die auch der Mensch zu sehen bekommt. Dann müssen wir versuchen, aussagekräftige und messbare Vergleichsmetriken zu finden.

Ein Beispiel: Eine Firma, die gebrauchte Handys recycelt, hat einen Prüfstand auf dem schnell und nach „Augenmaß“ entschieden wird, ob ein Gerät erneuert und wiederverkauft werden kann, ob es sich als Ersatzteillager lohnt oder ob es keinen Wert mehr hat und komplett verschrottet werden muss.

Um uns eine zuverlässige Metrik zu schaffen, begleiten wir die Person, die für diese Entscheidungen zuständig ist, an einem typischen Arbeitstag und untersuchen alle Geräte, die sie den Tag über geprüft hat, im Labor auf tatsächliche Verwertbarkeit. Jede Entscheidung bei der das Labor mit ihrem Urteil übereinstimmt ist ein Treffer. Daraus errechnen wir eine Trefferquote zum Beispiel von 87 %. Was erstmal nach nicht viel klingt, kann im laufenden Betrieb und aus Zeitersparnisgründen trotzdem effektiv sein. Diese selben Geräte können wir auch als Maßstab für ein trainiertes Modell nutzen und so prüfen, wie nah es an die Trefferquote des Menschen herankommt. Akzeptable Ergbnisse sind, wenn wir die Ergebnisse des Menschen mindestens zu 95 % reproduzieren können. Unsere Fehlerrate ist hier also reduziert um die Leistung des Menschen, tatsächlich richtig erkannt hätte man mit dieser Quote immerhin noch 82,65 % der Geräte.

Es ist aber auch gut möglich, dass unser Modell, das ja auf tatsächlich untersuchten Geräten trainiert wird, den Menschen übertrifft und 92 % aller geräte richtig einsortiert. Dies entspräche 105 % der Trefferquote des Menschen. Aber hier müssen wir vorsichtig sein. Denn KIs können gleichzeitig auf dem Papier eine durchschnittlich deutlich bessere Performance als Menschen abliefern und die „dümmsten Fehler machen“. Das liegt daran, dass Menschen viele Entscheidungen durch weiteren Kontext treffen können, während die KI „passen“ muss, weil ihr Informationen fehlen. Human Level Performance kann also ein erster Indikator sein ob wir auf dem richtigen Weg sind und unsere Lösng konvergiert, sie sollte aber niemals der einzige Maßstab sein. Und unser Training sollte immer möglichst breit aufgestellt sein und viele Situationen abdecken.

Aber wie stellen wir das sicher und wo holen wir entsprechende Daten her?

Daten kartografieren: Labeling

In manchen Fällen haben wir bereits alles was wir brauchen und können ein Modell auf unsere Daten loslassen. Sehr oft müssen wir aber Kontext hinzufügen, damit das Modell auf den erwarteten Antworten trainiert werden kann. Beispielsweise wenn wir ein Modell darauf trainieren wollen bestimmte Personen zu erkennen, wir brauchen nur zwei Listen Anlegen und unsere Fotos in diese einsortieren, die Bilder mit den zu erkennenden Personen und solche anderer zufälliger Personen. Das sind unsere Labels.

Das präzise Labeling von Daten ist wie das sorgfältige Kartografieren unerforschter Meere. Jedes Label ist ein Punkt auf der Karte, und jeder Fehler ist eine potenzielle Klippe, die unsere Reise gefährden könnte. In der Welt der MLOps ist ein akkurates und konsistentes Labeling entscheidend, um sicherzustellen, dass unser Modell die Welt so sieht und versteht, wie sie wirklich ist.

Stellen wir uns vor, wir sind Kartografen, mit der Aufgabe, unentdeckte Inseln zu kartieren. Jeder Fehler, jede falsche Markierung könnte dazu führen, dass zukünftige Seeleute in die Irre geführt werden. Ähnlich verhält es sich mit dem Labeling beim MLOps. Unsachgemäß gelabelte Daten können unser Modell in die Irre führen, zu falschen Vorhersagen führen und das Vertrauen in unsere KI-Systeme untergraben.

Das Labeling erfordert also Genauigkeit und ein tiefes Verständnis für die Daten und den Kontext, in dem sie verwendet werden. Es handelt sich um einen Prozess, der Sorgfalt und Aufmerksamkeit für Details erfordert. Wie in der Kartografie, bei der eine Person sicherstellt, dass jede Insel korrekt verzeichnet ist, müssen wir sicherstellen, dass jedes Datenlabel so präzise wie möglich ist.

Aber das Labeling ist nicht nur eine Frage der Genauigkeit. Es ist auch eine Frage der Perspektive. Wie Kartografie-Fachleute, die entscheiden, welche Merkmale einer Landschaft hervorzuheben sind, müssen wir entscheiden, welche Aspekte unserer Daten gelabelt werden müssen. Mit dem Ziel, das Problem, das wir lösen möchten, bestmöglich darzustellen. Dies erfordert ein tiefes Verständnis für das Problem und eine klare Vision davon, wie die gelabelten Daten verwendet werden sollen.

Und da Labels so gut wie immer von Menschen erstellt werden, gibt es auch hier eine Subjektivitätsfalle. Das heißt, Entscheidungen unterliegen immer auch kulturellen und persönlichen Einfärbungen und damit Vorurteilen der jeweiligen Person. Das ist unausweichlich und sollte uns daher bei jedem bereits gelabelten Datenset, das wir einkaufen, bewusst sein. Wollen wir möglichst neutrale und allgemeingültige Labels, kann es notwendig sein, ein vielfältiges Team aus diversen Persönlichkeiten zusammenzustellen.

Fazit

Ich würde sagen: Wir erreichen gerade die 30-Meter-Marke auf  unserer Tauchreise durch die Tiefen des Datenmeers. Wir haben gesehen, dass das Erfolgsgeheimnis eines ML-Projekts nicht allein in der Modellarchitektur oder den ausgeklügelten Algorithmen liegt, sondern in der gründlichen Vorbereitung und dem bewussten Umgang mit Daten. Wie ein erfahrener Kapitän, der seine Route sorgfältig plant und seine Ressourcen klug einsetzt, müssen auch wir unsere Datenlandschaft genau kartieren, potenzielle Gefahrenstellen identifizieren und frühzeitig entscheiden, ob wir auf dem richtigen Kurs sind.

Das Navigieren im Meer der Daten erfordert Präzision, Umsicht und die Bereitschaft, jederzeit auf neue Herausforderungen zu reagieren. Nur wenn wir die notwendigen Vorbereitungen treffen, können wir sicherstellen, dass unser ML-Schiff auch in stürmischen Gewässern stabil bleibt und sein Ziel erreicht.

Am Ende gilt: Die Qualität unserer Ergebnisse hängt nicht nur davon ab, wie gut unser Modell trainiert ist, sondern vor allem davon, wie gut wir unsere Daten verstehen und nutzen. Jedes Projekt ist einzigartig, und es gibt keine allgemeingültige Lösung. Doch mit einem soliden Verständnis für die Daten und einer klaren Strategie können wir den Erfolg unserer ML-Vorhaben erheblich steigern.

Ausblick

Jetzt, wo der Kompass kalibriert ist und die Karten gezeichnet sind, kann die Reise weitergehen. Schließlich gilt es, den Schatz zu heben, der sich in unseren Daten verbirgt. Im nächsten Artikel werden wir daher die Sauerstoffflasche gegen eine Taucherglocke tauschen und noch tiefer abtauchen: Es geht um die Frage, was wir tun können, wenn die Menge oder Qualität unserer Daten nicht ausreicht und wie wir die Daten in eine Form bringen, mit der unser Modell arbeiten kann.

Oder, um in der Seefahrtssprache zu bleiben: Wie machen wir unsere Gewässer befahrbar?

Überblick Artikelreihe Machine Learning mit MLOPs:

-> Einführung MLOps: Woran scheitern die meisten ML-Projekte, und wie kann MLOps helfen?

-> Scoping mit MLOps: Wie schätze ich ein Projekt und die dafür benötigten Ressourcen richtig ein?

-> Daten verstehen mit MLOps: Aktueller Artikel

-> Daten verarbeiten mit MLOps: Wie hole ich das Meiste aus meinen Daten heraus?

-> Modelltraining: Was brauche ich, um ein Modell auf den eigenen Daten zu trainieren? Wie wähle ich das geeignete Modell und wie können Automatisierung und Pipelines die Arbeit erleichtern?

-> Deployment: Wie integriere ich das Modell in ein zukünftiges oder bestehendes System bzw. eine Infrastruktur? Welche Strategien ermöglichen einen reibungslosen Umstieg?

-> Monitoring und Maintenance: Wie überwachen wir ab hier unser bestehendes ML-System? Welche Entwicklungen können Anpassungen erfordern? Wie bereiten wir uns auf diese vor?