Bewertungshilfen für LLM-Apps: Datensätze, Bewertungsmethoden und Regressionsfilter

Das Versenden einer LLM-Funktion ist der einfachere Teil; das Nachweisen, dass sie weiterhin gute Antworten liefert, ist der Punkt, an dem die meisten Teams ins Stocken geraten. Ein Evaluationswerkzeug schließt diese Lücke: Es führt eine feste Reihe von Aufgaben mit einem Modell durch, bewertet jede Antwort und wandelt „es scheint in Ordnung zu sein“ in Zahlen um, die man zwischen verschiedenen Versionen vergleichen kann. Am Ende dieses Leitfadens werden Sie wissen, aus welchen Bestandteilen ein solches Werkzeug besteht, warum die Ausgabe von LLMs es mehr benötigt als gewöhnlicher Code und wie es als Regressionstest in den Release-Prozess integriert wird.

Der Begriff klingt exotisch, aber die Idee ist vertraut. Wenn Sie bereits Unit-Tests geschrieben, einen Datenfluss validiert oder vor dem Aktualisieren eines Dashboards Datenqualitätsprüfungen durchgeführt haben, verstehen Sie bereits den Kern davon.

Die Frage, der sich jede KI-Funktion letztendlich stellen muss

Stellen Sie sich einen internen Assistenten vor, der Geschäftsfragen beantwortet. Ein Interessent fragt, welche Kunden im zweiten Quartal den größten Umsatz eingeführt haben, und die Antwort klingt plausibel. Ein anderer fragt, warum der Umsatz in Deutschland zurückgegangen ist, und auch diese Antwort wirkt überzeugend.

Zwei überzeugende Antworten beweisen jedoch wenig. Was man tatsächlich wissen muss, ist, ob der Assistent bei den Tausenden unterschiedlichen Fragen, die die Menschen jeden Tag eingeben werden – einschließlich der unangenehmen Fragen, an die niemand während der Demo gedacht hat – stets richtig liegt. Eine manuelle Überprüfung ist dafür nicht skalierbar und gibt keinerlei Hinweis darauf, wenn sich etwas leise ändert.

Dies ist die Wand, an der viele KI-Projekte scheitern: Die Entwicklung der Anwendung dauert Wochen, während die Demonstration ihrer zuverlässigen Funktionsweise oft noch länger dauert. Ein Harness ist das Werkzeug, das diese Demonstration systematisch macht.

Was ein Harness tatsächlich bewirkt

Ein Bewertungsframework ist ein System, das einem Modell eine vordefinierte Reihe von Fragen oder Aufgaben zur Verfügung stellt, die Ausgaben sammelt, diese nach festgelegten Regeln bewertet und die Ergebnisse ausgibt. Man kann es sich als automatische Qualitätskontrolle für das Verhalten des Modells vorstellen – oder als Prüfer, der jedem Kandidaten dieselbe Prüfung stellt und auf dieselbe Weise bewertet.

Der Ablauf ist linear: Die Testeingaben gelangen in das Framework, dieses ruft das Modell auf, die Antworten werden bewertet und die Ergebnisse in Noten sowie Berichte umgewandelt:

Test Questions
      │
      ▼
   Harness
      │
      ▼
 AI Model
      │
      ▼
Generated Answers
      │
      ▼
 Evaluation
      │
      ▼
   Scores &
    Reports

Weil jeder Schritt automatisiert ist, kann man die gesamte Prüfung immer wieder durchführen, sobald sich etwas ändert – sei es die Anfrage, die Modellversion, die Abrufkonfiguration oder die Temperatur-Einstellung.

Warum eine standardisierte Prüfung faire Vergleiche ermöglicht

Betrachten Sie, wie ein vernünftiges Team einen Datenanalysten einstellt. Bei drei Kandidaten würde man nicht einfach mit jedem über das Erste, was einem in den Sinn kommt, sprechen und anschließend auf Intuition vertrauen. Man würde allen denselben SQL-Test, denselben Geschäftsfall sowie dasselbe analytische Problem stellen und die Ergebnisse vergleichen.

