14Analytics im Onlinehandel

Mikio Braun

Der Onlinehandel ist traditionell sehr zahlengetrieben und Analytics, BI und Data Science bilden dabei die Grundlage der Entscheidungssysteme. Am Beispiel von Zalando, dem größten europäischen Versandhändler im Bereich Mode, werden verschiedene Herausforderungen, die bei der Nutzung von Data Science in diesem Umfeld gemeistert werden müssen, aufgezeigt und mögliche Lösungsansätze entwickelt. Neben der Frage, wie die Zusammenarbeit von Data Scientists und Programmierern aussehen kann, werden auch Architekturmuster vorgestellt, die sich bei der produktiven Nutzung von maschinellen Lernmethoden als hilfreich erweisen. Abschließend wird der Frage nachgegangen, was man auf Firmenebene tun kann, um den Einsatz von Data Science zu unterstützen.

14.1Einleitung

Zalando ist 2018 der größte europäische Versandhändler im Bereich Mode. Seit seiner Gründung 2008 ist die Firma rasant gewachsen und hatte 2017 einen Gesamtumsatz von rund 4,5 Mrd. Euro.1 Zalando ist nicht nur der eigentliche Webshop, sondern betreibt auch seine eigenen Lagerhäuser und hat weitere Unternehmungen wie die Zalando Lounge und Zalon.

Zalando war von Anfang an sehr zahlengetrieben und hat früh angefangen, die Grundlage für Analytics, BI und Data Science zu schaffen. In dieser Fallstudie soll es vor allem um Letzteres gehen und um die besonderen Herausforderungen, die eine Firma von der Größe wie Zalando stemmen muss, um Data Science firmenweit einsetzen zu können.

Ein Beispiel für einen Bereich, der heute vollständig von Methoden des maschinellen Lernens getrieben ist, sind die Empfehlungen. Die Teams, die für die Empfehlungen zuständig sind, stellen einen Backend-Service bereit, der in einer Vielzahl von Anwendungsfällen aufgerufen wird, wie bei den Empfehlungen auf der Artikelseite oder dem Newsletter per Mail.

Es gibt viele verschiedene Möglichkeiten, Empfehlungen bereitzustellen, die nicht notwendigerweise den Einsatz von Methoden des maschinellen Lernens erfordern. Zum Beispiel könnte man einfache Regeln wie zum Beispiel »zeige Artikel derselben Kategorie und Farbe, sortiert nach Beliebtheit« anwenden. In der Vergangenheit hat sich jedoch gezeigt, dass es sehr aufwendig ist, diese Regel über viele Artikelkategorien oder Preissegmente zu optimieren.

Der grundsätzliche Ansatz bei der datengetriebenen Optimierung von Empfehlungen besteht darin, das Nutzerverhalten zu analysieren. Indem man die Nutzeraktionen nach Besuchen gruppiert, kann man verfolgen, wie das Interesse des Nutzers seine Bahnen durch die Artikelgruppen zieht. Basierend darauf kann man Modelle aufstellen, die versuchen, das Verhalten des Nutzers vorherzusagen.

Inhaltsbasierte Empfehlungsmethoden verwenden Artikelattribute zur Vorhersage. Die Regeln ähneln denen des manuellen Ansatzes, werden aber automatisch über große Datenmengen eingestellt, was die Qualität der Empfehlungen sehr positiv beeinflusst.

Bei den Methoden des Collaborative Filtering dient ausschließlich das Benutzerverhalten dazu, Artikelähnlichkeiten zu identifizieren. Diese Methoden werden oft mit »Kunden, die sich dies angeschaut haben, haben sich das auch angeschaut« umschrieben. Tatsächlich ist es aber so, dass eine Ähnlichkeit zwischen Artikeln aufgrund der Kundenmengen, die sich die Artikel angeschaut haben, bestimmt wird. Zum Vergleich der Kundenmengen verwendet man z.B. das Skalarprodukt oder den Kosinus zwischen den Vektoren, die binär codieren, ob ein Kunde den Artikel angeschaut hat oder nicht.

Abb. 14–1Recommender-Systeme in der Praxis

Schließlich existieren weitere Methoden, die versuchen, das Kundenverhalten vorherzusagen. Diese Methoden schauen sich vergangene Kundenbesuche an und lernen, die Wahrscheinlichkeit vorherzusagen, dass ein Kunde auf einen bestimmten Artikel klickt. Diese Modelle verwenden wieder Artikel- und Kundenattribute, um auch für neue Artikel und Kunden gute Vorhersagen liefern zu können.

