Alle Eingaben sind klein, synthetisch und frei von Personenbezug. Die erwarteten Zahlen werden beim Validatorlauf durch ein gemeinsames Standardbibliothek-Skript geprüft. Schwellen und Mini-Datensätze demonstrieren Mechanik; sie sind keine universellen Produktionswerte.
Lab auswählen
19 von 19 Labs sichtbar.
Bearbeitungsmarken bleiben lokal im Browser und sind nur ein Lernsignal.
Lab 01SQL & DatenPython + SQLite :memory:
SQL-Grain vor dem Join sichern
Ziel: Zeige, wie ein One-to-many-Join Kennzahlen vervielfacht, und prüfe den erwarteten Grain vor der Aggregation.
Lab öffnen
Ziel & Voraussetzungen
Python 3 mit Standardbibliothek; keine externen Pakete und keine Dateiablage.
Schritte
Lege drei Vorgänge und vier Statuszeilen in einer In-memory-Datenbank an.
Zähle Rohzeilen nach dem Join und getrennte Vorgangs-IDs.
Aggregiere Status zuerst auf genau eine Zeile je Vorgang und wiederhole den Join.
Erwartetes Ergebnis
Naiver Join: 4 Zeilen für 3 Vorgänge; nach Voraggregation: 3 Zeilen und 3 eindeutige Vorgänge.
Interpretation
COUNT(*) beantwortet eine Zeilenfrage, COUNT(DISTINCT id) eine Einheitenfrage. Ohne expliziten Grain kann eine scheinbar korrekte SQL-Summe falsch sein.
Interviewfrage
Welche Einheit soll genau eine Ergebniszeile bilden, und welchen Assert setzt du direkt nach dem Join?
Fallstricke
DISTINCT kaschiert nicht jede falsche Multiplizität.
Ein technisch gültiger Join beweist keine fachlich korrekte Kardinalität.
Cleanup: Die :memory:-Verbindung wird geschlossen; es bleibt keine Datei zurück.
Ziel: Ordne jedem Ereignis nur den letzten damals bekannten Merkmalsstand zu und verhindere Zukunftsleakage.
Lab öffnen
Ziel & Voraussetzungen
Python 3; kleine synthetische Zeitstempel als ganze Tage.
Schritte
Sortiere Merkmalsstände je Entität nach Zeitpunkt.
Wähle pro Ereignis das Maximum snapshot_time ≤ event_time.
Vergleiche mit einem naiven Join auf den jeweils neuesten heutigen Stand.
Erwartetes Ergebnis
Die Ereignisse an Tag 3 und 8 erhalten die Werte 10 und 20; der heutige Latest-Join würde beiden fälschlich 20 geben.
Interpretation
Ein Feature muss relativ zum Entscheidungszeitpunkt verfügbar sein. Ein aktueller Stammdatenstand kann historische Evaluation unbemerkt optimistisch machen.
Interviewfrage
Welcher Zeitstempel beschreibt fachliche Gültigkeit, welcher technische Ankunft, und welcher war bei Inferenz verfügbar?
Fallstricke
Gleichheit am Grenzzeitpunkt braucht eine fachliche Regel.
Nachträgliche Korrekturen benötigen Bitemporalität oder einen reproduzierbaren Snapshot.
Cleanup: Nur konstante Listen im Prozess; kein Cleanup nötig.
Im echten Problem ist der fehlende Teil gerade unbekannt. Das Beispiel beweist nicht, welche Imputation richtig ist, sondern warum der Missingness-Prozess analysiert werden muss.
Interviewfrage
Wovon hängt Beobachtbarkeit ab, und welche Sensitivitätsanalyse würde deine Entscheidung kippen?
Fallstricke
MCAR, MAR und MNAR sind Annahmen, keine automatisch erkennbaren Labels.
Imputation vor dem Split kann Information zwischen Sets tragen.
Ziel: Vergleiche Random-Split und Vorwärts-Split, wenn ein Prozess sich zeitlich verändert.
Lab öffnen
Ziel & Voraussetzungen
Acht chronologisch sortierte Beobachtungen.
Schritte
Definiere Train als Tage 1–6 und Test als Tage 7–8.
Prüfe für jedes Trainingsfeature, ob dessen available_at ≤ Trainingsstichtag gilt.
Vergleiche mit einem Random-Split, der Tage 7–8 ins Training mischt.
Erwartetes Ergebnis
Vorwärts-Split enthält 0 Zukunftstage im Training; der vorgegebene Random-Split enthält 2.
Interpretation
Ein Random-Split beantwortet eine austauschbare-iid-Frage. Für zukünftige Entscheidungen muss die Evaluation die zeitliche Informationsgrenze imitieren.
Interviewfrage
Welche reale Cutoff-Zeit und welches Label-Delay bestimmen deinen letzten zulässigen Trainingsfall?
Fallstricke
Zeitliche Nähe kann über rollierende Aggregate leaken.
Ein einzelner Cutoff zeigt keine saisonale Stabilität.
Ziel: Übersetze Scores in eine Top-k-Policy und mache Bindungen sowie Kapazitätsgrenzen sichtbar.
Lab öffnen
Ziel & Voraussetzungen
Fünf Scores und Kapazität k = 2.
Schritte
Sortiere IDs stabil nach Score absteigend.
Wähle die ersten zwei statt eine willkürliche 0,5-Schwelle zu behaupten.
Berechne Precision@2 gegen die synthetischen Labels.
Erwartetes Ergebnis
Ausgewählt werden B und C; beide sind positiv, daher Precision@2 = 1,00 und Recall@2 = 2/3.
Interpretation
Top-k optimiert eine knappe Warteschlange, nicht automatisch Gesamtnutzen. Scorekalibrierung, Fairness und der Nutzen nicht ausgewählter Fälle bleiben separat.
Interviewfrage
Ist die Kapazität fix, und wie gehst du mit Score-Bindungen und schwankendem Volumen um?
Fallstricke
Auf dem Testset optimiertes k überfitten die Evaluation.
Ziel: Zeige, dass ein redundantes Feature einzeln unwichtig wirken kann, obwohl die gemeinsame Information entscheidend ist.
Lab öffnen
Ziel & Voraussetzungen
Vier binäre Beispiele mit zwei identischen Features und einer OR-Regel.
Schritte
Berechne Baseline-Accuracy mit beiden identischen Features.
Permutiere nur Feature A, während B unverändert bleibt.
Entferne beide Features und vergleiche den gemeinsamen Leistungseinbruch.
Erwartetes Ergebnis
Baseline und Einzelpermutation bleiben bei Accuracy 1,00; ohne beide Features fällt die definierte Majority-Baseline auf 0,50.
Interpretation
Korrelierte oder redundante Features können Einzelimportanzen teilen oder verdecken. Importance ist weder Kausalität noch automatisch eine lokale Erklärung.
Interviewfrage
Welche Vorhersagefunktion, welche Datenverteilung und welche Featureabhängigkeiten gelten für deine Erklärung?
Fallstricke
Permutation kann unrealistische Kombinationen erzeugen.
Testset wiederholt für Erklärungsentscheidungen zu nutzen kann es indirekt überfitten.
Cleanup: Fester Permutationsvektor; kein Zufallszustand.
Ziel: Zeige, warum Outcomes nur bei ausgewählten Fällen die Modellbewertung verzerren.
Lab öffnen
Ziel & Voraussetzungen
Sechs Fälle, von denen nur die drei höchsten Scores geprüft werden.
Schritte
Berechne Positivrate unter den drei geprüften Fällen.
Vergleiche mit der bekannten synthetischen Gesamtrate.
Skizziere Exploration oder unabhängige Stichprobe zur Identifikation.
Erwartetes Ergebnis
Geprüfte Positivrate = 2/3; Gesamtrate = 3/6 = 1/2; beobachtete Labels überschätzen hier die Prävalenz um 1/6.
Interpretation
Das Modell beeinflusst, wofür Labels entstehen. Ohne Logging der Auswahlwahrscheinlichkeit und Gegenstichprobe ist spätere Evaluation nicht repräsentativ.
Interviewfrage
Welche Entscheidung erzeugt dein Label, und wo erhältst du Outcomes außerhalb der Modellselektion?
Fallstricke
Mehr Retraining auf selektiven Labels kann den Loop verstärken.
Exploration muss ethisch und risikoadäquat gestaltet werden.
Ziel: Filtere Dokumente anhand expliziter Berechtigungen und behandle Dokumenttext als untrusted data statt Instruktion.
Lab öffnen
Ziel & Voraussetzungen
Drei synthetische Dokumente mit Rollenliste; eines enthält eine bösartige Textanweisung.
Schritte
Bestimme erlaubte Dokumente serverseitig für Rolle service.
Baue Kontext nur aus erlaubten IDs.
Prüfe, dass die bösartige Zeichenfolge weder Berechtigungen noch Toolaktionen verändert.
Erwartetes Ergebnis
Rolle service erhält genau die Dokumente public und service; admin bleibt ausgeschlossen. Die eingebettete Anweisung wird als Text markiert, nicht ausgeführt.
Interpretation
Prompt Injection ist keine reine Promptformulierungsfrage. Autorisierung, minimale Privilegien, Tool-Grenzen und Outputvalidierung liegen außerhalb des Modells.
Interviewfrage
Welche Kontrolle entscheidet unabhängig vom Modell über Dokument- und Aktionsrechte?
Fallstricke
RAG oder Fine-Tuning eliminieren Prompt Injection nicht.
Ein erlaubtes Dokument kann trotzdem manipulierten Inhalt enthalten.
Cleanup: Keine Netz- oder Toolaufrufe; nur lokale Strings.
Ziel: Treffe eine Guardrail-basierte Rollback-Entscheidung und hashe kanonische Inputs für einen reproduzierbaren Audit-Trail.
Lab öffnen
Ziel & Voraussetzungen
Zwei Modelversionen, Leistungs- und Fehlerraten sowie definierte Guardrails.
Schritte
Prüfe neue Version gegen Mindestleistung und maximale kritische Fehlerrate.
Wähle bei Verletzung die letzte freigegebene Version.
Serialisiere Entscheidungseingaben sortiert und berechne SHA-256.
Erwartetes Ergebnis
Die neue Version verletzt die kritische Fehlergrenze 0,02 mit 0,04; Entscheidung = rollback auf v1. Der SHA-256-Hash ist bei identischen Inputs stabil.
Interpretation
Rollback braucht vorab definierte Trigger, kompatible Artefakte und verantwortliche Freigabe. Ein Hash belegt Gleichheit der Inputs, nicht deren fachliche Richtigkeit.
Interviewfrage
Welche Signale lösen automatisches Stoppen, menschliche Eskalation oder Rollback aus, und wer besitzt die Entscheidung?
Fallstricke
Schema- oder Featureänderungen können einen technischen Rollback verhindern.
Nur Modellmetriken reichen bei Kunden- und Betriebsfolgen nicht.
Cleanup: Keine Dateien; kanonisches JSON wird nur im Speicher gehasht.
Ziel: Verbinde reife Outcome-Labels, richtige und schädliche Overrides sowie die Eskalationsqueue zu einem transparenten Stop- und Fallback-Urteil.
Lab öffnen
Ziel & Voraussetzungen
Zwölf vollständig synthetische Fälle, Monitoringstichtag Tag 10 und vier Tage simulierter Eskalationszufluss; keine APKV-Daten.
Schritte
Berechne Label-Coverage und End-to-end-Fehlerrate ausschließlich auf bis Tag 10 gereiften Outcomes; vergleiche zur Sensitivität mit der nur im synthetischen Lab bekannten späteren Vollsicht.
Trenne richtige Overrides, die einen Modellfehler korrigieren, von schädlichen Overrides, die einen richtigen Vorschlag verschlechtern.
Simuliere eine FIFO-Eskalationsqueue mit Ankünften [3, 3, 2, 1] und Kapazität 1 pro Tag; prüfe Coverage, Override-Schaden, Peak-Rückstand und Alter des ältesten offenen Falls gegen vorab gesetzte Lern-Guardrails.
Erwartetes Ergebnis
8/12 Outcomes sind gereift (66,7 %). Die beobachtete End-to-end-Fehlerrate ist 1/8 = 12,5 %, während die nur synthetisch bekannte spätere Vollsicht 3/12 = 25,0 % ergibt. Unter gereiften Fällen gibt es einen richtigen und einen schädlichen Override. Die Queue erreicht 5 offene Fälle und 2 Tage Maximalalter; Urteil: STOPP — Vorschläge pausieren, manueller Fallback.
Interpretation
Die niedrige beobachtete Fehlerrate entkräftet die Stop-Signale nicht: Outcomes sind selektiv unreif, mindestens ein Override schadet, und die Eskalationslast übersteigt die demonstrative Kapazität. Die Schwellen sind didaktische Beispielwerte; ein realer Workflow braucht fachlich begründete Fehlerkosten, Labelprozess, Kapazität, Subgruppen und Owner.
Interviewfrage
Welche Evidenz fehlt dir für eine Fortsetzung, wenn reife Fälle gut aussehen, aber Coverage und Eskalationsqueue die Guardrails reißen?
Fallstricke
Unreife Outcomes dürfen weder als korrekt noch als negativ codiert werden; Coverage und Reifemechanismus gehören neben jede Qualitätsrate.
Override- und Eskalationsquoten beweisen ohne Goldstichprobe, Gründe, Queue-Alter und Baseline keine wirksame Aufsicht.
Die im Lab bekannte spätere Vollsicht wäre in einem echten Monitoringstichtag gerade nicht verfügbar und darf nicht zur Live-Entscheidung leaken.
Cleanup: Nur konstante synthetische Listen im Prozess; keine Dateien, personenbezogenen Daten oder Zufallszustände.
python3 labs/decision_labs.py führt alle 19 Assertions aus; --json erzeugt maschinenlesbare Ergebnisse. Ein einzelnes Lab läuft beispielsweise mit python3 labs/decision_labs.py lab-oversight-capacity.