Ein Machine-Learning-Projekt abstecken, bevor Code entsteht: die Frage, die Entscheidung, die Zielvariable und ein Projektsteckbrief in sechs Zeilen

Die Frage, in einem Satz

Eine brauchbare Frage nennt eine Entscheidung, eine Art, den Erfolg zu messen, einen Geltungsbereich und die Person, die auf die Antwort hin handeln wird, alles in einem Satz.

„KI für die Logistik nutzen“ ist ein Vorhaben, keine Frage: Niemand kann sagen, ob es eingelöst wurde. Die Methode der Rahmensetzung, die der Kurs in seiner ersten Sitzung einführt (den Rahmen abstecken, bevor man modelliert), verlangt für die Problemstellung (problem statement) einen Satz mit vier Kennzeichen. Eine Entscheidung: etwas, das je nach Antwort anders gemacht wird. Ein Erfolgsmaß: woran wir erkennen, dass sich die Entscheidung verbessert hat. Ein Geltungsbereich: welche Population, welcher Ort, welcher Zeitraum. Eine verantwortliche Person: eine Rolle, die tatsächlich auf Grundlage der Vorhersage handeln wird.

Im durchgehenden Beispiel des Kurses war die verantwortliche Person ein Kreditanalyst, der Anträge prüft; im fiktiven Beispiel, das sich durch die ganze Aufgabenstellung zieht, ist es die Leitung eines Zustelldepots, die jeden Abend entscheidet, welche Kunden angerufen werden, damit die Zustellungen am nächsten Tag reibungslos laufen. Braucht die Frage zwei Sätze, verbirgt sie meist zwei Entscheidungen, und das Team sollte sich auf eine festlegen.

Zurück zum Inhalt.

Die Entscheidung und was jeder Fehler kostet

Schreiben Sie auf, wer entscheidet, welche Optionen es wirklich gibt und wann die Wahl fällt, und geben Sie dann dem unnötigen Handeln und dem versäumten Handeln einen Preis.

Die Entscheidung kommt zuerst, weil sie alles Weitere festlegt. Benennen Sie eine Rolle statt einer Person (eine Betriebsleitung, ein Kreditanalyst, ein Einkäufer, ein Disponent in der Rettungsleitstelle), die so zum Entscheidungsträger (decision owner) wird, und den Zeitpunkt, an dem diese Rolle handelt, denn dieser Zeitpunkt bestimmt, welche Informationen das Modell verwenden darf. Listen Sie dann zwei oder drei konkrete Optionen auf, die die Vorhersage in die eine oder die andere Richtung kippen kann.

Jede Entscheidung kann auf zwei Arten danebengehen: handeln, obwohl es nicht nötig war, und nicht handeln, obwohl es nötig gewesen wäre. Beides kostet fast nie dasselbe. Beide Preise aufzuschreiben, und sei es grob, erlaubt es später, eine Schwelle zu wählen, statt standardmäßig 0,5 hinzunehmen. „Verspätungen besser verstehen“ ist keine Entscheidung, denn niemand verhält sich je nach Antwort anders; ein Projekt ohne erkennbaren Entscheidungsträger endet meist als Demo, bei der nichts auf dem Spiel steht.

• Wer: eine Rolle und die Frist, bis zu der sie handelt.
• Was: die tatsächlichen Optionen, also die, die die Vorhersage ändern kann.
• Fehlalarm: die Kosten, umsonst zu handeln (ein vergeudeter Anruf, ein abgewiesener guter Kunde).
• Versäumnis: die Kosten, nicht rechtzeitig zu handeln (eine Beschwerde, ein bewilligter Kredit, der ausfällt).

Zurück zum Inhalt.

Eine datierte Zielvariable, die Data Leakage ausschließt

Die Zielvariable ist eine Spalte, die nach einer Regel zu einem bekannten Datum erfasst wird, und alles, was nach dem Zeitpunkt der Vorhersage geschieht, ist als Eingabe verboten.

Eine Zielvariable ist nicht das Phänomen selbst, sondern eine datierte Spur davon, erfasst nach einer Regel. Der Projektsteckbrief (scope document) nennt dazu vier Angaben: den genauen Namen der Spalte und wie sie berechnet wird, den Vorhersagehorizont (prediction horizon) und das Datum, an dem der wahre Wert bekannt ist. Für das Zustellbeispiel: verspätet gleich eins, wenn ein Paket nach dem zugesagten Zeitfenster ankommt, vorhergesagt am Vorabend, bekannt bei der Zustellung.

