Zum Inhalt springen

~/teaching · machine learning · hausaufgabe 3

Ein Machine-Learning-Projekt ausliefern: Repository, getesteter Service, nachvollziehbarer Bericht und die Dokumente, die ein Ausschuss liest

Der letzte Schritt eines Projekts: dieselbe Methode wie bei Referenzmodell und Champion-Modell, angewandt auf Ihr eigenes Thema und ausgeliefert

Zusammenfassung

Ein ausgeliefertes Projekt ist mehr als ein gutes Modell. Es ist ein Repository, das ein anderes Team ausführen kann, ohne Sie anzurufen, ein Service, der auf eine Anfrage antwortet, ein Bericht, in dem jede Zahl aus dem Code stammt, und eine Reihe kurzer Dokumente, die ein Entscheidungsträger und ein Validierungsteam lesen können. Diese Notiz fasst die Aufgabenstellung der letzten Hausaufgabe des Kurses Machine Learning an der Centrale Méditerranée zusammen (Schwerpunkt DDEFI, 2026-2027), in der jedes Team die Methode des Kurses auf ein selbst gewähltes Thema anwendet.

Die Methode wurde an einem durchgehenden Beispiel gelernt, einem Kreditausfall-Score, und das eigene Projekt des Teams hat zwei frühere Etappen durchlaufen: das Abstecken des Projekts und seiner Problemstellung und ein erstes lineares oder logistisches Modell auf den Projektdaten. Die Abschlussabgabe verwendet dieselbe Repository-Vorlage und ergänzt, was die letzten Sitzungen vermittelt haben: ein neuronales Netz, Drift-Überwachung, konforme Vorhersage (conformal prediction), eine Gewinnkurve (profit curve), eine Lückenanalyse zum EU AI Act und einen Vorhersage-Service.

Was folgt, ist die Methode, nicht die Organisation der Lehrveranstaltung. Sie liest sich wie eine Checkliste für alle, die ein Modell an Menschen übergeben, die es betreiben, dafür unterschreiben und es in der Produktion überwachen werden.

Die Folien

Abschlusspräsentation mit dem Code (50 %): das abgegebene Projekt

Hausaufgabe 3. Machine Learning, Centrale Méditerranée, Schwerpunkt DDEFI, 2026-2027. Die Folien gibt es auf Französisch und Englisch; der Link öffnet die englische Fassung.

Folien öffnen (Passwort vom Dozenten)

Der Foliensatz selbst ist für die Studierenden des Kurses verschlüsselt; diese Seite fasst ihn für alle zusammen.

Die Kursseite · Aufmerksamkeit und Transformer, Schritt für Schritt

Aufbau des Foliensatzes

  1. Wo das Projekt steht. Zwei Projekte, eine Methode: Das durchgehende Beispiel hat sie vermittelt, Ihr Thema wendet sie an.
  2. Was eine Abgabe enthält. Sieben Zeilen: Rahmen, Repository, drei Modelle, Dokumente, Bericht, Oberfläche, Einzelberichte der Mitglieder.
  3. Das finale Repository. Die Vorlage des durchgehenden Beispiels, mit einem Service, einer Oberfläche und Integrationstests.
  4. Der Bericht. Höchstens acht Seiten, zehn Abschnitte in fester Reihenfolge, jede Zahl nachvollziehbar.
  5. Die Dokumente. Modellkarte, Datenblatt, Überwachungsplan, AI-Act-Lückenanalyse, Kundenmemo, Entscheidungsprotokoll, KI-Anhang.
  6. Das Kundenmemo und der API-Vertrag. Eine Seite in Euro für einen Entscheidungsträger und ein typisierter Vertrag am Eingang des Modells.
  7. Organisation. Drei Rollen und namentlich gekennzeichnete Arbeit.
  8. Fallstricke und Produktion. Vier wiederkehrende Fehler und der Weg, den ein Modell in einer Bank durchläuft.

