Im vorhergehenden Blogbeitrag war das automatisierte Ausführen von Machine-Learning-Modellen als wichtiges Tool für die Antizipation von Kundenbedürfnissen vorgestellt worden. Sein Potenzial entfaltet es vor allem, wenn es nicht nur einmalig, sondern möglichst regelmässig dem Kundenberater Anstösse für eine individualisierte Kundenansprache gibt und – so die Vision – deren Verarbeitung möglichst autonom auslöst. Dafür müssen Machine-Learning-Modelle effizient bereitgestellt und automatisiert in die Produktion eingeführt sowie deren Betrieb und Qualität überwacht und ausgewertet werden. So kann ein automatisierter «Retrain»-Prozess das Machine Learning hin zu weiterer und weitestgehend eigenständiger Optimierung steuern.
Wird Machine Learning operationalisiert, kann – quasi analog zu DevOps in der Softwareentwicklung – die Einführung neuer ML-Modelle auf Basis von Modellpattern oder Frameworks beschleunigt werden. So kann ein Machine-Learning-Modell rascher eingespielt werden und «rechnet» fortan regelmässig, etwa täglich, wöchentlich oder nach Bedarf, automatisiert die vorgegebenen Algorithmen durch.

Qualitätskontrolle für das «Retraining»

Dabei wird stets auch die Qualität des Modells überprüft. Ändert sich die Datenlage, muss auch das Modell neu trainiert werden. Sobald im Monitoring eine Verschlechterung der Modellqualität festgestellt wird, steht ein Retraining an. Beispielsweise war bei der Produktivsetzung eines Modells als typischer Kunde für eine Marketingkampagne rund um Produkt A eine Persona zwischen 40 und 50 Jahre alt, urban, mit langjähriger Kundenbeziehung zum Finanzinstitut definiert worden. Inzwischen haben aber viele neue Kunden unter 30 das Produkt erworben. Die Produktkundschaft und damit auch die Zielgruppe für die nächste Kampagne haben sich verändert. Ergo muss auch das Modell neu trainiert werden, um die neuen Kunden mitzuberücksichtigen.

Retraining

Weniger manueller Aufwand, mehr Qualität

Kleinere Finanzinstitute verfügen unter Umständen über gar keine, mittlere höchstens über kleine Data-Sciences-Teams. Diese entwickeln häufig manuell auf Basis von Open Source Software einzelne Use Cases auf einem Entwicklungsserver. Dieser manuelle Aufwand kann mit Machine Learning Operations reduziert werden – von der Ausführung über den Datenimport pro Use Case oder die Bereitstellung der Resultate bis hin zur Gültigkeitsprüfung. Damit wird der Einsatz von ML DevOps insbesondere für kleine und mittlere Finanzinstitute attraktiv. Denn neben der Automatisierung der Prozesse kann die Modellentwicklung und deren Aktualisierung beschleunigt werden. Die Verwaltung der Softwarepakete wird vereinfacht und die Modelltrainingsresultate werden automatisch dokumentiert, so dass der Prozess nachvollzogen werden kann.

Nutzen von Best Practices und Tools für ML DevOps über den ganzen ML-Lifecycle hinweg

Mit den sich analog zu DevOps in der Softwareentwicklung etablierten Best Practices und Tools für ML DevOs kann somit die Einführungszeit (Time-to-Production) von ML Operations (ML OPS) verkürzt werden. Die Modellpatterns und Frameworks bestehen aus «Operations-ready Code»: einerseits Infrastruktur-Code und andererseits Business-Logik spezifischen ML Use Cases. Der Data Scientist kann diese Standards einfach auf seine eigenen Use Cases hin anwenden oder adaptieren.

Der Machine Learning Lifecycle kann in drei Phasen aufgesplittet werden: Entwicklung, Deployment und Betrieb.

  • ML OPS-Prozesse sichern in der ML-Entwicklung ab, dass die Arbeiten von Data Scientists automatisch dokumentiert werden: Jedes trainierte Modell wird einschliesslich der benutzten Features historisiert, so dass Entscheidprozesse nachvollzogen werden können.
  • Im Deployment wird das Modell abgenommen und auf Qualität bzw. Anwendbarkeit geprüft. Es wird kontrolliert, ob das Modell ethischen Richtlinien entspricht. Anschliessend wird es operationalisiert und automatisiert. Das Modell wird über eine ML-Pipeline in einer Umgebung ausgespielt, die dieselbe Spezifikation hat wie die Entwicklungsumgebung, in der aber der Betrieb automatisiert ist und die Modelle auch automatisiert gemonitort werden.
  • Im eigentlichen Betrieb werden die Modelle periodisch oder bei Bedarf via API Calls mit jeweils aktuell neu geladenen Daten ausgeführt. Die Resultate werden den Endkunden resp. Nutzer – also beispielsweise dem Bankberater oder dem Marketing – über eine Datenbank, ein Dashboard oder sonstige User Interfaces zur Verfügung gestellt.

Fazit: Durch Machine Learning Operations (ML OPS) wird der Aufwand für Infrastruktur-Code minimiert. Paketversionen, Datenbankverbindungen oder Monitoring-Alert-Konfigurationen u. ä. müssen nicht mehr bei jedem Modell neu entwickelt und auch das Scheduling kann ohne weiteres Programmieren gelöst werden. Der Data Scientist schreibt nur noch wenig Code und kann sich so mehr auf Entwicklung und Training der Modelle fokussieren. Im gesamten Lifecycle von Entwicklung über Deployment bis Betrieb wird mehr Effizienz, eine höhere Qualität und Skalierbarkeit erzielt. Wichtig ist jedoch, dass die Modelle regelmässig überprüft und ihre Genauigkeit sowie Aktualität sichergestellt werden. Das Data-Science-Team kann das Monitoring zentral ausüben und bei Bedarf zeitnah neue Modelle trainieren, die die Realität wieder korrekt abbilden.

Inventx baut in einem Pilotprojekt bereits einen ML OPS-Service für einen Kunden auf und wird perspektivisch MLOPS auf ihrer ix.OpenFinancePlattform im as-a-Service-Modell für weitere Kunden bereitstellen.