Kreditrisiko-Modell

Kreditrisiko-Modell (Credit Risk Model)

Modellierungs-Intake

Wichtige Vorgabe: Die erste Antwort nach Auslösen dieses Skills muss die Modellierungsanfrage klären, bevor irgendeine Modellierung, Feature-Auswahl, Abstimmung oder Berichterstellung erfolgt. Überspringen Sie diesen Intake nicht, auch wenn der Benutzer eine allgemeine Modellierungsaufgabe stellt. Beginnen Sie mit einem präzisen Fragenblock, der jeden der folgenden Punkte abdeckt; falls der Benutzer einen Punkt bereits angegeben hat, wiederholen Sie ihn als Bestätigung und fragen Sie nur nach Korrekturen. Nehmen Sie keine Annahmen an oder schließen Sie die Modellierung ab, bis der Benutzer antwortet, es sei denn, der Benutzer fordert ausdrücklich die Fortsetzung mit den Standardeinstellungen nach Ansicht des Fragenblocks.

1. Modellierungsziel:
   • Schlechte Kunden / Hochrisiko-Antragsteller ablehnen oder einstufen.
   • Gute Kunden / Hochqualitäts-Antragsteller auswählen.
   • Risikopreis, Kreditlinie festlegen, Inkassopriorität, Betrugsprüfung oder ein anderes Ziel.
   • Modellausgabe definieren: Wahrscheinlichkeit, Score, Note, Grenzwert, Ranking oder strategische Richtlinie.
2. Modellfamilie:
   • Scorecard / WOE-Logistische Regression.
   • LightGBM.
   • XGBoost.
   • Lineare/Logistische Regression ohne Scorecard.
   • CatBoost, Random Forest, neuronales Netzwerk, Survival-/Vintage-Modell oder ein anderes Modell.
   • Mehrere Modelle für Champion-/Herausforderer-Vergleiche.
3. Y-Wert:
   • Falls der Benutzer ein klares Ziel angibt, verwenden Sie es.
   • Falls nicht, schlagen Sie Optionen basierend auf Geschäftsziel, verfügbaren Labels, Vintage, Überfälligkeitsrate, MOB-Fenster und Ablehnungs-/Ausschlusslogik vor.
   • Bestätigen Sie die Richtung des Zielwerts: 1 = schlechtes / Risikoereignis, sofern der Benutzer nichts anderes angibt.
4. Stichprobenaufteilung:
   • OOT = Standardmäßig der nächste / letzte vollständige Monat.
   • Validierung kann ein naheliegender Monat oder eine stratifizierte Zufallsstichprobe aus den Nicht-OOT-Daten sein.
   • Bestätigen Sie, ob das Training Validierung und OOT ausschließt.
   • Falls ein Feld für Institut/Kanal existiert, fragen Sie, ob neben der zeitlichen OOT auch eine instituts-/kanalspezifische OOS-Stichprobe benötigt wird.
5. Parametertuning:
   • Fragen Sie, ob nur eine Standard-Baseline, ein leichtes Tuning oder eine tiefere Hyperparametersuche durchgeführt werden soll.
   • Für Scorecards: Standardmäßig maximal 15 Modell-Features, maximal 7 Bins pro Feature, base_score = 600, odds = 0,05, pdo = 60.
   • Für LightGBM/XGBoost: Verwenden Sie übliche Start-Hyperparameter und tunen Sie erst nach der ersten Diagnose.
6. Abgeleitete Merkmale:
   • Fragen Sie, ob abgeleitete Merkmale hinzugefügt werden sollen.
   • Falls ja, fragen Sie, ob WOE-Kombinationen und Entscheidungsbaum-Kombinationen zulässig sind oder nur direkt einsetzbare Rohformeln erlaubt sind.
7. Bericht und Einschränkungen:
   • Fragen Sie, ob der Benutzer eine Berichtsvorlage hat. Falls ja, passen Sie sich an; falls nein, verwenden Sie den Standard-Kreditrisiko-Validierungsbericht.
   • Fragen Sie nur bei Unklarheit: Die Sprache des Abschlussberichts sollte der Benutzersprache folgen. Anfragen von chinesischen Benutzern erhalten chinesische Berichte und Tabellenblattnamen; englische Benutzer erhalten englische Berichte und Tabellenblattnamen.
   • Für Scorecard-Modelle: Bestätigen Sie, dass der Modellvalidierungsbericht das genaue Format der Scorecard-Modellentwicklungs-Validierungsberichtsvorlage verwendet, sofern der Benutzer nicht ausdrücklich eine andere Vorlage anfordert.
   • Fragen Sie nach Pflichtvariablen, verbotenen Variablen, Policen-Einschränkungen, Monotonie-Einschränkungen, Score-Bändern, Genehmigungsraten-Zielen oder Bereitstellungsbeschränkungen.