Diese Zeitangaben sind der wichtigste Schutz gegen Data Leakage. Eine Zielvariable, die schon vor der Entscheidung bekannt ist, ist verdächtig, und keine Variable, die nach dem Zeitpunkt der Vorhersage erfasst wird, darf als Eingabe dienen: im Beispiel nichts, was während der Zustelltour des nächsten Tages geschieht. Die Notiz zu Entscheidungsschwelle und reproduzierbarem ML zeigt, wie eine Leakage-Karte, Spalte für Spalte, diese Prüfung systematisch macht.

Fügen Sie einen Satz dazu an, was die Spalte nicht erfasst. Im Beispiel zählt ein abwesender Kunde als Verspätung, und eine Minute Verspätung wiegt so schwer wie ein ganzer Tag. Das ist keine Bescheidenheit: Es hält das Team davon ab, dem Entscheidungsträger mehr zu versprechen, als die Spalte tatsächlich misst.

Zurück zum Inhalt.

Eine Metrik, die die Entscheidung misst, und überprüfbare Leitplanken

Beurteilen Sie das Modell in den Einheiten, die der Entscheidungsträger liest, legen Sie fest, ab welchem Niveau es nützlich wird, und listen Sie auf, was es nie tun darf, selbst wenn es damit besser abschnitte.

Entscheidend ist die Metrik, die zeigt, ob die Entscheidung besser geworden ist: etwa erwartete Kosten (expected cost) in Euro, eingesparte Stunden, vermiedene Verspätungen bei einer gegebenen Zahl von Anrufen. Schreiben Sie auch die Nützlichkeitsschwelle (usefulness threshold) auf, das Niveau, ab dem das Modell besser ist, als nichts zu tun, oder besser als die einfache Regel, die bereits gilt. Nennen Sie dann die Modellmetrik, die sie auf dem Validierungsdatensatz widerspiegelt: Log-Loss oder Brier-Score für Wahrscheinlichkeiten, PR-AUC für eine seltene Klasse, mittlerer absoluter Fehler für eine Größe.

Eine Leitplanke (safeguard) legt fest, was das Modell niemals tun darf. Leitplanken gibt es in drei Familien: verbotene Variablen (ein geschütztes Merkmal, direkt identifizierende personenbezogene Daten), zu schützende Personen (eine Gruppe, die ein Fehler härter träfe als andere) und Data Leakage (alles, was erst nach der Entscheidung bekannt ist). Im durchgehenden Kreditbeispiel war das Geschlecht ausgeschlossen, während Familienstand und Alter geprüft wurden. Es lohnt sich nur, eine Leitplanke aufzuschreiben, wenn sie sich im Code oder in den Daten überprüfen lässt, und sie wird glaubwürdiger, wenn eine klar benannte Rolle sie unterschreibt und befugt ist, das Modell zu stoppen.

Zurück zum Inhalt.

Daten, die sich heute öffnen lassen, ein Plan mit drei Modellen und das Team

Nennen Sie eine Quelle, die sich sofort öffnen lässt, mit Lizenz, Zeitraum und Lücken, planen Sie ein naives, ein besseres und ein aufwendiges Modell, und sagen Sie, wer zum Team gehört.

Die Datenzeile lässt mehr Projekte scheitern als jede andere, weil die Teams sie zuletzt ausfüllen. Sie braucht eine Adresse, die heute funktioniert, nicht „wir fragen beim Unternehmen an“; eine Lizenz, die gelesen wurde und zu einem öffentlichen Studierendenprojekt passt; den abgedeckten Zeitraum und die Zahl der Zeilen, an der sich ablesen lässt, ob eine Aufteilung nach Datum möglich ist; und eine ehrliche Liste dessen, was fehlt: die Spalte, die man gern hätte, Lücken, bekannte Verzerrungen bei der Erhebung. Hängt der Zugang von einem Dritten ab, schreiben Sie auf, wann Sie ihn erwarten, und nennen Sie einen gleichwertigen öffentlichen Ersatz. Die Notiz zu Open-Data-Projekten listet Quellen auf und zeigt, wie man eine Lizenz schnell liest. Eine Zeile, die sich diese Woche nicht ausfüllen lässt, ist ein Grund, das Thema zu wechseln, nicht das Modell.

Der Plan, in drei Modellen

