Evals: von KI-Experimenten zum sicheren Produktivbetrieb

• Foundation-Modelle haben sich zwar verbessert, doch erst konsequente Evaluierungsverfahren ermöglichen einen zuverlässigen Produktivbetrieb.

• Gut konzipierte Evals helfen Produktmanagement, KI-Governance-Verantwortlichen und CTOs, KI-Agenten sicher und in großem Maßstab einzusetzen. So wird KI vom isolierten Spielzeug zum Wettbewerbsvorteil.

• Dieses Vertrauen entsteht, wenn das Verhalten von KI-Agenten anhand echter Nutzeranfragen, Grenzfälle und domänenspezifischer Szenarien bewertet wird, die deinen tatsächlichen Geschäftskontext abbilden, nicht durch einen öffentlichen Benchmark, der behauptet: „Dieses Modell ist das beste.“

• Das Ziel besteht darin, dieses Vertrauen mit messbaren Ergebnissen zu begründen. Erfolg bedeutet, „gut“ konkret und messbar zu definieren sowie an deinen geschäftlichen Anforderungen und deiner Risikotoleranz auszurichten, etwa anhand von Faktentreue, angemessenem Ton, Geschwindigkeit oder Kosteneffizienz.

• Wenn Teams die Evaluierung im gesamten System verankern (Instrumentierung, Protokollierung, A/B-Tests und Schutzmechanismen) und Gründlichkeit mit Effizienz verbinden, können sie schneller und zuverlässiger bereitstellen.

Die meisten Unternehmen haben kein Problem damit, wenn ihre Beschäftigten ChatGPT oder Gemini ausprobieren. LLMs in kritischen Arbeitsabläufen oder Umgebungen einzusetzen, ist dagegen bislang weniger üblich.

Die Gründe dafür waren oft berechtigt: Die Qualität war uneinheitlich, und das Risiko von Halluzinationen oder unerwünschtem Verhalten überwog den möglichen Nutzen der Technologie.

Das Verhältnis von Risiko und Nutzen hat sich im vergangenen Jahr deutlich verschoben. Das ist zum Teil auf leistungsfähigere Foundation-Modelle zurückzuführen, zu einem großen Teil aber auch auf die zunehmend systematische Evaluierung, kurz „Evals“. Evals geben uns und unserer Kundschaft die nötige Sicherheit, um binnen weniger Wochen Agenten in großem Maßstab und mit Kundenkontakt bereitzustellen.

Dieser Leitfaden erläutert die Grundlagen von Evals und zeigt, wie du sie für Anwendungsfälle im Produktivbetrieb konzipierst, implementierst und betreibst.

Das Ziel der Evaluierung ist nicht, ein perfektes Modell zu finden. Vielmehr soll sie begründetes Vertrauen schaffen, dass sich dein Modell im Einklang mit deinen geschäftlichen Anforderungen, den Erwartungen deiner Nutzerinnen und Nutzer sowie der Risikotoleranz deiner Organisation verhält.

Jede Evaluierungsstrategie beginnt mit einer einfachen Frage: Was bedeutet „gut“? Die Antwort sollte konkret sein. Für eine Organisation kann „gut“ hohe Faktentreue innerhalb strenger Toleranzen bedeuten, für eine andere stehen vielleicht Geschwindigkeit, Kosteneffizienz oder ein unverwechselbarer Sprachstil im Vordergrund. Alle Rahmenbedingungen, von den nutzbaren Daten bis zu den geltenden regulatorischen Pflichten, prägen diese Definition.

Entscheidend ist, dass sich „gut“ in tatsächlich messbare Komponenten zerlegen lässt. Wenn Erfolg bedeutet, hilfreiche Finanzberatung anzubieten, muss sich diese Qualität durch Merkmale ausdrücken lassen: sachliche Richtigkeit, angemessene Hinweise, personalisiertes Reasoning und sichere Grenzen. Sobald „gut“ messbar definiert ist, stellt sich die nächste Frage: Wie analysierst und interpretierst du die Ergebnisse? Erst wenn du aus diesen Ergebnissen Maßnahmen ableitest, wird Evaluierung zu einer Methode statt zu einer bloßen Ermessensentscheidung.

Jede Evaluierungspipeline beruht auf drei miteinander verbundenen Säulen:

1. Eingaben/Benchmarks: Repräsentative Beispiele aus der Praxis für die allgemeine Leistung sowie kuratierte interne Datensätze, mit denen die Eignung für eine Domäne geprüft wird.

