Was sind LLM Evals? KI Antworten messen und LLM as a Judge

Was sind LLM Evals?

LLM Evals sind eine systematische Methode, die Antworten einer KI Anwendung mit einem vorab definierten Testdatensatz und klaren Kriterien zu messen. Eval ist die Kurzform von Evaluation, also Bewertung. Das Ziel: Sie zeigen also wiederholbar, dass die Anwendung gut arbeitet, statt es nur zu vermuten.

Zunächst eine einfache Analogie. In einer Restaurantküche probiert der Küchenchef jeden Teller, solange es wenige Bestellungen gibt. Sobald die Bestellungen steigen, reicht das allerdings nicht mehr. Deshalb kommen Rezeptkarten, Verkostungskriterien und Stichproben dazu. Kurz gesagt: Evals sind die Rezeptkarte und die Qualitätskontrolle einer KI Anwendung.

In diesem Leitfaden erklären wir den Begriff Schritt für Schritt. Zunächst geht es um die Frage, warum Evals nötig sind, danach um Testdatensatz und Kriterien. Danach behandeln wir den Ansatz LLM as a Judge und die Verzerrungen eines Bewertungsmodells. Schließlich vergleichen wir Evals mit Benchmarks und geben eine praktische Checkliste. Kurz gesagt: Sie erhalten eine konzeptionelle und praktische Antwort auf die Frage, was sind LLM Evals.

Was sind LLM Evals und wie unterscheiden sie sich von klassischen Softwaretests?

Bei klassischen Softwaretests liefert dieselbe Eingabe immer dieselbe Ausgabe. Geben Sie einer Additionsfunktion zwei und drei, lautet die Antwort fünf, und ein Test prüft das mühelos. Ein Sprachmodell verhält sich dagegen anders, denn es formuliert frei. Es formuliert bei jeder Anfrage etwas anders, und mehrere Varianten können trotzdem richtig sein.

Daher sucht ein Eval nicht nach einer exakten Übereinstimmung. Er prüft, ob die Antwort korrekt ist, zur Quelle passt und den richtigen Ton trifft. Außerdem betrachten Sie nicht eine einzelne Antwort, sondern das gemeinsame Verhalten vieler Beispieleingaben.

Der Unterschied lässt sich auf drei Punkte bringen:

• Die Ausgabe ist wahrscheinlichkeitsbasiert, deshalb lautet die Frage nicht "ist es gleich?", sondern "ist es akzeptabel?".
• Außerdem besteht Erfolg aus mehreren Dimensionen, nicht aus einer einzigen Zahl.
• Der Test läuft nicht nur bei Codeänderungen erneut, sondern auch dann, wenn sich Prompt, Modell oder Daten ändern.

Evals ersetzen also keine Unit Tests, sondern ergänzen sie. Funktionsaufrufe, API Verbindungen und Formatprüfungen testen Sie daher weiterhin klassisch. Die Sprachqualität messen Sie dann mit Evals.

Was ist stille Verschlechterung und warum brauchen Sie Evals?

Stille Verschlechterung bedeutet, dass die Antwortqualität sinkt, ohne dass eine Fehlermeldung erscheint. In der Praxis läuft das System, die Seite lädt, eine Antwort kommt an. Allerdings kann die Antwort vager, länger oder ungenauer sein als zuvor.

Dafür gibt es drei typische Auslöser. Erstens eine kleine Änderung am Prompt. Zum Beispiel kann ein höflicherer Satz eine andere Regel abschwächen. Zweitens ein Modellupdate des Anbieters oder Ihr eigener Wechsel zu einem anderen Modell. Drittens neue Dokumente in Ihrer Wissensbasis.

Konkret: Stellen Sie sich einen Assistenten für Produktbeschreibungen in einem Onlineshop vor. Sie kürzen den Prompt, weil Sie Kosten senken möchten. Der Assistent arbeitet weiter, lässt aber die Rückgabebedingungen gelegentlich weg. Das bemerken Sie nur, wenn Sie vor und nach der Änderung mit denselben Fragen messen.