Bereits in diesem einfachen Bild (vgl. Abb. 14–1) deuten sich die Probleme an, die bei einer Firma von der Größe Zalandos auftreten. Zum Beispiel:

• Wo kommen die Daten her? Verschiedene Teams sind für die Seiten im Webshop zuständig, die die Ereignisse liefern.
• Die Verarbeitung der Daten erfordert zum Teil große Berechnungsressourcen. Wo bekommt ein Team diese her?
• Überhaupt hat dieses Projekt hohe Anforderungen sowohl im Bereich maschinelles Lernen als auch in den Softwarekomponenten. Was ist der beste Weg, diese zu organisieren?

Im Folgenden werden wir einige dieser Aspekte am Beispiel einer Firma wie Zalando behandeln.

14.2Maschinelles Lernen: von der Uni zu Unternehmen

Die maschinellen Lernmethoden waren bis vor gar nicht so langer Zeit hauptsächlich in der universitären Forschung zu finden, wo sie entwickelt und studiert wurden, um lernende Maschinen und letztendlich Systeme zu entwickeln, die künstliche Intelligenz besitzen. Seit Mitte der 2000er-Jahre haben diese Methoden jedoch vermehrt Einzug in die Industrie gefunden und sind dort mittlerweile nicht mehr wegzudenken.

Maschinelle Lernmethoden stellen einen interessanten alternativen Ansatz dar, Programme zu erschaffen, die gewisse Aufgaben erfüllen. Der klassische Ansatz der Programmentwicklung benützt üblicherweise eine mathematische Beschreibung des Problems und erfordert einen kreativen Akt, um ein Programm zur Lösung zu schreiben. Zum Beispiel lässt sich das Problem, den kürzesten Weg von A nach B zu finden, beschreiben durch: Bei einem gegebenen Straßennetz soll das Programm unter allen möglichen Wegen von A nach B den ausgeben, der am kürzesten ist.

Für viele Probleme in der wirklichen Welt ist das nicht so ohne Weiteres möglich. Zum Beispiel ist in der Bildverarbeitung das Problem der Objekterkennung nicht so einfach formal zu definieren, ohne zu vagen Beschreibungen zu kommen wie »das Programm soll sagen, ob auf dem Bild ein Tiger ist oder nicht«. Doch was heißt es mathematisch, dass sich in einem Bild ein Tiger befindet?

Das maschinelle Lernen (ML) verfolgt hier nun den Ansatz, das Problem durch Beispiele zu beschreiben, also etwa durch viele Bilder und die Information, ob sich in dem Bild ein Tiger befindet oder nicht. Dann wird ein Modell aufgesetzt, das von einer Vielzahl von Parametern abhängt, und diese Parameter werden so eingestellt, dass der Vorhersagefehler auf neuen Bildern möglichst klein ist (vgl. Abb. 14–2).

Abb. 14–2Lernen über Beispiele

Gerade für das Problem der Bilderkennung haben in den letzten Jahren sogenannte Deep-Learning-Modelle eine beeindruckende Verbesserung der Vorhersagegüte erreicht, die zum Teil sogar über dem liegt, was Menschen leisten können.

So beeindruckend dies ist, es erfordert signifikant mehr Aufwand, solche Modelle nicht nur einmal zu trainieren, sondern produktiv zu nehmen. In der Forschung ist die Arbeit mit den Modellen oft sehr manuell. Der Forscher kümmert sich selbst darum, die Dateien in mühevoller Kleinarbeit in das richtige Format zu bringen und zu bereinigen. Dann werden oft nur halbautomatisiert verschiedene Methoden und Konfigurationen ausprobiert, bis man schließlich ein gut funktionierendes Modell hat. Diese Erfolge werden dann in wissenschaftlichen Artikeln immer noch viel zu oft ohne den zugehörigen Programmcode veröffentlicht.

Um ML-Methoden produktiv zu nehmen, ist allein schon technisch einiges mehr zu leisten. So muss die gesamte Pipeline von den Rohdaten bis zu einem Modell automatisiert werden, damit sie regelmäßig vollautomatisch aktualisiert werden kann. Es reicht auch oft nicht, die Vorhersagen nur einmal auszurechnen, sondern die Vorhersagen müssen für andere Dienste in einer Softwarearchitektur verfügbar gemacht werden. Schließlich müssen die Systeme auch ausreichend überwacht werden, insbesondere wenn es sich um systemkritische Dienste handelt, um Ausfälle und Fehler zu detektieren.

