Der ausführlichste Leitfaden zu MLOps: Teil 1

Hallo Hackernoon! In diesem Artikel werde ich das Konzept von MLOps im Detail besprechen. Darüber hinaus werde ich es auf drei Arten tun. Erstens theoretisch – durch das sinnvollste MLOps-Schema. Dann konzeptionell durch die Artefakte, die in den Ansatz eingebettet sind. Und schließlich durch das Verständnis von MLOps als Informationssystem.

So lass uns anfangen.

Was ist MLOps?

Diese Frage beschäftigt seit langem viele Entwicklungsteams für ML-Systeme. Unter einem solchen System verstehe ich in diesem Artikel ein Informationssystem, dessen eine oder mehrere Komponenten ein trainiertes Modell enthalten, das einen Teil der gesamten Geschäftslogik ausführt.

Wie jede andere Komponente des Systems muss auch dieser Teil der Geschäftslogik aktualisiert werden, um den sich ändernden Geschäfts- und Kundenerwartungen gerecht zu werden. Bei MLOps dreht sich alles um dieses regelmäßige Update.

MLOps-Definition und Erklärung

Es gibt noch keine einzige und vereinbarte Definition von MLOps. Viele Autoren haben versucht, es zu geben, aber es war eine Herausforderung, gleichzeitig eine klare und systematische Beschreibung zu finden.

Es gibt eine , die als solche angesehen werden könnte:

MLOps ist eine technische Disziplin, die darauf abzielt, ML-Systementwicklung (Dev) und ML-Systembereitstellung (Ops) zu vereinheitlichen, um die kontinuierliche Bereitstellung leistungsstarker Modelle in der Produktion zu standardisieren und zu optimieren.

Lassen Sie uns die kritischen Teile der MLOps-Definition hervorheben:

• Ingenieurdisziplin
• Ziel ist es, die Entwicklungs- und Bereitstellungsprozesse von ML-Systemen zu vereinheitlichen
• Standardisiert und optimiert die kontinuierliche Bereitstellung neuer Versionen
• Hochleistungsmodelle

MLOps ist also eine Art DevOps für ML-Modelle.

Geschichte der MLOps-Entstehung

Es ist leicht zu glauben, dass eine solche Ingenieursdisziplin ihren Ursprung in einem großen IT-Unternehmen hat. Wir können also der Theorie vertrauen, dass MLOps als sinnvoller Ansatz seinen Ursprung bei Google hat, wo D. Sculley versuchte, seine Nerven und Zeit von den alltäglichen Aufgaben rund um die Ausgabe von ML-Modellen in Erweiterungen zu sparen. D. Sculley ist mittlerweile weithin als „The Godfather of MLOps“ bekannt – der gleichnamige Podcast ist online leicht zu finden.

D. Sculley begann, die Arbeit mit Modellen unter dem Gesichtspunkt der technischen Schulden des Teams zu betrachten. Ja, es ist möglich, schnell neue Versionen von Modellen herauszubringen, aber die Kosten für die Unterstützung des resultierenden Systems werden erhebliche Auswirkungen auf das Budget des Unternehmens haben.

Seine Arbeit führte zu der Arbeit „Versteckte technische Schulden in maschinellen Lernsystemen " veröffentlicht im Jahr 2015 auf der NeurIPS-Konferenz. Das Datum der Veröffentlichung dieses Artikels kann als Ausgangspunkt für die Existenz von MLOps angesehen werden.

MLOps-Reifegrade: die bekanntesten Modelle

Wie die meisten IT-Prozesse haben MLOps Reifegrade. Sie helfen Unternehmen zu verstehen, wo sie sich jetzt befinden und wie sie auf die nächste Ebene gelangen können (sofern es ein solches Ziel gibt). Darüber hinaus ermöglichen Ihnen allgemein anerkannte Methoden zur Reifegradbestimmung, Ihren Platz im Wettbewerb zu bestimmen.

GigaOm MLOps-Reifegradmodell

Das am ausführlichsten beschriebene und weitgehend verständliche Modell stammt vom Analyseunternehmen GigaOm . Es kommt der Capability Maturity Model Integration (CMMI) aller Modelle am nächsten. Hierbei handelt es sich um eine Reihe von Methoden zur Verbesserung organisatorischer Prozesse, die ebenfalls aus 5 Ebenen bestehen – von 0 bis 4.

