~/teaching · machine learning · referenz
Das Handbuch für Daten- und KI-Fachleute: abgrenzen, Werkzeuge aufsetzen, modellieren, bereitstellen, beobachten
Ein Referenz-Foliensatz, der ein Projekt von der ersten Frage bis zum Dashboard im Produktivbetrieb begleitet.
Zusammenfassung
Dies ist das Referenzhandbuch des Machine-Learning-Kurses an der Centrale Méditerranée (Schwerpunkt DDEFI, 2026-2027). Es ist keine Vorlesung, sondern der Foliensatz, den die Studierenden während der Projektarbeit geöffnet lassen, und es bündelt an einem Ort, was die anderen Foliensätze verteilen. Seine fünf Hauptteile folgen dem Lebenszyklus eines echten Daten- und KI-Projekts im Unternehmen: den Projektrahmen schriftlich festlegen, die Werkzeuge wählen, beim einfachsten Kandidaten beginnend modellieren, ein Modell und eine Anwendung bereitstellen, dann beide beobachten. Was der Produktivbetrieb lehrt (Drift, Latenz, Kosten), fließt in den Projektrahmen zurück.
Jeder Teil ist praktisch. Der Projektsteckbrief passt in sechs Zeilen. Der Werkzeugkasten deckt acht Werkzeugfamilien ab, von Python und Git bis zu Airflow, Spark, Kafka, Docker, Kubernetes und den Stacks für Beobachtbarkeit (observability), jeweils mit der im offiziellen Repository nachgelesenen Lizenz und einer freien Alternative, wenn das Werkzeug kommerziell ist. Siebzehn Modellsteckbriefe von je einer Folie reichen vom Mittelwert bis zur abrufgestützten Generierung. Der Teil zur Bereitstellung setzt ein Notebook, einen FastAPI-Dienst, eine Streamlit-Seite, Tests, kontinuierliche Integration und einen Container zusammen. Der Teil zur Beobachtbarkeit vergleicht Datadog, den Elastic-Stack, Grafana mit Prometheus sowie OpenTelemetry.
Nach der Lektüre sollten Sie ein Projekt auf einer Seite abstecken, eine Auswahl von Werkzeugen und von drei Modellen wachsender Komplexität begründen, einen kleinen Dienst ausliefern, den jemand anderes aufrufen kann, und sagen können, was Sie auf seinem Dashboard beobachten würden. Am Ende stehen zwanzig weitere Projektthemen, die meisten aus dem Finanzbereich, und zu jedem ein offener Datensatz, dessen Herausgeber, Adresse und Nutzungsbedingungen geprüft wurden.
Aufbau des Foliensatzes
- So nutzen Sie das Handbuch. Eine Karte der Teile und des Kreislaufs, den sie bilden: abgrenzen, Werkzeuge aufsetzen, modellieren, bereitstellen, beobachten, dann von vorn.
- Der Projektsteckbrief. Eine Vorlage mit sechs Zeilen, ein ausgefülltes Beispiel zum Ausfall von KMU, die Fragen an den Auftraggeber und die klassischen Fehler.
- Der Werkzeugkasten. Acht Werkzeugfamilien mit je einem Steckbrief: was das Werkzeug ist, wann man es einsetzt, seine Lizenz und eine freie Alternative.
- Modellgrundlagen. Siebzehn Steckbriefe nach demselben Muster, von naiven Referenzmodellen bis zu Transformern und RAG, dann die Frage, welches man wählt.
- Ein Modell und eine Anwendung bereitstellen. Vom Notebook zum Skript, zur API, zur Oberfläche, zu Tests, CI, Docker, festgeschriebenen Versionen, Secrets und kostenlosem Hosting.
- Beobachten. Logs, Metriken und Traces; Datadog, Elastic, Grafana und OpenTelemetry; was man an einem Modell beobachtet; ein Projekt zur Log-Analyse.
- Die Teams. Wie die Kursteams die Arbeit auf rotierende Rollen für Daten, Modell und Review aufteilen.
- Zwanzig weitere Projekte. Dreizehn Finanzthemen und sieben aus Daten und KI, jeweils mit einem geprüften offenen Datensatz und seinen Nutzungsbedingungen.
Der Projektsteckbrief: sechs Zeilen vor jedem Code
Bevor Sie Code schreiben, schreiben Sie sechs Sätze: die Entscheidung, der das Modell dient, was es vorhersagt, wie Erfolg gemessen wird, was verboten ist, welche Daten genutzt werden, und den Plan.
Das Handbuch beginnt mit dem Abstecken des Projektrahmens im Projektsteckbrief (scope document), denn ein Modell, das keiner Entscheidung dient, ist nutzlos, so genau es auch sein mag. Die Vorlage hat sechs Zeilen mit je einem Satz: die Entscheidung (wer auf Grundlage der Vorhersage handelt und was jede Fehlerart kostet), die Zielvariable (was vorhergesagt wird, mit welchem Horizont und wann die Wahrheit bekannt wird), die Metrik (diejenige, die die Entscheidung widerspiegelt, mit einer Nützlichkeitsschwelle), die Leitplanken (verbotene Variablen, geschützte Personen, Data Leakage), die Daten (Quelle, Lizenz, Zeitraum, Lücken) und der Plan (drei Modelle, Meilensteine, wer was macht). Eine Zeile, die nicht in einen Satz passt, zeigt, dass das Problem noch nicht verstanden ist.
Daraus folgt ein praktischer Filter: Kann ein Team die Datenzeile nicht noch in dieser Woche ausfüllen, mit Adresse und Lizenz, sollte es eher das Thema wechseln als das Modell. Das Dokument liegt als Markdown im Repository und wird nur per Pull Request geändert, sodass seine Historie zeigt, wie das Verständnis des Teams gereift ist. Daneben liegt ein datiertes Entscheidungsprotokoll.
Das ausgefüllte Beispiel: Ausfall französischer KMU
- Entscheidung. Ein Firmenkundenbetreuer prüft zuerst die riskantesten 5 % der Kleinunternehmen; ein Fehlalarm kostet eine Prüfung, ein übersehener Ausfall kostet einen Verlust.
- Zielvariable. Eine im BODACC veröffentlichte Insolvenzbekanntmachung innerhalb von zwölf Monaten nach dem Bewertungsstichtag, der als Bezugspunkt dient: Jedes Merkmal muss an diesem Tag bekannt sein.
- Metrik. PR-AUC, Recall innerhalb der obersten 5 % und erwartete Kosten pro Akte, weil die Klasse selten und das Prüfbudget fest ist.
- Leitplanken und Daten. Keine Daten über Geschäftsführer, die natürliche Personen sind; BODACC und das Sirene-Register von data.gouv.fr unter Licence Ouverte 2.0; eine Aufteilung nach Datum.
- Plan. Die Ausfallrate nach Branche als naives Modell, dann logistische Regression, dann LightGBM.
Sechs Fragen übertragen dieselbe Vorlage in die Sprache des Auftraggebers: was Sie mit der Vorhersage anders machen werden, was jeder Fehler kostet, wann Sie die Wahrheit kennen werden, was Sie heute ohne Modell tun, wer die Daten sehen darf und was als Misserfolg gelten würde. Die vierte liefert Ihnen das naive Referenzmodell (baseline) gratis; die sechste legt die Nützlichkeitsschwelle fest, bevor es irgendein Ergebnis gibt, damit sie nicht zu dem Wert hin wandert, der am Ende herauskommt.
Bemerkung (Sechs wiederkehrende Fehler). Eine vage Zielvariable, eine Metrik, die einer seltenen Klasse schmeichelt (die Accuracy bei Betrug), Merkmale aus der Zukunft, eine zufällige Aufteilung datierter Daten, ein Wert ohne naives Modell, das ihm einen Maßstab gibt, und ein Datensatz, der ohne seine Lizenz erneut veröffentlicht wird. Eine AUC von 0,78 sagt für sich genommen wenig; neben den Wert der aktuellen Regel gestellt, wird sie zum Argument.
Der Werkzeugkasten: acht Familien, ein Werkzeug pro Schicht
Eine Daten- und KI-Fachkraft arbeitet mit einem ganzen Stack von Werkzeugen, vom Laptop bis in die Cloud, und ein studentisches Projekt braucht nur ein einfaches Werkzeug pro Schicht.
Der Werkzeugkasten ist als übereinanderliegende Schichten gezeichnet, von unten nach oben zu lesen: der Arbeitsplatz (Python, VS Code, Jupyter, Git, GitHub, Linux, Docker), die Daten (PostgreSQL, DuckDB, SQLite, pandas, Polars, Spark, Kafka, das Parquet-Format), die Orchestrierung (Airflow, dbt, Prefect, LangGraph, MCP), die Modelle (NumPy, scikit-learn, XGBoost, LightGBM, PyTorch, TensorFlow, Hugging Face, MLflow), die Auslieferung (FastAPI, uvicorn, Streamlit, Gradio, Nginx), die Infrastruktur (Kubernetes, Terraform, die großen Clouds, zwei französische Anbieter, GitHub Actions) und die Beobachtbarkeit. Generative KI ist als Spalte quer durch alle Schichten gezeichnet: Sie hilft beim Schreiben von Code, beim Extrahieren von Feldern aus einem Text, beim Zusammenfassen eines Vorfalls oder beim Steuern eines Agenten.
| Schicht | Genügt für ein Kursprojekt | Typisch im großen Maßstab |
|---|---|---|
| Daten | DuckDB oder pandas auf Parquet-Dateien | Spark auf einem Cluster, Kafka für Ereignisströme, PostgreSQL hinter einer Anwendung |
| Orchestrierung | ein Cronjob oder ein zeitgesteuerter GitHub-Actions-Workflow | Airflow, sobald mehrere abhängige Aufgaben Wiederholungen und eine Historie brauchen |
| Modelle | scikit-learn, dann XGBoost oder LightGBM; MLflow optional | PyTorch und vortrainierte Hugging-Face-Modelle auf GPUs |
| Auslieferung | FastAPI, gestartet von uvicorn, plus eine Streamlit-Seite | Nginx davor für HTTPS und Lastverteilung |
| Infrastruktur | Docker, GitHub Actions und ein kostenloser Host | Kubernetes und Terraform in einer Cloud |
| Beobachtbarkeit | Prometheus und Grafana, lokal betrieben | Datadog oder ein gehosteter Elastic- oder Grafana-Stack |
Jeder Steckbrief trennt die Softwarelizenz vom Preis des Dienstes. Im Machine Learning sind die Bibliotheken frei; die Kosten liegen bei Maschinen und Daten. Einige Lizenzen verdienen Aufmerksamkeit: Terraform wechselte 2023 zur Business Source License, die keine Lizenz für freie Software ist, und der Community-Fork OpenTofu blieb unter MPL 2.0; Elasticsearch lässt die Wahl zwischen AGPL v3, SSPL und der Elastic License, während OpenSearch unter Apache 2.0 bleibt; Docker Desktop hat eigene kommerzielle Bedingungen, getrennt von der freien Docker Engine. Preise und Kontingente der Gratis-Tarife werden nie übernommen, weil sie sich ändern; der Foliensatz rät, sie am Tag der Anmeldung auf der offiziellen Seite nachzulesen und vor dem Start jeder Cloud-Maschine einen Budgetalarm einzurichten.
Kubernetes und Spark werden als das vorgestellt, was sie sind: Werkzeuge für hohen Datenverkehr oder für Daten, die über eine Maschine hinausgehen, für ein Vorstellungsgespräch gut zu kennen, für ein dreimonatiges Projekt aber nicht die Installation wert. Baut man dasselbe Projekt zweimal, kostet es entweder Einrichtungszeit (freie Software auf einem Laptop) oder eine Rechnung, die mit der Nutzung wächst (gehostete Dienste). Cluster und Site Reliability behandelt die Notiz zu Data Engineering und Cloud.
Airflow und die Orchestrierung von Agenten auf Basis von Sprachmodellen
Ein Orchestrator startet Aufgaben in der richtigen Reihenfolge zur richtigen Zeit, wiederholt fehlgeschlagene und merkt sich jeden Lauf, ob die Aufgaben Daten bewegen oder ein Sprachmodell aufrufen.
In Airflow ist eine Pipeline ein gerichteter azyklischer Graph (directed acyclic graph, DAG): Aufgaben und die Abhängigkeiten zwischen ihnen. Airflow startet den Graphen nach einem Zeitplan, speichert für jeden Lauf den Status und die Logs jeder Aufgabe, wiederholt eine fehlgeschlagene Aufgabe nach einer Regel und alarmiert dann das Team. Das bloße Planen kann auch cron; was Airflow wertvoll macht, ist dieses Gedächtnis, mit dem man sieht, welche Aufgabe an welchem Tag fehlgeschlagen ist, und einen vergangenen Tag per Nachberechnung (backfill) erneut ausführt, ohne alles neu zu starten.
Mit derselben Mechanik laufen auch Agenten. Ein Agent im Unternehmen ist meist eine Kette von Sprachmodellaufrufen mit präzisen Anweisungen, eingebettet zwischen gewöhnlichen Schritten. Das Beispiel des Foliensatzes ist eine Presseschau für eine Bank: Artikel sammeln, zusammenfassen, jeden als Risiko einstufen oder nicht, die Ausgabe mit Regeln und einem Judge-Modell prüfen, auf die Freigabe durch einen Analysten warten, morgens veröffentlichen. Für Airflow ist jeder Aufruf nur eine Python-Funktion, und der Orchestrator liefert, was handgeschriebenen Agentenskripten fehlt: Wiederholungen bei Fehlern des Anbieters, ein Protokoll jedes Aufrufs für Audits, die Kosten pro Aufgabe und einen ausdrücklichen menschlichen Schritt vor jeder unumkehrbaren Aktion.
Bemerkung (Airflow, LangGraph, MCP). Airflow orchestriert den Tag; LangGraph orchestriert ein Gespräch, als Zustandsgraph, in dem das Modell in Schleifen Werkzeuge aufrufen kann und der Zustand an jedem Knoten gespeichert wird; MCP, das im November 2024 von Anthropic veröffentlichte Model Context Protocol, ist ein offener Weg, Werkzeuge (eine Datenbank, ein Repository) jedem kompatiblen Client zur Verfügung zu stellen. Ein Projekt kann alle drei nutzen; festzuhalten ist, dass der Zugriff eines Agenten auf Daten ein ausdrücklicher, begrenzter und protokollierter Vertrag ist.
Siebzehn Modellsteckbriefe, von einfach bis tief
Jedes Modell bekommt denselben einseitigen Steckbrief: die Idee in einem Satz, die Formel, eine Skizze, wann man es einsetzt, die wichtigen Einstellungen und die zu importierende Funktion.
Die Steckbriefe gliedern sich in drei Stufen. Einfach: der Mittelwert oder der letzte Wert (Persistenz), die gewöhnliche Kleinste-Quadrate-Schätzung, die logistische Regression, k-nächste Nachbarn, Naive Bayes. Mittel: der Entscheidungsbaum, der Random Forest, Gradient Boosting und XGBoost, SVMs mit Kerneln, die Hauptkomponentenanalyse (PCA), k-Means. Tief: das mehrschichtige Perzeptron, Faltungsnetze und rekurrente Netze, der Transformer, das große Sprachmodell, dann Fine-Tuning und RAG. Die linke Hälfte eines Steckbriefs zeigt, was man verstehen muss, die rechte, was man können muss. Einige wenige Formeln tragen den größten Teil des Kurses:
Die Methode der kleinsten Quadrate projiziert auf den von den Spalten von aufgespannten Raum (siehe die Notiz zur Methode der kleinsten Quadrate); die logistische Regression schickt einen linearen Score durch eine S-Kurve und ist das Modell hinter den Scorekarten der Banken, mit einer Schwelle, die aus den Fehlerkosten abgeleitet und nicht bei 0,5 belassen wird. Boosting fügt kleine Bäume hintereinander hinzu, jeder an das angepasst, was die vorherigen falsch gemacht haben, und mit einer Lernrate skaliert, während frühes Stoppen (early stopping) auf einem Validierungsdatensatz bestimmt, wie viele Bäume man behält. Attention lässt jedes Wort seine Darstellung aus allen anderen aufbauen, was der Artikel zu Attention Schritt für Schritt herleitet.
- Auf mittelgroßen Tabellen schlagen geboostete Bäume neuronale Netze meist noch; ein MLP geht als ein weiterer Kandidat unter derselben Regel in den Vergleich ein.
- Ein Sprachmodell erzeugt plausiblen Text, keinen wahren: Setzen Sie es dort ein, wo sich die Ausgabe prüfen lässt, etwa beim Extrahieren eines im Dokument gedruckten Betrags.
- Die abrufgestützte Generierung (retrieval-augmented generation, RAG) holt die ähnlichsten Passagen über die Kosinus-Ähnlichkeit von Embeddings und lässt die Gewichte unverändert; Fine-Tuning (oder LoRA, eine Korrektur niedrigen Rangs ) verändert das Modell. RAG für Wissen, das sich ändert, Fine-Tuning für Verhalten.
Welches Modell wählen: das naive, das beste, das schwere
Jedes Projekt vergleicht drei Modelle wachsender Komplexität und steigt nur dann eine Stufe höher, wenn der Gewinn größer ist als das Rauschen.
Der Ausgangspunkt hängt von den Daten und der Aufgabe ab, nicht von der Mode. Für jede Art von Problem schlägt das Handbuch einen Kandidaten pro Stufe vor: ein naives Modell, das den Maßstab liefert, das beste Modell, einfach und vor einem Gremium vertretbar, und ein schweres Modell, das prüft, ob sich Komplexität auszahlt. Es geht um einen fairen Vergleich, nicht um einen Sieg des schweren Modells: eine Aufteilung, eine Metrik, ein Testzeitraum für alle drei. Der Überblick über die Modelle bietet die lange Fassung dieser Tabelle.
| Problem | Naives Modell | Bestes Modell | Schweres Modell |
|---|---|---|---|
| Ja/Nein-Zielvariable in einer Tabelle | Basisrate | logistische Regression | XGBoost oder LightGBM |
| Betrag in einer Tabelle | der Mittelwert | OLS oder Ridge | LightGBM |
| Zeitreihe | letzter Wert oder gleiche Saison | Ridge auf Lags, ARIMA | Boosting auf Lags |
| Kurze gelabelte Texte | häufigste Klasse | TF-IDF mit logistischer Regression | ein feinabgestimmter Transformer |
| Fragen zu Dokumenten | BM25-Stichwortsuche | RAG | RAG mit Reranking |
| Bilder | häufigste Klasse | eingefrorenes vortrainiertes CNN mit logistischem Kopf | ein feinabgestimmtes CNN |
| Keine Labels | eine Geschäftsregel | k-Means, PCA | Isolation Forest, Autoencoder |
Projekte mit generativer KI behalten die drei Stufen bei, sofern sie ein gemeinsames Maß haben: eine Referenzmenge von Fragen oder Dokumenten, vom Team gelabelt und vor dem ersten Versuch eingefroren, ein im Voraus geschriebenes Bewertungsraster und Kosten in Euro und Sekunden pro Anfrage, denn ein Modell, das zwei Punkte besser und zehnmal teurer ist, ist nicht automatisch das richtige. Die Rechnung des Foliensatzes selbst zeigt, warum die Größe der Referenzmenge zählt.
Rechenbeispiel: wie genau eine an 50 Fragen gemessene Quote ist
- Beobachtete Quote. Ein Modell beantwortet 40 von 50 Referenzfragen richtig, also .
- Standardfehler. .
- Halbbreite bei 95 %. Mit der Normalapproximation ergibt sich , also etwa 11 Punkte nach beiden Seiten.
- Interpretation. Das Intervall reicht von etwa 69 % bis 91 %; ein Konkurrent mit 84 % auf derselben Menge lässt sich davon also nicht unterscheiden: Sagen Sie das, oder vergrößern Sie die Menge.
Ein Modell und eine Anwendung bereitstellen
Die Bereitstellung macht aus einem Notebook einen kleinen Dienst, den jeder aufrufen kann: ein Skript, das trainiert, eine API, die vorhersagt, eine Seite für Menschen und ein Roboter, der bei jeder Änderung alles prüft.
Die Architektur ist für alle Teams dieselbe; nur das Modell und die Oberfläche ändern sich. Auf der Entwicklerseite erkunden Sie in einem Notebook, verschieben den funktionierenden Code mit seinen Tests nach src/, öffnen einen Pull Request, und GitHub Actions prüft den Stil, führt die Tests aus und baut das Image. Auf der Seite des Hosts liefert eine API das Modell aus, und eine Oberfläche ruft sie auf. Secrets bleiben außerhalb des Repositorys; die Beobachtbarkeit überwacht die laufende API.
Schritt für Schritt
- Vom Notebook zum Skript. Jeder Schritt wird zu einer Funktion mit Argumenten, und ein einziger Befehl trainiert neu und schreibt dabei die Modelldatei und eine Metrikdatei; niemand überträgt eine Zahl von Hand, und derselbe Seed liefert dasselbe Ergebnis.
- Vom Skript zur API. FastAPI lädt das gespeicherte Modell einmal beim Start und trainiert nie neu; eine pydantic-Klasse ist der Eingabevertrag, sodass eine Anfrage außerhalb des zulässigen Bereichs mit einem Fehler 422 abgewiesen wird, bevor sie das Modell erreicht;
/docsliefert gratis eine Testseite. - Von der API zur Oberfläche. Eine Streamlit-Seite ruft die API auf, statt das Modell zu laden, sodass Menschen und Maschinen identische Vorhersagen sehen; die Adresse der API stammt aus einer Umgebungsvariablen, und ein sichtbarer Hinweis sagt, was der Score nicht ist.
- Tests. Drei Tests sind besser als keiner: Der Dienst antwortet, eine Wahrscheinlichkeit bleibt zwischen 0 und 1, eine absurde Eingabe wird abgelehnt. Der wertvollste prüft, dass das ausgelieferte Modell auf einigen festen Zeilen genau so vorhersagt wie das evaluierte.
- Kontinuierliche Integration. Die kontinuierliche Integration (continuous integration, CI) führt über einen kurzen YAML-Workflow bei jedem Push und jedem Pull Request Installation, Lint, Tests und Docker-Build auf einer sauberen Maschine erneut aus.
- Container und Versionen. Ein Dockerfile installiert die festgeschriebenen Abhängigkeiten, bevor es den Code kopiert, sodass der Cache Codeänderungen übersteht; exakte Versionen sorgen dafür, dass die Berechnung im März mit der im November übereinstimmt.
- Secrets und Hosting. API-Schlüssel liegen in einer lokalen, von Git ignorierten
.envund in den Variablen des Hosts; ein Schlüssel, der auch nur kurz gepusht wurde, wird beim Anbieter widerrufen, denn wer ihn in einem späteren Commit löscht, lässt ihn trotzdem in der Historie. Kostenlose Hosts eignen sich für eine Demo, doch eine schlafende Instanz muss vor der Präsentation geweckt werden.
Der Foliensatz betont, dass eine Anwendung Software ist, also gelten fünf Mindestpraktiken: Linting mit ruff, Tests in der CI, kein Merge ohne Review, ein Git-Tag pro Meilenstein mit festgeschriebenen Abhängigkeiten und ein datiertes Entscheidungsprotokoll. Generative KI beschleunigt das Schreiben eines API-Gerüsts, eines Tests oder eines Dockerfiles, macht aber selbstsichere Fehler (ein Paket, das es nicht gibt, ein in einem Vorbereitungsschritt verstecktes Leak, ein Schlüssel im Klartext); die gesparte Zeit zählt nur, wenn jemand, der den Code versteht, ihn prüft, und jedes Team legt seine Nutzung offen. Die Auslieferung von Modellen und die Drift behandelt die Notiz zu neuronalen Netzen und Drift.
Beobachtbarkeit: Logs, Metriken, Traces und was man an einem Modell beobachtet
Eine Anwendung zu beobachten heißt, anhand von drei Signalen (Logs, Metriken und Traces) zu erkennen, dass sie langsam ist, ausfällt oder driftet, bevor sich ein Nutzer beschwert.
Logs sagen, was passiert ist, Ereignis für Ereignis, und nützen nur, wenn sie strukturiert sind: eine JSON-Zeile pro Ereignis mit benannten Feldern (Route, Status, Dauer, Modellversion, Ausgabe), niemals personenbezogene Daten im Klartext. Metriken zählen und messen über die Zeit und lösen Alarme aus; ein Histogramm der Dauern erlaubt es, Quantile wie die Latenz am 95. Perzentil zu berechnen. Traces verfolgen eine Anfrage über mehrere Dienste hinweg und zeigen, wohin die Zeit ging, aufgeteilt in Spans.
| Datadog | Elastic-Stack | Grafana-Stack | |
|---|---|---|---|
| Betrieb | vom Anbieter gehostet | selbst gehostet oder Elastic Cloud | selbst gehostet oder Grafana Cloud |
| Logs, Metriken, Traces | Agent, Log-Management, APM | Elasticsearch, Metricbeat, Elastic APM | Loki, Prometheus, Tempo oder Jaeger |
| Oberflächen | eingebaute Dashboards | Kibana | Grafana |
| Stärke | alles auf einmal, schnell angeschlossen | Volltextsuche über riesige Log-Mengen | frei, leichtgewichtig und verbreitet |
Datadog, 2010 in New York von zwei Absolventen der Centrale gegründet, verkauft Zeit: Man installiert den Agenten, und Dashboards, Alarme und Traces erscheinen. Elasticsearch speichert Logs in einem invertierten Index (für jedes Wort die Liste der Zeilen, die es enthalten), sodass eine Suche zu einer Schnittmenge von Listen wird. Prometheus arbeitet umgekehrt wie die meisten Werkzeuge: Es ruft in festen Abständen die Seite /metrics jedes Dienstes ab und hält Zeitreihen mit Labels vor, die mit PromQL abgefragt werden; Grafana zeigt sie neben den Logs aus Loki an. OpenTelemetry, ein Projekt der Cloud Native Computing Foundation, standardisiert, wie die drei Signale erzeugt und versendet werden (das Protokoll OTLP, über einen Collector), sodass man einmal instrumentiert und ohne Änderung am Code von einem lokalen Stack zu einem kostenpflichtigen Dienst wechseln kann. Für den Kurs empfohlen ist der Grafana-Stack unter Docker Compose.
Ein Modell ergänzt Latenz, Fehlerquote und Volumen um eigene Indikatoren: die Drift der Eingaben, gemessen mit dem PSI pro Merkmal, ohne auf Labels zu warten, die Verteilung der ausgegebenen Scores, die tatsächliche Qualität (AUC, Kalibrierung), sobald die Wahrheit eintrifft, manchmal Monate später, und bei Aufrufen von Sprachmodellen die Eingabe- und Ausgabe-Token pro Anfrage, umgerechnet in Tageskosten. Die Schwellen des Foliensatzes sind Beispiele, etwa ein PSI über 0,25 aus der Praxis des Kreditscorings, und jeder Alarm braucht einen Verantwortlichen und eine Maßnahme. Einen FastAPI-Dienst zu instrumentieren erfordert einen Zähler, ein Histogramm, eine Route /metrics und eine JSON-Logzeile pro Vorhersage, die die Modellversion enthält.
Der Teil endet mit einem Rollentausch: ein Modell, das eine Anwendung beobachtet. Mit Loghub (LogPAI-Labor, Chinese University of Hong Kong), dessen Datensatz HDFS_v1 laut dem am 12. Oktober 2026 gelesenen README des Repositorys 11.175.629 Logzeilen über 38,7 Stunden umfasst, führen die Studierenden jede Zeile auf ihre Vorlage zurück (Drain-Algorithmus) und vergleichen dann eine Regel auf Fehlerwörtern, einen Isolation Forest auf den Häufigkeiten der Vorlagen und ein Sequenzmodell oder ein Sprachmodell. Ein Sprachmodell fasst anschließend jeden gemeldeten Vorfall für den Ingenieur in Rufbereitschaft zusammen, der weiterhin entscheidet; die Zusammenfassungen werden mit einem festen Bewertungsraster an rund dreißig von Hand geschriebenen gemessen. Loghub ist nur für Forschung und Lehre frei nutzbar, und der Artikel muss zitiert werden.
Das Wichtigste in Kürze
- Abstecken vor dem Programmieren: sechs Zeilen mit je einem Satz (Entscheidung, Zielvariable, Metrik, Leitplanken, Daten, Plan), im Repository versioniert und per Pull Request geändert.
- Ein einfaches Werkzeug pro Schicht genügt für ein Projekt; Spark, Kafka und Kubernetes sollte man verstehen, aber nicht für drei Monate Arbeit installieren.
- Der Wert von Airflow ist sein Gedächtnis (Laufhistorie, Wiederholungen, Nachberechnungen), und derselbe DAG kann Sprachmodellaufrufe mit einem ausdrücklichen menschlichen Schritt orchestrieren.
- Ein naives, das beste und ein schweres Modell auf derselben Aufteilung und mit derselben Metrik vergleichen und nur eine Stufe höher steigen, wenn der Gewinn das Rauschen übersteigt.
- Bereitstellen wie Software: ein Trainingsskript, eine API mit Eingabevertrag, eine getrennte Oberfläche, Tests in der CI, ein Container, festgeschriebene Versionen, Secrets außerhalb von Git.
- Mit Logs, Metriken und Traces beobachten; bei einem Modell kommen Drift, Verteilung der Ausgaben, verzögerte Qualität und die Kosten jedes Sprachmodellaufrufs hinzu.
- Lizenzen und Bedingungen lesen, bevor man baut: Mehrere verbreitete Werkzeuge und Datensätze sind nur quelloffen einsehbar (source-available) oder nicht kommerziell nutzbar, also keine freie Software.
Glossar
- Projektsteckbrief (scope document)
- Eine einseitige Projektbeschreibung in sechs Zeilen (Entscheidung, Zielvariable, Metrik, Leitplanken, Daten, Plan), die im Repository liegt.
- gerichteter azyklischer Graph (directed acyclic graph, DAG)
- Aufgaben und ihre Abhängigkeiten, die Einheit, die Airflow plant und ausführt.
- Nachberechnung (backfill)
- Die Läufe vergangener Stichtage einer Pipeline erneut ausführen, etwa nach einer Fehlerkorrektur, ohne alles andere neu zu starten.
- MCP
- Model Context Protocol, ein offenes Protokoll, über das ein Server Werkzeuge und Ressourcen für einen Sprachmodell-Client bereitstellt.
- abrufgestützte Generierung (retrieval-augmented generation, RAG)
- Die relevantesten Passagen abrufen und einem Sprachmodell übergeben, dessen Gewichte sich nicht ändern.
- Referenzmodell (baseline)
- Das naive Modell (Mittelwert, letzter Wert, aktuelle Regel), das jedes andere Modell schlagen muss, um seinen Platz zu verdienen.
- kontinuierliche Integration (continuous integration, CI)
- Das Projekt bei jedem Push automatisch auf einer sauberen Maschine neu installieren, linten, testen und bauen.
- Container
- Ein Image, das eine Anwendung mit allen Abhängigkeiten enthält und auf einem Laptop, in der CI und beim Host identisch läuft.
- Beobachtbarkeit (observability)
- Die Fähigkeit, Fragen zu einem laufenden System anhand seiner Logs, Metriken und Traces zu beantworten, ohne neu bereitzustellen.
- Drift
- Eine Veränderung der Eingaben oder ihrer Beziehung zur Zielvariable nach der Bereitstellung, oft mit dem PSI gemessen.
Die anderen Notizen des Kurses
Eine öffentliche Zusammenfassung pro Foliensatz, in der Reihenfolge des Kurses.
Zurück: ML-Projekte mit offenen Daten nach BrancheWeiter: Data Engineering, SRE und Cloud
- EinführungKI-Winter, Arbeitsmarkt und Methode
- WerkzeugeKaggle, GitHub, Python: die Werkzeuge
- Sitzung 1Projektrahmen und kleinste Quadrate
- Sitzung 2Maximum Likelihood und logistische Regression
- Sitzung 3Gradientenabstieg, Ridge und Lasso
- Sitzung 4Entscheidungsschwelle und reproduzierbares ML
- HausaufgabeML-Projekt abstecken: der Projektsteckbrief
- Sitzung 5Kernel, SVM und Entscheidungsbäume
- Sitzung 6Random Forests, Boosting, ehrlicher Vergleich
- Sitzung 7SHAP, Fairness, PCA und Clustering
- HausaufgabeEin einfaches Modell mit vollständiger Methode
- Sitzung 8Neuronale Netze, Drift, konforme Vorhersage
- HausaufgabeEin ausgeliefertes Machine-Learning-Projekt
- Sitzung 9Ein Machine-Learning-Projekt verteidigen
- ReferenzProjekt zum Kreditausfallscore
- ReferenzAktienrenditen: XGBoost und Sentiment
- ReferenzPython-Code für jedes ML-Modell
- ReferenzDeep Learning, das Wesentliche
- ReferenzML-Projekte mit offenen Daten nach Branche
- ReferenzHandbuch für Daten- und KI-Fachleute
- ReferenzData Engineering, SRE und Cloud
- ReferenzPanorama der Machine-Learning-Modelle
Ü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: .