In einem vorheriger Beitrag, haben wir die häufigsten Herausforderungen erörtert, mit denen Unternehmen bei der Operationalisierung von ML konfrontiert sind, und wie MLOps sie löst. In diesem Beitrag gehen wir auf die technischen Details der MLOps-Plattform von Ontinue ein, die auf der Grundlage der in unserem vorherigen Beitrag besprochenen Prinzipien entwickelt wurde. Die Ontinue MLOps-Plattform basiert auf ION IQ, der KI, die unsere ION MXDR-Dienst.
Vereinfachung der Konnektivität und Kostensenkung mit einem nativen Azure-Ansatz
Die Datenplattform von Ontinue, wie die ION-Technologieplattform selbst, wird hauptsächlich mit nativen Azure-Diensten aufgebaut. Dies vereinfacht die erforderliche Konnektivität und senkt die Kosten für den Datenzugriff.
Azure Machine Learning (Azure ML) ist die native Lösung von Azure für die Erstellung und Bereitstellung von Modellen für maschinelles Lernen. Dieser Dienst wurde kürzlich um vortrainierte Basismodelle und Tools zur Erstellung generativer KI-Lösungen erweitert. In diesem Beitrag konzentrieren wir uns ausschließlich auf das Training von Machine-Learning-Modellen.
Einfacher Zugang zu mehr Rechenleistung mit der Azure ML-Entwicklungsumgebung
Azure ML umfasst eine gehostete Entwicklungsumgebung mit einer Vielzahl von Funktionen für Datenwissenschaftler. Zu diesem Online-“Studio” gehört ein Jupyter-Notebook-Editor, mit dem unsere Datenwissenschaftler ein vertrautes Tool verwenden können, während sie ihren Code auf verwalteten Recheninstanzen ausführen, die leistungsfähiger sind als die Workstations der meisten Datenwissenschaftler. Für diejenigen, die eine integrierte Entwicklungsumgebung (IDE) bevorzugen, ist es möglich, sich über die Erweiterung ’Azure Machine Learning - Remote“ von VS Code aus mit den Compute-Instanzen zu verbinden.
Wie in unserem letzten Beitrag beschrieben, eignen sich Jupyter-Notebooks hervorragend für die erste Erkundung. Aber wenn die Menge des Codes wächst, wollen wir die Zellen in Funktionen und Module umstrukturieren, die in unserem gesamten Code wiederverwendet werden können. Eine gute Projektstruktur zu finden, kann eine Herausforderung sein. Glücklicherweise wird dies durch die Verwendung einer Cookiecutter-Vorlage erleichtert, die am besten für Ihr ML-Projekt geeignet ist.
Abstrahierung der Datenverwaltung und Konfiguration mit dem Kedro-Framework
Wir sind noch einen Schritt weiter gegangen und haben das Kedro-Framework übernommen, das nicht nur Projektvorlagen bereitstellt, sondern auch die Verwaltung von Daten und Konfiguration abstrahiert und Befehle zur Ausführung (von Teilen) unseres Codes bereitstellt. Auf diese Kedro-Funktionen kann auch von Jupyter-Notebooks aus zugegriffen werden, so dass wir unsere Exploration auf den Ergebnissen des umstrukturierten Codes aufbauen können.
Eine Kedro-Pipeline (links) und ihre Entsprechung in Azure ML (rechts)
Experimentverfolgung und Reproduzierbarkeit mit MLflow
Durch die Verwendung von Knoten und Pipelines zur Strukturierung unseres Trainingscodes kann der Code auf jedem von Kedro oder einem seiner zahlreichen Plug-ins unterstützten Rechenziel ausgeführt werden. Bei Ontinue nutzen und unterstützen wir die kedro-azureml Plugin, das Kedro-Pipelines in ihre Azure ML-Entsprechungen übersetzt und Unterstützung für die Verwendung von Azure ML Data Assets im Kedro Data Catalog bietet. Die Bedeutung dieser Funktion kann gar nicht hoch genug eingeschätzt werden: Durch einfaches Ersetzen des Befehls “kedro run” durch “kedro azureml run” wird unser Code als Azure ML Job übermittelt, ohne dass wir uns um die Boilerplate kümmern müssen, die normalerweise zur Erstellung dieser Jobs erforderlich ist. Das spart uns viel Zeit und Mühe.
Wenn es um die Verfolgung von Experimenten geht, ist MLflow kaum zu schlagen. Es bietet Funktionen zur Protokollierung von Metriken, Parametern und Artefakten für jeden Durchlauf Ihres Codes. Obwohl es lokal verwendet werden kann, nutzen wir es hauptsächlich auf Azure ML, da das gesamte Team auf die Ergebnisse zugreifen kann. Da Azure ML MLflow nativ unterstützt, ist es möglich, die Ergebnisse verschiedener Experimente im Azure ML Studio zu vergleichen, während wir gleichzeitig die Möglichkeit haben, diese Ergebnisse zu reproduzieren. Das liegt daran, dass alle Informationen über Code, Abhängigkeiten, Parameter und Eingabedaten an der gleichen Stelle gespeichert werden.
Vergleich von Metriken zwischen verschiedenen Jobs in Azure ML
Nachvollziehbarkeit und Automatisierung mit Azure ML und GitHub Actions
Dieselbe Funktionalität, die es uns ermöglicht, Experimente zu reproduzieren, ermöglicht es uns auch, genau zu wissen, wie die Modelle, die wir in der Produktion einsetzen, entstanden sind. Durch die Registrierung des Modells in der Azure ML Model Registry wird den Metadaten des Modells ein Link zu dem Job hinzugefügt, der es erzeugt hat, sodass wir genau verfolgen können, welcher Job welches Modell erstellt hat. Um Fehler zu vermeiden, die bei der manuellen Übermittlung dieser Aufträge entstehen könnten, verwenden wir einen GitHub Actions-Workflow, um den Auftrag automatisch zu erstellen, wenn der Code in unser Repository eingebunden wird. Für Modelle, die regelmäßig neu trainiert werden müssen, erstellen unsere CI/CD-Workflows einen Azure ML Schedule für den Trainingsauftrag.
Bevor neuer Code in das Repository integriert wird, ist es wichtig, ihn so gründlich wie möglich zu testen. Unser CI-System führt nicht nur Unit-Tests durch, sondern sendet auch einen Auftrag an Azure ML mit den Codeänderungen. So können die Code-Reviewer prüfen, ob sich der Code in einer realistischen Umgebung wie erwartet verhält.
Modellbereitstellung und -überwachung mit Azure ML und GitHub Actions
Unsere Modelle werden über Azure ML Managed Online Endpoints bereitgestellt, die sich nahtlos in die Model Registry integrieren lassen und die Verwaltung der Infrastruktur für die Ausführung der Modell-Endpunkte überflüssig machen. Je nach Projekt wird das neueste Modell in der Model Registry automatisch über einen GitHub Actions Cron Job bereitgestellt. Die Latenzzeit des Modells wird mit Azure Monitor überwacht. Unsere Modellvorhersagen werden auf unserer Datenplattform gespeichert, damit sie von Synapse-Pipelines analysiert und mit Power BI-Dashboards visualisiert werden können. So können Datenwissenschaftler jede Abweichung in den Vorhersagen erkennen und den Code bei Bedarf anpassen.
Entwicklung einer MLOps-Plattform für Ihr Unternehmen
Die Ontinue MLOps-Plattform ist die beste Plattform, die wir bauen konnten, da wir Azure-nativ sein, modernste Tools verwenden und innerhalb der Beschränkungen unseres Unternehmens arbeiten wollten. Die Anwendungsfälle und Einschränkungen sind jedoch in jedem Unternehmen anders und sollten bei der Entwicklung Ihrer Plattform berücksichtigt werden. Wir sind der Meinung, dass es wichtig ist, von den MLOps-Prinzipien auszugehen, was wahrscheinlich die Verwendung eines ML-Frameworks, eines Tools zur Verfolgung von Experimenten und einer Modellregistrierung bedeutet. Wenn Sie sicherstellen, dass diese Ihre ML-Anwendungsfälle unterstützen und in Ihre Datenplattform und Ihr CI/CD-Tool integriert werden können, sind die übrigen technischen Entscheidungen meist eine Frage der Präferenzen. Viel Erfolg bei der Entwicklung Ihrer MLOps-Plattform!
