Kaggle, GitHub und Python: die Konten, der Git-Workflow und das Repository eines Machine-Learning-Projekts

Warum das ganze Projekt in einem öffentlichen Repository lebt

Ein Projekt, das nur auf dem Laptop seines Autors läuft, beweist nichts; abgegeben wird ein öffentliches Repository, das jeder erneut ausführen kann, und es ist zugleich ein sichtbarer Nachweis Ihrer Arbeit.

Die drei Werkzeuge haben drei verschiedene Aufgaben. Kaggle ist der Trainingsplatz: bereits bereinigte Datensätze, ein gehosteter Rechner, eine Rangliste, um sich mit anderen zu messen. GitHub ist Baustelle und Schaufenster zugleich: der Code, seine vollständige Historie, die Reviews und am Ende die komplette Abgabe. Python ist die Sprache, in der alle schreiben, ganz gleich, mit welchen Vorkenntnissen sie beginnen. Alle drei sind kostenlos.

Das Abschlussprojekt wird als Adresse eines öffentlichen Repositorys abgegeben, nicht als Anhang. Dieses Repository enthält fünf Dinge: einen Projektsteckbrief (scope document), der vor jeder Codezeile geschrieben wird, lesbare Python-Module statt eines riesigen Notebooks, Batch-Skripte, die alles neu ausführen, die Präsentation (PDF und Quelle) und eine kleine Weboberfläche, in die man einen Fall eingibt und auf der das Modell antwortet. Ein Zwischenprojekt mit einem UCI-Datensatz verwendet dieselbe Struktur und dient als Vorlage.

Ein öffentliches Repository ist auch eine Zeile im Lebenslauf, die sich überprüfen lässt. GitHubs Octoverse-Bericht (Oktober 2025) zählte mehr als 180 Millionen Entwickler, 36 Millionen neue Konten allein im Jahr 2025 und rund 630 Millionen Repositorys, mit 2,6 Millionen Python-Beitragenden. Wer als Recruiter Ihr Repository öffnet, verbringt dort meist ein, zwei Minuten und sucht nach denselben Dingen wie ein anspruchsvoller Leser:

• ein README, das in wenigen Zeilen sagt, was das Projekt tut und wie man es startet;
• eine stetige Historie, deren Commit-Nachrichten erklären, warum, und nicht nur „fix“ lauten;
• eine Handvoll Tests und ein Befehl, der sie ausführt;
• ehrliche, bezifferte Ergebnisse mit Angabe der Evaluationsmethode;
• keine Zugangsdaten, keine personenbezogenen Daten, keine riesigen Binärdateien.

Zurück zum Inhalt.

Kaggle: Wettbewerbe, Metriken und die beiden Ranglisten

Ein Kaggle-Wettbewerb gibt Ihnen Trainingsdaten mit den Antworten, Testdaten ohne sie, eine Metrik und eine Rangliste; die Rangliste, die zählt, sehen Sie erst am Ende.

Kaggle wurde 2010 als Marktplatz für Vorhersagewettbewerbe gegründet und im März 2017 von Google gekauft, das gehostete Notebooks mit GPUs hinzufügte. Am 11. Oktober 2026 zeigte sein Zähler mehr als 34 Millionen Mitglieder. Jede Wettbewerbsseite hat dieselben Teile: einen Überblick (Problem, Metrik, Einreichungsformat), die Daten (train.csv mit der Zielvariable, test.csv ohne sie und eine Beispiel-Einreichung), öffentliche Notebooks, die Rangliste und die Regeln, darunter ein tägliches Limit für Einreichungen.

Titanic: Klassifikation, gemessen an der Accuracy

Der Titanic-Wettbewerb fragt, welche Passagiere überlebt haben: 891 gelabelte Passagiere zum Lernen, 418 zum Vorhersagen und eine CSV-Datei mit zwei Spalten (PassengerId,Survived) zum Einreichen. Die Metrik ist die Accuracy, der Anteil richtiger Antworten. Die von Kaggle mitgelieferte Referenzdatei, die schlicht vorhersagt, dass jede Frau überlebt, erreicht bereits 0,766; ein ehrliches Modell landet bei etwa 0,78 bis 0,80.