Das Modell von GigaOm unterteilt jeden Reifegrad in fünf Kategorien: Strategie, Architektur, Modellierung, Prozesse und Governance.

Wenn Sie sich in den frühen Phasen des Aufbaus eines ML-Systems an diesem Modell orientieren, können Sie über wesentliche Aspekte im Voraus nachdenken und die Wahrscheinlichkeit eines Scheiterns verringern. Der Übergang von einem Reifegrad zu einem höheren stellt das Team vor neue Herausforderungen, von denen es vorher möglicherweise nicht wusste, dass es sie gibt.

Google MLOps-Reifegradmodell

Es ist erwähnenswert, dass Google auch über sein MLOps-Reifegradmodell verfügt. Es war eines der ersten, das erschien. Es ist prägnant und besteht aus 3 Ebenen:

• Stufe 0: Manueller Prozess
• Ebene 1: ML-Pipeline-Automatisierung
• Ebene 2: CI/CD-Pipeline-Automatisierung

Man kann sich des Gedankens kaum entziehen, dass dieses Modell einer Anleitung zum Bemalen einer Eule ähnelt. Machen Sie zunächst alles von Hand, stellen Sie die ML-Pipelines zusammen und finalisieren Sie die MLOps. Trotzdem ist es gut beschrieben.

Azure MLOps-Reifegradmodell

Heutzutage haben viele große Unternehmen, die ML nutzen, ihre Reifegradmodelle zusammengestellt. Azurblau , das einen ähnlichen Ansatz zur Unterscheidung von Ebenen verwendet, ist enthalten. Allerdings gibt es davon mehr als die von Google:

• Stufe 0: Keine MLOps
• Level 1: DevOps, aber keine MLOps
• Stufe 2: Automatisiertes Training
• Stufe 3: Automatisierte Modellbereitstellung
• Stufe 4: Vollständig automatisierter MLOps-Betrieb

Alle hervorgehobenen Modelle stimmen ungefähr in einem Punkt überein. Auf der Nullebene gibt es keine ML-Praktiken. Auf der letzten Ebene verfügen sie über die Automatisierung von MLOps-Prozessen. Dazwischen gibt es immer etwas anderes, das mit der inkrementellen Prozessautomatisierung zu tun hat. Azure verfügt über diese Automatisierung des Trainingsprozesses und der anschließenden Modellbereitstellung.

MLOps-Konzeptrahmen

Wie beschreiben Sie alle Prozesse, die mit dem Konzept von MLOps verbunden sind? Überraschenderweise drei Deutsche – die Autoren des Artikels „ Machine Learning Operations (MLOps): Überblick, Definition und Architektur " - haben es sogar geschafft, sie in einem Diagramm zusammenzufassen. Sie führten eine tatsächliche Studie durch und beschrieben das Konzept von MLOps sehr detailliert.

Es kann einschüchternd sein, da viele Elemente miteinander interagieren. Allerdings finden sich darin viele Merkmale der oben genannten Reifegrade wieder. Zumindest automatisierte Pipelines, CI/CD, Überwachung, Modellregistrierung, Workflow-Orchestrierung und Bereitstellungskomponente.

Lassen Sie uns dieses Diagramm besprechen und ausführlicher auf jedes einzelne eingehen.

MLOps-Kernprozesse

Die Hauptteile des Schemas sind horizontale Blöcke, in denen die prozeduralen Aspekte von MLOps beschrieben werden (ihnen sind die Buchstaben A, B, C und D zugeordnet). Jeder von ihnen ist darauf ausgelegt, spezifische Aufgaben im Rahmen der Gewährleistung des reibungslosen Betriebs der ML-Dienste des Unternehmens zu lösen. Um das Schema leichter zu verstehen, ist es besser, in der falschen Reihenfolge zu beginnen.

Experimentieren

Wenn ein Unternehmen über ML-Dienste verfügt, arbeiten die Mitarbeiter in Jupyter. In vielen Unternehmen ist dies das Tool, in dem alle ML-Entwicklungsprozesse im Mittelpunkt stehen. Hier beginnen die meisten Aufgaben, die die Implementierung von MLOps-Praktiken erfordern.