Evals wirken deshalb weniger wie eine Versicherung und mehr wie ein Kompass. Sie verhindern zwar keine Fehler. Sie zeigen aber früh, dass sich Ihre Richtung verändert hat. Prüfen Sie aktuelle Modelleigenschaften in der offiziellen Dokumentation des Anbieters, denn Verhalten kann sich im Lauf der Zeit ändern.

Was ist ein Testdatensatz (Golden Dataset) und wie bauen Sie ihn auf?

Ein Testdatensatz ist eine Liste von Eingaben, die Ihre Anwendung tatsächlich erhalten wird, jeweils mit einer Beschreibung, wie eine gute Antwort aussieht. In der Praxis spricht man oft von einem Golden Dataset. Das Wort Golden steht dafür, dass diese Beispiele als verlässliche Referenz gelten.

Für einen guten Testdatensatz gehen Sie so vor:

1. Sammeln Sie echte Nutzerfragen. Bereinigen oder anonymisieren Sie Einträge mit personenbezogenen Daten.
2. Gruppieren Sie die Fragen: häufige, schwierige, mehrdeutige und Randfälle.
3. Schreiben Sie zu jeder Frage die erwartete Antwort oder die Eigenschaften, die die Antwort haben muss.
4. Nehmen Sie auch Fragen außerhalb des Themenbereichs auf, denn die Anwendung muss "das weiß ich nicht" sagen können.
5. Legen Sie eine verantwortliche Person fest und prüfen Sie den Datensatz regelmäßig.

Die wichtigste Regel heißt also Vielfalt. Ein Datensatz mit nur leichten Beispielen sieht in jeder Version gut aus und täuscht Sie. Deshalb gehören echte Tippfehler, unvollständige Sätze und irrelevante Fragen hinein.

Den Datensatz können Sie außerdem mit synthetischen Daten erweitern. Prüfen Sie synthetische Beispiele allerdings immer mit menschlichem Blick. Mehr dazu finden Sie in unserem Beitrag zu synthetischen Daten.

Welche Kriterien messen Sie: Genauigkeit, Quellentreue, Ton und Format?

Zunächst gibt es keinen einzigen Qualitätswert. Jede Anwendung gewichtet andere Dimensionen, deshalb definieren Sie die Kriterien zuerst selbst. Auch die offizielle Entwicklerdokumentation von Anthropic betont, dass Erfolgskriterien konkret, messbar und für den Zweck der Anwendung relevant sein sollen.

Die vier häufigsten Kriterien sind:

• Genauigkeit: Ist die Antwort sachlich richtig und beantwortet sie die Frage wirklich?
• Quellentreue: Erfindet die Antwort etwas, das nicht in den bereitgestellten Dokumenten steht? Bei Systemen mit RAG ist dieses Kriterium zentral.
• Ton: Passt die Antwort zur Stimme Ihrer Marke und zur Erwartung des Kunden?
• Format: Hat die Antwort die gewünschte Struktur, etwa Pflichtfelder, eine Längengrenze oder eine Listenform?

Außerdem kommen betriebliche Kriterien wie Konsistenz, Antwortzeit und Kosten. Laut der Dokumentation von Anthropic brauchen die meisten Anwendungen mehrere Kriterien gleichzeitig.

Falsche Informationen sind ein eigenes Thema. Dieses Risiko behandeln wir in unserem Beitrag zur KI Halluzination. Hier nur so viel: Somit ist Quellentreue ist der praktischste Weg, Halluzinationen messbar zu machen.

Wie funktioniert die automatische Bewertung?

Die automatische Bewertung vergibt also Punkte über eine Regel oder ein Programm. Ein Mensch liest nicht jede Antwort, daher lassen sich Hunderte Beispiele in Minuten durchlaufen. Die Eval Dokumentation von OpenAI beschreibt denselben Ansatz mit Datensätzen, Bewertern (Gradern) und Ergebnisanalyse.

Die wichtigsten automatischen Methoden sind:

