Stefan Toth
08.06.2021
Machine Learning eröffnet neue Möglichkeiten, bringt aber auch neue Herausforderungen für Technologie, Methodik und Organisation. Ein kleiner Einblick ...
Wahrscheinlich haben Sie von autonom fahrenden Autos gehört, benutzen ein Handy mit Gesichtserkennung und/oder verwenden Amazon oder andere Webseiten mit lernenden Subsystemen. Hier sind spannende Lösungen zu finden! Bei Spotify etwa wird nicht nur aus dem Hörverhalten gelernt, sondern es werden Musikseiten wie Pitchfork oder die Rolling Stone Seite analysiert, um beschreibende Wörter und Phrasen für Musik zu lernen. So entwickeln sich nicht nur die sogenannten „Audio Vector Spaces“ weiter, in denen Spotify Musik clustert, sondern auch die Grundlage auf der Musik überhaupt kategorisiert wird.
Machine Learning ist also cool. Und wie bei allen anderen Hype-Themen auch, hat die Diskussion drumherum Schlagseite und teilweise wenig Tiefe. Oft scheint es, als wäre Machine Learning nur die Auswahl des richtigen Lern-Algorithmus und des richtigen Tools, das diesen Algorithmus abbildet. Nachdem Daten für lernende Prozesse zentral sind, rücken manchmal auch statistische Prozesse und Datenlösungen in der Cloud ins Zentrum. Das sind alles wichtige Bausteine, doch mich interessiert in diesem Blogpost noch etwas anderes: Steckt hinter all diesen Techniken, Algorithmen, Daten-Pipelines und Werkzeugen auch Methode? Oder ist Machine Learning “nur” herumprobieren mit Fancy Tools und hoffen auf eine funktionierende Lösung?
In Machine Learning Vorhaben wird die Logik einer Softwarelösung nicht direkt entwickelt. Stattdessen arbeiten Algorithmen an unserem Problem, die sich selbständig verbessern indem sie Daten und/oder Feedback nutzen. Die Lösungsstrukturen, die dabei entstehen, sind für uns als Entwickler transparent und vielleicht auch irrelevant. Ist in dieser datengetriebenen Welt tatsächlich nichts mehr so stabil und zentral, dass es schwer änderbar ist? Wenn ein ML-Algorithmus mit wenig Aufwand neu trainiert werden kann, ist die Reaktion auf veränderte Tatsachen und damit das ganze Thema „Wartbarkeit“ geschenkt?
Softwarearchitektur beschäftigt sich mit fundamentalen und im weiteren Verlauf nur schwer änderbaren Entscheidungen, die den Erfolg eines Systems maßgeblich beeinflussen. Traditionell passen Strukturentscheidungen rund um Architekturmuster, Serviceschnitt und Abhängigkeiten gut in diese Definition. Etwas breiter gedacht sind aber auch Schnittstellen, Zielumgebungen, zentrale Entscheidungen zum Technologiestack und Vorgehensaspekte (wie Auslieferungs- oder Testprozesse) architektonisch relevant. Es ist unwahrscheinlich, dass ein ernsthaftes Machine Learning Vorhaben diese Aspekte alle ausblendet oder umschifft. Auch wenn sich der Charakter von Architekrturarbeit ändert, ist sie im ML-Kontext relevant und wichtig.
Es gibt einige spannende Entscheidungen in einem Machine Learning Vorhaben. Das wären zum Beispiel:
Aus dieser Liste möchte ich stellvertretend zwei Fragen herausgreifen und etwas tiefer besprechen. Andere Fragestellungen können wir bei Interesse in späteren Blog-Posts vertiefen.
Die vielleicht grundlegendste Frage der obigen Liste scheint trivial, hat allerdings viel damit zu tun, überhaupt sinnvolle Anwendungszwecke für Machine Learning zu finden. Machine Learning Ansätze können mit unterschiedlichen Strategien eine Vielzahl von Problemen lösen (siehe Abbildung 1), allerdings stellt sich die Frage, welche Probleme aus dem eigenen Kontext geeignet dafür sind.
Jede gezeigte Strategie aus Abbildung 1 will ausgewählt und muss trainiert werden. Im Falle von Supervised Learning trainieren wir, indem wir ein Trainingsset von Daten mit gewünschten Ergebnissen vorgeben. Danach soll das Modell auf andere Daten verallgemeinern. Im Unsupervised Learning versucht ein Algorithmus selbst Muster in den Daten zu erkennen, die wir nicht vorgeben. So entstehen etwa Cluster nach nicht vorgegebenen Attributen oder es werden Anomalien identifiziert. Im Reinforcement Learning wird das Ergebnis eines Algorithmus bewertet und dieser lernt gute Entscheidungswege von schlechteren zu unterscheiden.
Unsere Tätigkeit als Entwickler ist folglich, die passende Lernstrategie zu wählen und Daten sorgfältig handzuhaben. Die Regeln, die wir normalerweise selbst schreiben, entstehen durch den Prozess des Trainings (siehe Abbildung 2).
Was kann man aus der Tatsache, dass Machine Learning auf höherer Abstraktionsstufe mit fachlichen Problemen arbeitet, ableiten? Zunächst lässt sich festhalten, dass die Regeln, die aus den Daten entstehen, potentiell freier von Bias sind. Mit Daten unterfütterte Entscheidungen sind oft hilfreicher als frei „erfundene“ Business-Regeln. Außerdem schlägt ein Machine Learning Algorithmus häufig menschliche Vorhersagefähigkeit, wenn es um nicht-triviale Probleme geht.
Ein weiterer Vorteil von Machine Learning ist, dass wir die Regeln die wir abbilden wollen gar nicht genau kennen müssen. In den Grauzonen unserer Realität kann das sehr hilfreich sein. Während wir uns als Menschen mit vereinfachten Modellen herumschlagen, um z.B. Nutzerverhalten zu verstehen, kann ein ML-Algorithmus viel komplexere Zusammenhänge stemmen, schleichende Änderungen erkennen und die vielschichtige Realität besser abbilden.
Dieser Vorteil wird jedoch zum Nachteil wenn klare Regeln vorhanden sind. Will man etwa Gesetze und Vorschriften nachbilden, ist es sehr ineffizient und schwierig einen ML-Algorithmus mit Daten zu füttern und anschließend zu beweisen, dass das trainierte Modell auch in allen Nuancen korrekt arbeitet.
Der Sweet Spot von Machine Learning liegt folglich in hochdimensionalen Problemen, die noch mit Daten beschreibbar und vom Menschen begleitbar sind.
Dies ist eine weitere interessante Fragestellung von oben, die etwas fortgeschrittener ist als die erste behandelte Frage. Abbildung 3 zeigt ein übliches Problem in Machine Learning Vorhaben. Einerseits will man möglichst frei mit Daten und Lernstrategien hantieren, um Möglichkeiten auszuloten und Ansätze schnell zu wechseln (Exploration). Andererseits will man produktive ML-Lösungen auch skalierbar, performant und professionell aufgesetzt wissen, inkl. fachlichem Monitoring, Integration in die bestehende Landschaft und einer gesunden Testbasis (Produktion).
Diese Lücke ist auch wegen den üblicherweise beteiligten Rollen relevant (Data Scientists und Machine Learning Experten links, Software Ingenieure und Operations Experten rechts). Tatsächlich interessant wird sie aber, weil wir nicht nur einmal in der Exploration probieren, was möglich ist und dann einmal professionalisieren. Stattdessen sollten Erkenntnisse aus der Produktion und mögliche schleichende Änderungen aufgegriffen werden und zu weiterer Exploration führen. Diese Iteration macht in der Praxis Probleme und führt zu sehr unterschiedlichen technischen und organisatorischen Aufsätzen von ML Projekten.
Konkret gibt es drei Möglichkeiten in einem ML-Vorhaben mit dieser Lücke umzugehen. Abbildung 4 zeigt sie im Überblick.
Tatsächlich findet man jedes dieser Modelle in der Praxis wieder. Einige unserer Kunden setzen etwa auf Professionalisierung der Exploration und fördern professionelle Software-Engineering auch in Data Science Phasen (in Abb. 4 ganz oben). Andere setzen in eigenen Initiativen auf einen expliziten Professionalisierungsschritt, wenn die Exploration erfolgreich war (unten in Abb. 4). Hier sind interessante Verantwortungsfragen zu klären, dafür können beide Seiten optimal aufgestellt werden. Werden Tools wie Kubeflow oder Amazon Sagemaker eingesetzt, landet man implizit bei der mittleren Lösung, in der ein wenig professioneller exploriert wird, dann aber auch teilweise schwer testbare Lösungen in Produktion wandern, um einen Bruch zu verhindern.
Mit der Toolauswahl beeinflussen Sie also ggf. auch sehr zentrale methodische Fragen im ML Vorhaben, und dabei reden wir noch gar nicht von ML-Workflows oder Pipelining von Daten.
Wir haben uns in diesem Blogpost nur zwei von vielen architektonischen Fragen angesehen, die im ML-Kontext auftreten. Machine Learning Vorhaben arbeiten auf einer anderen Abstraktionsstufe, arbeiten datenzentriert, involvieren andere Rollen und erfordern eine andere Projektanatomie. Es geht also nicht ausschließlich um statistische Fähigkeiten und Werkzeuge wie Scikit-Learn, TensorFlow oder Keras. Was Sie im Machine Learning Umfeld leisten müssen, ist umfangreich und tiefgreifend. Wenn Sie über einzelne Inseln mit ein paar ML-Experimenten hinaus kommen wollen, müssen Sie professionalisieren und neu über Softwareentwicklung nachdenken.
Am 24. Juni 2021 findet bei embarc übrigens ein geselliger Sommernachmittag mit tollen Menschen, spannenden Vorträgen und vielen interaktiven Formaten statt. Oliver Zeigermann ist auch mit einem Vortrag aus dem Themenfeld Machine Learning direkt dabei. Save the date!