1. Naiv. Das Referenzmodell, das es zu schlagen gilt: eine historische Quote, ein Mittelwert oder die bereits verwendete Geschäftsregel.
2. Besser. Das beste vernünftige Modell, oft eine regularisierte lineare oder logistische Regression.
3. Aufwendig. Ein komplexeres Modell, etwa Gradient Boosting, das prüft, ob sich die Komplexität wirklich auszahlt.

Der Plan sagt auch, was bei jedem späteren Meilenstein vorliegen soll und wer was macht, mit drei Rollen (Daten, Modell, Review), die rotieren. Er ist keine verbindliche Zusage: Der Plan wird sich ändern, und die Versionsgeschichte der Datei wird zeigen, wie. Die Aufgabenstellung schließt die Vorlage mit Wer wir sind, in zwei Teilen. Zuerst die Team-Persona: das Unternehmen, das das Team für das Projekt verkörpert, ob eine Beratung, die für eine Bank arbeitet, die Dateneinheit innerhalb einer Bank, die Risikofunktion eines Fintechs oder die Quants eines Kreditfonds, mit seinem Kunden oder Gegenüber und der Person, die abzeichnet. Dann ein kurzes Teamprofil der realen Personen, eine Zeile pro Mitglied, vom Mitglied selbst geschrieben: Werdegang, angestrebter Beruf (ein ehrliches „weiß ich noch nicht“ ist in Ordnung), warum es diesen Schwerpunkt gewählt hat, und Interessen. Die Persona sagt allen, in wessen Namen das Team spricht; die Profile dienen dazu, Rollen zu verteilen, jeder Person Fragen nahe an ihrem künftigen Beruf zu stellen und das Projekt mit ihren Bewerbungen zu verbinden.

Zurück zum Inhalt.

Zwei ausgearbeitete Beispiele: ein Paketzustelldepot und Kreditrisiko

Ein fiktives Zustellteam zeigt eine vollständige Datei und wie zwei Fehlerpreise eine Schwelle ergeben; eine mit öffentlichen Kreditdaten ausgefüllte Datei zeigt dieselbe Vorlage an einem Finanzthema.

Die Aufgabenstellung füllt die ganze Vorlage für ein erfundenes Team mit erfundenen Zahlen aus: Lesen Sie die Form, nicht den Inhalt. Die Leitung eines Depots entscheidet jeden Abend bis zu einer festen Uhrzeit, ob ein Kunde angerufen werden soll. Ein vergeudeter Anruf wird mit 8 Euro angesetzt und eine unangekündigte Verspätung mit 25 Euro, weil sie eine Beschwerde auslöst. Die Zielvariable ist nach der Entscheidung datiert, die Metrik sind erwartete Kosten pro Abend, die Leitplanken verbieten, eine Zustellung zu verweigern und irgendwelche personenbezogenen Daten des Empfängers zu verwenden, und die Datenzeile nennt einen anonymisierten Export vergangener Touren, eine schriftliche Zugangsanfrage und einen öffentlichen Ersatz mit seiner Lizenz, dazu das fehlende Wetter, das über Datum und Gemeinde verknüpft werden soll.

In Worten, mit den Preisen des Beispiels (veranschaulichende Zahlen)

1. Zwei Preise. Ein falsch positives Ergebnis ist ein Anruf für nichts ($c_{FP} = 8$), ein falsch negatives eine übersehene Verspätung ($c_{FN} = 25$), und eine richtige Entscheidung wird als kostenlos gezählt.
2. Vergleichen. Für ein Paket mit Verspätungswahrscheinlichkeit $p$ kostet ein Anruf im Mittel $8(1-p)$ und kein Anruf $25p$, also lohnt sich der Anruf, wenn $25p > 8(1-p)$.
3. Schwelle. Das ist der Fall, sobald $p$ etwa 0,24 übersteigt, vorausgesetzt, die Wahrscheinlichkeiten sind kalibriert, weshalb die Metrikzeile auch den Log-Loss nennt.
4. Naives Referenzmodell. Bei 4 % verspäteten Paketen kostet „nie anrufen“ $0.04 \times 25 = 1$ Euro pro Paket und „alle anrufen“ etwa 7,7 Euro ($0.96 \times 8$); das Modell ist also nur nützlich, wenn es unter 1 Euro bleibt.

Kreditrisiko mit Home Credit Default Risk

