Evaluation, Deployment und Retrospektive

Ein System ist erst dann bereit für den Launch, wenn es unter realitätsnahen Bedingungen vollständig evaluiert wurde. Die abschließende Evaluierungsphase kombiniert alle in diesem Track erlernten Evaluierungstechniken: Retrieval-Metriken zur Überprüfung, ob die RAG-Pipeline die richtigen Chunks findet, LLM-as-Judge-Bewertungen zur Überprüfung der Antwortqualität, Lasttests zur Überprüfung der Latenz-SLAs und Sicherheitsscans zur Überprüfung der Härtung. Alle Prüfungen müssen bestanden sein, bevor die Bereitstellung beginnt.

Führen Sie die vollständige Evaluierungssuite in Ihrer Staging-Umgebung mit einer repräsentativen Stichprobe produktionsnaher Abfragen aus. Erfassen Sie alle Metriken: Trefferquote, MRR und NDCG für das Retrieval; Faithfulness und Antwortrelevanz für die Generierung; Kosten pro Abfrage; p50-, p95- und p99-Latenz. Vergleichen Sie jede Metrik mit den in der Architekturphase definierten Erfolgskriterien. Veröffentlichen Sie das System erst, wenn alle verbindlichen Mindestwerte erreicht sind.

Führen Sie vor dem Go-live einen Lasttest durch, der realistischen Produktionsverkehr simuliert. Verwenden Sie ein Tool wie Locust oder k6, um die erwartete Spitzenparallelität (z. B. 50 gleichzeitige Benutzer) schrittweise zu erreichen, und messen Sie, wie sich die Latenz unter Last verändert. Überprüfen Sie, dass die Circuit Breaker bei normaler Last nicht auslösen, der Rate Limiter bei Burst-Traffic korrekt 429-Antworten zurückgibt und die Trefferquote des semantischen Caches über Ihrem Zielwert bleibt. Beheben Sie alle Regressionen, bevor Sie fortfahren.

Stellen Sie das System mithilfe eines Blue-Green-Deployments bereit: Starten Sie die neue Version (Green) parallel zur bestehenden Version (Blue), führen Sie Smoke-Tests gegen Green aus und verlagern Sie den Traffic anschließend schrittweise von Blue zu Green. Leiten Sie zunächst 5 % des Traffics an Green weiter, überwachen Sie 10 Minuten lang Fehlerraten und Latenz und erhöhen Sie den Anteil dann auf 25 %, anschließend auf 50 % und schließlich auf 100 %. So ist bei Problemen ein sofortiges Rollback auf Blue ohne Ausfallzeit möglich.

Überwachen Sie nach dem Deployment in den ersten 2 Stunden aktiv die wichtigsten Metriken. Überwachen Sie: Fehlerrate (Ziel <1 %), p95-Latenz (Ziel <8 s), Cache-Trefferrate (Ziel >20 %) und Kosten pro Abfrage (Ziel <$0.05). Richten Sie für das erste Deployment einen War-Room-Slack-Kanal mit allen diensthabenden Engineers ein. Sobald eine Metrik einen Warnschwellwert überschreitet, muss eine Untersuchung eingeleitet werden; beim Überschreiten eines kritischen Schwellwerts erfolgt sofort ein Rollback auf Blue.

Verfassen Sie nach einer Woche im Produktivbetrieb ein Retrospektivdokument, in dem Sie festhalten, was funktioniert hat, was nicht funktioniert hat und was Sie anders machen würden. Eine gute Retrospektive geht ehrlich mit Fehlern um und formuliert Erkenntnisse konkret. Zukünftige Leserinnen und Leser – einschließlich Ihnen selbst in sechs Monaten – profitieren davon, die Gründe für Entscheidungen zu verstehen, die unter Zeitdruck getroffen wurden, sowie die unerwarteten Hindernisse, die dabei aufgetreten sind.