Betrachten wir ein Beispiel. Unternehmen A muss einen Teil einiger Prozesse mithilfe von maschinellem Lernen automatisieren (gehen wir davon aus, dass es eine entsprechende Abteilung und Spezialisten gibt). Es ist unwahrscheinlich, dass der Weg zur Lösung der Aufgabe im Voraus bekannt ist. Daher müssen die Ausführenden die Problemstellung studieren und mögliche Wege zu ihrer Umsetzung testen.

Dazu schreibt ein ML-Ingenieur/ML-Entwickler Code für verschiedene Aufgabenimplementierungen und wertet die erzielten Ergebnisse anhand von Zielmetriken aus. All dies geschieht fast immer im Jupyter Lab. In einem solchen Formular ist es notwendig, viele wichtige Informationen manuell zu erfassen und dann die Implementierungen untereinander zu vergleichen.

Eine solche Aktivität nennt man Experimentieren. Es bedeutet, ein funktionierendes ML-Modell zu erhalten, das zur Lösung relevanter Probleme weiter verwendet werden kann.

Block C im Diagramm beschreibt den Prozess der Durchführung von ML-Experimenten.

Analyse der im Rahmen der Aufgabe verfügbaren Daten

Viele Entscheidungen in der ML-Entwicklung werden auf Basis der Analyse der im Unternehmen verfügbaren Daten getroffen. Es ist nicht möglich, ein Modell mit Zielqualitätsmetriken auf Daten geringer Qualität oder auf Daten zu trainieren, die nicht vorhanden sind.

Daher ist es wichtig herauszufinden, welche Daten wir erhalten haben und was wir damit machen können. Dazu können wir zum Beispiel:

• Führen Sie eine ADHoc-Studie mit Jupyter oder Superset durch
• Standard-EDA (Explorative Datenanalyse)

Ein besseres Verständnis der Daten kann nur in Verbindung mit einer semantischen und strukturellen Analyse erreicht werden.

Allerdings liegt die Datenaufbereitung nur manchmal in der Kontrolle des Projektteams. In diesem Fall sind zusätzliche Schwierigkeiten garantiert. Manchmal wird in dieser Phase klar, dass es keinen Sinn macht, das Projekt weiterzuentwickeln, weil die Daten nicht für die Arbeit geeignet sind.

Bildung eines Qualitätsdatensatzes

Wenn Vertrauen in die verfügbaren Daten besteht, ist es notwendig, über die Vorverarbeitungsregeln nachzudenken. Selbst wenn es einen großen Satz geeigneter Daten gibt, gibt es keine Garantie dafür, dass diese keine Auslassungen, verfälschten Werte usw. enthalten. Der Begriff „Eingabedatenqualität“ und die bekannte Phrase „Garbage in – Garbage out“ sollten erwähnt werden Hier.

Unabhängig davon, wie gut ein Modell verwendet wird, führt es bei Daten geringer Qualität zu schlechten Ergebnissen. In der Praxis werden viele Projektressourcen für die Erstellung eines qualitativ hochwertigen Datensatzes aufgewendet.

Training und Validierung von ML-Modellen

Nach der vorherigen Stufe ist es sinnvoll, bei der Durchführung von Experimenten die Metriken des trainierten Modells zu berücksichtigen. Im Rahmen des betrachteten Blocks besteht das Experiment darin, Training und Validierung des ML-Modells zu verknüpfen.

Das Experiment besteht aus dem klassischen Schema, die gewünschte Version des Modells mit dem ausgewählten Satz von Hyperparametern auf dem vorbereiteten Datensatz zu trainieren. Zu diesem Zweck wird der Datensatz selbst in Trainings-, Test- und Validierungsbeispiele unterteilt:

• Die ersten beiden werden verwendet, um den optimalen Satz von Hyperparametern auszuwählen
• Der dritte Schritt ist die endgültige Überprüfung und Bestätigung, dass sich das auf dem ausgewählten Satz von Hyperparametern trainierte Modell angemessen auf unbekannte Daten verhält, die nicht am Prozess der Auswahl und des Trainings der Hyperparameter beteiligt waren

Weitere Informationen zu Validierungsbeispielen finden Sie unter Dieser Artikel .

Code und Hyperparameter in einem Repository speichern

Wenn die Lernmetriken des Modells gut sind, werden der Modellcode und die ausgewählten Parameter in einem Unternehmensrepository gespeichert.

