Ein erstes ehrliches Modell für ein neues Projekt: OLS oder logistische Regression, eine eingefrorene Aufteilung, ein naives Referenzmodell und eine Metrik, die sich verteidigen lässt

Die Methode zuerst am einfachsten Modell erproben

Ein einfaches Modell auf einer sauberen Aufteilung sagt Ihnen etwas Wahres über Ihre Daten, während ein leistungsstarkes Modell auf einer fehlerhaften Aufteilung nur zeigt, wie gut es den Fehler gelernt hat.

Die Reihenfolge zählt. Teams, die mit Gradient Boosting beginnen, stellen oft Wochen später fest, dass die Aufteilung ein Leak hatte oder dass die Metrik eine Frage beantwortete, die niemand gestellt hat. Ein lineares Modell ist schnell angepasst, leicht zu untersuchen und schwer zu schönen, deshalb weisen seine Fehler auf die Daten und den Aufbau hin statt auf das Tuning. Ist das Grundgerüst für OLS oder eine logistische Regression richtig, kostet ein Random Forest später eine Zeile mehr im Vergleich; ist es falsch, kann kein Modell es retten.

Ausgangsmaterial ist der Projektsteckbrief (scope document) aus dem ersten Meilenstein: die Entscheidung, die das Modell unterstützt, die Frage, die Zielvariable, zwei Metriken und eine Leitplanke dazu, was das Modell nie allein entscheiden darf. Alles Weitere leitet sich daraus ab. Das durchgehende Beispiel des Kurses, ein Kreditausfall-Score, der im Meilenstein zum Referenzmodell aufgebaut wurde, hat bereits die drei Gewohnheiten vermittelt, die weiter gelten: eine eingefrorene Aufteilung, ein naives Referenzmodell und eine Entscheidungsschwelle. Der zweite Meilenstein überträgt sie auf die eigenen Daten des Teams.

Die sechs Bausteine eines ersten ehrlichen Modells

1. Eine eingefrorene Aufteilung. Training, Validierung und ein Testdatensatz, der bis zur Abschlussabgabe versiegelt bleibt, ohne dass zwischen ihnen etwas durchsickert.
2. Ein naives Referenzmodell. Allein auf den Trainingszeilen berechnet, ignoriert es jedes Merkmal.
3. Ein gelerntes Modell. OLS für eine stetige Zielvariable, logistische Regression für eine binäre.
4. Eine begründete Metrik. Ein Satz verknüpft sie mit der Entscheidung, die im Projektsteckbrief festgehalten ist.
5. Validierungsergebnisse und Grenzen. Das Modell gegen das naive Referenzmodell, ehrlich gelesen, und wo es nicht mehr trägt.
6. Reproduzierbarkeit. Ein Befehl erzeugt jede Zahl aus einem frischen Klon des Repositorys neu.

Zurück zum Inhalt.

Die Zielvariable bestimmt das Modell, das Referenzmodell und die Metrik

Ob Sie eine lineare oder eine logistische Regression anpassen, ist keine Vorliebe: Es folgt daraus, was die Zielvariable ist, und das naive Referenzmodell und die Metrik folgen ebenfalls daraus.

Lesen Sie die Zielvariable im Projektsteckbrief ab, und der Rest ergibt sich. Für eine stetige Zielvariable, einen Betrag, eine Dauer, eine Anzahl, die groß genug ist, um sie als Größe zu behandeln, ist die gewöhnliche Kleinste-Quadrate-Schätzung (ordinary least squares, OLS) das passende Werkzeug, behandelt in kleinste Quadrate und lineare Regression. Eine binäre Zielvariable verlangt eine logistische Regression (logistic regression), angepasst per Maximum-Likelihood-Schätzung, behandelt in Maximum-Likelihood-Schätzung und logistische Regression.