8. Post-Modellierungsstrategie:
   • Fragen Sie nach Abschluss der Modellvalidierung, ob der Benutzer Strategievorschläge, Grenzwerttabellen oder Richtlinienregeln benötigt.
   • Falls ja, erstellen Sie Strategiekandidaten aus Score-Bändern, Modellrisiko-Ranking und aus abgeleiteten Merkmalen mit hohem Lift.

Kern-Workflow

1. Führen Sie den obligatorischen Modellierungs-Intake durch und dokumentieren Sie die gewählten Annahmen. Falls die erste Benutzeranfrage unzureichend spezifiziert ist, stellen Sie zuerst die Intake-Fragen; springen Sie nicht direkt in Code, Datenexploration oder Modelltraining.
2. Definieren Sie die Zielvariable und den Beobachtungszeitpunkt explizit: Antragsdatum, Leistungsfenster, Schlecht-Definition, Ausschlüsse, Stichprobenquelle und Deduplizierungsschlüssel. Leiten Sie niemals ein Ziel aus Spaltennamen ab, ohne das verfügbare Datenwörterbuch, die Labels oder die Benutzeranweisungen zu überprüfen.
3. Falls der Benutzer einen früheren Modellbericht, ein Scorecard-Blatt, ein Entwicklungsablaufdiagramm oder eine Berichtsvorlage bereitstellt, verwenden Sie diese als Referenz für Benennung, Score-Bänder und Berichtsformat. Für Scorecard-Modellvalidierungsberichte ist die Scorecard-Modellentwicklungs-Validierungsberichtsvorlage das standardmäßig erforderliche Format, sofern verfügbar; passen Sie es genau an. Falls nicht bereitgestellt, verwenden Sie den Standard-Kreditrisiko-Entwicklungsworkflow und die Berichtsstruktur für Nicht-Scorecard-Berichte oder nur für Scorecard-Entwürfe.
4. Teilen Sie Stichproben vor der Feature-Auswahl:
   • Verwenden Sie genau den vom Benutzer angegebenen OOT-Monat oder Zeitrahmen.
   • Ziehen Sie die Validierung aus der verbleibenden Nicht-OOT-Stichprobe, stratifiziert nach der Zielvariablen, wenn eine Zufallsvalidierung angefordert wird.
   • Passen Sie Bins, Encoder, Skalierer, Feature-Auswahl und Modellparameter nur auf dem Training an.
   • Lassen Sie OOT für die endgültige Validierung unangetastet, nicht für die Modellauswahl.
5. Erstellen Sie eine Baseline, die zur ausgewählten Modellfamilie passt. Falls der Benutzer sagt „basierend auf der ursprünglichen Scorecard“, analysieren Sie die ursprünglichen Scorecard-Variablen und passen Sie sie erneut an oder bewerten Sie sie als gesperrte Baseline, bevor Sie Features hinzufügen.
6. Trainieren Sie die erste Modellversion mit konservativen/Standardparametern und diagnostizieren Sie dann, ob es überangepasst, unterangepasst, über die Zeit instabil, schlecht kalibriert, ohne Signal oder durch Datenqualität eingeschränkt ist.
7. Optimieren Sie basierend auf der Diagnose. Vergleichen Sie jede akzeptierte Änderung mit der Baseline und dem aktuellen Modell, zuerst mit Validierungs-KS, dann mit OOT-Stabilität, AUC, PSI, Koeffizientenrichtung, Korrelation/VIF, Kalibrierung und Bereitstellbarkeit.
8. Falls die Leistung ungewöhnlich stark ist, untersuchen Sie auf Datenlecks, bevor Sie optimieren oder abschließen.
9. Erstellen Sie einen Abschlussbericht in derselben Struktur wie ein vorhandener Vorgängerbericht. Berichten Sie sowohl über Modellentwicklung als auch Validierung, nicht nur über eine Notebook-artige Metrikausgabe.
10. Fragen Sie, ob nach der Modellvalidierung eine Strategieebene benötigt wird. Gehen Sie nicht davon aus, dass der Modellbericht allein das endgültige Geschäftsergebnis ist.