2. Modellverhalten: Wie das Modell aufgerufen wird (Retrieval-Augmented Generation, Zusammenfassung, strukturierter Informationsabruf, Werkzeugnutzung).

3. Metriken: Wie du die Leistung misst und interpretierst.

Die Eingaben müssen die Welt abbilden, auf die dein System treffen wird. Die aussagekräftigsten Erkenntnisse stammen aus echten Beispielen: Anfragen deiner Kundschaft, Finanzszenarien oder branchenspezifische Fälle. Nur durch Tests anhand dieser Beispiele erkennst du, ob das Modell die von deinen Nutzerinnen und Nutzern benötigten Nuancen wirklich versteht und die geschäftlichen Anforderungen erfüllt.

Das Verhalten des Modells ist ebenso wichtig wie das Modell selbst: wie Prompts gestaltet, Abruf und Werkzeugnutzung orchestriert und Kontext bereitgestellt werden. Zwei identische Modelle können sich je nach Art ihrer Bereitstellung sehr unterschiedlich verhalten. Diese Ebene muss deshalb in dein Evaluierungskonzept einbezogen werden.

Schließlich kommen die Metriken hinzu. Zahlen allein erzählen selten die ganze Geschichte. Gut gewählte Metriken machen das Systemverhalten jedoch nachvollziehbar. Latenz, Genauigkeit, Sicherheit, Kohärenz, Verzerrungen, Kosten und Nutzerzufriedenheit ergeben zusammen ein mehrdimensionales Bild eines Systems im Produktivbetrieb. Die Kunst besteht darin, Metriken zu wählen, die zu den KPIs deines Projekts oder Unternehmens passen und die für deine Nutzerinnen und Nutzer wichtigsten Eigenschaften sichtbar machen. Einfachere Metriken sind häufig genauer und kostengünstiger. Schlecht gewählte Metriken können Teams dagegen in die Irre führen. So solltest du bei der Auswahl von Metriken vorgehen:

Beispiele für gut gewählte Metriken:

• Kundenservice-Chatbot: Lösungsquote beim Erstkontakt (wurde das Anliegen ohne Eskalation gelöst?), durchschnittliche Bearbeitungszeit, Nutzerzufriedenheit, Eskalationsquote an menschliche Ansprechpersonen

• Finanzrecherchetool: korrekte Quellenangaben (Anteil der Aussagen mit geeigneten Quellen), anhand gesicherter Referenzdaten geprüfte Faktentreue, Relevanz der abgerufenen Inhalte (wurden die richtigen Dokumente gefunden?), von Fachleuten bewertete Kohärenz des Reasonings

• Assistent zur Codegenerierung: korrekte Syntax, Erfolgsquote der Tests, Anzahl der Sicherheitslücken, Zeit bis zur funktionsfähigen Lösung

Beispiele für schlecht gewählte Metriken:

• Nur die Antwortlänge als Qualitätsindikator verwenden (länger ≠ besser)

• Geschwindigkeit messen, ohne Zielkonflikte mit der Genauigkeit zu berücksichtigen

• Konfidenzwerte des Modells verfolgen, ohne sie anhand der tatsächlichen Richtigkeit zu validieren

• Sich ausschließlich auf die interne Modellperplexität verlassen, ohne nutzerseitige Validierung

Häufige Fehler bei Metriken:

• Widersprüchliche Metriken: gleichzeitig auf Geschwindigkeit und Vollständigkeit optimieren, ohne den Zielkonflikt anzuerkennen

• Überanpassung an Benchmarks: Im Testdatensatz 95 % erreichen, aber im Produktivbetrieb scheitern, weil sich echte Nutzerinnen und Nutzer anders verhalten

Für ein Unternehmen aus dem stark regulierten Finanzsektor hatte die Genauigkeit seiner Deep-Research-Lösung oberste Priorität. Wir entwickelten sowohl von Fachleuten erstellte QA-Datensätze als auch werkzeuggenerierte Datensätze. So konnten wir die Präzision und die Fähigkeit des Systems bewerten, die richtigen Werkzeuge und Informationen auszuwählen. Dadurch erhielten wir ein ausgewogenes Bild von Genauigkeit und Reasoning-Qualität. Entscheidend war, mehrere Dimensionen zu messen: Faktentreue (Validierung durch Fachleute), Abrufqualität (Precision/Recall relevanter Dokumente) und Kohärenz des Reasonings (strukturierte Bewertung des logischen Ablaufs).

Wann LLM-as-a-Judge zur Bewertung differenzierter Qualität geeignet ist

