LLM-Evaluierungsframework: So bauen Sie eines auf (und die Tools, die es ausführen)

Wenn Ihr Team einen Prompt ändert, ein Modell austauscht oder eine Wissensdatenbank neu in Chunks aufteilt, muss jemand entscheiden, ob diese Änderung live gehen darf. Ohne ein LLM-Evaluierungsframework stützt sich diese Entscheidung auf ein paar manuelle Stichproben und die Meinung der Person, die sich die Ausgaben zuletzt angesehen hat. Für eine Demo reicht das, beim ersten Modell-Upgrade bricht es zusammen.

Kurz zusammengefasst: Legen Sie für jeden Anwendungsfall fest, was „gut“ bedeutet, sammeln Sie 50 bis 200 reale Beispiele mit dem erwarteten Verhalten, bewerten Sie diese mit einer Mischung aus Code-Checks, kalibrierten LLM-Judges und menschlicher Prüfung, und blockieren Sie jedes Release, das unter die vereinbarten Schwellenwerte fällt. Eine erste funktionsfähige Version bedeutet für einen Engineer in der Regel ein bis zwei Wochen Arbeit. Die laufenden Kosten danach bestehen hauptsächlich aus API-Aufrufen an das Judge-Modell sowie einigen Stunden menschlicher Prüfung pro Monat. Dieser Leitfaden führt Sie durch die sechs Schritte und vergleicht anschließend acht Tools, mit denen Sie sie umsetzen. Wenn Sie das Framework lieber für sich aufbauen und betreiben lassen möchten, genau das decken unsere Leistungen für LLM-Evaluierung ab.

Was ist ein LLM-Evaluierungsframework

Ein LLM-Evaluierungsframework ist der wiederholbare Prozess, mit dem ein Team nachweist, dass ein LLM-Feature gut genug für den Release ist: die Qualitätsziele, ein Golden Dataset (Referenzdatensatz), die Metriken, die Evaluatoren, die diese Metriken bewerten, Bestehensschwellen und ein Zeitplan, nach dem all das läuft. Bibliotheken wie DeepEval und Ragas sind die Tools, die diesen Prozess ausführen.

Das Wort „Framework“ wird für zwei verschiedene Dinge verwendet, und wer beides vermischt, hat am Ende ein Tool installiert, aber keine Evaluierungsstrategie. Ihr Framework ist die Summe Ihrer Entscheidungen: welche Verhaltensweisen zählen, wie Sie sie messen und welcher Score ein Release blockiert. Eine Framework-Bibliothek ist Code, der diese Entscheidungen für Sie ausführt, mit Metrik-Implementierungen, Test-Runnern und Dashboards. Die Bibliothek können Sie später austauschen und dabei jede dieser Entscheidungen beibehalten.

Die einzelnen Tests innerhalb des Frameworks heißen meist LLM-Evals. Ein Eval prüft zum Beispiel, dass ein Support-Bot nie einen Erstattungsbetrag verspricht; ein anderes bewertet, ob eine Zusammenfassung dem Quelldokument treu bleibt.

Kernkomponenten eines LLM-Evaluierungsframeworks

Jedes funktionierende Framework besteht aus denselben sechs Teilen, unabhängig davon, welches Tool es ausführt. Ziele und Datensätze legen fest, was Sie testen, Metriken und Evaluatoren legen fest, wie jede Ausgabe bewertet wird, und Schwellenwerte und Ausführungsrhythmus entscheiden, was mit dem Score passiert. Fehlt einer davon, verlieren die übrigen den Großteil ihres Werts: Eine gut gewählte Metrik ohne Schwellenwert liefert eine Zahl, auf die niemand reagiert, und ein Schwellenwert, der nur vor dem Launch geprüft wird, übersieht jede Regression, die danach auftritt. Die Tabelle zeigt alle sechs Teile am Beispiel eines Kundensupport-Assistenten.

Evaluatoren verdienen einen genaueren Blick, denn dort liegen die meisten Kosten und die meisten Vertrauensprobleme:

• Code-basierte Checks (Regex, Schemavalidierung, Exact Match, „wurde die richtige Funktion aufgerufen?“) sind günstig, deterministisch und eng gefasst. Setzen Sie sie für alles ein, was genau eine richtige Antwort hat.
• LLM-as-a-Judge bewertet subjektive Qualitäten wie Faithfulness (Quellentreue), Nützlichkeit oder Ton in großem Maßstab. Jeder Score kostet einen API-Aufruf, und das Ergebnis ist nur so vertrauenswürdig wie die Kalibrierung des Judges.
• Menschliche Reviewer sind der Referenzpunkt. Sie sind zu langsam, um jeden Durchlauf zu bewerten, daher besteht ihre Hauptaufgabe darin, das Kalibrierungsset zu labeln und die Fälle zu prüfen, bei denen sich die automatisierten Evaluatoren uneinig sind.

So bauen Sie ein LLM-Evaluierungsframework in 6 Schritten auf

Diese sechs Schritte bringen Sie von „wir schauen uns die Ausgaben mal an“ zu einem Framework, das über Releases entscheidet. Die Reihenfolge ist wichtig: Metriken, die gewählt werden, bevor die Anwendungsfälle definiert sind, messen meist das, was das Tool am einfachsten macht.

Schritt 1: Anwendungsfälle und Risikostufen definieren

Listen Sie jede einzelne Aufgabe auf, die das LLM in Ihrem Produkt übernimmt. Ein Support-Assistent beantwortet vielleicht Fragen zu Richtlinien, fasst ein Ticket für einen Support-Mitarbeiter zusammen und entwirft eine Antwort, und jede dieser Aufgaben scheitert auf andere Weise. Weisen Sie dann jedem Anwendungsfall eine Risikostufe zu, denn die Stufe bestimmt, wie viel Evaluierungsaufwand er verdient.

Schreiben Sie für jeden Anwendungsfall zwei kurze Listen: was eine gute Antwort leisten muss und was sie niemals tun darf. Diese Listen werden zu Ihren Evaluierungszielen.

Schritt 2: Ein Golden Dataset aufbauen

Ein Golden Dataset ist ein versionierter Satz von Eingaben mit dem erwarteten Verhalten für jede einzelne davon. Es ist das wertvollste Asset im gesamten Framework, denn jede Metrik und jedes Tool, das Sie später hinzufügen, läuft dagegen.

Gute Quellen, grob nach Wert sortiert:

• Anonymisierte Produktionslogs und Support-Tickets, die zeigen, was echte Nutzer tatsächlich fragen
• Von Fachexperten geschriebene Fälle für Situationen, die selten, aber teuer sind
• Adversariale Fälle und Edge Cases: Prompt-Injection-Versuche, Fragen außerhalb des Anwendungsbereichs, mehrdeutige Anfragen, andere Sprachen
• Synthetische Beispiele, die ein LLM zum Schließen von Lücken generiert und die jeweils von einem Menschen geprüft werden, bevor sie in den Datensatz aufgenommen werden

Beginnen Sie mit 50 bis 100 Beispielen pro Anwendungsfall mit hohem Risiko und bauen Sie den Bestand von dort aus. Jeder Eintrag sollte die Eingabe enthalten, gegebenenfalls den abgerufenen Kontext (bei Retrieval-Augmented Generation, kurz RAG), die erwartete Ausgabe oder ein Bewertungsschema sowie Tags wie Intent, Sprache und Schwierigkeitsgrad. Mit diesen Tags können Sie die Ergebnisse später pro Segment auswerten. Legen Sie den Datensatz neben Ihren Prompts in der Versionsverwaltung ab, damit sich jedes Evaluierungsergebnis auf genau die Datensatzversion zurückführen lässt, die es erzeugt hat.

Schritt 3: Metriken auswählen

Ordnen Sie jedem Evaluierungsziel aus dem Schritt zu den Anwendungsfällen eine Metrik zu, die es misst. Die meisten Produkte brauchen drei bis fünf Metriken pro Anwendungsfall, und zwar aus diesen Gruppen:

• Korrektheit und Grounding: Faithfulness, Hallucination Rate (Halluzinationsrate), Answer Relevancy (Antwortrelevanz) und bei RAG zusätzlich Context Precision (Kontextpräzision) und Context Recall (Kontextabdeckung)
• Aufgabenerfolg: Task Completion (Aufgabenerfüllung) und bei Agenten Tool-Call Correctness (Korrektheit der Tool-Aufrufe)
• Sicherheit: Toxizität, Abfluss personenbezogener Daten, korrekte Ablehnungen, Resistenz gegen Prompt Injection
• Format: Schemagültigkeit, Längenbegrenzungen, Vorhandensein der Pflichtfelder
• Betrieb: Latenz und Kosten pro Antwort, erfasst neben der Qualität, damit ein „besserer“ Prompt, der die Kosten verdreifacht, sichtbar wird

Unsere Übersicht der LLM-Evaluierungsmetriken erklärt, wie jede davon berechnet wird und wo jede in die Irre führen kann.

Agenten brauchen eine zusätzliche Ebene. Eine korrekte Endantwort kann einen schlechten Weg dorthin verdecken: zuerst das falsche Tool aufgerufen, eine Retry-Schleife, eine Schreibaktion, die nie hätte laufen dürfen. Bewerten Sie den Lösungsweg (die Trajectory) ebenso wie das Ergebnis; unser Leitfaden zu Metriken für die Evaluierung von KI-Agenten behandelt das Schritt für Schritt.

Wie wir die Metriken für Granola festgelegt haben. Für Granola, ein KI-Notizbuch, das Meeting-Audio und grobe Notizen in strukturierte Zusammenfassungen verwandelt, haben wir die Ausgaben des LLM auf sachliche Richtigkeit und Halluzinationen geprüft und darauf, ob es über komplexe Gespräche mit mehreren Runden hinweg den richtigen Kontext behält. Da sich die generierten Notizen bei jedem Durchlauf unterscheiden, ließen sie sich nicht mit Exact-Match-Checks bewerten. Deshalb haben wir LLMs in unseren Automatisierungsskripten eingesetzt, um die Zusammenfassungen zu verifizieren, unter anderem mit DeepEval, und die Suite in der CI ausgeführt. Das vollständige Setup beschreiben wir in unserer Fallstudie zur Testautomatisierung für Granola.

Schritt 4: Evaluatoren auswählen und Judges kalibrieren

Setzen Sie einen deterministischen Check ein, wo immer es einen gibt. Greifen Sie nur bei Qualitäten, die Code nicht bewerten kann, zu einem LLM-Judge, und behandeln Sie jeden Judge als nicht vertrauenswürdig, bis er an menschlichen Bewertungen kalibriert wurde.

Eine praxistaugliche Kalibrierungsroutine:

1. Nehmen Sie 50 bis 100 Ausgaben aus Ihrem Golden Dataset und lassen Sie zwei Personen sie unabhängig voneinander anhand des Bewertungsschemas labeln.
2. Klären Sie die Fälle, in denen die beiden Personen uneinig sind. Sind sie oft uneinig, ist das Bewertungsschema mehrdeutig, also korrigieren Sie es, bevor Sie ein Modell einbeziehen.
3. Lassen Sie den LLM-Judge dieselben Ausgaben bewerten und messen Sie, wie oft er mit den menschlichen Labels übereinstimmt.
4. Optimieren Sie den Judge-Prompt (klarere Kriterien, ausgearbeitete Beispiele, eine engere Skala), bis die Übereinstimmung für diese Risikostufe akzeptabel ist.
5. Kalibrieren Sie neu, sobald Sie das Judge-Modell, das Bewertungsschema oder die fachliche Domäne des Produkts ändern.