House Prices: Regression, gemessen am Logarithmus

House Prices verwendet den Datensatz von Dean De Cock zu Ames, Iowa (Journal of Statistics Education, 2011), der den alten Boston-Housing-Datensatz ersetzen sollte: 1.460 Häuser zum Trainieren, 1.459 zum Vorhersagen, 79 Variablen und fehlende Werte, die eine Bedeutung tragen (keine Garage, kein Pool). Die Metrik ist die Wurzel des mittleren quadratischen Fehlers zwischen den Logarithmen der vorhergesagten und der beobachteten Preise; sie misst also einen relativen Fehler.

Für diese drei Häuser beträgt die Metrik $\sqrt{(0.095^2 + 0.095^2 + 0.105^2)/3} \approx 0.099$. Zur Orientierung nennt der Foliensatz grobe Werte für den echten Wettbewerb: Den Mittelwert vorherzusagen ergibt etwa 0,40, eine saubere lineare Regression etwa 0,15, ein gut abgestimmtes Baum-Ensemble etwa 0,12. Diese Leiter aus einem naiven Referenzmodell (baseline), einem besseren und dann einem schweren Modell, verglichen auf denselben ungesehenen Daten, ist der rote Faden des ganzen Kurses.

Öffentliche und private Rangliste

Der Testdatensatz ist zweigeteilt, und daraus entstehen die öffentliche und private Rangliste (public and private leaderboard). Der öffentliche Teil wird nach jeder Einreichung bewertet; der private Teil wird erst zum Fristende aufgedeckt. Endlos auf die öffentliche Punktzahl hin zu optimieren, ist Überanpassung (Overfitting) an ein paar hundert Zeilen, und die private Rangliste bestraft sie. Der einzige Schutz ist eine interne Validierung auf Grundlage der Trainingsdaten. Beim Titanic-Wettbewerb gibt es perfekte Werte von 1,000, weil die Passagierliste öffentlich ist: Das ist Data Leakage, kein Modell, und der Kurs lehrt ab Sitzung 2, es zu erkennen.

Kaggle-Notebooks sind gehostete Jupyter-Sitzungen mit bereits eingebundenen Daten und einem wöchentlichen GPU-Kontingent; „Copy & Edit“ behält einen Link zum Original, der faire Weg, auf der Arbeit anderer aufzubauen. Kaggle Learn ergänzt vier kurze, kostenlose Kurse, insgesamt etwa sechzehn Stunden.

Zurück zum Inhalt.

Git ist nicht GitHub: das Werkzeug, die Website und zehn Wörter

Git ist ein Programm auf Ihrem Rechner, das jeden Zustand eines Projekts aufzeichnet; GitHub ist eine Website, die diese Aufzeichnungen hostet und hinzufügt, was ein Team für die Zusammenarbeit braucht.

Linus Torvalds schrieb Git im April 2005 für den Linux-Kernel, nachdem das Werkzeug, das der Kernel bis dahin nutzte, seine kostenlose Lizenz verloren hatte. Git läuft lokal, offline und ohne Konto: Es zeichnet auf, wer was wann und warum geändert hat. GitHub, 2008 gestartet und 2018 von Microsoft gekauft, hostet Git-Repositorys und fügt Pull Requests, Issues, Reviews, Webseiten und automatisierte Abläufe hinzu. GitLab, Codeberg und Bitbucket erfüllen ähnliche Aufgaben; der Kurs verwendet GitHub.

