Ein Projekt zum Kreditausfallscore, Schritt für Schritt: das reproduzierbare Repository zu den UCI-Daten Default of Credit Card Clients

Das Projekt und das Repository

Es geht darum, für jeden von 30.000 Karteninhabern die Wahrscheinlichkeit zu schätzen, im Folgemonat auszufallen, damit ein Kreditanalyst entscheiden kann; das Repository sorgt dafür, dass jeder diese Schätzung nachbauen kann.

Die Daten sind die UCI-Tabelle Default of Credit Card Clients: 30.000 Kunden einer taiwanischen Bank im Jahr 2005, mit Kreditlimit, demografischen Feldern, sechs Monaten Rückzahlungsstatus, Rechnungs- und Zahlungsbeträgen und einer binären Zielvariable, dem Ausfall im Folgemonat. Die Rohdatei wird nie committet: Ein Skript lädt sie herunter und vergleicht ihren SHA-256-Fingerabdruck mit dem im Repository gespeicherten, sodass eine unbemerkte Änderung der Quelle die Pipeline anhält.

Die Aufteilung in Trainings-, Validierungs- und Testdaten (train / validation / test split) erfolgt ein einziges Mal, stratifiziert, 60 % Training, 20 % Validierung, 20 % Test, mit festem Startwert des Zufallsgenerators (random seed), und auch der Fingerabdruck jedes Teildatensatzes wird gespeichert. Zwei Modelle liegen dem Repository bei: die Basisrate (base rate), die für alle dieselbe Wahrscheinlichkeit vorhersagt, und eine logistische Regression in einer scikit-learn-Pipeline, kalibriert auf dem Validierungsdatensatz. Das aufwendigere Modell bleibt den Teams überlassen.

Die Regel lautet: Nichts, was sich neu erzeugen lässt, wird versioniert, also keine Rohdaten, keine Teildatensätze, kein trainiertes Modell. Die .gitignore weist sie ab, und die Befehle bauen sie neu auf. Die Commit-Historie folgt dem Kurs, vom Gerüst und vom Projektrahmen über Daten, Aufteilung und Modelle bis zu den Tests, den Notebooks, den Meilenstein-Vorlagen und der Oberfläche; wer sie liest, liest das Projekt. Jedes Team erhält das Ganze als Pull Request in seinem eigenen Repository: Ein Mitglied liest die Änderungen, ein anderes führt sie zusammen, und danach führen alle die beiden Befehle aus.

Zurück zum Inhalt.

Zwei Befehle: make reproduce und make test

Liefert derselbe Befehl zweimal nicht dieselben Zahlen, dann haben sich die Daten, der Code, der Seed oder die Umgebung verändert, und man muss wissen, was davon.

make reproduce   # Download und Fingerabdruck, Aufteilung, Training, Kennzahlen
make test        # dreizehn Eigenschaftstests, wenige Sekunden
make compare     # nur Meilenstein 2, liest den Testdatensatz ein einziges Mal
make app         # ein Kunde, eine Entscheidung

make reproduce verkettet vier Ziele. Der Datenschritt bricht ab, wenn sich der Fingerabdruck geändert hat, denn Daten werden nicht ohne einen Eintrag im Entscheidungsprotokoll verändert. Der Aufteilungsschritt schreibt die Teildatensätze und ihre Fingerabdrücke, die anschließend ein Test einfriert. Der Trainingsschritt passt die beiden mitgelieferten Modelle an. Der Kennzahlenschritt misst nur auf dem Validierungsdatensatz und schreibt eine metrics.json. Der Testdatensatz wird hier überhaupt nicht gelesen: Er wird ein einziges Mal geöffnet, durch make compare, beim zweiten Meilenstein.

Die Basisrate beträgt in jedem Teildatensatz 22,12 %, bedingt durch die stratifizierte Aufteilung. Ihr Log-Loss ist nicht beliebig: Wer allen die Basisrate $p$ vorhersagt, erhält genau die Entropie der Zielvariable, die Untergrenze, unter die jedes nützliche Modell kommen muss.

