Tag 5 - GenAI-gestütztes Machine Learning

Generative AI for Managers - TUHH Institute of Entrepreneurship · Teil meines Technology-Management-MBA · Lernnotizen zur Wiederholung.

Die Tage 1 bis 4 drehten sich um Text: LLMs verstehen, sie mit Prompts steuern, sie in Dokumenten verankern (RAG) und sie handeln lassen (Agenten). Tag 5 ist ein anderes Kaliber. Hier geht es um Vorhersage aus Tabellen voller Zahlen - genau die Art von Frage, die eine Tabelle voller Kundinnen und Kunden aufwirft: Wer von diesen Menschen kündigt im nächsten Quartal? Wie viel ist jede und jeder wert? Wo sollten wir unsere begrenzte Aufmerksamkeit investieren?

Diese Aufgabe gehört ins Machine Learning (ML), nicht zu einem Chatbot. Doch hier kommt der Kniff, der daraus einen GenAI-Kurs macht: GenAI übernimmt nicht das Vorhersagen - es macht den gesamten ML-Prozess auch für Nicht-Programmierende zugänglich. Es hilft, das Problem zu formulieren, die Daten zu bereinigen, den Code zu schreiben, die Ergebnisse zu lesen und sie der Chefin oder dem Chef zu erklären. Das gedankliche Modell für den ganzen Tag lautet also:

Mensch (Managerin/Manager) + ML-Modell + GenAI-Copilot. Das ML-Modell erzeugt die Zahl. GenAI hilft dabei zu entscheiden, welche Zahl zu berechnen ist, wie man sie berechnet und wie man sie erklärt.

Zwei verschiedene “KI-Aufgaben”

Die nützlichste Idee zum Einstieg: GenAI und prädiktives ML lösen unterschiedliche Probleme. Sie zu verwechseln ist der klassische Anfängerfehler.

Wenn dein Problem klingt wie…	Das richtige Werkzeug	Was herauskommt
”Schreib / fasse zusammen / formuliere das um”	LLM (GenAI)	Text in natürlicher Sprache
”Finde die Antwort in unseren Dokumenten”	RAG (Tag 3)	Eine belegte Antwort mit Quellen
”Entscheide etwas anhand einer Datentabelle”	Supervised ML	Eine Zahl: eine Wahrscheinlichkeit oder eine Vorhersage
”Reihe Tausende Kundinnen und Kunden, ziel auf die besten”	ML + Entscheidungsregeln	Eine Rangliste + wer angesprochen wird

GenAI ist brillant bei unstrukturierter Arbeit (Sprache). Prädiktives ML ist brillant bei strukturierten Entscheidungen (Zeilen und Spalten - Zahlen, Kategorien, Daten): Ranking, Targeting, Prognosen, Risikobewertung. Sie sind Teamkollegen, keine Rivalen.

Warum das gerade jetzt wichtig ist: ML war traditionell hinter Data Scientists verschlossen - teuer einzustellen, langsam in der Iteration, und ihre Ergebnisse müssen erst übersetzt werden, bevor eine Managerin oder ein Manager handeln kann. GenAI + AutoML (dazu später mehr) senkt diese Mauer, sodass Menschen wie ich sinnvoll an einem ML-Projekt teilnehmen können, statt am Ende nur eine Folie zu erhalten.

Was Machine Learning tatsächlich ist

Normales Programmieren: Ein Mensch schreibt die Regeln, gibt Daten hinein und erhält Antworten. Machine Learning dreht die Mitte und das Ende um:

KlassischRegeln + Daten → Antworten

↔

Machine LearningDaten + Antworten → Regeln (Muster)

Man bringt einem Kind Hunde nicht bei, indem man jede Rasse aufzählt. Man zeigt ihm Hunderte Hunde, und es lernt das Muster. ML lernt aus Beispielen, nicht aus handgeschriebenen Regeln.

Für das Business zählen vor allem zwei Familien:

Familie	Was sie tut	Business-Beispiel	Ausgabe
Supervised	Aus gelabelten Beispielen lernen (wir kennen die Antwort bereits)	Churn-Vorhersage, Betrugserkennung, Prognosen	”Diese Kundin hat eine 78%ige Chance zu kündigen”
Unsupervised	Muster in ungelabelten Daten finden	Kundensegmentierung, Anomalieerkennung	”Diese 5 Gruppen verhalten sich unterschiedlich”

Heute geht es fast ausschließlich um Supervised Learning, das sich selbst in zwei Zweige teilt - und wir nutzen beide:

Classification (Klassifikation)
Regression

