KAPITEL 8

Verbundene Muster

Wir haben uns vorgenommen, einen Katalog von Entwurfsmustern für maschinelles Lernen zu erstellen – Lösungen für wiederkehrende Probleme beim Entwurf, dem Training und beim Bereitstellen von ML-Modellen und -Pipelines. In diesem Kapitel finden Sie eine Kurzreferenz zu diesem Inventar von Mustern. Die Muster haben wir in diesem Buch danach geordnet, wo sie in einem typischen ML-Workflow verwendet werden. Somit gibt es ein Kapitel zur Eingabedarstellung und ein anderes zur Modellauswahl. Dann haben wir Muster diskutiert, die die typische Trainingsschleife modifizieren und die Inferenz belastbarer machen. Zum Schluss haben wir Muster gezeigt, die einen verantwortungsbewussten Umgang mit ML-Systemen voranbringen. Dies ist vergleichbar mit der Organisation eines Rezeptbuchs mit eigenen Abschnitten für Vorspeisen, Suppen, Hauptgerichte und Desserts. Allerdings kann eine derartige Organisation es erschweren, zu bestimmen, wann man welche Suppe wählt und welche Nachspeisen zu einem bestimmten Hauptgericht passen. Deshalb zeigen wir in diesem Kapitel auch, wie die Muster zueinander in Beziehung stehen. Und schließlich stellen wir »Speisepläne« zusammen, indem wir besprechen, wie die Muster bei gängigen Kategorien von ML-Aufgaben zusammenwirken.

Muster-Referenz

Wir haben viele verschiedene Entwurfsmuster diskutiert und wie sie verwendet werden können, um häufig wiederkehrende Herausforderungen anzugehen, die beim maschinellen Lernen auftreten. Hier eine Zusammenfassung:

image
image
image
image
image

Wechselwirkungen von Mustern

Entwurfsmuster existieren nicht isoliert. Viele von ihnen stehen entweder direkt oder indirekt in enger Beziehung zueinander und ergänzen sich oft gegenseitig. Das Interaktionsdiagramm in Abbildung 8-1 fasst die gegenseitigen Abhängigkeiten und einige Beziehungen zwischen verschiedenen Entwurfsmustern zusammen. Wenn Sie ein Muster verwenden, sollten Sie sich überlegen, wie Sie andere, verwandte Muster einbinden können.

In diesem Abschnitt zeigen wir einige Möglichkeiten auf, wie diese Muster miteinander in Beziehung stehen und wie sie zusammen eingesetzt werden können, um eine Gesamtlösung zu entwickeln. Wenn Sie mit kategorialen Features arbeiten, könnten Sie zum Beispiel das Entwurfsmuster Hashed Feature mit dem Entwurfsmuster Einbettungen kombinieren. Diese beiden Muster wirken zusammen, um Modelleingaben mit hoher Kardinalität zu verarbeiten, beispielsweise beim Arbeiten mit Text. In TensorFlow wird dies demonstriert, indem eine Feature-Spalte categorical_column_with_hash_bucket in eine Feature-Spalte embedding verpackt wird, um die dünn besetzte, kategoriale Texteingabe in eine dichte Darstellung zu konvertieren:

import tensorflow.feature_column as fc

keywords = fc.categorical_column_with_hash_bucket("keywords",

hash_bucket_size=10K)

keywords_embedded = fc.embedding_column(keywords, num_buckets=16)

Bei der Erläuterung des Entwurfsmusters Einbettungen haben wir gezeigt, dass diese Technik empfohlen wird, wenn Sie das Entwurfsmuster Feature Cross verwenden. Das Entwurfsmuster Hashed Features geht Hand in Hand mit dem Entwurfsmuster Wiederholbare Aufteilung, da der Farm-Fingerprint-Hashing-Algorithmus für die Datenaufteilung verwendet werden kann. Und bei Verwendung der Entwurfsmuster Hashed Features oder Einbettungen ist es üblich, auf Konzepte der Hyperparameter-Abstimmung zurückzugreifen, um die optimale Anzahl von Hash-Buckets oder die richtige Einbettungsdimension zu bestimmen.

image