Die Aufgabenstellung füllt die Vorlage auch an einem echten Datensatz aus: Home Credit Default Risk, ein Kaggle-Wettbewerb von 2018 auf Basis der Daten eines Konsumentenkreditgebers, dessen Kunden oft nur eine dünne oder gar keine Kredithistorie haben. Die Persona ist erfunden: Aurore Data Conseil, eine Datenberatung, die für die Risikoabteilung des Kreditgebers arbeitet, deren Leitung die Schwelle abzeichnet. Die Frage lautet, welche Anträge des Monats ein Kreditsachbearbeiter einer manuellen Prüfung zuleiten sollte, um Ausfälle zu senken, ohne mehr gute Kunden abzuweisen als heute.

• Vor der Abgabe prüfen Sie, dass die Frage ihre vier Kennzeichen trägt, die Entscheidung eine Rolle und beide Fehlerpreise hat, die Zielvariable einen Horizont und ein Datum, ab dem ihr Wert bekannt ist, die Metrik eine Nützlichkeitsschwelle, jede Leitplanke überprüfbar ist und die Datenzeile eine Quelle, eine Lizenz, einen Zeitraum und ihre Lücken nennt.
• Prüfen Sie, dass der Plan, die Persona und das Teamprofil geschrieben sind und die Datei auf den Hauptbranch des gemeinsamen Repositorys gepusht ist.
• Der Nachbartest: Jemand aus einem anderen Team liest die Datei ohne jede Erklärung und gibt Frage, Entscheidung, Zielvariable und Metrik in eigenen Worten wieder. Jedes Zögern bedeutet, dass diese Zeile neu geschrieben werden muss.

Zurück zum Inhalt.

Übung: ein belastbares Referenzmodell am durchgehenden Beispiel aufstellen

Mit öffentlichen Kreditdaten kann ein Team die Methode proben, die der nächste Meilenstein auf sein eigenes Projekt anwendet: ein Referenzmodell, eine Notiz, eine ehrliche Ablation.

Der zweite Teil der Aufgabenstellung ist eine empfohlene Übung am durchgehenden Kreditausfall-Beispiel (UCI Default of Credit Card Clients, Yeh und Lien, 2009). Sie probt, was der nächste Meilenstein mit den eigenen Daten des Teams verlangt. Ein Referenzmodell (baseline) ist das einfache, ehrliche Modell, das jeder Kandidat mit einem gemessenen Abstand schlagen muss. Das erste Referenzmodell ist das konstante Modell, das für jeden Kunden die Basisrate $\pi$ vorhersagt, rund 22,1 % Ausfälle; seine Werte lassen sich von Hand berechnen.

Sechs Bausteine, in der Reihenfolge, in der man sie öffnet

1. Ein erneut ausführbares Repository. Code, Tests, eine Lock-Datei, kontinuierliche Integration und ein einziger Befehl, der von der rohen CSV-Datei bis zu einer Metrikdatei führt.
2. Zwei Modelle von Hand. Kleinste Quadrate über die Normalgleichungen und über die SVD (kleinste Quadrate), logistische Regression per Gradientenabstieg (logistische Regression), jeweils mit scikit-learn verglichen, Abweichung ausgegeben.
3. Eine zweiseitige Notiz. Seite eins: Rahmen, Daten, eingefrorene Aufteilung, Leakage-Karte. Seite zwei: das Modell gegen die Konstante, Kalibrierung mit einer Zuverlässigkeitskurve, die aus den Kosten abgeleitete Schwelle und was passiert, wenn sich die Kosten um ein Fünftel verschieben.
4. Eine präregistrierte Ablation. Für die Ablationsstudie (ablation study) vorhersagen, was ohne jede Spaltengruppe verloren geht, und diese Vorhersage als Issue mit Zeitstempel ablegen, eine Präregistrierung (pre-registration); dann auf dem Validierungsdatensatz rechnen, während der Testdatensatz versiegelt bleibt, und jede Abweichung kommentieren.
5. Ein Entscheidungsprotokoll. Datierte Einträge mit der verworfenen Alternative und dem Befehl, der die Zahl belegt.
6. Ein KI-Anhang. Jede Nutzung mit ihrer Stufe, und zwei Behauptungen des Assistenten, die durch einen fehlschlagenden Test, eine Rechnung oder eine Abbildung widerlegt wurden.