Ausgabesprache

• Passen Sie die Sprache in Enddokumenten, Arbeitsmappen, Tabellenblattnamen, Diagrammbeschriftungen und narrativen Zusammenfassungen an die des Benutzers an, es sei denn, dieser fordert ausdrücklich eine andere Sprache.
• Falls der Benutzer auf Chinesisch schreibt, erstellen Sie chinesischen Berichtstext und chinesische Tabellenblattnamen. Falls der Benutzer auf Englisch schreibt, erstellen Sie englischen Berichtstext und englische Tabellenblattnamen.
• Behalten Sie technische Bezeichner wie rohe Variablennamen, Dateinamen, SQL-Ausdrücke, Modellnamen und Metrikabkürzungen unverändert bei, wenn deren Übersetzung die Rückverfolgbarkeit verringern würde.

Daten- und Aufteilungsdisziplin

• Behandeln Sie Zeitdatenlecks als den wichtigsten Fehlermodus. Jedes Merkmal, das nach dem Antrags-/Beobachtungszeitpunkt berechnet wurde, muss ausgeschlossen oder zeitlich verschoben werden.
• Für monatliche OOT: Standardmäßig den nächsten/letzten verfügbaren vollständigen Monat verwenden, sofern der Benutzer keinen anderen Zeitrahmen angibt. Verwenden Sie in Ausgaben exakte Kalendermonate wie 2025-09, keine relativen Bezeichnungen.
• Validierung kann entweder ein naheliegender Monat/Zeitrahmen oder eine stratifizierte Zufallsstichprobe aus den Nicht-OOT-Daten sein. Bevorzugen Sie den vom Benutzer angeforderten Validierungsmodus; wählen Sie andernfalls den Modus, der am besten zur Stichprobengröße und Zeitstabilität passt, und geben Sie die Wahl an.
• Markieren Sie vor der endgültigen Aufteilung abnormale Monate mit zu wenigen Gesamtstichproben oder zu wenigen schlechten Stichproben. Melden Sie sie und den Grund; filtern Sie sie nicht automatisch heraus, es sei denn, der Benutzer stimmt ausdrücklich zu.
• Falls ein Feld für Institut/Kanal existiert, unterstützen Sie instituts-/kanalspezifische OOS zusätzlich zur zeitlichen OOT. Trennen Sie in Berichten klar zwischen zeitlicher OOT, instituts-/kanalspezifischer OOS, Validierung und Training.
• Berichten Sie Stichprobenanzahlen, Anzahl der Schlechten, Schlechtquoten, AUC, KS, PSI und Scoreverteilung für Training, Validierung und OOT.
• Falls die Validierung stratifiziert zufällig ist, berechnen Sie sie nach Entfernung von OOT.
• Behalten Sie Scores auf Zeilenebene mit row_id, Datum, Aufteilung, Zielvariable, Wahrscheinlichkeit, Logit und Score, damit jede Berichtstabelle reproduziert werden kann.

Optionale Bereinigungspipeline

Führen Sie eine leichte Datenbereinigung und Variablen-Screening-Pipeline vor der Modellierung durch, wenn die Rohdatenqualität unsicher ist, wenn der Benutzer eine Vorverarbeitung anfordert oder wenn ein Scorecard-/logistisches Modell sauberere Kandidatenvariablen benötigt. Für Gradient-Boosted-Tree-Modelle kann diese Pipeline übersprungen oder abgeschwächt werden, da Bäume fehlende Werte, Nichtlinearitäten und korrelierte Variablen besser tolerieren; führen Sie dennoch Leck-, Stichproben- und Stabilitätsprüfungen durch.

