Viele von uns Entwicklern kennen das Gefühl, die Zeit, die wir mit den Benutzern verbringen, um ihre Bedürfnisse zu verstehen, mit der eigentlichen Softwareentwicklung zu vereinbaren. In der data-Wissenschaft ist dies noch offensichtlicher, denn um ein effektives System zu entwickeln, ist eine Menge Fachwissen über dieses System erforderlich. In den letzten paar Jahren habe ich als ML-Ingenieur mit verschiedenen data Wissenschaft Teams habe ich mich oft gefragt, wie ich die Verantwortung für die Optimierung der Modellgenauigkeit und die Erstellung der gesamten Software, die für die Funktion dieses Modells erforderlich ist, voneinander trennen kann. Meiner bescheidenen Meinung nach sollten data-Wissenschaftler der Genauigkeit ihrer Modelle den Vorrang geben, während ML-Ingenieure dafür sorgen sollten, dass diese Modelle vom gesamten Unternehmen genutzt werden können.

Als allgemeine Faustregel für data-Wissenschaftsprojekte gilt: Je mehr Iterationen Sie durchführen, desto besser. Schauen wir uns also an, warum die Einbeziehung eines ML-Ingenieurs vom ersten Tag an Ihnen bei der Iteration helfen wird und somit Ihre Chancen auf ein erfolgreiches System erhöht. Um alle Aspekte abzudecken, werden wir jeden Grund in drei Hauptthemen von data-Wissenschaftsprojekten aufschlüsseln: data, Modelle und Infrastruktur.

Bevor ich darauf eingehe, lassen Sie mich kurz definieren, was ich mit Iteration. In diesem Artikel beziehe ich mich auf die End-to-End-Iterationen des kompletten Produkts, die oft die folgenden Schritte umfassen: data-Ingestion, Vorverarbeitung, Modelltraining und -bewertung, Bereitstellung der Infrastruktur usw. Was ich bedeuten nicht ist eine schnelle Iteration des Modells in einem Notizbuch mit der Änderung eines Hyperparameters. Wenn Sie es gewohnt sind, in einem agilen Rahmen zu arbeiten, können Sie sich diese Iterationen auch als Projektsprints vorstellen.

Die Erstellung eines Skeletts, auf dem Sie aufbauen können, ist die erste Priorität und kann ein langwieriger Prozess sein. Bei diesem Grundgerüst handelt es sich in der Regel um ein POC, das Ihr anfängliches Basismodell und eine Demo einer Anwendung oder einer Möglichkeit zur Nutzung der Ergebnisse des Modells enthält.

Infrastruktur: Die Auswahl kompatibler cloud-Ressourcen (VMs, Verbindungen zu verschiedenen data-Quellen) und das Design der cloud-Architektur sind einige der ersten Überlegungen des ML-Ingenieurs.

Data: Beschaffung der notwendigen data, um mit dem Aufbau eines Modells zu beginnen und die Verfügbarkeit von data aus verschiedenen Quellen zu gewährleisten, mit der Option, bei Bedarf neue Ströme zu entwickeln.

Modelle: Sicherstellung, dass die getesteten Modelle tatsächlich mit der vorgeschlagenen cloud-Architektur für die Modellbereitstellung und den technischen Anforderungen (z. B. Latenz, erforderliche Rechenleistung, Anforderungen an die Produktionsumgebung) kompatibel sind.

Der ML Engineer kann in dieser Phase auch bei der Definition von Best Practices für die Softwareentwicklung mit Versionskontrolle, Linting, Code-Architektur, Tests usw. helfen.

Sobald Sie das erste Modell erstellt haben, sind die ersten paar Iterationen oft schwierig und langsam. Wenn Sie die Iterationen beschleunigen, können Sie kleinere Iterationen mit einer einzigen Funktionsänderung durchführen - eine viel effektivere Art der Entwicklung, als viele Dinge an einem Modell zu ändern, bevor Sie Feedback erhalten.