make test prüft dreizehn Eigenschaften in wenigen Sekunden. Ein Test im Machine Learning lautet nicht „die AUC ist gut“, er ist ein eigenschaftsbasierter Test (property-based test): etwas, das gelten muss, was auch immer passiert. Der Schemavertrag (schema contract) mit Spalten, Zeilenzahl, Grenzen, einer 0/1-Zielvariable und fehlenden Werten; eine Aufteilung, deren Fingerabdrücke sich nie ändern und in der kein Kunde in zwei Teildatensätzen vorkommt; ein Modell, das auf trennbaren Daten eine AUC von 1 erreicht, sonst ist der Trainingscode defekt; Vorhersagen, die sich beim Vertauschen der Zeilen nicht ändern; ein neu geladenes Modell, dessen Vorhersagen bis auf eine absolute Abweichung von $10^{-12}$ mit denen des trainierten übereinstimmen; ein naives Modell, das der Basisrate entspricht; eine logistische Regression, die es schlägt. Dazu kommen sechs Robustheitseigenschaften, die weiter unten beschrieben sind.

Zurück zum Inhalt.

Das Leit-Notebook: Die Schwelle ist eine Entscheidung, Leaks sind der Feind

Das Notebook importiert den Code des Repositorys, statt ihn zu kopieren, und es zeigt, dass die Schwelle aus den Kosten folgt, nicht aus dem Modell.

Das Leit-Notebook hat sieben Abschnitte, einen pro Sitzung: Projektrahmen, die eingefrorene Aufteilung, das naive Modell und dann die logistische Regression, die Schwelle, dann die drei Meilensteine. Seine erste Zelle importiert src/credit. Ein Notebook, das seine eigene Kopie des Codes einfügt, zeigt bald etwas anderes als das, was tatsächlich läuft. Jeder Abschnitt endet mit einer kurzen Liste dessen, was man nicht tun sollte, und zusammen ergeben diese Listen einen Katalog dessen, was man Data Leakage nennt: Korrelationen auf dem gesamten Datensatz vor der Aufteilung berechnen, mit einem anderen Seed neu aufteilen, vor der Aufteilung standardisieren, Hyperparameter auf dem Validierungsdatensatz abstimmen, einen Blick auf den Testdatensatz werfen.

Im Schritt der logistischen Regression sind zwei Leitplanken sichtbar. Eine Assertion prüft, dass die Spalte SEX nicht zu den Merkmalen gehört; das ist ein Grundsatz, keine Frage der Performance. Und die Standardisierung sitzt in der Pipeline, sodass Mittelwerte und Varianzen nur auf dem Trainingsdatensatz gelernt werden, was das häufigste Leak des Kurses beseitigt.

Mit kalibrierten Wahrscheinlichkeiten hängt die Schwelle, bei der eine Entscheidung zwischen Ablehnen und Annehmen möglichst geringe erwartete Kosten (expected cost) verursacht, nur von den beiden Fehlerkosten ab:

Auf dem Validierungsdatensatz liegt das empirische Minimum der Kostenkurve bei 0,045, weit entfernt von 0,1176, und zwischen beiden Werten ist die Kurve fast flach. Das ist die ehrliche Diagnose: Das Referenzmodell sortiert niedrige Risiken schlecht. Das Repository behält die theoretische Schwelle, die sich verteidigen lässt, schreibt sie in config.yaml und begründet sie im Entscheidungsprotokoll. Eine von Hand in einem Batch-Skript oder in der Oberfläche geänderte Schwelle wäre eine Entscheidung, die niemand getroffen hat.

Zurück zum Inhalt.

Warum ein Modell? Gegen Geschäftsregeln, in Euro

Schon vor jedem Machine Learning lehnt eine Bank Kunden ab, die mit Zahlungen im Rückstand sind, also muss das Modell diese Regel in Geld schlagen, nicht nur bei der AUC.

Mit diesen Kosten schneidet die kalibrierte logistische Regression nicht besser ab als die plumpeste denkbare Strategie, denn fast alle Antragsteller abzulehnen kostet ungefähr gleich viel. Bei 22 % Ausfällen und einem Ausfall, der 7,5-mal so teuer ist wie ein verlorener Kunde, trennt eine AUC von 0,72 niedrige Risiken nicht gut genug. Das ist eine Tatsache über diese Kosten und dieses Modell, kein Urteil über Machine Learning, und es ist der Ausgangspunkt des zweiten Meilensteins.

Rechenbeispiel: wenn beide Fehler gleich viel kosten