Frage: welche Kategorie? Die Antwort ist eine Klasse, meist als Wahrscheinlichkeit geliefert. Unser Beispiel: Wird diese Kundin kündigen - ja oder nein? → p(churn), z. B. 0,78.

Der Business Case: Churn + Wert = gefährdeter Umsatz

Unser durchgehendes Beispiel für den ganzen Tag ist Kundenabwanderung (Churn = eine Kundin/ein Kunde, die/der geht bzw. kündigt) bei einem Telekommunikationsunternehmen. Aber hier kommt der entscheidende Management-Punkt:

Ein Churn-Modell ist nur nützlich, wenn es mit einer Handlung verbunden ist - einen Rabatt anbieten, anrufen, den Service verbessern oder nichts tun. Vorhersage ohne Entscheidung ist Trivia.

Und um gut zu entscheiden, reicht eine einzige Zahl nicht. Eine Kundin mit hohem Risiko ist vielleicht günstig zu verlieren; eine Kundin mit mittlerem Risiko ist vielleicht der wertvollste Account. Deshalb kombinieren wir zwei Vorhersagen:

Risikop(churn) - Classification

Wertmonatliche Gebühren - Regression

Gefährdeter Umsatzwen priorisieren

Gefährdeter Umsatz = p(churn) × vorhergesagter monatlicher Wert. Diese eine Formel ist die Brücke zwischen dem Classification-Modell und dem Regression-Modell - und genau das, was Managerinnen und Manager wirklich interessiert: wo das Geld liegt, nicht nur wer nervös ist.

Eine winzige Übung zur Entscheidungsregel, die zeigt, warum die Wahrscheinlichkeit allein zum Handeln führt. Nehmen wir an, ein Bindungsangebot kostet 10 €, und einen Abwanderer zu verlieren kostet 150 €. Es lohnt sich, das Angebot zu machen, wenn der erwartete vermiedene Verlust die Kosten übersteigt:

Angebot machen, wenn p(churn) × 150 > 10, also wenn p(churn) > 10/150 ≈ 0,067.

Also rechtfertigt hier schon eine Churn-Wahrscheinlichkeit von 7 % ein 10-€-Angebot. Der “richtige” Schwellenwert ist eine betriebswirtschaftliche Zahl (Kosten und Kapazität), kein technischer Standardwert - ein Thema, auf das wir immer wieder zurückkommen.

Die Daten - und die Fallen, die eine Managerin kennen muss

Der Telco-Datensatz umfasst rund 7.000 Kundinnen und Kunden und Spalten wie: Demografie (Senior, Partner), Dienste (Internet, Streaming, Telefon), Vertrag & Abrechnung (Vertragsart, Zahlungsmethode), ein Alters-Proxy (tenure = Monate als Kunde), Geld (MonthlyCharges, TotalCharges) und das Target (Churn: Yes/No).

Echte Daten sind chaotisch, und du solltest diese Probleme erwarten:

Fehlende Werte (z. B. TotalCharges leer bei brandneuen Kundinnen und Kunden).
Gemischte Typen (Text und Zahlen zusammen).
Klassenungleichgewicht (Class Imbalance) - meist deutlich weniger Abwanderer als Bleibende (hier ~27 % Churn). Das untergräbt leise die naive Genauigkeit (unten erklärt).
Leakage - die einzige gefährlichste Falle.

Der Supervised-Learning-Workflow

Jedes ML-Projekt - Churn, Nachfrage, Betrug - folgt ungefähr denselben sechs Schritten:

Problem definierenBusiness-Frage → ML-Aufgabe

→

Sammeln & bereinigenkorrigieren, zusammenführen, imputieren

→

Features bauenPrädiktoren erzeugen

→

Trainieren & tunendas Modell anpassen

→

Bewertenauf zurückgehaltenen Daten

→

Deployen & überwachenauf Drift achten

Der ML-Workflow. GenAI kann bei jedem einzelnen dieser Schritte unterstützen - und AutoML automatisiert den Trainieren-und-Tunen-Teil in der Mitte.

Training/Test Split und Over- vs. Underfitting

Wir müssen wissen, ob ein Modell auf neue Kundinnen und Kunden generalisiert und nicht nur die auswendig gelernt hat, die es kannte. Also teilen wir die Daten auf:

Training Set - verwendet, um das Modell anzupassen.
Test Set - bis ganz zum Schluss weggeschlossen, dann einmalig als realistisches Zeugnis genutzt.

Jedes Modell lebt in einer Spannung zwischen zwei Fehlermodi:

Fehler	Spitzname	Wie er aussieht
Underfitting (hoher Bias)	Zu einfach	Schlecht auf beiden, Trainings- und Testdaten - z. B. für alle dasselbe Churn-Risiko vorhersagen
Overfitting (hohe Varianz)	Zu komplex	Großartig im Training, schlecht im Test - hat das Rauschen auswendig gelernt

Das Ziel ist der Sweet Spot: komplex genug, um echte Muster zu erfassen, einfach genug, um übertragbar zu sein. Genau deshalb bauen wir Modelle in einer Leiter von einfach zu komplex (siehe unten) und fügen Komplexität nur hinzu, wenn das Test Set beweist, dass sie hilft.

Pipelines: ein sauberer, leakage-sicherer Prozess

Ein zuverlässiges ML-System ist nicht “ein Modell” - es ist eine Pipeline, die immer dieselben Schritte in derselben Reihenfolge ausführt: fehlende Werte füllen → Kategorien in Zahlen kodieren → (bei Bedarf skalieren) → vorhersagen. Das alles in ein Objekt zu bündeln, ist es, was Leakage aus dem Test Set verhindert und Ergebnisse reproduzierbar macht.

# A minimal scikit-learn pipeline: preprocessing + model in one object
from sklearn.compose import ColumnTransformer
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import OneHotEncoder
from sklearn.impute import SimpleImputer
from sklearn.linear_model import LogisticRegression

preprocess = ColumnTransformer([
    ("num", SimpleImputer(strategy="median"), numeric_cols),
    ("cat", Pipeline([
        ("impute", SimpleImputer(strategy="most_frequent")),
        ("onehot", OneHotEncoder(handle_unknown="ignore")),
    ]), categorical_cols),
])

model = Pipeline([("prep", preprocess),
                  ("clf", LogisticRegression(max_iter=1000))])

GenAI trifft ML: zwei Motoren, die zusammenarbeiten

Das ist das Herzstück von Tag 5. GenAI ersetzt das Modell nicht - es beseitigt die Reibung bei jedem Schritt. Stell dir zwei Motoren vor:

AutoML übernimmt die mechanische Komplexität - Algorithmen ausprobieren, Einstellungen tunen, Modelle vergleichen.
GenAI übernimmt die kognitive Komplexität - die Daten verstehen, Features vorschlagen, Ergebnisse in verständlichem Deutsch erklären.

Workflow-Schritt	Der alte Weg	Mit einem GenAI-Copiloten
Problem definieren	Lange Meetings zwischen Business- & Datenteams	LLM hilft, eine Business-Frage in eine ML-Aufgabe zu übersetzen
Daten verstehen	Code schreiben, Diagramme mustern	Datensatz beschreiben; LLM markiert Qualitätsprobleme & Leakage
Features bauen	Experten-Brainstorming + manuelles Coden	LLM schlägt Features aus Domänenwissen vor + schreibt den Code
Trainieren & tunen	Data Scientist wählt & tunt von Hand	AutoML sucht; LLM entwirft den Pipeline-Code
Bewerten	Data Scientist liest Metriken	LLM erklärt Metriken in Business-Begriffen, mit Kostenbezug
Kommunizieren	Analyst schreibt den Management-Bericht	LLM entwirft Zusammenfassung, Vorbehalte und Empfehlungen

GenAI für das Verstehen von Daten und das Erfinden von Features

Bevor du irgendetwas baust, beschreibst du dem LLM deinen Datensatz - Spaltennamen, Typen, ein paar Beispielzeilen - und fragst, was ihm auffällt. Oft bemerkt es, dass TotalCharges bei neuen Kundinnen und Kunden leer sein kann, dass eine breite Spanne bei MonthlyCharges auf Service-Stufen hindeutet, oder dass zu viel Class Imbalance bedeutet, dass “für alle kein Churn vorhersagen” trügerisch genau aussehen wird.

Feature Engineering - bessere Prädiktor-Spalten aus den rohen Spalten erfinden - ist traditionell der schwierigste, kreativste Teil des ML. Es ist zugleich der Bereich, in dem ein LLM glänzt, weil es Millionen von Business-Dokumenten “gelesen” hat. Du fragst nach Ideen als strukturiertes JSON (ein direkter Rückgriff auf Tag 2), damit du sie programmatisch nutzen kannst:

# Ask the model for derived-feature ideas, returned as clean JSON
resp = client.models.generate_content(
    model="gemini-2.5-flash-lite",
    contents="""I'm predicting telecom churn. Columns: tenure, monthly_charges,
    total_charges, contract, payment_method, internet_service, num_support_tickets.
    Suggest 8 derived features. Return JSON objects with:
    "feature_name", "formula", "rationale".""",
    config=types.GenerateContentConfig(response_mime_type="application/json"),
)