Drücken Sie bei einer Regression die Metrik in der Einheit der Zielvariable aus, denn ein Entscheidungsträger kann mit „wir liegen pro Reparatur um etwa zwei Stunden daneben“ etwas anfangen, mit einem $R^2$ dagegen nicht. Bei einer binären Zielvariable hängt die Entscheidung meist an einer Wahrscheinlichkeit und an Kosten, und die Schwelle, die die erwarteten Kosten minimiert, ist Thema der Notiz zur Entscheidungsschwelle. Zielvariablen mit mehreren Klassen, einer Rangordnung oder einer starken zeitlichen Dimension folgen demselben Prinzip, aber die Modellierungsentscheidung und ihr Grund kommen vor der ersten Rechnung ins Entscheidungsprotokoll (decision log), nicht erst nach den Ergebnissen.

Zurück zum Inhalt.

Eine eingefrorene Aufteilung, die kein Leak haben kann

Teilen Sie die Daten auf, bevor Sie irgendetwas berechnen, lernen Sie jeden Vorverarbeitungsschritt nur aus den Trainingszeilen, und halten Sie die Aufteilung fest, damit niemand sie stillschweigend neu vornehmen kann.

Zuerst aufteilen, vor jedem Mittelwert, jeder Imputation, jeder Grafik, die eine Wahl beeinflusst. Drei Teile: der Trainingsdatensatz, auf dem das Modell lernt; der Validierungsdatensatz (validation set), auf dem Sie messen und entscheiden; der Testdatensatz (test set), der bis zur Abschlussabgabe verschlossen bleibt. Tragen die Zeilen ein Datum, teilen Sie nach Datum auf, damit das Modell aus der Vergangenheit lernt und an der Zukunft gemessen wird, so wie es eingesetzt wird. Erscheint derselbe Kunde, derselbe Patient oder dieselbe Maschine in mehreren Zeilen, teilen Sie nach Gruppen auf, damit diese Einheit nie auf beiden Seiten landet.

Danach wird alles, was aus Daten lernt, Imputation, Skalierung, Kodierung, Merkmalsauswahl, allein auf den Trainingszeilen angepasst. Am einfachsten garantiert man das mit einer scikit-learn-Pipeline, abgesichert durch einen Unit-Test, der zum Beispiel prüft, dass der vom Scaler gespeicherte Mittelwert der Trainingsmittelwert ist. Zum Schluss frieren Sie die Aufteilung ein: ein Hash der Rohdatei, ein einziger Seed in config.yaml und die Liste der Kennungen in jedem Teil, alles committet. Das nennt man eine eingefrorene Aufteilung (frozen split). Die Skizze unten schreibt die drei Teile einmal und passt dann eine logistische Regression an, die die Testdatei nie zu sehen bekommt.

import pandas as pd
from sklearn.compose import ColumnTransformer
from sklearn.impute import SimpleImputer
from sklearn.linear_model import LogisticRegression
from sklearn.pipeline import Pipeline, make_pipeline
from sklearn.preprocessing import OneHotEncoder, StandardScaler

# split.py, einmal ausgeführt: nach Datum aufteilen, drei Dateien schreiben, Hashes protokollieren
df = pd.read_csv("data/raw.csv", parse_dates=["decided_on"])
parts = {"train": df.decided_on < "2024-01-01",
         "valid": (df.decided_on >= "2024-01-01") & (df.decided_on < "2024-07-01"),
         "test": df.decided_on >= "2024-07-01"}
for name, mask in parts.items():
    df[mask].to_csv(f"data/{name}.csv", index=False)

# fit.py: liest nur train und valid, jede Statistik wird auf train gelernt
train, valid = pd.read_csv("data/train.csv"), pd.read_csv("data/valid.csv")
prep = ColumnTransformer([
    ("num", make_pipeline(SimpleImputer(strategy="median"), StandardScaler()), NUM),
    ("cat", OneHotEncoder(handle_unknown="ignore"), CAT),
])
model = Pipeline([("prep", prep), ("clf", LogisticRegression(max_iter=1000))])
model.fit(train[NUM + CAT], train["y"])