Das Problem, das Git löst, kennt jeder, der schon einmal einen Ordner geteilt hat: model_v2_final.ipynb, model_v2_final_REAL.ipynb, und niemand weiß, welche Version funktioniert oder wer die Metrik geändert hat. Mit Git gibt es eine einzige Datei und eine Liste datierter, signierter Zustände, jeder mit einer einzeiligen Nachricht, die sagt, was sich geändert hat und warum. Jeder Zustand lässt sich wieder öffnen, mit dem vorherigen vergleichen oder sauber rückgängig machen.

Stellen Sie sich den Commit-Graphen vor, mit der Zeit von links nach rechts. Der Hauptstrang main trägt die Initialisierung, dann den Projektsteckbrief, dann das Referenzmodell. Ein Entwicklungszweig (branch) trennt sich davon, um ein schwereres Modell auszuprobieren, und kehrt über einen Merge zurück, sobald ein Teamkollege den Pull Request geprüft hat. Ein Tag kann den abgegebenen Commit markieren. Die Teamregel, die daraus folgt, ist einfach: `main` muss immer funktionieren; alles Unsichere geschieht auf einem Branch.

Wählen Sie den GitHub-Benutzernamen mit Bedacht, denn er steht in jeder Projektadresse und in Ihrem Lebenslauf, und aktivieren Sie die Zwei-Faktor-Authentifizierung, mit sicher aufbewahrten Wiederherstellungscodes.

Zurück zum Inhalt.

Der tägliche Zyklus, ein Branch pro Aufgabe und Konflikte

Jeder Arbeitstag folgt denselben vier Schritten, Pull, Bearbeiten, Commit, Push, und jede Aufgabe lebt auf ihrem eigenen Branch, bis ein Teamkollege sie geprüft hat.

Ein Teammitglied legt das Repository an, öffentlich vom ersten Tag an, mit einem kurzen Namen in Kleinbuchstaben mit Bindestrichen, einem README, der Python-Vorlage für .gitignore und einer Lizenz, und lädt dann die anderen als Mitwirkende ein. Die Lizenz ist der Schritt, den viele vergessen: Ohne sie gilt für ein öffentliches Repository „alle Rechte vorbehalten“, es ist lesbar, aber nicht wiederverwendbar. MIT ist die einfachste Wahl für ein studentisches Projekt.

Die vier täglichen Schritte

1. Pull. Holen, was die Teamkollegen gepusht haben, bevor Sie irgendetwas anfassen; die meisten Anfängerprobleme beginnen mit einem vergessenen Pull.
2. Bearbeiten und prüfen. Eine Sache ändern, dann git status ausführen, um genau zu sehen, was sich bewegt hat.
3. Commit. Nur die Dateien vormerken, die zusammengehören, und eine Nachricht schreiben, die sagt, warum, nicht nur was.
4. Push. Den Commit online stellen, damit die anderen darauf aufbauen können.

git pull                      # vom neuesten Stand des Teams ausgehen
git status                    # was sich hier geändert hat
git switch -c xgboost-model   # ein Branch pro Aufgabe
git add src/project/models.py
git commit -m "XGBoost mit Early Stopping hinzufügen"
git push -u origin xgboost-model   # dann den Pull Request öffnen

Das Source-Control-Panel von VS Code, GitHub Desktop und Codespaces erledigen dieselben Schritte per Mausklick, aber mindestens eine Person pro Team sollte sich im Terminal wohlfühlen, wo die Batch-Skripte laufen.

Zu dritt bekommt jede Aufgabe ihren eigenen Branch. Nach dem Push wird der Branch zu einem Pull Request mit einer kurzen Beschreibung: was, warum, wie man es prüft. Ein Teamkollege kommentiert Zeile für Zeile, genehmigt, und der Branch wird gemergt und gelöscht. Hier lernt ein Team am meisten, denn hier einigt man sich darauf, wie guter Code und ein gutes Ergebnis aussehen. Eine Historie, in der eine einzige Person alles gepusht hat, beschreibt ein Ein-Personen-Projekt, ganz gleich, wie die Autorenliste aussieht.

Zurück zum Inhalt.

