Azure Machine Learning Services – Was nun?

Mario Schnalzenberger
Feb 12, 2019 2:15:00 PM

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.

modell_der_arbeit_eines_datascientisten

"Woodworks on Azure ML Services"

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.

aufrufe_der_azure_ml_sdk

Dieses Bild zeigt die Aufrufe der Azure ML SDK in einem beispielhaften (primitiven) Modell.

dokumentation_experimente

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.

zeitreihe

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.


MEIN FAZIT

Ich persönlich schlage folgendes zur Arbeitsweise mit diesen neuen Möglichkeiten, vor:

  • Derzeit leider nur mit Python (an R wird gerade gearbeitet)
  • Entwickeln im IDE seiner Wahl (PyCharm, VS Code, Eclipse, Jupyter, …) – meine Empfehlung ist Jupyter für größere Gruppen, ansonsten ist das vollkommen egal.
  • Valide Modelle finden und mit Hilfe der Dokumentation nichts mehr vergessen (wie war die Parametrisierung vom letzten Donnerstag noch mal, die war doch besser als jetzt?)
  • Modelle und Methoden versionieren und schon frühzeitig Kandidaten an die Applikationsentwickler geben können.
  • Auch die Services kann man versionieren und damit die Applikationsentwicklern die Möglichkeit geben, schneller besser werden zu können. In Zeiten der Multiversions in App-Stores wie Google Play oder Apple Store ist das wohl essentiell.

Mein Tipp: Einfach anfangen und sich in die neue Arbeitsweise verlieben...

You May Also Like

These Stories on Data Science

Subscribe by Email

No Comments Yet

Let us know what you think