Machine-Learning-Modelle bewerten – Quality Gates etablieren

Die Qualität bzw. Nützlichkeit von Machine-Learning-Modellen lässt sich mit Hilfe von Testdaten und Metriken bewerten. Allerdings in welchem Umfang? Manuell, automatisiert, einmalig, regelmäßig? Manuell lassen sich die ersten Modelle als Ergebnis eines Proof of Concepts sicherlich noch überschaubar bewerten und vergleichen. Steigt die Anzahl der Modelle je nach Anwendungsfall in die Dutzende oder gar Hunderte und sind diese zudem noch beständig neu zu trainieren, skaliert das manuelle Vorgehen eher nicht mehr.
Die Vorbereitung der Daten, das Training der Modelle sowie deren Bewertung lässt sich in Form von Machine-Learning-Pipelines automatisieren. Eine qualifizierte Bewertung der Daten oder eine Bewertung der Vorhersagegüte eines Modells hat aber seine Tücken – insbesondere in automatisierter Form.

Beispiel einer einfachen Machine-Learning-Pipeline

In der klassischen Softwareentwicklung haben sich zur Qualitätssicherung Unit-Test, Integration-Test, End2End-Tests etc. innerhalb von CI/CD-Pipelines etabliert. Bei der Erstellung von Machine-Learning-Modellen sind ebenso Maßnahmen nötig. Diese könne den Prozess vom Aufarbeiten der Rohdaten bis zum Ausliefern eines Modells begleiten und die Qualität eines Modells gewährleisten.

Quality Gate

Der Begriff ‚Quality Gate‘ stammt aus dem Projektmanagement und beschreibt die Einführungen von ‚Prüfpunkten‘ in den Projektablauf. Ziel ist es, die Projektlaufzeit in kürzere, überschaubare Abschnitte einzuteilen, um somit den Fortschritt nachhalten zu können. Dabei sind vorab pro Gate prüfbare Erfolgskriterien festzulegen.
Ein Gate beinhaltet beispielsweise eine Liste von Zielen oder Qualitätsansprüchen an die resultierenden Artefakte am Ende einer Projektphase. Diese müssen erfüllt sein, bevor der nächste Abschnitt im Prozessablauf gestartet wird. Gegebenenfalls kann es beim Prüfen des Status allerdings auch zum Abbruch des Projekts kommen. Denn es wird transparent, dass wesentliche Eigenschaften nicht erreicht wurden oder sehr wahrscheinlich auch gar nicht mehr erreicht werden. Durch einen frühzeitigen Stopp eines Projekts lassen sich somit unter Umständen auch Zeit, Ressourcen und Geld sparen.

Quality-Gates im Projektablauf

Im Machine-Learning-Kontext können Quality Gates als dezidierte Checks zwischen den einzelnen Schritten einer automatisierten Pipeline integriert werden und somit die Qualität der Artefakte im Prozess nachhalten und monitoren. Typische Artefakte sind hier die Roh- und aufbereiteten Daten sowie die trainierten Modelle.

Daten

Die Qualität der Daten ist die Grundlage, um überhaupt erfolgreich Machine-Learning-Modelle trainieren zu können. Die ersten Quality Gates widmen sich daher den Daten und stellen sicher, dass das Training der Modelle auf einer sinnvollen Datenbasis geschieht. Zunächst lassen sich die Rohdaten prüfen. Sie müssen den bisherigen Annahmen/Statistiken und Ausprägungen entsprechen, da sonst gegebenenfalls Korrekturen im Setup des Modells und Trainings nötig werden können.
In der Regel ist die Aufbereitung der Rohdaten höchst individuell und unter Umständen aufwendig. Das heisst, es sind gegebenenfalls weitere Prüfpunkte zwischen den Aufbereitungsschritten, hier nicht dargestellt, einzusetzen.
Darüberhinaus kann beispielsweise die Verteilung der Daten in den resultierenden Datensets getestet werden. Eine faire und repräsentative Verteilung der Daten sowie eine ausreichende Menge an Datensätzen in den Sets sollte gewährleistet sein. Ansonsten ist die Auswertungen auf möglichen Validierungs- und Testsets nur bedingt aussagekräftig [1] .
Eine unzureichende Datenbasis führt eher nicht zu den erhofften qualitativ möglichst guten Modellen. Falls diese Gates nicht passiert werden, kann ein frühzeitiger Abbruch schon zu Beginn der Pipeline Zeit, Ressourcen und Geld sparen. Insbesondere, wenn diese Gates mit überschaubarem Aufwand eingeführt werden können.