• Exakter Abgleich: Ist die Antwort eine Kategorie, etwa "positiv" oder "negativ", vergleichen Sie sie mit dem erwarteten Etikett.
• Regelprüfung: Sie prüfen, ob ein Pflichtausdruck vorkommt, ob ein verbotener Ausdruck auftaucht und ob die Längengrenze überschritten ist.
• Semantische Ähnlichkeit: Sie messen mit Embedding Vektoren, ob die Bedeutung der Antwort nahe an einer Referenzantwort liegt.
• Bewertung durch ein Modell: Ein anderes Modell vergibt Punkte auf einer definierten Skala. Diese Methode behandeln wir deshalb in einem eigenen Abschnitt.

Regelbasierte Methoden sind zum Beispiel schnell, günstig und konsistent. Allerdings erfassen sie subjektive Eigenschaften wie Höflichkeit oder Klarheit nicht. Ein gutes Eval Setup kombiniert deshalb einfache Regeln mit der Bewertung durch ein Modell.

Ein wichtiges Prinzip lautet daher: Führen Sie zuerst die günstigste Prüfung aus. Ist das Format kaputt, hat eine Bewertung durch ein Modell wenig Sinn.

Wann ist die menschliche Bewertung unverzichtbar?

Automatische Methoden skalieren zwar, ersetzen das menschliche Urteil aber nicht vollständig. Die menschliche Bewertung ist in drei Situationen unverzichtbar.

Erstens, wenn ein Kriterium neu definiert wird. Hat sich das Team noch nicht geeinigt, was eine "gute" Antwort ist, sollten zunächst Menschen einige Hundert Antworten lesen. Dieser Schritt schärft somit das Kriterium.

Zweitens, wenn Sie das Bewertungsmodell prüfen. Stimmen die Punkte eines Modells nicht mit menschlichen Punkten überein, können Sie ihnen dann nicht trauen. Sie lassen daher eine kleine Stichprobe sowohl von Menschen als auch vom Bewertungsmodell beurteilen und untersuchen die Abweichung.

Drittens bei Ausgaben mit hohem Risiko. Bei rechtlich, finanziell oder sicherheitlich heiklen Antworten sollte deshalb ein Mensch das letzte Wort behalten.

Zudem ist die Auswahl, welche Antworten zur menschlichen Prüfung gehen, eine Designentscheidung. In der Praxis laufen automatische Prüfungen bei jeder Änderung, während die menschliche Durchsicht in Abständen und per Zufallsstichprobe stattfindet. Außerdem sollten Menschen Antworten lesen, die der automatische Wert als "gut" einstufte, über die sich der Kunde aber beschwert hat. Genau diese Antworten sind die wertvollsten neuen Beispiele für Ihren Testdatensatz.

Was ist LLM as a Judge und wie funktioniert es?

LLM as a Judge bezeichnet den Ansatz, dass ein Sprachmodell als Richter die Antwort eines anderen Modells oder einer Anwendung bewertet. Das Verfahren bietet daher eine skalierbare Option, wenn menschliche Bewertung langsam und teuer ist.

Die Logik ist denn auch einfach. Sie geben dem Bewertungsmodell drei Dinge: die Frage, die zu bewertende Antwort und ein klares Bewertungsraster. Danach liefert das Modell einen Punktwert oder eine Kategorie, oft mit einer kurzen Begründung.

Es gibt drei gängige Einsatzformen:

• Einzelbewertung: Die Antwort erhält einen Wert auf einer Skala, zum Beispiel von eins bis fünf.
• Ja Nein Einstufung: Die Antwort wird als "erfüllt die Regel" oder "erfüllt die Regel nicht" markiert.
• Paarweiser Vergleich: Der Richter wählt, welche von zwei Antworten besser ist.

Die Arbeit von Zheng und Kollegen zu LLM as a Judge mit MT Bench und Chatbot Arena (arXiv) zählt zu den Kernquellen, die diesen Ansatz systematisch untersuchen. Laut Zusammenfassung können starke Bewertungsmodelle in hohem Maß mit menschlichen Präferenzen übereinstimmen. Dieselbe Zusammenfassung nennt allerdings auch Verzerrungen und begrenzte Fähigkeiten beim Schlussfolgern. Genau darum geht es im übernächsten Abschnitt.