Infrastruktur: Durch die Optimierung der Speicher- und Recheninfrastruktur kann Zeit gespart werden. Während dieser Iterationen kann ein ML-Ingenieur die Infrastruktur selbst versionieren, mit Infrastructure as Code (IaC) Tools wie Terraform. Die Verwendung von IaC ermöglicht die Automatisierung der Infrastrukturbereitstellung direkt mit CI/CD-Pipelines, die Beschleunigung der Integration von Änderungen, die an der bestehenden Infrastruktur vorgenommen werden müssen, und die Erstellung verschiedener cloud-Umgebungen (Dev, Staging, Production). Auch die Verwendung spezifischer cloud-Komponenten kann Ihre Arbeitsabläufe beschleunigen, z.B. die Erstellung von Images aus der Ferne mit der GCP Wolke bauen.

Data: Preprocessing-Pipelines können von data-Wissenschaftsteams schnell aufgebaut werden, um schnell zur Modellierung zu gelangen. Ein ML-Ingenieur kann Ihnen in dieser Phase helfen, Ihre Verarbeitungsabfragen zu optimieren, sei es in Sql, Pandas, Pyspark usw. Wenn Sie dies frühzeitig tun, können Sie auf lange Sicht viel Zeit bei den Iterationen sparen, da dieser Code ausgeführt wird eine Menge.

Modelle: komplexe Modellarchitekturen können zu einem langwierigen Trainingsprozess führen. Wenn sich ein data-Wissenschaftler auf ein “Modell” bezieht, kann er in Wirklichkeit eine Gruppe von 100 Modellen meinen, die auf verschiedenen Slices des data trainiert wurden, jedes mit einem SHAP-Erklärer zur Ableitung der Merkmalsbedeutung. Ein ML-Ingenieur kann sich darauf konzentrieren, wie die Trainingspipeline parallelisiert werden kann, sei es auf einer VM mit Multiprocessing in Python oder durch die Verteilung Ihrer Arbeitslast auf mehrere Knoten auf dem cloud. Auch dies kann wiederholt werden, aber mit überraschend wenig Aufwand lassen sich hier große Fortschritte erzielen. Automatisieren Sie die Bereitstellung Ihres Modells mit einer CI/CD/CT Pipeline beschleunigt auch Ihre Iterationen und gewährleistet Wiederholbarkeit.

Ein Ingenieur, der das cloud-Budget Ihres Projekts überwacht, ist von entscheidender Bedeutung, insbesondere bei data-intensiven Anwendungen.

Infrastruktur: Die Kosten sind eine wichtige Variable in der Gleichung für die Auswahl der Infrastruktur. Sobald die Infrastruktur ausgewählt ist, können Budgetwarnungen eingerichtet werden, um sicherzustellen, dass kostspielige Komponenten genau überwacht werden.

Data: Intelligente Abfragen und die Speicherung von data können auch die Kosten jeder Iteration erheblich reduzieren. Zum Beispiel sollte die Aggregation von data während der Modelliterationen nur sparsam durchgeführt werden.

Modelle: Durch die Parallelisierung Ihrer Trainingspipeline können Sie auch die Betriebszeiten teurer Maschinen oder die Laufzeit von serverlosen Komponenten einsparen.

Schnelle Iterationen mit einer Qualitäts-Feedback-Schleife in Ihrem Projekt zu erreichen, ist großartig, aber wenn Sie nicht jedes dieser Szenarien replay können, nützt das nicht viel. Eine wiederholbare Pipeline bedeutet implizit, dass Sie eine Möglichkeit haben sollten, die Pipelineläufe zu überwachen, um Läufe auf der Grundlage bestimmter Parameter oder Leistungskennzahlen zu identifizieren, die Sie bei Bedarf wiederholen können. Wenn Sie dies während der Entwicklung robust einrichten, können data-Wissenschaftler frei experimentieren (ohne die berüchtigte Untitled12.ipynb zu benötigen) und die Pipeline für die Überwachung in der Produktion vorbereiten.