• Laden und formatieren Sie Daten, ohne die Originaldatei zu ändern.
• Markieren Sie abnormale Monate anhand der Gesamtstichprobenanzahl und der Anzahl schlechter Stichproben, entfernen Sie sie jedoch standardmäßig nicht.
• Berechnen Sie Fehl-/Wertquoten insgesamt; falls ein Institut/Kanal-Feld existiert, berechnen Sie diese auch pro Institut/Kanal.
• Entfernen Sie Variablen mit hohem Fehlanteil nur, wenn der Schwellenwert vereinbart oder eindeutig schädlich ist.
• Berechnen Sie IV insgesamt; falls ein Institut/Kanal-Feld existiert, berechnen Sie IV auch pro Institut/Kanal und kennzeichnen Sie Variablen, die in zu vielen Institutionen/Kanälen schwach sind.
• Berechnen Sie PSI monatlich; falls ein Institut/Kanal-Feld existiert, berechnen Sie monatlichen PSI auch pro Institut/Kanal und kennzeichnen Sie konzentrierte Instabilität.
• Führen Sie optional eine Null-Importanz-Entrauschung durch, um Rauschvariablen zu identifizieren, indem Sie den echten LightGBM-Gewinn mit dem Label-Permutations-Gewinn vergleichen.
• Entfernen Sie hochkorrelierte Variablen unter Verwendung des Prinzips „Behalte die beste Variable in der korrelierten Gruppe“.
• Dokumentieren Sie jede Runde der Variablenentfernung mit Schwellenwert, entfernter Variable und Entfernungsgrund.

Feature Engineering

• Beginnen Sie mit rohen Originalmerkmalen plus erforderlichen Geschäftsvariablen wie Unternehmensalter / Dauer der Unternehmensgründung, wenn der Benutzer diese anfordert.
• Überprüfen Sie die grundlegende Datenqualität:
  • Entfernen Sie Merkmale, bei denen ein Wert 95 %+ dominiert, es sei denn, dies wird geschäftlich ausdrücklich benötigt.
  • Entfernen Sie unbrauchbare, instabile, nach dem Ergebnis erstellte, doppelte oder logisch ungültige Variablen.
  • Bewahren Sie erzwungene Baseline-Variablen bei der Reproduktion einer vorhandenen Scorecard, auch wenn sie generische Filter verletzen; legen Sie diese Sperre offen.
• Berechnen Sie sowohl rohe/univariate IV als auch gebinnte Scorecard-IV nach dem Training-Set-Binning, wenn nützlich. Kennzeichnen Sie sie separat; nennen Sie rohe ungebinnte IV nicht Scorecard-IV.
• Rangieren Sie wichtige Merkmale mit einer gewichteten Kombination aus LightGBM-Importance, IV und gebinnter IV. Falls der Benutzer keine Gewichte angibt, normalisieren Sie Ränge oder Perzentil-Scores und verwenden Sie eine ausgewogene Standardeinstellung wie LightGBM-Gain 0,4, IV 0,3, gebinnte IV 0,3; behalten Sie LightGBM-Split-Anzahl als sekundäres Diagnosemittel.
• Verwenden Sie Null-Importanz als optionalen Entrauschungsschritt für große Kandidatenpools: Trainieren Sie ein echtes LightGBM-Importance-Modell, trainieren Sie ein oder mehrere Label-permutierte/Null-Modelle und kennzeichnen Sie Variablen, deren echter Gain nicht ausreichend über dem Null-Gain liegt.
• Behalten Sie den ursprünglichen Feature-Namen, die chinesische/Geschäftsbezeichnung, Formel, Elternmerkmale, Fehlrate, IV, gebinnte IV, Single-Feature-AUC/KS, LightGBM-Gain/Split, Screening-Status und Screening-Grund bei.

Abgeleitete Variablen

• Wenn der Benutzer die Verwendung von Standardeinstellungen angibt, behandeln Sie abgeleitete Variablen als aktiviert. Generieren Sie eine breite Bibliothek abgeleiteter Variablen, sofern Daten- und Bereitstellungsbeschränkungen dies zulassen:
  • Rohe Arithmetik: Differenz, Verhältnis, Kehrwert, Anteil, relative Differenz, Mittelwert, Summe, Min/Max, absolute Differenz.
  • Fenster- und Trendmerkmale: Kurzzeit-/Langzeit-Verhältnis, monatlicher Durchschnitt, monatliche Beschleunigung, Lücke zwischen aktuellen und historischen Werten.
  • Transformationen: Log, Clipping/Winsorisierung, Perzentil-Rang, Indikatoren für fehlende/spezielle Werte.
  • WOE-Kombinationen: WOE-Summe, WOE-Differenz, WOE-Produkt, WOE-Min/Max, WOE-absolute Lücke.
  • Baumkombinationen: 2- bis 3-stufige Entscheidungsbaum-Blattmerkmale oder kompakte Regel-Buckets, die aus 2-3 starken Variablen erstellt wurden.
  • Gruppeninteraktionen: Kredit, Abfrage, Nutzung, Überfälligkeit, Saldo und Unternehmensalter derselben Familie.