Das grundlegende Ziel des Experimentierprozesses ist die Modellentwicklung, die die Auswahl des besten Algorithmus und die Auswahl der besten Hyperparameter-Abstimmung impliziert.

Die Schwierigkeit bei der Durchführung von Experimenten besteht darin, dass der Entwickler viele Kombinationen von Betriebsparametern des ML-Modells überprüfen muss. Dabei handelt es sich nicht um verschiedene Varianten des verwendeten mathematischen Apparats.

Im Allgemeinen erfordert es Arbeit. Und was tun, wenn im Rahmen von Kombinationen von Modellparametern die gewünschten Kennzahlen nicht erreicht werden?

Feature-Engineering

Wenn die gewünschten Metriken des ML-Modellbetriebs nicht erreicht werden können, können Sie versuchen, die Funktionsbeschreibung von Datensatzobjekten um neue Funktionen zu erweitern. Dadurch wird der Kontext für das Modell erweitert und daher können sich die gewünschten Metriken verbessern.

Zu den neuen Funktionen können gehören:

• Für tabellarische Daten: beliebige Transformationen bereits vorhandener Objektattribute – z. B. X^2, SQRT(X), Log(x), X1*X2 usw.
• Basierend auf dem Themenbereich: Body-Mass-Index, Anzahl überfälliger Kreditzahlungen für ein Jahr usw.

Schauen wir uns den Teil des Diagramms an, der sich auf Feature Engineering bezieht.

Ziel von Block B1 ist es, eine Reihe von Anforderungen für die Transformation der verfügbaren Quelldaten und die Gewinnung von Merkmalen daraus zu formulieren. Die Berechnung der Komponenten selbst erfolgt aus diesen sehr vorverarbeiteten und bereinigten Daten nach den vom ML-Entwickler eingegebenen „Formeln“.

Es ist wichtig zu sagen, dass die Arbeit mit Features iterativ ist. Durch die Anwendung einer Reihe von Merkmalen kann eine neue Idee in den Sinn kommen, die in einer anderen Reihe von Merkmalen umgesetzt wird, und so weiter bis ins Unendliche. Dies wird im Diagramm explizit als Rückkopplungsschleife dargestellt.

Block B2 beschreibt den unmittelbaren Prozess des Hinzufügens neuer Funktionen zu den Daten.

Das Herstellen einer Verbindung zu und das Abrufen von Datenquellen sind technische Vorgänge, die recht kompliziert sein können. Der Einfachheit halber gehe ich davon aus, dass es mehrere Quellen gibt, auf die das Team Zugriff hat, und Tools zum Entladen von Daten aus diesen Quellen (zumindest Python-Skripte).

Datenbereinigung und -transformation. Diese Phase überschneidet sich fast mit dem ähnlichen Schritt im Experimentblock (C) – der Datenvorbereitung. Bereits zu Beginn der ersten Experimente zeichnet sich ab, welche Daten und in welchem Format für das Training von ML-Modellen benötigt werden. Es bleibt nur noch, neue Features korrekt zu generieren und zu testen, allerdings sollte der Datenaufbereitungsprozess hierfür so weit wie möglich automatisiert werden.

Berechnung neuer Features. Wie oben erwähnt, können diese Aktionen darin bestehen, einfach einige Elemente eines Datentupels zu transformieren. Eine andere Möglichkeit besteht darin, eine separate große Verarbeitungspipeline auszuführen, um ein einzelnes Feature zum gleichen Datentupel hinzuzufügen. In jedem Fall gibt es eine Reihe von Aktionen, die nacheinander ausgeführt werden.

Ergebnis hinzufügen. Das Ergebnis der vorherigen Aktionen wird dem Datensatz hinzugefügt. Am häufigsten werden Features stapelweise zum Datensatz hinzugefügt, um die Datenbanklast zu reduzieren. Aber manchmal ist es notwendig, dies im laufenden Betrieb (Streaming) zu tun, um die Ausführung von Geschäftsaufgaben zu beschleunigen.

Es ist wichtig, die erhaltenen Funktionen so effizient wie möglich zu nutzen: Speichern und Wiederverwendung in Aufgaben anderer ML-Entwickler des Unternehmens. Zu diesem Zweck verfügt das Schema über einen Feature Store. Es sollte innerhalb des Unternehmens verfügbar sein, separat verwaltet werden und alle darin enthaltenen Funktionen versioniert haben. Der Feature Store besteht aus zwei Teilen: online (für Streaming-Skripte) und offline (für Batch-Skripte).