Was „ausgeliefert“ bedeutet

Ein Projekt ist ausgeliefert, wenn Menschen, die es nicht gebaut haben, es erneut ausführen und abfragen, nachlesen, warum es so gebaut wurde, und entscheiden können, ob sie es nutzen.

Die Abgabe geht von einem Projektsteckbrief (scope document) aus, der früh per Pull Request abgestimmt und auf demselben Weg aktuell gehalten wird: die Entscheidung, die das Modell unterstützt, die Zielvariable, die Metrik, die Leitplanken, die Daten und der Plan. Anschließend werden drei Modelle nach den Regeln der Champion-Etappe verglichen, ein naives, ein besseres und ein aufwendiges, mit Konfidenzintervallen und einer Champion-Regel, die vor den Ergebnissen als Issue hinterlegt wird.

  • Ein öffentliches Repository, in dem make reproduce, make compare und die Tests laufen, dessen kontinuierliche Integration (continuous integration, CI) grün ist und dessen README ein anderes Team allein befolgt hat.
  • Ein Service und eine minimale Webseite, auf der man einen Fall eingibt und das Modell antwortet.
  • Ein Bericht von höchstens acht Seiten und ein kurzer Foliensatz.
  • Die Dokumente der Abgabe, vollständig statt nur im Entwurf.
  • Für jedes Mitglied eine Seite darüber, was es geschrieben und was es selbst überprüft hat, und wie.

Bemerkung (Dieselbe Vorlage, neue Daten). Nichts davon ist grundsätzlich neu. Jeder Bestandteil der Abgabe wurde zuerst am durchgehenden Beispiel erarbeitet; die Abgabe schreibt es für ein anderes Problem neu, und genau diese Fähigkeit sucht ein Arbeitgeber.

Zurück zum Inhalt.

Ein kurzer Bericht, in dem jede Zahl eine Quelle hat

Der Bericht folgt einer festen Gliederung, damit nichts Unbequemes wegfällt, und jede Zahl darin findet sich in einer Datei, die der Code erzeugt hat.

Die Gliederung ist vorgegeben und für alle Teams gleich, was die Berichte vergleichbar macht und die Abschnitte erzwingt, die man gern überspringt. Ein Abschnitt kann aus einem einzigen Absatz bestehen, wenn es wenig zu sagen gibt, aber keiner darf fehlen.

Tabelle 1: Die zehn Abschnitte des Berichts, in ihrer Reihenfolge, und die Frage, die jeder beantwortet.
§AbschnittBeantwortete Frage
1RahmenWelche Entscheidung, für wen, gemessen an welcher Metrik
2Daten und Data LeakageWoher die Daten stammen und was wann bekannt ist
3MethodenWelche Modelle ausprobiert wurden, vom einfachen bis zum aufwendigen
4VergleichWelches Modell gewinnt, mit Intervallen und einem korrigierten Test
5Schwelle und KostenWo die Schwelle liegt, angesichts der Kosten jedes Fehlers
6Konforme VorhersageWie sicher sich das Modell ist, Fall für Fall
7FairnessOb Gruppen unterschiedlich behandelt werden
8ÜberwachungWas in der Produktion beobachtet wird und wer handelt
9WertWas das Modell in Euro wert ist
10GrenzenWo man ihm nicht vertrauen sollte

Die Regel, die alles zusammenhält: Jede Zahl im Bericht nennt die Datei und den Schlüssel, aus denen sie stammt, zum Beispiel einen Eintrag in compare.json. Eine von Hand eingetippte Zahl lässt sich nicht überprüfen, also wird ein Prüfer sie für falsch halten, bis das Gegenteil belegt ist.

Zurück zum Inhalt.

Die Dokumente, die ein Ausschuss liest