Typische Vorschläge: is_new_customer (Vertragsdauer unter 6 Monaten - neue Kundinnen und Kunden churnen häufiger), support_ticket_rate (Tickets ÷ Vertragsdauer) oder is_month_to_month (keine Bindung = leicht zu gehen).

Die Modell-Leiter: einfach → stark → am besten

Ein zentrales Management-Prinzip: transparent beginnen, Komplexität nur hinzufügen, wenn sie sich lohnt. Für Churn (Classification) klettern wir eine dreistufige Leiter hinauf. Zuerst schlägt man immer eine dumme Baseline (z. B. “immer keinen Churn vorhersagen” oder “Month-to-month = Churn”) - wenn ein ausgefallenes Modell eine naive Regel nicht schlagen kann, sollte es nicht in Produktion gehen.

Modell	Wie es funktioniert (verständlich erklärt)	Interpretierbarkeit	Typische Leistung	Worauf achten
Logistic Regression	Gewichtete Summe der Features → in eine 0-1-Wahrscheinlichkeit gepresst	Hoch - jedes Feature-Gewicht ablesbar	Gute Baseline	Findet nur einfache Muster
Random Forest	Hunderte Entscheidungsbäume auf zufälligen Datenausschnitten, gemittelt	Mittel	Stark direkt ab Werk	Wenig Tuning nötig
Gradient Boosting	Bäume nacheinander gebaut, jeder korrigiert die Fehler des vorherigen	Mittel (SHAP nutzen)	Oft das beste bei Tabellen	Braucht Tuning; kann overfitten

Ein paar Intuitionen, die es sich mitzunehmen lohnt:

Logistic Regression gibt jedem Feature einen ablesbaren Koeffizienten: “Ein Month-to-month-Vertrag addiert +1,2 zum Churn-Score; ein Zweijahresvertrag zieht 0,8 ab.” Diese Transparenz ist der Grund, warum es der natürliche Ausgangspunkt ist.
Ein einzelner Entscheidungsbaum ist bloß ein Flussdiagramm aus Ja/Nein-Fragen (“Ist der Vertrag Month-to-month?” → “Ist die Vertragsdauer kurz?”). Intuitiv, aber ein einzelner Baum ist instabil - stupse die Daten an, und du bekommst einen völlig anderen Baum.
Ein Random Forest behebt diese Instabilität, indem er viele vielfältige Bäume baut und mittelt, sodass sich ihre einzelnen Fehler ausgleichen (dieser Mittelungs-Trick heißt Bagging).
Gradient Boosting ist noch cleverer: Jeder neue Baum wird auf den verbleibenden Fehlern aller vorherigen Bäume trainiert, sodass das Modell immer weiter seine eigenen Schwachstellen ausbessert. Es gewinnt bei tabellarischen Daten meist - auf Kosten sorgfältigen Tunings.

Genau dieselbe Leiter funktioniert auf der Regression-Seite (Vorhersage von MonthlyCharges): Lineare Regression → Random-Forest-Regressor → Gradient-Boosting-Regressor.

Modelle so bewerten, wie es eine Managerin tun sollte

Dieser Abschnitt ist der, in dem Managerinnen und Manager den größten Mehrwert liefern - denn die naheliegende Metrik ist meist die falsche.

Die Confusion Matrix (vier Kästchen)

Jede Ja/Nein-Vorhersage landet in einem von vier Kästchen:

	Vorhergesagt: wird kündigen	Vorhergesagt: bleibt
Hat tatsächlich gekündigt	True Positive (erwischt)	False Negative (verpasst)
Ist tatsächlich geblieben	False Positive (Fehlalarm)	True Negative (korrekt ignoriert)

In Management-Sprache: Ein False Positive bedeutet, dass du Aufwand in jemanden gesteckt hast, der nie gehen wollte (verschwendete Kosten); ein False Negative bedeutet, dass ein echter Abwanderer durchgerutscht ist (verlorener Umsatz). Welcher Fehler mehr schmerzt, ist eine betriebswirtschaftliche Frage.

Warum Genauigkeit lügt

Also nutzen wir Metriken, die das Ziel tatsächlich widerspiegeln:

Metrik	Bedeutung in Klartext	Wann sie am wichtigsten ist
Precision	”Wenn wir jemanden markieren, wie oft liegen wir richtig?”	Wenn Fehlalarme teuer sind (verschwendete Angebote)
Recall	”Von allen echten Abwanderern, wie viele haben wir erwischt?”	Wenn das Verpassen eines Abwanderers teuer ist
F1 Score	Ein einzelner Wert, der nur hoch ist, wenn sowohl Precision als auch Recall hoch sind	Wenn beide Fehlerarten zählen und Churn selten ist
ROC-AUC	”Chance, dass das Modell einen zufälligen Abwanderer über einen zufälligen Bleibenden reiht” (1,0 = perfekt, 0,5 = Münzwurf)	Modelle breit vergleichen; ausgewogene Klassen
PR-AUC	Gesamt-Ranking-Qualität mit Fokus auf die seltene Positiv-Klasse	Die ehrliche Wahl bei Churn/Betrug (unausgewogen)

Warum F1 einen “harmonischen Mittelwert” statt eines einfachen Durchschnitts nutzt: Stell dir 95 % Precision, aber nur 10 % Recall vor (super wählerisch, erwischt fast niemanden). Ein einfacher Durchschnitt sagt 52,5 % - klingt in Ordnung. F1 meldet korrekt ~18 % und legt offen, dass das Modell zum tatsächlichen Finden von Abwanderern nahezu nutzlos ist. F1 lässt sich von einer einzigen guten Zahl nicht täuschen.

Warum ROC zu rosig aussehen kann und PR bei Churn ehrlicher ist: Die False-Positive-Rate von ROC wird durch die riesige Menge der Bleibenden verwässert, sodass eine moderate Anzahl Fehlalarme sie kaum bewegt - dasselbe Modell könnte ROC-AUC 0,87 (sieht großartig aus) aber PR-AUC 0,68 (nüchterner) zeigen. PR betrachtet nur die Kundinnen und Kunden, die du tatsächlich markiert hast, sodass jeder Fehlalarm wehtut. Berichte beide; entscheide bei unausgewogenen Problemen anhand von PR-AUC.

Schwellenwerte sind eine betriebswirtschaftliche Entscheidung

Das Modell gibt eine Wahrscheinlichkeit aus; du wählst den Grenzwert, der daraus ein Ja/Nein macht. Der Standard von 0,5 ist willkürlich. Senke den Schwellenwert, und du markierst mehr Menschen - fängst mehr Abwanderer (höherer Recall), aber mit mehr Fehlalarmen (niedrigere Precision). Gleiches Modell, anderer Schwellenwert → eine völlig andere Anrufliste. Wähle ihn anhand von Kosten und Kapazität, nicht anhand eines Lehrbuch-Standards.

Lift und Dezile - die managerfreundlichste Sicht

AUC-Werte dienen dem Vergleich von Modellen. Aber die eigentliche Frage einer Managerin ist konkret: “Ich kann diese Woche nur 500 Kundinnen und Kunden anrufen - wie viele Abwanderer erwische ich?” Genau das beantwortet Lift.

Reihe alle nach vorhergesagtem Risiko, teile sie in zehn gleich große Gruppen (Dezile) und vergleiche mit zufälligem Anrufen:

Kontaktiere die obersten 10 % → das Modell erfasst, sagen wir, 52 % aller Abwanderer (zufällig wären es 10 %). Das ist ein Lift von ~5,2×.
Kontaktiere die obersten 30 % → erfasse ~88 % der Abwanderer.
Ab Dezil 4 fällt der Lift unter 1,0 - diese Kundinnen und Kunden churnen seltener als der Durchschnitt, sie anzurufen verschwendet also Aufwand.

Lift bildet sich direkt auf die operative Kapazität ab, weshalb Führungskräfte ihn lieben: Er sagt dir, ob deine begrenzten 500 Anrufe 5× mehr Abwanderer finden als der Zufall oder einen Münzwurf kaum schlagen.

Regressionsmetriken (für das Wertmodell)

Metrik	Übersetzung für Managerinnen und Manager	Am besten für
MAE (mittlerer absoluter Fehler)	“Im Schnitt liegen wir um 8,50 € daneben”	Kommunikation mit Stakeholdern - am intuitivsten
RMSE (Wurzel des mittleren quadratischen Fehlers)	“Typischer Fehler, bestraft aber große Ausreißer”	Gelegentliche wilde Vorhersagen aufdecken
R²	”Das Modell erklärt 75 % der Variation”	Modelle vergleichen (für Nicht-Fachleute weniger intuitiv)

Lass GenAI die Zahlen übersetzen

Statt einer Führungskraft eine Tabelle voller Metriken hinzulegen, kannst du das LLM bitten, sie zu erklären - aber erst, nachdem du sie tatsächlich berechnet hast:

# Feed REAL metrics; ask for a plain-language, cost-aware explanation
resp = client.models.generate_content(
    model="gemini-2.5-flash-lite",
    contents="""Explain these churn results to a non-technical VP. Cover what the
    model catches, what it misses, and the precision/recall trade-off, in concrete
    numbers. Accuracy 82%, Precision 71%, Recall 65%, 1,400 test customers.""",
)

