AI-EVAL · Pfad 4: Bauen und betreiben
Evaluation, Observability und Guardrails
Ohne Golden Dataset und Release-Gates ist jedes KI-Release ein Experiment an Ihren Nutzern.
- Dauer
- 2 Tage
- Gruppe
- bis 12 Personen
- Format
- Inhouse · Remote · Im Lab
- Sprache
- Deutsch oder Englisch
- Preis
- 15.800 € pauschal, zzgl. MwSt.
Für wen dieser Track ist
Entwickler, Platform Engineers und technische Verantwortliche, die ein KI-System in Richtung Produktion bringen oder bereits betreiben. Ideal für Teams, die auf Prompt-Änderungen bisher mit Ausprobieren und Hoffen reagieren.
Für wen nicht
Nicht für Teams ohne laufendes oder konkret geplantes KI-System, denen fehlt das Messobjekt, sie starten mit AI-RAG. Die Sicherheitssicht auf Bedrohungen liefert Secure GenAI und Agent Threat Modeling (AI-SEC).
Ausgangssituation
Das System läuft, aber niemand kann belegen, ob das letzte Modell-Update die Antworten besser oder schlechter gemacht hat. Beschwerden kommen von Nutzern statt aus dem Monitoring, die Token-Kosten wachsen unbemerkt und jede Prompt-Änderung geht ungeprüft live. Was fehlt, ist keine Meinung, sondern ein Messsystem.
Das existiert nach dem Track
- Ein Golden Dataset für das eigene System: kuratierte Fälle mit Erwartungsergebnissen, Randfällen und bewusst schwierigen Anfragen
- Implementierte Qualitätsmetriken für Groundedness, Relevanz und Vollständigkeit, inklusive kalibriertem LLM-as-Judge mit Stichproben-Gegenprüfung
- Tracing über die gesamte Kette von der Anfrage über Retrieval und Modellaufruf bis zur Antwort, mit Kosten und Latenz je Schritt
- Ein Kosten- und Latenzbudget je Anfragetyp mit Alarmschwellen
- Definierte Release-Gates: welche Messwerte ein Deployment passieren muss und wann ein Rollback ausgelöst wird
Voraussetzungen
Programmierkenntnisse in Python und ein reales oder im Training bereitgestelltes KI-System als Messobjekt. Erfahrung mit CI/CD-Pipelines ist hilfreich.
Vorarbeit vor dem Track
Sie sammeln vorab 20 reale Anfragen an Ihr System, davon mindestens 5, bei denen die Antwort schlecht oder strittig war, anonymisiert im bereitgestellten Format. Diese Fälle werden am Tag 1 zum Kern Ihres Golden Datasets. Teams ohne eigenes System erhalten ein präpariertes RAG-System auf der Lab-Umgebung.
Lieferumfang
- 2 Trainingstage mit Dino Bordonaro, inhouse, remote oder im Lab
- Persönliche Lab-Umgebung mit vorbereitetem Referenzsystem und Evaluations-Stack, plus 14 Tage Nachlauf
- Code-Repository mit Metrik-Implementierungen, Judge-Prompts und Pipeline-Vorlagen
- Vorlagen für Golden Dataset, Budgetdefinition und Release-Gate-Checkliste
- Teilnahmezertifikate und Schulungsdokumentation für Ihr Compliance-Archiv
- 60-minütige Remote-Sprechstunde 4 Wochen nach dem Training zum Review der eigenen Gates
Agenda
Tag 1
Der Blindflug-Befund
Live-Experiment am Referenzsystem: ein scheinbar harmloser Prompt-Fix verschlechtert messbar die Hälfte der Antworten. Frage an die Runde: Wie viele Ihrer letzten Änderungen gingen ohne Messung live?
Das Golden Dataset bauen
Werkstatt an den mitgebrachten Fällen: Erwartungsergebnisse formulieren, Randfälle und Fangfragen ergänzen, Repräsentativität prüfen. Ergebnis ist ein versioniertes Dataset mit 30-50 Fällen je Team.
Metriken implementieren: Groundedness, Relevanz, Vollständigkeit
Hands-on: automatisierte Bewertung mit LLM-as-Judge, Kalibrierung gegen menschliche Stichproben-Urteile, Umgang mit Judge-Fehlurteilen. Jede Metrik läuft am Ende gegen das eigene Dataset.
Der erste Evaluationslauf
Vollständiger Lauf des eigenen Datasets gegen das System, Auswertung der Ausreißer: Ist der Fehler im Retrieval, im Prompt oder im Judge? Die Fehlerklassifikation entscheidet über die richtige Korrektur.
Tagesergebnis: eine belastbare Baseline
Jedes Team legt seine Baseline vor: Dataset-Umfang, Metrikwerte, klassifizierte Ausreißer. Prüffrage: Würden Sie auf Basis dieser Zahlen eine Änderung freigeben oder ablehnen können?
Tag 2
Tracing: die Kette sichtbar machen
Hands-on: Instrumentierung der Pipeline mit Traces je Anfrage, von Retrieval-Treffern über Modellaufrufe bis zur Antwort. Übung: einen realen Schlechtfall allein anhand des Trace diagnostizieren.
Kosten- und Latenzbudget
Auswertung der Trace-Daten: Was kostet welcher Anfragetyp in Token und Millisekunden? Jedes Team definiert Budgets und Alarmschwellen und verankert sie im Monitoring.
Guardrails vor und nach dem Modell
Implementierung: Eingabefilter gegen Prompt Injection und Datenabfluss, Ausgabeprüfung auf Grounding und Formatverstöße. Messübung: Was fangen die Guardrails, was kostet das an Latenz?
Release-Gates und Regression-Erkennung
Werkstatt: Evaluationslauf als Pflicht-Stage in der Deployment-Pipeline, Schwellwerte je Metrik, Rollback-Kriterien. Test am eigenen System: eine absichtlich eingebaute Regression muss vom Gate gestoppt werden.
Tagesergebnis: das Gate hält
Abnahme je Team: Die präparierte Regression wird vom eigenen Release-Gate erkannt und blockiert, die saubere Version passiert. Das dokumentierte Gate-Regelwerk ist das überprüfbare Abschlussartefakt.
Übungen und Lab-Anteil
Rund 70 Prozent der Zeit ist Implementierungsarbeit auf der Lab-Umgebung: Dataset bauen, Metriken coden, Traces auswerten, Gates testen. Der Härtetest am Ende ist eine real eingebaute Regression, die das eigene Gate fangen muss.
Plattformen
Der Evaluations-Stack basiert auf Open-Source-Komponenten und läuft auf unserer Lab-Umgebung, wahlweise gegen Ihr mitgebrachtes System oder unser Referenz-RAG. Die Muster sind auf Azure- und On-Prem-Umgebungen übertragbar, Plattformdienste in der jeweils verfügbaren Version.
Transfernachweis
Transfernachweis ist der bestandene Gate-Test am Tag 2: Regression erkannt, saubere Version freigegeben, Regelwerk dokumentiert. Teilnahme und Ergebnisse werden revisionssicher dokumentiert.
Mitgenommene Artefakte
- Golden Dataset des eigenen Systems, versioniert und erweiterbar
- Implementierte Metrik-Suite mit kalibrierten Judge-Prompts
- Tracing-Setup mit Kosten- und Latenzauswertung je Anfragetyp
- Budgetdefinition mit Alarmschwellen als Betriebsdokument
- Release-Gate-Regelwerk mit Rollback-Kriterien für die eigene Pipeline
Optionale Erweiterungen
- Secure GenAI und Agent Threat Modeling (AI-SEC) für die Sicherheitssicht jenseits der Qualitätsmetriken
- LLMOps für verbundene, getrennte und Air-Gap-Umgebungen (AI-OPS) für den vollständigen Betriebsrahmen
- Agentic Systems Engineering (AI-AGENT), wenn Ihre Gates künftig Agenten statt Assistenten prüfen sollen
Abgrenzung
Der Track befähigt Ihr Team, das eigene Messsystem zu bauen und zu betreiben. Er ist kein Audit Ihres Produktivsystems und kein Managed-Monitoring-Service, dafür sprechen wir über ein Projekt.
Häufige Fragen
Unser System ist noch nicht produktiv. Ist der Track zu früh?
Nein, eher im Gegenteil: Wer Golden Dataset und Gates vor dem ersten Release aufbaut, misst von Anfang an. Voraussetzung ist nur ein lauffähiges System als Messobjekt, notfalls unser Referenz-RAG auf der Lab-Umgebung.
Sind LLM-as-Judge-Bewertungen nicht selbst unzuverlässig?
Unkalibriert ja, deshalb ist die Kalibrierung Kernbestandteil: Judge-Urteile werden gegen menschliche Stichproben geprüft, Abweichungsmuster dokumentiert und die Prompts nachgeschärft. Sie lernen auch, wann ein Judge die falsche Wahl ist und regelbasierte Prüfungen tragen.
Funktioniert das remote genauso gut wie im Lab?
Ja, die gesamte Übungsumgebung läuft ohnehin auf unserem Lab und wird remote bedient. Inhouse oder im Lab gewinnen Sie die Diskussionen am Whiteboard, remote gewinnen Sie Reisekosten, die Artefakte sind identisch.