Automatisierter ML-Workflow

Am Anfang des Artikels habe ich darauf hingewiesen, dass ich mit ML-System ein Informationssystem meine, in dem eine oder mehrere Komponenten ein trainiertes Modell enthalten, das einen Teil der gesamten Geschäftslogik ausführt. Je besser das ML-Modell aufgrund der Entwicklung ist, desto größer ist der Effekt seines Betriebs. Ein trainiertes Modell verarbeitet den eingehenden Strom von Anfragen und liefert als Antwort einige Vorhersagen, wodurch einige Teile des Analyse- oder Entscheidungsprozesses automatisiert werden.

Der Prozess der Verwendung eines Modells zum Generieren von Vorhersagen wird als Inferenz bezeichnet, und das Trainieren eines Modells wird als Training bezeichnet. Eine klare Erklärung des Unterschieds zwischen den beiden kann von Gartner ausgeliehen werden. Hier werde ich an Katzen üben.

Für den effizienten Betrieb eines Produktions-ML-Systems ist es wichtig, die Inferenzmetriken des Modells im Auge zu behalten. Sobald sie zu fallen beginnen, sollte das Modell entweder neu trainiert oder durch ein neues ersetzt werden. Am häufigsten geschieht dies aufgrund von Änderungen in den Eingabedaten (Datendrift). Es gibt beispielsweise ein Geschäftsproblem, bei dem das Modell Cupcakes auf Fotos erkennen kann und ihm diese als Eingabe übermittelt. Die Chihuahua-Hunde im Beispiel dienen dem Ausgleich:

Das Modell im Originaldatensatz weiß nichts über die Chihuahua-Hunde und hat daher falsche Vorhersagen. Daher ist es notwendig, den Datensatz zu ändern und neue Experimente durchzuführen. Das neue Modell soll so schnell wie möglich in Produktion gehen. Niemand verbietet Benutzern das Hochladen von Bildern von Chihuahua-Hunden, aber sie erhalten falsche Ergebnisse.

Nun zu weiteren Beispielen aus der Praxis. Betrachten wir die Entwicklung eines Empfehlungssystems für einen Marktplatz.

Basierend auf der Kaufhistorie des Benutzers, Käufen ähnlicher Benutzer und anderen Parametern generiert ein Modell oder Ensemble von Modellen einen Block mit Empfehlungen. Es enthält Produkte, deren Kauferlös regelmäßig gezählt und verfolgt wird.

Es passiert etwas und die Bedürfnisse der Kunden ändern sich. Folglich sind ihre Empfehlungen nicht mehr relevant. Die Nachfrage nach den empfohlenen Produkten sinkt. All dies führt zu einem Umsatzrückgang.

Die nächsten Manager schreien und verlangen, dass bis morgen alles wiederhergestellt sei, was zu nichts führt. Warum? Es liegen nicht genügend Daten über neue Kundenpräferenzen vor, sodass nicht einmal ein neues Modell hergestellt werden kann. Sie können einige grundlegende Algorithmen zur Empfehlungsgenerierung (elementbasierte kollaborative Filterung) nehmen und sie in die Produktion integrieren. Auf diese Weise funktionieren Empfehlungen irgendwie, aber das ist nur eine vorübergehende Problemumgehung.

Idealerweise sollte der Prozess so eingerichtet sein, dass der Prozess der Umschulung oder des Experimentierens mit verschiedenen Modellen auf der Grundlage von Metriken gestartet wird, ohne dass die Manager sie dazu auffordern. Und das beste würde irgendwann das aktuelle in der Produktion ersetzen. Im Diagramm ist dies die Automated ML Workflow Pipeline (Block D), die durch Trigger in einem Orchestrierungstool gestartet wird.

Dies ist der am stärksten belastete Abschnitt des Schemas. Am Betrieb von Block D sind mehrere wichtige Komponenten von Drittanbietern beteiligt:

• Die Workflow-Orchestrator-Komponente, die für den Start der Pipeline nach einem bestimmten Zeitplan oder Ereignis verantwortlich ist
• Feature Store, aus dem Daten zu notwendigen Features für das Modell entnommen werden
• Model Registry und ML-Metadatenspeicher, in dem die Modelle und ihre Metriken abgelegt werden, die nach der Arbeit der gestarteten Pipeline erhalten werden