Verfassen Sie für jeden Alert, der in der Produktion ausgelöst werden kann, ein Runbook. Ein Runbook ist eine Schritt-für-Schritt-Anleitung zur Diagnose und Behebung eines bestimmten Alerts. Es sollte folgende Fragen beantworten: Was bedeutet dieser Alert, was ist die wahrscheinliche Ursache, wie diagnostiziere ich das Problem und wie behebe ich es? Runbooks verkürzen die mittlere Zeit bis zur Behebung (MTTR) von Stunden auf Minuten, da während eines stressigen Incidents keine Diagnoseschritte mehr selbst hergeleitet werden müssen.

Messen Sie nach einem Monat im Produktivbetrieb die geschäftlichen Auswirkungen des Systems, die über technische Metriken hinausgehen. Bei einem Q&A-Assistenten: Wie stark ist das Volumen der Kundensupport-Tickets zurückgegangen? Wie hoch ist die Nutzerzufriedenheit bei von der KI beantworteten Anfragen? Wie viele Anfragen hat das System bearbeitet, für die zuvor menschliche Supportmitarbeiter erforderlich waren? Diese Geschäftsmetriken rechtfertigen die Investition und helfen bei der künftigen Priorisierung zwischen Qualitätsverbesserungen und neuen Funktionen.

Ein ausgeliefertes System ist nie fertig – es bildet die Grundlage für kontinuierliche Verbesserungen. Nutzen Sie Ihre Evaluierungsdaten, das Feedback der Nutzerinnen und Nutzer sowie die Erkenntnisse aus der Retrospektive, um die nächste Iteration zu planen. Priorisieren Sie Verbesserungen, die sich am stärksten auf die wichtigsten Metriken auswirken: Wenn die Retrieval-Trefferrate der begrenzende Faktor ist, investieren Sie in besseres Chunking oder ein anderes Embedding-Modell; wenn die Nutzerzufriedenheit trotz guter Retrieval-Ergebnisse niedrig ist, investieren Sie in die Prompt-Qualität.

Dokumentieren Sie die wichtigsten, nicht unmittelbar ersichtlichen Implementierungsentscheidungen des Systems. Dazu gehören: warum eine bestimmte Chunk-Größe gewählt wurde (und was die Experimente gezeigt haben), wie der Ähnlichkeitsschwellwert des semantischen Caches kalibriert wurde, welche Injection-Muster der Filter derzeit erkennt und welche nicht und wie dem Agenten neue Tools hinzugefügt werden. Eine gute interne Dokumentation verkürzt die Einarbeitungszeit neuer Mitwirkender und verhindert, dass Entscheidungen versehentlich von Personen rückgängig gemacht werden, die die dahinterstehenden Gründe nicht kennen.

Reflektieren Sie über das vollständige System, das Sie in diesem Capstone erstellt haben: eine hybride RAG-Pipeline, die dichte und sparse Retrieval-Verfahren mit Reranking kombiniert, einen Streaming-Agenten mit Function Calling und Sicherheitsleitplanken, einen semantischen Cache, der die Kosten um 30 % senkt, Circuit Breaker für automatisches Failover, eine kontinuierlich in CI/CD ausgeführte LLM-as-Judge-Evaluierung und Schutzmaßnahmen gegen Prompt Injection, die vor adversarialen Eingaben schützen. Das ist AI Engineering für den Produktivbetrieb.

Testen Sie Ihr Verständnis von Deployment und Evaluierung von KI-Systemen im Produktivbetrieb.

In dieser Lektion haben Sie gelernt: Die abschließende Evaluierung umfasst Retrieval-Metriken, LLM-as-Judge-Bewertungen, Lasttests und Sicherheitsscans, bevor ein Deployment beginnt. Ein Blue-Green-Deployment mit schrittweiser Traffic-Verlagerung ermöglicht ein sofortiges Rollback ohne Ausfallzeit, und Retrospektiven und Runbooks halten das institutionelle Wissen fest und verkürzen dadurch künftig die Zeit zur Behebung von Incidents. Herzlichen Glückwunsch zum Abschluss des Tracks „AI Engineering: LLM, RAG and Agents“!