Die 11 Fallen im Machine Learning

Es ist leichter denn je, Machine Learning (ML) einzusetzen. Die Software, sowie Tutorials und Anleitungen gibt es umsonst oder für kleines Geld. Ein erfahrener Softwareingenieur kann sich recht schnell in die Materie einarbeiten und schnell Ergebnisse produzieren. Klingt zu gut, um wahr zu sein? Ist es auch, denn es gibt viele Fallen auf dem Weg zum ML-gestützten Produkt. Hier hilft Erfahrung im Systems Engineering, denn eine ML-gestützte Anwendung besteht aus vielen Teilsystemen mit komplexen Abhängigkeiten.

Warum Machine Learning?

Machine Learning, oder maschinelles Lernen, ist ein Teilbereich der künstlichen Intelligenz. Ein ML-System muss mit Beispielen trainiert werden. Nach der Trainingsphase kann das ML-System das Gelernte verallgemeinern.

Anwendungsfälle für Machine Learning gibt es viele – es muss ja nicht gleich ein autonomes Fahrzeug sein. ML wird viel im medizinischen Umfeld angewendet, zum Beispiel bei der Erkennung von Tumoren auf Röntgenaufnahmen. Auch in der Textanalyse wird ML viel eingesetzt, zum Beispiel bei der Analyse von Chatverläufen, um die Antwort für Kunden automatisch zu finden, oder deren Stimmung zu analysieren, um bei Frustration an einen Menschen weiterzuleiten.

Unternehmen können Machine Learning direkt im Produkt verbauen. Wenn Google beim Tippen Textvorschläge macht, dann ist das ein ML-gestütztes Produktfeature. Ein anderes Beispiel ist die Erkennung von Vorhofflimmern einer Smartwatch.

Alternativ kann ML natürlich auch intern eingesetzt werden, zum Beispiel, um Kundendaten zu analysieren oder als Teil der Marktforschung.

In wenigen Schritten zum ML-System

Für einen erfahrenen Softwareentwickler ist es recht leicht, sich in die Materie einzuarbeiten. Insbesondere Google hat 2015 den Markt durch die Veröffentlichung von TensorFlow aufgemischt, einem quelloffenen Framework. Das ist nur eines der bekannteren Frameworks. Es gibt viele andere und ein ganzes Ökosystem an unterstützender Infrastruktur, kostenlos und kommerziell.

Jede Entwicklung eines ML-Systems beginnt mit einer interessanten Frage: “Was ist die Stimmung des Kunden?”; “Hat der Mensch Vorhofflimmern?”, usw.

Im nächsten Schritt erheben wir Daten. Ein wichtiger Teil der Daten sind Labels, also die Klassifizierung der Daten. Es reicht also nicht, EKGs von Menschen zu sammeln. Die EKGs müssen als gesund oder nach Störung klassifiziert werden.

Darauf folgt ein Analyseprozess, in dem die Daten untersucht und für das ML-System vorbereitet werden, zum Beispiel durch die Identifizierung von relevanten Features.

Dieses Verständnis ermöglicht es uns, ein Modell zu erstellen, welches hoffentlich auch neue Fragen richtig beantworten kann.

Als letztes müssen die Ergebnisse aufbereitet, bzw. dem Anwendungsfall entsprechend kommuniziert werden.

Das klingt soweit alles machbar, doch auf dem Weg zum Erfolg gibt es viele Fallen:

1. Falle: Daten sind Mangelware!

“Daten sind überall, wir müssen sie nur einsammeln” – von wegen! Zum einen haben die meisten Firmen wesentlich weniger relevante (!) Daten als sie denken. Zum zweiten haben diese Daten in der Regel noch keine Labels. Der Umgang mit Daten erfordert eine Strategie, die im Voraus etabliert werden sollte. Dazu später noch mehr.

2. Falle: Was ist “gut genug”?

ML-Systeme spucken in der Regel eine Zahl aus: “Das Ergebnis hat eine 80%-ige Genauigkeit”. Doch was genau bedeutet das? Das Einfachste ist noch zwischen “False Positives” und “False Negatives” zu unterscheiden. Ist es schlimmer, Vorhofflimmern nicht zu erkennen? Oder einen gesunden Menschen zu warnen, dass dieser möglicherweise unter Vorhofflimmern leidet? Und welche Wahrscheinlichkeiten sind akzeptabel?

Selbst wenn es nicht um potentiell lebensgefährliche Informationen geht, sollten diese Dinge mit den Stakeholdern diskutiert und quantifiziert werden. Ein Abzeichnen der Entscheidungen ist empfehlenswert oder sogar erforderlich (Compliance).

3. Falle: Können wir den Ergebnissen trauen?

Die eben genannte Genauigkeit bezieht sich auf die Daten, die wir als Input verwendet haben. Doch sind die Ergebnisse verlässlich? Ein oft zitiertes Beispiel betrifft die Identifizierung von Huskies. Das System lernte stattdessen Schnee zu erkennen.

4. Falle: Kann das Modell den Nutzern schaden?

Diese Falle ist mit der vorhergehenden verwandt. Ein Beispiel sind einseitige oder vorurteilsbelastete Daten, die dunkelhäutige Menschen diskriminieren. Das hat bereits zu Problemen bei medizinischen und juristischen Anwendungen geführt.

Die Lösung dieses Problems erfordert eine entsprechende Datenhygiene: Wo kamen die Daten her, wer hat das Labeling vorgenommen? Labeling ist, wie bereits in der 1. Falle erwähnt, eine sehr wichtige Aktivität. Es gibt inzwischen auch leistungsfähige Werkzeuge, die Entscheidungen des ML-Systems erklären können. Diese helfen bei der Kontrolle.