Die Struktur des Blocks selbst kombiniert die Phasen der Experimentier- und Funktionsentwicklungsblöcke (B2). Kein Wunder, wenn man bedenkt, dass es sich hierbei um Prozesse handelt, die automatisiert werden müssen. Die Hauptunterschiede liegen in den letzten beiden Phasen:

• Modell exportieren
• Pushen Sie in die Modellregistrierung

Die übrigen Schritte sind identisch mit den oben beschriebenen.

Separat möchte ich Serviceartefakte erwähnen, die der Orchestrator benötigt, um Pipelines für die Neuschulung von Modellen auszuführen. Dies ist der Code, der im Repository gespeichert ist und auf ausgewählten Servern ausgeführt wird. Die Versionierung und Aktualisierung erfolgt nach allen Regeln der Softwareentwicklung. Dieser Code implementiert die Modell-Retraining-Pipelines und das Ergebnis hängt von seiner Richtigkeit ab.

Meistens werden im Code verschiedene ML-Tools ausgeführt, innerhalb derer die Ausführung der Schritte der Pipelines erfolgt, zum Beispiel:

• Der Airflow Orchestrator führt den Code aus, um die Phasen der Pipelines auszuführen
• Feast entlädt auf Befehl Daten zu den Features im Datensatz
• Anschließend erstellt ClearML einen neuen Datensatz und führt ein Experiment mit den erforderlichen Modellleistungsmetriken durch, die es aus seinem eigenen Repository übernimmt
• Nachdem die Untersuchung abgeschlossen ist, speichert ClearML das Modell und seine Leistungsmetriken im Speicher

Hierbei ist zu beachten, dass es grundsätzlich nicht möglich ist, Experimente zu automatisieren. Selbstverständlich ist es möglich, das AutoML-Konzept in den Prozess einzubinden. Allerdings gibt es derzeit keine anerkannte Lösung, die für jeden Versuchsgegenstand mit den gleichen Ergebnissen angewendet werden kann.

Im Allgemeinen funktioniert AutoML folgendermaßen:

1. Erzeugt irgendwie einen Satz vieler Kombinationen von Modellbetriebsparametern
2. Führt für jede resultierende Kombination ein Experiment durch. Legt Metriken für jedes Experiment fest, auf deren Grundlage das beste Modell ausgewählt wird
3. AutoML führt alle Manipulationen durch, die ein Junior/Middle Data Scientist in einem Kreis von mehr oder weniger Standardaufgaben durchführen würde

Die Automatisierung wurde ein wenig behandelt. Als nächstes müssen wir die Lieferung einer neuen Version des Modells an die Produktion organisieren.

Modelle bedienen und überwachen

Zum Generieren von Vorhersagen ist ein ML-Modell erforderlich. Aber das ML-Modell selbst ist eine Datei, die nicht so schnell generiert werden kann. Eine solche Lösung findet man oft im Internet: Ein Team nimmt FastAPI und schreibt einen Python-Wrapper um das Modell, damit man „den Prädikaten folgen“ kann.

Von dem Moment an, in dem die ML-Modelldatei empfangen wird, gibt es mehrere Möglichkeiten, wie sich die Dinge entwickeln können. Das Team kann gehen:

• Schreiben Sie den gesamten Code, um einen RESTfull-Dienst zu erstellen
• Implementieren Sie die gesamte Umhüllung
• Bauen Sie alles in ein Docker-Image ein
• Und dann werden Sie irgendwo aus diesem Bild einen Container bauen
• Skaliere es irgendwie
• Organisieren Sie die Sammlung von Metriken
• Benachrichtigungen einrichten
• Richten Sie Regeln für die Einführung neuer Versionen des Modells ein
• Viele andere Dinge

Es ist eine arbeitsintensive Aufgabe, dies für alle Modelle durchzuführen und die gesamte Codebasis in Zukunft zu pflegen. Zur Vereinfachung sind spezielle Serviertools erschienen, die drei neue Entitäten eingeführt haben:

• Inferenzinstanz/-dienst
• Inferenzserver
• Serviermotor