Auch bei der Auswahl von Modellen funktioniert es genauso. Die Kandidaten werden zu GPT, Claude und Gemini; die Vorstellungsfragen werden zu Geschäftsfragen, Programmieraufgaben, Zusammenfassungsaufgaben und SQL-Generierungsaufgaben. Ein Vergleich ist nur sinnvoll, wenn jedes Modell unter identischen Bedingungen denselben Test absolviert. Andernfalls misst man den Unterschied zwischen den Fragen und nicht zwischen den Modellen.

Warum KI-Modelle dies dringender benötigen als herkömmlicher Code

Die meisten konventionellen Softwarelösungen sind deterministisch. Eine solche Ausdrucksform:

2 + 2

hat genau ein akzeptables Ergebnis:

4

Jeder andere Fall ist ein Fehler, und eine Gleichheitsprüfung reicht als Test aus.

Sprachmodelle funktionieren nicht so. Bitten Sie zwei Modelle, zu erklären, was ein Data Warehouse ist. Eines könnte es als zentrale Speicherstelle für integrierte historische Daten beschreiben; das andere könnte es als System bezeichnen, das Daten aus vielen Quellen zur Analyse zusammenführt. Beides ist richtig, doch die Beschreibungen haben fast nichts miteinander zu tun. Selbst dasselbe Modell kann die Dinge von Lauf zu Lauf unterschiedlich formulieren.

Daher verschiebt sich die Aufgabe von der Überprüfung eines exakten Ausgangswerts auf das Beurteilen der Qualität: Ist die Antwort korrekt, relevant und vollständig – auch wenn ihre Formulierung neu ist? Dieser Wandel ist der grundlegende Unterschied zwischen dem Testen von Software und der Bewertung von KI, und er erklärt, warum es spezielle Testframeworks statt einfacher Assertionsbibliotheken gibt.

Die vier Komponenten eines Testframeworks

Die meisten Harnesses, egal ob selbst entwickelt oder fertig gekauft, bestehen aus denselben vier Komponenten.

Testdatensatz

Der Datensatz ist wie eine Prüfungsfrage: Eine Sammlung von Anfragen, Fragen oder Aufgaben, die darstellen, was das System bewältigen soll. Ein kleines, gemischtes Beispiel:

Write a SQL query to find duplicate customers.

Summarize this article in one paragraph.

Classify this customer support ticket.

Ein Harness kann niemals besser sein als seine Testfälle. Ein nützlicher Datensatz umfasst die häufigen Anfragen, die bekannten schwierigen Fälle sowie die Fehlermuster, die man bereits in der Produktion gesehen hat. Viele Teams halten ihn unter Versionskontrolle und fügen jeden Testfall hinzu, sobald ein Benutzer eine falsche Antwort meldet – genauso wie bei der Behebung eines Fehlers ein Regressionstest erstellt wird. Warum auch die erwarteten Antworten versioniert werden müssen, erfahren Sie unter Dataset-Version-Pinning in LLM-Evaluierungs-Suiten.

Getestetes Modell

Dies ist das System, das untersucht wird: GPT, Claude, Gemini, Llama, Mistral oder Ihre vollständige Anwendung, die auf einem davon basiert. Ein wesentlicher Vorteil des Designs ist, dass das Datensatz einmal erstellt wird und für jedes Modell, das Sie ausprobieren möchten, wiederverwendet werden kann.

In der Praxis umfasst „das Modell“ oft mehr als nur das reine Modell selbst. Es kann sich um das Prompt-Muster, den Abrufschritt sowie die nachgelagerte Verarbeitung zusammen handeln – genau das erleben die Nutzer, weshalb dies in der Regel auch getestet werden sollte.

Bewertungslogik

Sobald eine Antwort vorliegt, muss etwas sie bewerten. Manchmal ist das einfach. Die erwartete Antwort lautet:

Paris

Das Modell gibt zurück:

Paris

und das Urteil lautet:

Pass

Ein solcher exakte oder normalisierte Abgleich funktioniert bei kurzen, faktenbasierten Antworten, Klassifizierungslabels sowie strukturiertem Ausgabeformat. Die meisten echten Anwendungen benötigen jedoch umfangreichere Kriterien, wie zum Beispiel:

• Richtigkeit
• Relevanz
• Vollständigkeit
• Halluzinationrate
• Ton
• Sicherheit
• Treue zum Quellmaterial