Abbildung 8-1: Viele der in diesem Buch besprochenen Muster sind miteinander verwandt oder können zusammen verwendet werden. Diese Darstellung ist im GitHub-Repository für dieses Buch verfügbar (https://github.com/GoogleCloudPlatform/ml-design-patterns).

Tatsächlich ist das Entwurfsmuster Hyperparameter-Abstimmung ein üblicher Teil des ML-Workflows und wird oft in Verbindung mit anderen Mustern verwendet. Zum Beispiel können wir per Hyperparameter-Abstimmung die Anzahl der älteren Beispiele bestimmen, die zu verwenden sind, wenn wir das Entwurfsmuster Bridged Schema implementieren. Und wenn wir Hyperparameter-Abstimmung einsetzen, müssen wir unbedingt auch im Auge behalten, wie wir die Checkpoints des Modells mithilfe von virtuellen Epochen und verteiltem Training eingerichtet haben. Gleichzeitig ist das Entwurfsmuster Checkpoints mit Transfer Learning auf natürliche Weise verbunden, da während der Feinabstimmung oft frühere Modell-Checkpoints verwendet werden.

Einbettungen tauchen überall im maschinellen Lernen auf, sodass es viele Möglichkeiten gibt, wie das Entwurfsmuster Einbettungen mit anderen Mustern interagiert. Vielleicht am bemerkenswertesten ist Transfer Learning, da die von den Zwischenschichten eines vorab trainierten Modells generierten Ausgaben im Wesentlichen gelernte Feature-Einbettungen sind. Wir haben auch gesehen, wie das Einbinden des Entwurfsmusters Neutrale Klasse in ein Klassifizierungsmodell – entweder auf natürliche Weise oder über das Entwurfsmuster Reframing – diese gelernten Einbettungen verbessern kann. Wenn die Einbettungen im weiteren Verlauf als Features für ein Modell verwendet werden, könnte es von Vorteil sein, sie nach dem Entwurfsmuster Feature Store zu speichern, sodass sie leicht zugänglich sind und versioniert werden können. Oder die vorab trainierte Modellausgabe könnte wie im Fall von Transfer Learning als anfängliche Ausgabe eines Kaskadenmusters angesehen werden.

Sie haben auch gesehen, wie man das Entwurfsmuster Rebalancing angehen kann, indem man zwei andere Entwurfsmuster kombiniert: Reframing und Kaskade. Mit Reframing könnten wir den unausgewogenen Datensatz als Klassifizierung von entweder »normal« oder »Ausreißer« darstellen. Die Ausgabe dieses Modells würde dann an ein sekundäres Regressionsmodell übergeben werden, das für die Vorhersage auf beiden Datenverteilungen optimiert ist. Diese Muster werden wahrscheinlich auch zu dem Muster Erklärbare Vorhersagen führen, da es beim Umgang mit unausgewogenen Daten besonders wichtig ist, zu überprüfen, ob das Modell die richtigen Signale für die Vorhersage aufgreift. Tatsächlich wird empfohlen, das Muster Erklärbare Vorhersagen zu berücksichtigen, wenn eine Lösung mit einer Kaskade von mehreren Modellen aufgebaut wird, da dies die Modellerklärbarkeit einschränken kann. Dieser Kompromiss von Modellerklärbarkeit zeigt sich auch bei den Mustern Ensemble und Multimodale Eingabe, da sich diese Techniken ebenfalls nicht gut für einige Erklärbarkeitsmethoden eignen.

Das Entwurfsmuster Kaskade könnte ebenfalls hilfreich sein, wenn das Muster Bridged Schema verwendet wird, und könnte als alternatives Muster dienen, indem ein vorläufiges Modell fehlende Werte des sekundären Schemas imputiert. Diese beiden Muster ließen sich dann kombinieren, um den resultierenden Feature-Satz – wie im Muster Feature Store beschrieben – für eine spätere Verwendung zu speichern. Dies ist ein weiteres Beispiel, das die Vielseitigkeit des Musters Feature Store verdeutlicht, und zeigt, wie es oft mit anderen Entwurfsmustern kombiniert wird. So bietet ein Feature-Speicher eine bequeme Möglichkeit, Streaming-Modell-Features, die durch das Muster Windowed Inference entstehen können, zu verwalten und zu nutzen. Feature-Speicher arbeiten auch Hand in Hand mit der Verwaltung verschiedener Datensätze, die im Entwurfsmuster Reframing entstehen können, und bieten eine wiederverwendbare Version der Techniken, die bei der Verwendung des Entwurfsmusters Transformation entstehen. Die beim Entwurfsmuster Feature Store besprochene Fähigkeit zur Versionierung spielt auch eine Rolle im Entwurfsmuster Modellversionierung.

Das Entwurfsmuster Modellversionierung ist andererseits eng mit den Mustern Zustandslose Serving-Funktion und Kontinuierliche Modellbewertung verwandt. In Kontinuierliche Modellbewertung können verschiedene Modellversionen verwendet werden, um zu beurteilen, wie sich die Performance eines Modells im Laufe der Zeit verschlechtert hat. In ähnlicher Weise bieten die verschiedenen Modellsignaturen der Serving-Funktion eine einfache Möglichkeit, verschiedene Modellversionen zu erstellen. Dieser Ansatz der Modellversionierung über das Entwurfsmuster Zustandslose Serving-Funktion kann mit dem Muster Reframing verbunden werden, bei dem zwei verschiedene Modellversionen ihre eigenen REST-API-Endpunkte für die beiden verschiedenen Darstellungen der Modellausgabe bereitstellen können.

Wir haben ebenfalls diskutiert, dass es beim Muster Kontinuierliche Modellbewertung oftmals vorteilhaft ist, auch die im Muster Workflow-Pipeline präsentierten Lösungen zu untersuchen – sowohl um Trigger einzurichten, die die Retraining-Pipeline initiieren, als auch um die Nachverfolgung der Abstammung für die verschiedenen erstellten Modellversionen zu gewährleisten. Das Entwurfsmuster Kontinuierliche Modellbewertung ist eng mit dem Muster Keyed Predictions verbunden, da dieses einen Mechanismus zum einfachen Verbinden der Grundwahrheit mit den ausgegebenen Modellvorhersagen bieten kann. In der gleichen Weise ist das Muster Keyed Preditions auch mit dem Muster Batch-Serving verflochten. Aus demselben Grund wird das Muster Batch-Serving häufig in Verbindung mit dem Muster Zustandslose Serving-Funktion verwendet, um Vorhersageaufträge in großem Umfang auszuführen, die wiederum auf dem Muster Transformation basieren, um die Konsistenz zwischen Training und Serving zu gewährleisten.

Muster in ML-Projekten

ML-Systeme versetzen Teams in einer Organisation in die Lage, Lösungen für maschinelles Lernen in großem Umfang zu erstellen, bereitzustellen und zu warten. Sie bieten eine Plattform, auf der sich alle Phasen des ML-Lebenszyklus automatisieren und beschleunigen lassen, angefangen bei der Datenverwaltung über das Trainieren der Modelle, die Bewertung der Performance, die Bereitstellung von Modellen und das Serving von Vorhersagen bis zur Überwachung der Performance. Die Muster, die dieses Buch beschrieben hat, tauchen in jedem ML-Projekt auf. In diesem Abschnitt beschreiben wir die Phasen des ML-Lebenszyklus und zeigen, wo viele dieser Muster wahrscheinlich auftreten werden.

ML-Lebenszyklus

Der Aufbau einer ML-Lösung ist ein zyklischer Prozess, der mit einem klaren Verständnis der Geschäftsziele beginnt und schließlich in einem ML-Modell in der Produktion gipfelt, das diesem Ziel dient. Der in Abbildung 8-2 dargestellte Überblick über den ML-Lebenszyklus bietet eine nützliche Roadmap, die darauf ausgelegt ist, mit maschinellem Lernen einen Mehrwert für das Unternehmen zu generieren. Jede dieser Phasen ist gleich wichtig, und wenn einer dieser Schritte nicht abgeschlossen wird, steigt das Risiko, dass in späteren Phasen irreführende Erkenntnisse oder Modelle ohne Wert entstehen.

image

Abbildung 8-2: Der ML-Lebenszyklus definiert als Erstes den geschäftlichen Anwendungsfall und führt schließlich zu einem in der Produktion eingesetzten ML-Modell, das diesem Ziel dient.

Der ML-Lebenszyklus besteht aus drei Phasen, wie Abbildung 8-2 zeigt: Entdeckung, Entwicklung und Bereitstellung. Für die einzelnen Schritte jeder Phase gibt es eine kanonische Reihenfolge. Allerdings werden diese Schritte iterativ fertiggestellt, und frühere Schritte können je nach den Ergebnissen und Erkenntnissen aus späteren Phasen erneut aufgesucht werden.

Entdeckung

Maschinelles Lernen existiert als Tool, um ein Problem zu lösen. In der Entdeckungsphase eines ML-Projekts wird als Erstes der geschäftliche Anwendungsfall definiert (Schritt 1 in Abbildung 8-2). Dies ist ein entscheidender Zeitpunkt für Führungskräfte und ML-Praktiker:innen, um sich über die Besonderheiten des Problems abzustimmen und ein Verständnis dafür zu entwickeln, was maschinelles Lernen tun kann und was nicht, um dieses Ziel zu erreichen.

Es ist wichtig, den Geschäftswert in jeder Phase des Lebenszyklus im Auge zu behalten. In den verschiedenen Phasen müssen viele Entscheidungen getroffen werden, und oftmals gibt es nicht die eine »richtige« Antwort. Vielmehr ergibt sich die beste Option daraus, wie das Modell zur Unterstützung des Geschäftsziels verwendet wird. Während ein machbares Ziel für ein Forschungsprojekt darin bestehen könnte, eine um 0,1 % höhere Genauigkeit bei einem Benchmark-Datensatz herauszuholen, ist dies in der Industrie nicht akzeptabel. Bei einem Produktionsmodell, das für ein Unternehmen erstellt wird, hängt der Erfolg von Faktoren ab, die enger mit dem Unternehmen verbunden sind, beispielsweise der Verbesserung der Kundenbindung, der Optimierung von Geschäftsprozessen oder der Senkung der Churn-Raten. Entwicklungsentscheidungen können aber auch von indirekten Faktoren in Bezug auf den geschäftlichen Anwendungsfall beeinflusst werden, beispielsweise von der Geschwindigkeit der Inferenz, der Modellgröße oder der Modellinterpretierbarkeit. Jedes ML-Projekt sollte mit einem gründlichen Verständnis der Geschäftsmöglichkeit beginnen und klären, wie ein ML-Modell die aktuellen Abläufe spürbar verbessern kann.

Eine erfolgreiche Entdeckungsphase erfordert die Zusammenarbeit zwischen den Experten der Geschäftsdomäne und den ML-Experten, um die Durchführbarkeit eines ML-Ansatzes zu bewerten. Es ist entscheidend, dass jemand, der das Geschäft und die Daten versteht, mit Teams zusammenarbeitet, die die technischen Herausforderungen und den damit verbundenen Entwicklungsaufwand verstehen. Wenn die Gesamtinvestition der Entwicklungsressourcen den für das Unternehmen akzeptablen Wert übersteigt, ist es keine lohnende Lösung. Es ist möglich, dass der technische Overhead und die Kosten der Ressourcen für die Überführung in die Produktion höher sind als der Nutzen eines Modells, das die Churn-Vorhersage letztlich nur um 0,1 % verbessert. Aber vielleicht auch nicht. Wenn die Kundenbasis eines Unternehmens ein Milliarde Menschen umfasst, sind 0,1 % immer noch eine Million glücklichere Kunden.

Während der Entdeckungsphase ist es wichtig, die Geschäftsziele und den Geltungsbereich für die Aufgabe zu umreißen. Zu diesem Zeitpunkt ist auch festzulegen, mit welchen Metriken Erfolg gemessen oder definiert wird. Erfolg kann für verschiedene Organisationen oder sogar innerhalb verschiedener Gruppen derselben Organisation unterschiedlich aussehen. Ein Beispiel hierfür liefert die Diskussion zu mehreren Zielen im Abschnitt »Allgemeine Herausforderungen beim maschinellen Lernen« auf Seite 28 in Kapitel 1. Wenn man gleich zu Beginn eines ML-Projekts über gut definierte Metriken und Leistungskennzahlen (Key Performance Indicators, KPIs) verfügt, lässt sich leichter sicherstellen, dass alle Beteiligten auf das gemeinsame Ziel ausgerichtet sind. Im Idealfall gibt es bereits ein Verfahren mit einer komfortablen Baseline, gegen die zukünftige Fortschritte gemessen werden können. Dies könnte ein Modell sein, das sich bereits in der Produktion befindet, oder auch nur eine derzeit verwendete regelbasierte Heuristik. Maschinelles Lernen ist nicht die Antwort auf alle Probleme, und manchmal ist eine regelbasierte Heuristik schwer zu schlagen. Entwicklung sollte nicht um der Entwicklung willen stattfinden. Egal wie einfach ein Baseline-Modell ist, es hilft am Ende, Entwurfsentscheidungen zu treffen und zu verstehen, wie jede Entwurfsentscheidung die Nadel auf die vorgegebene Bewertungsmetrik bewegt. In Kapitel 7 haben wir die Rolle von heuristischen Benchmarks sowie andere Themen in Bezug auf verantwortungsbewusste KI diskutiert, die häufig zur Sprache kommen, wenn die Auswirkungen und der Einfluss des maschinellen Lernens mit den Stakeholdern im Unternehmen zu kommunizieren ist.

Natürlich sollten diese Konversationen auch im Kontext der Daten stattfinden. Eine tiefgehende Analyse des Unternehmens sollte Hand in Hand gehen mit einer genauen Datenerkundung (Schritt 2 in Abbildung 8-2). So vorteilhaft eine Lösung auch sein mag – wenn keine Qualitätsdaten vorhanden sind, gibt es kein Projekt. Vielleicht sind auch die Daten vorhanden, lassen sich aber aus Gründen des Datenschutzes nicht nutzen oder müssen um relevante Informationen bereinigt werden, die aber für das Modell erforderlich sind. In jedem Fall hängen die Machbarkeit eines Projekts und die Erfolgsaussichten von den Daten ab. Daher ist es wichtig, dass Datenverantwortliche innerhalb der Organisation frühzeitig in diese Gespräche einbezogen werden.

Die Daten steuern den Prozess, und es ist wichtig, die Qualität der verfügbaren Daten zu verstehen. Wie sehen die Verteilungen der Schlüsselmerkmale aus? Wie viele fehlende Werte gibt es? Wie wird mit fehlenden Werten umgegangen? Gibt es Ausreißer? Sind irgendwelche Eingabewerte stark korreliert? Welche Features existieren in den Eingabedaten, und welche Features sollten konstruiert werden? Viele ML-Modelle benötigen einen sehr umfangreichen Datensatz für das Training. Sind genügend Daten vorhanden? Wie können wir den Datensatz erweitern? Gibt es Verzerrungen im Datensatz? Dies sind wichtige Fragen, die allerdings nur an der Oberfläche kratzen. Eine mögliche Entscheidung in diesem Stadium ist, dass mehr Daten oder Daten eines bestimmten Szenarios gesammelt werden müssen, bevor man mit dem Projekt fortfahren kann.

Die Datenerkundung ist ein Schlüsselschritt bei der Beantwortung der Frage, ob Daten ausreichender Qualität vorhanden sind. Konversation allein ist selten ein Ersatz dafür, die Dinge tatsächlich anzupacken und mit den Daten zu experimentieren. Die Visualisierung spielt eine wichtige Rolle in diesem Schritt. Dichte-Diagramme und Histogramme sind hilfreich, um die Streuung der verschiedenen Eingabewerte zu verstehen. Boxplots können helfen, Ausreißer zu identifizieren. Streudiagramme sind nützlich, um bivariate Beziehungen zu entdecken und zu beschreiben. Mit Perzentilen lässt sich der Bereich für numerische Daten ermitteln. Mittelwert, Median und Standardabweichung sind Kennwerte, um eine zentrale Tendenz zu beschreiben. Diese und andere Techniken können dabei helfen, festzustellen, welche Features dem Modell wahrscheinlich nützen und welche Datentransformationen erforderlich sind, um die Daten für die Modellierung vorzubereiten.

In der Entdeckungsphase kann es hilfreich sein, mit einigen Modellierungsexperimenten zu ermitteln, ob es wirklich ein »Signal im Rauschen« gibt. An diesem Punkt könnte es von Vorteil sein, eine Machbarkeitsstudie für maschinelles Lernen durchzuführen (Schritt 3). Es klingt, als handele es sich dabei typischerweise um einen kurzen technischen Sprint, der sich nur über ein paar Wochen erstreckt und dessen Ziel es ist, die Brauchbarkeit der Daten für die Problemlösung zu bewerten. Dies bietet die Möglichkeit, Optionen für die Formulierung des ML-Problems zu untersuchen, mit der Auswahl der Algorithmen zu experimentieren und zu lernen, welche Feature-Engineering-Schritte am vorteilhaftesten wären. Der Schritt der Machbarkeitsstudie in der Entdeckungsphase ist zudem ein guter Grund dafür, einen heuristischen Benchmark zu erstellen (siehe Kapitel 7).

Entwicklung

Nachdem man sich auf die wichtigsten Bewertungsmetriken und geschäftlichen Leistungskennzahlen geeinigt hat, beginnt die Entwicklungsphase des ML-Lebenszyklus. Die Details der Entwicklung eines ML-Modells werden in der umfangreichen Literatur zum maschinellen Lernen ausführlich behandelt. Wir heben hier die wichtigsten Komponenten hervor.

In der Entwicklungsphase erstellen wir zunächst Datenpipelines und konstruieren Features (Schritt 4 in Abbildung 8-2), um die Dateneingaben zu verarbeiten, die in das Modell eingespeist werden. Die in realen Anwendungen gesammelten Daten können mit vielen Problemen behaftet sein, beispielsweise fehlenden Werten, ungültigen Beispielen oder doppelten Datenpunkten. Datenpipelines sind erforderlich, um diese Dateneingaben aufzubereiten, sodass das Modell sie verwenden kann. Beim Feature Engineering werden rohe Eingabedaten in Features umgewandelt, die enger auf das Lernziel des Modells ausgerichtet sind und in einem Format ausgedrückt werden, das für das Training des Modells geeignet ist. Zu den Feature-Engineering-Techniken gehören das Zuordnen der Eingaben in Buckets, das Konvertieren zwischen Datenformaten, Tokenisierung und Wortstammbildung von Text, das Erstellen kategorialer Features oder 1-aus-n-Codierung, Hashing von Eingaben, Erstellen von Feature Crosses und Feature-Einbettungen sowie viele weitere. Kapitel 2 dieses Buchs hat Entwurfsmuster zur Datendarstellung beschrieben und viele Datenaspekte abgedeckt, die während dieser Phase des ML-Lebenszyklus auftreten. Kapitel 5 und Kapitel 6 beschreiben Muster, die sich auf Resilienz und Reproduzierbarkeit in ML-Systemen beziehen, was beim Erstellen von Datenpipelines hilft.

In diesem Schritt können auch die Labels für das Problem konstruiert und Entwurfsentscheidungen hinsichtlich der Problemdarstellung getroffen werden. Zum Beispiel kann dies bei Zeitreihenproblemen bedeuten, Feature-Fenster einzurichten und mit Verzögerungszeiten und der Größe von Label-Intervallen zu experimentieren. Vielleicht ist es hilfreich, ein Regressionsproblem als Klassifizierung umzuformulieren und die Darstellung der Labels komplett zu ändern. Möglicherweise ist es auch notwendig, Rebalancing-Techniken zu bemühen, wenn die Verteilung der Ausgabeklassen durch eine einzige Klasse überrepräsentiert ist. Kapitel 3 dieses Buchs konzentriert sich auf die Problemdarstellung und behandelt diese und andere wichtige Entwurfsmuster, die mit dem Problem-Framing zusammenhängen.

Der nächste Schritt der Entwicklungsphase (Schritt 5 in Abbildung 8-2) ist auf das Erstellen des ML-Modells ausgerichtet. Während dieses Entwicklungsschritts ist es entscheidend, sich an die bewährten Verfahren zu halten, um ML-Workflows in einer Pipeline zu erfassen (siehe dazu »Entwurfsmuster 25: Workflow-Pipeline« auf Seite 312 in Kapitel 6). Hierzu gehört auch das Erstellen wiederholbarer Aufteilungen für Trainings-/Validierungs-/Testdatensätze, bevor mit der Modellentwicklung begonnen wird, um Datenverluste zu vermeiden. Verschiedene Modellalgorithmen oder Kombinationen von Algorithmen können trainiert werden, um ihre Performance auf dem Validierungsdatensatz zu beurteilen und die Qualität ihrer Vorhersagen zu untersuchen. Parameter und Hyperparameter werden abgestimmt, Regularisierungstechniken eingesetzt und Randfälle erkundet. Die typische Trainingsschleife eines ML-Modells wird am Anfang von Kapitel 4 detailliert beschrieben. Hier gehen wir auch auf nützliche Entwurfsmuster ein, mit denen sich die Trainingsschleife ändern lässt, um bestimmte Ziele zu erreichen.

Viele Schritte des ML-Lebenszyklus sind iterativ, und dies gilt insbesondere während der Modellentwicklung. Oftmals kann es nach einigen Experimenten notwendig sein, die Daten, die Geschäftsziele und die KPIs zu überdenken. In der Modellentwicklungsphase werden neue Datenerkenntnisse gewonnen, und diese Einblicke können ein anderes Licht darauf werfen, was möglich ist (und was nicht). Nicht selten verbringt man lange Zeit in der Modellentwicklungsphase, vor allem bei der Entwicklung eines benutzerdefinierten Modells. Kapitel 6 befasst sich mit vielen weiteren Entwurfsmustern zur Reproduzierbarkeit, die sich den Herausforderungen widmen, die während dieser iterativen Phase der Modellentwicklung auftreten.

Während der gesamten Entwicklung des Modells wird jede neue Anpassung oder jeder neue Ansatz gegen die Bewertungsmetriken gemessen, die in der Entdeckungsphase festgelegt wurden. Daher ist die erfolgreiche Ausführung der Entdeckungsphase entscheidend, und es ist notwendig, dass die in dieser Phase getroffenen Entscheidungen abgestimmt werden. Letztendlich gipfelt die Modellentwicklung in einem abschließenden Bewertungsschritt (Schritt 6 in Abbildung 8-2). An diesem Punkt hört die Modellentwicklung auf, und die Modellperformance wird gegen diese vorher festgelegten Bewertungsmetriken bewertet.

Eines der wichtigsten Resultate der Entwicklungsphase ist die Interpretation und Präsentation der Ergebnisse (Schritt 7 in Abbildung 8-2) für die Stakeholder und die regulatorischen Gruppen innerhalb des Unternehmens. Diese Bewertung auf hoher Ebene ist entscheidend und notwendig, um dem Management den Wert der Entwicklungsphase zu vermitteln. Dieser Schritt konzentriert sich darauf, die Zahlen und Grafiken für erste Berichte zu erstellen und sie den Stakeholdern innerhalb der Organisation vorzulegen. Kapitel 7 diskutiert einige gängige Entwurfsmuster, die sicherstellen, dass KI verantwortungsbewusst eingesetzt wird, und die sich im Umgang mit Stakeholdern als hilfreich erweisen. In der Regel ist dies ein wichtiger Punkt, um zu entscheiden, ob weitere Ressourcen für die letzte Phase des Lebenszyklus aufgewendet werden, die Überführung in die Produktion und die Bereitstellung von maschinellem Lernen.

Bereitstellung

Sobald die Modellentwicklung erfolgreich abgeschlossen ist und vielversprechende Ergebnisse vorliegen, geht es in der nächsten Phase um die Überführung des Modells in die Produktion, wobei der erste Schritt (Schritt 8 in Abbildung 8-2) die Planung der Bereitstellung ist.

Das Training eines ML-Modells erfordert einen beträchtlichen Arbeitsaufwand, aber um den Wert dieses Aufwands voll auszuschöpfen, muss das Modell in der Produktion laufen und die Geschäftsvorgänge unterstützen, die es entsprechend seiner Zielstellung verbessern soll. Es gibt verschiedene Ansätze, um dieses Ziel zu erreichen, und die Bereitstellung kann bei verschiedenen Organisationen je nach Anwendungsfall unterschiedlich aussehen. Zum Beispiel könnten die in die Produktion überführten ML-Assets in Form von interaktiven Dashboards, statischen Notebooks, Code in einer wiederverwendbaren Bibliothek oder Webservice-Endpunkten vorliegen.

Für die Überführung von Modellen in die Produktion sind diverse Überlegungen und Entwurfsentscheidungen anzustellen. Wie zuvor sind viele der Entscheidungen, die während der Entdeckungsphase getroffen wurden, auch für diesen Schritt maßgebend. Wie sollte das erneute Training des Modells gehandhabt werden? Müssen Eingabedaten als Stream eingespeist werden? Sollte das Training auf neuen Batches von Daten oder in Echtzeit erfolgen? Wie sieht es mit der Modellinferenz aus? Sollten wir für einmalige Batch-Inferenz-Jobs pro Woche planen, oder müssen wir Echtzeitvorhersagen unterstützen? Gibt es spezielle Durchsatz- oder Latenzprobleme zu berücksichtigen? Ist mit Spitzenbelastungszeiten zu rechnen? Steht geringe Latenz im Vordergrund? Ist die Netzwerkkonnektivität ein Problem? Die Entwurfsmuster in Kapitel 5 berühren einige der Probleme, die bei der Operationalisierung eines ML-Modells auftreten.

Dies sind wichtige Überlegungen, und diese letzte Phase stellt für viele Unternehmen tendenziell die größte Hürde dar, da sie eine starke Koordination zwischen verschiedenen Teilen der Organisation und die Integration einer Vielzahl von technischen Komponenten erfordern kann. Diese Schwierigkeit ist zum Teil auch darauf zurückzuführen, dass bei Überführung in die Produktion ein neuer Prozess in ein bestehendes System integriert werden muss, und zwar ein Prozess, der sich auf das ML-Modell stützt. Dazu kann es notwendig sein, sich mit Legacy-Systemen auseinanderzusetzen, die entwickelt worden sind, um ein einzelnes Konzept zu unterstützen, oder dass komplexe Änderungskontroll- und Produktionsprozesse innerhalb der Organisation zu befolgen sind. Außerdem verfügen bestehende Systeme oft nicht über einen Mechanismus, um Vorhersagen zu unterstützen, die von einem ML-Modell kommen, sodass neue Anwendungen und Workflows entwickelt werden müssen. Es ist wichtig, diese Herausforderungen im Vorfeld zu erkennen. Eine umfassende Lösung zu entwickeln, erfordert erhebliche Investitionen vonseiten des Geschäftsbetriebs, um den Übergang so einfach wie möglich zu gestalten und die Geschwindigkeit der Markteinführung zu erhöhen.

Der nächste Schritt der Bereitstellungsphase ist die Operationalisierung des Modells (Schritt 9 in Abbildung 8-2). Dieser Praxisbereich wird in der Regel als MLOps bezeichnet und umfasst Aspekte, die mit Automatisierung, Überwachung, Testen, Verwalten und Warten von ML-Modellen in der Produktion zusammenhängen. Es ist eine notwendige Komponente für jedes Unternehmen, das hofft, die Anzahl der durch maschinelles Lernen gesteuerten Anwendungen innerhalb seiner Organisation zu skalieren.

Zu den wichtigsten Eigenschaften von operationalisierten Modellen gehören automatisierte Workflow-Pipelines. Die Entwicklungsphase des ML-Lebenszyklus ist ein mehrstufiger Prozess. Wenn man Pipelines erstellt, die diese Schritte automatisieren, sind effizientere Workflows und wiederholbare Prozesse möglich. Dies verbessert die zukünftige Modellentwicklung und erlaubt es, auftretende Probleme agiler zu lösen. Heute bieten Open-Source-Tools wie Kubeflow (https://oreil.ly/I_cJf) diese Funktionalität, und viele große Softwarefirmen haben ihre eigenen End-to-End-ML-Plattformen entwickelt, wie Michelangelo (https://oreil.ly/se4G9) von Uber (https://oreil.ly/OznI3) oder TFX von Google, die ebenfalls Open Source sind.

Eine erfolgreiche Operationalisierung beinhaltet Komponenten der kontinuierlichen Integration und kontinuierlichen Bereitstellung (Continuous Integration und Continuous Delivery, CI/CD), die zu den bekannten Best Practices der Softwareentwicklung gehören. Diese CI/CD-Praktiken sind auf Zuverlässigkeit, Reproduzierbarkeit, Geschwindigkeit, Sicherheit und Versionskontrolle innerhalb der Codeentwicklung ausgerichtet. ML/KI-Workflows profitieren von den gleichen Überlegungen, auch wenn es einige bemerkenswerte Unterschiede gibt. So ist es beispielsweise wichtig, diese CI/CD-Prinzipien nicht nur auf den Code, der für die Entwicklung des Modells verwendet wird, sondern auch auf die Daten anzuwenden, einschließlich Datenbereinigung, Versionierung und Orchestrierung von Datenpipelines.

Im letzten Schritt der Bereitstellungsphase sind Überwachung und Wartung des Modells zu berücksichtigen. Nachdem das Modell operationalisiert ist und in der Produktion eingesetzt wird, muss man die Performance des Modells überwachen. Mit der Zeit ändern sich die Datenverteilungen, wodurch das Modell veraltet. Diese Alterung des Modells (siehe Abbildung 8-3) kann viele Ursachen haben – von Änderungen im Kundenverhalten bis hin zu Veränderungen in der Umgebung. Aus diesem Grund benötigt man Mechanismen zur effizienten Überwachung des ML-Modells und aller Komponenten, die zu seiner Performance beitragen, beginnend bei der Datenerfassung bis zur Qualität der Vorhersagen beim Serving. Die Diskussion in »Entwurfsmuster 18: Kontinuierliche Modellbewertung« auf Seite 245 in Kapitel 5 behandelt dieses häufige Problem und seine Lösung im Detail.

image

Abbildung 8-3: Modellalterung kann aus vielen Gründen auftreten. Wenn Modelle regelmäßig neu trainiert werden, kann das helfen, ihre Performance im Laufe der Zeit zu verbessern.

So ist es zum Beispiel wichtig, die Verteilung von Feature-Werten zu überwachen, um sie mit den Verteilungen zu vergleichen, die während der Entwicklungsschritte verwendet wurden. Ebenso wichtig ist es, die Verteilung der Label-Werte zu überwachen, um sicherzustellen, dass keine Datendrift zu einer Unausgewogenheit oder Verschiebung der Label-Verteilung geführt hat. Oftmals stützt sich ein ML-Modell auf Daten, die von einer externen Quelle gesammelt wurden. Vielleicht verlässt sich unser Modell auf eine Verkehrs-API eines Drittanbieters, um Wartezeiten für Autoabholungen vorherzusagen, oder verwendet Daten aus einer Wetter-API als Eingabe für ein Modell, das Flugverspätungen vorhersagt. Diese APIs werden nicht von unserem Team verwaltet. Wenn eine derartige API ausfällt oder ihr Ausgabeformat wesentlich ändert, wirkt sich das auf unser Produktionsmodell aus. In diesem Fall ist es wichtig, eine Überwachung einzurichten, um auf Änderungen in diesen vorgelagerten Datenquellen zu prüfen. Schließlich sollten Sie auch Systeme einrichten, um Vorhersageverteilungen zu überwachen und nach Möglichkeit die Qualität dieser Vorhersagen in der Produktionsumgebung zu messen.

Nach Abschluss des Überwachungsschritts kann es von Vorteil sein, den geschäftlichen Anwendungsfall zu überdenken und objektiv und genau zu bewerten, wie das ML-Modell die Geschäftsperformance beeinflusst hat. Wahrscheinlich führt dies zu neuen Erkenntnissen und dem Start neuer ML-Projekte – der Lebenszyklus beginnt von vorn.

KI-Bereitschaft

Wir stellen fest, dass sich verschiedene Organisationen, die an der Entwicklung von ML-Lösungen arbeiten, in unterschiedlichen Stadien der KI-Bereitschaft befinden. Laut einem von Google veröffentlichten Whitepaper (https://oreil.ly/5GljC) lässt sich der Reifegrad eines Unternehmens bei der Integration von KI in das Unternehmen typischerweise in drei Phasen charakterisieren: taktisch, strategisch und transformationell. Die Tools für maschinelles Lernen in diesen drei Phasen reichen von der Einbeziehung hauptsächlich manueller Entwicklung in der taktischen Phase über die Verwendung von Pipelines in der strategischen Phase bis zur vollständigen Automatisierung in der transformationellen Phase.

Taktische Phase: manuelle Entwicklung

Die taktische Phase der KI-Bereitschaft ist häufig in Unternehmen zu beobachten, die gerade erst damit beginnen, das Potenzial für KI zu erkunden, wobei der Schwerpunkt auf kurzfristigen Projekten liegt. Hier sind die KI/ML-Anwendungsfälle in der Regel enger gefasst und konzentrieren sich eher auf Proof of Concept oder Prototypen; eine direkte Verbindung zu den Geschäftszielen ist möglicherweise nicht immer klar. In dieser Phase erkennen Organisationen das Versprechen fortgeschrittener Analytik, aber die Ausführung wird hauptsächlich von einzelnen Mitarbeitern vorangetrieben oder komplett an Partner ausgelagert. Der Zugriff auf umfangreiche Qualitätsdatensätze innerhalb der Organisation kann schwierig sein.

Typischerweise gibt es in dieser Phase keinen Prozess, um Lösungen konsistent zu skalieren, und die verwendeten ML-Tools (siehe Abbildung 8-4) werden auf Ad-hoc-Basis entwickelt. Die Daten werden offline oder in isolierten Dateninseln gelagert und für die Datenexploration und -analyse manuell abgerufen. Es stehen keine Tools bereit, um die verschiedenen Phasen des ML-Entwicklungszyklus zu automatisieren, und es wird wenig Wert auf die Entwicklung wiederholbarer Prozesse des Workflows gelegt. Das macht es schwierig, Assets unter den Mitgliedern der Organisation zu teilen, und es gibt keine dedizierte Hardware für die Entwicklung.

Der Umfang von MLOps ist auf ein Repository von trainierten Modellen beschränkt, und es gibt kaum einen Unterschied zwischen Test- und Produktionsumgebungen, in denen das endgültige Modell als API-basierte Lösung bereitgestellt werden kann.

image

Abbildung 8-4: Manuelle Entwicklung von KI-Modellen; Abbildung adaptiert aus der Google-Cloud-Dokumentation (https://oreil.ly/aC1HP)

Strategische Phase: Nutzung von Pipelines

Unternehmen in der strategischen Phase haben KI-Bemühungen an den Geschäftszielen und -prioritäten ausgerichtet, und ML wird als entscheidender Beschleuniger für das Geschäft angesehen. Daher werden ML-Projekte, die von qualifizierten Teams und strategischen Partnern durchgeführt werden, oftmals von der Geschäftsleitung unterstützt und mit einem eigenen Budget ausgestattet. Eine vorhandene Infrastruktur erlaubt diesen Teams, Ressourcen gemeinsam zu nutzen und ML-Systeme zu entwickeln, die sowohl einsatzbereite als auch benutzerdefinierte Modelle verwenden. Zwischen Entwicklungs- und Produktionsumgebungen wird klar unterschieden.

In der Regel verfügen Teams bereits über Kenntnisse in der Datenaufbereitung mit Kompetenz in deskriptiver und prädiktiver Analytik. Die Daten werden in einem Data Warehouse des Unternehmens gespeichert, und es gibt ein einheitliches Modell für die zentralisierte Verwaltung von Daten und ML-Assets. Die Entwicklung von ML-Modellen erfolgt in Form eines orchestrierten Experiments. Die ML-Assets und der Quellcode für diese Pipelines werden an einem zentralen Quell-Repository gespeichert und können leicht von den Mitgliedern der Organisation gemeinsam genutzt werden.

Die Datenpipelines für die Entwicklung von ML-Modellen sind automatisiert und nutzen einen vollständig verwalteten, serverlosen Datendienst für die Datenerfassung und -verarbeitung, wobei sie entweder nach einem Zeitplan oder ereignisgesteuert arbeiten. Zusätzlich wird der ML-Workflow für Training, Bewertung und Batch-Vorhersage von einer automatisierten Pipeline verwaltet, sodass die Phasen des ML-Lebenszyklus, von der Validierung und Vorbereitung der Daten bis zum Training und der Validierung des Modells (siehe Abbildung 8-5), von einem Trigger zur Performanceüberwachung ausgeführt werden. Diese Modelle werden in einer zentralisierten Registrierung für trainierte Modelle gespeichert und können automatisch auf Basis vorgegebener Metriken zur Modellvalidierung bereitgestellt werden.

image

Abbildung 8-5: Pipeline-Phase in der KI-Entwicklung; Abbildung adaptiert aus Google-Cloud-Dokumentation (https://oreil.ly/sMNo7)

Es können mehrere ML-Systeme mit Protokollierung, Performanceüberwachung und Benachrichtigungen in der Produktion bereitgestellt und verwaltet werden. Die ML-Systeme nutzen eine Modell-API, die in der Lage ist, Datenströme in Echtzeit sowohl für die Inferenz als auch zum Sammeln von Daten zu verarbeiten. Diese Datenströme werden in die automatisierte ML-Pipeline eingespeist, um das Modell für ein späteres Training aufzufrischen.

Transformationelle Phase: vollständig automatisierte Prozesse

Unternehmen in der transformationellen Phase der KI-Bereitschaft setzen KI aktiv ein, um Innovationen zu fördern, Agilität zu unterstützen und eine Kultur zu pflegen, in der ständig experimentiert und gelernt wird. Strategische Partnerschaften werden genutzt, um Neuerungen auf den Weg zu bringen, mitzugestalten und technische Ressourcen innerhalb der Firma zu erweitern. Viele der Entwurfsmuster in den Kapiteln 5 und 6, die sich auf Reproduzierbarkeit und Resilienz beziehen, kommen in dieser Phase der KI-Bereitschaft zum Tragen.

In dieser Phase ist es üblich, dass produktspezifische KI-Teams in breiter aufgestellte Produktteams eingebettet sind und vom Advanced-Analytics-Team unterstützt werden. Auf diese Weise kann das ML-Expertenwissen in verschiedene Geschäftsbereiche innerhalb der Organisation eindringen. Die etablierten gemeinsamen Muster und Best Practices sowie Standardtools und -bibliotheken zur Beschleunigung von ML-Projekten werden von den verschiedenen Gruppen innerhalb der Organisation problemlos gemeinsam genutzt.

Datensätze werden in einer Plattform gespeichert, auf die alle Teams zugreifen können, sodass es leicht ist, Datensätze und ML-Assets zu entdecken, zu teilen und wiederzuverwenden. Es gibt standardisierte ML-Feature-Speicher, und die Zusammenarbeit in der gesamten Organisation wird gefördert. Vollständig automatisierte Organisationen betreiben eine integrierte ML-Experimentier- und Produktionsplattform, auf der Modelle erstellt und bereitgestellt werden. Jedem in der Organisation stehen die ML-Praktiken offen. Diese Plattform wird von skalierbarer und serverloser Rechentechnik für die Eingabe und die Verarbeitung der Daten als Batch und online unterstützt. Spezialisierte ML-Beschleuniger wie zum Beispiel GPUs und TPUs sind auf Abruf verfügbar, und es gibt orchestrierte Experimente für End-to-End-Daten und ML-Pipelines.

Die Entwicklungs- und Produktionsumgebungen sind denen der Pipeline-Stufe ähnlich (siehe Abbildung 8-6), haben aber auch CI/CD-Best-Practices in jede der verschiedenen Stufen ihres ML-Workflows eingebunden. Diese CI/CD-Best-Practices konzentrieren sich auf Zuverlässigkeit, Reproduzierbarkeit und Versionskontrolle für den Code, um die ML-Modelle zu produzieren, sowie auf die Datenpipelines und deren Orchestrierung. Dies ermöglicht das Erstellen, Testen und Verpacken der verschiedenen Pipeline-Komponenten. Die Modellversionierung wird durch eine ML-Modellregistrierung verwaltet, die zudem die erforderlichen ML-Metadaten und -Artefakte speichert.

image

Abbildung 8-6: Vollständig automatisierte Prozesse unterstützen die KI-Entwicklung; Abbildung adaptiert aus der Google-Cloud-Dokumentation (https://oreil.ly/VX31C).

Allgemeine Muster nach Anwendungsfall und Datentyp

Viele der in diesem Buch besprochenen Entwurfsmuster werden im gesamten Entwicklungszyklus für maschinelles Lernen genutzt und wahrscheinlich auch unabhängig vom Anwendungsfall in der Produktion verwendet – zum Beispiel Hyperparameter-Abstimmung, Heuristischer Benchmark, Wiederholbare Aufteilung, Modellversionierung, Verteiltes Training, Workflow-Pipelines oder Checkpoints. Vielleicht stellen Sie auch fest, dass andere Entwurfsmuster besonders nützlich für bestimmte Szenarios sind. An dieser Stelle gruppieren wir häufig verwendete Entwurfsmuster nach beliebten Anwendungsfällen für maschinelles Lernen.

Verstehen natürlicher Sprache

Das Verstehen natürlicher Sprache (Natural Language Understanding, NLU) ist ein Zweig der KI, der sich darauf konzentriert, eine Maschine zu trainieren, um die Bedeutung hinter Text und Sprache zu verstehen. NLU wird von Sprachagenten wie Alexa von Amazon, Siri von Apple und Assistant von Google verwendet, um Sätze wie: »Wie ist die Wettervorhersage für dieses Wochenende?« zu verstehen. Es gibt viele Anwendungsfälle, die unter den Schirm von NLU fallen. Und NLU kann auf eine Vielzahl von Prozessen angewendet werden, zum Beispiel Textklassifizierung (E-Mail-Filterung), Extrahieren von Entitäten, Beantwortung von Fragen, Spracherkennung, Textzusammenfassung und Stimmungsanalyse.

Computer Vision

Computer Vision ist der weit gefasste Oberbegriff für KI, die Maschinen darauf trainiert, visuelle Eingaben zu verstehen, zum Beispiel Bilder, Videos, Symbole und alles, was mit Pixeln zu tun haben könnte. Computer-Vision-Modelle zielen darauf ab, Aufgaben zu automatisieren, die auf menschliches Sehen angewiesen sind, von der Verwendung eines MRT zur Erkennung von Lungenkrebs bis hin zu selbstfahrenden Autos. Einige klassische Anwendungen von Computer Vision sind Bildklassifizierung, Videobewegungsanalyse, Bildsegmentierung und Entrauschen von Bildern.

Prädiktive Analytik

Prädiktive (vorhersagende) Modellierung verarbeitet vergangenheitsbezogene Daten, um Muster zu erkennen und die Wahrscheinlichkeit für ein bestimmtes Ereignis, das in der Zukunft stattfindet, zu bestimmen. Prädiktive Modelle sind in vielen verschiedenen Branchen zu finden. Zum Beispiel können Unternehmen prädiktive Modelle verwenden, um den Umsatz genauer zu prognostizieren oder die zukünftige Nachfrage nach Produkten vorherzusehen. In der Medizin verwendet man Vorhersagemodelle, um das Risiko einer chronischen Erkrankung eines Patienten abzuschätzen oder um vorherzusagen, wann ein Patient nicht zu einem geplanten Termin erscheint. Weitere Beispiele sind Energieverbrauchsprognosen, Vorhersage von Kundenabwanderungen, Finanzmodellierung, Wettervorhersage und vorausschauende Wartung.

IoT-Analytik ist ebenfalls eine breit gefasste Kategorie, die in der prädiktiven Analytik angesiedelt ist. IoT-Modelle stützen sich auf gesammelte Daten von sogenannten IoT-Geräten, d. h. von Sensoren, die mit dem Internet verbunden sind. Denken Sie an ein Verkehrsflugzeug, das mit Tausenden von Sensoren ausgestattet ist, die mehr als 2 TByte Daten pro Tag sammeln. Maschinelles Lernen von IoT-Sensorgeräten kann Vorhersagemodelle liefern, die vor Geräteausfällen warnen, bevor sie auftreten.

Empfehlungssysteme

Empfehlungssysteme gehören zu den am weitesten verbreiteten Anwendungen des maschinellen Lernens in der Wirtschaft. Man findet sie überall dort, wo Benutzer mit Artikeln interagieren. Empfehlungssysteme erfassen Merkmale früheren Verhaltens und ähnlicher Benutzer und empfehlen Artikel, die für einen bestimmen Benutzer am relevantesten sind. Denken Sie daran, wie YouTube Ihnen eine Reihe von Videos auf der Grundlage Ihres Sehverhaltens empfiehlt oder Amazon Ihnen anhand der Artikel in Ihrem Einkaufswagen weitere Käufe vorschlägt. Empfehlungssysteme sind in vielen Geschäftszweigen beliebt, insbesondere für Produktempfehlungen, beim personalisierten und dynamischen Marketing und bei Streaming-Plattformen für Musik und Videos.

Betrugs- und Anomalieerkennung

Viele Finanzinstitute nutzen maschinelles Lernen zur Betrugserkennung, um die Konten ihrer Kunden zu schützen. Diese ML-Modelle werden trainiert, um betrügerisch erscheinende Transaktionen zu markieren, und zwar basierend auf bestimmten Eigenschaften oder Mustern, die sie aus den Daten gelernt haben.

Im weiteren Sinn ist die Anomalieerkennung eine Technik, um anormales Verhalten oder Ausreißerelemente in einem Datensatz zu finden. Anomalien können sich als Spitzen oder Einbrüche zeigen, die von den normalen Mustern abweichen, oder sie können längerfristige abnormale Trends sein. Die Erkennung von Anomalien taucht in vielen verschiedenen Anwendungsfällen des maschinellen Lernens auf und kann sogar in Verbindung mit einem davon getrennten Anwendungsfall verwendet werden. Denken Sie beispielsweise an ein ML-Modell, das anomale Bahnschienen anhand von Bildern identifiziert.