"Sieht gut aus" ist kein Qualitätsmaßstab
Ein Maschinenbauunternehmen führt einen KI-Assistenten ein, der Angebotsanfragen vorqualifiziert: Er liest eingehende Anfragen, extrahiert die wichtigsten Eckdaten und schlägt eine Einordnung vor. In der Demo begeistert das System alle Beteiligten. Der Projektleiter tippt ein paar Beispielanfragen ein, die Antworten wirken plausibel, das Projekt geht live. Drei Monate später beschwert sich der Vertrieb: Bei Anfragen mit mehreren Positionen übersieht das System regelmäßig die zweite Position, und seit dem letzten Update des zugrunde liegenden Modells formatiert es Mengenangaben anders, was den nachgelagerten Import bricht. Niemand kann sagen, seit wann das so ist, wie oft es passiert oder ob es früher besser war. Es gibt schlicht keine Messung.
Diese Geschichte wiederholt sich in unzähligen Varianten, und sie hat eine gemeinsame Wurzel: Sprachmodelle sind nicht deterministisch. Dieselbe Eingabe kann unterschiedliche Ausgaben erzeugen, kleine Änderungen am Prompt können große Auswirkungen an unerwarteter Stelle haben, und ein Modellwechsel des Anbieters verändert das Verhalten, ohne dass sich an Ihrem Code eine Zeile geändert hätte. Klassische Software testet man mit Unit-Tests, die entweder grün oder rot sind. Bei KI-Systemen ist die Antwort selten eindeutig richtig oder falsch, sondern mehr oder weniger gut. Genau deshalb braucht es ein eigenes Instrumentarium: Evals.
Was Evals sind und wie man sie aufbaut
Ein Eval, kurz für Evaluation, ist im Kern eine Sammlung repräsentativer Testfälle mit definierten Erwartungen, gegen die das KI-System automatisiert geprüft wird. Repräsentativ ist das entscheidende Wort: Die Testfälle sollten die tatsächliche Vielfalt des Produktivbetriebs abbilden, nicht die drei Schönwetter-Beispiele aus der Demo. Für den Angebots-Assistenten von oben hieße das: kurze und lange Anfragen, Anfragen mit einer und mit fünf Positionen, Anfragen mit Tippfehlern, mit ungewöhnlichen Einheiten, auf Englisch, mit fehlenden Angaben, mit widersprüchlichen Angaben. Eine gute erste Quelle sind echte Fälle aus der Vergangenheit, ergänzt um konstruierte Grenzfälle und um Fälle, die schon einmal schiefgegangen sind. Jeder Produktionsfehler, den Sie entdecken, sollte als neuer Testfall im Eval landen, so wächst das Sicherheitsnetz mit.
Zu jedem Testfall gehört eine Erwartung, und je nach Aufgabe sind unterschiedliche Metriken sinnvoll. Bei extraktiven Aufgaben lässt sich Korrektheit oft hart prüfen: Wurde die richtige Artikelnummer erkannt, stimmt die Menge, ist das Datum korrekt? Format-Treue ist ebenfalls exakt messbar: Ist die Ausgabe gültiges JSON, sind alle Pflichtfelder vorhanden, hält sich die Antwort an die maximale Länge? Andere Kriterien sind weicher, etwa Tonalität, Vollständigkeit einer Zusammenfassung oder ob eine Antwort beim Thema bleibt. Wichtig ist, die Kriterien vorher explizit zu machen. Ein Eval mit fünfzig durchdachten Fällen und klaren Erwartungen ist mehr wert als tausend Fälle, bei denen niemand definiert hat, was "bestanden" bedeutet.
#
Vom Testfall zur Kennzahl
Aus den Einzelergebnissen entsteht eine Kennzahl, etwa: 92 Prozent der Fälle korrekt extrahiert, 100 Prozent formattreu, durchschnittliche Bewertung 4,1 von 5. Diese Zahlen sind das Fundament für alles Weitere, denn sie machen Veränderung sichtbar. Sinnvoll ist dabei, nicht nur den Gesamtdurchschnitt zu betrachten, sondern die Ergebnisse nach Fallgruppen aufzuschlüsseln: Ein System, das insgesamt bei 90 Prozent liegt, aber bei mehrsprachigen Anfragen nur 60 Prozent erreicht, hat ein anderes Problem als eines, das gleichmäßig bei 85 Prozent liegt. Solche Untergruppen-Auswertungen zeigen, wo gezielt nachgearbeitet werden muss, statt pauschal am Prompt zu drehen.
Ein Wort zur Wiederholbarkeit: Weil Sprachmodelle bei gleicher Eingabe unterschiedlich antworten können, lohnt es sich, kritische Testfälle mehrfach laufen zu lassen und die Streuung zu betrachten. Ein Fall, der mal besteht und mal durchfällt, ist kein bestandener Fall, sondern ein Hinweis auf ein instabiles Verhalten, das im Produktivbetrieb genauso zufällig auftreten wird. Gerade bei Aufgaben mit hartem Richtig-oder-Falsch-Charakter ist diese Flatterhaftigkeit oft der interessanteste Befund des gesamten Eval-Laufs, denn sie zeigt, wo das System an seiner Verlässlichkeitsgrenze arbeitet.
Der Vergleichslauf: vor jedem Release, vor jedem Modellwechsel
Ihren größten Wert entfalten Evals als Regressionstest. Bevor eine geänderte Version live geht, sei es ein umformulierter Prompt, eine neue Retrieval-Logik oder ein Wechsel auf ein neueres Modell, läuft das komplette Eval einmal gegen die alte und einmal gegen die neue Variante. Erst der Vergleich beider Läufe beantwortet die entscheidende Frage: Ist die neue Version wirklich besser, oder nur anders?
Das Ergebnis ist oft ernüchternd und genau deshalb so wertvoll. Ein Prompt-Feinschliff, der die Höflichkeit verbessert, verschlechtert vielleicht die Extraktionsgenauigkeit bei langen Anfragen. Ein neues Modell ist in Summe stärker, versagt aber ausgerechnet bei den zehn Fällen mit handschriftlich eingescannten Anlagen, die für Ihren wichtigsten Kunden typisch sind. Ohne Eval fallen solche Regressionen erst im Betrieb auf, mit Eval sehen Sie sie vor dem Release in einer Tabelle. Der Vergleich sollte dabei fallweise erfolgen, nicht nur in der Summenzeile: Interessant sind vor allem die Fälle, die vorher bestanden und jetzt durchfallen, denn sie zeigen konkret, was die Änderung gekostet hat, und die neu bestandenen Fälle zeigen, was sie gebracht hat. Erst dieses Gegeneinander erlaubt eine informierte Abwägung statt eines Bauchgefühls mit Zahlenanstrich. Bewährt hat sich, den Eval-Lauf fest in den Entwicklungsprozess einzubauen, analog zur Continuous Integration in der Softwareentwicklung: Kein Merge und kein Release ohne Vergleichslauf, und bei signifikanter Verschlechterung wird nicht deployt. Auch Modell-Updates des Anbieters, die sich nicht abwählen lassen, verlieren so ihren Schrecken, weil Sie zumindest sofort wissen, was sich verändert hat.
LLM-as-Judge: das Modell als Gutachter, mit Vorsicht
Bei weichen Kriterien wie "Ist die Zusammenfassung vollständig und sachlich richtig?" stößt regelbasierte Prüfung an Grenzen, und Menschen jeden Eval-Lauf bewerten zu lassen, skaliert nicht. Hier kommt das Muster LLM-as-Judge ins Spiel: Ein Sprachmodell bewertet die Ausgaben eines anderen (oder desselben) Systems anhand einer präzisen Bewertungsanleitung, einer sogenannten Rubrik. Der Judge bekommt die Aufgabe, die Ausgabe und klare Kriterien, etwa: Vergib 1 bis 5 Punkte für faktische Korrektheit, begründe die Bewertung, ziehe Punkte ab, wenn Informationen erfunden wurden.
Das funktioniert erstaunlich gut, verlangt aber Sorgfalt, denn der Richter hat eigene Schwächen. Die wichtigste Regel: Kalibrieren Sie den Judge gegen menschliche Urteile. Lassen Sie einige Dutzend Fälle parallel von Fachleuten und vom Judge bewerten und prüfen Sie, wie stark beide übereinstimmen. Erst wenn die Übereinstimmung hoch genug ist, dürfen Sie den automatischen Urteilen trauen, und diese Validierung sollte regelmäßig wiederholt werden. Bekannte Verzerrungen sind gut dokumentiert: Judges bevorzugen tendenziell längere, ausführlichere Antworten, auch wenn die Länge keinen Mehrwert bringt, dieser Längen-Bias lässt sich durch explizite Anweisungen in der Rubrik und durch Gegenprüfungen abmildern. Bei Paarvergleichen spielt zudem die Reihenfolge eine Rolle, weshalb man beide Reihenfolgen testen sollte, und Modelle neigen dazu, Ausgaben im eigenen Stil wohlwollender zu bewerten. Ein Judge ist also ein nützlicher, aber befangener Gutachter: brauchbar mit klarer Rubrik, Kalibrierung und Stichprobenkontrolle durch Menschen, gefährlich als unkontrollierte Blackbox.
Observability: das Messnetz im Produktivbetrieb
Evals prüfen vor dem Release, Observability beobachtet danach. Gemeint ist die systematische Erfassung dessen, was Ihr KI-System im echten Betrieb tut: Welche Prompts wurden gesendet, welche Antworten kamen zurück, wie lange dauerte die Verarbeitung, was hat der Aufruf gekostet, welche Fehler traten auf? Solche Traces, also nachvollziehbare Aufzeichnungen jedes einzelnen Durchlaufs inklusive aller Zwischenschritte, sind bei mehrstufigen Systemen mit Retrieval und Werkzeugaufrufen Gold wert, weil sich nur so klären lässt, an welcher Stelle einer Kette ein Fehler entstand.
Auf dieser Datenbasis lassen sich die Kennzahlen überwachen, die im Alltag zählen: Latenz und deren Ausreißer, Kosten pro Anfrage und pro Monat, Fehlerraten wie ungültige Formate oder abgebrochene Aufrufe, und die Entwicklung all dessen über die Zeit. Dazu gehört auch Nutzerfeedback als billigste und ehrlichste Qualitätsquelle: ein simples Daumen-hoch-Daumen-runter an jeder Antwort, die Quote der Fälle, in denen Nutzer die KI-Antwort manuell korrigieren, oder die Rate der Eskalationen an menschliche Bearbeiter. Negativ bewertete Fälle fließen zurück ins Eval, womit sich der Kreis schließt: Produktion liefert die Testfälle von morgen. Wer diesen Kreislauf etabliert, verwandelt ein launisches System schrittweise in ein verlässliches.
Für den Einstieg braucht es dabei keine große Plattform. Ein strukturiertes Log, das zu jeder Anfrage eine Kennung, Zeitstempel, Prompt-Version, Modellname, Ein- und Ausgabe, Dauer und Token-Verbrauch festhält, deckt bereits die wichtigsten Fragen ab und lässt sich in wenigen Stunden einbauen. Spezialisierte Observability-Werkzeuge für LLM-Anwendungen, von denen es inzwischen etliche offene und kommerzielle gibt, ergänzen darauf aufbauend komfortable Auswertungen, Trace-Ansichten über mehrstufige Abläufe und die Verknüpfung von Produktionsdaten mit Eval-Läufen. Wichtiger als das Werkzeug ist die Gewohnheit: Wer Kennzahlen erhebt, aber nie hineinschaut, hat nur teurere Blindheit. Ein fester wöchentlicher Blick auf Fehlerraten, Kostenverlauf und die schlechtesten bewerteten Antworten der Woche kostet dreißig Minuten und entdeckt Probleme Wochen vor der ersten Kundenbeschwerde. Und denken Sie beim Loggen an den Datenschutz: Prompts und Antworten können personenbezogene Daten enthalten, also gehören Aufbewahrungsfristen, Zugriffsrechte und gegebenenfalls Pseudonymisierung von Anfang an ins Konzept.
Fazit: Messen macht KI erwachsen
Der Unterschied zwischen einem KI-Experiment und einem KI-Produkt liegt nicht im Modell, sondern in der Messbarkeit. Evals mit repräsentativen Testfällen und klaren Erwartungen machen Qualität vergleichbar, Vergleichsläufe vor jedem Release verhindern schleichende Regressionen, ein kalibrierter LLM-Judge skaliert die Bewertung weicher Kriterien, und Observability hält das Ohr am Produktivbetrieb. Drei nächste Schritte: Sammeln Sie zwanzig bis fünfzig echte Fälle aus Ihrer Anwendung und notieren Sie zu jedem, was eine gute Antwort ausmacht. Bauen Sie daraus einen ersten automatisierten Eval-Lauf und machen Sie ihn zur Pflicht vor jeder Änderung. Und ergänzen Sie Ihre Anwendung um ein einfaches Feedback-Signal, damit die Produktion Ihnen laufend neue Testfälle liefert. Falls Sie sich dabei Begleitung wünschen: FJ Design unterstützt Unternehmen beim Aufbau messbar guter KI-Systeme.