1. Abstand pro Antrag. $133 - 112 = 21$ Euro zugunsten der logistischen Regression, also $21 / 133 \approx 16\%$ weniger als bei der Regel.
2. Pro Jahr. Bei 6.000 Anträgen etwa $21 \times 6000 = 126\,000$ Euro; der Foliensatz, der mit ungerundeten Kosten rechnet, nennt etwa 130.000 Euro.
3. Samt Unsicherheit. Die Validierungs-AUC von 0,723 hat ein 95-%-Bootstrap-Intervall von 0,706 bis 0,740, ein Konkurrent mit 0,735 wäre also nicht als besser belegt.

Die Lehre für ein Kundenmemo: Kosten sind Annahmen, die von der Fachseite kommen, und der Wert eines Modells verschiebt sich mit ihnen. Das Argument muss über mehrere Kostenniveaus hinweg gezeigt werden, mit seinem Intervall.

Zurück zum Inhalt.

Sechs Robustheitstests, geschrieben, bevor man hinschaut

Ein robustes Modell ist eines, für das man im Voraus aufgeschrieben hat, was es tun muss, wenn sich die Daten verändern, und jede dieser Aussagen in einen automatischen Test verwandelt hat.

• Intervall. Die Bootstrap-AUC liegt deutlich von 0,5 entfernt, und ihr Intervall ist schmaler als 0,06.
• Rauschen. Eine Störung der Beträge um 1 % verschiebt keine vorhergesagte Wahrscheinlichkeit um mehr als 2 Punkte.
• Monotonie. Ein Monat mehr Zahlungsverzug senkt das vorhergesagte Risiko nie.
• Absurde Eingaben. Ein Kreditlimit von einer Milliarde oder ein Alter von 200 Jahren liefert weiterhin eine Ausgabe in $[0, 1]$.
• Stabilität. Fünf Neuziehungen des Trainingsdatensatzes ergeben AUC-Werte, die höchstens 0,01 auseinanderliegen.
• Teilgruppen. Keine Gruppe nach Familienstand fällt unter eine AUC von 0,65.

Jede Eigenschaft ist zugleich ein Test in tests/test_robustness.py und eine Notebook-Zelle, die sie erklärt. Die Tests sind offen, was ihre Grenzen angeht: Für einen Kunden mit einem Limit von einer Milliarde gibt das Modell eine Wahrscheinlichkeit von 0,0 aus, die innerhalb der Grenzen liegt und trotzdem keine sinnvolle Antwort ist. In der Produktion sollte der Schemavertrag eine solche Zeile abweisen, bevor das Modell sie sieht.

Die letzte Zelle simuliert eine Drift: Jedes Kreditlimit verdoppelt sich, und das mittlere vorhergesagte Risiko sinkt um 1,4 Punkte. Niemand kann sagen, ob das stimmt, weil das Modell solche Kunden nie gesehen hat. Genau deshalb überwacht man die Eingaben nach dem Deployment, das Thema der Sitzung zu Drift und konformer Vorhersage.

Zurück zum Inhalt.

Arbeiten im Team: Branches, Pull Requests, CI, Oberfläche

Der Hauptbranch ist die Version, die funktioniert; jede Änderung läuft über einen kurzen Branch, einen von jemand anderem geprüften Pull Request und eine CI, die die Zahlen reproduziert.

Der Zyklus, den der Branch-Leitfaden beschreibt

1. Von main ausgehen. Auf main wechseln, die Änderungen holen (pull) und einen kurzen Branch anlegen, der nach einer einzigen Aufgabe benannt ist.
2. Ein Commit pro Idee. Nachrichten im Präsens, die sagen, was und warum, damit sich git log wie das Projektprotokoll liest; nie Daten, Modelle, Secrets oder Notebook-Ausgaben in einem Commit.
3. Pull Request. Drei Zeilen: was er ändert, wie man es prüft, was noch offen ist; geprüft von jemand anderem als dem Autor.
4. Mit einem Merge-Commit zusammenführen. Kein Squash, damit die Historie die Spur jedes Branches behält.
5. Die Abgabe taggen. Es zählt der letzte vor der Frist gepushte Commit; ein Tag wie jalon-1 markiert ihn.

