LLMOps & Evaluation

Die Demo, die bestand, und das Produkt, das versagte

Anfang 2024 verlor Air Canada ein Bagatellverfahren, das jeden CDO mit einem GenAI-Piloten erschrecken sollte. Ein trauernder Passagier fragte den Chatbot der Airline-Website nach Trauerfalltarifen. Der Bot erfand selbstbewusst eine Regelung, die nicht existierte, sagte dem Kunden, ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önne die Erstattung rückwirkend beantragen, und das Gericht machte die Airline für die Aussagen ihres Bots haftbar. Der Chatbot hatte seine interne Demo mit hoher Wahrscheinlichkeit bestanden. Er antwortete flüssig. Er klang hilfreich. Er lag auf eine Weise falsch, auf die niemand getestet hatte.

Das ist die zentrale Täuschung von LLMLLMEin Large Language Model ist ein KI-System, das auf riesigen Textmengen trainiert wurde, um Sprache vorherzusagen und zu erzeugen. Damit sind Aufgaben wie Schreiben, Zusammenfassen und Beantworten von Fragen möglich.Vollständige Definition ansehen →-Systemen: Sprachliche Flüssigkeit gibt sich als Korrektheit aus. Ein klassisches Modell, das eine Transaktion falsch klassifiziert, scheitert laut und messbar. Ein LLM scheitert *überzeugend*. Es produziert eine selbstbewusste, grammatikalisch korrekte, plausible Antwort, die subtil oder katastrophal falsch ist, und es tut das nicht-deterministisch: Derselbe Prompt kann am Dienstag durchgehen und am Donnerstag scheitern.

Sie wissen bereits, wie man MLOpsMLOpsMachine Learning Operations: die Verbindung von ML- und DevOps-Praktiken, um Modelle zu industrialisieren, auszurollen, zu überwachen und in der Produktion zuverlässig neu zu trainieren.Vollständige Definition ansehen → für einen Klassifikator aufsetzt: Modell versionieren, Drift überwachen, nach Zeitplan neu trainieren. Dieses Playbook lässt sich nicht einfach übertragen. LLMOps ist eine andere Disziplin, weil die Fehlermodi andere sind, die Inputs unbegrenzte natürliche Sprache sind und die „ground truth“ oft eine Ermessensfrage ist. Der schwierige Teil Ihres GenAI-Programms ist nicht der Bau des Piloten. Es ist der Nachweis, dass dem Piloten zu vertrauen ist, und der Aufbau der Maschinerie, die diesen Nachweis nach dem Launch fortlaufend erbringt. Diese Maschinerie macht diese Lektion konkret.

Warum die Evaluation der Engpass ist, nicht das Modell

Der Instinkt der meisten Teams ist, sich auf Modellauswahl und Prompt EngineeringPrompt EngineeringPrompt Engineering ist die Praxis, Texteingaben so zu gestalten und zu verfeinern, dass große Sprachmodelle präzise, relevante und verlässliche Ergebnisse liefern.Vollständige Definition ansehen → zu fixieren. Das ist die sichtbare, unterhaltsame Arbeit. Aber der Grund, warum 80 % der GenAI-Piloten vor der Produktion stecken bleiben, ist: Niemand hat einen glaubwürdigen Weg gebaut, die Frage zu beantworten, die Ihr Board stellen wird: *„Woher wissen wir, dass es funktioniert?“*

Überlegen Sie, was „funktioniert“ für einen Retrieval-Augmented-Support-Assistenten überhaupt bedeutet. Es gibt mindestens vier unterschiedliche Dimensionen, und sie stehen im Zielkonflikt zueinander:

• Correctness, Ist die Antwort auf Basis Ihrer Quelldokumente faktisch richtig?
• Groundedness (Faithfulness), Bleibt die Antwort im abgerufenen Kontext verankert, oder halluziniert sie darüber hinaus?
• Relevance, Adressiert sie tatsächlich, was der Nutzer gefragt hat?
• Safety/Compliance, Vermeidet sie verbotene Inhalte, PII-Leakage oder unzulässige Beratung?

Eine einzige Accuracy-Zahl kann das nicht erfassen. Und anders als bei einem Klassifikator können Sie diese Dimensionen nicht durch einen einfachen Label-Vergleich berechnen, weil es keinen einzigen korrekten String gibt. „Ihre Erstattung wird in 5-7 Werktagen bearbeitet“ und „Erwarten Sie die Erstattung innerhalb einer Woche“ sind beide korrekt.

Deshalb teilt die Disziplin die Evaluation in zwei Regime, und ein CDO muss beide finanzieren:

