LLM-Evaluierung: KI-Systeme vor der Produktion testen
Jedes KI-Projekt hat einen Moment, in dem jemand „es funktioniert" sagt — meist nachdem das System in einem Meeting drei oder vier Eingaben verarbeitet hat. Das ist eine Demo, keine Messung. Der Abstand zwischen einem System, das in der Demo funktioniert, und einem System, das Sie echten Nutzern vorsetzen können, ist fast vollständig eine Evaluierungslücke: Was Sie nicht gemessen haben, können Sie weder verbessern noch ausliefern noch verteidigen. Dieser Leitfaden zeigt, wie man Evaluierung von Anfang an in ein KI-System einbaut — was man misst, wie man es ohne Budget-Verbrennung bewertet und warum reine Offline-Zahlen ein kaputtes System trotzdem durchlassen.
Warum „es funktioniert" keine Messung ist
Eine Demo ist eine Stichprobe der Größe drei, handverlesen, einmal ausgeführt. „Es funktioniert" sagt unter diesen Bedingungen aus, dass das System nicht völlig kaputt ist. Mehr nicht. Die Fragen, die tatsächlich darüber entscheiden, ob Sie ein Produkt haben, sind andere: Funktioniert es bei Eingaben, die Sie nicht ausgewählt haben? Funktioniert es noch, nachdem Sie den Prompt geändert haben? Ist es besser oder schlechter als letzte Woche? Ist es gut genug zum Ausliefern — und woran würden Sie das erkennen?
Keine dieser Fragen lässt sich ohne eine wiederholbare Messung beantworten. Die Teams, die zuverlässige KI-Systeme ausliefern, sind nicht klüger als die, die es nicht tun. Sie haben festgelegt, was „gut" bedeutet, bevor sie mit dem Bauen anfingen, es als Test aufgeschrieben und diesen Test bei jeder Änderung laufen lassen. Alles andere in diesem Leitfaden ist Mechanik. Diese Entscheidung ist die eigentliche Disziplin — und sie fehlt am häufigsten bei den KI-Projekten, die vor der Produktion scheitern.
Was Sie tatsächlich evaluieren
„Evaluierung" wird benutzt, als bedeute es eine Sache. Es bedeutet drei — und sie zu vermischen ist der Grund, warum Teams am Ende gleichzeitig einen hohen Score und eine unzufriedene Nutzerbasis haben.
Aufgabenqualität — erledigt der Output die Aufgabe
Korrektheit, Vollständigkeit, Formattreue, Treue zum Quellmaterial. Das ist, was die meisten sich unter „Evaluierung" vorstellen — und es ist nur ein Drittel des Bildes.
Regressionen — hat eine Änderung etwas anderes kaputt gemacht
Einen Prompt zu reparieren verschlechtert fast immer einen anderen Fall. Ohne eine Möglichkeit, die gesamte Oberfläche zu messen, tauschen Sie sichtbare Fehler gegen unsichtbare und nennen es Fortschritt.
Betriebskosten — Latenz und Tokens pro Anfrage
Ein System, das zwei Prozent genauer, aber dreimal langsamer und viermal teurer ist, kann das schlechtere System sein. Qualitätszahlen ohne Kostenzahlen sind eine halbe Entscheidung.
Sie brauchen alle drei. Die meisten Teams messen das erste, schätzen das zweite über den Daumen und erfahren das dritte aus der Rechnung.
Das Eval-Set ist das eigentliche Asset
Das wertvollste Artefakt in einem KI-Projekt ist nicht der Prompt und nicht das Modell. Es ist das beschriftete Set aus Eingaben mit bekannt guten Outputs. Prompt und Modell sind Dinge, die Sie wieder und wieder ändern werden; das Eval-Set ist der Fixpunkt, der Ihnen sagt, ob die Änderung geholfen hat. Bauen Sie es, bevor Sie das System bauen.
Woher die Beispiele kommen
Echte Eingaben schlagen synthetische. Ziehen Sie aus echten Nutzeranfragen, Support-Tickets, den Dokumenten, die das System wirklich sehen wird. Synthetische Beispiele sind in Ordnung, um eine Abdeckungslücke zu füllen — ein seltener Fall, für den Sie noch keine echten Daten haben — aber ein Eval-Set, das vollständig synthetisch ist, misst nur, wie gut Ihr Modell mit dem Modell übereinstimmt, das die Daten erzeugt hat.
Umfang: kleiner als gedacht, aber bewusst gewählt
Sie brauchen keine zehntausend Fälle. Sie brauchen fünfzig bis zweihundert, bewusst ausgewählt: den häufigen Fall, den langweiligen Fall, die bekannten schweren Fälle, die Edge Cases, die Sie schon einmal getroffen haben, und eine Handvoll adversarialer Eingaben. Ein kuratiertes Set aus achtzig Fällen, das Ihre echten Fehlermuster abdeckt, schlägt einen zufälligen Abzug von zweitausend Fällen jedes Mal — und Sie werden sich die Ergebnisse tatsächlich ansehen.
Jeder Fall braucht eine Daseinsberechtigung
Jeder Fall braucht drei Dinge: die Eingabe, den erwarteten Output oder die erwarteten Eigenschaften des Outputs, und eine einzeilige Notiz, warum er im Set ist — „Regression für den Bug vom März", „testet die Ablehnung von Anfragen außerhalb des Scopes", „der häufige Fall". Diese Notiz ist das, was verhindert, dass das Eval-Set zu einem Haufen Beispiele verkommt, dem niemand traut und den niemand zu löschen wagt.
Eine Scoring-Leiter: die günstigste Methode, die noch unterscheidet
Greifen Sie nicht zuerst zur teuren Bewertungsmethode. Steigen Sie die Leiter hinauf und halten Sie auf der untersten Sprosse an, die den Unterschied zwischen einem guten und einem schlechten Output noch erkennt.
1. Deterministische Checks
Wurde gültiges JSON zurückgegeben? Sind die Pflichtfelder vorhanden? Liegt es unter dem Längenlimit? Wurde eine Quellen-ID zitiert, die tatsächlich existiert? Kostenlos, sofort, und sie fangen die meisten katastrophalen Fehler. Hier fängt man immer an.
2. Property-Assertions
Kein Exact Match — Exact Match bricht bei jeder gültigen Umformulierung — sondern konkrete, prüfbare Aussagen: die Antwort enthält die Bestellnummer, die Zusammenfassung nennt die Frist, keine PII im Output. Günstig, robust, und sie kodieren, worauf es wirklich ankommt, statt der exakten Worte.
3. LLM-as-Judge
Ein separates Modell bewertet den Output gegen eine Rubrik. Notwendig für alles wirklich Subjektive — Tonfall, Hilfreichkeit, Qualität der Argumentation, ob eine Antwort gut strukturiert ist. Mächtig und leicht zu missbrauchen — der nächste Abschnitt handelt ausschließlich davon, sich damit nicht selbst zu täuschen.
4. Menschliche Bewertung
Die Grundwahrheit, und die teuerste Sprosse. Reservieren Sie sie für die Kalibrierung der günstigeren Methoden und für die Fälle, in denen die günstigeren Methoden uneins sind. Sie können nicht jeden Lauf von Hand bewerten; Sie können genug von Hand bewerten, um der Automatisierung zu trauen, die es tut.
Faustregel: Ein deterministischer Check, der einen echten Bug fängt, ist mehr wert als ein LLM-Judge, der eine Meinung dazu hat.
LLM-as-Judge, ohne sich selbst zu täuschen
LLM-as-Judge ist das Arbeitspferd moderner Evaluierung und die einfachste Stelle, sich selbst stillschweigend zu belügen. Die Fehlermodi sind gut bekannt — und in einem echten Projekt treffen Sie sie alle.
Positions- und Verbosity-Bias
Judge-Modelle bevorzugen die zuerst gezeigte Option und die längere Antwort, unabhängig von der Qualität. Wenn Sie zwei Outputs vergleichen, randomisieren Sie die Reihenfolge und kontrollieren Sie für die Länge — sonst messen Sie Formatierung und nennen es Qualität.
Self-Preference
Ein Modell, das Outputs bewertet, neigt dazu, den Stil seiner eigenen Modellfamilie höher zu bewerten. Wenn dasselbe Modell den Output erzeugt und benotet, sind Ihre Scores zu optimistisch. Nutzen Sie ein anderes Modell — idealerweise einen anderen Anbieter — als Judge.
Vage Rubriken erzeugen vage Scores
„Bewerten Sie die Hilfreichkeit von eins bis zehn" liefert Rauschen im Gewand einer Zahl. „Beantwortet die Antwort die Frage des Nutzers, ohne Fakten zu erfinden? Ja oder nein, dann eine Zeile Begründung" liefert ein Signal. Nutzen Sie binäre Skalen oder solche mit wenigen Stufen und explizit ausformulierten Kriterien.
Keine Kalibrierung gegen Menschen
Ein LLM-Judge, den Sie nie gegen menschliche Labels geprüft haben, ist ein unvalidiertes Messinstrument. Beschriften Sie dreißig bis fünfzig Fälle von Hand, messen Sie, wie oft der Judge zustimmt, und prüfen Sie diese Übereinstimmung erneut, sobald Sie das Judge-Modell oder die Rubrik ändern.
LLM-as-Judge ist ein Messwerkzeug, kein Orakel. Behandeln Sie es so: kalibrieren, versionieren — und misstrauen Sie einem Score, der in derselben Woche gestiegen ist, in der Sie den Judge geändert haben.
Regressionstests: Wo sich Evaluierung auszahlt
Der erste Eval-Lauf sagt Ihnen, wo Sie stehen. Jeder Lauf danach ist der eigentliche Ertrag der Arbeit. KI-Systeme ändern sich permanent — Prompts werden getunt, Modelle ausgetauscht, eine Abhängigkeit aktualisiert sich, ein Anbieter justiert stillschweigend das Modell hinter einem stabilen API-Namen. Jedes davon kann Ihren Zielfall verbessern und leise fünf andere kaputt machen.
Lassen Sie das vollständige Eval-Set bei jeder bedeutsamen Änderung laufen: Prompt-Änderungen, Modell-Versionssprünge, Retrieval-Änderungen, ein neu aufgebauter RAG-Index. Und dann setzen Sie ein Gate davor. Eine Änderung, die den Score unter einen vereinbarten Schwellenwert drückt, wird nicht gemergt. Das Eval-Set als Merge-Gate in die CI einzubauen ist der wirkungsvollste Punkt auf dieser Liste — und der, den die meisten Teams überspringen, weil er sich nach Overhead anfühlt, bis er zum ersten Mal eine Regression fängt, die Sie gerade ausliefern wollten.
Zwei Fälle verdienen besondere Aufmerksamkeit. Wenn Sie Modelle wechseln — auch beim „Upgrade" auf ein neueres — ist das Eval-Set, wie Sie herausfinden, was Sie eingetauscht haben; neuer ist für Ihre konkrete Aufgabe nicht durchgängig besser. Und achten Sie auf Anbieter-Drift: Ein gehostetes Modell hinter einem stabilen API-Namen ist kein stabiles Modell. Regelmäßige erneute Läufe gegen ein fixes Eval-Set fangen diese Änderung, bevor Ihre Nutzer es tun. Dieselbe Disziplin gilt, ob Sie einen Prompt, eine Retrieval-Pipeline oder ein feingetuntes Modell evaluieren.
Offline-Evals reichen nicht: in der Produktion messen
Ein perfekter Score auf Ihrem Eval-Set bedeutet, dass das System die Eingaben verarbeitet, an die Sie gedacht haben. Die Produktion sind die Eingaben, an die Sie nicht gedacht haben. Offline-Evaluierung ist notwendig und sie ist nicht hinreichend — Sie müssen das System auch dort messen, wo es tatsächlich läuft.
Echten Traffic stichprobenartig mitschneiden
Loggen Sie Eingabe, Output, abgerufenen Kontext und Token-Zahlen für eine Stichprobe der Live-Anfragen. Sie können nicht reparieren, was Sie nicht sehen — und die Verteilung echter Eingaben driftet mit der Zeit immer von Ihrem Eval-Set weg.
Auf die günstigen Online-Signale achten
Implizites Feedback — hat der Nutzer es erneut versucht, umformuliert, die Sitzung abgebrochen, die Antwort kopiert oder an einen Menschen eskaliert — ist verrauschter als ein Label, aber es ist kostenlos und es ist echt. Ein plötzlicher Anstieg von Wiederholungen ist ein Regressionsalarm, den Sie nicht bauen mussten.
Produktionsfehler zurück ins Eval-Set speisen
Jeder echte Fehler, der nicht schon im Eval-Set war, ist eine Lücke im Set. Die Schleife ist einfach: Die Produktion bringt einen Fehler ans Licht, er wird zu einem beschrifteten Fall, der Regressionstest fängt ihn für immer. Diese Schleife ist es, die ein System besser werden lässt statt nur anders.
Wo man anfängt
Sie brauchen keine Eval-Plattform, keinen Anbieter und kein Framework, um zu beginnen. Die erste Version ist bewusst schlicht:
Eins. Fünfzig echte Eingaben mit bekannt guten Outputs, in einer Datei, jede mit einer Notiz, warum sie da ist.
Zwei. Ein Skript, das sie durch das System laufen lässt und deterministische Checks plus eine Handvoll Property-Assertions anwendet.
Drei. Eine Zahl am Ende und die Liste, welche Fälle durchgefallen sind.
Lassen Sie es vor und nach Ihrer nächsten Änderung laufen. Das erste Mal, dass es eine Regression fängt, die Sie ausgeliefert hätten, hat es sich bezahlt gemacht. Fügen Sie LLM-as-Judge hinzu, wenn deterministische Checks wirklich nicht erfassen können, worauf es Ihnen ankommt — nicht vorher. Fügen Sie Produktions-Tracing hinzu, sobald das Offline-Set stabil ist. Die Teams mit zuverlässigen KI-Systemen sind nicht mit ausgefeilter Evaluierung gestartet; sie sind mit einer Datei voller Beispiele gestartet und der Disziplin, sie bei jeder Änderung laufen zu lassen.
Weiterführend: warum die meisten KI-Projekte vor der Produktion scheitern, LLM-Integration in Geschäftssysteme, und der LoRA-Fine-Tuning-Praxisleitfaden.