Eine Inferenzinstanz oder Inferenzdienst ist ein spezifisches ML-Modell, das darauf vorbereitet ist, Abfragen zu empfangen und Antwortvorhersagen zu generieren. Eine solche Entität kann einen Sub in einem Kubernetes-Cluster mit einem Container mit dem erforderlichen ML-Modell und den technischen Tools für dessen Ausführung darstellen.

Der Inferenzserver ist der Ersteller von Inferenzinstanzen/-diensten. Es gibt viele Implementierungen von Inference Server. Jeder kann mit spezifischen ML-Frameworks arbeiten und die darin trainierten Modelle in gebrauchsfertige Modelle zur Verarbeitung von Eingabeabfragen und zur Generierung von Vorhersagen umwandeln.

Die Serving Engine führt die primären Verwaltungsfunktionen aus. Es bestimmt, welcher Inferenzserver verwendet wird, wie viele Kopien der resultierenden Inferenzinstanz gestartet werden sollen und wie diese skaliert werden.

In dem betrachteten Schema gibt es keine solche Detaillierung der modellführenden Komponenten, es werden jedoch ähnliche Aspekte skizziert:

• CI/CD-Komponente, die Modelle bereitstellt, die in der Produktion ausgeführt werden können (sie kann als eine der Versionen von Serving Engine betrachtet werden)
• Model Serving organisiert innerhalb der ihm zur Verfügung stehenden Infrastruktur das Schema der Vorhersagegenerierung für ML-Modelle, sowohl für Streaming- als auch für Batch-Szenarien (es kann als eine der Versionen von Inference Server betrachtet werden).

Als Beispiel für einen kompletten Stack für Serving können wir uns auf den Stack von Seldon beziehen:

• Seldon Core ist die Serving Engine
• Seldon ML Server ist der Inferenzserver, der den Zugriff auf das Modell über REST oder gRPC vorbereitet
• Seldon MLServer Custom Runtime ist die Inferenzinstanz, eine Shell-Instanz für jedes ML-Modell, dessen Beispiel ausgeführt werden muss, um Vorhersagen zu generieren.

Es gibt sogar ein standardisiertes Protokoll zur Implementierung von Serving, dessen Unterstützung in allen derartigen Tools de facto obligatorisch ist. Es heißt V2 Inference Protocol und wurde von mehreren prominenten Marktteilnehmern entwickelt – KServe, Seldon und Nvidia Triton.

Bereitstellen vs. Bereitstellen

In verschiedenen Artikeln finden Sie möglicherweise Verweise auf die Tools zum Bereitstellen und Bereitstellen als eine Einheit. Es ist jedoch wichtig, den unterschiedlichen Zweck beider zu verstehen. Dies ist ein umstrittenes Thema, aber in diesem Artikel wird es so ausgedrückt:

• Serving – die Erstellung eines API-Modells und die Möglichkeit, daraus Vorhersagen zu erhalten. Am Ende erhalten Sie eine einzelne Dienstinstanz mit einem darin enthaltenen Modell.
• Bereitstellen – Verteilen der Dienstinstanz in der erforderlichen Menge, um eingehende Anforderungen zu verarbeiten (kann als Replikatsatz in der Kubernetes-Bereitstellung dargestellt werden).

Für die Bereitstellung von Modellen können viele Strategien verwendet werden , diese sind jedoch nicht ML-spezifisch. Übrigens unterstützt die kostenpflichtige Version von Seldon mehrere der Strategien, Sie können also einfach diesen Stack auswählen und genießen, wie alles funktioniert.

Denken Sie daran, dass Modellleistungsmetriken verfolgt werden müssen. Andernfalls können Sie Probleme nicht rechtzeitig lösen. Die große Frage ist, wie man Kennzahlen genau verfolgt. Arize AI hat darauf ein ganzes Unternehmen aufgebaut, aber niemand hat Grafana und VictoriaMetrics abgesagt.

Projektinitiierung

Wenn man alles oben Geschriebene berücksichtigt, stellt sich heraus, dass der ML-Befehl:

• Erzeugt Datensätze
• Führt dazu Experimente an ML-Modellen durch
• Entwickelt neue Funktionen zur Erweiterung von Datensätzen und zur Verbesserung der Qualität von Modellen
• Speichert die besten Modelle in der Modellregistrierung zur späteren Wiederverwendung
• Passt die Bereitstellung und Bereitstellung von Modellen an
• Passt die Überwachung von Modellen in der Produktion und die automatische Neuschulung aktueller Modelle oder die Erstellung neuer Modelle an

