LLM-Evaluierung (Evals) ist die systematische Messung, wie gut eine Sprachmodell-Anwendung eine Aufgabe erfüllt. Sie kombiniert Testdatensätze, automatische Prüfungen, modellbasierte Bewerter und menschliches Review, um Eigenschaften wie Korrektheit, Quellentreue, Relevanz, Sicherheit und Format zu bewerten, vor einem Release und laufend im Produktivbetrieb.
Was ist LLM-Evaluierung?
LLM-Evaluierung, kurz Evals, beantwortet eine Frage, die klassische Tests nicht beantworten können: Ist die Ausgabe eines nicht deterministischen Modells gut genug? Ein Unit-Test prüft, ob eine Funktion einen exakten Wert liefert. Ein LLM kann eine richtige Antwort auf viele Arten formulieren, und eine flüssige Antwort kann trotzdem falsch sein. Evals bewerten Ausgaben deshalb anhand von Kriterien, über viele Beispiele hinweg, und verfolgen diese Bewertungen über die Zeit.
Evals sind immer dann wichtig, wenn sich etwas ändert: eine neue Modellversion, ein angepasster Prompt, eine andere Retrieval-Strategie oder ein neues Tool. Ohne Evals beurteilen Teams Änderungen anhand weniger manueller Versuche, und Verschlechterungen fallen erst auf, wenn Nutzer sich beschweren.
Eine gute Eval-Suite macht aus vagen Eindrücken wie „das neue Modell fühlt sich besser an“ Zahlen pro Kriterium und Kategorie. Entscheidungen werden dadurch nachvollziehbar: Ein Team erkennt etwa, dass ein günstigeres Modell bei einfachen Fragen gleich gut, bei komplexen aber schlechter abschneidet, und kann den Verkehr entsprechend aufteilen. Evals dokumentieren zudem, was die Anwendung leisten soll. Das hilft, wenn mehrere Personen Prompts und Konfiguration ändern.
Arten von Evals
- Offline-Evals schicken vor einem Release einen festen Datensatz von Eingaben, idealerweise mit Referenzantworten, durch die Anwendung. Sie funktionieren wie eine Regressionstest-Suite.
- Online-Evals bewerten laufend eine Stichprobe echter Produktivanfragen, meist ohne Referenzantwort.
- Menschliche Bewertung durch Fachexperten bleibt die Referenz für feine Qualitätsfragen und dient zur Kalibrierung automatischer Verfahren.
- Red-Team-Evals prüfen die Robustheit gegen bösartige Eingaben wie Prompt Injection.
Methoden und Metriken
| Methode | Geeignet für | Grenze |
|---|---|---|
| Deterministische Prüfungen (exakter Vergleich, Regex, JSON-Schema) | Klassifikation, Extraktion, strukturierte Ausgaben | Kann Freitext nicht beurteilen |
| Ähnlichkeit zur Referenz (z. B. Embedding-Ähnlichkeit) | Antworten mit bekannter Referenz | Ähnliche Formulierung heißt nicht korrekter Inhalt |
| LLM-as-a-Judge | Relevanz, Quellentreue, Tonalität, Hilfsbereitschaft | Bewerter haben Verzerrungen und müssen an menschlichen Urteilen kalibriert werden |
| Aufgabenerfolg | Agenten: Ziel erreicht, mit wie vielen Schritten | Erfordert eine klare Definition von Erfolg |
Für RAG-Systeme sind gängige Kriterien Kontextrelevanz (hat das Retrieval die richtigen Dokumente gefunden), Quellentreue oder Faithfulness (ist die Antwort durch sie belegt) und Antwortrelevanz. Faithfulness-Werte sind ein praktischer Weg, Halluzinationen messbar zu machen.
Beispiel: eine Prompt-Änderung bewerten
Ein illustratives Vorgehen: Ein Team pflegt 300 kuratierte Fragen für seinen Dokumentations-Assistenten, jeweils mit Referenzantwort und erwarteter Quelle. Vor dem Wechsel auf eine neue Prompt-Version laufen beide Versionen über den Datensatz. Ein Bewertermodell vergibt Werte von 0 bis 1 für Quellentreue und Relevanz, deterministische Prüfungen stellen sicher, dass jede Antwort eine Quelle nennt, und Token-Verbrauch sowie Latenz werden mit erfasst. Der neue Prompt schneidet bei der Relevanz besser ab, bei Preisfragen aber schlechter in der Quellentreue. Das Team korrigiert ihn vor dem Rollout und gibt ihn dann als Canary für einen kleinen Teil des Verkehrs frei, mit aktiven Online-Evals.
Best Practices
- Bauen Sie den Datensatz aus echten Nutzerfragen auf, inklusive schwieriger Fälle und Grenzfälle, und erweitern Sie ihn um jeden Fehler aus der Produktion.
- Definieren Sie Kriterien präzise und geben Sie Bewertern eine Rubrik mit Beispielen.
- Kalibrieren Sie LLM-Bewerter an menschlichen Urteilen und prüfen Sie erneut, wenn Sie das Bewertermodell wechseln.
- Bewerten Sie Qualität zusammen mit Kosten und Latenz; eine bessere Antwort, die dreimal so lange dauert, ist nicht unbedingt eine Verbesserung.
- Vergleichen Sie mit einer Baseline, nicht nur mit absoluten Zahlen.
- Versionieren Sie Datensätze, Prompts, Modelle und Bewerterkonfigurationen, damit Ergebnisse reproduzierbar bleiben.
Häufige Fehler
Typische Fallstricke sind zu kleine oder zu einfache Datensätze, Bewerter, die lange Antworten bevorzugen, Evaluierung nur vor dem Release statt auch im Betrieb und Durchschnittswerte, die Ausfälle in einer wichtigen Kategorie verdecken. Berichten Sie Werte pro Kategorie und sehen Sie sich die schlechtesten Beispiele an, nicht nur den Mittelwert.
Ein weiteres häufiges Problem ist die isolierte Bewertung des Modells. Im Betrieb hängt die Qualität von der gesamten Kette ab: Retrieval, Zusammenbau des Prompts, Tool-Aufrufe und Nachverarbeitung. Evals sollten deshalb gegen den echten Anwendungspfad laufen, und ihre Ergebnisse sollten mit Traces verknüpft sein. So lässt sich ein schlechter Wert auf den Schritt zurückführen, der ihn verursacht hat. Halten Sie außerdem Bewertermodell und Bewerter-Prompt stabil, während Sie Versionen vergleichen; wer Bewerter und Anwendung gleichzeitig ändert, kann die Ergebnisse nicht mehr sinnvoll deuten.
Wie Obseria hilft
Die AI Observability von Obseria bringt eingebaute Bewerter für Relevanz, Quellentreue, Toxizität und Datenlecks im Produktivverkehr mit und vergleicht Qualität, Kosten und Latenz über Modell- und Prompt-Versionen hinweg in denselben Traces.