Zurück zum Inhalt.

Ein naives Referenzmodell und eine Metrik, die sich verteidigen lässt

Jedes Ergebnis braucht ein Referenzmodell, das überhaupt kein Merkmal verwendet, und eine Metrik, die mit Blick auf die Entscheidung gewählt wurde, sonst bedeutet eine gut aussehende Zahl womöglich nichts.

Ein naives Referenzmodell (naive baseline) betrachtet keine einzige Variable. Bei einer Regression sagt es für jede Zeile den Trainingsmittelwert der Zielvariable vorher, oder den Median, wenn die Metrik der mittlere absolute Fehler ist, denn der Median minimiert ihn. Bei einer binären Zielvariable sagt es für alle die Basisrate $\pi$ des Trainings vorher. Seine Werte sind die Zahlen, die es zu schlagen gilt, und sie sind oft schwerer zu schlagen, als es aussieht.

Ein durchgerechnetes Beispiel mit einer Basisrate von 0,20

1. Brier-Score. Das naive Referenzmodell erreicht $0.20 \times 0.80 = 0.16$, ein Modell mit einem höheren Brier-Score schneidet also schlechter ab, als einfach die Basisrate zu kennen.
2. Log-Loss. $-(0.20 \ln 0.20 + 0.80 \ln 0.80) \approx 0.500$, die Zahl, die eine logistische Regression senken muss.
3. Accuracy. Für alle mit Nein zu antworten ist in 80 % der Fälle richtig, weshalb die Accuracy (der Anteil richtiger Vorhersagen) allein ein nutzloses Modell schönt, wenn die Klassen unausgewogen sind.

Die Metrik wird dann in einem Satz begründet, der von der Entscheidung im Projektsteckbrief ausgeht, nie von der Gewohnheit. Zum Beispiel: „Wir weisen den Log-Loss aus, weil die Instandhaltungsplaner auf Grundlage einer Wahrscheinlichkeit handeln, und die erwarteten Kosten bei der gewählten Schwelle, weil ein übersehener Maschinenausfall weit mehr kostet als eine unnötige Inspektion“. Die Accuracy übersteht diesen Satz selten, wenn die Klassen unausgewogen sind. Bei einer Regression passt der RMSE, wenn große Fehler überproportional schaden, der MAE, wenn jede Fehlereinheit gleich viel kostet.

Zurück zum Inhalt.

Ergebnisse auf der Validierung, der Testdatensatz bleibt versiegelt

Stellen Sie das Modell auf dem Validierungsdatensatz dem naiven Referenzmodell gegenüber, mit einer Vorstellung von der Unsicherheit, und halten Sie den Testdatensatz für das endgültige Urteil verschlossen.

Kern der Abgabe ist eine kleine Tabelle, und jede Zahl darin schreibt der Code in eine Ergebnisdatei wie metrics.json, nie wird sie von Hand eingetippt. Mindestens zwei Zeilen, das naive Referenzmodell und das gelernte Modell, und eine Spalte für den Abstand zwischen beiden. Alles wird auf dem Validierungsdatensatz gemessen: Trainingswerte sind konstruktionsbedingt optimistisch, und Testwerte können, sobald man sie angesehen hat, nicht mehr als unverzerrtes Urteil dienen.

import numpy as np
from sklearn.metrics import brier_score_loss, log_loss

y = valid["y"].to_numpy()
p_naive = np.full(len(y), train["y"].mean())   # Basisrate des Trainings
p_model = model.predict_proba(valid[NUM + CAT])[:, 1]

def gap(i):  # Log-Loss des Modells minus Log-Loss des naiven Referenzmodells
    return log_loss(y[i], p_model[i], labels=[0, 1]) - log_loss(y[i], p_naive[i], labels=[0, 1])