Bei LLM-as-a-Judge fungiert ein zweites KI-Modell als Prüfinstanz. Menschliche Prüfungen werden dabei durch skalierbare, automatisierte Qualitätsbewertungen ersetzt. LLM-as-a-Judge wird oft unnötig eingesetzt, obwohl einfachere Metriken die erforderliche Genauigkeit liefern würden. Das Verfahren kann nützlich sein, wenn deterministische Prüfungen die Qualität nicht erfassen können, etwa bei semantischen Metriken wie Nützlichkeit, Quellenbezug, Reasoning-Qualität, Ton oder Richtlinienauslegung und wenn keine deterministische Bewertung möglich ist. Möglicherweise benötigst du skalierbares Feedback für viele Prompt- und Modellvarianten sowie ein klar definiertes Bewertungsraster und ein Schema für strukturierte Ausgaben. Damit das Verfahren für dich funktioniert, solltest du diese Schritte befolgen:

• Definiere die Dimensionen des Bewertungsrasters ausdrücklich: Richtigkeit, Quellenbezug, Richtlinienkonformität, Umsetzbarkeit und Ton.

• Verwende strukturierte Ausgaben (JSON-Schema) für die Antworten der Prüfinstanz.

• Erfasse sowohl binäre Freigabewerte als auch Diagnosetexte für die Fehleranalyse.

• Kalibriere die Ausgaben der Prüfinstanz in jedem Release-Zyklus anhand von menschlich gekennzeichneten Beispielen.

• Verwende bei kritischen Anwendungsbereichen zwei Prüfinstanzen oder regelmäßige Konsensprüfungen.

• Verfolge im Zeitverlauf Abweichungen der Prüfinstanz und die Häufigkeit unterschiedlicher Bewertungen.

Ein Benchmark-Datensatz ist eine feste, kuratierte Sammlung von Testbeispielen mit bekannten Antworten. Damit lassen sich Modelle einheitlich bewerten und Ergebnisse verschiedener Versionen fair vergleichen. Er enthält normalerweise Eingaben wie Nutzeranfragen, erwartete Ausgaben oder Referenzbewertungen sowie Bewertungskriterien oder Labels für die Punktevergabe. Öffentliche Benchmark-Tests dienen dazu, die Leistung modernster Modelle zu vergleichen. Bei der Konzeption deines Systems können sie eine erste Orientierung bieten, welches Modell infrage kommt.

Für dein eigenes System darfst du dich jedoch nicht auf diese Benchmarks als Ersatzmaß für die Leistung in deinem Geschäftskontext verlassen. Sie weisen bekannte Probleme auf:

• Kontamination: Modelle wurden möglicherweise mit Benchmark-Daten trainiert. Eine Bewertung anhand desselben Datensatzes gleicht dann einer Prüfung mit Spickzettel.

• Sättigung: Alle führenden Modelle erreichen bereits nahezu die Höchstwerte. Verbesserungen oder Verschlechterungen beschränken sich daher auf wenige Prozentpunkte und liegen oft innerhalb der natürlichen Schwankungsbreite der Testergebnisse.

• Enger Umfang: Benchmark-Daten bilden deine tatsächlichen Aufgaben nicht ab, da sie stark kuratiert und bereinigt sind. Manche wurden sogar von LLMs erzeugt und bilden weder die Komplexität noch die Grenzfälle deiner Daten ab, etwa Tippfehler, ungewöhnliche Formulierungen oder verrauschte Bilder.

Ein Schüler oder eine Schülerin bittet die Anwendung um Hilfe beim Lösen von Textaufgaben.

Ein geeigneter öffentlicher Benchmark: GSM8K (mathematisches Reasoning auf Grundschulniveau)

• Optionaler, schwierigerer Datensatz: MATH.

Warum dieser Benchmark nützlich ist:

• Du kannst schnell vergleichen, welches Modell bei allgemeinem mathematischem Reasoning besser abschneidet.

• Er ist ein guter erster Filter, bevor du in umfassende Produkt-Evals investierst.

Warum du trotzdem einen eigenen Datensatz benötigst:

Deine App hat Anforderungen, die GSM8K nicht prüft:

• Formulierungen und Reihenfolge der Themen in deinem Lehrplan,

• Erklärungsstil für deine Altersgruppe,

• Umgang mit mehrdeutigen oder fehlerhaft geschriebenen Fragen von Schülerinnen und Schülern,

• Richtlinien, etwa wann Hinweise statt vollständiger Antworten gegeben werden sollen.