Es sieht kostspielig aus und ist nur manchmal gerechtfertigt. Daher gibt es im Diagramm einen separaten MLOps-Projektinitiierungsblock (A), der für die rationale Zielsetzung verantwortlich ist.

Ein Beispiel für die Argumentation des IT-Leiters kann hier die Denkweise veranschaulichen. Ein begeisterter Projektmanager kommt zu ihm und bittet um eine neue Plattforminstallation für den Aufbau eines ML-Systems. Handeln beide im besten Interesse des Unternehmens, folgen klärende Fragen des IT-Leiters:

• Welches Geschäftsproblem werden Sie mit dem neuen ML-System lösen?
• Warum haben Sie entschieden, dass das neue ML-System dieses Problem lösen sollte?
• Wäre es einfacher und kostengünstiger, Prozesse zu ändern oder mehr Leute für den technischen Support einzustellen?
• Wo können Sie eine vergleichende Analyse der ML-Systemkomponenten sehen, die die Grundlage für Ihre aktuelle Auswahl bildeten?
• Wie hilft die gewählte ML-Systemarchitektur bei der Lösung eines Geschäftsproblems?
• Sind Sie sicher, dass ML über den notwendigen mathematischen Apparat verfügt, um das identifizierte Problem zu lösen?
• Wie lautet die Problemstellung für die Lösung?
• Woher erhalten Sie die Daten zum Trainieren der Modelle? Wissen Sie, welche Daten Sie zur Erstellung der Modelle benötigen?
• Haben Sie die verfügbaren Daten bereits geprüft?
• Ist die Qualität der Daten ausreichend, um das Modell zu lösen?

Der IT-Direktor wird als Lehrer an einer Universität abgesetzt, spart aber dem Unternehmen Geld. Wenn alle Fragen beantwortet sind, besteht ein echter Bedarf für ein ML-System.

Nächste Frage: Muss ich MLOps darin ausführen?

Kommt auf das Problem an. Wenn Sie eine einmalige Lösung finden müssen, zum Beispiel PoC (Proof of Concept), benötigen Sie keine MLOps. Wenn es wichtig ist, viele eingehende Anfragen zu verarbeiten, ist MLOps erforderlich. Im Wesentlichen ähnelt der Ansatz der Optimierung eines beliebigen Unternehmensprozesses.

Um die Notwendigkeit von MLOps gegenüber dem Management zu rechtfertigen, müssen Sie Antworten auf die folgenden Fragen vorbereiten:

• Was wird besser?
• Wie viel Geld sparen wir?
• Ob wir unser Personal erweitern müssen?
• Was müssen wir kaufen?
• Wo kann man Fachwissen erwerben?

Als nächstes müssen Sie die Prüfung zum IT-Leiter wiederholen.

Die Herausforderungen bleiben bestehen, denn auch das Team muss von der Notwendigkeit überzeugt sein, seine Arbeitsprozesse und seinen Technologie-Stack zu ändern. Manchmal ist dies schwieriger, als das Management um ein Budget zu bitten.

Um das Team zu überzeugen, lohnt es sich, Antworten auf die Fragen vorzubereiten:

• Warum ist die alte Arbeitsweise nicht mehr möglich?
• Was ist der Zweck der Änderung?
• Wie wird der Technologie-Stack aussehen?
• Was und von wem lernen?
• Wie unterstützt das Unternehmen bei der Umsetzung der Änderungen?
• Wie lange dauert die Änderung?
• Was passiert mit denen, die es nicht schaffen?

Wie Sie sehen, ist dieser Prozess nicht einfach.

Kleines Fazit

Ich bin hier mit einer detaillierten Untersuchung des MLOps-Schemas fertig. Dies sind jedoch nur theoretische Aspekte. In der praktischen Umsetzung kommen immer wieder weitere Details zum Vorschein, die vieles verändern können.

Im nächsten Artikel werde ich Folgendes besprechen:

• MLOps-Artefakte
• MLOps als Informationssystem
• Open Source für MLOps: Kubeflow vs. MLflow vs. Pachyderm

Danke für Ihre Aufmerksamkeit!