Vorhersagen mit SHAP erklären

Ein Modell, das Churn vorhersagt, ist nützlich. Ein Modell, das erklärt, warum, ist weit wertvoller - denn es sagt dir, was zu tun ist, und es erlaubt dir, die Entscheidung zu verteidigen (entscheidend in regulierten Umfeldern).

SHAP (SHapley Additive exPlanations) borgt eine Idee der fairen Anteilszuweisung aus der Spieltheorie: Wenn ein Team ein Ergebnis erzielt, wie teilt man den Beitrag fair unter den Spielern auf? SHAP behandelt jedes Feature als Spieler und die Vorhersage als Ergebnis des Teams und errechnet, wie stark jedes Feature diese spezifische Vorhersage vom Durchschnitt weggeschoben hat.

Für eine einzelne Kundin wird die Vorhersage additiv aus der Basislinie aufgebaut:

prediction = average prediction + contribution₁ + contribution₂ + … + contributionₙ

Jeder Beitrag ist eine vorzeichenbehaftete Zahl - positiv schiebt Richtung Churn, negativ zieht Richtung Bleiben.

Global (was treibt Churn insgesamt?)
Local (warum DIESE Kundin?)

Aggregiere SHAP über alle Kundinnen und Kunden, und du erhältst ein gereihtes Bild dessen, worauf sich das Modell stützt, z. B.:

Month-to-month-Vertrag · 0,18Vertragsdauer · 0,15Support-Tickets · 0,12monatliche Gebühren · 0,09

Es beantwortet: “Was treibt das Churn-Risiko in unseren Daten - und sind diese Treiber sinnvoll?”

Dann verwandelt GenAI SHAP in Worte - globale Treiber in eine empfohlene Strategie, oder die Beiträge einer einzelnen Kundin in eine zweizeilige Notiz für die Kundenbetreuung: “Markiert wegen eines Month-to-month-Vertrags, sehr kurzer Vertragsdauer und vier kürzlichen Support-Tickets; vorgeschlagene Maßnahme: einen vergünstigten Jahresplan anbieten.”

AutoML: Autopilot für die Modellauswahl

AutoML automatisiert die mechanischen Teile - mehrere Algorithmen ausprobieren, ihre Einstellungen tunen und sie kombinieren -, um schnell ein starkes Modell zu bekommen. In den Labs kannst du es mit einem winzigen Zeitbudget laufen lassen und mit deiner handgebauten Pipeline vergleichen:

from flaml import AutoML
automl = AutoML()
automl.fit(X_train, y_train, task="classification",
           metric="ap",        # average precision ≈ PR-AUC
           time_budget=60)      # give it 60 seconds

AutoML wählt ein Modell; es liefert kein Urteilsvermögen. Bevor du irgendeinem Leaderboard-”Sieger” vertraust, prüfe:

Entscheidung & Kosten - für welche Handlung ist das gedacht; was kosten ein False Positive und ein False Negative jeweils?
Validierung - gibt es ein echtes, zurückgehaltenes Test Set, das die Realität widerspiegelt?
Leakage-Scan - kodiert irgendein Feature Zukunftswissen?
Metrikwahl - PR-AUC / Lift für unausgewogenen Churn, nicht rohe Genauigkeit.
Erklärbarkeit - ergeben die SHAP-Treiber Sinn?
Stabilität & Monitoring - hält es über Segmente hinweg; was löst ein Neutrainieren aus?

Das übliche Versagen: Teams bringen den AutoML-Sieger in Produktion, dann bricht die Leistung im Produktivbetrieb wegen Leakage, Drift oder der falschen Metrik zusammen.

Faustregel des Kurses: Nutze AutoML als Benchmark, nachdem du eine transparente Baseline (Logistic/Linear) und ein starkes manuelles Modell (Forest/Boosting) gebaut hast - nicht als Ersatz für das Denken.

Von der Vorhersage zur Handlung (und wie man sie am Leben hält)

Ein Modell verdient sein Geld erst, wenn es verändert, was das Business tut. Ein einfaches Retention-Playbook:

Alle scoren - p(churn) für alle Kundinnen und Kunden berechnen.
Alle bewerten - den monatlichen Wert vorhersagen (Regression).
Nach gefährdetem Umsatz reihen = p(churn) × MonthlyCharges.
Reale Einschränkungen anwenden - Kontaktkapazität (z. B. 500 Anrufe/Woche), Berechtigungsregeln (keine Rabatte an Kundinnen und Kunden, die bereits in einer Promo sind).
Ein Experiment durchführen - den Retention-Angebot per A/B-Test prüfen und die inkrementelle Rettung messen, denn das Modell zeigt, wer gefährdet ist, nicht, was hilft.