Kurze Dokumente mit jeweils einer einzigen Aufgabe erlauben einem Leser, der den Code nie öffnen wird, über das Modell zu entscheiden, es zu validieren und zu überwachen.

  • Modellkarte (model card): Metriken mit Intervallen, Schwelle, Fairness-Ergebnisse und Latenzen, gemessen auf einer benannten Maschine.
  • Datenblatt (datasheet): Herkunft, Erhebung, Lizenz und vor allem, was die Daten nicht abdecken.
  • Überwachungsplan: Drift-Indikatoren wie der Populationsstabilitätsindex (population stability index, PSI) und die Kolmogorov-Smirnov-Statistik, für jeden eine begründete Alarmschwelle, die Maßnahme, die sie auslöst, die Person, die handelt, und eine Strategie für das Nachtrainieren.
  • Lückenanalyse (gap analysis) zum AI Act: zwei Seiten, die das Repository mit der technischen Dokumentation vergleichen, die Anhang IV der KI-Verordnung der EU verlangt, wenn das Thema darunterfällt, oder ein Absatz, der erklärt, warum es nicht darunterfällt.
  • Kundenmemo: eine Seite in Euro für einen Entscheidungsträger (nächster Abschnitt).
  • Entscheidungsprotokoll und KI-Anhang: datierte Einträge bis zum letzten Commit und mindestens zwei KI-Vorschläge, die nachweislich falsch waren.
PSI=∑b(ab−eb) ln⁡abeb\mathrm{PSI} = \sum_{b} \big(a_b - e_b\big)\,\ln\frac{a_b}{e_b}
(1)

Dabei sind ebe_b und aba_b die Anteile der Fälle in der Klasse bb zur Trainingszeit und in der Produktion. Die Formel ist der einfache Teil. Ein Überwachungsplan ist sein Geld wert, wenn er für jeden Indikator sagt, ab welchem Wert etwas geschieht und wer entscheidet; eine Liste von Indikatoren ohne Schwelle und ohne verantwortliche Person ist der dritte Fallstrick weiter unten. Lesen Sie für den AI Act den konsolidierten Text der Verordnung statt Folien, denn seine Geltungsdaten haben sich bereits einmal verschoben.

Zurück zum Inhalt.

Das Kundenmemo: eine Seite, in Euro

Das Memo richtet sich an jemanden, der den Bericht nicht lesen wird und mit Ja oder Nein antworten muss, deshalb nennt es auf einer Seite die Entscheidung, das Geld, die Annahmen und die Grenzen.

Der Wert einer Schwelle tt addiert, was die Entscheidung bei den richtig Positiven einbringt, und zieht die Kosten jeder Fehlerart ab. Im durchgehenden Beispiel ist es eine binäre Entscheidung; jedes Team passt sie an sein eigenes Thema an. Bei der gewählten Schwelle auf dem Validierungsdatensatz abgelesen und auf ein Jahresvolumen hochgerechnet, ergibt er die Zahl, nach der ein Entscheidungsträger zuerst fragt.

V(t)=∑i[gi 1{si≥t, yi=1}−cFP 1{si≥t, yi=0}−cFN 1{si<t, yi=1}]V(t) = \sum_i \Big[ g_i\,\mathbf{1}\{s_i \ge t,\, y_i = 1\} - c_{FP}\,\mathbf{1}\{s_i \ge t,\, y_i = 0\} - c_{FN}\,\mathbf{1}\{s_i < t,\, y_i = 1\} \Big]
(2)

Fünf Bereiche, in dieser Reihenfolge

  1. Die erbetene Entscheidung. Ein Satz: diesen Score mit dieser Schwelle in diesem Geltungsbereich einsetzen.
  2. Der Gewinn. Was das Modell pro Jahr im Vergleich zum Verzicht auf ein Modell einbringt, abgelesen an der Gewinnkurve.
  3. Die Annahmen. Kosten jedes Fehlers, Schwelle, Volumen und Basisrate, sichtbar, damit der Leser erkennt, wovon die Zahl abhängt.
  4. Die Überprüfung. Der A/B-Test, der das Versprechen überprüfen wird: Stichprobenumfang pro Arm, Dauer und Abbruchregel.
  5. Die Grenzen. Fairness, Drift, wie oft sich das Modell enthält und was die Daten nicht abdecken.