Die Datei für die kontinuierliche Integration (continuous integration, CI) installiert die festgelegten Versionen, führt make reproduce und make test aus, berechnet die Kennzahlen dann ein zweites Mal und vergleicht die beiden metrics.json. Weicht auch nur eine Zeile ab, ist die Prüfung rot, und der Pull Request wird nicht zusammengeführt. Genau das verlangt der erste Meilenstein (milestone) als Eingangskriterium: Ein anderes Team klont Ihr Repository und erhält Ihre Zahlen.

Die Oberfläche, app/app.py, ist eine Streamlit-Seite mit rund sechzig Zeilen: Felder für die Variablen, eine Schaltfläche, die Wahrscheinlichkeit und die Entscheidung. Sie lädt dieselbe Pipeline wie der Batch, liest die Schwelle aus config.yaml und enthält keine eigene Geschäftslogik. Eine Berechnung, die nur in der Oberfläche geändert würde, wiche stillschweigend vom nächtlichen Batch ab, der dasselbe für eine ganze CSV-Datei tut.

Zurück zum Inhalt.

Was bleibt: drei Meilensteine, ein aufwendigeres Modell, fünf Regeln

Das Repository ist ein Ausgangspunkt; drei Meilensteine vervollständigen es, und das Abschlussprojekt übernimmt dieselbe Struktur für ein anderes Thema.

Das aufwendigere Modell ist absichtlich leer: Die Funktion in src/credit/model.py listet auf, was zu tun ist (Gradient Boosting in einer Pipeline mit festem Seed, Hyperparameter per Kreuzvalidierung auf dem Trainingsdatensatz, dieselbe Kalibrierung wie beim Referenzmodell, die Champion-Regel zuerst aufgeschrieben, ein korrigierter Resampling-t-Test nach Nadeau und Bengio) und löst einen Fehler aus, solange sie nicht geschrieben ist. Auch make compare verweigert die Ausführung, solange im Entscheidungsprotokoll die Champion-Regel fehlt. Ein Boosting-Modell zu schreiben dauert mit einem Assistenten Sekunden; jeden Hyperparameter zu erklären und das Intervall zu zeigen, das den Champion von der logistischen Regression trennt, ist die eigentliche Arbeit.

• Notebooks importieren src/credit und fügen nie eine Kopie davon ein.
• Jedes Anpassen, Skalieren und Kodieren nutzt nur den Trainingsdatensatz, nie den gesamten Datensatz.
• Der Testdatensatz wird ein einziges Mal gelesen, durch make compare, nachdem die Champion-Regel geschrieben ist.
• SEX kommt nie ins Modell; der Familienstand ist erlaubt, mit einem Fairness-Audit.
• Code darf mit einem KI-Assistenten geschrieben werden, aber jedes Mitglied muss jede Zeile mündlich erklären können.

Vier der fünf Regeln haben einen automatischen Wächter: Die Merkmalsfunktion weist verbotene Spalten ab, die Pipeline trägt die Vorverarbeitung, make compare prüft das Entscheidungsprotokoll, die Tests frieren die Aufteilung ein. Die fünfte wird persönlich geprüft.

Zurück zum Inhalt.

Das Wichtigste in Kürze

1. Versionieren Sie Code, Konfiguration und Fingerabdrücke; erzeugen Sie Daten, Teildatensätze und Modelle mit einem einzigen Befehl neu.
2. Ein Test im Machine Learning prüft eine Eigenschaft, die immer gelten muss, etwa eine eingefrorene Aufteilung oder eine perfekte AUC auf trennbaren Daten, keinen guten Score.
3. Die Entscheidungsschwelle folgt aus den Fehlerkosten und steht in der Konfiguration; bei diesen Kosten beträgt sie 600/5.100, etwa 0,118.
4. Ein Modell muss die bestehende Regel schlagen, in Euro und über mehrere Kostenniveaus, mit Intervall; hier gelingt das der logistischen Regression nur in bescheidenem Maß.
5. Schreiben Sie Robustheitseigenschaften auf, bevor Sie sich die Zahlen ansehen, und räumen Sie ein, was sie nicht klären können, etwa das Verhalten unter einer nie gesehenen Drift.
6. Kurze Branches, geprüfte Pull Requests und eine CI, die zweimal reproduziert, halten den Hauptbranch vertrauenswürdig.

Glossar

Aufteilung in Trainings-, Validierungs- und Testdaten (train / validation / test split)