Monitoring: Modelle verrotten leise

Ein Modell, das auf der Welt des Vorjahres trainiert wurde, verschlechtert sich lautlos, während die Welt weiterzieht. Das ist Drift, und eine Managerin sollte einen Monitoring-Plan vor dem Deployment einfordern.

Drift-Art	Was sich ändert	Wie man sie erkennt
Data Drift	Feature-Verteilungen verschieben sich (eine Kampagne spült neue Kundinnen und Kunden herein)	Feature-Histogramme vergleichen: Training vs. aktuell
Performance Drift	Genauigkeit/AUC sinkt langsam	Metriken auf einem gleitenden Fenster frischer Daten verfolgen
Calibration Drift	”30 % Risiko” bedeutet in der Realität nicht mehr 30 % Churn	Vorhergesagte vs. beobachtete Raten vergleichen
Concept Drift	Die Beziehung Feature→Ergebnis selbst ändert sich	Beobachten, ob sich die wichtigsten SHAP-Treiber über die Zeit verschieben

Die übliche Abhilfe, wenn Drift auftritt: auf jüngeren Daten neu trainieren.

Die letzte Meile: Ergebnisse kommunizieren

Du hast das Modell gebaut, die SHAP-Werte ergeben Sinn - aber jetzt stehst du der VP, dem CFO oder dem Vorstand gegenüber. Sie interessieren sich nicht für F1-Werte; sie interessieren sich für Umsatz und dafür, was zu tun ist. Hier schließt GenAI den Kreis und verwandelt Ausgaben in eine vorstandsreife Geschichte. Was Führungskräfte wirklich fragen:

Sie fragen…	Du gibst ihnen…
”Was habt ihr gefunden?"	"Wir können 65 % der Abwanderer erkennen, bevor sie gehen."
"Wie viel steht auf dem Spiel?"	"Diese vorhergesagten Abwanderer repräsentieren 1,2 Mio. € Jahresumsatz."
"Was sollten wir tun?"	"Drei priorisierte Retention-Maßnahmen, nach Segment."
"Wie sicher seid ihr?"	"Hoch für die obersten 50 Kundinnen und Kunden, moderat für die nächsten 100."
"Was könnte schiefgehen?"	"Trainiert auf 2024er-Daten; eine große Preisänderung könnte die Genauigkeit senken.”

Dieses Memo kannst du mit GenAI entwerfen - du fütterst es mit deinen echten Zahlen und bittest um einen strukturierten One-Pager (Kernbefund → Business-Auswirkung → empfohlene Maßnahmen → Sicherheit & Grenzen → nächste Schritte), ausgerichtet auf eine nicht-technische Leserschaft.

Die eigentliche Aufgabe des Managers (und die Grenzen von GenAI)

Wenn wir den ganzen Tag zusammenziehen: Der Mensch wird nicht wegautomatisiert - der Mensch stellt die Fragen und wacht über die Qualität.

Erfundene Ergebnisse - es könnte “AUC = 0,92” behaupten, ohne dass irgendetwas berechnet wurde. Wenn es nicht im Notebook lief, ist es nicht real.
Stilles Leakage - Features vorschlagen, die zum Entscheidungszeitpunkt nicht existieren.
Falsche Metrik - Genauigkeit bei einem unausgewogenen Problem optimieren.
Übertrieben selbstsichere Geschichten - Erzählungen, die nicht durch die tatsächlichen Plots/Metriken gestützt sind.

Nicht verhandelbare Regel: Alles, was GenAI vorschlägt, muss in deinem Notebook mit echten Ausgaben validiert werden - Metriken, Plots, gespeicherte Dateien. Daher das geforderte Copilot Log in den Labs: Notiere für jeden Prompt, was du gefragt, was du geändert und was du von Hand verifiziert hast. Anerkennung gibt es für validierte Verbesserungen, nicht für die Anzahl der Prompts.

Praxis: Labs & Aufgabe

Die Theorie sitzt erst, wenn du sie auf echten Daten laufen lässt. Alle drei Übungen nutzen den Telco-Churn-Datensatz in Google Colab, mit GenAI als Copilot fürs Coden, Debuggen und Interpretieren - nie zum Erfinden von Ergebnissen.