Neben den technischen Herausforderungen gibt es die Frage, wie man einzelne Teams organisiert und wie die Zusammenarbeit zwischen Data Scientists und Entwicklern aussieht. Schließlich gibt es firmenübergreifende Themen, wie man ML und Data Science unterstützen kann. All dies werden wir im Folgenden behandeln.

14.3Wie arbeiten Data Scientists und Programmierer zusammen?

Es gibt verschiedene Möglichkeiten, die Zusammenarbeit von Data Scientists und Programmierern zu ermöglichen. Gerade wenn man erste Erfahrungen sammeln möchte, entscheiden sich viele Firmen für ein zentrales Data-Science-Team. Die Vorteile sind, dass die Data Scientists flexibel in verschiedenen Bereichen des Unternehmens eingesetzt werden können, ohne dass man direkt flächendeckend Data Scientists anstellen muss. Der Nachteil ist, dass es oft nicht gelingt, die Ergebnisse in die Produktionssysteme zu überführen, sodass es häufig bei Prototypen bleibt. Der Hauptgrund dafür liegt darin, dass die datengetriebene Lösung ein Fremdkörper für die Produktionsteams darstellt und diese oft ohnehin schon genug zu tun haben, um die Integration zu leisten.

Zalando hat auch anfangs dieses Modell verfolgt, sich dann aber nach einigen Jahren entschieden, die Data Scientists direkt in agile Produktionsteams zu integrieren. Die Idee ist, dass Data Scientists dann eng mit den anderen Softwareentwicklern zusammenarbeiten können und beide Seiten direkt von Anfang an an der Produktentwicklung beteiligt sind. Darüber hinaus können die Softwareentwickler die Data Scientists in ihrer Arbeit unterstützen und ihnen zum Beispiel helfen, die Produktionssysteme entsprechend performant und robust zu machen.

Dies erfordert natürlich, dass die Softwareentwickler offen sind und sich mit der neuen Technologie und den zum Teil andersartigen Arbeitsmethoden auseinandersetzen wollen. In der Praxis führt dies anfangs oft zu Reibung, da sich auf den ersten Blick die eher offene und forschungsgetriebene Arbeit der Data Scientists nicht gut in den Rahmen agiler Softwareentwicklung einpassen lässt.

Die Arbeit mit Daten und Methoden des maschinellen Lernens hat grundsätzlich einen etwas höheren Forschungsanteil als »normale« Softwareentwicklung. Dies liegt an den zusätzlichen Unsicherheiten, die die Arbeit mit Daten mit sich bringt. Zum Beispiel ist es nicht ohne Weiteres möglich, zu ermitteln, ob die Daten für die jeweilige Fragestellung geeignet sind. Es könnte zum Beispiel sein, dass die Daten die geforderte Information nicht enthalten oder dass die Daten eine zu schlechte Qualität haben, weil sie viele fehlerhafte Datenpunkte haben. Es kann auch sein, dass die Datenmenge für die Komplexität des Problems nicht ausreicht, usw.

Um diese Unsicherheit systematisch zu verringern, wenden Data Scientists ein Vorgehen an, das eng an die wissenschaftliche Arbeit angelehnt ist. Hierbei werden Hypothesen aufgestellt, die dann durch Experimente (durch Berechnung und Simulation) entweder bestätigt oder verworfen werden (vgl. Abb. 14–3).

Abb. 14–3Wissenschaftliches Arbeiten

Es liegt nun im Kern des wissenschaftlichen Arbeitens, dass man vorher nicht wirklich sagen kann, wie lange es dauert, bis man eine Antwort hat. Auf den ersten Blick läuft das der Art, wie üblicherweise Aufgaben in der Softwareentwicklung geplant werden, zuwider. In Scrum werden zum Beispiel pro Sprint Aufgaben definiert, die am Ende in einer Demo dem Kunden gezeigt werden können. Tatsächlich ist es oft ein Konfliktpunkt in gemischten Teams, die am Anfang ihrer Reise sind, dass die Data Scientists sich weigern, sich auf bestimmte Resultate festlegen zu lassen.

Andererseits ist das Arbeiten in Iterationen nichts, was der Forschung fremd ist. Die Idee, nicht erst lange Zeit ins Land gehen zu lassen, bis etwas Greifbares geliefert wird, sondern in kürzeren Abschnitten Stück für Stück etwas zu bauen, sodass man die Gelegenheit hat, das Design oder Features anzupassen, findet sich genauso in der Forschung wieder.