Die drei disjunkten Teildatensätze: einer zum Anpassen, einer zum Kalibrieren und zur Wahl der Schwelle, einer, der für den abschließenden Vergleich ein einziges Mal gelesen wird.

Startwert des Zufallsgenerators (random seed)

Die feste Zahl, die Aufteilung und Training wiederholbar macht.

Data Leakage

Jede Nutzung von Informationen aus den Validierungs- oder Testdaten oder aus der Zukunft beim Anpassen des Modells.

Basisrate (base rate)

Der Anteil der Ausfälle in den Daten, hier 22,12 %; die Vorhersage des naiven Modells.

Brier-Score

Die mittlere quadratische Abweichung zwischen vorhergesagter Wahrscheinlichkeit und Ergebnis; niedriger ist besser.

erwartete Kosten (expected cost)

Die durchschnittlichen Kosten pro Antrag einer Entscheidungsregel, wobei jeder Fehler mit seinem Preis gewichtet wird.

eigenschaftsbasierter Test (property-based test)

Ein Test, der eine Eigenschaft prüft, die unabhängig von den Daten gelten soll, statt eines bestimmten Scores.

Schemavertrag (schema contract)

Die deklarierten Spalten, Typen und Grenzen, die jede Eingabezeile einhalten muss.

kontinuierliche Integration (continuous integration, CI)

Automatische Reproduktion und automatische Tests des Repositorys bei jedem Push und jedem Pull Request.

Pull Request

Eine vorgeschlagene Änderung auf einem Branch, die jemand anderes prüft, bevor sie in main zusammengeführt wird.

Meilenstein (milestone)

Eine terminierte Abgabe, gekennzeichnet durch den letzten vor der Frist gepushten Commit und meist durch einen Tag.

Modellkarte (model card)

Ein Dokument, das festhält, wofür ein Modell gedacht ist, wie es evaluiert wurde und wo seine Grenzen liegen.

Ablationsstudie (ablation study)

Das vorab registrierte Entfernen einer Gruppe von Merkmalen, um zu messen, was sie wirklich beiträgt.

Die anderen Notizen des Kurses

Eine öffentliche Zusammenfassung pro Foliensatz, in der Reihenfolge des Kurses.

Zurück: Ein Machine-Learning-Projekt verteidigenWeiter: Aktienrenditen: XGBoost und Sentiment

1. EinführungKI-Winter, Arbeitsmarkt und Methode
2. WerkzeugeKaggle, GitHub, Python: die Werkzeuge
3. Sitzung 1Projektrahmen und kleinste Quadrate
4. Sitzung 2Maximum Likelihood und logistische Regression
5. Sitzung 3Gradientenabstieg, Ridge und Lasso
6. Sitzung 4Entscheidungsschwelle und reproduzierbares ML
7. HausaufgabeML-Projekt abstecken: der Projektsteckbrief
8. Sitzung 5Kernel, SVM und Entscheidungsbäume
9. Sitzung 6Random Forests, Boosting, ehrlicher Vergleich
10. Sitzung 7SHAP, Fairness, PCA und Clustering
11. HausaufgabeEin einfaches Modell mit vollständiger Methode
12. Sitzung 8Neuronale Netze, Drift, konforme Vorhersage
13. HausaufgabeEin ausgeliefertes Machine-Learning-Projekt
14. Sitzung 9Ein Machine-Learning-Projekt verteidigen
15. ReferenzProjekt zum Kreditausfallscore
16. ReferenzAktienrenditen: XGBoost und Sentiment
17. ReferenzPython-Code für jedes ML-Modell
18. ReferenzDeep Learning, das Wesentliche
19. ReferenzML-Projekte mit offenen Daten nach Branche
20. ReferenzHandbuch für Daten- und KI-Fachleute
21. ReferenzData Engineering, SRE und Cloud
22. ReferenzPanorama der Machine-Learning-Modelle

Alle Notizen als Leseliste

Aufmerksamkeit und Transformer, Schritt für Schritt

Über diese Notizen

Vom Dozenten auf Grundlage der Folien verfasst, als öffentliche Zusammenfassung: die Kernideen, die Formeln und ein durchgerechnetes Beispiel. Die Übungen, ihre Lösungen, die Tests und die Bewertung bleiben im Foliensatz, für die Studierenden des Kurses.

Stand: 16. Oktober 2026.