Wie schreiben Sie ein Bewertungsraster für das Bewertungsmodell?

Die Qualität des Bewertungsmodells hängt stark vom Raster ab. Dagegen liefert eine vage Anweisung wie "bewerte die Antwort" bei jedem Durchlauf andere Punkte. Beschreiben Sie stattdessen in schlichten Sätzen, was als gut gilt.

Ein gutes Raster enthält diese Teile:

• Aufgabenbeschreibung: Sagen Sie in einem Satz, was das Modell bewertet.
• Kriterienbeschreibung: Für Quellentreue schreiben Sie zum Beispiel "jede Aussage der Antwort muss im bereitgestellten Dokument stehen".
• Skalendefinition: Erklären Sie mit kurzen Beispielen, was jeder Punktwert bedeutet.
• Begründung anfordern: Erst eine kurze Begründung, dann der Punktwert: Das erhöht die Konsistenz.
• Ausgabeformat: Legen Sie fest, wie der Wert zurückkommt, damit ein Programm ihn lesen kann.

Danach testen Sie das Raster an einer kleinen Beispielmenge. Lesen Sie die Punkte selbst und tragen Sie jede Abweichung von Ihrer Erwartung ins Raster zurück. Somit wird das Raster wie Code zu einem versionierten, verbesserbaren Bestandteil Ihrer Arbeit.

Welche Verzerrungen hat ein Bewertungsmodell?

Ein Bewertungsmodell ist kein neutrales Messgerät. Die Arbeit von Zheng und Kollegen nennt in ihrer Zusammenfassung drei zentrale Verzerrungen: Positionsverzerrung, Längenverzerrung und Selbstbevorzugung. Außerdem erwähnt sie begrenzte Fähigkeiten beim Schlussfolgern als Einschränkung.

Jede einfach erklärt:

• Positionsverzerrung: Zeigen Sie zwei Antworten nebeneinander, bevorzugt der Richter womöglich die Antwort an einer bestimmten Stelle, ohne den Inhalt abzuwägen.
• Längenverzerrung: Der Richter bewertet eine längere, ausführlicher wirkende Antwort eventuell höher, auch wenn sie nicht besser ist.
• Selbstbevorzugung: Ein Bewertungsmodell kann Antworten höher einstufen, die seinen eigenen Ausgaben ähneln.
• Begrenztes Schlussfolgern: Antworten, die Mathematik oder mehrstufige Logik erfordern, kann auch der Richter falsch beurteilen.

Diese Verzerrungen machen den Ansatz allerdings nicht ungültig. Sie zeigen aber, dass Sie die Punkte nicht als absolute Wahrheit lesen dürfen. Anders gesagt: Ein Richterwert ist ein Signal, kein Urteil.

Die Gedanken aus unserem Beitrag zu KI Bias gelten auch hier. Denn der Richter ist ebenfalls ein Modell und trägt Neigungen aus seinen Trainingsdaten.

Wie verringern Sie die Verzerrungen des Bewertungsmodells?

Verzerrung lässt sich nicht vollständig beseitigen, aber ihre Wirkung können Sie verkleinern. Die folgenden Schritte sind die wichtigsten Maßnahmen, die in der Praxis helfen.

1. Tauschen Sie beim paarweisen Vergleich die Reihenfolge der Antworten und bewerten Sie zweimal. Ändert sich das Ergebnis mit der Reihenfolge, dann gilt das Beispiel als unsicher.
2. Schreiben Sie ins Raster, dass Länge kein Grund für mehr Punkte ist. Ergänzen Sie eine Regel wie "eine kürzere, korrekte Antwort schlägt eine lange, zerstreute".
3. Nutzen Sie als Richter ein anderes Modell als das, das die Antwort erzeugt hat. Auch die Dokumentation von Anthropic empfiehlt, zur Bewertung ein anderes Modell zu wählen als im Produktivbetrieb.
4. Außerdem: Halten Sie die Skala schmal. Klare Kategorien wie bestanden und nicht bestanden sind konsistenter als feine Abstufungen.
5. Lassen Sie den Richter zuerst eine kurze Begründung schreiben und erst danach den Wert vergeben.
6. Lassen Sie regelmäßig eine kleine Stichprobe von Menschen bewerten und vergleichen Sie sie mit dem Richter.

