LLM-Evals

Was sind LLM-Evals?

LLM-Evals sind wiederholbare, automatisierte Tests, die messen, ob die Ausgabe eines Sprachmodells einen definierten Qualitätsstandard erfüllt: Korrektheit, Tonalität, Sicherheit, Format, Aufgabenerfüllung. Während Unit-Tests prüfen, ob Code sich deterministisch verhält, bewerten Evals probabilistische Ausgaben anhand eines Maßstabs – so können Teams Prompts und Modelle ändern, ohne raten zu müssen, ob sich die Qualität verändert hat.

Die wichtigsten Punkte

• Evals sind die Regressionstest-Suite für KI-Features. Ohne sie ist jede Prompt-Anpassung und jedes Modell-Upgrade eine blinde Änderung am Produktivverhalten.
• Ein sinnvolles Eval besteht aus drei Teilen: einem Datensatz repräsentativer Eingaben, einer Bewertungsmethode und einem Schwellenwert, der das Deployment freigibt.
• Bewertungsmethoden werden nach Kosten gestaffelt: zuerst exakte Übereinstimmungen und codebasierte Prüfungen, dann LLM-as-a-Judge für Eigenschaften, die sich nicht per String-Vergleich erfassen lassen, und menschliche Überprüfung zur Kalibrierung.
• Der Datensatz ist wichtiger als das Framework. Zwanzig echte Fehlerfälle aus der Produktion schlagen fünfhundert generische Beispiele.
• Evals sind nie fertig. Jeder Produktionsvorfall sollte zu einem Eval-Fall werden – genauso wie Ausfälle zu Regressionstests werden.

So funktioniert es

Ein Eval-Lauf nimmt einen Datensatz von Eingaben, führt das eigentliche System gegen jede einzelne davon aus (Prompt, Modell, Retrieval – was auch immer im Pfad liegt) und bewertet jede Ausgabe. Der Gestaltungsaufwand konzentriert sich auf die Bewertung. Deterministische Prüfungen kommen zuerst, weil sie kostenlos und eindeutig sind: Ließ sich das JSON parsen, wurde das SQL ausgeführt, enthält die Antwort die vorgeschriebene Klausel zur Rückerstattungsrichtlinie, hat generierter Code seine Tests bestanden. Alles, was die günstigen Prüfungen übersteht, aber noch Urteilsvermögen erfordert – etwa Hilfsbereitschaft oder Treue zu einem Quelldokument –, geht an einen modellbasierten Bewerter, der anhand einer schriftlichen Rubrik urteilt. Ein kleiner Ausschnitt wird regelmäßig von Menschen überprüft, um sicherzustellen, dass die automatisierten Bewerter noch mit dem menschlichen Urteil übereinstimmen.

Scores fließen in Metriken ein, die pro Commit verfolgt werden, genau wie bei einer Test-Suite. Teams binden Evals in die CI ein, sodass eine Prompt-Änderung, die die Aufgabengenauigkeit von 94 auf 81 Prozent senkt, den Merge blockiert, statt still und leise ausgeliefert zu werden. Die Verbreitung hinkt der Rhetorik noch hinterher: In LangChains Umfrage unter mehr als 1.300 Fachleuten Ende 2025 gaben nur 52,4 Prozent der Organisationen an, Offline-Evaluierungen auf Testdatensätzen durchzuführen, und nur 37,3 Prozent führten Online-Evaluierungen durch [1]. Das ist echter Fortschritt gegenüber dem Vorjahr, als dieselbe Umfrage 39,8 Prozent bei Offline-Evals und 32,5 Prozent bei Online-Evals fand [2] – bedeutet aber immer noch, dass etwa die Hälfte der Branche Änderungen nach Gefühl ausliefert. Dieselbe Suite läuft auch, wenn ein Anbieter eine neue Modellversion veröffentlicht – oft die Quelle stiller Regressionen: Der Anbieter hat aktualisiert, die eigenen Prompts blieben gleich, und das Verhalten hat sich darunter verschoben. Das ist zugleich die Verteidigung gegen Modell-Drift.

Den Datensatz aufzubauen ist der wenig glamouröse Kern der Arbeit. Gute Quellen sind Produktionslogs, Support-Eskalationen und Grenzfälle, von denen das Team bereits weiß, dass sie schwierig sind. Synthetische Daten können die Abdeckung erweitern, aber die Ankerbeispiele sollten echt sein. Die meisten Teams starten peinlich klein, mit zehn bis fünfzig Fällen, und erweitern die Suite jedes Mal, wenn etwas kaputtgeht.

Beispiel