Offline-Evaluation läuft gegen ein kuratiertes, versioniertes Eval-Set, bevor irgendetwas ausgeliefert wird. Online-Evaluation misst das Verhalten gegen echten, unvorhersehbaren Produktions-Traffic. Teams, die nur Offline-Evaluation machen, werden von Anfragen überrascht, die sie sich nie vorgestellt haben. Teams, die nur online monitoren, fliegen ohne Pre-Flight-Check. Sie brauchen beides, und beide nutzen unterschiedliches Tooling.

Bauen Sie das Golden Eval Set zuerst, vor dem Piloten

Das Artefakt mit der höchsten Hebelwirkung in Ihrem gesamten GenAI-Programm ist nicht das Modell. Es ist das Golden Evaluation Set: eine kuratierte Sammlung repräsentativer Inputs, gepaart mit erwartetem Verhalten, abgestuften Kriterien und bekannten Edge Cases. Das ist ein Data Asset, das Ihnen gehört, das Wettbewerber nicht kaufen können und das über Zeit an Wert gewinnt.

Ein seriöses Eval-Set sind nicht 20 Fragen, die ein Engineer an einem Freitag getippt hat. Es sollte bewusst zusammengestellt werden:

1. Echte Intents auswerten. Ziehen Sie tatsächliche historische Anfragen, Support-Tickets, Suchlogs, Agent-Transkripte. Wenn Sie vor dem Launch stehen, lassen Sie sie von Subject-Matter-Experten schreiben. Stratifizieren Sie nach Häufigkeit, damit häufige Fälle korrekt gewichtet sind.
2. Den Tail bewusst übergewichten. Die Fehler, die rechtliche und reputative Risiken erzeugen, leben in den Edge Cases: adversariale Prompts, ambivalente Fragen, Anfragen außerhalb des Scopes („Kann ich medizinischen Rat bekommen?“) und Prompt-Injection-Versuche.
3. Abgestufte Erwartungen hinterlegen, nicht nur Antworten. Legen Sie für jedes Item fest, was eine gute Antwort enthalten muss, was sie nicht enthalten darf und wie sie sich verhalten soll (z. B. „muss Policy-Quelle zitieren“, „muss ablehnen und eskalieren“).
4. Versionieren Sie es wie Code. Das Eval-Set liegt in Ihrem Repository, wird bei Änderungen reviewt, und jedes Modell- oder Prompt-Release wird gegen eine gepinnte Version gescort, damit Sie Äpfel mit Äpfeln vergleichen.

Ein praktikables Ziel: 200-500 kuratierte Items für einen ersten Produktionspiloten, kontinuierlich wachsend, sobald die Produktion neue Fehlermodi sichtbar macht. Jeder Fehler aus der Praxis wird zu einem neuen dauerhaften Testfall. So verzinst sich dieses Asset.

Grading im MaMaEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen →ßstab: LLM-as-Judge, ehrlich eingesetzt

Das offensichtliche Problem: Wer bewertet 500 offene Antworten, jedes Mal wenn Sie einen Prompt anpassen? Menschliches Review skaliert nicht auf die Iterationsgeschwindigkeit, die Sie brauchen. Die inzwischen etablierte Antwort ist LLM-as-Judge: ein starkes Modell scort Outputs gegen Ihre Kriterien.

Das funktioniert, aber nur wenn Sie dem Judge mit derselben Skepsis begegnen wie jedem anderen Messinstrument. Der Judge selbst hat Biases: Er bevorzugt längere Antworten, er mag Antworten, die seinem eigenen Stil entsprechen, und er lässt sich manipulieren. Die Disziplin besteht darin, den Judge gegen menschliche Labels zu kalibrieren. Lassen Sie Ihre SMEs eine Stichprobe von einigen hundert Outputs manuell bewerten und messen Sie dann, wie gut Ihr LLM-Judge mit ihnen übereinstimmt. Ist die Übereinstimmung zwischen Judge und Mensch hoch, können Sie ihm zum Skalieren vertrauen. Ist sie niedrig, muss Ihr Judge-Prompt nachgearbeitet werden, bevor Sie sich darauf verlassen.

Ein Judge-Prompt sollte eine rubrikbasierte, strukturierte Entscheidung erzwingen statt eines vagen Qualitätsgefühls:

You are evaluating a support answer for GROUNDEDNESS.
Context provided to the assistant:
{retrieved_context}
User question: {question}
Assistant answer: {answer}

Score groundedness 1-5:
5 = every claim is directly supported by the context
1 = answer contains claims not present in the context
Return JSON: {"score": int, "unsupported_claims": [..], "reasoning": "..."}