• Verfolgen Sie die Bereitstellbarkeit für jede abgeleitete Variable. Bevorzugen Sie einfachere Rohformeln, wenn mehrere Kandidaten ähnliche Validierungs-/OOT-Leistung haben, schließen Sie WOE-Kombinationen oder Baumkombinationen jedoch nicht standardmäßig aus.
• Lassen Sie abgeleitete Variablen standardmäßig am Screening und an der Modellauswahl teilnehmen. Erfordern Sie eine abgeleitete Variable im endgültigen Modell nur, wenn sie die Validierungs-/OOT-Leistung, Stabilität oder Interpretierbarkeit wesentlich verbessert; melden Sie andernfalls, dass abgeleitete Variablen generiert und abgelehnt wurden.
• Dokumentieren Sie abgeleitete Formeln in einer bereitstellungsbereiten Form unter Verwendung der Quellmerkmale, nicht nur generierter Anzeigenamen.
• Fügen Sie der endgültigen Ausgabe eine Prüftabelle für abgeleitete Variablen oder ein Blatt hinzu, wenn abgeleitete Variablen generiert wurden, einschließlich Formel, Elternvariablen, Bereitstellbarkeit, Screening-Status, IV und endgültigem Auswahlstatus.

Standardparameter

Verwenden Sie diese Standardeinstellungen, sofern der Benutzer keine Alternativen bereitstellt.

• Scorecard:
  • Feature-Obergrenze: maximal 15 endgültige Variablen.
  • Binning-Obergrenze: maximal 7 Bins pro Feature, einschließlich Bins für fehlende/spezielle Werte, wo möglich.
  • Score-Skala: base_score = 600, odds = 0,05, pdo = 60.
  • Feature-Screening: Entfernen Sie Variablen mit 95 %+ gleichem Wert, sofern nicht obligatorisch; entfernen Sie gebinnte IV unter 0,05, sofern nicht obligatorisch; überprüfen Sie WOE-Trend und Geschäftslogik.
  • Korrelationsschwellenwert: Kennzeichnen Sie absolute Korrelation über 0,5.
  • Multikollinearität: Verwenden Sie schrittweise logistische Regression, Vorzeichenprüfungen der Koeffizienten und VIF.
• LightGBM-Baseline:
  • Ziel: Binäre Klassifikation, sofern der Benutzer nicht Regression/Ranking gewählt hat.
  • Typische Startparameter: learning_rate 0,03-0,08, num_leaves 15-63, max_depth 3-7 oder unbegrenzt mit kleinen Blättern, min_data_in_leaf 100-1000 je nach Stichprobengröße, feature_fraction 0,7-0,9, bagging_fraction 0,7-0,9, bagging_freq 1, lambda_l1 0-5, lambda_l2 0-20, Early Stopping auf Validierung.
• XGBoost-Baseline:
  • Typische Startparameter: eta 0,03-0,08, max_depth 3-6, min_child_weight 20-200, subsample 0,7-0,9, colsample_bytree 0,7-0,9, gamma 0-5, reg_alpha 0-5, reg_lambda 1-20, Early Stopping auf Validierung.
• Lineare/Logistische Regression:
  • Standardisieren oder WOE-transformieren Sie Merkmale nach Bedarf.
  • Stimmen Sie Regularisierungsstärke und -strafe ab, nachdem Sie Koeffizientenstabilität und Validierungsleistung überprüft haben.

Binning und WOE

• Passen Sie WOE-Bins nur auf dem Training an. Wenden Sie dieselben Binkanten und den fehlenden Bin auf Validierung und OOT an.
• Verwenden Sie Entscheidungsbaum-, Quantil- und manuelle/geschäftliche Binning-Strategien. ...

(Der Inhalt wurde aus Platzgründen gekürzt, folgt aber dem gleichen Muster.)