Testen Sie es vor der Abgabe an einer fachfremden Person. Das Memo hat bestanden, wenn diese Person die Anfrage und den erwarteten Gewinn in einem einzigen Satz wiedergeben kann; andernfalls braucht es eine weitere Fassung.

Zurück zum Inhalt.

Ein Vorhersage-Service ist ein Vertrag, kein Notebook hinter einer Route

Ein Service verspricht, was er annimmt, was er zurückgibt und wie schnell, und Integrationstests prüfen diese Versprechen bei jedem Push.

Die Vorlage stellt mit FastAPI drei Routen bereit: /predict, /health und /model-info, und davor sitzt eine Streamlit- oder Gradio-Seite für Menschen. Der Eingabevertrag ist ein typisiertes pydantic-Schema, in dem jede Variable einen Typ und einen Wertebereich hat, sodass ein Alter von 250 mit einer klaren Meldung abgewiesen wird, bevor es das Modell erreicht. Deployment und Observability im Allgemeinen behandelt die Notiz Data Engineering, SRE und Cloud.

Vier Integrationstests, die sich lohnen

  1. Eine geschäftliche Eigenschaft. Im Kreditbeispiel darf der Ausfallscore nicht sinken, wenn der Zahlungsverzug steigt, bei sonst gleichen Bedingungen; ein Verstoß ist entweder ein Fehler oder ein Befund, der ins Protokoll gehört. Das ist ein eigenschaftsbasierter Test (property-based test).
  2. Geladen gleich trainiert. Das vom Service geladene Modell liefert genau dieselben Vorhersagen wie das trainierte Modell.
  3. Enthaltung. Wenn die konforme Vorhersagemenge zu breit ist, antwortet der Service, dass er es nicht weiß, statt zu raten.
  4. Identität. Die Routen für Health und Model-Info geben die Modellversion und den Hash der Trainingsdaten zurück.

Latenz wird gemessen, nicht behauptet: Median und 95. Perzentil über tausend Aufrufe im Entwicklungscontainer, in der Modellkarte festgehalten, zusammen mit der Maschine, auf der sie entstanden sind. Das ist die erste Frage, die das Team stellen wird, das das Modell betreibt.

Zurück zum Inhalt.

Vier wiederkehrende Fallstricke und was die Produktion verlangt

Die meisten gescheiterten Abgaben scheitern an Nachvollziehbarkeit und Portabilität statt an der Modellierung, und für jeden Fallstrick gibt es eine Prüfung mit geringem Aufwand, die ihn aufdeckt.

Fallstrick 1 in Zahlen: ein Bericht, der das Repository nicht beschreibt

  1. Im Bericht steht 0,781. Die AUC wurde von Hand aus einem früheren Lauf des Modells abgetippt.
  2. Das Repository liefert 0,774. Ein erneuter Lauf des Vergleichs schreibt diesen Wert in die Ergebnisdatei.
  3. Der Abstand beträgt 0,007. Er überschreitet die Toleranz von 0,005, mit der die kontinuierliche Integration die Stabilität der Ergebnisse prüft.
  4. Die Korrektur. Die Tabellen aus der Ergebnisdatei neu erzeugen, Datei und Schlüssel zitieren und beide vor der Abgabe per Diff vergleichen.
  • Ein Service, der nur auf dem Laptop seines Autors läuft, mit einem absoluten Pfad oder einem Paket außerhalb der Lock-Datei. Ein anderes Team führt das Serve-Target und die Service-Tests im Entwicklungscontainer aus.
  • Ein Überwachungsplan ohne Schwelle und ohne verantwortliche Person. Für jeden Indikator ein Wert, eine Maßnahme, eine Person.
  • Ein Memo, das die Grenzen verschweigt. Lesen Sie es Seite an Seite mit dem Abschnitt „Grenzen“ des Berichts.

