Wie unsere Reise durch die Welt der algorithmischen Voreingenommenheit gezeigt hat, stehen Datenwissenschaftler vor einer gewaltigen Herausforderung, bei der uralte gesellschaftliche Praktiken und Vorurteile, Unternehmenseigentümer, Nutzer, widerspenstige Datensätze und das müde Gehirn des Datenwissenschaftlers sich alle verschwören können, um algorithmische Verzerrungen entstehen zu lassen. Gleichzeitig haben Datenwissenschaftler viele Möglichkeiten, algorithmische Verzerrungen durch durchdachte Modellierungsentscheidungen einzudämmen. In diesem letzten Teil des Buches werden wir die wichtigsten Techniken, mit denen Datenwissenschaftler algorithmische Verzerrungen eindämmen können, in größerem und technischerem Detail diskutieren. Damit ich keine unrealistischen Erwartungen wecke, möchte ich betonen: Algorithmische Verzerrungen sind kein einzelner Feind, sondern eine ganze Armee von Gegnern – die Erstellung eines Modells kann sich wie eine Wanderung durch den Dschungel anfühlen, bei der man sich gegen alles wehren muss, von Moskitos über Giftschlangen bis hin zu wilden Tigern. Deshalb gibt es leider kein Patentrezept, sondern nur einen Überlebenskurs und eine Packliste mit empfehlenswerten Utensilien wie Moskitoschutzmittel und Machete.
In diesem Kapitel werden wir den in Kap. 4 vorgestellten Modellentwicklungsprozess wieder aufgreifen und spezifische Schritte und Werkzeuge für den auf Verzerrungen bedachten Datenwissenschaftler nennen. Im nächsten Kapitel werden wir uns eingehender mit Techniken beschäftigen, mit denen sich beurteilen lässt, ob in den Daten versteckte Verzerrungen lauern. In Anbetracht der Tatsache, dass maschinelles Lernen sowohl Freund als auch Feind sein kann, wird in Kap. 20 erörtert, wann maschinelles Lernen ein Feind ist und durch mehr manuelle Techniken ersetzt werden sollte, während in Kap. 21 erörtert wird, wie maschinelles Lernen Ihr Freund sein und helfen kann, algorithmische Verzerrungen zu bekämpfen. Kap. 22 greift das Thema der Selbstverbesserung von maschinellen Lernmodellen auf einer eher technischen Ebene auf, und Kap. 23 nimmt eine Governance-Perspektive ein und erörtert, wie die hier besprochenen Techniken in einer großen Organisation eingebettet werden können, in der es mehr Data Scientists gibt, als Sie persönlich anleiten und beaufsichtigen können.
Schritt 1: Modelldesign
- 1.
Holen Sie sich Einblicke aus dem wirklichen Leben an der Front! Wenn Sie die Kreditausfälle von Lebensmittelgeschäften in Familienbesitz modellieren, sprechen Sie mit den Kreditsachbearbeitern, die die Anträge bearbeiten, mit den Verkäufern in der Filiale, die ihnen Kredite verkaufen, mit den Inkassobüros, die sie wegen unbezahlter Kredite verfolgen, und mit dem Handelsvertreter eines berühmten italienischen Unternehmens, der ihnen unwiderstehliche, ungesunde Süßwaren verkauft. Wenn Sie Kfz-Versicherungsansprüche modellieren, sprechen Sie mit der Polizei über Autodiebstähle, sprechen Sie mit Mechanikern in Karosseriewerkstätten über Reparaturkosten und fragen Sie die Leute eines deutschen oder schwedischen Automobilclubs, die den so genannten Elchtest (definiert in der internationalen Norm ISO 3888-2) durchführen, warum Fahrzeuge umkippen, wenn Fahrer haarigen Biestern ausweichen, die auf die Straße springen.
- 2.
Überlegen Sie, ob die Daten, die Ihnen jetzt zur Verfügung stehen, möglicherweise durch eine reale Verzerrung beeinträchtigt sind, und wie Sie diese am besten beseitigen können. Vielleicht können Sie externe Daten finden, um die Verzerrung zu korrigieren (z. B. können für abgelehnte Kreditanträge in vielen Märkten Daten von Kreditbüros gekauft werden, um die sogenannte Ablehnungsinferenz durchzuführen (d. h., auf Grundlage des Verhaltens des Kunden bei anderen Banken herauszufinden, was passiert wäre, wenn der Kredit genehmigt worden wäre)), oder vielleicht müssen Sie auf eine spezielle Datengenerierung drängen (z. B. ein Experiment mit zufällig ausgewählten Fällen), um unverzerrte Daten von Grund auf zu erstellen.
- 3.
Stellen Sie sicher, dass der Geschäftsprozess fatale Rückkopplungsschleifen verhindert.
Wenn Sie mit den Mitarbeitern an der Front sprechen, sollten Sie sich überlegen, welche Fragen mehr oder weniger wahrscheinlich voreingenommene Antworten hervorrufen werden. Für einen Kreditsachbearbeiter ist es zum Beispiel viel einfacher zu beurteilen, welche Unternehmensmerkmale ein Unternehmen im Allgemeinen „profitabler“ machen, als zu beurteilen, was es „ausfallgefährdeter“ macht. Er wird sowohl profitable als auch unprofitable Unternehmen zu Dutzenden gesehen haben (und somit über eine solide Erfahrungsbasis verfügen, um differenzierende Merkmale zu beobachten), während der Unterschied zwischen einer niedrigen und einer hohen Ausfallwahrscheinlichkeit vielleicht nur 3 pro 100 Unternehmen beträgt. Daher ist es äußerst unwahrscheinlich, dass der Kreditreferent bei vielen Merkmalen genügend Fälle für eine statistisch gültige Bewertung beobachtet hat; stattdessen werden seine Antworten wahrscheinlich auf einigen traumatischen Erfahrungen beruhen (z. B., wenn eine US-Bank ein einziges deutsches Unternehmen als Kunden hatte und dieses Unternehmen in einem spektakulären Zusammenbruch unterging, der dem Kreditsachbearbeiter eine Menge unangenehmer Fragen bescherte,2 wird seine Amygdala ihn mit großer Wahrscheinlichkeit dazu veranlassen, auf die Frage, was ein risikoreiches Unternehmen ausmacht, „Deutsche!“ herauszuplatzen).
Ich kann auch nicht genug betonen, wie wichtig es ist, lange und gründlich darüber nachzudenken, ob die verfügbaren Daten verzerrt sein könnten (denken Sie an unser Beispiel mit den Zollkontrollen), und wenn nötig darauf zu drängen, neue, unverzerrte Daten zu erstellen, anstatt mit Datenmüll zu arbeiten. Um dies in die richtige Perspektive zu rücken: Wenn ich Einstellungsinterviews mit Datenwissenschaftlern abhalte, ist der häufigste Grund für die Ablehnung eines Bewerbers, dass er oder sie übersehen hat, dass meine Fallstudie verzerrte Daten enthielt (auch wenn ich unverhohlen Hinweise gegeben habe). Und es ist aus drei Gründen wirklich schwer, auf die Erhebung neuer, unverzerrter Daten zu drängen: Es bedeutet sehr oft, dass eine vom Unternehmen anvisierte Frist verpasst wird, es erfordert eine Investition (sowohl von Geld als auch von Zeit des Managements), und Entscheidungsträger haben eine angeborene Neigung, kurzfristige Schmerzen (d. h., sie wollen vermeiden, eine Frist zu versäumen oder ihren Chef um das Budget für ein Experiment zu bitten) unter Hinnahme von langfristigen Schmerzen (d. h., mit einem verzerrten Algorithmus arbeiten zu müssen) zu minimieren. Der beste Weg, diese Voreingenommenheit zu überwinden, besteht darin, den Entscheidungsträger zu bitten, sich vorzustellen, wie er sich in einem Jahr verteidigen muss, weil der neue Algorithmus, den er in Auftrag gegeben hat, völlig unbrauchbar ist und sein Chef ihn feuern will, weil er das Problem nicht behoben hat.
Um die Schwere des Problems zu verdeutlichen, möchte ich an das Schicksal einer asiatischen Bank erinnern, die ein neues statistisches Modell für die Vergabe von Verbraucherkrediten entwickelte. Das Modell wurde anhand der von der Bank vergebenen Kredite erstellt – und niemand hatte den Statistiker darauf aufmerksam gemacht, dass die Filialmitarbeiter in der Vergangenheit Kunden weggeschickt hatten, die sie für riskant hielten (eine der Hochrisikogruppen waren z. B. Polizisten – in diesem Markt glaubten diese, über dem Gesetz zu stehen, und neigten daher dazu, finanzielle Schulden nicht zurückzuzahlen). Nach der Einführung des neuen Modells wurden die Filialmitarbeiter gebeten, alle Anträge durch das neue System laufen zu lassen, und zu ihrer Freude (und wahrscheinlich auch Überraschung) wurden die meisten der „riskanten“ Kunden (z. B. Polizisten) genehmigt. Das Ergebnis war ein enormer Anstieg der Kreditverluste – das neue Modell hatte Millionen von Dollar vernichtet. Die einzige Möglichkeit für diese Bank, dieses Schicksal zu vermeiden, wäre gewesen, zumindest für eine Stichprobe (z. B. alle Anträge, die in einigen Filialen über einen Zeitraum von zwei Wochen gestellt wurden) jeden Kunden aufzuzeichnen, der „durch die Tür“ kam (mit allen Informationen, die im Antrag angegeben waren), zusammen mit dem, was die Kundenbetreuer taten (den Kunden wegschicken oder den Antrag bearbeiten).
Schließlich erinnert uns die Berücksichtigung potenzieller Rückkopplungsschleifen daran, dass Algorithmen kein Selbstzweck sind – wir entwickeln und verwenden sie für ein übergeordnetes Geschäftsziel, und der Algorithmus, den ein Geschäftsinhaber angefordert hat, und die Art und Weise, wie er ihn zu verwenden gedenkt, können für die Erreichung seiner Ziele geeignet sein oder auch nicht. Hier haben wir die Möglichkeit und die Pflicht, als Denkpartner aufzutreten, der den Geschäftsinhaber bei der Gestaltung eines besseren Geschäftsprozesses anleitet und dabei hilft, die richtige Rolle und das richtige Design für einen einzelnen oder eine ganze Reihe von Algorithmen zur Unterstützung dieses Prozesses zu definieren.
Eine vierte Überlegung beim Modelldesign ist die Wahl der Modellierungstechnik im Hinblick auf mögliche Verzerrungen. Dieses Thema wird in Kap. 20 ausführlich behandelt.
Schritt 2: Datenaufbereitung („data engineering“)
Seien Sie paranoid bei der Definition der Stichprobe – bei fast jedem Modell, das ich erstelle, ist die Definition der Stichprobe die schwierigste Aufgabe, weil sie so viele Fallen mit sich bringt, die zu Verzerrungen führen. Ich mache mir insbesondere Gedanken über (1) die Stratifizierung (d. h. wie ich die Größenbeschränkungen meiner Stichprobe aufgrund von Kosten- und Zeitbudgets umgehen kann und so eine unzureichende Anzahl von Fällen für bestimmte Profile vermeide), (2) die abzudeckenden Zeiträume und (3) die Gesamtgröße der Stichprobe, die für ein robustes Modell erforderlich ist (unter Berücksichtigung der Anzahl und Größe der Teilsegmente, von denen ich annehme, dass sie unterschiedliche Verhaltensweisen aufweisen, der Häufigkeit bestimmter seltener Merkmale und der Modellierungstechniken, die ich anwenden möchte). All diese Entscheidungen erfordern in der Regel kreatives Denken, um die Kosten zu minimieren (z. B. kann es sein, dass ich eine modulare Struktur aufbaue, bei der ich eine kleinere Stichprobe für eine einzelne teure Datenquelle und eine viel größere Stichprobe für alle anderen Datenquellen habe), und es kann erforderlich sein, ein größeres Budget zu beantragen (z. B. um externe Daten für eine größere Stichprobe zu kaufen).
Datenerhebung: Seien Sie äußerst wachsam in Bezug auf Datenbankabfragen oder manuelle Prozesse, die versehentlich bestimmte Profile ausschließen bzw. übersehen könnten – sowohl aufgrund technischer Probleme (z. B. kann sich bei einer bestimmten Auslandsfiliale der Offline-Upload bestimmter Daten verzögern, was erklärt, warum ein Schnappschuss zum Jahresende, der aus einem Datenarchiv gezogen wird, Fälle aus dieser Filiale ausschließen könnte) als auch aufgrund konzeptioneller Probleme (z. B. gibt es in vielen Kontexten eine sog. Überlebenden-Verzerrung – also „survivorship bias“). Wenn man beispielsweise Banken um eine Liste aller ausgefallenen Konten bittet, ist die Wahrscheinlichkeit, dass Fälle fehlen, sehr hoch. Ich habe Banken erlebt, die abgeschriebene (d. h. nicht bezahlte) Konten aus ihrem IT-System gelöscht haben; die die Ausfallmarkierung aus dem System entfernt haben, als sie sich mit dem Kunden auf eine Umstrukturierung des Kredits geeinigt haben (auch wenn dies für die Bank mit Verlusten verbunden war); oder die die Papierakte mit wesentlichen Kreditinformationen für ausgefallene Kunden als „fehlend“ meldeten, weil die Akte physisch in ihre Inkassoabteilung verlegt worden war. In ähnlicher Weise können SQL-Abfragen leicht winzige konzeptionelle Fehler aufweisen, die dazu führen, dass bestimmte Profile übersehen (oder falsch klassifiziert, dupliziert oder verschlüsselt werden). Auch hier liegt der Schlüssel zu all dem oft an der Front: Befragen Sie leitende Buchhalter und Back-Office-Mitarbeiter in der Inkassoabteilung zu den unzähligen Möglichkeiten, wie ein Kredit „schlecht“ werden kann, und holen Sie nützliche Benchmarks ein (z. B. den Gesamtkreditverlust, der für das betreffende Portfolio im Jahresabschluss des letzten Jahres verbucht wurde), um zu beurteilen, ob Ihr Datensatz vollständig aussieht.
Bei der Aufteilung der Stichprobe in eine Entwicklungs-, eine Test- und eine Validierungsstichprobe sind die Zeiträume sorgfältig zu wählen, wobei insbesondere auf verkürzte Leistungsfenster („performance period“) für das Ergebnis und verkürzte Datenverläufe bei den Prädiktoren zu achten ist, zwei gewaltige Quellen für konzeptionelle Verzerrungen.
Die Datenqualität ist für die Vermeidung von Verzerrungen so wichtig, dass ich diesem Thema das gesamte nächste Kapitel gewidmet habe.
Testen Sie bei der Datenaggregation die konzeptionelle Solidität, indem Sie eine Reihe von Testfällen sorgfältig untersuchen, insbesondere auf Ausnahmen. Ein Beispiel für typische Probleme sind Datenelemente mit einer 1:n-Beziehung (d. h. eine zu vielen) – so könnte eine Bank in einem Kreditbürobericht mehrere Kredite eines Kunden finden; ein Arzt, der sich nach der Krebsgeschichte in der Familie eines Patienten erkundigt, könnte auf mehrere Geschwister, Onkel usw. stoßen; und ein Zollinspektor, der die Geschichte eines Spediteurs untersucht, könnte mehrere Sendungen in der Vergangenheit finden. Wie fasst man diese zusammen? Bei Hochrisikomarkern wird häufig ein Kriterium für den schlimmsten Fall gewählt (z. B. „jemals irgendwo 90 Tage überfällig“). Dies führt jedoch zu einer subtilen Voreingenommenheit gegenüber Proliferationen: Wenn Sie mit einer extrem großen Familie gesegnet sind, in der Ihre Familie über Generationen hinweg stolz darauf war, eine zweistellige Anzahl von Kindern zu haben, ist die Wahrscheinlichkeit, dass Sie einen einzigen Krebsfall in der Familiengeschichte finden, bei sonst gleichen Bedingungen viel größer, als wenn Ihre Vorfahren begeisterte Verfechter einer Ein-Kind-Politik waren! In einem Algorithmus, der die Wahrscheinlichkeit einer Krebserkrankung abschätzen soll, könnte die Variable „schlimmster Krebsstatus in der Familie“ daher zu einer Verzerrung führen, die die Wahrscheinlichkeit einer Person, an Krebs zu erkranken, überschätzt, wenn die Person aus einer sehr großen Familie stammt, und unterschätzt, wenn die Familie klein ist. Gleichzeitig ist ein Verhältnis (% der Familienmitglieder mit Krebs) ähnlich irreführend – wenn Sie sich an frühere Diskussionen über Signifikanz erinnern, werden Sie sich daran erinnern, dass 0 von 5 Fällen viel weniger aussagekräftig ist als 0 von 500. In diesem Fall wäre es am besten, zwei aggregierte Variablen zu erstellen – die Anzahl der Familienmitglieder mit Krebs und die Anzahl ohne Krebs – und aus diesen Werten während der Merkmalsentwicklung komplexere abgeleitete Merkmale zu erstellen (was wir im nächsten Schritt angehen werden).
Schritt 3: Modellzusammenbau („model assembly“)
- Ausschluss von Datensätzen: Welche Arten von Datensätzen in der Stichprobe wären für die statistische Entwicklung des Algorithmus irreführend? Kreditanträge sind ein gutes Beispiel, da es bis zu vier Arten von irreführenden Fällen geben kann (wenn nicht mehr):
Geringfügige Ausfälle (d. h. kleine Beträge) haben in der Regel andere Ursachen als Kreditprobleme, wie oben erläutert.
Fälle von Identitätsbetrug sind irreführend, weil das Profil des Antragstellers irrelevant war und der Schaden entstand, weil die Identitätsprüfung der Bank versagte (und daher ein Krimineller, der sich als jemand anderes mit einem guten Risikoprofil ausgab, den Kredit im Namen der anderen Person erhalten konnte).
Inaktive Konten (z. B. geschlossene oder eingefrorene Kreditkarten oder Autokredite, die zwar bewilligt, aber nie ausgezahlt wurden, weil der Kunde den Autokauf storniert hat) ziehen keine tatsächliche Zahlungsverpflichtung des Kunden nach sich (sie sind wie Geister in den Systemen der Bank, ohne dass dem Kunden jemals echtes Geld ausgehändigt wurde), und es ist daher unmöglich, dass der Kunde in Verzug gerät.
Spezielle Segmente sind solche, in denen die normalen Entscheidungsprozesse nicht gelten (z. B. Entwicklungskredite mit staatlicher Garantie – hier ist die Risikobewertung der Bank irrelevant und die einzige Frage ist, ob der Antrag die Anforderungen der Regierung erfüllt).
- Entwicklung von Variablen: Hier sollte sich der Datenwissenschaftler vor allem um zwei Probleme kümmern: fehlende Variablen und konzeptionelle Missverständnisse.
Fehlen Ihnen wichtige Prädiktoren für die Ergebnisse (insbesondere diejenigen, die von den Mitarbeitern an der Front vorgeschlagen wurden)? Wenn ja, welche Merkmale haben Sie, die mit den fehlenden Merkmalen korreliert sein könnten? Könnten sie zu Verzerrungen in den Fällen führen, in denen die korrelierten Merkmale schlechte Näherungswerte für die fehlenden Merkmale sind? Wenn ja, wie könnten Sie die fehlenden Merkmale erheben, und sei es nur für eine kleine Stichprobe? Wenn dies absolut unmöglich ist, ist es dann verantwortbar, das verzerrte Modell zu entwickeln? Wie könnte der Entscheidungsprozess angepasst werden, damit diese Verzerrung im Algorithmus keinen Schaden anrichtet?
Und sind die abgeleiteten Merkmale in allen Situationen konzeptionell einwandfrei? Wenn Sie z. B. die Minimal- und Maximalwerte der beiden Eingangsvariablen für einen zu berechnenden Quotienten in Ihrer Stichprobe auswerten, könnten Sie über negative Werte stolpern, die eine von Ihnen berechnete Verhältniszahl zunichte machen können. Verhältnisse sind ein gutes Beispiel für scheinbar einfache Aggregationen, die viele Fallen haben. Betrachten wir zur Veranschaulichung eine Standardkennzahl, die zur Bewertung der Gesundheit von Unternehmen verwendet wird: der Verschuldungsgrad, der üblicherweise als Gesamtverschuldung geteilt durch das Eigenkapital definiert wird. Normalerweise ist ein kleinerer Wert sicherer ($10/$100 ist 0,10 und steht für eine geringere Verschuldung als $50/100=0,50); im Gegensatz dazu ist aber $10000.000/$100 Mio. ebenfalls 0,10, weil es sich hier einfach um ein größeres Unternehmen handelt, das aber relativ gesehen die gleiche Menge an Schulden pro Eigenkapitaleinheit hat wie das kleinere Unternehmen – Quoten werden gerade deshalb verwendet, weil sie die Struktur messen, aber die Größenordnung ignorieren). Einige angeschlagene Unternehmen haben jedoch ein negatives Eigenkapital – je höher die Überschuldung, desto größer die Probleme, aber desto geringer das Verhältnis von Schulden zu Eigenkapital (das sich bei einer unendlich hoher Überschuldung dem Wert –∞ nähert). Darüber hinaus sind viele Kreditanalysten der Ansicht, dass die Nettoverschuldung ein besserer Maßstab für die Verschuldung ist, wobei von der Gesamtverschuldung alle Barmittel und bargeldähnlichen Vermögenswerte (z. B. Staatsanleihen) abgezogen werden. Wenn ein Unternehmen über mehr Barmittel als Schulden verfügt, kann die Nettoverschuldung auch einen negativen Wert annehmen. Dividiert man eine negative Nettoverschuldung durch ein positives Eigenkapital (ein extrem gesundes Unternehmen), so ergibt sich ebenfalls ein negativer Wert für die Kennzahl – eine Kennzahl von −0,5 könnte also entweder für ein sehr schlechtes Unternehmen (viele Schulden und negatives Eigenkapital) oder für ein sehr sicheres Unternehmen stehen. Und wenn die Stichprobe vom letzteren Typ dominiert wird, könnte das Modell leicht ein positives Vorurteil gegenüber Unternehmen mit einem negativen Nettoverschuldungsgrad aufweisen und einige sehr riskante Unternehmen enthusiastisch genehmigen, was zu großen Verlusten für die Bank führt. Um dieses Problem zu lösen, müssen Sie alle verschiedenen Kombinationen von positiven, negativen oder Nullwerten für Nenner und Zähler getrennt behandeln. Fortgeschrittene Techniken des maschinellen Lernens sind in der Regel recht gut in dieser Hinsicht, aber wenn solche Fälle selten sind, können unsinnige Behandlungen immer noch durchrutschen. Alternativ muss der Datenwissenschaftler ein komplexes neues Merkmal erstellen, das die verschiedenen Wertebereiche von Nenner und Zähler sorgfältig auf einen kontinuierlichen Risikoindex abbildet (d. h., der negative Schulden und positives Eigenkapital in den sichersten Bereich, normale Wertebereiche in die Mitte und Unternehmen mit positiven Schulden, aber negativem Eigenkapital in den riskantesten Bereich einordnet usw.).
Reduktion von Variablen: Sobald Sie eine erste Auswahl an Merkmalen für das Modell erstellt haben, sollten Sie sich noch einmal an die Frontlinie wenden, um Feedback darüber einzuholen, ob eines der Merkmale eine Verzerrung verursachen könnte (z. B. könnten Sie glauben, dass die Marke eines Luxusrucksacks ein großartiges Vorhersagemerkmal für positive Ergebnisse ist, aber ein Marsmensch könnte Ihnen sagen, dass dies Marsmenschen diskriminieren würde, weil die meisten Marsmenschen keine Rucksäcke tragen, weil sie glauben, dass sie von der zeta-retikulanischen Polizei beim Passieren von Zug- und U-Bahn-Stationen häufig durchsucht werden, wenn sie einen Rucksack bei sich tragen). Oft besteht die Möglichkeit, problematische Merkmale gegen weniger problematische, aber hoch korrelierte auszutauschen. Die Hauptkomponentenanalyse ist ein großartiges Instrument, um die Suche nach Alternativen zu erleichtern, und dieser Arbeitsschritt ist der ideale Zeitpunkt für diese Diskussion, da eine kürzere Liste von Merkmalen eine eingehendere Diskussion ermöglicht (im Gegensatz zur anfänglichen Datenerfassung, die Tausende von Variablen umfassen kann), man aber immer noch alle Freiheitsgrade hat, um Variablen zu ersetzen.
Modellschätzung: Hier sollten Sie die Hyperparameter sorgfältig prüfen, um eine Überanpassung – die Quelle schädlicher Modellartefakte – zu vermeiden.
Feinjustierung des Modells: Jetzt ist es an der Zeit, die gesamte Palette der in Kap. 15 besprochenen Analysen durchzuführen, um Verzerrungen im Prototypen des Modells aufzudecken. Ich lege meinen Datenwissenschaftlern auch immer nahe, alle Merkmale im endgültigen Modell visuell zu überprüfen, indem sie das Merkmal gegen (gleitende oder Kategorie-Durchschnitte von) Log-Odds-Ratios (für binäre Ergebnisse) oder die kontinuierliche abhängige Variable (zumindest die ersten 10–20 Merkmale, wenn die Anzahl groß ist) plotten – dies ist ein großartiges Werkzeug, um Probleme in der Merkmalsentwicklung zu identifizieren. Darüber hinaus können Sie die Modellvorhersagen für einige repräsentative Fälle (echte oder künstlich erzeugte) simulieren, bei denen Sie eine Verzerrung des Algorithmus vermuten. Ich fand es zum Beispiel sehr interessant, als ein Vorstandsmitglied einer taiwanesischen Bank, für die ich tätig war, mich darauf ansprach, ob das neue Modell Unternehmensgründer ungerechtfertigt benachteiligen könnte. Er führte das Beispiel eines Schönheitschirurgen an, der über umfangreiche Berufserfahrung in den USA verfügte, aber eine neue Klinik in Taiwan eröffnete und sich an die Bank wandte, um eine Finanzierung zu erhalten. Wir erstellten einen hypothetischen Antrag für einen Schönheitschirurgen und waren erfreut zu sehen, dass das Modell ihn genehmigte, wenn auch mit einer erhöhten Risikoeinschätzung, die unserer Meinung nach die mit einem neuen Unternehmen verbundenen Risiken angemessen widerspiegelte.
Kalibrierung: Hier sollten Sie Ihre Aufmerksamkeit auf zwei Aspekte richten: Stabilitätsverzerrungen und Teilsegmente mit geringer Vorhersagekraft. Um Stabilitätsverzerrungen zu vermeiden, sollten Sie erörtern, wie sich die Zukunft systematisch vom Stichprobenzeitraum unterscheiden könnte und wie sich die zentrale Tendenz (z. B. die durchschnittliche Ausfallrate eines Kreditportfolios) in der Zukunft entwickeln könnte. Und um algorithmische Verzerrungen gegenüber Teilsegmenten zu vermeiden, in denen das Modell eine schlechte Vorhersagekraft hat, sollten Sie entscheiden, in welchen Fällen Sie als Modellergebnis „weiß nicht“ ausgeben möchten, anstatt Schätzungen abzugeben, die ein Schuss ins Blaue sind.
Modelldokumentation: Diese Aufgabe ist bei den meisten Datenwissenschaftlern sehr unbeliebt; manchmal wird sie sogar übersprungen, wenn es keine strenge Governance gibt. Ein Teil der Herausforderung könnte darin bestehen, dass das Schreiben von Dutzenden von Textseiten eine andere Fähigkeit ist als das Modellieren und daher für Datenwissenschaftler oft weder einfach noch angenehm ist. Grundlegender ist jedoch, dass dies oft als geringer „Mehrwert“ und ausschließlich zum Nutzen anderer wahrgenommen wird, nicht zuletzt der formalen Validierer (die ebenfalls eher unbeliebt sind). Das ist sehr schade, denn wenn sie angemessen gestaltet ist, kann die Modelldokumentation ein großartiges Werkzeug für Datenwissenschaftler sein, um bessere Modelle zu erstellen und Verzerrungen zu vermeiden! Damit die Modelldokumentation dieses Ziel erreichen kann, muss sie zwei Anforderungen erfüllen: Sie muss ein Format haben, das hilfreiche Überlegungen auslöst, und sie muss fortlaufend während der Modellentwicklung geschrieben werden, wenn Erkenntnisse, die sich beim Schreiben der Dokumentation ergeben, noch eine Anpassung des letzten Arbeitsschritts auslösen können (Überlegungen des Datenwissenschaftlers zur Stichprobenziehung sind eher nutzlos, wenn das Modell einmal gebaut ist). Eine gute Möglichkeit, dies zu erreichen, besteht darin, die Modelldokumentation in einem Frage&Antwort-Format zu strukturieren; sie wird im Grunde zu einer aufgezeichneten Diskussion zwischen dem Datenwissenschaftler und einem fiktiven Freund. In Tab. 18-1 finden Sie ein Beispiel für ein Inhaltsverzeichnis einer solchen Modelldokumentation.
Beispiel eines Inhaltsverzeichnisses für eine Modelldokumentation im Frage&Antwort-Format
Abschnitt | Frage |
|---|---|
1. | Modelldesign |
1.1 | Welches Geschäftsproblem wird mit dem Modell angegangen? |
1.2.1 | Welche Quellen von Fachwissen/Erfahrung wurden angezapft, um potenzielle Einflussfaktoren auf die Ergebnisse zu ermitteln? |
1.2.2 | Was erwarten wir a priori (d. h. bevor wir irgendwelche Analysen dazu durchführen) als Hauptfaktoren für die Ergebnisse? |
1.3.1 | In welchen Situationen soll das Modell angewendet werden? |
1.3.2 | Wann wird das Modell nicht angewendet (Ausnahmen)? |
1.3.3 | Wie wird der Prozess der Anwendung des Modells aussehen? Wie könnte sich dieser Prozess auf die Funktionsweise des Modells auswirken? |
1.4.1 | Welches Ergebnis sagt das Modell voraus? |
1.4.2 | Welche Verzerrungen sind in den für die Modellentwicklung verwendeten historischen Daten vorhanden (oder könnten vorhanden sein)? |
1.4.3 | Was wurde getan, um Modellierungsdaten ohne solche Verzerrungen zu erhalten? |
1.4.4 | Welche verbleibenden Verzerrungen sind in den Daten noch zu erwarten? Welche Nutzungsbeschränkungen für den Algorithmus ergeben sich daraus? |
1.5. | Wie sieht die Gesamtstruktur des Modells aus? |
2. | Datenaufbereitung |
2.1.1 | Welche Ziele, Probleme und Beschränkungen wurden bei der Definition der Stichprobe berücksichtigt? |
2.1.2 | Welche Stichprobe wurde für die Modellentwicklung verwendet (z. B. Beschreibung der erfassten Zeiträume, des Stichprobenumfangs und jeglicher Stratifizierung oder Zufallsstichprobe)? |
2.2 | Welche Probleme und Einschränkungen wurden bei der Datenerhebung erwartet bzw. sind aufgetreten? Wie wurde mit diesen umgegangen? |
2.3 | Wie wurde die Stichprobe in Entwicklungs-, Test- und Validierungsstichprobe aufgeteilt? Welche Überlegungen führten zu dieser Aufteilung? |
2.4.1 | Welche Probleme mit der Datenqualität waren von vornherein zu erwarten? |
2.4.2 | Was wurde getan, um Probleme mit der Datenqualität zu erkennen? |
2.4.3 | Welche Probleme mit der Datenqualität wurden festgestellt, und wie wurden sie gelöst? |
2.5.1 | Welche a priori Erkenntnisse oder Hypothesen über das Modellierungsproblem haben sich auf die Datenaggregationsstrategie ausgewirkt? |
2.5.2 | Wie wurden die Daten aggregiert? |
2.5.3 | Welche Verzerrungen könnten durch die Art und Weise, wie die Daten aggregiert wurden, entstanden sein (unabhängig davon, ob solche Verzerrungen später festgestellt wurden oder nicht)? |
3. | Modellzusammenbau |
3.1 | Welche Datensätze sollten auf konzeptioneller Ebene ausgeschlossen werden und warum? Wie wurde jeder Ausschluss durchgeführt (insbesondere im Hinblick auf die Identifizierung der relevanten Datensätze)? |
3.2.1 | Welche Merkmale, von denen Sie a priori erwartet hatten, dass sie die Ergebnisse beeinflussen, fehlten in den Daten? Welche Proxies haben Sie verwendet? |
3.2.2 | Welche Gestaltungsprinzipien lagen der Entwicklung der Prädiktoren (features) zugrunde (z. B. im Hinblick auf die Normalisierung)? |
3.2.3 | Welche Merkmale wurden kodiert? Welche potenziellen Merkmale wurden weggelassen und warum? |
3.3.1 | Wie wurden die Prädiktoren reduziert? |
3.3.2 | Welche Merkmale wurden für die Modellschätzung in die engere Wahl gezogen? |
3.4.1 | Welche Modellierungstechnik(en) haben Sie in Betracht gezogen, und welche haben Sie gewählt? |
3.4.2 | Wie haben Sie die Hyperparameter für die gewählte(n) Modellierungstechnik(en) festgelegt? |
3.5.1 | Welche Ergebnisse haben die Tests der ersten Version des Modells in Bezug auf Stabilität und Verzerrungen erbracht? |
3.5.2 | Wie hat sich das Modell während der Feinjustierung entwickelt? |
3.6.1 | Welche Überlegungen lagen Ihrem Kalibrierungsansatz zugrunde? |
3.6.2 | Welche Annahmen und welchen Ansatz haben Sie für die Kalibrierung gewählt? |
3.6.3 | Für welche Teilsegmente müssen die Modellergebnisse in irgendeiner Form qualifiziert werden (z. B. Ersetzen von Schätzungen durch „weiß nicht“)? |
4. | Implementierung des Modells |
4.1 | Welche Probleme könnten bei der Modellimplementierung auftreten, die zu einer Verzerrung der Modellergebnisse führen? |
4.2 | Welche Vorschriften möchten Sie für die Modellimplementierung machen, um sicherzustellen, dass das Modell ordnungsgemäß funktioniert und nur in Situationen angewendet wird, in denen es sicher und kompetent ist? |
4.3 | Welches Testprogramm empfehlen Sie, um sicherzustellen, dass das Modell korrekt implementiert wird? |
4.4 | Welche Verzerrungen könnten bei der fortlaufenden Nutzung des Modells im Laufe der Zeit auftreten? |
4.5 | Welches laufende Überwachungssystem empfehlen Sie, um solche Verzerrungen und andere Leistungsprobleme zu erkennen? |
4.6 | Welche Maßnahmen müssen ergriffen werden (z. B. regelmäßige randomisierte Experimente), um sicherzustellen, dass unverzerrte Daten zur Überprüfung und Verfeinerung des Modells in der Zukunft zur Verfügung stehen? |
Schritt 4: Modellvalidierung
Eine bewährte Praxis zur Eindämmung von Voreingenommenheit bei wichtigen Entscheidungen, die durch menschliches Urteilsvermögen getroffen werden, besteht darin, jemanden zu benennen, der den ausdrücklichen Auftrag hat, den Entscheidungsträger in Frage zu stellen – eine Rolle, die manchmal als Advocatus Diaboli („Anwalt des Teufels“) bezeichnet wird. Sogar mittelalterliche Könige beschäftigten einen speziellen Mitarbeiter, der sie herausforderte und neue Informationen lieferte, die sie bei ihren Überlegungen möglicherweise übersehen hatten: den Hofnarren. In der modernen Modellsteuerung wird die Rolle des Herausforderers, der die Solidität eines Algorithmus sicherstellen soll, oft durch eine Funktion formalisiert, die als Modellvalidierung bezeichnet wird. Leider ist die fröhliche Natur des mittelalterlichen Narren irgendwo verloren gegangen, zum großen Nachteil einer effektiven Validierung.
Nach allem, was wir darüber gelernt haben, dass selbst Datenwissenschaftler voreingenommen sind (ich bin da keine Ausnahme – ich neige dazu, überall eine Voreingenommenheit zu sehen, selbst dort, wo vielleicht nur ein zufälliger Fehler gemacht wurde!), und angesichts der vielfältigen Möglichkeiten, wie sich böse kleine Vorurteile in einen Algorithmus einschleichen können, sollte es keinen Zweifel am Wert und an der Bedeutung einer unabhängigen Überprüfung eines Algorithmus geben – und in der Tat habe ich zahlreiche Fälle erlebt, in denen die Modellvalidierung kritische Mängel aufgedeckt hat.
Leider ist die Modellvalidierung in vielen Unternehmen – insbesondere in Finanzinstituten, wo die Modellvalidierung oft gesetzlich vorgeschrieben ist und mit besonderem Eifer betrieben wird – zu einem zweischneidigen Schwert geworden, wenn nicht sogar zu einer regelrechten Dysfunktion. Übereifrige Validierungsfunktionen können es fast unmöglich machen, einen neuen Algorithmus zuzulassen.
Ich habe zum Beispiel einmal mit einer Bank zusammengearbeitet, bei der jahrelang kein einziges neues Modell die Validierung bestand. Eines der Haupthindernisse bestand darin, dass das Validierungsteam bei der Neuerstellung eines Modells von Grund auf (indem es den ganzen Weg zurückging, um die Daten aus den Quellsystemen zu extrahieren – an sich eine sehr gründliche und wertvolle Übung angesichts der Gefahren für Verzerrungen in der Datentechnik, die wir erörtert haben), verlangte, dass die Modellkoeffizienten vollkommen identisch waren (vielleicht wurden die Koeffizienten für 8 oder 10 Stellen hinter dem Komma verglichen). Infolgedessen würde selbst die kleinste Unregelmäßigkeit in den Daten – vielleicht eine einzige Zahl unter Tausenden von Fällen, in denen ein kleiner Tippfehler gemacht wurde – ein Modell zum Scheitern bringen.
Wenn die Modellvalidierung übermäßig streng ist, kann sie echten Schaden anrichten. Zum einen kann es passieren, dass ein minderwertiges Modell nicht durch ein neues, besseres Modell ersetzt wird, weil die Bedenken überzogen sind. Darüber hinaus habe ich beobachtet, dass sich das Verhalten von Datenwissenschaftlern in unvorteilhafter Weise ändert, wenn sie zu viel Angst davor haben, dass ihre Modelle bei der Validierung versagen. Sie können zögern, innovative Wege auszuprobieren, weil sie glauben, dass es am einfachsten ist, ein Modell validieren zu lassen, indem sie darauf hinweisen, dass der Ansatz mit einem anderen, bereits validierten Modell identisch ist; sie können auch versuchen, Schwächen in den Daten oder anderswo im Modell zu verbergen.
Ein Teil des Grundes ist das wenig hilfreiche Konstrukt der Rolle des Validierers – noch nie hat eine Bank ihr Wachstum oder ihre Rentabilität darauf zurückgeführt, dass ihre Modellvalidierer großartige neue Modelle absegneten, aber mehr als einmal wurden die Validierer dafür verantwortlich gemacht, wenn ein Modell nicht funktionierte oder eine Aufsichtsbehörde Bedenken gegen ein Modell äußerte. Das Ergebnis ist eine Kultur, in der die Validierer ein asymmetrisches Interesse daran haben, selbst auf die kleinsten Probleme hinzuweisen und ihre Zustimmung zu verweigern, selbst wenn nur die geringsten Bedenken auftauchen.
Anstelle eines binären Ergebnisses (Genehmigung oder Ablehnung eines Modells) sollte das Ergebnis der Modellvalidierung eine Quantifizierung des Modellrisikos sein (z. B. unter Verwendung eines einfachen Ampelsystems wie grün/gelb/rot oder vielleicht 4–5 Stufen).
Eine Einstufung, die nicht grün oder rot ist (d. h. wenn ein Modell einige nicht lebensbedrohliche Probleme oder Einschränkungen aufweist), sollte immer mit der Formulierung angemessener Nutzungsbeschränkungen einhergehen (was die Überwachung bestimmter Kennzahlen und die Anforderung beinhalten kann, ein Modell auszusetzen, wenn bestimmte Schwellenwerte überschritten werden, oder eine Begrenzung der finanziellen Nachteile, wie z. B. eine maximale Kreditsumme, die durch einen wackeligen Kreditwürdigkeitsalgorithmus genehmigt werden kann).
Das Bewertungssystem für Validierer sollte mehrere Kriterien umfassen, die ein gesundes Gleichgewicht zwischen Risikoerkennung, Risikovermeidung und Risikobereitschaft herstellen. Beispielsweise könnte eine Balanced Scorecard (die für jede Dimension etwa fünf verschiedene Leistungsniveaus greifbar macht) den Einfallsreichtum des Validierers bei der Ermittlung der Grenzen eines Modells, das Ausmaß, in dem die auferlegten Modellbeschränkungen dem ermittelten Modellrisiko angemessen erscheinen, und die Effektivität des Validierers bei der Ermöglichung von Innovationen ohne unangemessene Risiken für die Institution bewerten.
Schritt 5: Modellimplementierung
Die Implementierung der prädiktiven Merkmale ist eine oft unterschätzte Herausforderung. Sehr oft werden die vielen Data-Engineering-Schritte, die erforderlich sind, um die Eingabedaten eines Algorithmus zu beschaffen, zu bereinigen, zu aggregieren und umzuwandeln, iterativ entwickelt (z. B. weil erst während der Modellfeinjustierung das fünfundzwangzigste Datenqualitätsproblem erkannt wird, das vielleicht die Korrektur einer Datenbankabfrage gleich zu Beginn der Datenextraktion erfordert). Infolgedessen kann es für einen Datenwissenschaftler äußerst schwierig sein, einen vollständigen Satz von Anweisungen zu erstellen, wenn das Modell fertig ist. Außerdem unterscheiden sich die Sprachen und Werkzeuge, die in Produktionssystemen verwendet werden (d. h. in der IT-Umgebung, in der ein Algorithmus im wirklichen Leben „lebt“), oft von denen, die ein Datenwissenschaftler während der Entwicklung verwendet. Ich empfehle daher jedem Datenwissenschaftler, so früh wie möglich eine erste Version eines Algorithmus im Produktionssystem zu implementieren (d. h. eine „Pipeline“ im Fachjargon des maschinellen Lernens zu erstellen) und bereits zu Beginn des Modelldesigns zu überlegen, welche Tools und Techniken am Ende verwendet werden sollen, um den während des Data Engineering und der Variablenentwicklung (feature engineering) entwickelten Code zu übersetzen (z. B, Skripte, die in R, Python oder SAS geschrieben wurden), um ihn in ein Produktionssystem zu überführen, das den Anforderungen der realen Nutzung gerecht wird (z. B. in puncto Reaktionsgeschwindigkeit oder dezentrale Bereitstellung – vielleicht muss der Algorithmus sogar auf mobilen Geräten eingesetzt werden). Und es versteht sich von selbst, dass nach der Implementierung strenge Tests erforderlich sind, um sicherzustellen, dass sich keine versteckten Verzerrungen eingeschlichen haben.
Die fortlaufende Generierung frischer, unverzerrter Daten zur Überprüfung und Verbesserung des Algorithmus ist am wahrscheinlichsten, wenn sie automatisiert erfolgt – z. B. wenn ein Entscheidungssystem für die Kreditvergabe automatisch eine Zufallsstichprobe von 100 Krediten pro Monat auswählt, die unabhängig von der Kreditwürdigkeit bewilligt werden (vielleicht nachdem ein paar vernünftige Filter angewandt wurden). Anstatt dies einem Wunschdenken zu überlassen, das im letzten Absatz der Modelldokumentation festgehalten wird, sollten Datenwissenschaftler es als Teil ihrer Aufgabe bei der Modellimplementierung betrachten, diese Datengenerierung zu ermöglichen. Denken Sie an ein neues Flugzeug – wenn es frisch aus der Fabrik kommt, ist es bereits mit einer „Black Box“ ausgestattet, die Daten aufzeichnet, um die Entwicklung noch besserer Technologie zu ermöglichen, falls es abstürzt.
Zusammenfassung
Investieren Sie Fachwissen und Einblicke aus dem wirklichen Leben in das, was Sie modellieren wollen, um Ihre Hypothesen darüber zu informieren, wo Verzerrungen lauern könnten und was die Ergebnisse, die Sie modellieren, beeinflussen sollte.
Geben Sie niemals der Versuchung nach, verzerrte Daten für die Modellentwicklung zu verwenden, wenn Sie wissen, dass es das Richtige wäre, neue, unverzerrte Daten von Grund auf zu generieren – auch wenn das bedeutet, dass Sie eine Frist versäumen oder sich mit einer kleinen Stichprobe und damit einer viel einfacheren Modellierungstechnik zufrieden geben müssen, als Sie sich vorgestellt hatten.
Verstehen Sie den End-to-End-Geschäftsprozess, in dem Ihr Algorithmus eingesetzt wird, und wie dieser Prozess Ihrem Algorithmus schaden könnte.
Seien Sie vorsichtig bei der Zusammenstellung einer guten Stichprobe und berücksichtigen Sie insbesondere, ob eine Stratifizierung erforderlich ist, welche Zeiträume abgedeckt werden sollen und welche Mindeststichprobengröße angestrebt werden muss.
Seien Sie ebenso paranoid, was die konzeptionelle Integrität Ihres Datenerhebungsansatzes angeht – verwenden Sie Benchmarks (z. B. erwartete Summen oder Durchschnittswerte), um zu überprüfen, dass keine Fälle versehentlich ausgelassen wurden.
Achten Sie darauf, dass Ihre Daten nicht durch unsachgemäße Aggregationsschritte ihre konzeptionelle Fundiertheit verlieren.
Irreführende Datensätze, die das Modell verfälschen könnten, sind auszuschließen.
Achten Sie darauf, dass einzelne Merkmale den Algorithmus nicht verzerren, weil sie entweder schlechte Stellvertreter für fehlende Merkmale oder konzeptionell fehlerhaft sind – vor allem, nachdem Sie eine überschaubare Anzahl von Merkmalen in die engere Wahl gezogen haben.
Legen Sie die Hyperparameter sorgfältig fest, um eine Überanpassung („overfitting“) zu vermeiden, und testen Sie die erste Version Ihres Modells gründlich auf Verzerrungen, die bei der Feinjustierung des Modells behoben werden müssen.
Überlegen Sie, welche Anpassungen bei der Modellkalibrierung notwendig sind, wie z. B. die Änderung der zentralen Tendenz, um eine Stabilitätsverzerrung auszugleichen, oder das Überschreiben der Modellprognosen für Segmente mit geringer Vorhersagekraft mit „weiß nicht“.
Verwenden Sie die Modelldokumentation systematisch als Durchsetzungsmechanismus, um alle Best-Practice-Schritte zum Kampf gegen Verzerrungen „abzuhaken“.
Schaffen Sie eine wertschöpfende Modellvalidierungsfunktion, die sich darauf konzentriert, inwieweit Modellbeschränkungen die Ergebnisse beeinträchtigen, und die Nutzungsbeschränkungen formuliert, die die Verzerrungen eines Algorithmus ausgleichen, und die motiviert ist, das richtige Gleichgewicht zwischen der Förderung von Innovation und dem Schutz des Unternehmens zu finden.
Stellen Sie bei der Implementierung sicher, dass nicht nur die Kodierung des Algorithmus und seiner Eingabemerkmale einwandfrei ist, sondern auch, dass ein Mechanismus vorhanden ist, um unverzerrte Daten für künftige Modellentwicklungen zu erzeugen.
Und im nächsten Kapitel werden wir einen Doppelklick auf das data engineering machen und noch eingehender erörtern, wie man Verzerrungen im „neuen Gold“ (für die Unprätentiösen: den Daten) aufspüren kann.