Datele care fac diferența: calitate, istoric și “sanity checks” pentru modelare
Secțiunea 1 · Lecția 3 — Datele care fac diferența: calitate, istoric și “sanity checks” pentru modelare
În lecția asta înveți cea mai importantă regulă din modelare de risc: nu există “model bun” peste date proaste.
Vei vedea ce înseamnă calitatea datelor “pe bune”, cum arată un istoric util (vs. unul “frumos în Excel, inutil în viață”), ce sanity checks sunt obligatorii înainte să antrenezi orice model, și cum folosești AI ca să accelerezi verificările (fără să inventezi sau să maschezi probleme).
0) Hook: “Garbage in, garbage out” – dar în credit doare în bani
În analytics există o expresie celebră: garbage in, garbage out.
În credit, traducerea e mai dură:
garbage in → pierderi reale.
De ce? Pentru că un model nu “știe” realitatea. El vede doar ceea ce îi dai.
Dacă îi dai istoric incomplet, etichete greșite, variabile nealiniate, perioade amestecate, valori lipsă mascate,
atunci modelul nu învață riscul — învață artefacte.
Și artefactele sunt periculoase pentru că arată convingător: scoruri, grafice, AUC, lift.
Dar când treci în producție, apare șocul:
modelul performează pe hârtie și e slab în viață.
60–80% dintr-un proiect serios de risc este muncă de date: definiții, curățare, aliniere, testare, monitoring.
🎬 Scena clasică: “Avem date, putem modela!”
Echipa: “Avem datele, sunt în DWH.”
Modeler: “Perfect. Ce înseamnă default la voi? E consistent pe ani? Avem cure window? Avem date lipsă marcate corect?”
Echipa: “E… în principiu… depinde… cred…”
Modeler: “Ok, deci nu avem date. Avem un folder.”
1) Ce înseamnă “date bune” în risc de credit
“Date bune” nu înseamnă doar “multe”. În risc, date bune înseamnă 5 lucruri:
- Definite corect: știi exact ce măsori și cum (default, expunere, status, recuperări).
- Complete suficient: lipsurile sunt înțelese și tratate (nu ascunse).
- Consistente: aceeași variabilă înseamnă același lucru în timp și în sisteme.
- Reprezentative: istoric care acoperă comportament relevant (cicluri, șocuri, segmente).
- Auditabile: poți explica de unde vine fiecare câmp și de ce e corect.
“Curat” nu e egal cu “corect”. Poți avea un dataset fără valori lipsă, dar complet greșit (ex.: lipsurile au fost umplute arbitrar).
2) Istoricul: cât îți trebuie și ce trebuie să acopere
În modelarea de risc, “cât istoric” nu se răspunde cu un număr magic, ci cu o întrebare:
istoricul acoperă suficiente situații ca modelul să învețe?
În practică, istoric util înseamnă:
- Perioade “normale” + perioade “stresate” (dacă există).
- Schimbări de politică (cut-offs, produse noi, strategii).
- Segmente cu comportamente diferite (industrii, mărimi, produse).
- O definiție stabilă de default și cure.
Dacă ai doar ani “buni”, modelul învață să fie optimist. Dacă ai doar ani “răi”, modelul poate supra-penaliza.
De aceea, în risc, vorbim mult despre representativeness și despre monitorizare continuă.
🧠 “Default” nu e doar un label – e o decizie de design
Default-ul este eticheta pe care modelul o învață. Dacă eticheta e incoerentă, totul cade.
În practică, trebuie să stabilești:
- Eveniment: ce înseamnă default (DPD 90+, insolvency, write-off etc.).
- Fereastră: pe ce orizont îl măsori (12 luni, 18 luni etc.).
- Cure: cum tratezi revenirile (când nu mai e default?).
- Multiple defaults: cum tratezi recidiva.
3) Sanity checks: pachetul minim înainte de orice model
Sanity checks sunt verificări simple care îți spun dacă datele au sens.
Nu sunt “nice to have”. Sunt “nu treci mai departe fără ele”.
| Check | Întrebare | De ce contează | Red flag tipic |
|---|---|---|---|
| Unicitate | Am un rând per entitate per dată? | Altminteri dublezi expuneri și strici ținta | aceeași expunere apare de 2–3 ori |
| Completitudine | Ce % e missing pe câmpurile cheie? | Missing poate induce bias sau poate ascunde probleme | missing mascat ca 0 / “N/A” |
| Range | Valorile sunt plauzibile? | Outliers pot fi erori sau evenimente rare | DSCR 999, LGD -20% |
| Semn & logică | Indicatorii respectă semnificația? | Semnele greșite inversează concluzii | dobânzi negative fără motiv |
| Timp | Nu am leakage (info din viitor)? | Leakage = performanță falsă, eșec în producție | folosești “status final” ca input |
| Stabilitate | Distribuțiile sunt stabile în timp? | Drift = model degradat, necesită recalibrare | salt brusc în feature |
Dacă folosești variabile care “știu viitorul” (direct sau indirect), modelul va părea genial.
În producție, devine inutil. Regula: la data deciziei, variabila exista?
🧪 Set minim de “plauzibilitate” (exemple rapide)
- PD trebuie să fie între 0 și 1 (sau 0–100%).
- LGD tipic 0–1 (poate depăși 1 în cazuri speciale de costuri, dar trebuie justificat).
- EAD nu ar trebui să fie negativ (decât dacă ai convenții speciale / semnări contabile).
- DPD nu are voie să sară înapoi în timp fără explicație (ex.: restructurare, cure rules).
- Colateral: valori lipsă vs valori zero trebuie diferențiate (zero real vs necunoscut).
4) Data lineage & definiții: “de unde vine câmpul?”
În risc, fiecare câmp important ar trebui să aibă o “fișă” scurtă: definiție, sursă, transformări, frecvență, owner.
Asta se numește data lineage (pe scurt).
Fără lineage, ajungi în situații periculoase:
- același câmp are două definiții în două sisteme;
- un ETL a fost schimbat și nimeni nu știe;
- “default” înseamnă altceva în portofoliu A decât în portofoliu B;
- valorile lipsă au fost “reparate” de un job fără documentație.
📌 Template lineage (gata de lipit)
Nume câmp:
Definiție (1–2 rânduri):
Unitate / scală:
Sursă sistem:
Tabelă / view:
Transformări (ETL):
Frecvență refresh:
Reguli pentru missing:
Reguli pentru outliers:
Owner / contact:
Note (când se schimbă):
5) Missing values: problema reală nu e “missing”, ci “de ce lipsește”
În credit, “missing” poate însemna 3 lucruri complet diferite:
- Nu există în realitate (ex.: client fără colateral).
- Există, dar nu a fost colectat (problemă de proces).
- Există, dar nu a ajuns în sistem (problemă de date/ETL).
Un model care tratează toate cele 3 ca “0” face praf realitatea.
De aceea, în practică, missing se tratează cu:
- flag-uri “is_missing” (semnal util în sine);
- imputare controlată (nu magic);
- segmente separate (ex.: cu colateral vs fără colateral);
- reguli de calitate (dacă missing e prea mare → nu modelăm / nu folosim variabila).
Missing-ul este un semnal de proces. Uneori, missing înseamnă risc mai mare (ex.: lipsă documente = lipsă transparență).
6) AI în munca de date: copilot pentru sanity, nu “make it pretty”
Aici AI-ul e foarte util, pentru că poate accelera:
- rezumarea unui profil de date (distribuții, outliers, missing);
- generarea unui checklist de validare;
- documentarea lineage (în format standard);
- generarea de reguli de test (SQL/Python) pe baza definițiilor;
- detectarea anomaliilor pe text (ex.: note de audit, justificări, “reason codes”).
Dar regula e simplă: AI nu trebuie să “repare” datele fără să înțelegi ce repară.
AI te ajută să vezi problema mai repede și să o documentezi mai bine.
🤖 Prompt pack: sanity checks + raport de calitate (gata de folosit)
„Ești data quality analyst. Îți dau un tabel cu statistici (missing%, min/max, p1/p50/p99, #distinct, count).
Scrie un raport structurat:
– 5 probleme potențiale (cu motiv),
– 5 verificări suplimentare recomandate,
– 3 riscuri de leakage de verificat,
– 3 recomandări de standardizare (naming/unități).
Regulă: nu inventa valori; lucrează doar cu ce primești.”PROMPT 2 — Reguli de test (SQL/Python) din definiții
„Îți dau definiții de câmp și reguli de plauzibilitate.
Generează un set de teste:
– range checks
– null checks
– uniqueness checks
– referential integrity (dacă e cazul)
– time consistency
Returnează pseudo-cod + exemple de query.
Regulă: indică ce presupuneri faci.”PROMPT 3 — Leakage hunt (brainstorm controlat)
„Îți dau lista de features și momentul deciziei.
Marchează potențial leakage:
– direct (variabile de outcome)
– indirect (proxy: restructurare, status final, recovery)
– time alignment risks
Returnează top 10 riscuri și cum le testezi.”
7) Mini-caz (15–25 min): dataset “curat” care minte
Ai un dataset fără missing, totul pare perfect. Modelul are performanță excelentă în training/validation.
În producție, scade brusc. Descoperi că un câmp folosit ca feature a fost calculat folosind date post-decision.
Întrebare: care sunt 5 pași practici ca să previi asta data viitoare?
Vezi răspuns-ghid
- Definești “momentul deciziei” și îl aplici ca regulă pentru toate features (time alignment).
- Construiești lineage pentru câmpurile cheie: sursă + transformări + timestamp logic.
- Rulezi leakage checks: cauți variabile care sunt outcome/proxy (status final, restructurare, recovery flags).
- Separi pipeline de training vs scoring: feature engineering identic, dar cu date disponibile la t0.
- Institui governance: review obligatoriu pe lista finală de features + audit pe schimbări ETL.
Nu “interzici” variabile. Le aliniezi corect în timp. Leakage e o problemă de timing, nu de “câmpuri rele”.
8) Mini-quiz (consolidare) — răspunsurile sunt ascunse
1) Adevărat/Fals: Dacă nu ai missing values, datele sunt de calitate.
Vezi răspuns
2) Alege 1: Cel mai periculos tip de problemă de date pentru performanță “fals bună” este:
Vezi răspuns
3) Completează: În risc, “date bune” = definite, consistente, reprezentative și ________.
Vezi răspuns
4) Adevărat/Fals: AI ar trebui folosit ca să “repare” automat outliers și missing.
Vezi răspuns
9) Output-ul lecției: Data Quality Pack (checklist + sanity)
📦 Data Quality Pack (gata de folosit în proiect)
DATA QUALITY PACK — Minim înainte de model
A) Definiții:
– Default: definiție + orizont + cure rules
– Segmente: criterii și stabilitate în timp
– Timestamp-uri: moment decizie (t0), outcome (t+), observații (t-)
B) Sanity checks (obligatorii):
– Unicitate: 1 rând per entitate per dată
– Missing: % pe câmpuri cheie + motiv (NU mascate ca 0)
– Range/Plauzibilitate: min/max/p99/p1 + reguli de business
– Leakage: listă de câmpuri interzise/monitorizate + test time alignment
– Stabilitate: distribuții în timp + semnal drift
C) Lineage:
– pentru fiecare câmp critic: sursă, ETL, owner, refresh, schimbări
D) AI (rol permis):
– rezumat profil date
– generare checklist și test cases
– documentare lineage
– semnalare anomalii / drift
Regulă: AI nu schimbă datele fără aprobarea procesului.
Dacă Data Quality Pack nu e “verde”, nu ești “încă” în faza de model. Ești în faza de a face datele adevărate.
Recap rapid (de ținut minte)
- Date bune = definite, consistente, reprezentative, auditabile.
- Sanity checks sunt obligatorii: unicitate, missing, range, timp, stabilitate.
- Leakage e cel mai periculos: îți dă performanță falsă.
- AI e copilot: detectează, structurează, documentează — nu “repară” magic.
Să te îndrăgostești de un scor AUC bun înainte să verifici dacă datele “știu viitorul”.
📝 Obiectivele lecției (bifează la final)
- Știu să definesc “date bune” în context de risc
- Pot lista sanity checks obligatorii înainte de modelare
- Pot identifica și testa riscuri de leakage
- Pot construi un template de lineage pentru câmpuri critice
- Știu rolul sănătos al AI în data quality