Einige Gewohnheiten machen Judges zuverlässiger. Ein binäres Bestanden/Nicht bestanden oder eine Dreipunktskala lässt sich leichter kalibrieren als ein Score auf einer Zehnpunktskala. Wenn der Judge seine Begründung vor dem Urteil formuliert, werden die Ergebnisse konsistenter. Fixieren Sie die Version des Judge-Modells, damit die Scores über die Zeit vergleichbar bleiben, und verwenden Sie nach Möglichkeit eine andere Modellfamilie als die des bewerteten Modells, da Modelle ihren eigenen Stil tendenziell wohlwollend bewerten. Lassen Sie bei paarweisen Vergleichen jedes Paar in beiden Reihenfolgen laufen, um den Positions-Bias auszugleichen.

Schritt 5: Evaluierungen in die CI einbinden und Gates festlegen

Eine Evaluierung, an deren Ausführung jemand denken muss, wird irgendwann nicht mehr ausgeführt. Bauen Sie sie in die Pipeline ein:

• Bei jedem Pull Request, der einen Prompt, eine Modelleinstellung, die Retrieval-Konfiguration oder eine Tool-Definition berührt, führen Sie eine schnelle Teilmenge des Golden Dataset aus, die in wenigen Minuten durchläuft.
• Jede Nacht oder vor jedem Release führen Sie den vollständigen Datensatz mit allen Metriken aus.

Legen Sie dann fest, was einen Merge blockiert. Harte Gates sind Checks mit null Toleranz: Schemafehler, Sicherheitsfehler, ein Tool-Aufruf mit hohem Risiko ohne Bestätigung. Weiche Gates vergleichen Qualitätsmetriken mit der aktuellen Produktions-Baseline und schlagen fehl, wenn ein Segment um mehr als eine vereinbarte Marge abfällt. Der Vergleich mit einer Baseline funktioniert besser als feste absolute Zielwerte, weil LLM-Ausgaben von Durchlauf zu Durchlauf schwanken. Reduzieren Sie dieses Rauschen, indem Sie die Temperature fixieren, wo das Produkt es zulässt, oder indem Sie jeden Fall mehrmals ausführen und den Durchschnitt bewerten.

Das ist der Kern von LLM-Regressionstests: Jede Änderung wird Segment für Segment an der letzten bekanntermaßen guten Version gemessen.

Planen Sie Budget für die Judge-Aufrufe ein. Ein vollständiger Durchlauf mit 200 Fällen und drei per Judge bewerteten Metriken bedeutet 600 Judge-Aufrufe, eine nächtliche Suite plus die Pull-Request-Läufe summieren sich über einen Monat also. Code-Checks kosten nichts, ein weiterer Grund, sie zuerst einzusetzen.

Schritt 6: Produktion überwachen und Fehler in den Datensatz zurückführen

Die Evaluierung vor dem Release deckt nur die Eingaben ab, an die Sie gedacht haben, also muss das Produktionsmonitoring den Rest auffangen. Tracen Sie jeden LLM-Aufruf (Eingabe, abgerufener Kontext, Tool-Aufrufe, Ausgabe, Latenz, Kosten), lassen Sie Ihre Judges eine Stichprobe des Live-Traffics bewerten und beobachten Sie Nutzersignale wie Daumen-runter-Bewertungen, Eskalationen an einen Menschen und abgebrochene Sitzungen.

Sichten Sie die Fehler einmal pro Woche. Jeder echte Fehler, der ein neues Muster offenbart, wird zu einem neuen Fall im Golden Dataset, sodass das nächste Release automatisch dagegen getestet wird. Diesen Kreislauf kontinuierlich zu betreiben, mit klarer Verantwortung, festem Rhythmus und Drift-Alerts, ist die Praxis, die als EvalOps bekannt ist.

Die besten LLM-Evaluierungsframeworks und Tools

Sobald die sechs Schritte definiert sind, führt ein Tool sie aus. Der Markt teilt sich in Open-Source-Bibliotheken, die Sie selbst betreiben, und verwaltete Plattformen, die Tracing, Dashboards und Review-Queues ergänzen. Viele Teams nutzen am Ende je eines davon: eine Bibliothek für Tests in der CI und eine Plattform für Produktions-Traces.