5. Falle: Können Nutzer das Modell missbrauchen?

Bei Falle 4 ging es um belastete Daten. Doch auch die Endanwender könnten versuchen, das Modell gezielt zu missbrauchen. Die Möglichkeiten sind vielfältig, vom gezielten Verfälschen des Modells bis hin zum Diebstahl vom Modell.

6. Falle: Bugs im Modell

Die Veröffentlichung eines ML-Systems ist ein großer Schritt, doch wie geht es danach weiter? Wie bei jedem System wird es “Bugs” geben, doch diese können nicht wie in der traditionellen Softwareentwicklung korrigiert werden.

Ein Beispiel wäre ein ML-System, das Käufer und Verkäufer zusammenbringen soll, indem die von den Nutzern eingestellten Texte analysiert werden. Falls es sich hier um ein Flohmarktsystem handeln sollte, kann alles Mögliche angeboten werden. Vielleicht kommt so ein System durcheinander, wenn Sammler alter Münzen mit Goldhändlern zusammengebracht werden.

Wichtig ist zunächst, die Bugs in der Form von Unit Tests in die Entwicklung mit aufzunehmen. Um bei dem Beispiel zu bleiben: Hier sollten eine Reihe von Beschreibungen aufgenommen werden, und zwar die True und False Negatives, sowie True und False Positives. Denn eines ist klar: Die Liste der Bugs wird immer länger werden und dementsprechend auch die Liste der Tests.

7. Falle: Unzureichende Versionierung

Wenn wir nun einen Bug identifiziert haben, können wir diesen korrigieren. Das kann an verschiedenen Stellen passieren: Im Code oder in den Trainingsdaten. Daher sollte auch unbedingt beides in einem Repository versioniert werden.

Doch damit reicht es nicht aus: Wir müssen auch die Testergebnisse versionieren, denn hier haben wir bald das nächste Dilemma: Ein altes Modell mit den alten Trainingsdaten hat eine bestimmte Qualität (siehe 2. Falle). Doch wenn wir neue Testfälle haben, dann ändert sich auch die gemessene Qualität. Daher ist es auch unbedingt notwendig, auch die alten Modelle neu zu bewerten, wenn sich die Trainingsdaten ändern.

8. Falle: Verschlimmbesserungen

Aus der 6. und 7. Falle ergibt sich, dass neue Bugfixes alte Bugfixes beeinflussen. Hier ist es erforderlich, die Stakeholder aufzufordern, Kompromisse zu quantifizieren. Es gibt dabei drei Parameter:

• Wie viele Nutzer sind betroffen? Je mehr, desto kritischer.
• Wie extrem ist der Fehler? Also “ein bisschen falsch” oder komplett daneben?
• Wie schädlich ist der Fehler? Die Frage muss für alle Stakeholder beantwortet werden. Eine falsche Krediteinschätzung könnte für die Bank schädlicher sein als für den Kreditnehmer.

Für jeden Bug ergibt das Produkt dieser drei Faktoren eine Priorität, die uns bei der Umsetzung führt.

9. Falle: Überraschendes neues Verhalten

Das Verhalten unseres Modells verändert sich zwangsläufig. Wir müssen verstehen, was das für die Stakeholder bedeutet. Ein klassisches Beispiel ist die Vertriebsmitarbeiterin, die sich ein schönes Demo-Skript zurechtgelegt hat. Es ist gut möglich, dass während einer Demo im Vertriebsgespräch das System ein unerwartetes Ergebnis liefert und die Vertriebsmitarbeiterin aus dem Konzept bringt.

10. Falle: Das Nutzerverhalten verschiebt sich langsam

Gerade wenn wir längere Zeiträume betrachten, kann sich das Nutzerverhalten verändern. Da dies relativ langsam vonstatten geht, kann sich dadurch der Kundennutzen langsam aber sicher verschlechtern. Daher ist es wichtig bei der Datenpflege auch die alten Daten regelmäßig zu analysieren und bei Bedarf zu aktualisieren.

11. Falle: Instabilitäten

Ein Modell kann leider auch schnell instabil werden. Das kann viele Gründe haben, ein wichtiger Grund ist die Datenqualität. Am Ende muss ein Mensch das Labeling durchführen. Wenn die Personen nicht entsprechend geschult werden, dann können sie Labels inkonsistent vergeben, was das Modell destabilisiert. Eine Lösung wäre, die selben Daten von mehreren Menschen labeln zu lassen, was wieder die Kosten in die Höhe treibt. So ein Vorgehen kann allerdings auch helfen, schwierige Probleme zu erkennen: Wenn sich die Labeler nicht einig sind, ist das ein Indiz für ein Problem, das genauer untersucht werden sollte.

Es gibt auch verschiedene Techniken, um Instabilitäten zu erkennen, wie das Injizieren von Rauschen. Wenn dies die Ergebnisse stark beeinflusst, haben wir ein instabiles Modell.

Fazit

Es ist erfreulich einfach, mit Machine Learning loszulegen. Der Weg zum Erfolg ist jedoch lang und es gibt jede Menge Fallen auf dem Weg. Wie bei vielen Dingen ist es wichtig, eine nachhaltige Strategie zu etablieren und alle Stakeholder mit ins Boot zu holen.

Ebenso ist es wichtig zu erkennen, dass ein ML-System ein sehr komplexes “System of Systems” ist, bei dessen Entwicklung die Prinzipien des Systems Engineering angewendet werden müssen. Das Zusammenspiel von Trainingsdaten und System kann zum überraschenden Verhalten führen. Erfahrung im Systems Engineering hilft, die 11 Fallen zu umschiffen.

Photo by Susan Q Yin on Unsplash