Wenn man einen Schritt zurücktritt, so sieht man, dass der gesamte Produktentwicklungsprozess, der durch agile Softwareentwicklung ermöglicht werden soll, im Kern auch ein Forschungsprojekt ist. Einer der Gründe für die agilen Methoden war die Einsicht, dass es oft nicht möglich ist, zu definieren, was genau der Kunde eigentlich möchte. Selbst wenn der Kunde genau spezifiziert hat, was er haben möchte, hat man am Ende oft festgestellt, dass das Feature in der Realität nicht so funktioniert, wie der Kunde es haben möchte. Die agile Softwareentwicklung versucht nun durch ein iteratives Vorgehen schnell Zwischenergebnisse zu liefern, die dann dem Kunden gezeigt werden können, um gegebenenfalls Anpassungen und Änderungen einfließen lassen zu können.

Teams aus Data Scientists und Softwareentwicklern kommen zusammen, wenn man nicht nur konkrete Entwicklungsaufgaben, sondern auch Forschungsaufgaben als mögliche Aufgaben zulässt. Das Ergebnis ist in Letzterem kein Feature, das in einer Demo gezeigt werden kann, sondern die Antwort auf eine Hypothese. Zum Beispiel kann die Hypothese lauten, dass eine bestimmte Methode auf den Daten besser funktioniert als der existierende Ansatz. Die konkreten Implementierungsarbeiten sind in diesem Fall bekannt und gut schätzbar und das Ergebnis kann auch am Ende des Sprints vorgestellt werden (vgl. Abb. 14–4).

Abb. 14–4Agiles Arbeiten in gemischten Teams

Ein weiterer wichtiger Unterschied in der Arbeit zwischen Data Scientists und Softwareentwicklern ist die Bedeutung des Quellcodes.

Für Entwickler ist der Quellcode (und die sich daraus ergebenden Produktionssysteme) das primäre Ergebnis ihrer Arbeit. Die Arbeit für Softwareentwickler ist sehr klar strukturiert, zum Beispiel durch die Verwendung von Pull-Requests, wie sie GitHub populär gemacht hat. Hierbei gibt es einen Hauptzweig, der die Hauptlinie der Entwicklung darstellt und an den hohe Anforderungen gestellt werden. Neue Features werden zunächst in Branches entwickelt und dann erst nach erfolgreichem Peer-Review in den Hauptzweig zurückintegriert (vgl. Abb. 14–5). Softwarequalität, Wartbarkeit und Fehlerrobustheit sind hohe Ideale, die erreicht werden wollen, damit die Software über Jahre weiterentwickelt und verwendet werden kann.

Abb. 14–5Vorgehen von Entwicklern

Für den Data Scientist dagegen ist der Quellcode oft nur Mittel zum Zweck, um mit Daten zu arbeiten oder Methoden auszuprobieren. Dies spiegelt sich auch darin wider, wie Programme geschrieben werden. Oft sind dies nur Skripte, die mehr oder weniger chaotisch organisiert sind und oft auch nicht zwischen verschiedenen Mitarbeitern geteilt werden. Die Entwicklung folgt hierbei den Einsichten, die die Experimente und die Datenanalyse liefern und oft nicht vorhersehbar sind. So kann es leicht geschehen, dass man in mehrere Sackgassen läuft, bevor man schließlich eine Lösung findet, die auch gerne aus Teileinsichten aus früheren Sackgassen bestehen kann.

So etwas wie einen Hauptzweig gibt es auch. In diesem können dann gefundene Lösungen gesammelt werden, zum Beispiel hochwertige Implementierungen komplexer Algorithmen oder Integrationen mit bestehenden Datenquellen, die wiederverwendet werden können (vgl. Abb. 14–6).

Abb. 14–6Vorgehen von Data Scientists

Diese beiden Herangehensweisen sind nicht ohne Weiteres in einem Prozess vereinbar, aber was hilft, ist diese Unterschiede den beteiligten Personen deutlich zu machen und eine klare Trennung von experimentellem Quellcode und Produktionscode herzustellen.

Gleichzeitig sollte der allmähliche Übergang von experimentellem Quellcode zu Produktionscode durch die Data Scientists mit Unterstützung der Softwareentwickler durchgeführt werden. Größere Experimente sollten ohnehin in einem Versionskontrollsystem gespeichert sein, damit man später rekonstruieren kann, wie Ergebnisse erzielt wurden. Idealerweise erhält man dann einen allmählichen Übergang von rein experimentellen Skripten zu Modulen, die bereits höheren Ansprüchen genügen und schließlich in die Produktionssysteme integriert werden können.