Wenn Ihr Produkt vor allem eine Retrieval-Pipeline ist, geht unser Vergleich der RAG-Evaluierungstools tiefer auf retrieval-spezifisches Scoring ein als dieser allgemeine Leitfaden.

Das richtige LLM-Evaluierungsframework für Ihr Team wählen

Gehen Sie von drei Rahmenbedingungen aus: Ihrem Stack, Ihrer Teamgröße und der Frage, wohin Ihre Daten übertragen werden dürfen. Der Stack bestimmt, wie viel Integrationsaufwand ein Tool erfordert, denn eine Bibliothek, die zu Ihrer Sprache und Ihrem CI-Runner passt, kann schon nach wenigen Tagen über Pull Requests entscheiden. Die Teamgröße entscheidet, ob sich eine gehostete Plattform rechnet, und die Datenresidenz schließt oft Optionen aus, bevor überhaupt Features verglichen werden.

Nach Teamgröße. Ein oder zwei Engineers fahren am besten mit einer einzigen Open-Source-Bibliothek in der CI und einer Tabelle mit menschlichen Labels; eine Plattform bringt in dieser Phase vor allem zusätzlichen Einrichtungsaufwand. Teams von etwa fünf bis zwanzig Personen ergänzen in der Regel eine Tracing-Plattform, sobald der Produktions-Traffic nennenswert ist, weil sich Stichproben aus dem Live-Traffic von Hand nicht mehr skalieren lassen. Größere oder regulierte Organisationen brauchen rollenbasierte Zugriffe, Audit-Trails und oft Self-Hosting, was sie in Richtung Enterprise-Pläne oder selbst gehostetes Open Source lenkt.

Nach Datenresidenz. Wenn Prompts oder Ausgaben personenbezogene, Finanz- oder Gesundheitsdaten enthalten, klären Sie früh, ob Traces Ihre Infrastruktur verlassen dürfen. Langfuse und Phoenix lassen sich in ihren kostenlosen Versionen selbst hosten; LangSmith, Braintrust und die Plattform Confident AI bieten Self-Hosting nur in Enterprise-Plänen an. Auch Judge-Modelle zählen: Ein LLM-Judge sendet jede bewertete Ausgabe an seinen Anbieter, ein selbst gehostetes Dashboard allein hält die Daten also nicht im eigenen Haus.

Wann Sie keine Plattform brauchen. Wenn Sie ein einziges LLM-Feature, moderaten Traffic und ein Team haben, das ohnehin in der CI arbeitet, deckt eine Bibliothek plus ein Golden Dataset in Git das meiste dessen ab, was eine Plattform leisten würde. Ergänzen Sie eine Plattform, wenn Produktions-Stichproben, Review-Queues oder der Zugang für Nicht-Engineers zu echten Anforderungen werden.

Die Tool-Wahl lässt sich zudem leichter rückgängig machen, als es scheint, vorausgesetzt, Golden Dataset, Bewertungsschemata und Schwellenwerte liegen in einem einfachen Format in Ihrem Repository. Diese lassen sich in jedes Tool übernehmen; Dashboards und gespeicherte Traces in der Regel nicht.

Häufige Fehler bei der LLM-Evaluierung

1. Die Evaluierung nur einmal ausführen. Eine Evaluierung in der Launch-Woche deckt nur die Launch-Version ab, und die nächste Prompt-Änderung, das nächste Modell-Update des Anbieters oder die neuen Dokumente vom letzten Monat in der Wissensdatenbank können das Ergebnis jeweils zunichtemachen. Eine Evaluierung, die nicht in der CI läuft und keine Stichproben aus der Produktion zieht, veraltet innerhalb weniger Wochen.

2. Einem unkalibrierten Judge vertrauen. Ein LLM-Judge liefert selbstsichere, konsistent wirkende Scores, unabhängig davon, ob sie mit dem menschlichen Urteil übereinstimmen. Ohne die Kalibrierungsroutine aus dem Schritt zu den Judges kann ein Team einen Prompt monatelang auf eine Zahl hin optimieren, die nicht widerspiegelt, was Nutzer erleben.