Die Notiz übernimmt die Gliederung, die das Modellkomitee einer Bank liest: Ein unabhängiges Validierungsteam rechnet die Zahlen aus dem Repository nach und sucht dann nach dem Leak, der unbegründeten Schwelle, der unkalibrierten Wahrscheinlichkeit, bevor das Komitee genehmigt, unter Auflagen genehmigt oder ablehnt. Jede Zahl der Notiz muss aus der Metrikdatei stammen. Vier Fallstricke tauchen immer wieder auf: ein Scaler, der vor der Aufteilung auf die ganze CSV-Datei angepasst wurde (ein Test vergleicht seinen gespeicherten Mittelwert mit dem des Trainings-Folds), eine AUC, die auf harten Labels statt auf Wahrscheinlichkeiten berechnet wurde, Zufalls-Seeds, die über Notebooks verstreut sind, statt in einer einzigen Konfigurationsdatei zu stehen, und ein README, das nur auf dem Rechner seines Autors läuft und erst auffällt, wenn jemand anderes das Repository klont und der Anleitung folgt.

Zurück zum Inhalt.

Das Wichtigste in Kürze

1. Schreiben Sie die Frage in einem Satz, mit einer Entscheidung, einem Erfolgsmaß, einem Geltungsbereich und einer verantwortlichen Person; braucht sie zwei Sätze, wählen Sie eine Entscheidung.
2. Benennen Sie, wer entscheidet, wann und zwischen welchen Optionen, und beziffern Sie beide Fehler: umsonst handeln und nicht rechtzeitig handeln.
3. Datieren Sie die Zielvariable und den Zeitpunkt der Vorhersage: Alles, was nach diesem Zeitpunkt erfasst wird, ist Data Leakage und kann keine Eingabe sein.
4. Messen Sie die Entscheidung in den Einheiten des Entscheidungsträgers, mit einer Nützlichkeitsschwelle, und verlassen Sie sich bei einer seltenen Klasse nie allein auf die Accuracy.
5. Schreiben Sie überprüfbare Leitplanken, eine Datenquelle, die sich heute öffnen lässt, mit ihrer Lizenz und ihren Lücken, und einen Plan mit einem naiven, einem besseren und einem aufwendigen Modell.
6. Stellen Sie ein belastbares Referenzmodell auf: ein konstantes Modell, von Hand geschriebene Modelle, eine nachvollziehbare Notiz und eine Ablation, deren Vorhersagen vorab abgelegt wurden.
7. Sagen Sie, wer Sie sind: das Unternehmen, das das Team verkörpert, sein Kunde und wer abzeichnet, dann die realen Menschen dahinter.

Glossar

Projektsteckbrief (scope document)

Eine kurze Datei, die Frage, Entscheidung, Zielvariable, Metrik, Leitplanken, Daten und Plan eines Projekts festhält.

Problemstellung (problem statement)

Die Frage, die ein Projekt beantwortet, so formuliert, dass jemand auf Grundlage der Antwort handeln kann.

Entscheidungsträger (decision owner)

Die Rolle, die zu einem bekannten Zeitpunkt auf Grundlage der Vorhersage handelt.

erwartete Kosten (expected cost)

Die durchschnittlichen Kosten der mit einem Modell getroffenen Entscheidungen, wobei jeder Fehler mit seinem Preis gewichtet wird.

Nützlichkeitsschwelle (usefulness threshold)

Das Niveau, ab dem ein Modell besser ist, als nichts zu tun, oder besser als die bestehende Regel.

Vorhersagehorizont (prediction horizon)

Die Zeit zwischen dem Zeitpunkt der Vorhersage und dem vorhergesagten Ereignis.

Data Leakage

Information, die zum Entscheidungszeitpunkt nicht verfügbar ist, aber ins Modell gelangt und seine Werte aufbläht.

Leitplanke (safeguard)

Etwas, das das Modell nie tun darf, so genau formuliert, dass es sich überprüfen lässt.

Team-Persona

Das Unternehmen, das ein Projektteam für sein Projekt verkörpert, mit seinem Kunden und der Person, die abzeichnet.

Accuracy

Der Anteil richtiger Vorhersagen; irreführend, wenn eine Klasse selten ist.

Referenzmodell (baseline)

Das einfache Vergleichsmodell, das jeder Kandidat mit einem gemessenen Abstand schlagen muss.

Ablationsstudie (ablation study)

Gruppen von Eingaben werden nacheinander entfernt, um zu messen, was jede beiträgt.

Präregistrierung (pre-registration)

Vorhersagen mit Zeitstempel aufschreiben, bevor das Experiment läuft.

Die anderen Notizen des Kurses

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

Zurück: Entscheidungsschwelle und reproduzierbares MLWeiter: Kernel, SVM und Entscheidungsbäume

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.