Gemischte Teams aus Data Scientists und Softwareentwicklern zum Erfolg zu führen ist eine große Herausforderung, die auch noch nicht letztendlich gelöst ist. Ein besseres Verständnis für die Unterschiede in der Arbeitsweise zu finden, Data Scientists in agile Softwareprozesse zu integrieren, indem man auch Aufgaben zulässt, die auf Erkenntnisgewinn aus sind, sowie die unterschiedliche Bedeutung von Quellcode zu verstehen und explizit zu machen, haben sich als gute Herangehensweisen erwiesen.

14.4Architekturmuster, um maschinelle Lernmethoden produktiv zu nehmen

Bei Zalando haben sich in den letzten Jahren in vielen Bereichen Teams etabliert, die aus Data Scientists und Softwareentwicklern bestehen. Diese Teams liefern zum Beispiel den Backend-Service, der Empfehlungen auf Artikelseiten oder im Newsletter liefert, beschäftigen sich mit der Vorhersage von Artikelnachfrage oder der Risikobewertung von Betrug.

Diese Teams haben relativ unabhängig voneinander ihre Lösungen gebaut, im direkten Vergleich zeigen sich jedoch bereits einige Architekturmuster, die sich wiederholen. Ganz im Sinne der Design Patterns aus der klassischen Softwareentwicklung sind dies Mikroarchitekturen, die einem die Arbeit ersparen können, das Rad neu zu erfinden.

Im Folgenden diskutieren wir ein paar exemplarische Designmuster, die sich grob in fünf Bereiche einteilen lassen können:

• Maschinelles Lernen
• Modelle ausliefern
• Datenvorverarbeitung und Feature-Extraktion
• Automation und Monitoring
• Integrationsmuster für maschinelles Lernen

14.4.1Architekturmuster des maschinellen Lernens

Dies sind die Designmuster, die sich mit der eigentlichen Anwendung des maschinellen Lernens beschäftigen. Hierzu müssen Daten beschafft werden, die anschließend vorverarbeitet werden, um dann ein Modell zu trainieren und zu validieren, woraus sich eine Schätzung für die Qualität des Modells ergibt.

Wir wollen hier zwei Hauptmuster herausstellen. Für die verschiedenen Anwendungsgebiete gibt es noch eine Vielzahl spezialisierter Muster.

In der Regel werden die Daten in einem Vorverarbeitungsschritt (»preprocess« in Abb. 14–7) aus ihrem Ursprungsformat in das Datenformat überführt, das der Lernalgorithmus benötigt. Hierbei werden verschiedene Berechnungen durchgeführt, zum Beispiel:

• Die Daten werden rein technisch von einem Datenformat in ein anderes überführt.
• Die Daten werden aggregiert oder anderweitig umorganisiert, um das eigentliche Lernproblem in der Form von Eingabe/Ausgabe-Beispielen zu erhalten.
• Es werden Merkmale (»features«) aus den Daten berechnet, die als Eingabe für den Lernalgorithmus benötigt werden.

Abb. 14–7Split, train, apply

Als Nächstes werden die Daten aufgeteilt (»split«), um Daten für das Training und für die Validierung im Test zu erhalten. Hierdurch soll simuliert werden, wie der Algorithmus auf zukünftigen Daten funktioniert. Schließlich wird das Modell trainiert und (»train«) auf den Testdaten angewendet (»apply«), um ein Maß für die Güte des Algorithmus zu erhalten (»error«).

Diese beiden Schritte, Vorverarbeitung und Validierung, kommen in quasi allen Anwendungsfällen des maschinellen Lernens vor. Im Folgenden beschäftigen wir uns jetzt mit weiteren Mustern, die besonders in Produktionssystemen auftauchen.

14.4.2Architekturmuster, um Modelle auszuliefern

Ist erst einmal ein Modell gelernt, geht es um die Frage, wie die Vorhersagen des Modells technisch zur Verfügung gestellt werden. Auf den ersten Blick denkt man vielleicht, man muss das System immer zum Beispiel als REST-Service verpacken. Tatsächlich gibt es je nach Anwendungsgebiet verschiedene Alternativen, von denen wir drei diskutieren werden.

