Evaluationswerkzeuge für GenAI: Ein Praxisleitfaden für Entwickler und Tester
Einen funktionsfähigen Prototypen für eine GenAI‑App zusammenzuklicken, ist heute leichter denn je: In den letzten Monaten schossen OpenAI‑API‑Wrapper-Projekte, LlamaIndex‑ und LangChain‑Quickstarts wie Pilze aus dem Boden [1]. Ob LLM‑gestützte Datenextraktion, Summarizer oder Chatbot – ein erstes Demo wirkt oft nach wenigen Tagen beeindruckend. Doch hier beginnt die eigentliche Arbeit, denn die Achillesferse der Sprachmodelle heißt Zuverlässigkeit: Von zehn Antworten eines Chatbots sind fünf gut, drei passabel und zwei schlicht falsch. Genau wie jede andere Software müssen GenAI‑Applikationen das erwartete Verhalten garantieren – und dafür braucht es mehr als herkömmliche Testmethoden.
Diese stoßen bei generativen Modellen schnell an ihre Grenzen. Ein großes Sprachmodell (LLM) wählt seine Wörter jedes Mal neu, daher können zwei identische Anfragen leicht unterschiedliche Antworten erzeugen. Einen festen "Soll-Wert", gegen den man prüfen könnte, gibt es in der Regel nicht.
Hinzu kommt, dass wir das Innenleben proprietärer Modelle nicht sehen, sie bleiben eine Black Box. Wenn etwas schiefgeht, bleibt uns nur ein Blick auf die Eingabe – den Prompt – und die Ausgabe, statt detaillierter Fehlermeldungen oder Schritt-für-Schritt-Debugging wie in normalem Code.
Häufig wird deshalb damit argumentiert, wie gut einzelne Modelle in generellen Vergleichstests abschneiden. Aber eine Genauigkeit von 88 Prozent im MMLU-Benchmark sagt wenig darüber aus, wie überzeugend das Modell in unserer eigenen Fachdomäne argumentiert [2].
Warum Testen nicht gleich Evaluieren ist
In der klassischen Softwareentwicklung überprüfen Tests, ob ein Stück Code bei genau definierten Eingaben exakt die erwartete Ausgabe liefert. Das Ziel lautet deterministische Funktionskorrektheit, bei der wir fragen: "Funktioniert es?"
In der ML‑Forschung sprechen wir dagegen von Evaluation: Ein Modell wird über viele Beispiele hinweg gegen einen Gold‑Standard (Ground Truth) vermessen; hier lautet die Frage: "Wie gut wird das Problem gelöst?"
Tabelle 1 verdeutlicht die Trennlinie zwischen den Disziplinen. Tests liefern ein binäres Ergebnis (bestanden/ nicht bestanden). Evaluation bündelt Leistungskennzahlen über einen Datensatz und zeichnet so ein graduelles Bild, das Trends sichtbar macht und Reruns vergleichbar hält.
Tabelle 1: Ein Vergleich zwischen Testen von Software und dem Evaluieren von Machine-Learning-(ML-)Anwendungen.
| Disziplin | Zweck | Typische Methoden |
| Testen | Korrekte Funktion und Integration der Software‑Komponenten | Unit‑, Integrations‑, End‑to‑End‑Tests |
| Evaluieren | Objektive Qualitätsmessung des ML‑Modells anhand von vordefinierten Metriken | Quantitativ: F1, Accuracy, MSE |
Wie bereits skizziert, wirken bei GenAI‑Systemen drei Faktoren zusammen, die klassische Tests allein überfordern: probabilistische Antworten ohne deterministisches Ergebnis, fehlende Einblicke in die Black Box interner Gewichte sowie eine fehlende Bewertung der Ausrichtung auf die vorliegende Fachdomäne. Eine systematische Evaluation dient deshalb als ergänzendes Sicherheitsnetz – sie quantifiziert die Antwortstreuung, deckt Hidden Failure Modes auf und weist anhand reproduzierbarer Metriken nach, ob die Lösung tatsächlich den Fachanforderungen genügt. Kurz: Tests und Evaluation sind Pflicht.
Generalisierte Benchmarks reichen nicht
"Mein Modell schafft 88 Prozent auf MMLU – also perfekt für den Unternehmens‑Chatbot!" Diese Aussage ist leider allzu oft falsch. Eine hohe Punktzahl in einem akademischen Benchmark wie MMLU, HellaSwag oder TruthfulQA sagt wenig über Ihr konkretes Geschäftsproblem aus [3].
Was misst MMLU-Benchmark eigentlich?
MMLU-Benchmark – das Massive-Multitask-Language-Understanding‑Benchmark – ist im Kern ein umfangreicher Multiple‑Choice‑Test. Die Autoren haben aus öffentlichen Quellen wie US-High-School‑Lehrplänen, Universitätsklausuren und professionellen Zertifizierungsprüfungen 57 Fachgebiete zusammengestellt, von Astrophysik bis Virologie. Zu jedem Gebiet existieren rund zweihundert Aufgaben, insgesamt etwa 12.000 Fragen [2].
Jede Aufgabe besteht aus einem kurzen Prompt, gefolgt von genau vier Antwortmöglichkeiten (A bis D). Ein LLM muss lediglich den Buchstaben der seiner Ansicht nach richtigen Lösung ausgeben. Ein Beispiel ist in Tabelle 2 zu sehen. Das Modell soll also nur den Buchstaben A ausgeben.
Tabelle 2: Eine Multiple-Choice-Frage, wie sie im Datensatz des MMLU-Benchmark zum Evaluieren von Large Language Models (LLM) vorkommt.
| Welches Enzym katalysiert die endgültige Spaltung von Laktose? | |||
| A) β‑Galactosidase | B) Lactat‑Dehydrogenase | C) Amylase | D) Cellulase |
Damit behandelt MMLU das Sprachmodell wie einen Vier‑Klassen‑Klassifikator. Die Gesamtleistung wird mit Accuracy angegeben: "Wie viel Prozent der Antworten sind exakt richtig?"
Weitere Metriken aus dem klassischen Machine Learning (ML) sind Precision, Recall und F1‑Score. Sie stammen aus der mehrklassigen Klassifikation und werden aus den Zählwerten True Positives (TP), False Positives (FP) und False Negatives (FN) berechnet:
Angenommen, eine Multiple-Choice-Aufgabe lässt mehrere richtige Antworten zu, z. B. die Optionen A und B sind richtig, aber C und D sind falsch. Wenn das Modell A und C auswählt, sind TP = 1 (A), FP = 1 (C) und FN = 1 (B). Daraus ergeben sich Precision = 0,5, Recall = 0,5 und F1 = 0,5.
Solche Metriken sind nützlich, wenn Mehrfachantworten erlaubt sind oder wenn die Klassen sehr unausgewogen sind. Beim MMLU-Benchmark hingegen ist nur eine Option richtig. Dadurch reduzieren sich Precision, Recall und F1 auf die gleiche Aussage wie Accuracy – der Buchstabe ist entweder richtig oder falsch.
Das Problem mit Benchmarks wie MMLU in GenAI-Anwendungen
Bei einem genaueren Blick auf das Bewertungssystem des MMLU wird klar: Der Grund, warum die KI eine bestimmte Antwort ausgewählt hat, spielt im Benchmark keine Rolle. Wichtig ist nur, dass der Buchstabe stimmt.
Daraus ergeben sich zwei grundlegende Einschränkungen, wenn wir die Ergebnisse des MMLU auf reale Anwendungen übertragen wollen. Erstens misst der Benchmark das reine Faktengedächtnis in diskreter Form. Eine GenAI-Anwendung sollte jedoch in den meisten Fällen Freitext erzeugen, der präzise, vollständig und logisch konsistent ist.
Zweitens betrachtet MMLU die einzelne Frage isoliert, während produktive GenAI-Pipelines eine Kette von Schritten umfassen. Ein Beispiel ist Retrieval Augmented Generation (RAG), eine Architektur, die es einem Chatbot ermöglicht, Fragen zu einer fachlichen Dokumentensammlung zu beantworten. Abb. 1 zeigt stark vereinfacht eine RAG, wie wir sie auch in der Praxis einsetzen.
Jeder Prozessschritt dieses Ablaufs ist fehlerbehaftet und kann die Gesamtqualität gefährden, z. B. wenn das Retrieval irrelevante Textpassagen liefert oder die Qualitätsprüfung Halluzinationen nicht stabil erkennt. Ein Benchmark, der nur den LLM-Kern, d. h. die Antwortgenerierung betrachtet (wie MMLU), ignoriert diese Wechselwirkungen. Wie wir später sehen werden, müssen spezifische Anforderungen der Pipeline bei der Evaluierung berücksichtigt werden.
Fazit: Eine Accuracy von 88 Prozent für MMLU zeigt, dass ein Modell in der Lage ist, breit gestreutes Allgemeinwissen auf Multiple-Choice-Niveau zu reproduzieren. Sie sagt aber nichts darüber aus, ob dasselbe Modell einen Fachartikel präzise zusammenfasst, strukturierte Informationen extrahiert oder in einem Dialog konsistent bleibt.
Evaluation ist vom Use Case abhängig
Die Kernfrage der Evaluation ist: "Wie gut wird das Problem gelöst?" Wie wir es messen, hängt jedoch vom Anwendungsfall ab. Anders als klassische Unit‑Tests, die nur "funktioniert / funktioniert nicht" beantworten, liefern Evaluationsmetriken ein Gradientenbild der Modellqualität. Dieses Bild variiert je nach Problemkategorie massiv. Eine Erkennung von Fitnessübungen misst sich an Precision und Recall, eine Preisprognose an der mittleren quadratischen Abweichung, ein Text‑Generator an semantischer Genauigkeit.
Je nach Problemstellung wird üblicherweise zwischen Kategorien wie Klassifikation, Regression, Zeitreihenanalyse oder Clustering unterschieden. Entsprechend der Kategorie ist in der Regel ein wohldefinierter Satz von Metriken geeignet. Bei der Klassifikation haben wir dies bereits mit Precision, Recall und F1 gesehen, bei der Regression sind es häufig statistische Metriken wie RMSE, MAE oder R² [4].
GenAI-Applikationen fallen in den Bereich des Natural Language Processing (NLP). Die Messung der Korrektheit von Sprache ist seit den Anfängen dieser Disziplin ein echtes Problem. Metriken wie Jaro-Winkler, Levenshtein, ROUGE oder BLEU haben sich zwar über die Jahre etabliert, berücksichtigen aber – wie wir noch sehen werden – keine semantischen Eigenschaften [5]. Moderne Ansätze wie LLM-as-Judge versuchen hier Abhilfe zu schaffen.
Im Folgenden haben wir zwei konkrete Beispiele aus unserem Projektalltag mitgebracht, anhand derer wir diese Metriken diskutieren und Best Practices austauschen wollen.
Datenextraktion aus Transportaufträgen (Beispiel 1) [6]
Täglich gehen bis zu 1.000 Transportanfragen bei Speditions- und Logistikdienstleistern ein – als lose E-Mails, eingescannte PDFs, Smartphone-Fotos oder XLS-Anhänge. Die Informationen sind selten vollständig, oft mehrsprachig und fast nie in einer bestimmten Reihenfolge. Unsere Aufgabe war es, diese unstrukturierten Dokumente in ein JSON-Schema zu überführen, um eine möglichst schnelle Weiterverarbeitung zu ermöglichen (s. Abb. 2).
Während klassische Extraktionspipelines auf regelbasierte Verarbeitung setzen, haben wir einen LLM-basierten Ansatz gewählt. Vereinfacht gesagt führen wir zunächst eine Texterkennung mittels OCR auf den Dokumenten durch und übergeben dann den erzeugten Textkorpus an das LLM, welches daraus das strukturierte JSON erzeugen soll.
Das Modell muss zunächst relevante Passagen erkennen (z. B. die Abmessungen eines Palettenstapels in einer Fußnote) und gleichzeitig fehlende Felder ergänzen – etwa das Gewicht, wenn es nur als "3t Gesamtladung" am Seitenrand auftaucht. Hinzu kommt die Medienvielfalt: OCR-Artefakte aus Fax-Scans, Bildrauschen in Handyfotos und in E-Mails kopierte Tabellen. Abb. 2 (links) zeigt als Beispiel einen Screenshot einer Excel-Tabelle, die als Bild in die E-Mail eingebettet ist.
Dieses Vorgehen birgt einige Fallstricke. Erstens neigen LLMs dazu, Felder zu halluzinieren, wenn sie ein Attribut nicht eindeutig finden können; ein fehlendes Gewicht wird mit plausibel klingenden Zahlen aufgefüllt. Zweitens ändert sich das E-Mail-Layout ständig – eine neue ERP-Version des Kunden ändert die Spaltennamen, wodurch feste Prompts überflüssig werden. Hersteller wie OpenAI oder Google versuchen hier mit sogenannten Structured Output APIs (recht erfolgreich) gegenzusteuern [9]. Drittens wirken sich OCR-Fehler exponentiell aus: Ein falsch erkanntes Dezimaltrennzeichen kann dazu führen, dass alle folgenden Felder inkonsistent sind, obwohl das Modell für jedes einzelne Feld einen "high confidence"-Wert meldet.
Evaluation von strukturierten Daten
Diese technischen Details sind zwar interessant, aber den Kunden interessiert meist nur eines: "Wie genau ist die Extraktion?". Anhand der Antwort kann der Kunde das Automatisierungspotenzial abschätzen.
Um diese Frage zu beantworten, messen wir pro Datenfeld einen binären Treffer (korrekt/ inkorrekt) und aggregieren anschließend über alle Felder der Stichprobe. Die Stichprobe entnehmen wir einem Testdatensatz, der häufig als "Ground Truth" bezeichnet wird. Dieser enthält realistische Transportaufträge mit der korrekt zu erwartenden strukturierten Ausgabe, erzeugt von einem Menschen. Streng genommen ist die Accuracy somit der Anteil korrekt extrahierter Werte.
Liefert das Modell jedoch mehr oder weniger Werte, als tatsächlich existieren, zum Beispiel, wenn es ein Feld halluziniert oder ein optionales Attribut leer lässt, entstehen sogenannte False Positives (zu viel) beziehungsweise False Negatives (zu wenig). Um diese beiden Fehlerquellen gemeinsam zu bewerten, kann der bereits vorgestellte F1-Score herangezogen werden.
Ein "korrekter" Wert ist jedoch je nach Datentyp unterschiedlich definiert. Für numerische Felder setzen wir einen Toleranzbereich von ± 1 Prozent auf den Wert der Ground Truth. Für klar definierte Codes (Incoterms, ISO-Länderkürzel) muss es ein exakter Match sein; bei Freitextfeldern wie Straßennamen erlauben wir einen kleinen Levenshtein-Abstand, um variable Schreibweisen zu tolerieren (etwa Straße vs. Strasse). Diese Per Field Scorings ermöglichen eine granulare Evaluation. In Abb. 3 zeigen wir beispielhaft ein Schema zur Berechnung des Scorings pro Feld.
Um eine Aussage über die Accuracy zu treffen, wird jedes Feld einzeln gegen den Ground-Truth-Datensatz geprüft. Das liefert pro Feld einer Stichprobe ein Tupel (passed: bool, reason: str), sodass wir nicht nur Treffer zählen, sondern auch sofort erkennen können, warum ein Vergleich fehlgeschlagen ist (z. B. "levenshtein > 2" oder "exact match failed"). Unsere Lösung erreicht auf diesem Benchmark eine Accuracy von 90 Prozent auf einem Testdatensatz von 100 Transportaufträgen und 150 Rechnungsbelegen, wobei aus jeder Datei bis zu 60 unterschiedliche Datenfelder zu extrahieren sind. Das ist mehr als ausreichend, um die Arbeit des Fachpersonals erheblich zu unterstützen.
Dieses Beispiel zeigt somit exemplarisch, dass sich GenAI-Applikationen bei klar definierten Schemata mit klassischen Werkzeugen des Machine Learning testen lassen. Abgesehen von wenigen Freitextfeldern gibt es kaum Variabilität, sodass Fehler eindeutig zähl- und behebbar sind. Metriken wie Accuracy und F1-Score liefern in diesem Setting harte, reproduzierbare Qualitätskennzahlen.
Assistent zum Abrufen von internem Wissen (Beispiel 2)
RAG-Chatbots sind wahrscheinlich das am häufigsten genannte Beispiel für GenAI-Anwendungen – sie ermöglichen es einer Organisation, interne Dokumente und Prozesse über ein Sprachmodell zugänglich zu machen. Nutzer können per E-Mail oder Chat-Interface beliebige Fragen stellen, welche das LLM anhand von thematisch passenden Textauszügen beantworten kann. In unserem konkreten Anwendungsfall bestand die Dokumentenbasis aus den gesammelten Compliance-Richtlinien und -Vorgaben eines großen Unternehmens, und die Nutzeranfragen bezogen sich zumeist auf konkrete Situationen im Geschäftsalltag (s. Abb. 4).
Die Verarbeitung einer Nutzeranfrage erfolgt vereinfacht in zwei Schritten. Zunächst wird die Dokumentenbasis nach Textabschnitten durchsucht, die dem Text der Anfrage ähnlich sind (sog. Retrieval). Dies kann mit verschiedenen algorithmischen Methoden geschehen – am beliebtesten sind Ähnlichkeitsvergleiche anhand von Text-Embeddings (semantic similarity), dynamische Schlagwortsuche (bm25) und hybride Ansätze, die beides kombinieren. Die so gefundenen Textabschnitte, auch Chunks, werden im zweiten Schritt in das Prompt des Sprachmodells eingefügt, welches eine Antwort formuliert (Generation).
Wie zu erwarten ist, gibt es bei beiden Schritten eine Vielzahl von Fehlerfällen, von denen jeder einzelne schlussendlich zu einer fachlich oder semantisch falschen Antwort führen kann. Im Gegensatz zu unserem ersten Beispiel besitzt das Output-Format hier keine wohldefinierte Struktur, sondern besteht aus beliebigem Freitext. Für die Definition einer "korrekten" oder "guten" Antwort sind oft sowohl Fachwissen als auch Wissen um die Präferenzen des Nutzers erforderlich. Zur Illustration hier ein paar Fehlerfälle, die uns im Betrieb begegnet sind:
- *Das Retrieval liefert falsche Chunks, welche keine Antwort auf die Frage enthalten, obwohl es bessere Chunks gegeben hätte.
- Das Retrieval liefert richtige Chunks, aber das LLM ignoriert oder fehlinterpretiert diese.
- Das LLM zitiert korrekte Informationen aus den Chunks, die jedoch die Frage nicht beantworten.
- Das LLM gibt eine korrekte Antwort auf die Frage, liefert aber zusätzlich auch eine Reihe irrelevanter Informationen.
- Das LLM gibt eine oberflächlich korrekte Antwort, die aber zu simpel ist oder weiterer Erklärungen bedarf.
- Es gibt in der Dokumentenbasis überhaupt keine Antwort auf die Nutzerfrage, aber das LLM halluziniert eine Antwort.
Die Nuancen der natürlichen Sprache im Kontext einer automatisierten Evaluation abzubilden, ist ein laufendes Forschungsproblem.
Gleichzeitig müssen wir aber genau diese Qualität für ein RAG‑System messbar machen: Wie gut beantwortet die Pipeline eine Frage und wo liegen ihre typischen Fehlermuster? Dazu brauchen wir eine Evaluationsschicht, die auf semantischer Ebene arbeitet – sie vergleicht nicht bloß Tokens, sondern den tatsächlichen Inhalt zweier beliebiger Strings beliebiger Länge. Nur so lassen sich die oben beschriebenen Fehlerfälle zuverlässig sichtbar machen und Fortschritte quantitativ belegen.
Evaluation von natürlicher Sprache – Recall-Oriented Understudy for Gisting Evaluation (ROUGE)
Eine klassische Metrik, um mehr als nur eine reine String-Gleichheit zu prüfen, ist Recall-Oriented Understudy for Gisting Evaluation (ROUGE)[5]. Sie misst die Überlappung von n‑Grammen zwischen Referenz- und Systemausgabe. Abhängig von der Variante werden einzelne Wörter (ROUGE‑1), Wortpaare (ROUGE‑2), die längste gemeinsame Teilsequenz (ROUGE‑L) oder gewichtete Wortmengen (ROUGE‑W) verglichen. Meist berichtet man den Recall, da er bestraft, wenn Schlüsselbegriffe fehlen; optional lassen sich aber auch Precision oder ein F‑Score analog zu Abschnitt 2 angeben.
Zum besseren Verständnis mal ein einfaches Beispiel für ROUGE-1:
"Die Katze schläft auf der warmen Decke." – Referenz/ Ground Truth
"Die Katze ruht auf der Decke." – Systemausgabe/ Generierter Text
Die gemeinsamen fünf Unigramme sind {Die, Katze, auf, der, Decke}. Precision und Recall lassen sich nun mit
angeben. Im Recall fehlen sowohl das Wort "warmen" als auch das für "ruht" vorhandene Synonym "schläft". ROUGE wertet daher eine semantisch korrekte Paraphrase ab, weil es allein exakte Übereinstimmungen berücksichtigt. Trotzdem eignet sich ROUGE als schneller und quantifizierbarer Smoke‑Test und bildet die Basis vieler Benchmarks.
Evaluation von natürlicher Sprache – Embedding Similarity
Ein Embedding lässt sich als Funktion
formulieren, die Wörter, Sätze oder ganze Dokumente als n-dimensionale Vektoren abbildet, sodass inhaltlich verwandte Texte im Raum dicht beieinander liegen [8]. Die semantische Nähe zweier Texte wird in der Praxis herkömmlicherweise über die Cosinus-Similarity
gemessen. Ihr Wertebereich ist normiert auf [-1, 1], wobei 1 maximale Ähnlichkeit (identische Richtung), 0 keine Korrelation (orthogonal) und -1 die maximale Dissimilarität (entgegengesetzte Vektoren) beschreibt.
Das Retrieval eines RAG-Systems nutzt genau dieses Prinzip, um die bestmöglich passenden Chunks zu identifizieren. In der Praxis funktioniert das oft hervorragend, jedoch auch nicht immer. Mal ein einfaches Beispiel unter Verwendung des Embedding-Modells multilingual-e5-large-instruct:
"Die Übergabe eines Buddybären an eine externe Person ist hinsichtlich der Compliance nicht vertretbar." – Referenz/ Ground Truth
Tabelle 3: Beispiel unter Verwendung des Embedding-Modells
| Systemausgabe/ Generierter Text | Cosinus-Similarity |
| 1. "Die Übergabe eines Buddybären an eine externe Person ist hinsichtlich der Compliance vertretbar." | 0,992 |
| 2. "Die Übergabe eines Buddybären als Geschenk ist nach den Richtlinien nicht gestattet." | 0,780 |
Die zweite Ausgabe ist eine paraphrasierte und gekürzte Version der Referenz. Sie ist inhaltlich korrekt und enthält einen Score von 0,780.
Die erste Ausgabe hat den fast identischen Wortlaut, jedoch wird die Negation durch das "nicht" übersehen. Die Antwort wird mit einem Score von 0,992 als nahezu identisch interpretiert, obwohl die Aussage diametral entgegensetzt ist.
Was bei der Verwendung von Embedding-Modellen auch häufig vergessen wird, ist, dass die tatsächliche Skalierung stark von der Architektur des Modells und seinem Training abhängt. Ursachen können die Art des Trainings (z. B. Kontrastive Klassifikation gegen Retrieve and Rank), der Datensatz (z. B. Englisch gegen multilingual) oder die Normierung (im Training gegen während der Inferenz) sein. Konkret bedeutet das, dass beispielsweise ein Modell wie text-embedding-3-large Similarity-Werte zwischen 0,2 und 0,95 erreicht, während ein Modell wie multilingual-e5-large-instruct mit einem ähnlichen Beispielsatz bereits > 0,98 erreicht.
Aus der obigen Diskussion können wir drei zentrale Grenzen von Embeddings ableiten:
- Semantik ≠ Faktentreue: Der Kosinuswert bewertet die geometrische Nähe, nicht die logische Korrektheit. Ein fehlendes "nicht" wird häufig ignoriert, weil alle übrigen Token exakt übereinstimmen.
- Modell-Abhängigkeit: Andere Embedding-Modelle können dieselben Sätze deutlich anders skalieren. Deshalb sind Rohscores nur im Kontext desselben Modells und Datensatzes sinnvoll vergleichbar [9].
- Keine Schwellenwerte: ("< 0,7 ist falsch / ≥ 0,9 ist richtig") funktionieren nur innerhalb desselben Modells und desselben Datentyps, weil genau dann die Winkelverteilung stabil bleibt.
Der praktische Nutzen von Embedding-Modellen ist natürlich nicht von der Hand zu weisen. Das Verfahren ist robust gegenüber Synonymen, Wortreihenfolgen und Tippfehlern. Mehrsprachigkeit, kurze und lange Textpassagen sowie viele generelle Aufgabenstellungen können abgebildet werden. Leider eignet sich die Cosinus-Similarity nur bedingt als belastbare Evaluationsmetrik, weshalb sie (mal wieder) als Smoke-Test mit relativen Entscheidungsstrategien eingesetzt wird, z. B. "Top-K-Retrieval nimmt immer die drei bestbewerteten Chunks" oder "Flagge alles, was > (µ + 2 σ) eines Batch Scores liegt".
Evaluation von natürlicher Sprache – LLM-as-a-judge
Da in realen Projekten selbst ambitionierte Teams kaum mehr als einige Dutzend valide Frage-Antwort-Paare zusammentragen können, verlieren klassische Kennzahlen wie ROUGE rasch an Aussagekraft. Anstelle einer kaum vorhandenen Ground Truth setzt man daher vermehrt auf das domänenübergreifende Vorwissen eines sogenannten LLM-"Judge". Die vom Retrieval gefundenen Chunks und die daraufhin generierte Antwort werden einem zweiten Sprachmodell vorgelegt, welches das RAG-Ergebnis anhand verschiedener Metriken beurteilt. So lässt sich ohne großen Annotierungsaufwand prüfen, ob die bereitgestellten Passagen tatsächlich relevant sind und die Antwort fachlich korrekt, konsistent und vollständig ausfällt – eine Vorgehensweise, die sich als LLM-as-a-judge etabliert hat und für die sich inzwischen gängige Metriken etablieren:
- Contextual Precision: Werden die relevantesten Chunks zur Beantwortung der Frage zuverlässig im Retrieval gefunden?
- Contextual Recall: Welcher Anteil aller potenziell relevanten Chunks wird im Retrieval gefunden?
- Faithfulness: Stimmt die generierte Antwort mit den Informationen aus den gefundenen Chunks überein?
- Answer Relevancy: Passt die generierte Antwort zur Nutzeranfrage?
Im Gegensatz zu den fest definierten Metriken im klassischen ML gibt es für diese Bewertungskriterien keinen Konsens über konkrete Berechnungsformeln. GenAI-Evaluationsframeworks wie RAGAS und DeepEval versuchen mit verschiedenen Methoden, weiche Konzepte wie "Relevanz" in harten Zahlen auszudrücken – etwa indem sie die generierte Antwort mittels LLM in eine Reihe von (hoffentlich) distinkten "Statements" unterteilen, welche anschließend einzeln auf Korrektheit geprüft werden [10]. Danach wird der Anteil der für die Nutzerfrage "relevanten" Statements als numerische Kennzahl zurückgegeben:
Das RAGAS-Framework berechnet dieselbe Metrik mit einem komplett anderen Ansatz. Hier werden zuerst von der Antwort des Modells ausgehend eine Reihe hypothetischer Nutzerfragen (Egi) generiert – es wird quasi geraten, was der Nutzer gefragt haben könnte. Die durchschnittliche Embedding Similarity dieser generierten Fragen zur tatsächlichen Nutzerfrage (E0) ergibt dann die Answer Relevancy:
Die auf diese Weise ermittelten Werte sind nur von begrenzter Aussagekraft. Sie sollten eher als grobe Richtwerte für die Qualität der RAG-Pipeline betrachtet werden und nicht als verlässliche Performance-Kennzahlen. Die Vergleichbarkeit zweier Evaluationsergebnisse ist nur gegeben, wenn sie mit derselben Berechnungsmethode und demselben Judge-LLM bestimmt wurden. Zur Veranschaulichung haben wir für einen Testdatensatz aus 25 realen User-Fragen und LLM-generierten Antworten die Answer Relevancy Scores der beiden Frameworks gegenübergestellt (Abb. 5).
Unser kleines Experiment zeigt deutlich, dass die Ergebnisse der beiden Frameworks nur sehr schwach korreliert sind – wenn überhaupt. Und es offenbart noch ein weiteres Problem: Die errechneten Scores sind über mehrere Läufe hinweg nicht stabil (Fehlerbalken, n=10). Anders ausgedrückt: Dieselbe Antwort kann vom LLM-as-a-judge-Mechanismus verschiedene Scores erhalten, wenn die Metrik mehrmals berechnet wird. Ist diese Streuung groß genug (wie im Falle von DeepEval in unserem Experiment), so verliert die Evaluation jede Aussagekraft.
Trotz aller Einschränkungen ist LLM-as-a-judge derzeit die einzige Bewertungsmethode, die komplexe fachliche Zusammenhänge zumindest ansatzweise erfassen und subtile semantische Fehler aufdecken kann. Auch wenn der aktuelle Stand dieser Tools wenig Vertrauen erweckt, bleibt zu hoffen, dass wir in den kommenden Jahren erhebliche Fortschritte bei Standardisierung und Robustheit sehen werden.
Einen interessanten Ansatz schlägt Prometheus ein: ein speziell auf die Bewertung LLM-generierter Texte trainiertes Sprachmodell [11]. Solche maßgeschneiderten Evaluatoren könnten die heute üblichen, oft instabilen Prompt-Ketten ablösen. In Benchmarks erzielt Prometheus – trotz seiner kompakten 13 Milliarden Parameter – eine Pearson-Korrelation von rund 0,897 mit menschlichen Urteilen. Das liegt auf Augenhöhe mit GPT-4 (0,882) und klar über den von GPT-3.5 erreichten 0,392.
Künstliche Intelligenz auf den diesjährigen IT-Tagen
Spannende Vorträge und Workshops zum Thema Künstliche Intelligenz erwarten Euch auch auf den IT-Tagen, der Jahreskonferenz von Informatik Aktuell. Die IT-Konferenz findet jedes Jahr im Dezember in Frankfurt statt – dieses Jahr vom 08.-11.12.
Fazit
Wie bewertet man die Qualität einer GenAI-Anwendung? Die unbefriedigende Antwort ist wie so oft: "Es kommt darauf an." Ist der Output der App stark strukturiert und wenig variabel, sind strikte programmatische Kriterien die beste Wahl. Für einzelne Wörter und kurze Sätze kommen klassische NLP-Metriken infrage; bei langen Freitexten mit komplexem Inhalt bleibt nur noch LLM-as-a-judge, und auch das ist auf dem aktuellen Entwicklungsstand eher als Behelfslösung zu werten. Gerade bei komplexen, domänenspezifischen Fragestellungen zeigt sich, dass letztlich nur fachkundige Menschen die Antwortqualität wirklich zuverlässig beurteilen sollten. Es geht dabei nicht nur um formale Ähnlichkeit zu einer Musterlösung, sondern um inhaltliche Plausibilität und Korrektheit im gegebenen Kontext.
Eines jedoch ist sicher: Solange LLMs noch Fehler machen, wird das Evaluationsproblem uns weiter begleiten. Und es sieht nicht so aus, als würde sich daran in nächster Zeit etwas ändern. Die beste Praxis besteht daher darin, menschliche Evaluation zumindest punktuell einzusetzen, um automatische Bewertungsmethoden zu kalibrieren und deren Ergebnisse zu validieren.
- LlamaIndex
LangChain - D. Hendrycks, C. Burns, S. Basart, A. Zou, M. Mazeika, D. Song und J. Steinhardt: Measuring massive multitask language understanding, in International Conference on Learning Representations, 2020.
- K. Zhou, Y. Zhu, Z. Chen, W. Chen, W. X. Zhao, X. Chen, Y. Lin, J.-R. Wen und J. Han: Don't make your LLM an evaluation benchmark cheater, arXiv preprint arXiv:2311.01964, 2023.
- C. M. Bishop und N. M. Nasrabadi, Pattern recognition and machine learning, Springer, 2006.
- C.-Y. Lin: Rouge: A package for automatic evaluation of summaries, Text summarization branches out, 2004.
K. Papineni, S. Roukos, T. Ward und W.-J. Zhu: Bleu: a method for automatic evaluation of machine translation, in Proceedings of the 40th annual meeting of the Association for Computational Linguistics, 2002. - cronn GmbH: SaaS-Lösung für präzise und skalierbare Datenextraktion
- OpenAI: Introducing Structured Outputs in the API
- K. W. Church: Word2Vec, Natural Language Engineering, 2017.
- H. Steck, C. Ekanadham und N. Kallus: Is cosine-similarity of embeddings really about similarity?, in Companion Proceedings of the ACM Web Conference 2024, 2024.
- ragas - Supercharge Your LLM Application Evaluations
DeepEval - The LLM Evaluation Framework - S. Kim, J. Shin, Y. Cho, J. Jang, S. Longpre, H. Lee, S. Yun, S. Shin, S. Kim und J. Thorne: Prometheus: Inducing fine-grained evaluation capability in language models, in The Twelfth International Conference on Learning Representations, 2023.
