Was kann das neue System, wo steht es im Azure Universum und warum sollte sich das jeder Data Scientist mal ansehen? Dazu möchte ich erst einmal damit anfangen, wie derzeit noch üblicherweise mit Data Science umgegangen wird. Ich erzähle hier aus dem Nähkästchen über Erfahrungen von Freunden und es ist damit kein einzelnes Unternehmen angesprochen. Es gibt sehr wohl Unternehmen, die schon anders arbeiten, aber das ist eben - zumindest derzeit - der Median (um beim Fach zu bleiben).
Der Chef kommt mit dem Wunsch, ein bestimmtes Ereignis oder den Umsatz oder auch nur einige Zahlen vorherzusagen. Wir (die Data Scientisten) fragen dann nach Daten. Danach arbeiten wir mit dem Tool unserer Wahl (R, Python, KNIME, …) an den Modellen und der Modellwahl und nachdem wir alles zu unserer Zufriedenheit fertig gestellt haben, übergeben wir die Daten an den Chef zurück.
Diese Lösungen sind aber natürlich nicht von Dauer und auch noch nicht automatisiert. Dazu wird dann mit einem Entwickler gesprochen, der im besten Fall die Modelle direkt in den Code übernehmen kann (weil Python unterstützt wird) oder diese explizit ausprogrammiert. Ja, auch das habe ich schon bei sehr große Unternehmen gesehen, die mit Statistik ihren Unterhalt verdienen.
Was also macht Azure ML Services anders? In kurzen Worten: Es macht DevOps auf Machine Learning oder umgekehrt. Unsere Arbeit wird auf sehr überzeugend einfache Weise dokumentiert und versioniert. Diese Versionen stellen auch gleich die Basis dar, um Scoring-Modelle also Vorhersage-Maschinen zu bauen. Diese Maschinen liegen in der Verantwortung der Data Scientists und damit dort, wo sie auch hin gehört. Die Vorhersage besteht aus dem Code für die Vorhersage und einer Version eines bestimmten Modells. Dafür wird dann ein „Service“ deployed, das direkt im Code integriert werden kann (REST). Das war übrigens auch in „Azure ML Studio“ schon so. ML Services ist aber noch viel stärker, denn wir entwickeln hier Container und diese Container können überall hin deployed werden. Das bedeutet, ich kann in der ACI oder einer dezidierten VM oder aber direkt am Device (im konkreten Fall bspw. einem EDGE-Device) diesen Container verwenden. Die Versionierung liegt in der Hand des Data Scientisten und die Versionswahl in der Hand des Developers.
Das verändert die Arbeit eines Data Scientist grundlegend, wenn man es ernst nimmt. Nun bestimmt der Data Scientist, was wo läuft. Er ist es, der rasch neue Versionen der Modelle deployen kann. Die Entwickler können das mit einem kurzen Update der Container und im besten Fall ohne Änderung des Source Codes sofort umsetzen.
Auch die tägliche Arbeit, wenn mehrere Personen an verschiedenen Modellen für dieselbe Aufgabe arbeiten, wird sich verändern. Dazu eignen sich die Azure Notebooks hervorragend. Mein Beispiel im Vortrag vom SQL Saturday Vienna 2019 benutzt eben diese Notebooks und baut ein einfaches Modell.
So lautete mein Vortrag, beim heurigen SQL Saturday in Wien. Nachfolgend eine kurze Zusammenfassung meiner Session:
Ein Experiment steht für die Durchführung einer Evaluierung bzw. Berechnung („Training“) eines Modells (hier ist die statistische Methode gemeint). Dies wird bspw. in Notebooks gemacht (PyCharm, VS Code, uvm sind aber auch möglich). Diese rufen spezielle Routinen in der Azure ML SDK auf, womit die Dokumentation automatisiert wird. Die Berechnung selbst kann ebenso wie die Vorhersage später auch auf speziellen „Compute Targets“ durchgeführt werden, dies ist insbesondere bei Aufgaben mit großen Datenmengen oder komplizierten Methoden (aka Big Data oder Deep Learning) sinnvoll. Die Ergebnisse werden sinnvoll dargestellt und man kann direkt die Experimente nach Statistiken auswerten, die man selbst wählt.
Ist das Experiment erfolgreich, kann man die berechneten Ergebnisse direkt in ein Modell (hier ist der Modellbegriff der Azure ML Services gemeint) überführen und versionieren. Wird noch der Code für die Vorhersage und die notwendigen Konfigurationen über die verwendeten/notwendigen Bibliotheken für den Container zusammengeführt, kann ein Image erzeugt werden. Das Image ist nun eine Version eines verwendbaren Containers.
Dieser kann später als Service in der Cloud (also REST fähig) verwendet werden um die Vorhersagen zu machen oder aber direkt auf eine andere containerfähige Maschine (also auch auf einzelne Rechner/Server) angewendet werden. Dabei werden nicht die Daten oder die Modellerstellungsskripts (also das Data Science Know How) sondern nur noch die fertigen Modelle an diese Server geschickt.
Dieses Bild zeigt die Aufrufe der Azure ML SDK in einem beispielhaften (primitiven) Modell.
Diese Aufrufe führen – wie man in diesem Bild sehen kann – zur Dokumentation aller Experimente. Dabei sind vor allem die Aufrufe von run.log hervorzuheben, diese dokumentieren die Experimente und deren statistische Eigenschaften so, dass man die Experimente danach in der Ansicht so sortieren kann, um das „Beste“ zu finden.
Wird run.log öfter als einmal pro Experiment aufgerufen, so ergibt sich eine Zeitreihe, die wiederum direkt im Portal der Azure ML Services dargestellt werden kann. Dies ist insbesondere bei iterativen Verfahren sinnvoll, um die Verbesserung über die Zeit darzustellen und ggf. noch Verbesserungen am Algorithmus auszumachen. Diese Algorithmen sind hier nicht so gedacht, dass man mit kleinen Datenmengen auf dem lokalen Rechner arbeitet, sondern eine nicht ganz so einfache Arbeit mit hochgradig parallelisierten Methoden auf Compute Targets ausführt. Dort wird dann im Nachgang mit diesen Grafiken einfacher zu arbeiten sein.
Ich persönlich schlage folgendes zur Arbeitsweise mit diesen neuen Möglichkeiten, vor:
Mein Tipp: Einfach anfangen und sich in die neue Arbeitsweise verlieben...