rng = np.random.default_rng(SEED)              # der einzige Seed aus config.yaml
boot = [gap(rng.integers(0, len(y), len(y))) for _ in range(2000)]
print(f"Brier naiv {brier_score_loss(y, p_naive):.3f}, Modell {brier_score_loss(y, p_model):.3f}")
print(f"Abstand {gap(np.arange(len(y))):.3f}, 95-%-Intervall {np.percentile(boot, [2.5, 97.5]).round(3)}")

Das Intervall für den Abstand stammt aus einem Bootstrap der Validierungszeilen; bei mehreren zeitlich geordneten Folds erfüllt die Streuung zwischen den Folds denselben Zweck. Es beantwortet die erste Frage, die ein Leser stellen wird: Ist die Verbesserung größer als das, was das Resampling allein hervorbringen würde? Ein Abstand von $-0.045$, dessen Intervall deutlich unter null bleibt, ist ein Ergebnis; ein Abstand von $-0.004$ mit einem Intervall, das die Null einschließt, ist noch keines.

Die Koeffizienten lesen

Ein lineares Modell verdient seinen Platz auch, weil es sich lesen lässt. Bei OLS ist $\hat\beta_j$ die Änderung der vorhergesagten Zielvariable, in ihrer eigenen Einheit, wenn $x_j$ um eine Einheit steigt und die anderen Merkmale fest bleiben; standardisiert die Pipeline die Eingaben, ist die Einheit eine Standardabweichung, und der Bericht sollte das sagen. Bei einer logistischen Regression verschiebt $\beta_j$ die Log-Odds, und $e^{\beta_j}$ ist das Chancenverhältnis (Odds Ratio): Ein Koeffizient von 0,4 pro Standardabweichung multipliziert die Odds mit etwa 1,49. Zwei Vorbehalte. Korrelierte Merkmale teilen sich das Verdienst, sodass ein Vorzeichen kippen kann, wenn ein benachbartes Merkmal hinzukommt. Und ein Koeffizient beschreibt einen Zusammenhang in diesen Daten, nicht die Wirkung eines Eingriffs in das Merkmal.

Zurück zum Inhalt.

Schriftlich festgehaltene Grenzen und ein Neuaufbau mit einem Befehl

Grenzen sind konkrete Aussagen darüber, wo das Modell nicht trägt, und Reproduzierbarkeit bedeutet, dass ein anderes Team aus einem frischen Klon mit einem Befehl genau Ihre Zahlen erhält.

Grenzen sind kein Höflichkeitsabsatz. Fünf präzise Zeilen genügen, wenn jede eine Information enthält, mit der ein Entscheidungsträger etwas anfangen kann.

• Population und Zeitraum. Wen und welchen Zeitraum die Daten beschreiben, also für wen das Modell nichts aussagt.
• Die Zielvariable. Was sie schlecht misst oder auslässt.
• Ausgeschlossene Merkmale. Was aus Sorge vor Data Leakage oder aus Prinzip beiseitegelassen wurde, und was das kostet.
• Größe der Validierung. Ob sich ein Abstand von 0,01 bei dieser Zeilenzahl vom Rauschen unterscheiden lässt.
• Verbotene Verwendungen. Was das Modell nie allein entscheiden darf, übernommen aus den Leitplanken des Projektsteckbriefs.

Reproduzierbarkeit (reproducibility) ist eine Bedingung, kein Bonus: Ein anderes Team klont das Repository, führt make reproduce im Dev-Container aus und erhält dieselbe metrics.json, und die kontinuierliche Integration ist auf dem letzten Commit grün. Können die Daten nicht veröffentlicht werden, erklärt das README, wie ein Prüfer sie bekommen kann, oder das Repository liefert eine anonymisierte Stichprobe mit, mit der die Pipeline von Anfang bis Ende läuft. Ein Leser findet dann in vorhersehbarer Reihenfolge eine kurze schriftliche Notiz (Aufteilung und Data Leakage, naives Referenzmodell, Metrik, Ergebnistabelle, Grenzen), den Code und seine Tests, die Ergebnisdatei, den Projektsteckbrief, aktualisiert, falls sich das Problem verschoben hat, und das Entscheidungsprotokoll mit einem Anhang dazu, wie KI-Werkzeuge genutzt wurden.