Ein Fintech-Team bringt einen Assistenten heraus, der Fragen zu Transaktionsstreitigkeiten beantwortet. Vor dem Launch bauen sie eine Eval-Suite aus 120 echten, anonymisierten Kundenfragen mit Referenzantworten, die von ihren Support-Leitungen verfasst wurden. Jeder Lauf prüft drei Dinge: eine codebasierte Prüfung, dass Antworten niemals eine garantierte Rückerstattungsfrist nennen (eine Compliance-Regel), einen LLM-Judge, der die faktische Übereinstimmung mit der Referenzantwort auf einer Skala von 1 bis 5 bewertet, und eine Formatprüfung auf den vorgeschriebenen Eskalationslink. Die Suite läuft bei jeder Prompt-Änderung. Zwei Monate später veröffentlicht ihr Anbieter ein Modell-Update; der Eval-Lauf entdeckt, dass die neue Version bei einer Chargeback-Frage das falsche Widerspruchsfenster nennt – eine Zeile in einem Report mit 120 Fällen. Sie fixieren die alte Version, korrigieren den Prompt und liefern das Upgrade eine Woche später mit unveränderten Scores aus. Niemand außerhalb des Teams hat die Regression je bemerkt.

Häufige Missverständnisse

Das große Missverständnis ist, dass öffentliche Benchmarks eigene Evals überflüssig machen. Der Score eines Modells auf einem LLM-Benchmark wie MMLU oder SWE-bench sagt etwas über die allgemeine Leistungsfähigkeit aus – aber nichts darüber, ob es mit der eigenen Rückerstattungsrichtlinie, dem eigenen Schema oder den eigenen Tonalitätsvorgaben zurechtkommt. Teams wählen das Modell, das die Bestenliste anführt, verzichten auf eine eigene Suite und stellen in der Produktion fest, dass Benchmark-Rang und Aufgabenleistung bestenfalls lose korreliert sind. Entwickler spüren die Lücke bereits: Die Stack-Overflow-Entwicklerumfrage 2025 fand, dass 46 Prozent der Genauigkeit von KI-Tools aktiv misstrauen, gegenüber 33 Prozent, die ihr vertrauen [3]. Benchmarks wählen Kandidaten aus. Evals mit den eigenen Daten bestimmen den Gewinner und halten ihn ehrlich.

FAQ

Was ist der Unterschied zwischen Evals und Testing? Klassische Tests prüfen deterministisches Verhalten: gleiche Eingabe, gleiche Ausgabe, bestanden oder nicht bestanden. Evals bewerten probabilistische Ausgaben anhand eines Qualitätsstandards und berichten Raten statt Absolutwerte – eine Erfolgsquote von 94 Prozent, kein grünes Häkchen. In der Praxis brauchen KI-Produkte beides: Unit-Tests für den umgebenden Code und Evals für das modellabhängige Verhalten. Die umfassendere Disziplin des KI-Testings beschreibt, wie beide zusammenspielen.

Wie viele Eval-Fälle braucht man für den Start? Weniger, als die meisten Teams denken. Zwanzig bis fünfzig gut gewählte Fälle, die die Hauptaufgabe und bekannte Fehlermodi abdecken, fangen von Tag eins an echte Regressionen ab. Die statistische Sicherheit steigt mit der Größe, aber eine unvollkommene Suite, die bei jeder Änderung läuft, schlägt eine perfekte Suite, die nie zum Einsatz kommt. Man lässt sie aus Produktionsfehlern wachsen.

Sind KI-Evals nur für Chatbots? Nein. Alles mit einem Modell im Ablauf braucht sie: Extraktionspipelines, Codegenerierung, RAG-Systeme und Agenten. Agenten benötigen eine erweiterte Form, die agentenspezifische Evaluierung, die mehrstufige Abläufe und Tool-Nutzung bewertet statt einzelner Antworten.

Quellen

1. LangChain. "State of Agent Engineering"-Umfrage unter mehr als 1.300 Fachleuten: 52,4 % führen Offline-Evaluierungen durch, 37,3 % Online-Evaluierungen. https://www.langchain.com/state-of-agent-engineering. Abgerufen im August 2026.
2. LangChain. "State of AI Agents"-Umfrage unter mehr als 1.300 Fachleuten: 39,8 % nutzten Offline-Evaluierungen, 32,5 % Online-Evaluierungen. https://www.langchain.com/stateofaiagents. Abgerufen im August 2026.
3. Stack Overflow. "2025 Developer Survey": 46 % der Entwickler misstrauen aktiv der Genauigkeit von KI-Tools, 33 % vertrauen ihr. https://survey.stackoverflow.co/2025/ai. Abgerufen im August 2026.