Zunächst besteht die Möglichkeit, das Modell direkt in die Applikation zu integrieren (»Embed« in Abb. 14–8). Das Modell wird am Ende des Trainings hierzu in einer Datei serialisiert und dann von der Applikation beim Start geladen. Dies hat besonders dann Vorteile, wenn es notwendig ist, sehr viele Vorhersagen zu berechnen (weil beispielsweise die Applikation das Modell zur Planung verwendet und dafür viele verschiedene Werte ausprobieren muss, um die Lösung zu erhalten), oder wenn die Vorhersagen des Modells noch nachverarbeitet werden müssen, um Regeln anzuwenden, die manuell festgelegt werden. Zum Beispiel verwenden wir bei Zalando in der Produktempfehlung oft Regeln, die die Empfehlungen auf eine bestimmte Marke oder Kategorie beschränken. Dies passiert erst in einem zweiten Schritt nach der Anwendung des maschinellen Lernalgorithmus.

Abb. 14–8Verschiedene Architekturmuster für die Auslieferung von Modellen

Manchmal kann es sehr aufwendig sein, den Algorithmus in Echtzeit abzufragen und ihn dafür schnell genug zu bekommen. Vor allem Modelle des Deep Learning sind in der Vorhersage oft einige Größenordnungen langsamer als einfachere Modelle. Wenn jedoch die Vorhersagen für eine beschränkte Menge von Objekten berechnet werden müssen, dann kann es auch sinnvoll sein, die Vorhersagen vorab zu berechnen und in einer Datenbank zu speichern, von der sie dann für die Vorhersage aufgerufen werden (»Precompute«). Zum Beispiel kann man so die Vorhersagen für alle Artikel, die aktuell verkauft werden, berechnen und spart sich dann die Mühen, den Algorithmus auf Echtzeit zu trimmen.

Die letzte Möglichkeit ist nun tatsächlich, das Modell selbst zum Beispiel in einen REST-Service zu packen und als Echtzeitservice bereitzustellen (»Serve«). Für den letzten Fall ergibt sich die Frage, wie die Feature-Extraktion integriert wird. Hierzu kommen wir als Nächstes.

14.4.3Datenvorverarbeitung und Feature-Extraktion

Wie oben bei den Designmustern zum maschinellen Lernen erklärt, gibt es in der Regel einen ersten Schritt, bei dem die Rohdaten in Merkmale umgewandelt werden. Dies kann ein durchaus komplexer Schritt sein. Die Frage ist jetzt, wie diese Modelle dann berechnet werden, insbesondere, wenn die Modelle als Service eingesetzt werden.

Abb. 14–9Der Feature Store

Gerade bei komplexen Merkmalen (zum Beispiel Statistiken über das Nutzerverhalten wie Anzahl Besuche, die aus den Logdaten aggregiert werden) ist es oft nicht möglich, diese ad hoc für jede Anfrage neu zu berechnen.

Hierbei kommt in der Praxis oft ein Feature Store zum Einsatz (in Abb. 14–9 in der unteren Reihe). Dies ist ein Key-Value-Store, der für alle zu erwartenden Objekte die Features bereithält. Bei der Anfrage werden die Features für die Objekte in der Eingabe zur Laufzeit abgerufen und dann dem Modell gezeigt.

Es gibt verschiedene Varianten, wann die Daten in den Feature Store geladen werden. Die einfachere Variante (obere Reihe in Abb. 14–9) speichert die Merkmale, wie sie im Training berechnet werden, im Feature Store. Dies kann den Nachteil haben, dass es für neue Objekte (zum Beispiel neue Kunden oder neue Artikel) keine Merkmale gibt und keine gute Vorhersage geliefert werden kann.

Die komplexere Variante (untere Reihe) verwendet auch einen Feature Store, aber sie hat außerdem eine Echtzeitkomponente, die die Merkmale aus dem Ereignisstrom berechnet und im Feature Store aktualisiert.

Für den Feature Store kommen oft schnelle Key-Value-Datenbanken, wie zum Beispiel Redis, zum Einsatz. Solche In-Memory-Datenbanken sind besonders geeignet, da sie sehr schnell sind. Der Mangel an Persistenz ist kein Problem, da die Daten meist einfach aus Trainingsdaten rekonstruiert werden können.

14.4.4Automation und Monitoring

Diese Anforderungen ergeben sich daraus, dass in Produktionssystemen oft Modelle täglich neu trainiert und auch im Betrieb automatisch überwacht werden müssen.