Der sechste Schritt ist der wichtigste, weil er den Richter an einer unabhängigen Referenz prüft. Setzen Sie einen Richter, dessen Werte von menschlichen Werten abweichen, erst nach einer Überarbeitung des Rasters ein.

Wie funktionieren Regressionstests mit Evals?

Ein Regressionstest prüft, ob eine Änderung etwas kaputt gemacht hat, das vorher funktionierte. Bei Evals gilt daher dieselbe Logik. Gemessen wird allerdings die Sprachqualität.

In der Praxis sieht der Ablauf so aus. Zunächst lassen Sie die aktuelle Version auf dem Testdatensatz laufen und halten das Ergebnis als Referenz fest. Danach ändern Sie Prompt, Modell oder Wissensbasis. Anschließend führen Sie denselben Datensatz erneut aus und legen die Ergebnisse nebeneinander.

Beim Vergleich achten Sie auf diese Fragen:

• Welches Kriterium ist gesunken, welches gestiegen?
• Konzentriert sich der Rückgang auf eine bestimmte Fragengruppe?
• Haben die Fehler bei einzelnen Beispielen ein gemeinsames Muster?

Außerdem kann eine Änderung ein Kriterium verbessern und ein anderes verschlechtern. Der Ton wird zum Beispiel wärmer, dafür sinkt die Quellentreue. Dieses Gleichgewicht sehen Sie also nur durch Messen.

Wenn Sie eine Schwelle festlegen, einigen Sie sich zuerst im Team auf das "niedrigste akzeptable Niveau". Legen Sie aktuelle Schwellenwerte nach Ihrer eigenen Risikobereitschaft fest, denn eine allgemeingültige Zahl gibt es nicht. Ob Unterschiede zwischen zwei Varianten aussagekräftig sind, können Sie mit unserem A/B Test Rechner als gedankliche Stütze einordnen.

Was sind LLM Evals und sind sie dasselbe wie Benchmarks?

Nein, das ist nicht dasselbe, denn der Umfang unterscheidet sich. Ein Benchmark ist eine öffentliche, standardisierte Testsammlung, mit der Modelle bei allgemeinen Fähigkeiten verglichen werden. LLM Evals messen dagegen zum Beispiel Ihre eigene Anwendung mit Ihren Daten und Ihren Kriterien.

Ein Benchmark gleicht einer allgemeinen Führerscheinprüfung. Evals dagegen sind die interne Schulung, die misst, wie sicher dieser Fahrer Ihre Lieferstrecke in Ihrer Stadt meistert. Der Führerschein ist ein guter Anfang, bedeutet aber nicht, dass der Fahrer die Strecke kennt.

Drei Kernunterschiede:

• Umfang: Ein Benchmark misst allgemeine Aufgaben, ein Eval misst Ihre Aufgabe.
• Besitz: Ein Benchmark ist öffentlich, Ihr Evalsatz gehört Ihnen und kann vertraulich bleiben.
• Zweck: Ein Benchmark informiert die Modellwahl, ein Eval verfolgt die Qualität Ihrer Anwendung über die Zeit.

Benchmark Ergebnisse können deshalb bei der Modellwahl ein nützlicher erster Filter sein. Allerdings veralten sie schnell und bilden Ihren Anwendungsfall womöglich nicht ab. Prüfen Sie aktuelle Ergebnisse auf der offiziellen Seite des Anbieters, treffen Sie die endgültige Entscheidung aber mit Ihrem eigenen Evalsatz.

Wie unterscheiden sich Evals von ähnlichen Begriffen?

Das Feld wächst schnell, deshalb werden verwandte Begriffe verwechselt. Die folgende Tabelle hilft Ihnen, Evals von Nachbarbegriffen abzugrenzen.