Eine wirksame Validierung erfordert anwendungsspezifische Evaluierungsbenchmarks. Diese Datensätze sollten auf echten Interaktionen, typischen Grenzfällen und plausiblen Fehlerszenarien beruhen. Bei der Einführung eines neuen Produkts oder Prozesses kann das schwierig sein. In den meisten Fällen lassen sich jedoch Daten aus einem bestehenden Produkt oder schon frühzeitig sammeln, sogar während einer ersten Testphase. Nach der Entwicklung deiner Anwendung sollten sich diese Benchmarks mit deinem Produkt weiterentwickeln und im Laufe der Zeit vielfältiger und repräsentativer werden.

Die Verbindung zwischen deinem anwendungsspezifischen Benchmark und der Modellauswahl ist entscheidend. Dein Benchmark zeigt nicht nur, ob eine Lösung funktioniert, sondern auch, welche Kombination aus Modellgröße und Post-Training-Verfahren die benötigte Leistung am kosteneffizientesten erzielt. Die wirksamsten Verbesserungen vortrainierter Modelle, das „PT“ in ChatGPT, entstehen nicht durch erneutes Training, sondern durch „Post-Training“-Verfahren.

Diese Verfahren bestimmen, auf welche Informationen das Modell zugreifen kann, wie diese strukturiert sind und wie das Modell bei der Inferenz angeleitet und orchestriert wird. Zu den Post-Training-Verfahren gehören:

• Prompts für Gedankenketten und dynamische Zuweisung von Rechenleistung, damit das Modell bei schwierigeren Problemen intensiver nachdenkt

• Selbstkonsistenz, bei der mehrere Ausgaben erzeugt und die beste ausgewählt wird

• Kontextaufbau und Orchestrierung, beispielsweise Retrieval-Augmented Generation (RAG), Few-Shot-Beispiele und agentische Arbeitsabläufe

• Werkzeugnutzung und Zugriff auf externes Wissen, damit das Modell über seine internen Parameter hinaus Aktionen ausführen kann

• Strategien zur Wissensrepräsentation und -speicherung, die einen effizienten Abruf und Reasoning mit strukturierten und unstrukturierten Daten ermöglichen

Diese Post-Training-Verfahren können die Systemleistung deutlich verbessern, bringen aber auch Zielkonflikte mit sich. Jede zusätzliche Ebene für Orchestrierung, Abruf oder Reasoning erhöht die Systemkomplexität, Inferenzzeit und Betriebskosten. Bei durchdachtem Einsatz ermöglicht die richtige Kombination aus Post-Training-Verfahren jedoch häufig kleinere, schnellere und günstigere Modelle, die dennoch die Leistungsanforderungen erfüllen. Statt die Modellgröße zu erhöhen, wird die Leistung durch ein besseres Systemdesign erzielt.

Die richtige Balance ist immer anwendungsspezifisch. Nutze deine anwendungsspezifischen Evals, um die optimale Kombination von Verfahren zu bestimmen. Damit erkennst du, ab wann zusätzliche Orchestrierung keine relevanten Verbesserungen mehr bringt. Teams können so die geringste für ihre Zielleistung erforderliche Post-Training-Komplexität wählen.

Eine KI-Lösung muss als Gesamtsystem betrachtet werden: Datenbanken, APIs, Benutzeroberflächen, Orchestrierungsebenen, Monitoring-Infrastruktur und mehr. Die Evaluierung muss deshalb den gesamten Stack umfassen. Du solltest wichtige Teile des Systems überwachen, damit mögliche Probleme sichtbar bleiben und du verantwortungsvoll schneller vorankommst.

Die Überwachung wichtiger Systemkomponenten umfasst:

• Instrumentiere deine Pipelines, um messbare Ergebnisse zu erhalten.

• Protokolliere Experimente, damit du die Wirkung jeder Änderung erkennen kannst.

• Nutze einfache A/B-Vergleiche, bevor du größere Änderungen bereitstellst, um mögliche Regressionen zu erkennen.

Datengestützte Iteration verkürzt den Weg vom Prototyp zum Produktivbetrieb, ohne blinde Flecken zu hinterlassen. Protokollierung und Monitoring sind außerdem wichtig, um die tatsächliche Nutzung der Anwendung zu verstehen. Dieses Beispiel zeigt, wie du Beobachtbarkeit sicherstellst:

• Schritt 1: Die Nutzeranfrage geht mit request_id, user_segment und intent ein.

• Schritt 2: Der Trace protokolliert Modellversion, Prompt-Version, abgerufene Dokumente und Werkzeugaufrufe.

• Schritt 3: Eine LLM-Prüfinstanz bewertet die Antwort (Richtigkeit, Quellenbezug, policy_risk).

