Leakage-sichere Evaluation
Training, Validation und finaler Test bleiben klar getrennt. Modellwahl, Tuning, Calibration und Threshold-Auswahl verwenden den Testsplit nicht vor der finalen Evaluation.
Machine Learning · Explainable AI · Evaluation · Reliability
Eigenprojekt · abgeschlossenExplainable Risk Intelligence
Explainable Risk Intelligence ist ein reproduzierbares ML-Eigenprojekt zur Analyse von Credit-Risk-Wahrscheinlichkeiten. Neben Vorhersagequalität verbindet der Explainable-AI-Ansatz (XAI) Calibration, Fehlerkosten, Explainability, Fairness, Robustness und nachvollziehbare Modellentscheidungen im Mittelpunkt.
Das Projekt ist ausdrücklich als Decision-Support- und Risk-Intelligence-Prototyp konzipiert und ist keine kommerzielle Kundenreferenz. Es trifft keine automatischen Kreditentscheidungen und erhebt weder Anspruch auf regulatorische Freigabe noch auf produktiven Bankbetrieb.
Als Engineering-Nachweis zeigt das Projekt, wie Modellqualität, Wahrscheinlichkeitskalibrierung, Entscheidungsschwellen, Explainability, Fairness, Robustness und reproduzierbare Softwareprozesse zu einem vollständigen ML-System verbunden werden.
Status
Abgeschlossen
Datensatz
30.000 Fälle
Finales Modell
HistGradientBoosting
Finaler Test
ROC-AUC 0,781
Relevanz für reale ML-Systeme
Nicht nur ein Modell trainieren, sondern Entscheidungen technisch absichern.
Kalibrierte Wahrscheinlichkeiten
Neben Ranking-Metriken wird geprüft, wie gut prognostizierte Wahrscheinlichkeiten mit beobachteten Ereignissen übereinstimmen. Calibration wird damit als eigene Systemqualität behandelt.
Entscheidungslogik statt fixer 0,5-Grenze
Der Klassifikations-Threshold wird anhand dokumentierter Fehlerkosten auf dem Validation-Set gewählt. Modellscore und fachliche Entscheidungspolitik bleiben technisch getrennt.
Explainability, Fairness und Robustness
SHAP, Permutation Importance, Subgruppen-Audits, Missingness- und Perturbationstests sowie Drift-Metriken erweitern die Bewertung über reine Modellgüte hinaus.
Problem und Datengrundlage
Risiko abschätzen, ohne Modellwahrscheinlichkeiten mit Gewissheit zu verwechseln.
Verwendet wird der öffentliche UCI-Datensatz Default of Credit Card Clients mit 30.000 Beobachtungen und einem binären Target für einen Zahlungsausfall im Folgemonat.
Die Daten werden in 18.000 Trainings-, 6.000 Validation- und 6.000 Testbeobachtungen aufgeteilt. Der finale Testsplit bleibt während Modellwahl, Hyperparameter-Tuning, Calibration und Threshold-Auswahl unangetastet.
Identifikatoren sowie Geschlecht, Alter, Bildungs- und Familienstandsmerkmale werden nicht als Modellfeatures verwendet. Demografische Felder bleiben ausschließlich für separate Fairness- und Subgruppenanalysen erhalten.
Der Datensatz ist unter CC BY 4.0 verfügbar und wird im Projekt mit dokumentierter Provenienz und SHA-256-Prüfung verarbeitet.
Finale Testevaluation
Generalisierung wird auf einem unangetasteten Testsplit gemessen.
Das finale Modell ist ein per Cross-Validation getunteter HistGradientBoostingClassifier mit anschließender Sigmoid-Calibration. Die Ergebnisse unten stammen aus der finalen Testevaluation.
ROC-AUC
0,7810
95 %-Bootstrap-CI: 0,7675–0,7956
PR-AUC
0,5593
95 %-Bootstrap-CI: 0,5322–0,5911
Recall
0,7295
bei validation-basiertem Threshold 0,17
Brier Score
0,1345
kalibrierte Testwahrscheinlichkeiten
Weitere Testmetriken
- Log Loss
- 0,4283
- Accuracy
- 0,6718
- Precision
- 0,3755
- Recall
- 0,7295
- F1
- 0,4958
Confusion Matrix
- True Negative
- 3.063
- False Positive
- 1.610
- False Negative
- 359
- True Positive
- 968
Modellvergleich und Calibration
Nicht das komplexeste Modell, sondern die belastbarste Pipeline gewinnt.
| Modell | Validation PR-AUC |
|---|---|
| Tuned HistGradientBoosting | 0,557 |
| HistGradientBoosting | 0,555 |
| Random Forest | 0,545 |
| Logistic Regression | 0,500 |
| Dummy Baseline | 0,221 |
Die anschließende Sigmoid-Calibration verbesserte auf dem Validation-Set den Brier Score von 0,13413 auf 0,13390 und die Average Precision von 0,55683 auf 0,56023.
Threshold und Fehlerkosten
Der Entscheidungsschwellenwert wird nicht blind auf 0,5 gesetzt.
Die Auswahl des Thresholds erfolgt ausschließlich auf dem Validation-Set. Als exemplarische Kostenannahme wird ein False Negative fünfmal höher gewichtet als ein False Positive.
False Positive
Kosten 1
False Negative
Kosten 5
Policy-Threshold
0,17
Diese Kostenannahme dient ausschließlich dazu, die technische Auswahl eines Schwellenwertes nachvollziehbar zu demonstrieren. Sie ist keine reale Kreditvergaberichtlinie.
Engineering-Ansatz
Vom Rohdatensatz bis zum auditierbaren Modellresultat.
-
01
Datenaufnahme und Provenienz
Der offizielle UCI-Datensatz wird reproduzierbar bezogen, per SHA-256 geprüft, gegen ein definiertes Schema validiert und mit dokumentierter Datenherkunft verarbeitet.
Implementiert -
02
Leakage-sicheres Evaluation Design
30.000 Beobachtungen werden reproduzierbar und stratifiziert in 18.000 Trainings-, 6.000 Validation- und 6.000 Testfälle getrennt. Modellwahl, Tuning, Calibration und Threshold-Auswahl bleiben vom finalen Testset getrennt.
Implementiert -
03
Baseline, Modellvergleich und Tuning
Dummy-, Logistic-Regression-, Random-Forest- und HistGradientBoosting-Modelle werden verglichen. Das finale Gradient-Boosting-Modell wird per Cross-Validation ausschließlich auf Trainingsdaten getunt.
Implementiert -
04
Calibration und Threshold Policy
Vorhersagewahrscheinlichkeiten werden kalibriert. Ein exemplarischer Entscheidungsschwellenwert wird ausschließlich auf dem Validation-Set anhand dokumentierter False-Positive- und False-Negative-Kosten ausgewählt.
Implementiert -
05
Explainability und Fehleranalyse
Permutation Importance und SHAP liefern globale Einblicke. Lokale Erklärungen, False-Positive-/False-Negative-Analysen und threshold-nahe Fälle machen Modellverhalten und Fehlerbilder nachvollziehbar.
Implementiert -
06
Fairness, Robustness und Monitoring
Demografische Merkmale werden ausschließlich für Subgruppen-Audits verwendet. Missingness-, Perturbations-, Input-Validation-, PSI- und KS-Checks ergänzen die technische Risikoanalyse.
Implementiert -
07
Reproduzierbarkeit und Engineering Quality
CLI, Makefile, exakte Dependency-Locks, automatisierte Tests, Ruff, maschinenlesbare Ergebnisartefakte, GitHub Actions, Package-Builds und Fresh-Clone-Checks machen den vollständigen Workflow reproduzierbar.
Implementiert
Explainability
Globale Muster und einzelne Vorhersagen werden getrennt untersucht.
Die globale Analyse kombiniert Permutation Importance und SHAP. Zu den stärksten Signalen gehören aktuelle und historische Zahlungsverzögerungen sowie abgeleitete Merkmale zur Kreditnutzung und zum Verhältnis von Zahlung und Rechnung.
Permutation Importance
- 1. PAY_0
- 2. max_payment_delay
- 3. delayed_month_count
- 4. credit_utilization
- 5. payment_to_bill_ratio
SHAP
- 1. max_payment_delay
- 2. PAY_0
- 3. credit_utilization
- 4. avg_payment_amount
- 5. LIMIT_BAL
Ergänzend werden lokale Erklärungen für einen hohen, einen niedrigen und einen threshold-nahen Risikofall erzeugt. Feature Attribution wird dabei ausdrücklich nicht als Kausalitätsnachweis interpretiert.
Fairness Audit
Gruppenunterschiede werden gemessen – nicht wegdefiniert.
Geschlecht und Altersgruppen werden ausschließlich als Auditmerkmale betrachtet und nicht als Eingaben des finalen Modells verwendet. Die resultierenden Gap-Metriken sind deskriptiv und stellen weder einen Fairness-Nachweis noch eine regulatorische Bewertung dar.
| Attribut | Demographic Parity | Equal Opportunity | Equalized Odds |
|---|---|---|---|
| Geschlecht | 0,0263 | 0,0363 | 0,0363 |
| Altersgruppen | 0,0672 | 0,0458 | 0,0666 |
Robustness und Monitoring
Nicht nur der Idealzustand wird getestet.
Bei fünf Prozent künstlich fehlenden Featurewerten sank die PR-AUC um 0,0152 und der Brier Score verschlechterte sich um 0,00246.
Eine plausible Feature-Perturbation verursachte im Mittel eine absolute Wahrscheinlichkeitsänderung von 0,00285. Unzulässige Eingaben wie ein negativer Kreditrahmen werden durch Input Validation abgewiesen.
PSI- und KS-Auswertungen sowie ein synthetisch verschobener Datensatz demonstrieren, wie Verteilungsänderungen später überwacht werden könnten. Dieser Teil ist ausdrücklich ein Monitoring-Demonstrator und kein Nachweis eines produktiven Monitoring-Systems.
Technischer Stack
Klassisches Machine Learning als Engineering-System.
- Python
- scikit-learn
- HistGradientBoosting
- Pandas
- NumPy
- SHAP
- Permutation Importance
- Probability Calibration
- Fairness Audit
- Robustness Testing
- pytest
- Ruff
- GitHub Actions
- Package Build
- Wheel Smoke Testing
Engineering Quality
Ergebnisse müssen reproduzierbar und automatisch prüfbar sein.
- 44 automatisierte Tests erfolgreich
- Ruff Check und Ruff Format Check erfolgreich
- Exakte Dependency-Locks für Python 3.11 und 3.13
- Non-editable Installation und Import aus site-packages geprüft
- Vollständige Pipeline reproduzierbar über Makefile und CLI
- Package-Build und isolierter Wheel-Smoke-Test erfolgreich
- Fresh-Clone-Reproduzierbarkeit geprüft
- Maschinenlesbare JSON-/CSV-Ergebnisse und automatischer README-Abgleich
- Model Card, Data Card und Responsible-Use-Dokumentation
- GitHub Actions erfolgreich auf Python 3.11 und 3.13
- Öffentlicher Release v1.0.0 veröffentlicht
Reproduzierbarkeit
Vom Datenbezug bis zum Report über dokumentierte Commands.
make install
make quality
make test
make reproduceDie vollständige Reproduktion umfasst Datenprüfung, Datenaufbereitung, Modelltraining, Hyperparameter-Tuning, Calibration, finale Evaluation und Reportgenerierung.
Responsible Use
Ein Modellscore ersetzt keine verantwortliche Entscheidung.
Das Projekt ist ein technischer Portfolio- und Decision-Support-Prototyp. Es wurde nicht in einem realen Kreditprozess validiert und ist weder regulatorisch freigegeben noch für automatische Kreditentscheidungen vorgesehen.
Historische Zusammenhänge im Datensatz können gesellschaftliche, institutionelle oder prozessuale Verzerrungen enthalten. Explainability- und Fairness-Metriken helfen bei der Analyse, beseitigen diese Risiken jedoch nicht automatisch.
Vor einem realen Einsatz wären unter anderem fachliche Validierung, rechtliche und regulatorische Prüfung, Datenqualitätskontrollen, Monitoring, Governance, Human Oversight und fortlaufende Modellvalidierung erforderlich.
Projektstatus
Abgeschlossen, veröffentlicht und reproduzierbar validiert.
Implementierung, Reproduktion, Tests, Reports und Dokumentation sind abgeschlossen. Das Projekt ist als Release v1.0.0 öffentlich veröffentlicht und die GitHub-Actions-CI läuft für Python 3.11 und 3.13 erfolgreich.
Der finale Portfolio-Stand umfasst 44 automatisierte Tests, exakte Dependency-Locks, non-editable Installation, Package- und Wheel-Smoke-Tests sowie Fresh-Clone-Validierung. Die Ergebnisse bleiben als technischer Portfolio- und Decision-Support-Prototyp eingeordnet und stellen keinen Nachweis für produktiven Kreditbetrieb oder regulatorische Konformität dar.