Zu Red Teaming lesen Sie unseren Beitrag zu AI Red Teaming, zu Guardrails unseren Beitrag zu KI Guardrails. Beide arbeiten daher als eigene Schichten neben einem Eval Aufbau.

Wie unterscheiden sich Evals bei RAG und bei Agenten?

Bei einem einfachen Chat Assistenten messen Sie zunächst nur die Antwort. In einem System mit RAG gibt es dagegen zwei getrennte Stufen: das passende Dokument finden und daraus eine Antwort schreiben. Deshalb bewerten Sie beide Stufen einzeln. Ist die Suche schlecht, kann also selbst das beste Sprachmodell nicht gut antworten. RAG selbst haben wir in unserem Beitrag zu RAG erklärt.

Zwei typische Fragen für RAG lauten:

• Sind die gefundenen Textstellen wirklich relevant für die Frage?
• Nutzt die erzeugte Antwort ausschließlich die Informationen aus diesen Textstellen?

Bei Agenten messen Sie nicht eine Antwort, sondern eine Folge von Entscheidungen. Welches Werkzeug der Agent wählt, ob er es mit den richtigen Parametern aufruft und ob er die Aufgabe in einer sinnvollen Zahl von Schritten beendet, sind eigene Kriterien. Ihr Testdatensatz kann daher neben Fragen und Antworten auch die erwartete Schrittfolge enthalten.

In beiden Fällen bleibt das Prinzip dennoch gleich. Messen Sie zuerst die Bausteine einzeln, danach das Gesamtverhalten. So erkennen Sie bei einem Fehler schnell, ob das Problem in der Suche, im Kontext oder in der Formulierung der Antwort liegt.

Wie arbeiten Offline und Online Bewertung zusammen?

Offline Bewertung heißt, vor dem Livegang mit einem fertigen Testdatensatz zu messen. Online Bewertung heißt, echten Nutzerverkehr stichprobenartig mit denselben Kriterien zu bewerten. Beide konkurrieren also nicht, sondern ergänzen sich.

Zunächst ist die Offline Messung schnell und sicher. Eine Prompt Änderung testen Sie, bevor sie Nutzer erreicht. Allerdings bildet kein Testdatensatz die Wirklichkeit perfekt ab. Stichproben aus dem Live Betrieb zeigen Fragetypen, die Sie nicht erwartet haben.

Ein praktischer Kreislauf sieht so aus:

1. Prüfen Sie die Änderung mit dem Offline Datensatz.
2. Rollen Sie die Änderung schrittweise aus.
3. Ziehen Sie Zufallsstichproben aus dem Live Verkehr und bewerten Sie sie mit denselben Kriterien.
4. Sehen Sie sich schlecht bewertete Antworten und Antworten mit Nutzerbeschwerden an.
5. Nehmen Sie die interessanten Fälle in den Offline Datensatz auf.

Dieser Kreislauf macht somit Ihren Testdatensatz jede Woche ein Stück realistischer. Verarbeiten Sie bei der Online Stichprobe Nutzerdaten, beachten Sie die Datenschutzregeln und maskieren Sie die Daten bei Bedarf.

Beispielszenario: Wie bewerten Sie einen Kundensupport Assistenten?

Dies ist ein Beispielszenario und kein echtes Kundenergebnis. Angenommen, ein Onlineshop hat einen Assistenten, der Fragen zu Rückgabe und Versand beantwortet. Der Assistent schreibt seine Antworten auf Basis der Richtliniendokumente des Shops.

Zunächst bauen Sie den Testdatensatz. Sie entnehmen Fragen aus echten Supportanfragen und entfernen personenbezogene Daten. Danach ordnen Sie zu jeder Frage den passenden Abschnitt des Richtliniendokuments als Referenz zu. Außerdem nehmen Sie Fragen außerhalb des Themas auf, etwa zum Wetter oder zur Richtlinie einer anderen Marke.

Dann wählen Sie die Kriterien:

• Quellentreue: Nutzt die Antwort nur Informationen aus dem Richtliniendokument?
• Genauigkeit: Stimmen Rückgabefrist und Bedingungen mit dem Dokument überein?
• Ton: Schreibt der Assistent respektvoll und klar an den Kunden?
• Format: Gibt er Schritte bei Bedarf als nummerierte Liste aus?