Für die Automatisierung gibt es zahlreiche Tools. Die einfacheren (z.B. cron, oder Services wie AWS Scheduled Event) starten eine Berechnungsaufgabe zu einer bestimmten Uhrzeit, während die komplexeren, wie zum Beispiel airflow von Airbnb, die Definition komplexer Abhängigkeiten zwischen Berechnungsaufgaben erlauben und auch automatisch auf Fehler im Ablauf reagieren können.

Beim Monitoring besteht die Herausforderung darin, mehr zu liefern als das oft eher sehr technische Monitoring, das sich oft auf Latenzen und Fehlerraten beschränkt. Ein Fehler in der Trainingspipeline kann nämlich dazu führen, dass die Qualität des Modells massiv verschlechtert ist, ohne dass das System technisch versagt oder Auffälligkeiten zeigt.

Es hat sich gezeigt, dass das Monitoring von einigen Kernstatistiken der Daten bzw. Kernkenngrößen der Algorithmen helfen können, insbesondere wenn die Qualität der Algorithmen nicht unmittelbar zu überprüfen ist. Zum Beispiel kann die Vorhersagequalität eines Algorithmus zur Betrugsbekämpfung oft erst nach Monaten bestimmt werden, wenn letztendlich klar geworden ist, welche Bestellungen offenbleiben. Aber durch das Monitoring von statistischen Eigenschaften der Daten lässt sich zumindest sicherstellen, dass die Daten sich seit dem Training nicht grundlegend verändert haben.

14.4.5Integrationsmuster für maschinelles Lernen

Das maschinelle Lernen beschäftigt sich oft nur mit einem Teilaspekt der Aufgaben, die ein System leisten muss, um ein Produkt auszuliefern. Zum Beispiel verwenden wir Algorithmen, um die Nachfrage für Produkte vorherzusagen, aber diese Modelle werden dann von anderen Systemen verwendet, um den Handel zu steuern. Abschließend betrachten wir einige der Muster, um Methoden des maschinellen Lernens in bestehende Algorithmen zu integrieren.

Wir unterscheiden vier verschiedene Einsatzszenarien. Oft werden Modelle verwendet, um bestimmte Objekte zu bewerten. Zum Beispiel kann man die Wahrscheinlichkeit, dass ein Artikel von einem Kunden angeklickt wird, vorhersagen und dann darauf basierend Artikel auswählen, die einem Kunden angezeigt werden sollen.

Ein anderer Einsatz von maschinellem Lernen besteht darin, eine Eingabe zunächst zu verarbeiten, um dann damit mehr zu machen. Zum Beispiel kommt bei Chatsystemen oft maschinelles Lernen zum Einsatz, um die Spracheingabe des Nutzers in Text umzuwandeln.

Schließlich kann maschinelles Lernen eingesetzt werden, um eine Vorhersage über die Auswirkung bestimmter Aktionen zu berechnen. Zum Beispiel kann man die Nachfrage in Abhängigkeit vom Preis vorhersagen, um damit den Artikelpreis zu optimieren.

Die letzte Einsatzmöglichkeit besteht schließlich darin, ein System des maschinellen Lernens »end-to-end« einzusetzen. Dies ist möglich, wenn entsprechende Trainingsdaten in großer Menge vorhanden sind, und erfordert oft den Einsatz komplexer Deep-Learning-Modelle. Diese werden in der Zukunft noch eine große Rolle spielen.

Wie wir gesehen haben, kann man aus der Erfahrung des Einsatzes von Methoden des maschinellen Lernens bereits einige wiederkehrende Designmuster ableiten. Diese zu kennen und ihre Vor- und Nachteile zu verstehen, kann einem helfen, Architekturentscheidungen schneller und besser zu treffen.

14.5Was kann man sonst auf Firmenebene tun, um Data Science zu unterstützen?

Bislang haben wir mehr die Team- und Technologieebene betrachtet, um einige der Erfahrungen und Einsichten zu teilen, die wir bei Zalando gemacht haben. In diesem abschließenden Abschnitt werden wir einige der darüber hinausgehenden Themen behandeln, wie wir auf Firmenebene die Entwicklung für Data Science unterstützt haben. Dies sind im Wesentlichen drei Bereiche: (1) zentraler Eventbus und Data Lake, (2) Data Science Guild, (3) Zalando Research.

Daten sind ein essenzieller Bestandteil, um datengetriebene Lösungen in einem Unternehmen zu ermöglichen. Die Methoden des maschinellen Lernens erlauben es, Programme zu schreiben, die auch komplexe Aufgaben ausführen können, allerdings sind die Methoden auf eine große Menge an Beispielen angewiesen. Bei Zalando haben wir zu diesem Zweck sowohl einen zentralen Eventbus entwickelt als auch einen zentralen Data Lake, in dem alle relevanten Daten gesammelt werden.

