Erkunden der Lösungsarchitektur

  • 4 Minuten

Überarbeiten wir jetzt die MLOps-Architektur (Machine Learning Operations), um den Zweck von dem zu verstehen, was wir erreichen möchten.

Stellen Sie sich vor, dass Sie zusammen mit dem Data Science- und dem Software-Entwicklungsteam die folgende Architektur vereinbart haben, um das Diabetesklassifizierungsmodell zu trainieren, zu testen und bereitzustellen:

Diagram of machine learning operations architecture.

Hinweis

Das Diagramm zeigt eine vereinfachte Darstellung einer MLOps-Architektur. Eine detailliertere Beschreibung der Architektur finden Sie in den Anwendungsfällen im Solution Accelerator für MLOps (v2).

Die Architektur umfasst:

  1. Setup: Erstellen aller erforderlichen Azure-Ressourcen für die Lösung.
  2. Modellentwicklung (innere Schleife): Untersuchen und Verarbeiten der Daten zum Trainieren und Auswerten des Modells.
  3. Continuous Integration: Packen und Registrieren des Modells.
  4. Modellbereitstellung (äußere Schleife): Bereitstellen des Modells.
  5. Continuous Deployment: Testen des Modells und Höherstufen in die Produktionsumgebung.
  6. Überwachung: Überwachen der Modell- und Endpunktleistung.

Das Data Science-Team ist für die Modellentwicklung verantwortlich. Das Softwareentwicklungsteam ist verantwortlich für die Integration des bereitgestellten Modells mit der Web-App, die von Ärzten verwendet wird, um zu beurteilen, ob ein Patient Diabetes hat. Sie sind dafür verantwortlich, das Modell von der Modellentwicklung in die Modellimplementierung zu überführen.

Sie erwarten, dass das Data Science-Team fortlaufend Änderungen an den Skripts vorschlägt, die zum Trainieren des Modells verwendet werden. Wenn es eine Änderung am Trainingsskript gibt, müssen Sie das Modell neu trainieren und es erneut auf dem vorhandenen Endpunkt bereitstellen.

Sie möchten es dem Data Science-Team erlauben, zu experimentieren, ohne den Code für die Produktion anzurühren. Sie möchten auch sicherstellen, dass jeder neue oder aktualisierte Code automatisch vereinbarte Qualitätsprüfungen durchläuft. Nachdem Sie den Code zum Trainieren des Modells überprüft haben, verwenden Sie das aktualisierte Trainingsskript, um ein neues Modell zu trainieren und bereitzustellen.

Zum Nachverfolgen von Änderungen und Überprüfen des Codes vor dem Aktualisieren des Produktionscodes ist es erforderlich, mit Branches zu arbeiten. Sie haben mit dem Data Science-Team vereinbart, dass es für jede von ihm gewünschte Änderung einen Featurebranch erstellt, um eine Kopie des Codes zu erstellen und die Änderungen an der Kopie vorzunehmen.

Alle Data Scientists können Featurebranches erstellen und darin arbeiten. Wenn sie den Code aktualisiert haben und möchten, dass dieser Code der neue Produktionscode sein soll, müssen sie einen Pull Request erstellen. Im Pull Request wird für andere sichtbar, was die vorgeschlagenen Änderungen sind, und sie erhalten die Möglichkeit, die Änderungen zu überprüfen und zu diskutieren.

Wenn ein Pull Request erstellt wird, möchten Sie automatisch überprüfen, ob der Code funktioniert und ob die Qualität des Codes den Standards Ihrer Organisation entspricht. Nachdem der Code die Qualitätsprüfungen bestanden hat, muss der verantwortliche Data Scientist die Änderungen überprüfen und die Aktualisierungen genehmigen, bevor der Pull Request zusammengeführt wird und der Code im Hauptbranch entsprechend aktualisiert werden kann.

Wichtig

Niemandem darf jemals gestattet werden, Änderungen in den Hauptbranch zu pushen. Zum Schutz Ihres Codes, insbesondere des Produktionscodes, sollten Sie erzwingen, dass der Hauptbranch nur über Pull Requests aktualisiert werden darf, die genehmigt werden müssen.