Anschließend übergeben Sie prüfbare Regeln (Format, Pflichtausdrücke) an Code und subjektive Kriterien (Ton, Quellentreue) an ein Bewertungsmodell. Dann lassen Sie bei jeder neuen Prompt Version den Datensatz erneut laufen. Sehen Sie einen Rückgang, prüfen Sie, welche Fragengruppe betroffen ist. So wird aus der Debatte "ich finde, es ist besser geworden" eine Entscheidung auf Basis von Messwerten.

Welche Einstellungen beeinflussen die Eval Ergebnisse?

Lassen Sie denselben Prompt zweimal laufen, können zwei verschiedene Antworten entstehen. Der Hauptgrund sind die Zufallseinstellungen, die das Modell beim Erzeugen nutzt. Beim Lesen von Eval Ergebnissen sollten Sie diese Einstellungen daher konstant halten.

Steigt die Temperatur, werden die Antworten vielfältiger. Für einen Eval heißt das konkret: Dasselbe Beispiel kann in einem Durchlauf bestehen und im nächsten durchfallen. In unserem Beitrag zu Temperature und Top p erklären wir diese Einstellungen ausführlich.

Praktische Empfehlungen:

• Fixieren und protokollieren Sie die Einstellungen bei jedem Eval Lauf.
• Führen Sie bei Aufgaben, bei denen Vielfalt zählt, jedes Beispiel mehrfach aus und betrachten Sie die Streuung der Ergebnisse.
• Speichern Sie Prompt, Modellname und Einstellungen zusammen mit dem Ergebnis. So können Sie ein altes Ergebnis nachvollziehen.

Auch das, was Sie in den Kontext legen, verändert das Ergebnis. Das haben wir in unserem Beitrag zu Context Engineering behandelt. Ein Eval macht außerdem den Aufbau des Kontexts messbar.

Welche Fehler stören den Eval Prozess am häufigsten?

Eval Setups scheitern jedoch meist an Gewohnheiten, nicht an Technik. Die häufigsten Probleme aus der Praxis sehen so aus.

• Nur auf einen Durchschnittswert schauen. Ein Durchschnitt kann einen deutlichen Einbruch in einer Fragengruppe verdecken. Schneiden Sie die Ergebnisse nach Gruppen auf.
• Den Datensatz ohne Verantwortlichen lassen. Pflegt ihn niemand, veraltet er und entfernt sich von der realen Nutzung.
• Das Bewertungsraster nie testen. Ein unscharfes Raster liefert uneinheitliche Werte.
• Ergebnisse nicht festhalten. Wissen Sie nicht, welcher Prompt welchen Wert erreichte, können Sie nicht rückwirkend vergleichen.
• Die Zahl der Kriterien aufblähen. Zu viele Kriterien machen aus Signal Rauschen. Drei bis fünf gut gewählte Kriterien genügen oft.

Alle diese Fehler lösen Sie deshalb durch Prozess. Behandeln Sie den Datensatz wie ein Produkt: Er braucht eine verantwortliche Person, Versionen und regelmäßige Durchsicht.

Welche Risiken und Grenzen haben Evals?

Evals sind ein starkes Werkzeug, haben aber trotzdem Grenzen. Wer sie kennt, vermeidet trügerische Sicherheit.

Die wichtigsten Grenzen:

• Der Testdatensatz kann einseitig sein. Er enthält nur Fragen, die Sie schon gesehen haben, und kann neue Arten übersehen, die morgen eintreffen.
• Außerdem ist Überanpassung ein Risiko. Nutzen Sie immer denselben Datensatz und stimmen den Prompt darauf ab, wirkt die Anwendung auf dem Datensatz gut und im echten Leben mittelmäßig. Halten Sie deshalb einen getrennten Prüfdatensatz zurück.
• Richterwerte sind unvollkommen. Wie die Abschnitte zu Verzerrungen zeigen, brauchen die Werte menschliche Prüfung.
• Kosten und Zeit summieren sich. Große Datensätze bei jeder Änderung mit einem Bewertungsmodell auszuführen, kostet Geld. Nutzen Sie einen schnellen Kerndatensatz und einen größeren, der nur regelmäßig läuft.
• Ein falsches Kriterium liefert ein falsches Ergebnis. Ein schlecht definiertes Kriterium perfekt zu optimieren heißt, das falsche Ziel zu treffen.