Guided Lab Churn- + Wertmodellierung mit erklärbarem ML. Lade und bereinige die Telco-Daten, baue eine leakage-sichere Preprocessing-Pipeline, trainiere und vergleiche alle drei Churn-Modelle mit managerfreundlichen Metriken (Lift + PR-AUC), füge ein MonthlyCharges-Regressionsmodell hinzu, erzeuge globale und lokale SHAP-Erklärungen und produziere eine gereihte Anrufliste nach gefährdetem Umsatz.

Independent Lab Von Vorhersagen zu Entscheidungen. Wähle eine Vertiefungsspur und treibe sie weiter: (A) Kosten- & Kapazitäts-Targeting (einen Schwellenwert nach Erwartungswert wählen), (B) Kalibrierung & Wahrscheinlichkeitsqualität (Kalibrierungskurve + Brier Score), (C) ein AutoML-Benchmark gegen deine manuellen Modelle, oder (D) ein Segment-Stresstest (hält das Modell über Vertragsarten und Vertragsdauer-Bänder?). Liefere verbesserte Berichte, eine finale Anrufliste und eine kurze Management-Empfehlung - plus ein Copilot Log.

Assignment 5 Model Card + Management-Empfehlung. Das benotete Ergebnis, das deine gewählte Spur fortführt: ein belastbarer Workflow mit explizitem Leakage-Scan, 5-facher Cross-Validation über alle Modelle, businessorientierter Bewertung (Lift, Schwellenwert gewählt per Kostenkurve, Kapazitätsplan), SHAP global + drei lokale Geschichten, eine Anrufliste nach gefährdetem Umsatz mit Begründungscodes und einem Monitoring-/Risikoplan. Reiche ein Notebook, eine Anruflisten-CSV, ein Metriken-JSON und ein einseitiges Management-Memo in verständlicher Business-Sprache ein.

Notebooks herunterladen (in Google Colab öffnen):

Meine eingereichte Lösung: Aufgabe 5 - mein gelöstes Notebook (.ipynb) - meine eigene Arbeit aus dem Kurs.

Wiederholungs-Zusammenfassung

Kernpunkt	Kurz gemerkt
Zwei KI-Aufgaben	GenAI übernimmt unstrukturierten Text; prädiktives ML übernimmt strukturierte Entscheidungen - Teamkollegen, keine Rivalen
Supervised Learning	Aus gelabelten Beispielen lernen: Classification (welche Kategorie) oder Regression (welche Zahl)
Features vs. Label	Features sind die Eingabespalten; das Label ist die Antwort, die wir vorhersagen
Gefährdeter Umsatz	`p(churn) × vorhergesagter Wert` - die Formel, die die beiden Modelle verbindet und das Targeting steuert
Leakage	Ein Feature, das das Modell zum Entscheidungszeitpunkt nicht hätte; sieht großartig aus, versagt dann in Produktion
Die 80/20-Regel	~80 % des ML-Aufwands sind Datenarbeit (Schritte 1-3), nur ~20 % ist Modellierung
Training/Test Split	Test Set = eine verschlossene Prüfung; eine große Lücke Training vs. Test bedeutet Overfitting
Over-/Underfitting	Overfit = Rauschen auswendig gelernt (super Training, schlechter Test); Underfit = zu einfach (schlecht auf beiden)
Modell-Leiter	Logistic (transparent) → Random Forest (starker Standard) → Gradient Boosting (oft am besten)
Genauigkeits-Falle	Bei unausgewogenen Daten schneidet “keinen Churn vorhersagen” hoch ab und ist nutzlos - nutze Precision/Recall/PR-AUC
Precision vs. Recall	Precision = richtig, wenn wir markieren; Recall = Anteil erwischter Abwanderer; F1 balanciert beide
Schwellenwert	Eine betriebswirtschaftliche Wahl aus Kosten/Kapazität - gleiches Modell, anderer Schwellenwert, andere Anrufliste
Lift	”Wie viele Male besser als der Zufall” für dein oberstes Dezil - bildet sich auf die Anrufkapazität ab
SHAP	Teilt eine Vorhersage fair in Beiträge je Feature auf; global (Treiber) + lokal (diese Kundin)
AutoML	Automatisiert Modellsuche & Tuning - ein schneller Benchmark, nie ein Ersatz für Urteilsvermögen
Drift	Modelle verfallen, während sich die Welt verschiebt; fordere vor dem Deployment einen Monitoring- & Retraining-Plan
Korrelation ≠ Kausalität	Ein Modell sagt, wer gefährdet ist, nicht was hilft - beweise die Wirkung mit einem Experiment
GenAI ist Copilot, nicht Pilot	Es setzt Rahmen, codet, interpretiert und kommuniziert - aber jede Behauptung muss mit echten Ausgaben validiert werden