LLM-Anwendungen testen: Evals, Testdaten und Regressionen

LLM-Anwendungen testen funktioniert anders als klassische Softwaretests: Dieselbe Eingabe kann unterschiedliche, aber gleichermaßen richtige Antworten liefern. Statt exakter Vergleiche braucht es Testdatensätze, Prüfregeln und Bewertungsraster. Wer das früh aufbaut, kann Prompts und Modelle ändern, ohne im Blindflug zu sein.

Warum Tests unverzichtbar sind

Eine kleine Änderung am Systemprompt, ein Modellwechsel oder ein neues Dokument im Index kann Antworten an Stellen verschlechtern, an die niemand gedacht hat. Ohne Tests merken das erst die Nutzer. Mit Tests sehen Sie vor dem Ausrollen, ob die neue Version besser oder schlechter ist.

Schritt 1: Testdatensatz anlegen

• Echte Fälle sammeln: typische Anfragen aus Gesprächsprotokollen oder von Fachleuten.
• Grenzfälle ergänzen: unklare Fragen, Fragen außerhalb des Themas, Versuche, Regeln zu umgehen.
• Erwartung festhalten: eine Musterantwort, Pflichtinhalte oder die richtige Quelle.
• Klein anfangen: 30 bis 50 gute Fälle sind wertvoller als 1.000 ungeprüfte.

Schritt 2: Passende Prüfungen wählen

• Regelbasiert: Ist die Antwort gültiges JSON? Enthält sie die Pflichtfelder? Bleibt sie unter der Längengrenze? Kommt ein verbotener Begriff vor? Diese Prüfungen sind billig und eindeutig.
• Vergleich mit Referenz: Bei Klassifizierung oder Extraktion lässt sich die Antwort direkt mit dem erwarteten Wert vergleichen.
• Modell als Richter: Ein zweites Modell bewertet die Antwort anhand eines Bewertungsrasters, etwa „Beantwortet die Frage vollständig“, „Keine Aussagen ohne Quelle“. Das eignet sich für freie Texte.
• Menschliche Stichproben: regelmäßig, um auch den Richter zu überprüfen.

Ein Bewertungsraster mit klaren Kriterien und Punkten entwirft der Bewertungsraster-Generator.

Tipps für das Modell als Richter

1. Konkrete Kriterien statt „Ist die Antwort gut?“.
2. Pro Kriterium ja oder nein abfragen statt einer Note von 1 bis 10.
3. Den Richter zuerst begründen lassen, dann urteilen.
4. Bei einigen Fällen prüfen, ob Richter und Mensch übereinstimmen.

Ein Beispiel für einen Testfall in einem Support-Bot: Frage „Kann ich nach 40 Tagen noch zurückgeben?“, Pflichtinhalt „Rückgabefrist 30 Tage“, verbotener Inhalt „Ausnahme zusagen“, erwartete Quelle „Rückgabebedingungen“. Solche Fälle lassen sich teils regelbasiert, teils per Bewertungsmodell prüfen.

Schritt 3: Bei jeder Änderung laufen lassen

Binden Sie die Tests in den Entwicklungsablauf ein: Vor jedem Ausrollen einer neuen Prompt-Version oder eines anderen Modells läuft der Testdatensatz durch, und die Ergebnisse werden mit der vorherigen Version verglichen. Weil Antworten schwanken, lohnt es sich, wichtige Fälle mehrfach laufen zu lassen. Wie Sie Prompt-Versionen nachvollziehbar verwalten, beschreibt Prompt-Versionierung; Grundlagen zu Evals stehen unter Evals für Prompts.

Kosten der Tests

Jeder Testlauf kostet Tokens, beim Modell als Richter sogar doppelt. Bei 50 Fällen ist das meist überschaubar. Für große Testsätze eignen sich Batch-Schnittstellen mit Rabatt. Zwei Prompt-Varianten nebeneinander vergleichen können Sie schnell mit dem Prompt-Vergleich.

Was nach dem Start kommt

Tests vor dem Ausrollen ersetzen nicht die Beobachtung im Betrieb. Echte Nutzer stellen Fragen, an die niemand gedacht hat. Protokollieren Sie Anfragen und Bewertungen und übernehmen Sie auffällige Fälle in den Testdatensatz. Wie das geht, erklärt LLM-Observability und Logging.