Acht Prüfungen vor der Übergabe

1. Aufteilung. Gehashte Daten, ein einziger Seed, die Kennungen jedes Teils committet.
2. Pipeline. Kein Vorverarbeitungsschritt wird außerhalb von ihr angepasst.
3. Versiegelter Test. Eine Suche im Code zeigt, dass kein Skript dieses Schritts die Testdatei liest.
4. Naives Referenzmodell. Seine Zeile steht in der Ergebnisdatei, neben dem Modell.
5. Metrik. Begründet in einem Satz, der von der Entscheidung ausgeht.
6. Grenzen. Fünf, jede konkret genug, um danach zu handeln.
7. Frischer Klon. Der Neuaufbau läuft aus einem temporären Ordner, nicht vom Laptop des Autors.
8. Zuständigkeit. Jeder Teil hat eine namentlich benannte verantwortliche Person, die ihn erklären kann.

Zurück zum Inhalt.

Optionale Übung: den Champion-Vergleich proben

An einem öffentlichen Kreditausfall-Datensatz können Sie schon jetzt den Vergleich von Modellfamilien proben, den die Abschlussabgabe verlangen wird, ohne dass etwas auf dem Spiel steht.

Der Kurs behält die frühere, ehrgeizigere Aufgabenstellung als optionale Übung am durchgehenden Beispiel bei, den Daten UCI Default of Credit Card Clients (Yeh und Lien, 2009), vorgestellt im Projekt zum Kreditausfall-Scoring. Sie ist die Generalprobe für den Modellvergleich, den die Abschlussabgabe auf den eigenen Daten des Teams verlangt, und ein sicherer Ort, um Fehler zu machen.

• Ein Vergleichsbefehl: eine logistische L1-Regression als Referenzmodell, ein Random Forest, Gradient Boosting und ein Kernel-Modell, über drei Seeds und fünf Folds, Hyperparameter per verschachtelter Kreuzvalidierung abgestimmt, der Testdatensatz bleibt außen vor.
• Korrigierte Intervalle: Die Folds überlappen, daher ist die einfache Varianz der Fold-Werte zu klein, und die Korrektur nach Nadeau und Bengio unten vergrößert sie.
• Eine Champion-Regel, die vor den Ergebnissen geschrieben wird, abgelegt als Issue mit Zeitstempel, damit das Kriterium nicht passend zur Tabelle gewählt werden kann.
• Eine Model Card mit Fairness-Audit, das über das Entfernen der sensiblen Spalte hinausgeht: ein Proxy-Test, dann Gruppenmetriken mit Intervallen.
• Drei von Hand geschriebene Algorithmen, Gradient Boosting, Kernel Ridge und ein eindimensionaler EM-Algorithmus, jeder durch einen automatisierten Test gegen scikit-learn geprüft.

Mit $J = 15$ Messungen und Bewertungs-Folds, die ein Viertel so groß sind wie der Trainingsdatensatz, beträgt der Faktor $1/15 + 1/4$ statt $1/15$, die Varianz wird also mit 4,75 multipliziert. Das Urteil wird dann an der gepaarten Differenz zwischen einem Herausforderer und dem Referenzmodell abgelesen: Enthält ihr korrigiertes Intervall die Null, ist der Gewinn nicht belegt, und das einfachere Modell bleibt. Die Methoden hinter dieser Übung werden in Random Forests und Gradient Boosting und SHAP, Fairness, PCA und Clustering behandelt.

Zurück zum Inhalt.

Das Wichtigste in Kürze