Infrastruktur: Die Verknüpfung der Trainingscodeversion mit der Infrastrukturcodeversion ist hier die “Extrameile”, aber sie ist notwendig, um vollständige Rollback-Möglichkeiten zu einem früheren Lauf zu bieten. Die Sicherstellung der Wiederholbarkeit und Überwachung auf der Basis von Pipeline-Läufen ist für mich die wesentliche erste Stufe von ML Ops, die Teams anstreben sollten. Cloud-Plattformen haben Dienste (GCP's Vertex AI zum Beispiel), die sich schnell einrichten lassen, aber Sie können auch den “Best-of-Breed”-Ansatz mit Open-Source-Tools in Betracht ziehen. Der Kompromiss besteht hier in der Abwägung zwischen der größeren Funktionalität spezifischer Open-Source-Tools und der höheren Komplexität der Gesamtinfrastruktur des Systems.

Data: Speichern aller data-Objekte in jeder Phase der Pipeline. Je nach Volumen werden vorrangig die Trainings-/Testsätze jedes Laufs gespeichert.

Modelle: wie oben, wobei Sie alle Modelle für jeden Lauf mit allen erforderlichen Parametern und Metriken speichern. Ein weiterer Tipp ist, einen Kommentar zu jedem Lauf zu protokollieren, der angibt, was für diesen spezifischen Lauf geändert wurde, um alle Experimente während der Entwicklung zu protokollieren, wie Sie es mit einem Git Commit Nachricht.

Als die data-Wissenschaft aufkam, war sie sehr explorativ und erforderte einen enormen Aufwand mit einer Gruppe von Softwareingenieuren, um jedes Modell einzusetzen, sobald es gute Leistungen auf historischen data gezeigt hatte. Diese Phase der “Industrialisierung” ist eine sehr schmerzhafte Erfahrung, da sich die Entwicklungsumgebung (flache Dateien & Python-Notebook) stark von der Produktionsumgebung (automatisierte data-Flows mit Produktions-data & Produktions-Coding-Umgebung) unterscheidet. Die erfolgreichsten Projekte, an denen ich gearbeitet habe, waren diejenigen, bei denen wir die Produktionsumgebung in der Entwicklungsphase so genau wie möglich kopieren konnten. Dies verkürzt die Zeit bis zur Produktion und ermöglicht es Ihnen, in der Entwicklungsumgebung sicher zu iterieren und die Produktionsumgebung zu nutzen, wenn Sie mit einer Iteration zufrieden sind.

Infrastruktur: Die Emulation der notwendigen Produktionsinfrastruktur in der Entwicklungsabteilung ist nicht immer einfach und kann kostspielig sein. Hier ist Infrastruktur als Code nützlich und ermöglicht es Ihnen, problemlos zwischen verschiedenen Umgebungen zu wechseln.

Data: etwas, das die data-Wissenschaftsentwicklung von der traditionellen Softwareentwicklung oder sogar data-Engineering unterscheidet, ist, dass data-Wissenschaftler Produktions-data in der Entwicklung benötigen. Sandbox data (unter Ausschluss einiger data oder einschließlich einiger synthetischer Test-data) für das reguläre data-Engineering ist eine gute Praxis während der Entwicklung, kann aber eine große Zeitverschwendung für die data-Wissenschaft sein und kann große Auswirkungen auf die gesamte data-Wissenschaftspipeline haben. Daher sollten Sie vom ersten Tag an mit Ihrem data-Team darüber verhandeln, dass Sie nur Lesezugriff auf Produktionstabellen haben.

Modelle: Von Beginn des Projekts an sollte nur ein Modell (oder Modellierungsansatz) in Ihrem Produktionscode vorhanden sein. Alle Experimente sollten in Notizbüchern oder separaten temporären Skripten in einem anderen Ordner bleiben. So vermeiden Sie, dass sich toter Code in Ihrer Produktionscodebasis ansammelt, und es ist einfacher, ihn zu pflegen oder andere Entwickler einzubinden.

Zusammenfassend lässt sich sagen, dass die Erstellung von Modellen und die Entwicklung der Software, die diese Modelle umgibt, von Beginn eines jeden Projekts an zwei Prioritäten sein sollten. Getrennte Arbeitsabläufe mit unterschiedlichen Verantwortlichkeiten können den Teams helfen, sich auf beides parallel zu konzentrieren. Die Rolle des ML-Ingenieurs entwickelt sich von Tag zu Tag weiter, und ich würde mich freuen, wenn Sie mir sagen, was ich übersehen habe!