• Schritt 4: Die Regel-Engine prüft die Schwellenwerte.

• Schritt 5: Bei einer Verletzung des Schwellenwerts wird ein Alarm ausgelöst und an eine Ausweichlösung oder menschliche Prüfung weitergeleitet.

• Schritt 6: Der Fehler wird der Triage-Warteschlange und anschließend dem Benchmark-Backlog hinzugefügt.

Echte Nutzerinnen und Nutzer verhalten sich selten genau so, wie es das Entwicklungsteam erwartet. Manche werden Anweisungen missverstehen. Andere werden gezielt nach Schwachstellen suchen. Diese Grenzfälle sind keine Anomalien, sondern äußerst wertvolle Signale. Eine gut implementierte Evaluierungspipeline erfasst und analysiert sie und übernimmt sie in künftige Tests. Schnelle Iterationen ohne blinde Flecken sind nur möglich, wenn die Evaluierung im System verankert und nicht erst nach der Entwicklung ergänzt wird.

Wir empfehlen, Schutzmechanismen und Monitoring von Anfang an zu integrieren:

• Überwache Modellmetriken und Regressionen regelmäßig anhand deines anwendungsspezifischen Benchmarks.

• Erfasse und prüfe Grenzfälle oder adversarielle Eingaben und ergänze damit deinen anwendungsspezifischen Benchmark-Datensatz.

• Stelle sicher, dass diese Evaluierungsmetriken auf deine zentralen KPIs abgestimmt sind.

• Hinterfrage deinen Datensatz und Benchmark regelmäßig, damit du keine neuen Risiken übersiehst oder Verzerrungen unterliegst.

• Implementiere automatische Warnungen bei einer Verschlechterung der Metriken, etwa eine Prüfung, sobald die Genauigkeit unter 85 % fällt.

• Behalte für kritische Entscheidungen einen menschlichen Prüfprozess bei, etwa bei Rechtsberatung, medizinischer Beratung oder Finanztransaktionen.

Jeder Benchmark-Durchlauf verbraucht Rechenleistung und Energie. Jedes redundante Experiment erhöht die Kosten. Verantwortungsvolle Evaluierung sollte Gründlichkeit und Effizienz ins Gleichgewicht bringen.

Mit einigen praktischen Maßnahmen lässt sich verhindern, dass Energieverbrauch und Kosten ausufern:

• Nutze möglichst kleinere Modelle. Führe erste Experimente mit günstigeren Modellen aus und skaliere erst, nachdem du den Ansatz validiert hast.

• Speichere Prompts und API-Aufrufe im Cache.

• Plane Aufgaben energiebewusst ein, etwa durch Stapelverarbeitung, Spot-Instanzen oder flexible Priorität.

• Erfasse neben der Leistung auch die Nutzung von Rechenressourcen.

Behalte ebenso neue KI-Vorschriften im Blick. Auch wenn es kein eigenes Gesetz gibt, gelten bestehende Regelwerke und notwendige Maßnahmen, beispielsweise:

Datenschutz:

• Stelle sicher, dass Benchmark-Datensätze ohne entsprechende Einwilligung keine personenbezogenen Daten enthalten.

• Lege Aufbewahrungsrichtlinien für protokollierte Anfragen fest.

• Stelle Verfahren für Anträge auf Datenlöschung bereit.

Gleichbehandlung und Verzerrungen:

• Prüfe die Leistung für verschiedene demografische Gruppen.

• Achte bei der Erstellung von Benchmarks auf vielfältige Repräsentation.

Menschenrechte und Transparenz:

• Dokumentiere die Grenzen des Modells für Nutzerinnen und Nutzer verständlich.

• Begründe Entscheidungen mit weitreichenden Folgen.

• Ermögliche bei kritischen Anwendungen menschliche Aufsicht.

Evaluierung ist kein einmaliges Ereignis, sondern ein System, das sich laufend weiterentwickelt. In einem dynamischen Bereich liegt dein Vorteil darin, wie schnell du testen, lernen und dich anpassen kannst. So kannst du Modelle und neue Lösungen wirksamer bereitstellen.

Wenn Teams die Evaluierung als zentrale Aufgabe in Entwicklung und Produktmanagement verankern, können sie schneller und sicherer Innovationen voranbringen. Definiere zunächst, was „gut“ im Kontext deiner KI-Anwendung bedeutet, richte eine Evaluierungsplattform ein und entwickle sie weiter. So entsteht ein anwendungsspezifischer Benchmark, mit dem du bei jeder Iteration die Produktionsreife zuverlässig einschätzen kannst.