1. Erproben Sie die Methode zuerst an einem einfachen Modell: Ein lineares Modell auf einer sauberen Aufteilung ist mehr wert als ein Boosting-Modell auf einer Aufteilung mit Leak.
2. Die Zielvariable entscheidet: OLS für eine Größe, logistische Regression für ein Ja oder Nein, und naives Referenzmodell und Metrik folgen aus derselben Wahl.
3. Teilen Sie auf, bevor Sie irgendetwas berechnen, passen Sie jeden Vorverarbeitungsschritt innerhalb einer Pipeline auf den Trainingszeilen an, und frieren Sie die Aufteilung mit einem Hash, einem Seed und den Kennungen ein.
4. Ein naives Referenzmodell, das jedes Merkmal ignoriert, ist die erste Zeile der Ergebnistabelle; bei einer Basisrate von 0,20 liegt sein Brier-Score bereits bei 0,16.
5. Begründen Sie die Metrik in einem Satz, der von der Entscheidung ausgeht, messen Sie auf der Validierung mit einem Intervall für den Abstand, und lassen Sie den Testdatensatz versiegelt.
6. Fünf konkrete Grenzen und ein Neuaufbau mit einem Befehl aus einem frischen Klon machen aus einer Zahl ein Ergebnis, dem jemand anderes vertrauen kann.

Glossar

gewöhnliche Kleinste-Quadrate-Schätzung (ordinary least squares, OLS)

Lineare Regression, deren Koeffizienten die Summe der quadrierten Residuen minimieren.

logistische Regression (logistic regression)

Modell der Wahrscheinlichkeit eines binären Ausgangs über eine lineare Funktion der Log-Odds, angepasst per Maximum-Likelihood-Schätzung.

naives Referenzmodell (naive baseline)

Eine Referenzvorhersage, die jedes Merkmal ignoriert: der Trainingsmittelwert, der Median oder die Basisrate.

Data Leakage

Information, die das Modell nutzt, obwohl sie zum Entscheidungszeitpunkt nicht verfügbar wäre oder aus den Zeilen der Evaluation stammt.

eingefrorene Aufteilung (frozen split)

Eine Aufteilung in Training, Validierung und Test, einmal festgelegt, mit Daten-Hash, Seed und Kennungen festgehalten und nie neu vorgenommen, um Ergebnisse zu verbessern.

Validierungsdatensatz (validation set)

Zeilen, mit denen Modelle gemessen und Entscheidungen getroffen werden, getrennt von den Trainingszeilen.

Testdatensatz (test set)

Zeilen, die bis zum endgültigen Urteil versiegelt bleiben und einmal verwendet werden.

Brier-Score

Mittlere quadrierte Differenz zwischen einer vorhergesagten Wahrscheinlichkeit und dem beobachteten Ausgang 0 oder 1.

Log-Loss

Mittlere negative Log-Likelihood der beobachteten Ausgänge unter den vorhergesagten Wahrscheinlichkeiten.

Chancenverhältnis (Odds Ratio)

Faktor, mit dem sich die Odds p/(1 − p) multiplizieren, wenn ein Merkmal um eine Einheit steigt; die Exponentialfunktion eines logistischen Koeffizienten.

Bootstrap

Ziehen von Zeilen mit Zurücklegen, um abzuschätzen, wie stark eine Statistik schwanken würde.

Reproduzierbarkeit (reproducibility)

Eine andere Person erhält mit demselben Code und denselben Daten mit einem einzigen Befehl dieselben Zahlen.

Projektsteckbrief (scope document)

Die schriftliche Festlegung von Entscheidung, Zielvariable, Metriken und Leitplanken, auf der ein Projekt aufbaut.

Entscheidungsprotokoll (decision log)

Datierte Einträge, die jede Wahl, die verworfene Alternative und den Beleg dafür festhalten.

Die anderen Notizen des Kurses

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

Zurück: SHAP, Fairness, PCA und ClusteringWeiter: Neuronale Netze, Drift, konforme Vorhersage

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.