Notebooks, Zugangsdaten und große Dateien: was nicht ins Repository gehört

Ein Repository sollte enthalten, was nötig ist, um das Projekt neu aufzubauen, und nichts, was geheim, persönlich, riesig oder automatisch neu erzeugbar ist.

Ein Notebook ist eine JSON-Datei, die ihre Ausgaben neben dem Code speichert, daher ergeben zwei Läufe mit identischem Code zwei verschiedene Dateien, und Gits Diff wird unlesbar. Löschen Sie die Ausgaben vor dem Commit, lassen Sie nbstripout das automatisch erledigen oder, am besten, verlagern Sie den wichtigen Code in Module unter src/ und behalten das Notebook für die Exploration.

• Zugangsdaten: API-Schlüssel, Passwörter, .env-Dateien, das Kaggle-Token. Ein einmal gepushtes Geheimnis bleibt in der Historie, selbst wenn es im nächsten Commit gelöscht wird, und automatisierte Bots greifen solche Lecks binnen Minuten ab.
• Große Dateien: GitHub warnt ab 50 MB und lehnt Dateien über 100 MB ab. Rohdaten werden in data/README.md beschrieben und von einem Skript heruntergeladen.
• Personenbezogene Daten: Namen, E-Mail-Adressen, Kundenkennungen, niemals in einem öffentlichen Repository, nicht einmal für einen schnellen Test.
• Alles, was sich neu erzeugen lässt: die virtuelle Umgebung (virtual environment), Caches, trainierte Modelle, Notebook-Ausgaben.

Die Datei .gitignore listet die Muster auf, die Git ignorieren soll. GitHubs Python-Vorlage deckt virtuelle Umgebungen und Caches bereits ab; ein Datenprojekt ergänzt Zeilen für den Rohdatenordner, CSV-Dateien, serialisierte Modelle, Logs und Dateien mit Zugangsdaten.

Der Kaggle-Kommandozeilen-Client (pip install kaggle) zeigt am deutlichsten, warum das wichtig ist. Mit ihm kann ein Skript die Wettbewerbsdaten herunterladen und eine Datei mit einer Nachricht einreichen, ganz ähnlich wie bei einem Commit, und genau das werden die Batch-Skripte eines Projekts brauchen. Beim Anmelden wird ein Zugriffstoken in ~/.kaggle/ gespeichert. Dieses Token ist ein Passwort: Es gehört nie in ein Repository, ein geteiltes Notebook oder eine E-Mail, und wenn es durchsickert, widerrufen Sie es und melden sich neu an.

Zurück zum Inhalt.

Der Aufbau eines reproduzierbaren Projekt-Repositorys

Ein gutes Repository ist so geordnet, dass eine fremde Person das Projekt in dreißig Sekunden versteht, es in zwei Minuten ausführen kann und jeden Teil der Abgabe dort findet, wo sein Name es ankündigt.

kreditrisiko-projekt/
  README.md          # was, für wen, wie starten, Ergebnisse
  docs/scope.md      # der Projektsteckbrief
  docs/journal.md    # datierte Entscheidungen
  data/README.md     # woher die Daten stammen
  notebooks/         # Exploration, Ausgaben gelöscht
  src/project/       # data, features, models, evaluate
  batch/             # prepare, train, predict, evaluate
  app/               # die Weboberfläche
  slides/  tests/  requirements.txt  config.yaml  LICENSE

Das README wird oft anstelle von allem anderen gelesen. Vier Blöcke genügen: ein Satz dazu, was das Modell für wen vorhersagt; die etwa drei Befehle zum Ausführen, die auf einem frischen Rechner genau so funktionieren müssen, wie sie dastehen; eine Ergebnistabelle, die das naive, das bessere und das schwere Modell auf Daten vergleicht, die im Training nie zu sehen waren; die Autoren, die Lizenz und Links zu den Folien und zur Live-Oberfläche.

