In den letzten Jahren ist die KI-Branche explodiert und hat einen enormen Aufschwung erlebt. Dieses Wachstum hat zu zahlreichen neuen Projekten geführt, die darauf abzielen, die Modellentwicklung zu standardisieren. Dennoch ist die Modellentwicklung nur die Hälfte der Arbeit, und die meisten Projekte scheitern an der Umsetzung in die Produktion.
Die Bereitstellung eines Modells als funktionale Einheit eines Produkts (auch bekannt als ML-gesteuertes Produkt) ist nach wie vor eine Kunst, die von den Praktikern verlangt, dass sie alle Teile sorgfältig Stück für Stück in einer Wasserfallmethode zusammensetzen. Moderne KI-Infrastrukturen, wie sie im Folgenden beschrieben werden, haben das Potenzial, dies zu ändern.
Obwohl Scrum und agile Methoden in der Technologiebranche populär geworden sind, können diese Methoden bei der Entwicklung von ML-gesteuerten Produkten aufgrund der fragilen Abhängigkeiten zwischen den einzelnen Schritten nicht angewendet werden:
- Datenermittlung – Datenteams sammeln Informationen aus internen und externen Ressourcen.
- Datenaufbereitung – Datenteams wandeln Rohdaten um und kuratieren relevante Datenpunkte, die für das Problem relevant sind (auch „Datenmerkmale“ genannt).
- Modelltraining – Datenwissenschaftler experimentieren mit den Daten, um eine Aufgabe zu lösen.
- Modellvalidierung – Datenwissenschaftler verfolgen die Modellexperimente und finden das Modell mit der besten Leistung.
- Produktionscode – Ingenieure schreiben einen Mikrodienst, der das Modell nutzt, um Vorhersagen für die Produktion zu treffen.
- Bereitstellung und Test – Der Produktionscode sollte für die Skalierung ausgelegt sein und mithilfe des CI/CD-Systems des Unternehmens bereitgestellt und getestet werden.
- Kontinuierliche Überwachung und Lernen
Obwohl der ML-gesteuerte Produktentwicklungszyklus (auch ML-Workflow genannt) ein sehr komplexer Prozess ist, können wir ihn in drei Hauptphasen unterteilen: (1) Vorbereitung, (2) Schulung, (3) Produktisierung.
Der schwierigste Teil des ML-Lebenszyklus, der auch das größte Hindernis darstellt, ist zweifellos die Produktivitätsphase.
Die Ausstattung des Modells mit Funktionen mit Vorhersagegenauigkeit (auch bekannt als On-Demand-Funktionen) kann die genauesten und aktuellsten Vorhersagen erzeugen, was für ML-gesteuerte Produkte zwingend erforderlich ist.
Dies ist für ML-gesteuerte Produkte unabdingbar. Dennoch ist dies aufgrund der berüchtigten Reibung zwischen DS- und SW-Ingenieuren eine große Herausforderung.
SW-Ingenieure müssen eng mit den Data Scientists zusammenarbeiten, die das Modell trainiert haben, um es produktionsreif zu machen. Manchmal müssen sie sogar den Code ihrer Kollegen zurückentwickeln oder ihn ganz neu schreiben.
Um eine solche Lösung zu erstellen, ist es üblich, eine neue Microservice-Anwendung zu schreiben, die:
- Umhüllen Sie das Modell mit einem Inferencing-Code.
- Online-Transformation der Daten aus den Produktionsdatenquellen, so genau wie in unserem Vorbereitungsprozess in „On-Demand-Features“.
- Versorgung des Modells mit den On-Demand-Features.
- Bereitstellen der Vorhersage
Aktuelle Architekturen
Derzeitige Architekturen sind als monolithischer domänenspezifischer Dienst (z. B. ein „Betrugserkennungsdienst“) aufgebaut, der für die Übersetzung der domänenspezifischen Anfrage (d. h. Transaktion), die Umwandlung der Daten, die Vorhersage, die Überwachung und die Modellverwaltung zuständig ist.
Diese Art von Architekturen erfordern eine enge Zusammenarbeit von DS- und SW-Ingenieuren, um einen solchen Dienst zu entwickeln.
Aufgrund der komplexen Arbeitsabläufe bei der Bereitstellung von Modellen suchten Unternehmen nach neuen Ansätzen, um die Entwicklung und Bereitstellung von ML-gesteuerten Produkten zu standardisieren und die lange Produktionszeit des Projekts zu reduzieren.
Im Jahr 2017 veröffentlichte Uber einen Artikel über Michaellangello – Uber’s ML Platform. Der Artikel beschrieb die Initiativen, die Uber ergriffen hat, um die Entwicklung von ML-gesteuerten Produkten zu beschleunigen, sowie eine einzigartige Datenverwaltungsschicht – den „Feature Store“.
Der Feature Store ist eine einzigartige Speicherebene, die die Wiederverwendbarkeit von „Daten-Features“ ermöglicht. Er nutzt einen „kalten“ Speicher für die Bereitstellung von Features für das Training und einen „heißen“ Cache-Speicher, um sie für die Produktion zu kommunizieren.
Obwohl die Idee einer gemeinsamen Caching-Schicht kein neuer Ansatz in der SW-Entwicklung ist, war das Konzept der Trennung des Wasserfall-Workflows revolutionär. Es ermöglichte die Aufteilung des Prozesses und die getrennte Behandlung der Datenverarbeitung von der Modellentwicklung und erleichterte den Feature-Engineering-Prozess.
Das Feature-Engineering gilt als die iterativste, zeit- und ressourcenaufwändigste Phase des Workflows. In der Tat verbringen Datenteams etwa 80 % ihrer Zeit damit. Eine Vereinfachung dieser Phase scheint daher ein notwendiger Schritt in der Entwicklung der KI-Infrastruktur zu sein.
Kürzlich haben andere Unternehmen das neue Paradigma übernommen und begonnen, die ML-Betriebssysteme von ihren Feature-Betriebssystemen zu trennen und den monolithischen Prozess zu durchbrechen.
Diese neue Architektur ermöglicht es Unternehmen, Feature- und Modellbelange zu trennen, einen Vertrag zwischen dem Modell und den Daten zu standardisieren und die Reibung zwischen DS- und SW-Engineering zu verringern. Ähnlich wie bei der „Microservices“-Revolution ermöglichte uns die Standardisierung von Einheiten im Arbeitsablauf, neue Teile zu verallgemeinern und unsere Entwicklung zu beschleunigen.
Ein neuer Horizont erstrahlt.
Im Vergleich zu den derzeitigen Architekturen werden moderne KI-Infrastrukturen den operativen Aufwand der Modellbereitstellung von der Funktionsbereitstellung trennen und die Bindung zwischen DS- und SW-Ingenieuren teilweise aufheben.
Darüber hinaus übernehmen neue Architekturen rasch das Feature-Store-Konzept und die Trennung von Belangen in der ML-Industrie. Dennoch reichen Feature Stores nicht aus und lösen nur einen Teil des Problems; daher müssen moderne Infrastrukturen umfassende Lösungen bieten:
Data Science-Plattformen (auch bekannt als MLOps-Plattformen)
Data Science-Plattformen sind umfassende Lösungen, die für die Entwicklung, Verfolgung von Experimenten, Verwaltung, Bereitstellung, Überwachung und Verwaltung von Modellen zuständig sind. Sie sind für den operativen Aspekt dieses Prozesses verantwortlich und erleichtern die Komplexität des täglichen Betriebs.
Die MLOps-Plattformen stellen einen generischen Inferenzserver bereit, der eine Inferenzschicht für die Lösung bereitstellen kann, die eine Reihe von Eingabefunktionen enthält. Diese Server können auch eine „Transformationsschicht“ implementieren, die eine Verbindung zu den Feature-Plattformen ermöglicht. Einige auf dem Markt befindliche Produkte bieten bereits eine solche Schicht: KFServing, TensorFlow serving, Seldon, SageMaker, GCP, und andere.
Viele haben über die Bedeutung von MLOps-Systemen und ihre Fähigkeit, die Abhängigkeit von Ops zu verringern, geschrieben. Dennoch ist es wichtig, sie nicht mit Infrastrukturlösungen zu verwechseln, da sie eine andere Rolle spielen.
Eine hervorragende Analogie sind Kafka und Jenkins – Kafka ist ein Infrastruktursystem, während Jenkins ein DevOps-System ist.
Funktionsplattformen (Technik)
Feature-Plattformen sind eine fehlende Komponente im ML-Ökosystem. Die Feature-Plattformen sind für die Umwandlung, Bereitstellung und Überwachung der Features der Modelle verantwortlich.
Aufgrund ihrer Rolle als funktionaler Teil der Produktionssysteme müssen moderne Feature-Plattformen die Einhaltung der Produktions-SLA gewährleisten und eine stabile, skalierbare, latenzarme und ausfallsichere Lösung bieten.
Es ist wichtig zu betonen, dass Features sowohl für das Training als auch für die Inferenz benötigt werden, und Features sollten in beiden Phasen entwickelt werden. Dieses zweigleisige Verfahren führt zu einer Schieflage zwischen dem Training und der Inferenz – es liegt in der Verantwortung der Plattform, einen Mechanismus bereitzustellen, der den Abgleich zwischen beiden gewährleistet.
Im Gegensatz zu den MLOps-Plattformen sind die Feature-Plattformen nicht für das operative Ökosystem zuständig, sondern für den Zugriff auf den Produktionsdatenfluss.
Feature-Plattformen sind für die folgenden Ziele verantwortlich:
- Zugriff auf und Speicherung von Merkmalswerten und Merkmalsgruppen
- Verwaltung und Überwachung von Feature-Metadaten
- Ermöglichen und Verwalten von sugared engineering Prozessen
- Handeln als operative Funktion und Sicherstellung eines hochgradigen SLA
Moderne Feature-Plattformen stellen nicht nur Speicher zur Verfügung, sondern auch eine standardisierte Kommunikationsschicht zwischen dem technischen Aufwand für das Verschieben und Transformieren von Daten und der eigentlichen Transformationslogik (Business).
Feature-Plattformen sollten die folgenden Funktionen umfassen, um ihren Zweck zu erfüllen: Governance-Schicht, Feature-Speicher, Transformationsrahmen und eine Betriebsschicht.
Governance
Feature-Plattformen sollten eine einheitliche Governance für die Features bieten, einschließlich:
- Metadaten und Feature-Register – d.h. Feature-Name, textliche Erläuterung seiner Logik, Eigentümerschaft usw.
- Merkmalskatalog – Ermöglicht die Zusammenarbeit und Wiederverwendbarkeit von Merkmalen innerhalb des Unternehmens.
- Überwachung – Ermöglicht die Verfolgung der Feature-Leistung und die Entdeckung von Abweichungen in den Daten.
- Versionierung – Verfolgung verschiedener Implementierungen der Datentransformation.
Merkmalsspeicher (Speicherung)
Der Merkmalsspeicher ist für die Bereitstellung von Merkmalen sowohl für die Bereitstellung als auch für die Schulung zuständig. Er sollte auch als einziger Punkt der Wahrheit in Bezug auf die Schulung und Bereitstellung von Merkmalen dienen und den Abgleich zwischen Online- und Offline-Werten sicherstellen.
Diese Komponente ist auch dafür verantwortlich, eine „Zeitreise“-Funktionalität zu ermöglichen, die für die Verfolgung unterschiedlicher Werte von Zeitreihenmerkmalen und die Synchronisierung der Werte mit anderen Merkmalen im Datensatz unerlässlich ist.
Um dieses Ziel zu erreichen, können verschiedene Architekturen implementiert werden; die typische Architektur kombiniert jedoch „Online-/Offline“-Speicher (also Merkmalspeicher), die die Last durch den Filter der Latenzanforderung aufteilen.
Transformations-Framework
Das Transformations-Framework sollte Werkzeuge für die Kommunikation mit dem Merkmalsspeicher bereitstellen, um Rohdaten zu verarbeiten, anzureichern und in einen Merkmalswert zu berechnen und diesen im Merkmalsspeicher zu speichern.
Die Transformations-Frameworks sollten den Entwicklern eine vereinfachte Kommunikation ermöglichen, indem sie die Menge an technischem Code reduzieren, die für die Verarbeitung von „High-Level-Use-Cases“ erforderlich ist, z. B. Backfilling, On-Demand-Transformationen, Bulk-(Offline-)Transformationen, funktionale (z. B. Geo-Distanz, abgeleitete Merkmale) usw.
Betriebsebene
Da die Funktionsplattform ein kritischer Teil der Produktionslösung ist, muss sie die SLA des Produkts erfüllen, d. h. niedrige Latenzzeiten, Skalierbarkeit, hohe Verfügbarkeit usw. bieten.
Groß angelegte Implementierungen können auch die Herausforderung der Bereitstellung von Funktionen in verschiedenen Cloud-Umgebungen bewältigen.
Das große Bild
Die Bereitstellung eines ML-gesteuerten Produkts, das Online-Modellvorhersagen genau als funktionalen Teil des Produkts liefern kann, ist eine sehr komplexe Aufgabe, aber das sollte nicht so sein. Eine moderne KI-Infrastruktur kann Reibungsverluste effektiv reduzieren und eine friedliche Interaktion zwischen Datenwissenschaftlern und Ingenieuren schaffen.
Wie beim traditionellen Softwareprozess erwarten wir eine Unterbrechung des Arbeitsablaufs, um den betrieblichen und technischen Aufwand bei der Entwicklung und Bereitstellung neuer Dienste zu reduzieren.
Aufgrund der Komplexität der datengesteuerten Produkte wird der ML-Bereich sein monolithisches System in mehrere Systeme aufteilen müssen. Jedes ist für eine andere Aufgabe zuständig, ähnlich wie im traditionellen Softwarebereich.
Feature-Plattformen werden Rohdaten aus den Produktionsdatenquellen sammeln und umgewandelte Features kuratieren, die die Modellplattformen für Trainings- und Servicezwecke nutzen können. Im Gegensatz dazu helfen die MLOps-Plattformen Datenwissenschaftlern bei der Entwicklung und Bereitstellung von ML-Modellen.
Abschließende Überlegungen
Bei den aktuellen Lösungen auf dem Markt ist es immer noch schwierig, zwischen den verschiedenen Teilen der Architektur zu unterscheiden. Daher ist es wichtig, zwischen MLOps und KI-Infrastrukturen zu unterscheiden, da beide Systeme sehr unterschiedliche Aufgaben haben.
Obwohl einige aufstrebende Architekturen beträchtliche Fortschritte gemacht haben, konzentrieren sich aktuelle Lösungen immer noch auf den Betrieb und die Bereitstellung von Funktionen, anstatt sich auf die Herausforderung zu konzentrieren, diese zu erstellen.
Moderne Funktionsplattformen müssen sich auf die Funktionserstellung und nicht auf die Zwischenspeicherung konzentrieren und könnten der Schlüssel zur Erleichterung der Entwicklung und Bereitstellung neuer ML-gesteuerter Produkte und Dienste sein.
Quelle: medium.com