Die Idee eines zentralen Eventbusses bedeutet, dass es einen Ort gibt, an dem Ereignisse publiziert und auch verarbeitet werden können. Hierdurch wird zum einen verhindert, dass Teams ihre eigenen Lösungen bauen, zum anderen wird die Integrationsarbeit zwischen Teams entkoppelt, da alles über den zentralen Eventbus geht.

Der zweite Schritt besteht darin, alle Daten, die auf dem zentralen Eventbus liegen, in einen Data Lake zu speichern. Hierdurch umgeht man wiederum das Problem, dass Teams eigene Lösungen bauen müssen, um Daten zu sammeln, zu teilen oder zu verarbeiten.

Es gibt weitere Vorteile, insbesondere im Rahmen der DSGVO, wofür jedoch das Konzept des klassischen Data Lake erweitert werden muss. Der »klassische« Data Lake versuchte, die oft sehr aufwendigen Integrationsprobleme eines Data Warehouse zu umgehen, indem erlaubt wurde, die Daten in beliebigen Formaten im Data Lake zu hinterlegen. In Bezug auf Sicherheit und zum Schutz der Privatsphäre kann ein Data Lake nun auch sehr nützlich werden, wenn man zumindest sicherstellt, dass es für den Data Lake transparent ist, welche Attribute in den verschiedenen Datensätzen gespeichert sind. Dann ist es zum Bespiel möglich, den Zugang zu Daten zentral zu regeln und langfristig auch die Teams zu entlasten, die ansonsten individuell die Anforderungen der DSGVO umsetzen müssten.

Data Scientists direkt in Produktionsteams zu haben, hat den Vorteil, dass sie eng mit Softwareentwicklern zusammenarbeiten können. Es führt aber auch andererseits dazu, dass sie isolierter sind und der oft wichtige Austausch mit Fachkollegen fehlt. Um diesen Effekt abzumildern, unterstützt Zalando die Organisation sogenannter Gilden, die von entsprechend motivierten Teilnehmern selbst geleitet werden. Solche Gilden gibt es für verschiedene Fachgruppen, aber auch für Programmiersprachen, Datenbanktechnologien oder rund um Themen wie »Data Engineering«.

Die Data Science Guild ist eine der größeren Gilden bei Zalando und organisiert zum Beispiel eine wöchentliche Vortragsreihe, bei der interne und externe Gäste Vorträge halten, Frühstücke und Mittagessen, die von Zalando gesponsert werden, und als Jahresevent, die data science days. Dies ist eine zweitägige interne Konferenz, bei der alle Data Scientists eingeladen sind, ihre Arbeiten zu präsentieren. Es gibt Vorträge und eine Postersession, wobei sichergestellt ist, dass alle vortragen können, die das wollen, und die Auswahl der Vorträge so erfolgt, dass ein interessanter und repräsentativer Querschnitt durch die Data-Science-Arbeiten bei Zalando entsteht.

Als Letztes sei noch Zalando Research erwähnt. Dies ist ein Team von etwa einem Dutzend Mitarbeiter, deren Aufgabe es ist, zum einen Grundlagenforschung zu leisten und zum anderen Teams in Pilotprojekten zu unterstützen, die eine hohe Innovationsanforderung haben. Der Unterschied zu zentralen Data-Science-Teams besteht vor allem darin, dass Zalando Research eng mit Data Scientists zusammenarbeitet, die bereits Teil der Teams sind.

14.6Fazit

Die flächendeckende Einführung von Methoden des maschinellen Lernens in Firmen von der Größe und technischen Komplexität von Zalando ist eine große Herausforderung. Wir haben drei verschiedene Aspekte dieser Aufgabe beleuchtet: Zum einen besteht die Frage, wie konkret in Teams zusammengearbeitet werden kann, sodass die Arbeit der Data Scientists auch ihren Weg in die Produktion findet. Technisch stellt sich die Frage, wie Methoden des maschinellen Lernens überhaupt technisch umgesetzt werden und wie man mit verschiedenen Anforderungen wie Automatisierung oder Echtzeitanforderungen umgehen kann. Schließlich muss eine Firma auch als Ganzes Data Science zum Teil ihrer Kultur machen, damit entsprechende Unterstützung gegeben werden kann.