Bespiele für Daten-Quality-Gates

Metriken

Um die Qualität der Vorhersagen eines Modells in einer Pipeline bewerten zu können, ist ein Set an automatisch auswertebaren Kriterien obligatorisch. Idealerweise kommen dazu numerische Metriken zum Einsatz. Diese können auf Vorhersagen des Modells auf dem zurückgelegten Testset ausgewertet werden.
Dabei hängen die möglichen Metriken sowie Grenzwerte natürlich vom jeweiligen Anwendungsfall ab. Beispielsweise gilt es bei einer Klassifikation einen guten Tradeoff zwischen Abdeckung und Präzision zu finden und zu definieren, ab welcher Vorhersagesicherheit eine Klasse als erkannt gilt [2] . Sind adequate Metriken aber erstmal ausgewählt und die zu erreichende Resultate bzw. Grenzwerte definiert, können die Kriterien in einem ersten Quality Gate für das Modell automatisiert geprüft werden.
Allerdings stellt sich natürlich die Frage: Lohnt der ganze Aufwand überhaupt, komplizierte Machine-Learning-Modelle einzuführen? Oder gibt es nicht auch einfacherer Alternativen, um die Anforderungen zu erfüllen?

Baselines

Eher rudimentäre Lösungen lassen sich mit Hilfe von einfacheren Modellen meist günstig und schnell realisieren. Diese Modelle können durch Heuristiken, einfachen Statistiken oder gar einer schlichten Generierung von Zufallswerten erstellt werden und sind in einem Test zu schlagen. Durch den Vergleich mit Baseline-Modellen bekommt man eine Idee davon, welche Leistung einfach zu erreichen ist. Dazu können Prognosen der Baseline und einem Modellkandidaten auf demselben Testset erstellt und mit den ausgewählten Metriken verglichen werden. Wie groß der Unterschied zu einer einfacheren Lösung ist, lässt sich somit verdeutlichen.
Es sollte schon einen gewissen, letztendlich vorab zu definierenden Unterschied in der Leistungsfähigkeit zu Gunsten des komplexeren Modells geben, um den Einsatz zu rechtfertigen. Besteht Klarheit darüber, ab welchem Unterschied ein echter Mehrwert des ML-Ansatzes vorliegt, lässt sich dies als Kriterium nutzen und damit ein weiteres Gate in den Prozess integrieren. Wird die Baseline nicht geschlagen, sind weitere Optimierungen an den Daten oder dem Training nötig oder gar der gewählte Ansatz zu überdenken.

Beispiele für Model Quality Gates

A/B-Tests

Die eigentliche Performance des Models wird sich aber wohl erst in einer realen Situation, beispielsweise mit Hilfe von A/B-Tests, zeigen. „Der A/B-Test (auch split test) ist eine Testmethode zur Bewertung zweier Varianten eines Systems, bei der die Originalversion gegen eine leicht veränderte Version getestet wird.“ [3] . Wenn die Infrastruktur es zulässt, können A/B-Tests ausgeführt werden und hilfreiche Einblicke liefern.
Beispielsweise sind Korrelationen zwischen den zuvor geprüften Offline-Metriken und den Ergebnissen der Online-Metriken der A/B-Tests möglich. Es lässt sich damit einschätzen, inwiefern die Offline-Metriken die Performance der Modelle überhaupt vorhersagen können, bzw. welche am ehesten in Betracht gezogen werden sollten.
Was unter Umständen vorab schon mal manuell ausgeführt und begutachtet werden kann ist ein A/B-Test zwischen einem ersten trainierten Modell und der Baseline.
Darüber hinaus kann, wenn weitere Modell-Ansätze zu testen sind, natürlich auch das jeweils letzt beste Modell mit einem neuen potentiell besseren Modell verglichen werden. Der A/B-Test lässt sich damit auch als Quality Gate vor dem Deployment am Ende der Pipeline integrieren. Wobei A/B-Tests gegebenenfalls zeitaufwändig und somit automatisiert nicht immer praktikabel sind.

