Wie validiert man erfolgreich KI-Systeme? Eine Q-Perspektive.

Traditionellerweise werden Software-Systeme nach Abschluss der Entwicklung in die Test- und Abnahmephase überführt, um dort entsprechend ihren Anforderungen verifiziert zu werden. Die Erwartungshaltung ist in jeder Phase der Software-Entwicklung deterministisch und eindeutig.

Diese strikte Erwartungshaltung gilt für Machine Learning (ML)-Systeme nicht. Die Erwartungshaltung gegenüber dem ML-System stellt keinen exakten Wert dar, sondern fordert die Einhaltung eines Wertebereichs. Analytische Systeme zur Mustererkennung arbeiten immer mit einer Wahrscheinlichkeit, die eine Aussage bezüglich der Treffergenauigkeit macht. Dies gilt auch für Prognosesysteme. Der Erfolg von ML-Systemen stützt sich auf die Verwendung von historischen Daten und der damit verbundenen Adaption der Modellparameter des ML-Systems. Die Programmierung solcher Systeme beschränkt sich zumeist auf die Integration von umliegenden Systemen via Schnittstellen. Die Entwicklung wird durch Parametrierung ersetzt und der klassische Software-Entwicklungszyklus durch einen Continuous Adaption / Continuous Integration – Approach:

Select: In der Realität wird in den meisten Fällen auf etablierte Open Source – Bibliotheken, wie zum Beispiel TensorFlow, Scikit-lean, oder Apache Spark zurückgegriffen. Was hier fairerweise nicht unterschätzt werden darf ist die Komplexität der zu verwendeten Schnittstellen und die notwendige Infrastruktur, die für den Einsatz benötigt wird. Anbieter, wie zum Beispiel Microsoft mit Azure bieten hier Komplettlösungen an.

Train: Nach der Selektion eines geeigneten ML-Modells wird dieses unter Laborbedingungen via Trainingsdaten soweit trainiert, dass es den Erwartungshaltungen der Tester genügt. In diesem Qualitätssicherungsschritt, und das ist der Unterscheid zum herkömmlichen Testen, wendet sich der Tester vom klassischen rein deterministischen Ansatz ab und formuliert seine Erwartungshaltung als Ergebnisbereiche, nicht als Ergebniswerte. Die Verifikation tritt in den Hintergrund und die Validierung gewinnt an Bedeutung. Ein deterministisches Verhalten würde an dieser Stelle nicht zielführend sein und ein Indiz für overfitting sein was einem auswendig lernen gleich kommt. Damit hätte das Modell seine gewünschte Flexibilität verloren.

Check: Im nächsten Schritt wird ein Robustness-Test durchgeführt. Hierbei wird ein Validation Set von Eingangsdaten genommen und evaluiert, wie sich das parametrierte ML-System verhält. Der Schwerpunkt liegt auf Ausreisserszenarien: Wie verhält sich die Erkennung von Nummernschildern im Winter, wenn ein Teil des Autonummernschilds vom Schnee bedeckt ist? Gibt es wirklich eine Krise, wenn die Pizza-Lieferanten in der Nähe des Regierungsgebäudes Hochkonjunktur haben? Wie gut kann das ML-System Kauf- oder Verkaufsempfehlungen nach einem Börsen-Crash prognostizieren? Das Ergebnis dieses Tests stellt ein Quality Gate dar und bewertet die Aussagekraft des Systems unter Extrembedingungen.

Integrate: Im dritten Schritt, der Inbetriebnahme in die Produktionsumgebung, wird das ML-System nicht gänzlich den Anwendern überlassen, sondern durch ein geeignetes Monitoring aktiv unterstützt. Das Monitoring sammelt Kombinationen von Eingangsdaten und Ergebnissen die ausserhalb eines akzeptablen Ergebnisbereichs liegen.

Adopt: Die aus dem Monitoring gewonnen Erkenntnissen und den zugrundeliegenden Daten werden von Domain-Spezialisten ausgewertet und gegebenenfalls zur Adaption der ML-Modellparameter verwendet. Die Adaption der Modellparameter geschieht durch direkte Justierung von Schwellenwerten oder einer erneuten Lern-Session (Phase Train).

Die hier vorgestellten Phasen, wobei Train und Adopt als identische Phase mit unterschiedlichen Voraussetzungen angesehen werden kann, entsprechen einem Entwicklungs- und Integrationszyklus (Select, Train, Check, Integrate) und einer Bugfix-Auslieferung (Adopt) im klassischen Sinne. Der Unterschied hierbei ist, dass kein Code, sondern Parameter-Sets des ML-Modells ausgeliefert werden. Aus Sicht der Qualitätssicherung bestimmen Validierungen und Wahrscheinlichkeitsräume die Bedeutung und ersetzen deterministische Erwartungshaltungen.

In einem dynamischen System gibt es keine statische Lösung

In diesem Artikel wurde bewusst auf eigentlich notwendige mathematische Verweise aus der Statistik, der Algebra und natürlich der Wahrscheinlichkeitstheorie verzichtet. Dieses mathematische Fundament ist essentiell, um die Qualität solcher Modelle bewerten zu können. In weiteren Artikeln werde ich näher darauf eingehen.