Viele dieser Aspekte lassen sich nicht durch String-Vergleiche überprüfen, weshalb moderne Systeme zunehmend ein zweites Modell als Bewertungsinstanz verwenden – ein Ansatz, der als LLM-as-a-Judge bezeichnet wird. Er ist leistungsstark, führt aber auch eigene Fehlerquellen mit sich, wodurch die Bewertungsinstanz anhand menschlicher Labels kalibriert werden muss; ein detaillierter Überblick zur Erstellung einer zuverlässigen Bewertung mit einem solchen Judge findet sich hier.

Berichterstattung

Schließlich werden die einzelnen Bewertungen zu Metriken und Dashboards zusammengefasst. Eine vereinfachte Zusammenfassung könnte wie folgt aussehen:

Model      Accuracy
GPT         92%
Claude      90%
Gemini      87%

Die hier angegebenen Zahlen dienen nur zur Veranschaulichung und stellen keinen Vergleichswert dar. Entscheidend sind vielmehr die Schlussfolgerungen, die ein solcher Bericht ermöglicht:

• Welches Modell eingesetzt werden soll
• Ob eine neue Version der aktuellen überlegen ist
• Ob eine Änderung des Prompts tatsächlich die Ergebnisse verbessert hat
• Ob eine Veröffentlichung für die Produktion sicher ist

Regressionen: das Versagen, das ein Harness abfangen soll

Der stärkste Grund, in einen Harness zu investieren, besteht darin, Regressionen zu verhindern. Angenommen, Ihr Assistent erzielt derzeit folgende Ergebnisse:

Accuracy = 92%

Jemand passt den Prompt an, um freundlichere Antworten zu erhalten. Einige manuelle Überprüfungen deuten auf Probleme hin, doch die Änderung wird dennoch veröffentlicht. Drei Tage später steigen die Support-Anfragen, und als schließlich jemand nachforscht, ist die Genauigkeit auf folgendes Niveau gefallen:

84%

Ohne ein geeignetes Framework sind es zunächst die Kunden, die etwas bemerken. Mit einem solchen Framework wird bei jeder Änderung des Prompts zunächst das gesamte Datensatzensemble überprüft, wobei Fehler als fehlgeschlagene Prüfungen sichtbar werden. Dies entspricht direkt einer Regressionstest-Suite in der herkömmlichen Entwicklung. Prompts, Modellversionen sowie Abrufeinstellungen sollten als Codeänderungen betrachtet werden, die diese Suite bestehen müssen.

Eine praktische Einschränkung: Da die Ausgaben von Large Language Models bei verschiedenen Ausführungen variieren können, stellen kleine Unterschiede in den Bewertungswerten manchmal nur Rauschen dar. Durch mehrfache Ausführung jedes Falls oder durch Festlegung einer Toleranzschwelle vor einer Änderung, die als Regression gilt, wird verhindert, dass der Überprüfungsprozess unkontrolliert reagiert.

Welche Rolle spielt die Bewertung im Lebenszyklus der KI-Entwicklung?

Anfänger gehen oft davon aus, dass die KI-Entwicklung hauptsächlich aus dem Schreiben von Prompts besteht. Produktionsysteme benötigen jedoch einen vollständigen Lebenszyklus, der in einem erfahrenen Team in etwa so aussieht:

Build
   ↓
Test
   ↓
Evaluate
   ↓
Compare
   ↓
Deploy
   ↓
Monitor

Das Tool übernimmt die Phasen des Tests, der Bewertung und des Vergleichs. Wenn man diese überspringt, basieren die Entscheidungen zur Bereitstellung auf Eindrücken statt auf Beweisen. Die Überwachung nach der Veröffentlichung führt neue Fehlerfälle wieder in den Datensatz ein, wodurch der Kreislauf geschlossen bleibt.

Ein funktionierendes Szenario: Ein Assistent für Verkaufsdaten auf Databricks

Um dies aus Sicht der Datenverarbeitung konkret zu machen, stellen Sie sich einen auf Databricks basierenden Assistenten vor, der Fragen zu Verkaufsdaten beantwortet. Die Nutzer stellen beispielsweise Folgendes:

What were total sales in Q1?

Who are our top customers?

Which regions experienced growth last year?

Bevor eine neue Modellversion veröffentlicht wird, sammelt das Team einige hundert repräsentative Fragen. Das Tool führt alle davon automatisch aus und überprüft:

