Performance-Messung

Insbesondere bei Klassifikationsmethoden benötigt man eine Kennzahl dafür, wie gut ein Modell gearbeitet hat. Für die Einschätzung ist jedoch nicht allein wichtig, wie häufig ein Modell richtig prognostiziert.

Angenommen, ein Modell sagt bei jeder Kreditentscheidung nein, dann hätte es auf jeden Fall alle Kreditausfälle richtig prognostiziert (True Positives). Die True-Positive-Rate bezeichnet man auch als Sensitivität (bekannt durch Corona-Tests). Dummerweise hätte die Bank dann aber auch kein Geschäft mehr gemacht, da das Modell auch die guten Transaktionen verhindert hätte (False Positives). Würde es dagegen alle Anträge gestatten, dann hätte es neben den korrekten Entscheidungen (True Negatives, deren Rate man auch als Spezifität bezeichnet) auch alle inkorrekten Entscheidungen zugelassen (False Negatives).

Idealerweise minimiert ein Modell also sowohl False Positives als auch False Negatives: Bei beiden Extremen geht die Bank pleite – entweder, weil sie gar kein Geschäft mehr macht, oder weil zu viele Kreditausfälle auftreten, die sich nicht mehr durch Krediteinnahmen kompensieren lassen. Die vier Werte der False und True Positives und Negatives bildet eine Confusion Matrix ab: Sie sagt genau, in welcher Kategorie der Positives und Negatives ein Algorithmus wie viele Fälle generiert. Damit lassen sich die Performance-Details zwar gut überblicken, doch der Vergleich mit anderen Modellvarianten fällt schwer, da die Performance nicht in Form einer Kennzahl vorliegt.

Eine Möglichkeit zum Erfassen einer solchen Kennzahl bietet die sogenannte ROC AUC. Das Kürzel steht für die sperrige Bezeichnung Receiver Operating Characteristics Area Under the Curve. Dahinter steckt der Ansatz, die Datenpunkte auf zwei Achsen zu plotten – eine für die Sensitivität, die andere für die Spezifität. Als Kennzahl verwendet man dann die Fläche unter der entstehenden Kurve (Abbildung 4). Bei einem Wert um die 0,5 wäre der Zufall genauso gut, unter 0,5 ist das Ergebnis schlechter als bei einer Zufallsentscheidung.

Eine andere Möglichkeit liefert die Precision Recall Curve: Die Precision ergibt sich hier aus dem Verhältnis der True Positives zur Summe der True und False Positives, der Recall ist dasselbe wie die Sensitivität.

All diese KPIs sagen allerdings nur bedingt etwas darüber aus, wie sich ein Modell nachher in der Wirklichkeit verhält. So ist es häufig sinnvoll, ein Modell gegen das bisherige Modell (oder gegebenenfalls manuelle Prozesse) in einem Split-Test laufen zu lassen. Um beim Beispiel der Bank zu bleiben: Hat das Modell für weniger Kreditausfälle gesorgt? Hinzu kommt, dass man ein Modell auch entwickeln und unterhalten muss, was Kosten verursacht. Rechnet sich dieser Aufwand?

Ein weiteres Thema, das viele Tutorials ignorieren: Ein Modell kann zwar gut funktionieren, aber eventuell diskriminiert es einen Teil der Menschen, die hinter den Datenpunkten stehen. Diese Erfahrung musste zum Beispiel der Erfinder von Ruby on Rails, David Heinemeier Hansson, machen [2], als seine Ehefrau ein zwanzig Mal schlechteres Limit für die AppleCard erhielt als er. Die AppleCard ist eine Kreditkarte von Apple, die Goldman Sachs herausgibt und die es bisher nicht in Deutschland gibt. Seltsamerweise hatte Mrs. Hansson einen besseren Credit Score (ein Pendant zum in Deutschland populären Schufa-Score) als ihr Gatte und war steuerlich mit ihm gemeinsam veranlagt. Das legt die Vermutung nahe, dass dass allein ihr Geschlecht der Grund dafür war, ihr ein schlechteres Limit zu geben.

Neben den reinen Messungen zur Leistung eines Algorithmus gilt es also auch zu testen, ob ein Algorithmus diskriminiert. Dazu könnte man zum Beispiel bei einem Kreditantrag exakt dieselben Daten eingeben, bis auf das Geschlecht oder eine andere Variable, die auf keinen Fall zu einer Benachteiligung führen darf. (jcb/jlu)