BlogTesten
Regressionstests für LLM-Anwendungen: Was bei Prompt- und Modellwechseln laufen muss
Behandeln Sie jede Änderung an Prompt, Modellversion, Retrieval-Index, Tool oder Einstellung beim Anbieter als Release, auch wenn sich kein Anwendungscode geändert hat. Halten Sie ein eingefrorenes Set von Fällen, die das System schon gut beherrscht, erwarten Sie dort Werte nahe 100 % und stoppen Sie das Release bei jedem neuen Fehler in einem kritischen Kriterium. Lassen Sie zuerst die deterministischen Prüfungen laufen, dann die validierten Judges, und vergleichen Sie alte und neue Version Fall für Fall statt über Durchschnitte. Fälle, die Fortschritt bei schwierigen Problemen messen, gehören in ein eigenes Set, damit ein niedriger Wert dort nicht jedes Release blockiert.
Was als Änderung zählt
In gewöhnlicher Software folgt ein Regressionslauf auf eine Codeänderung. In einer LLM-Anwendung ändert sich das Verhalten auch, wenn jemand einen Prompt in einer Konfigurationsdatei bearbeitet, Dokumente neu indexiert oder eine Einstellung anpasst, und wenn ein Anbieter das Modell hinter einem Alias aktualisiert. Stellen Sie all das unter Versionskontrolle oder halten Sie es zumindest in einem Änderungsprotokoll fest, und lösen Sie die Suite bei jeder dieser Änderungen aus.
- Änderungen an Prompt und System-Prompt, auch solche außerhalb des Code-Repositorys
- Ein neues Modell oder eine neue Modellversion und Alias-Updates beim Anbieter
- Neue oder geänderte Dokumente im Retrieval-Index und Änderungen an Chunking oder Embeddings
- Neue Tools und geänderte Tool-Beschreibungen oder Berechtigungen
- Einstellungen wie Temperatur, maximale Ausgabelänge oder die Zahl der abgerufenen Chunks
Was in die Regressionssuite gehört
Das Engineering-Team von Anthropic unterscheidet Capability Evals, die Fortschritt bei Aufgaben messen, die das System noch nicht gut kann, von Regression Evals, die eine Erfolgsquote von nahezu 100 % haben sollten. Für eine Regressionssuite heißt das: Fälle, die die aktuelle Version beherrscht, die jeden gesehenen und behobenen Fehlertyp abdecken, dazu die kritischen Kriterien aus der Abnahme. Wird ein Fehler behoben, kommt sein Fall in die Suite, damit der Fehler nicht unbemerkt zurückkehrt.
Ordnen Sie die Prüfungen nach Kosten. Deterministische Prüfungen laufen zuerst und brechen beim ersten Fehler ab: Schemas, Pflichtfelder, Tool-Argumente, Zitate, die auf existierende Dokumente zeigen, Ablehnungen bei Anfragen außerhalb des Zwecks. Danach kommen die LLM-Judges, jeder an den Bewertungen einer Fachperson validiert, für die Kriterien, die ein Urteil brauchen. Halten Sie die Suite klein genug, um sie bei jeder Änderung laufen zu lassen. Hamel Husain und Shreya Shankar beschreiben Sets für die CI als klein und gezielt zusammengestellt, in vielen Fällen 100 Beispiele oder mehr.
Versionen Fall für Fall vergleichen
Lassen Sie alte und neue Version auf denselben Fällen laufen, im Vokabular des ISTQB-Lehrplans CT-AI ein Back-to-Back-Test, und sehen Sie sich die Fälle an, die gekippt sind. Ein neuer Prompt kann den Durchschnitt heben und trotzdem fünf Fälle kaputt machen, die vorher funktionierten, und genau diese fünf bemerkt vielleicht ein Kunde. Weisen Sie drei Zahlen aus: neu fehlschlagende Fälle, neu bestandene Fälle und die Nettoveränderung.
Ob eine Nettoveränderung echt ist, zeigt nur ein gepaarter Test, kein Vergleich zweier Durchschnitte. Unser Leitfaden zur Stichprobengröße bei Evals zeigt die Methode an einem Beispiel: Bei 100 Fällen liegen 8 behobene und 5 neu kaputte Fälle noch im Rauschen.
Wann ein Release gestoppt wird
- Jeder neue Fehler in einem kritischen Kriterium stoppt das Release, egal was der Durchschnitt macht.
- Eine deterministische Prüfung, die neu fehlschlägt, stoppt das Release, weil sie einen Bug zeigt.
- Bei statistischen Kriterien stoppen Sie, wenn die Erfolgsquote klar unter die Anforderung aus der Abnahme fällt, also auch die obere Grenze ihres Intervalls darunter liegt, und prüfen von Hand, wenn es knapp ist oder Fälle in beide Richtungen gekippt sind.
- Ein Judge, der sich geändert hat, mit neuem Modell oder neuem Prompt, wird erneut an den Labels der Fachperson validiert, bevor seine Zahlen zählen.
Modellwechsel verdienen einen zweiten Schritt. Bevor Sie den Betrieb auf ein neues Modell umstellen, lassen Sie es im Schattenbetrieb auf einer Stichprobe echter Anfragen laufen, mit protokollierten, aber nicht angezeigten Antworten, und vergleichen Sie diese mit der aktuellen Version. Schattenläufe finden die Fragen, die Ihr Testset noch nicht enthält.
Die Suite schnell und bezahlbar halten
Eine Suite mit 300 Fällen, je drei Läufen und zwei Judges pro Lauf bedeutet 900 Antworten und 1800 Judge-Aufrufe pro Änderung. Lassen Sie die volle Suite bei Modell- und Prompt-Wechseln laufen und ein kleineres Smoke-Set bei kleinen Anpassungen, nutzen Sie gespeicherte Antworten der unveränderten Version als Vergleichsbasis und stellen Sie einen Judge erst auf ein günstigeres Modell um, wenn Sie dieses Modell an den Labels der Fachperson validiert haben.
Fragen
Wie testen wir auf Regression, wenn Antworten nie identisch sind?
Vergleichen Sie nicht den Text. Vergleichen Sie, ob jeder Fall seine Prüfungen noch besteht, die deterministischen und die bewerteten. Eine andere Formulierung, die weiter besteht, ist keine Regression.
Sollten wir die Modellversion festschreiben?
Ja, wo der Anbieter es erlaubt. Nutzen Sie im Betrieb eine datierte Modellversion statt eines Alias und wechseln Sie bewusst nach einem Regressionslauf auf eine neue Version, nicht dann, wenn sich der Alias ändert.
Wie oft sollte die Suite laufen, wenn sich nichts geändert hat?
Nach Zeitplan, zum Beispiel wöchentlich, um Änderungen zu finden, die Sie nicht selbst gemacht haben: Updates beim Anbieter, neue Dokumente und sich verschiebende Anfragen. Vergleichen Sie die Ergebnisse mit dem letzten Lauf.
Wer pflegt die Suite?
Das Team, das Änderungen ausliefert, meist die Entwicklung, mit QA, das die Abdeckung prüft, und der Fachperson, die neue Fälle bewertet. Ohne jemanden, der Fälle aus neuen Fehlern ergänzt, bildet die Suite echte Nutzung nach und nach nicht mehr ab.
Verwandte Leistungen
Mehr aus dem Blog
KI-Systeme testen
Eine Teststrategie für LLM-Anwendungen, RAG-Assistenten und Agenten: Teststufen, Testorakel, wiederholte Läufe, Testdaten und die übertragbaren CT-AI-Techniken.
Abnahmekriterien für KI-Systeme
Wie Sie Abnahmekriterien für eine LLM-Anwendung schreiben, pro Fehlertyp einen Schwellenwert setzen und entscheiden, ob eine gemessene Quote ihn erfüllt, mit Rechner.
Stichprobengröße für Evals
Wie Sie Eval-Ergebnisse mit Konfidenzintervallen versehen, zwei Prompts oder Modelle Fall für Fall vergleichen und ein Testset für den Unterschied bemessen, den Sie erkennen müssen.
LLM-Judge validieren
Wie Sie einen LLM-Judge an von Hand gelabelten Beispielen prüfen, seine True Positive Rate und True Negative Rate ausweisen und die gemeldete Erfolgsquote korrigieren.
Mit einem Engineer sprechen
Bringen Sie eine Aufgabe mit, die Sie verbessern möchten. Das Gespräch dauert 30 Minuten und braucht keinen Zugriff auf Ihre Systeme oder Ihre Daten.
Die Buchung läuft über Google Kalender.
Lieber zuerst schreiben? Hinterlassen Sie Ihre E-Mail-Adresse und ein paar Zeilen, dann antworten wir mit Terminvorschlägen.
Sehen Sie in Ihrem E-Mail-Programm nach dem Entwurf
Senden Sie ihn von dort ab, und ein Engineer antwortet Ihnen persönlich mit Terminvorschlägen für ein 30-minütiges Gespräch. Hat sich kein Entwurf geöffnet, schreiben Sie uns an miki@cloudsail.com.