• Die Qualität der generierten SQL-Anfragen
• Die Genauigkeit der Endantworten
• Die Konsistenz bei mehreren Ausführungen
• Die Latenzzeit
• Halluzinationen

Die neue Version wird nur dann gefördert, wenn sie mindestens genauso gut abschneidet wie die derzeit in Produktion befindliche Version. Im Grunde handelt es sich dabei um CI/CD für eine KI-Anwendung: Der Bewertungsvorgang ist ein Schritt im Pipeline-Prozess, und die erzielte Punktzahl dient als Entscheidungskriterium.

Ein Framework, viele Modelle

Kann dasselbe Framework GPT, Claude und Gemini nebeneinander bewerten? Ja, und das Vergleichen von Modellen ist eine der Hauptaufgaben davon. Der Trick besteht darin, die Bewertunglogik unabhängig von einem bestimmten Anbieter zu halten, sodass die Modelle über eine gemeinsame Schnittstelle angeschlossen werden können:

Harness
   ├── GPT
   ├── Claude
   ├── Gemini
   └── Llama

Jedes Modell erhält dieselben Fragen und wird nach denselben Regeln bewertet, was zu einem fairen Vergleich für Ihren spezifischen Anwendungsfall statt zu einer allgemeinen Rangliste führt. Die Ergebnisse beziehen sich außerdem auf Ihre eigenen Daten: Das Modell, das in öffentlichen Benchmarks an die Spitze kommt, ist nicht immer dasjenige, das am besten auf die Fragen Ihres Teams antwortet.

Werkzeuge, auf die Sie wahrscheinlich stoßen werden

Es ist selten notwendig, alles von Grund auf zu entwickeln. Häufig verwendete Optionen sind:

• OpenAI Evals
• DeepEval
• LangSmith
• MLflow Evaluation
• Promptfoo
• RAGAS, das sich auf die Bewertung von RAG-Pipelines konzentriert

Ihre Funktionen und Integrationen unterscheiden sich, und sie ändern sich schnell, daher sollten Sie bei der Auswahl die aktuelle Dokumentation prüfen. Sie teilen ein gemeinsames Ziel: Die Qualität zu messen, bevor Ihre Nutzer es für Sie tun.

Warum Dateningenieure einen Vorsprung haben

Dateningenieure gehen oft davon aus, dass die KI-Entwicklung eine völlig separate Disziplin ist. Die Überschneidung ist größer, als es scheint. Die Jahre, die damit verbracht werden, sicherzustellen, dass schlechte Daten niemals einen Dashboard erreichen (Erwartungen definieren, bei jeder Ladung Überprüfungen durchführen, die Veröffentlichung blockieren, wenn diese fehlschlagen), sind genau die Gewohnheiten, die für die Bewertung von KI-Systemen notwendig sind. Das zu testende Objekt hat sich zwar von einer Tabelle in die Antworten eines Modells verändert, doch die ingenieurwissenschaftliche Disziplin bleibt dieselbe.

Kernpunkte

• Die Wahl des intelligentesten Modells ist weniger wichtig als die Fähigkeit, das Verhalten des Systems zu messen; die Bewertung ist es, was eine Demo von einem Produkt unterscheidet.
• Ein Evaluationsframework besteht aus vier Teilen: einem Testdatensatz, dem zu testenden Modell, der Bewertungslogik und der Berichterstattung. Der Datensatz legt die Grenzen für alles Weitere fest.

Die Ausgabe eines LLM kann nicht allein durch präzise Gleichheitsprüfungen überprüft werden, weshalb die Bewertung in der Regel deterministische Prüfungen mit bewerteten Kriterien kombiniert, manchmal unter Verwendung eines Modells als Urteilsinstanz.

Führen Sie den Harness bei jeder Änderung des Prompts, des Modells oder der Konfiguration aus und blockieren Sie Veröffentlichungen, deren Bewertung unter dem aktuellen Baseline liegt.

Durch die Unabhängigkeit vom Bewertungsdienstleister können Sie Modelle auf Ihren eigenen Daten fair vergleichen.

Eine nützliche Einzeilenzusammenfassung: Ein Harness ist das Unit-Testing-, QA- und Regressionssystem für LLM-Anwendungen. Kein ernstzunehmendes Team veröffentlicht Software ohne Tests, und auch eine LLM-Funktion verdient denselben Umgang, bevor sie in die Produktion gelangt.

Weitere Literatur