Der Projektsteckbrief überträgt den in der ersten Sitzung abgesteckten Rahmen in das Repository: die Entscheidung, der das Modell dient, die in einem eindeutigen Satz definierte Zielvariable, die Metrik, die diese Entscheidung misst, die Leitplanken (verbotene Variablen, geschützte Gruppen, Leaks), die Daten und ihre Herkunft sowie den Plan. Er ist eine einzige versionierte Markdown-Seite, die per Pull Request geändert wird, wann immer das Team seine Meinung ändert, sodass seine Historie zeigt, wie das Verständnis des Problems gereift ist. Wie man den Rahmen absteckt, führt die Notiz zu Projektrahmen und kleinsten Quadraten aus.

Batch-Skripte sind der Kern der Reproduzierbarkeit. Ein in falscher Reihenfolge ausgeführtes Notebook kann Ergebnisse zeigen, die sein Code nicht mehr erzeugt; ein Batch-Skript (batch script) läuft von oben nach unten, immer gleich, für jeden, auch für eine Maschine in der Nacht. Vier Skripte (aufbereiten, trainieren, vorhersagen, evaluieren) und ein Befehl, der sie verkettet, etwa make all oder ein run.sh. Jede Einstellung (Datenpfad, Seed des Zufallsgenerators, Entscheidungsschwelle, Hyperparameter) steht in config.yaml, sodass ein neues Experiment nie bedeutet, Code zu ändern. Sitzung 4 baut diese Kette an einem Kreditscoring-Fall auf; siehe Entscheidungsschwelle und reproduzierbares ML.

Issues sind die Aufgabentafel des Teams: ein nummeriertes Issue pro Aufgabe, mit einer verantwortlichen Person und einem Meilenstein, automatisch geschlossen durch eine Commit-Nachricht wie Fixes #17.

Die Weboberfläche lässt sich kostenlos aus dem Repository bereitstellen: standardmäßig über Streamlit Community Cloud, über Hugging Face Spaces mit Gradio oder über GitHub Pages für statische Seiten. Das Minimum ist ein Formular, das einen Fall entgegennimmt und eine Vorhersage mit ihrer Konfidenz zurückgibt.

Ein durchgerechnetes Beispiel dieser Struktur ist das Projekt zum Kreditausfall-Scoring, und Ideen für Themen auf Basis offener Daten sind in Machine-Learning-Projekte mit offenen Daten gesammelt.

Zurück zum Inhalt.

Python: die Bibliotheken, Ihr Ausgangspunkt und die Installation

Fünf Bibliotheken decken den ganzen Kurs ab, und ob Sie nie programmiert haben oder schon sicher programmieren, ein kurzer Weg führt Sie bis zum ersten Projektmeilenstein.

Guido van Rossum veröffentlichte Python im Februar 1991. Es wurde zur gemeinsamen Sprache der Datenwelt, weil jede wichtige Bibliothek dafür geschrieben ist und Anfänger es lesen können. Der Kurs braucht fünf: pandas für Tabellen, NumPy für Vektoren und Matrizen, scikit-learn für Modelle, Validierung und Pipelines, Matplotlib (mit Seaborn als Aufsatz) für Abbildungen und XGBoost für das schwere Modell auf Tabellendaten. Der Code jedes Modells im Kurs ist in Python-Code für Machine-Learning-Modelle gesammelt.

Drei Ausgangspunkte

1. Nie programmiert. Beginnen Sie mit kurzen Python-Lektionen im Browser anhand von Finanzfällen (Variablen, Schleifen, Funktionen, dann pandas), dann mit dem Python-Kurs von Kaggle; planen Sie etwa zehn Stunden ein, bevor Sie sich an den Titanic-Wettbewerb wagen.
2. Etwas Python. Gehen Sie direkt zum Pandas-Kurs von Kaggle, dann zum offiziellen Titanic-Tutorial: eine CSV-Datei einlesen, bereinigen und einreichen.
3. Sicher. Belegen Sie Intermediate Machine Learning (Pipelines, Kreuzvalidierung, XGBoost, Data Leakage), bauen Sie das schwere Modell früh und helfen Sie dem Rest des Teams.