In einer Bank geht ein Scoring-Modell nie direkt von einem Notebook zu einer Entscheidung. Die Entwicklung liefert Code, Tests und Protokoll. Die unabhängige Validierung, ein Team, das das Modell nicht gebaut hat, geht Daten, Data Leakage und Vergleich erneut durch und muss die Zahlen reproduzieren. Ein Ausschuss genehmigt das Modell mit einer Schwelle, einem Geltungsbereich und Grenzen. Das Deployment bringt einen Eingabevertrag, eine Latenz und eine nachvollziehbare Version, und die Überwachung dauert Jahre. Die Abgabe ist eine verkleinerte Fassung dieses Wegs, und die anschließende mündliche Verteidigung beschreibt die Notiz zur Projektverteidigung. Im Vorstellungsgespräch werden wenige nach Ihrer AUC fragen; sie werden fragen, wie sie validiert wurde und was passiert, wenn Drift eintritt.

Zurück zum Inhalt.

Das Wichtigste in Kürze

  1. Eine Abgabe wird danach beurteilt, was andere damit tun können: sie erneut ausführen, abfragen, lesen und entscheiden.
  2. Behalten Sie die Repository-Vorlage der früheren Meilensteine bei; ein Befehl pro Aufgabe und eine grüne kontinuierliche Integration sind die Eintrittskarte.
  3. Jede Zahl im Bericht nennt die Datei und den Schlüssel, aus denen sie stammt; eine eingetippte Zahl gilt als falsch, bis das Gegenteil bewiesen ist.
  4. Jedes Dokument hat einen Leser und eine Aufgabe: Modellkarte, Datenblatt, Überwachungsplan, AI-Act-Lückenanalyse, Kundenmemo, Entscheidungsprotokoll.
  5. Ein Service ist ein Vertrag: typisierte Eingaben mit Wertebereichen, eine durch Tests abgesicherte geschäftliche Eigenschaft, Enthaltung bei Unsicherheit, gemessene Latenz.
  6. Ein Überwachungsplan ohne Schwellen und Verantwortliche oder ein Memo ohne Grenzen ist nicht fertig.

Glossar

Projektsteckbrief (scope document)
Die abgestimmte Festlegung von Entscheidung, Zielvariable, Metrik, Leitplanken, Daten und Plan.
Modellkarte (model card)
Ein kurzes Dokument, das Verwendungszwecke, Metriken, Grenzen, Fairness-Prüfungen und Latenz eines Modells angibt.
Datenblatt (datasheet)
Ein Dokument über Herkunft, Erhebung, Lizenz und Lücken eines Datensatzes.
Drift
Eine Veränderung der Eingaben oder ihres Zusammenhangs mit der Zielvariable im Lauf der Zeit, die die Leistung schmälert.
Populationsstabilitätsindex (population stability index, PSI)
Ein Maß dafür, wie weit sich die in Klassen eingeteilte Verteilung einer Variable seit dem Training verschoben hat.
konforme Vorhersage (conformal prediction)
Eine Methode, die Vorhersagemengen mit garantierter Überdeckungsrate liefert.
Enthaltung
Das Modell verzichtet auf eine Antwort, wenn seine Unsicherheit zu groß ist.
eigenschaftsbasierter Test (property-based test)
Ein Test, der prüft, ob eine Regel für viele generierte Eingaben gilt.
Gewinnkurve (profit curve)
Der Geldwert der Entscheidung in Abhängigkeit von der Schwelle.
kontinuierliche Integration (continuous integration, CI)
Automatische Tests und Prüfungen, die bei jedem Push laufen.
Lückenanalyse (gap analysis)
Ein Vergleich zwischen dem, was eine Verordnung verlangt, und dem, was das Projekt liefert.

Die anderen Notizen des Kurses

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

  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: .