3. Schwache Segmente hinter Durchschnittswerten verschwinden lassen. Angenommen, die Faithfulness liegt insgesamt bei 0,92. Dieser Durchschnitt kann ein spanischsprachiges Segment mit 0,70 enthalten oder ein Segment mit Erstattungsfragen, das in einem von fünf Fällen scheitert. Taggen Sie Ihr Golden Dataset, weisen Sie jede Metrik pro Segment aus und setzen Sie Gates sowohl auf das schwächste Segment als auch auf den Durchschnitt.

4. Keine Feedback-Schleife aus der Produktion. Wenn echte Fehler nie zurück in das Golden Dataset gelangen, entfernt sich der Datensatz allmählich von dem, was Nutzer fragen. Die Testsuite besteht weiterhin, während die Beschwerden zunehmen. Eine wöchentliche Sichtung, die Produktionsfehler in neue Testfälle umwandelt, ist die günstigste Lösung auf dieser Liste.

5. Nur den Happy Path testen. Ein Datensatz aus sauberen, wohlgeformten Fragen übersieht, was LLM-Features in der Praxis zum Scheitern bringt: mehrdeutige Anfragen, Fragen außerhalb des Anwendungsbereichs, Prompt Injection, sehr lange Eingaben und Nutzer, die mitten im Gespräch die Sprache wechseln. Streben Sie an, dass mindestens ein Fünftel jedes Datensatzes mit hohem Risiko aus Edge Cases und adversarialen Fällen besteht.

Wie QAwerk LLM-Evaluierung aufbaut und betreibt

Die meisten Teams kommen in einem von zwei Momenten zu uns: vor dem Launch eines ersten LLM-Features oder nachdem ein Modellwechsel oder eine Prompt-Änderung bereits eine sichtbare Regression verursacht hat. Wir steigen dort ein, wo das Projekt gerade steht. Bei einem bestehenden Produkt ist der erste Schritt meist ein Audit dessen, was das Team bereits misst, gefolgt von einem Golden Dataset, das aus echtem Traffic und den Anwendungsfällen mit hohem Risiko aufgebaut wird.

Von dort aus richten unsere QA-Engineers die sechs oben beschriebenen Teile ein:

• Nach Risiko gestufte Anwendungsfälle und schriftlich festgehaltene Evaluierungsziele, abgestimmt mit Ihrem Product Owner
• Ein versioniertes Golden Dataset mit Segment-Tags und adversarialen Fällen
• Metriken und Evaluatoren, die auf jedes Ziel abgestimmt sind, mit LLM-Judges, die an menschlichen Labels kalibriert sind
• Evaluierungsläufe, die in Ihre CI-Pipeline eingebunden sind, mit harten und weichen Release-Gates
• Produktions-Stichproben und eine wöchentliche Fehlersichtung, die den Datensatz aktuell hält

Die Zusammenarbeit funktioniert als Erweiterung Ihres Teams: Wir arbeiten mit Ihrem Repository, Ihrer CI und den von Ihnen gewählten Tools, sodass nichts migriert werden muss, wenn wir uns zurückziehen. Bei retrieval-lastigen Produkten lässt sich dasselbe Setup auf dediziertes RAG-Testing von Retriever, Chunking und Grounding erweitern.

Wenn Sie ein Evaluierungsframework für sich aufbauen und betreiben lassen möchten, richten unsere QA-Engineers Ihr Golden Dataset, Ihre Metriken, kalibrierten Judges und CI-Gates ein und halten sie aktuell, während sich Ihr Produkt weiterentwickelt. Erzählen Sie uns von Ihrem LLM-Produkt, und wir schlagen Ihnen vor, wo Sie am besten ansetzen.

FAQ

Sehen Sie, wie wir über 1.100 Testfälle für Granola, einen KI-Notizblock, gebaut und gepflegt und 76 % seiner Regressionssuite automatisiert haben

Bitte geben Sie Ihre Geschäfts-E-Mail ein ist keine Geschäfts-E-Mail

Fallstudie Erhalten