Beachten Sie, dass dies den Judge zwingt, nicht gestützte Behauptungen *aufzulisten*. Diese Struktur verbessert die Genauigkeit und liefert Ihrem Team debugbaren Output: Sie sehen, *warum* etwas schlecht abgeschnitten hat, nicht nur dass es so war.

GuardrailsGuardrailsRegeln und Kontrollen, die ein KI-System in sicheren, rechtskonformen und markengerechten Grenzen halten und unerwünschte Ausgaben blockieren.Vollständige Definition ansehen →: die Runtime-Schicht zwischen Modell und Nutzer

Evaluation zeigt Ihnen, wie sich das System in der Gesamtheit verhält. Guardrails sind die Echtzeitkontrollen, die jede einzelne Antwort einschränken, bevor sie einen Nutzer erreicht oder auf ein System einwirkt. Denken Sie an Evaluation als Ihren Qualitätsprozess und an Guardrails als Ihre Sicherungen.

Guardrails greifen an zwei Punkten, und ausgereifte Systeme nutzen beide:

Input-Guardrails prüfen, was ins Modell geht: Erkennung von Prompt Injection („ignoriere deine Anweisungen und …“), Filterung von PII, bevor sie an eine Drittanbieter-APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen → geht, und Klassifikation, ob eine Anfrage überhaupt im Scope liegt. Eine medizinische Frage außerhalb des Scopes an einen Banking-Bot sollte hier abgefangen und nicht beantwortet werden.

Output-Guardrails prüfen, was zurückkommt: Abgleich auf Halluzinationen gegen die abgerufenen Quellen, Blockieren toxischer oder nicht-konformer Inhalte, Verifikation des Antwortformats und, für regulierte Branchen entscheidend, die Durchsetzung, dass bestimmte Antworten Disclaimer enthalten oder eine Eskalation an Menschen auslösen.

Die Architekturentscheidung, die ein CDO treffen muss, ist, wo die Verantwortung liegt. Lassen Sie nicht zu, dass Anwendungsentwickler einen Regex-Filter selbst zusammenbauen und das Governance nennen. Guardrails sollten eine gemeinsame, zentral verantwortete Service-Schicht sein, damit Ihre Policy zum Umgang mit PII oder zur Ablehnung medizinischer Beratung einmal definiert und über jede GenAI-Anwendung im Unternehmen hinweg konsistent durchgesetzt wird. Hier wird Ihr bestehendes Governance-Mandat zu ausführbarem Code. Die Policy, die Ihr Governance Council schreibt, muss auf ein Guardrail abbilden, das jemand durchsetzen und auditieren kann.

Hier ist die Abwägung, über die Teams stolpern: Guardrails erzeugen Latenz und Kosten, weil jede Prüfung oft ein weiterer Modellaufruf ist. Ein aggressives Output-Validierungs-Guardrail kann Ihre Antwortzeit verdoppeln. Sie werden explizite Trade-offs machen: leichtgewichtige Checks bei jeder Anfrage, teure Verifikation nur bei Intents mit hohem Risiko. Dieses Risk-Tiering ist eine CDO-Entscheidung, kein Nachgedanke des Engineerings.

Monitoring: Vertrauen ist eine Runtime-Eigenschaft, kein Launch-Meilenstein

Die gefährlichste Annahme bei GenAI ist, dass eine bestandene Offline-Evaluation dauerhaftes Vertrauen verdient. Tut sie nicht. LLM-Systeme degradieren auf Weisen, die Klassifikatoren nicht kennen. Ihr Anbieter aktualisiert das zugrundeliegende Modell stillschweigend. Nutzerverhalten verschiebt sich und erzeugt Anfragen, die Ihr Eval-Set nie abgedeckt hat. Ihr eigener Retrieval-Korpus veraltet, weil Dokumente sich ändern. Ein System, das beim Launch 92 % erreichte, kann leise auf 70 % driften, ohne dass Sie eine Zeile Code geändert haben.

Produktions-Monitoring ist also keine optionale Telemetrie, es ist der Mechanismus, durch den Vertrauen *aufrechterhalten* wird. Ein CDO sollte darauf bestehen, dass der Monitoring-Stack vier Schichten erfasst:

• System-Metriken, Latenz (besonders Time-to-First-Token, die die wahrgenommene Qualität treibt), Kosten pro Anfrage, Throughput, Fehlerraten. GenAI-Kosten sind variabel und können ausschlagen; unbeobachtet kann eine einzige fehlerhafte Integration an einem Wochenende einen sechsstelligen Betrag verbrennen.
• Qualitätssignale, eine rollierende Stichprobe von Produktionsantworten, gescort von Ihrem LLM-Judge gegen dieselben Rubriken wie offline. So erkennen Sie Drift.
• Guardrail-Auslöseraten, wie oft jedes Guardrail greift. Ein plötzlicher Anstieg blockierter Prompt Injections heißt, Sie werden angegriffen; ein Anstieg von „out-of-scope“-Ablehnungen heißt, Nutzer wollen etwas, das Sie nicht anbieten, und das ist Produkt-Intelligence.
• Nutzer-Feedback, Thumbs up/down, Eskalationsrate an Menschen, Abbruch von Konversationen. Die Eskalationsrate ist oft Ihr ehrlichster Qualitäts-Proxy.

Die operative Disziplin, die das zusammenhält, ist ein Feedback Loop: Jeder markierte Produktionsfehler wird triagiert, und die echten Fehler wandern in das Golden Eval Set. Das ist das Flywheel. Ihr Eval-Set wird genau dort reicher, wo die Realität Ihnen Unrecht nachgewiesen hat, und das nächste Release wird gegen genau den Fehler getestet, der Sie letztes Mal blamiert hat. Ein GenAI-Programm ohne diesen Loop ist kein Produkt; es ist eine Demo auf geliehener Zeit.

Der Arbeitsrhythmus, den ein CDO installieren muss

Konkret ist dies die Kadenz, die Sie aufsetzen, bevor ein Pilot in Produktion geht:

• Pre-Deployment-Gate: Kein Release geht raus, ohne gegen das gepinnte Golden Eval Set gescort zu werden und einen definierten Schwellwert in jeder Dimension zu erreichen, Correctness, Groundedness, Safety. Dieses Gate ist nicht verhandelbar und hat eine namentlich benannte Verantwortung.
• Canary Rollout: Neue Modelle oder Prompts gehen zuerst auf einen kleinen Traffic-Anteil, mit Online-Qualitätsscores im Vergleich zum Bestandssystem, bevor vollständig ausgerollt wird. Behandeln Sie einen Modellwechsel wie ein Code-Deployment, denn genau das ist er.
• Wöchentliches Quality Review: Ein fester Termin, in dem Produkt, Data und Risk Drift-Metriken, Guardrail-Auslöseraten und neu aufgenommene Eval-Fälle durchgehen. Hier wird Degradation erkannt, bevor ein Kunde sie erkennt.
• Incident Playbook: Ein definierter Weg, eine Prompt- oder Modellversion in Minuten zurückzurollen, weil Sie ihn *brauchen* werden.

Die Organisationen, die bei Enterprise-GenAI gewinnen, sind nicht die mit den besten Modellen, alle mieten dieselben Frontier-Modelle. Sie gewinnen, weil sie die Evaluations- und Monitoring-Maschinerie gebaut haben, die schnelles *und sicheres* Iterieren erlaubt: wöchentliche Verbesserungen mit Zuversicht statt einmaliger Pilot und Hoffen.

Key Takeaways

1. Finanzieren Sie das Golden Eval Set vor dem Piloten. Es ist Ihr dauerhaftestes, sich verzinsendes Data Asset, 200-500 kuratierte, versionierte Fälle, die den risikoreichen Tail übergewichten. Kein Eval-Set, keine Produktion. Behandeln Sie es als Board-Level-Artefakt, nicht als Nebenaufgabe des Engineerings.
2. Vertrauen Sie niemals einem unvalidierten Judge. LLM-as-Judge skaliert das Grading, aber kalibrieren Sie ihn zuerst gegen menschliche Labels und erzwingen Sie rubrikbasiertes, strukturiertes Scoring. Ein unkalibrierter Judge ist ein selbstbewusster Lügner, der einen anderen selbstbewussten Lügner misst.
3. Machen Sie Guardrails zu einem Shared Service, nicht zu App-Klempnerei. Zentralisieren Sie Input- und Output-Kontrollen, damit Ihre Governance-Policy einmal durchgesetzt und überall auditiert wird, und stufen Sie die teuren Checks explizit nach Risiko gegen Latenz und Kosten ab.
4. Instrumentieren Sie Vertrauen als Runtime-Eigenschaft. Monitoren Sie System-, Qualitäts-, Guardrail- und Nutzer-Feedback-Schichten fortlaufend; ein Score vom Launch-Tag sagt drei Wochen später nichts mehr, sobald der Anbieter das Modell aktualisiert oder der Traffic sich verschiebt.
5. Schließen Sie den Loop, oder verlieren Sie den Krieg. Jeder echte Produktionsfehler muss zu einem dauerhaften Eval-Fall werden. Dieses Flywheel, nicht die Modellwahl, unterscheidet ein verteidigungsfähiges GenAI-Produkt von einer Demo auf geliehener Zeit.