Produktion

Ein Unterschied zum Projektmanagement-Ansatz ist allerdings, dass der typische ML-Prozess in Zyklen verläuft. Letztendlich ist das Messen der Qualität eines Modells in den verschiedenen Gates innerhalb einer Machine-Learning-Pipeline nur eine Wette auf die Zukunft.
Ist das Modell erst einmal in Produktion, unterliegt es einer gewissen Degeneration, welche je nach Domäne verschieden ausgeprägt und unterschiedlich schnell eintreten kann. Das heisst, Modelle veralten mit der Zeit und müssen gegebenenfalls an neue Gegebenheiten respektive Daten quasi angepasst werden. Dies kann beispielsweise durch erneutes oder weiteres Trainieren der Modelle erreicht werden, womit der Prozess von vorne beginnt.
Quality Gates sind daher auch während des Betriebs der Modelle einzusetzen um festzustellen, ob das Modell in einer sich beständig ändernden Umgebung adequate Ergebnisse liefert bzw. weiterhin liefern kann.
So können sich im Falle eines ‚Data Drift‘ zum einen die Daten ändern, beispielsweise die Verteilung oder Wertebereich der Daten bzw. Features. Oder die Muster, die das Modell gelernt hat, sind nicht mehr gültig und unterliegen einem Concept Drift [4] . Zum Beispiel können saisonale Effekte oder wie gerade geschehen in Zeiten einer Pandemie unerwartete Effekte die Vorhersagequalität von Modellen beeinflussen [5] .
Auch im Betrieb des Modells kann daher ein weiteres Gate regelmäßig neue Daten prüfen und verifizieren, dass sie den Annahmen noch entsprechen.

Machine Learning Quality-Gates-Kette inklusive Monitoring der aktuellen Modellqualität

Wie oft ein Modell neu trainiert werden muss und welche Änderungen vorzunehmen sind, hängt vom Anwendungsfall und der Ausprägung der neuen Gegebenheiten ab. Ob es sich ferner überhaupt lohnt ist ebenso abzuschätzen, da gegebenenfalls die Kosten um neue Modelle zu trainieren nicht unerheblich sein können.
Dieser Trade-Off zwischen Kosten und Nutzen oder sogar Kritikalität des Modells stellt ebenso ein Gate dar. Das Gate wird aber kurioserweise nur zum nächsten Schritt, des erneuten Trainings, geöffnet, wenn das Modell ’schlecht‘ genug ist.

Fazit

Wie hier beispielhaft dargestellt lassen sich Quality Gates an verschiedenen Stellen in einer Pipeline integrieren, um die Qualität der jeweiligen Artefakte eines Teilprozesses sicher zu stellen. Dazu müssen Erfolgskriterien, die zum Passieren eines Gates zu erfüllen sind, vorab definieret werden und automatisiert prüfbar sein.
Ein frühzeitiger Stopp einer Machine-Learning-Pipeline kann Zeit, Ressourcen und Geld sparen. Denn durch das Fehlschlagen eines Gates ist absehbar, dass am Ende eine ausreichende Vorhersagegüte des Modells nicht mehr gewährleistet werden kann.
Letztendlich sind Modelle auch in der Produktion zu überwachen, um eine mögliche Modell-Degeneration frühzeitig zu erkennen und entsprechend darauf reagieren zu können.
Darüber hinaus können eine Reihe weitere Gates und Tests in Betracht gezogen werden, um zu gewährleisten, dass das Ökosystem rund um den Machine-Learning-Ansatz in der Praxis besteht. Dies geht allerdings über den Rahmen dieses Artikels hinaus, soll hier aber nicht unerwähnt bleiben [6] .

Referenzen

[1] codecentric Blog – Machine-Learning-Modelle bewerten: die Crux mit den Testdaten

[2] codecentric Blog – Machine-Learning-Modelle bewerten – die Crux mit der Metrik

[3] wikipedia – AB-Test

[4] wikipedia – Concept_drift

[5] Fortune – A.I. algorithms had to change when COVID-19 changed consumer behavior

[6] Google, Inc. – The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction