Von Janina Nuber

Voraussichtliche Lesedauer: 15 Minuten

Techblog

Ist KI testbar?

Wenn ein Tesla-Auto mit autonomen Elementen plötzlich ohne erkennbaren Grund die Geschwindigkeit reduziert, – hätte Tesla das Verhalten des Autos in exakt dieser Situation testen können? Anders gefragt: kann Tesla wirklich für jede mögliche Fahrsituation einen Test durchführen? Vermutlich nicht. Um die Gründe dafür und um andere Herausforderungen beim Testen von Machine Learning (ML)-Systemen geht…

Techblog

Wenn ein Tesla-Auto mit autonomen Elementen plötzlich ohne erkennbaren Grund die Geschwindigkeit reduziert, – hätte Tesla das Verhalten des Autos in exakt dieser Situation testen können? Anders gefragt: kann Tesla wirklich für jede mögliche Fahrsituation einen Test durchführen? Vermutlich nicht. Um die Gründe dafür und um andere Herausforderungen beim Testen von Machine Learning (ML)-Systemen geht es in diesem Artikel.

Testen, Testen und Testen

Unter Testen verstehen wir, das Verhalten eines Systems unter verschiedenen Bedingungen zu beobachten und auf auftretende „Fehler“ zu achten. Im klassischen Software Engineering gibt es üblicherweise zwei Dimensionen, in denen die Dinge schieflaufen können: in der abstrakten Logik des Algorithmus oder in der Qualität der Implementierung als Code. Bei ML-Systemen kommen noch zwei weitere Dimensionen hinzu, in denen sich Quellen für „Fehler“ einschleichen können: das Modell und die Daten.

Über das Testen von ML-Software lässt sich daher aus drei technischen Perspektiven nachdenken. Sie unterscheiden sich darin, wie eng sie mit dem zusammenhängen, was ein ML-System auszeichnet – dem Modell und den Daten.

  1. Software Testing: Tests, die nicht direkt Daten und Modell betreffen (Integration Tests, End-2-End-Tests).
  2. Pipeline Testing: Tests, die darauf abzielen, dass die Pipeline von Daten-Input zu Modell-Output in der Trainingsphase und in der Testphase fehlerfrei und effizient läuft (Unit Tests, etwa für das Pre-Processing der Daten).
  3. Model Testing: Testen des trainierten Modells auf einem Testdatensatz, um zu kontrollieren, ob das Modell auch auf unbekannten Daten eine ausreichend zufriedenstellende Genauigkeit/Zuverlässigkeit/Mächtigkeit besitzt (Statistical Tests).

Es ist unproblematisch, ML-Systeme aus der Perspektive des Software Testing und des Pipeline Testing zu testen. Komplizierter ist jedoch das Model Testing.

Warum? Dazu erinnern wir uns an zwei Punkte, die wir im letzten Artikel (https://www.maibornwolff.de/blog/ein-ki-system-muss-fehler-machen-duerfen) über die Eigenarten von Machine Learning und über die Arbeit als Data Scientist erfahren haben:

  • Die Ursache für unerwartetes Verhalten des Systems ist nicht unbedingt im Quellcode ersichtlich. Die meisten ML-Modelle, insbesondere Deep Learning Networks und Bayesian Networks, folgen keiner explizit von uns definierten Regel, wenn sie basierend auf Input-Daten einen Output berechnen. Das System selbst lernt den Pfad von Input zu Output und dieser Pfad liegt in den Tiefen der Modellparameter vergraben.
  • Es hängt stark vom konkreten Projekt und damit vom konkreten Business-Ziel des Kunden ab, welches ML-Modell und welches Evaluationsmaß passend ist und welche Leistung des ML-Modells ausreicht – also welches Data-Science-Ziel gesetzt ist.

Ein klar definiertes Data-Science-Ziel dient uns als objektives Test-Kriterium, das unsere Erwartungen an den Modell-Output eingrenzt – sind wir schon mit 89 Prozent Accuracy zufrieden? Oder erst mit 95 Prozent? Oder sind wir mit 68 Prozent Recall und 80 Prozent Precision oder 77 Prozent F1-Score zufrieden? Gerade da uns eine explizite, nachvollziehbare Wenn-Dann-Regel wie bei klassischen Software-Systemen fehlt, die wir erklären, kontrollieren und debuggen können, ist ein solches objektives Test-Kriterium so wichtig. Auch wenn wir die Regeln nicht direkt bestimmen und nicht direkt einsehen können, können wir deren Befolgung durch das System letztlich anhand eines objektiven Ergebnis-Zielwerts testen.

Verschiedene Test-Metriken für verschiedene ML-Modelle

Schauen wir uns zwei Beispiele an, mit welchen statistischen Methoden man bestimmte Modelle auf einen Ergebnis-Zielwert hin testen kann.

Beispiel 1: binäre Klassifikation


Wir stellen uns ein Klassifikationsmodell vor, das Inputdaten je einer von zwei möglichen Klassen zuordnen soll. Zum Beispiel ein ML-System, das medizinische Bildaufnahmen von Gewebeteilen danach klassifiziert, ob es sich bei dem Gewebe um gesundes oder krankes Gewebe handelt (etwa in der Brustkrebserkennung). Hierbei wird das Modell darauf trainiert, krankes Gewebe zu erkennen. Ein „positives“ Ergebnis bedeutet daher, dass das Gewebe als krank klassifiziert wurde.

Um zu testen, wie zuverlässig ein solches binäres Klassifikationsmodell krankes Gewebe von gesundem unterscheidet, können wir eine sog. Wahrheitsmatrix aufstellen.

Aus dieser Tabelle kann man ablesen, wie häufig das Modell

  • gesundes Gewebe als krank („falsch positiv“)
  • krankes Gewebe als gesund („falsch negativ“)
  • gesundes Gewebe als gesund („richtig negativ“)
  • krankes Gewebe als krank („richtig positiv“)

klassifiziert.

klassifikierungstabelle_zum_erstellen_der_receiver_operating_characteristic_kurve

Aus dieser Tabelle kann man die sog. Receiver Operating Characteristic Kurve (ROC-Kurve, https://towardsdatascience.com/understanding-auc-roc-curve-68b2303cc9c5) erstellen. Die ROC-Kurve vergleicht die Rate der „richtig positiven“ Ergebnisse mit der Rate der „falsch positiven“ Klassifikationen. Sie dient dazu, die Qualität des binären Klassifikators zu messen und zu veranschaulichen.

Beispiel 2: Regressionsanalysen & Vorhersagemodelle

Viele Probleme erfordern es aufgrund relevanter Informationen bestimmte Werte zu berechnen oder Vorhersagen zu treffen. Will man zum Beispiel die Entwicklung des Stromverbrauchs in einer bestimmten Produktionsanlage vorhersagen, muss man dazu die Stromverbrauchsdaten der Vergangenheit analysieren, die entscheidenden Variablen identifizieren und ein Vorhersagemodell entwickeln. Bei so einer Regressionsanalyse erhalten wir ein Modell, das basierend auf den Input-Variablen (etwa realisierte Produktionsmenge, Außentemperatur) einen numerischen Output-Wert liefert (Menge an benötigten kWh). Diese Vorhersage kann sich entweder auf einen bestimmten Zeitpunkt beziehen („Wie viel Strom wird das Werk voraussichtlich am 03. August 2021 verbrauchen?“) oder auch auf einen Zeitverlauf („Welche Entwicklung des Stromverbrauchs ist in den nächsten drei Monaten zu erwarten?“).

Um zu beurteilen, wie treffsicher die Vorhersagen eines Regressionsmodells sind, können wir verschiedene Metriken berechnen. Sie alle geben an, wie weit die vorhergesagten Werte von den beobachteten Werten im Durchschnitt entfernt sind.

Eine grundlegende (wenn auch nicht perfekte) Metrik ist der sogenannte Mean Absolute Error (MAE). Stark vereinfacht gesagt: Wie hoch ist die rechnerische Differenz zwischen den vom Modell vorhergesagten Werten und den tatsächlich beobachteten Werten im Durchschnitt über alle Datenpunkte beziehungsweise über alle Zeitpunkte? Also: Wie hoch war die Abweichung des vorhergesagten Stromverbrauchs vom tatsächlichen Stromverbrauch im Durchschnitt über die letzten drei Monate im Datensatz?

Mean Absolute Error Metrik

Die roten Linien zeigen die Abweichungen von den vorhergesagten zu den tatsächlichen Werten. (https://i.imgur.com/tqnei6J.jpg)

Das Schaubild kann diesen Gedanken verdeutlichen. Die grüne Linie zeigt die vorhergesagten Werte, die blauen Punkte sind die tatsächlich beobachteten Werte und die roten Linien zeigen die rechnerische Differenz zwischen Vorhersage und Beobachtung.

Der MAE hat einige Schwachstellen, unter anderem drückt er nur aus, wie weit die Vorhersage von der Beobachtung abweicht, aber nicht, in welche Richtung die Summe aller Abweichungen zeigt. Er sagt uns also nicht, ob in einem Zeitraum von drei Monaten insgesamt mehr oder weniger Strom verbraucht wurde als vorhergesagt. (Um im Detail zu verstehen, warum das so ist, empfiehlt es sich zum Beispiel hier zu stöbern: https://towardsdatascience.com/forecast-kpi-rmse-mae-mape-bias-cdc5703d242d)

Glücklicherweise hat die Statistik noch andere Metriken hervorgezaubert, die diese Schwachstellen des MAE ausgleichen, etwa den Mean Absolute Scaled Error (https://medium.com/@ashishdce/mean-absolute-scaled-error-mase-in-forecasting-8f3aecc21968).

Neue Welt, alte Daten

Auch wenn wir Wege finden können, ein ML-Modell möglichst objektiv auf die Beziehung von Input zu Output und auf einen Zielwert hin zu testen, ist dies nur eine Momentaufnahme. Wir testen Modell und Daten, die einen bestimmten Ausschnitt der Wirklichkeit zu einem bestimmten Zeitpunkt nachbilden. Aber nach dem Testen steht unsere Welt nicht still. Sie ändert sich ständig. Daten, die gestern noch als eine annähernde Repräsentation unserer Welt angesehen werden konnten, sind heute schon veraltet. Modelle, die auf diesen veralteten Daten trainiert wurden, tendieren umso mehr dazu, einen anderen Output zu liefern als den, den wir erwarten.

Übrigens: Verändert sich die Beziehung zwischen einer Input-Variable und den Output-Werten auf unvorhersehbare Weise grundlegend bezeichnet man dieses Problem als Concept Drift. Um die negativen Auswirkungen von diesem Concept Drift abzufangen, müssen wir das Model Testing nicht als Einmalaktion verstehen, sondern (so wie das Software-Testing und das Pipeline-Testing) dauerhaft in die DevOps-Pipeline einbauen.

Kritisch wird es, wenn alte Modelle und alte Daten auf neue Situationen treffen. Oder um es mathematisch auszudrücken: wenn die statistische Verteilung, auf die das Model anhand der Trainings- und Testdaten konditioniert wurde, die Daten aus einer vollkommen anderen statistischen Verteilung erklären soll. Schauen wir uns nur an, wie sich die Wirtschaftsrealität durch COVID-19 verändert hat: Ein Modell, das vor dem Ausbruch der Pandemie Anfang 2020 mit damals aktuellen Flugverkehrsdaten trainiert wurde, wird keine nützlichen Vorhersagen mehr über Ticketpreise oder Passagieraufkommen im Jahr 2021 treffen können.

Manipulierte Daten

Sogenannte Adversarial Attacks nutzen diese Schwachstelle in ML-Modellen ganz gezielt aus. Angreifer können künstliche Input-Daten fabrizieren oder bestehende Input-Daten der echten Welt so manipulieren, dass sie die statistischen Annahmen des trainierten Modells durchbrechen und das Modell damit austricksen. Ein paar relativ kleine physische Manipulationen an Verkehrsschildern können ML-Modelle so verwirren, dass sie zum Beispiel ein Stoppschild als ein Geschwindigkeitsbegrenzungsschild einordnen – selbst wenn es für den menschlichen Fahrer ganz offensichtlich ist, dass ein Stoppschild mit ein paar kleinen weißen und schwarzen Klebestreifen immer noch ein Stoppschild ist.

Das Teuflische an den Adversarial Attacks ist aber, dass auch bereits kleinste Manipulationen an den Input-Daten zu massiven Abweichungen im Modell-Output führen können – und zwar so kleine, dass sie für den Menschen gar nicht wahrnehmbar sind. Und noch teuflischer: Diese Fehl-Klassifikationen gehen oft mit hohen Confidence-Werten ein, das heißt, das Modell ist sich bei der falschen Klassifikation auch noch sehr sicher.

klebestreifen_auf_stoppschild

Die Klebestreifen auf dem Stoppschild bewirken, dass die ML das Schild als Geschwindigkeitsbegrenzungs-Schild einordnet. (https://arxiv.org/pdf/1707.08945.pdf)

Wie kann man ML-Modelle gegen solche Adversarial Attacks abhärten und testen? Man könnte sich selbst in die Rolle des Angreifers begeben, möglichst viele künstliche Adversarial Examples konstruieren und diese als Negativ-Beispiele in die Trainingsdaten miteinbeziehen. Der Haken: So ein Vorgehen führt letztlich zu einem unendlichen Hin-und-Her-Spielchen zwischen Angreifern und ML-Entwicklern. Kreative Angreifer können schließlich eine unbegrenzte Anzahl möglicher Adversarial Examples erzeugen. (Für mehr spannende Details zu Adversarial Attacks sei dieser Artikel empfohlen: https://openai.com/blog/adversarial-example-research/)

Vielfältige und seltene Daten

Aber all diese Probleme sind eher eine Unterkategorie eines größeren Problems: Wie können ML-Modelle auf „elegante“ Weise mit Fällen umgehen, die sie nicht kennen? Diese Frage erstreckt sich insbesondere auf die Edge Cases, also Sonder- oder Grenzfälle, die eher selten oder gar nicht in den Trainingsdaten vorkommen. Der Inputraum von ML-Systemen ist weitaus vielfältiger als der von klassischen regelbasierten Software-Systemen. Sie verarbeiten mediale Daten (große Mengen Text, Fotos, Videos oder andere komplexe Signale), die zum Beispiel oft nicht eindeutig klassifiziert werden können. Wäre das nicht so, würde ein klassisches regelbasiertes System genügen. Es ist daher unmöglich, ML auf seine Generalisierbarkeit im gesamten möglichen Input-Raum zu testen.

Datengetriebene Produktentwicklung

Selbst wenn ein ML-System, das in einem Produkt oder einem Service integriert ist, die oben beschriebenen technischen Tests so besteht, dass die Ingenieure damit zufrieden sind, gibt es noch einen anderen entscheidenden Test: durch den User des Produkts. Wenn die ausgeklügelte Recommendation Engine von Spotify uns einen Song empfiehlt, muss er uns zwangsläufig gefallen? Wie schätzt ein User den Nutzen der ML-getriebenen Empfehlungsfunktion ein, wenn er den Song doof findet (auch wenn der Algorithmus ihm zuvor schon viele tolle Songs vorgeschlagen hat)? Hätte Spotify vorab testen können, wie jeder Nutzer über all die vielen empfohlenen Songs denkt? Vermutlich nicht – genauso wenig wie Tesla das Verhalten seiner Autos in jeder möglichen Situation vorab testen kann.

Können wir es also schaffen, bei nicht-sicherheitskritischen Anwendungen eine tolerante Fehlerkultur ohne Häme gegenüber der ML zu entwickeln – und unseren Sprachassistenten nicht gleich an die Wand schmeißen, wenn er uns auch beim dritten Mal noch nicht versteht? Es gilt schließlich: Ein Produkt wird benutzt, wenn es nützlich ist. Das Interessante ist aber, dass ML-Systeme nützlich sein können, obwohl sie manchmal Fehler machen. Das haben wir auch im letzten Artikel festgehalten: Machine Learning ist trotz inhärenter „Fehler“ die beste Lösung für viele Probleme, die man ohne Machine Learning lange Zeit gar nicht lösen konnte.

Daher müssen sich die Produkt-Hersteller überlegen, wie sie ML-getriebene Produkte entwickeln können, die im großen und ganzen Nutzen für den User bringen – auch wenn sie ab und an versagen. Nur dann sind User auch tolerant gegenüber Fehlern – ganz getreu dem Satz: “all models are wrong, but some are useful”. 

Und hier greift noch ein anderer Aspekt von ML-getriebenen Produkten: Hersteller wie Tesla gestalten ihre Produkte als datengetriebene Produkte. Das bedeutet: Ein Tesla-Auto ist so entwickelt, dass es Daten über sein eigenes Fahrverhalten und über die Interaktion des Insassen mit dem Auto sammelt. Muss der Insasse in das Fahrverhalten des Autos eingreifen, um einen Fehler zu korrigieren, wird das in den Daten aufgezeichnet. Tesla nutzt diese Daten, um unbekannte Szenarien zu entdecken und ihr ML-getriebenes Fahrsystem kontinuierlich zu verbessern.

Diese Art der kontinuierlichen, datengetriebenen Produktverbesserung ist typisch für ML-gestütze Produkte, wie der „Virtuous Cylce of AI“ verdeutlicht:

virtuose_cycle_of_ai

Virtuous Cycle of AI

Fazit

Gerade die machtvollsten ML-Lösungen können Menschenleben gefährden, wenn sie nicht wie erwartet agieren – nicht nur bei autonomen Fahrzeugen, sondern auch bei Medizingeräten oder Produktionsanlagen. Neben dem Testen gibt es daher noch das Verifizieren von Software. Beim Testen beobachtet man lediglich, ob Fehler auftreten. Verifikation geht darüber hinaus: Das Ziel von Verifikation ist es, eine begründete Sicherheitsgarantie dafür zu geben, dass das System unter einer Vielzahl von Umständen eben keine Fehler macht. Es geht also darum, ML-Systeme von nachweisbarer Qualität zu entwickeln.

Wie das Beispiel der Adversarial Attacks zeigt, ist es jedoch im Grunde unmöglich, ein ML-System mit allen erdenklichen Input-Daten zu testen – und gerade für ungewöhnliche Inputs müsste man das Verhalten eines ML-Systems verifizieren, um Sicherheitsgarantien geben zu können. Deshalb ist es umso wichtiger, das ML-System mit einer möglichst großen Menge erdenklicher Edge Cases im Vorfeld zu testen.

Sowohl das Testen als auch das Verifizieren von ML-Software sind also Forschungsfelder, in denen große Fortschritte nötig sind. Ein aktueller Ansatz ist klassische Software, die auf expliziten, nachvollziehbaren Regeln basiert, als maßgebliche Ergänzung zu den ML-Komponenten in KI-Systeme zu integrieren. Die Idee ist, die Macht der ML-Modelle mit der Nachvollziehbarkeit von klassischer Software zu verbinden. Die Forschung der kommenden Jahre wird zeigen, ob wir irgendwann die Frage „Ist KI testbar?“ oder gar „Ist KI verifizierbar?“ eindeutig mit Ja beantworten können.

Was wir heute schon festhalten können: Machine Learning ist innerhalb gewisser Grenzen testbar, aber wir müssen den Gemeinheiten, die in der Vielfalt der realen Input-Daten lauern, aufmerksam begegnen.

Quellen & weiterführende Links:


Über die Autorin

Janina Nuber