# eine Umgebung pro Projekt, damit sich Versionen nie vermischen
conda create -n project python=3.12
conda activate project
pip install -r requirements.txt
python -c "import sklearn, pandas, xgboost"   # kein Fehler heißt: bereit

Läuft die letzte Zeile ohne Fehler, ist alles bereit; die in requirements.txt festgeschriebenen Versionen erlauben es einem anderen Rechner, dieselbe Umgebung neu aufzubauen.

Zurück zum Inhalt.

Das Wichtigste in Kürze

1. Kaggle dient dem Training, GitHub der Abgabe, Python dem Schreiben; alle drei sind kostenlos, und alle drei sind im Lebenslauf sichtbar.
2. Ein Kaggle-Wert ist nur im Vergleich mit einer internen Validierung aussagekräftig: An die öffentliche Rangliste kann man ein Modell überanpassen, und ein perfekter Wert deutet meist auf ein Leak hin.
3. Git zeichnet die Zustände eines Projekts auf; GitHub hostet sie und ergänzt Pull Requests, Reviews und Issues. Halten Sie main funktionsfähig und legen Sie alles Unsichere auf einen Branch.
4. Der tägliche Zyklus lautet Pull, Bearbeiten, Commit mit einer Nachricht, die das Warum nennt, Push; ein Branch pro Aufgabe und ein geprüfter Pull Request pro Branch.
5. Zugangsdaten, personenbezogene Daten, große Dateien und neu erzeugbare Ausgaben gehören nie in ein Repository; ein gepushtes Token bleibt in der Historie.
6. Ein reproduzierbares Projekt hat ein README, einen Projektsteckbrief, Module in src/, Einstellungen in einer Konfigurationsdatei und Batch-Skripte, die auf einem frischen Rechner mit einem Befehl alles neu aufbauen.

Glossar

Repository

Ein Projektordner mit seiner vollständigen Versionshistorie, lokal gespeichert und meist auch auf GitHub.

Entwicklungszweig (branch)

Ein paralleler Arbeitsstrang; main ist der Haupt-Branch und muss immer funktionieren.

Pull Request

Auf GitHub eine Anfrage, einen Branch zu mergen, die ein Teamkollege vor dem Merge prüft.

Merge-Konflikt (merge conflict)

Zwei Branches haben dieselben Zeilen geändert; Git schreibt beide Versionen, und ein Mensch entscheidet.

öffentliche und private Rangliste (public and private leaderboard)

Die beiden Ranglisten eines Kaggle-Wettbewerbs: Die eine wird während des Wettbewerbs auf einem Teil des Testdatensatzes berechnet, die andere zum Fristende aufgedeckt.

Data Leakage

Information über die Antwort, die beim Training oder bei der Vorhersage zum Modell gelangt und den Wert ohne echtes Können aufbläht.

Projektsteckbrief (scope document)

Eine Markdown-Seite, die die unterstützte Entscheidung, die Zielvariable, die Metrik, die Leitplanken, die Daten und den Plan festhält.

Batch-Skript (batch script)

Ein Skript, das einen Schritt ohne menschliches Eingreifen von Anfang bis Ende ausführt, etwa Aufbereiten, Trainieren, Vorhersagen oder Evaluieren.

virtuelle Umgebung (virtual environment)

Ein isolierter Satz von Python-Paketen für ein Projekt, damit sich Bibliotheksversionen zwischen Projekten nicht in die Quere kommen.

Referenzmodell (baseline)

Das einfachste vernünftige Modell, etwa die Vorhersage des Mittelwerts, mit dem jedes andere Modell verglichen wird.

Die anderen Notizen des Kurses

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

Zurück: KI-Winter, Arbeitsmarkt und MethodeWeiter: Projektrahmen und kleinste Quadrate

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.