Evals bieten keine Garantie. Sie zeigen nicht, dass Fehler fehlen, sondern dass bekannte Risiken unter Kontrolle sind. Nehmen Sie Einträge mit personenbezogenen Daten in einen Testdatensatz auf, beachten Sie das Datenschutzrecht. Dieser Beitrag ersetzt keine Rechtsberatung.

Was sind LLM Evals für kleine Unternehmen und wie sieht eine praktische Checkliste aus?

Für ein kleines Team lautet die Antwort auf die Frage, was sind LLM Evals, nicht: eine perfekte Plattform bauen. Es geht darum, eine kleine, regelmäßige Gewohnheit zu starten. Die folgende Liste gibt einen Rahmen.

1. Formulieren Sie den Zweck der Anwendung in einem Satz und halten Sie die Erfolgskriterien bei drei bis fünf Punkten.
2. Bauen Sie aus echten Eingaben einen Kerndatensatz und ergänzen Sie Randfälle sowie Fragen außerhalb des Themas.
3. Wählen Sie für jedes Kriterium die Bewertungsmethode: Regel, semantische Ähnlichkeit, Bewertungsmodell oder Mensch.
4. Nutzen Sie ein Bewertungsmodell, schreiben Sie das Raster, testen Sie es mit vertauschter Reihenfolge und prüfen Sie es mit einer menschlichen Stichprobe.
5. Speichern Sie Prompt, Modell und Einstellungen als Version.
6. Führen Sie den Datensatz vor und nach jeder Änderung aus und vergleichen Sie die Ergebnisse.
7. Nehmen Sie fehlerhafte Live Antworten wieder in den Datensatz auf.
8. Legen Sie fest, wie oft Datensatz und Kriterien überprüft werden.

Haben Sie diese Liste einmal eingerichtet, verliert der Wechsel zu neuen Modellen seinen Schrecken. Denn die Frage "taugt das neue Modell für unsere Arbeit?" beantworten Sie mit Messung statt mit Meinung. Prüfen Sie aktuelle Modelleigenschaften und Bedingungen in der offiziellen Dokumentation des Anbieters.

Wie kann unser Team Sie bei diesem Prozess unterstützen?

Wir von Talha Aslan und Team legen Wert darauf, KI Anwendungen nicht nur zu bauen, sondern auch zu messen. Die Qualität eines produktiven Assistenten bleibt nicht auf dem Stand des Starttags. Sie verändert sich mit jeder Änderung an Prompt und Modell.

Unser Team unterstützt Sie beim Entwurf eines Testdatensatzes für Ihr Unternehmen, bei der Festlegung von Kriterien und bei der Anbindung der Bewertungsroutine an Ihre bestehenden Abläufe. Arbeiten wir mit Ihren echten Daten, klären wir Datenschutz und Datengrenzen von Anfang an. Wir versprechen keine Ergebnisse. Unser Ziel ist ein messbarer, wiederholbarer und nachvollziehbarer Prozess.

Möchten Sie den Umfang Ihres KI Projekts klären, schauen Sie auf unsere Seite zur KI Beratung. Als Quellen empfehlen wir den Eval Leitfaden von OpenAI, die Dokumentation von Anthropic zum Entwickeln von Tests und die Arbeit zu Bewertungsmodellen von Zheng und Kollegen.

Zum Schluss: Dieser Beitrag dient der allgemeinen Information. Modelleigenschaften und Oberflächen von Werkzeugen können sich ändern, prüfen Sie deshalb vor der Umsetzung die offiziellen Dokumente. Für die Seite des Prompt Designs lesen Sie auch unseren Beitrag zu Prompt Engineering.