Regression Testing für LLMs: CI/CD, Snapshot-Tests und Modell-Update-Drift erkennen

Was ist LLM-Regression-Testing?

Regression Testing für LLMs ist die automatische Prüfung, ob eine Änderung an Prompt, Modell, Retrieval-Logik oder Pipeline-Konfiguration die Antwort-Qualität im Vergleich zur vorigen Version verschlechtert hat. "Regression" heisst hier nicht nur "Fehler ist zurück" (klassische Software-Definition), sondern auch "Qualitäts-Metrik ist gesunken".

Klassisches Software-Regression-Testing prüft deterministisches Verhalten ("Funktion gibt 42 zurück"). LLM-Regression-Testing prüft semantische Äquivalenz und statistische Verteilung ("Faithfulness-Score liegt bei 92% ± 2%"). Die Prüfung ist nie pixelgenau, sondern toleranz-basiert.

Mai 2026 ist Regression-Testing für produktive LLM-Pipelines De-Facto-Standard in den fortgeschritteneren Treuhand- und Anwalts-Setups. Tools wie Promptfoo, DeepEval und Ragas haben native CI-Integration. GitHub Actions, GitLab CI und CircleCI sind direkt anbindbar.

Der Anwendungsfall ist klar: Anthropic veröffentlicht das aktuelle Claude-Spitzenmodell. Sie wollen migrieren, weil 4.7 schneller und etwas günstiger ist. Aber wird die Buchungs-Klassifizierungs-Genauigkeit auf Ihrem 200-Fall-Dataset weiterhin über 92% liegen? Ohne Regression-Test wechseln Sie und merken erst nach drei Wochen, dass die MWST-Zuordnung von 91% auf 86% gefallen ist – und produzieren zwischen drei Monaten falsche Buchungen.

Warum es wichtig ist

LLM-Pipelines sind fragiler als klassischer Code. Eine Prompt-Änderung um drei Worte kann die Halluzinations-Rate verdoppeln. Ein Modell-Update kann auf 80% der Fälle besser sein und auf 5% katastrophal schlechter. Ohne Regression-Test sehen Sie nur den Durchschnitt – und der ist taeuschend.

In der Treuhand-Praxis besonders gefährlich: stiller Drift. Ihre Pipeline läuft seit Monaten gut, dann ändert sich beim Cloud-Provider unter der Haube das Modell (typisches "model alias" wie `claude-sonnet-latest` zieht plötzlich `4.7` statt `4.6` ein), und Ihre Buchungs-Vorschläge werden schlechter – ohne Code-Änderung Ihrerseits. Regression-Tests, die täglich oder zumindest wöchentlich laufen, fangen das.

Die regulatorische Sicht: EU AI Act Art. 17 verlangt für Hochrisiko-Systeme ein "post-market monitoring", also Überwachung im Betrieb. Regression-Tests in CI sind die technische Umsetzung dieser Pflicht. Wer das nicht hat, ist nicht compliant.

Wirtschaftlich amortisieren sich Regression-Tests nach dem ersten erkannten Fehlschlag. Ein Treuhand-Büro hat Mai 2026 berichtet, dass ihr Regression-Test ein Sonnet-4.6-zu-4.7-Update als negativen Drift erkannt hat (Bilanz-Plausibilitäten-Genauigkeit fiel von 89% auf 81%). Sie sind nicht migriert, sondern haben gewartet, bis 4.7.1 mit gefixtem Problem kam. Geschätzter Schaden ohne Test: 30-50 Stunden Nacharbeit über drei Wochen.

Wie es funktioniert – Patterns und Tools

Snapshot Testing für Prompts. Ähnlich wie React-Component-Snapshots: Sie speichern bei jedem Test-Lauf die generierte Antwort zu jedem Test-Fall, und der CI-Lauf prüft, ob die neue Antwort "äquivalent" zur Snapshot-Antwort ist. Äquivalenz wird nicht durch String-Match, sondern durch semantische Ähnlichkeit (Embedding-Distanz < Schwelle) oder LLM-Judge-Score (>= 4 von 5) geprüft. Promptfoo und DeepEval unterstützen dieses Pattern nativ.

Diff-Testing zwischen Modell-Versionen. Beispiel das aktuelle Claude-Modell → 4.7. Sie laufen 200 Test-Fälle durch beide Modelle parallel. Für jeden Fall vergleicht ein dritter Modell-Judge (z.B. Das aktuelle GPT-Spitzenmodell) die Antworten: "4.7 besser", "4.6 besser", "gleichwertig". Resultat: ein Migrations-Report – auf welchen Fall-Typen ist 4.7 besser, auf welchen schlechter? Konkret bei einem Mai-2026-Treuhand-Projekt: 4.7 war auf 78% besser, auf 9% schlechter – und die 9% schlechteren Fälle waren alle MWST-Spezial-Fälle. Die Migration erfolgte mit zusätzlichem Custom-Prompt für den problematischen Sub-Use-Case.

Statistical Tolerance Testing. Statt jeden Einzelfall zu prüfen, prüft der Test die aggregierte Verteilung: "Faithfulness mean >= 0.85", "Hallucination rate <= 5%", "P95 latency <= 4s". Wenn die Aggregat-Metriken in der Toleranz liegen, ist der Test grün, auch wenn einzelne Fälle anders aussehen als vorher. Sinnvoll für Test-Sets über 500 Fälle.

CI/CD-Integration. GitHub Actions, GitLab CI, CircleCI: ein YAML-Workflow, der bei jedem Commit den Eval-Lauf triggert. Bei Pass: Merge erlaubt. Bei Fail: Block. Typischer Lauf bei 200 Test-Fällen + 3 Metriken: 5-15 Minuten, Kosten USD 3-10. Wird oft mit `if: changed-files` qualifiziert, sodass nur bei Prompt- oder Modell-Änderungen gelaufen wird.

Scheduled Drift Detection. Zusätzlich zum PR-Trigger: ein Cron-Lauf, der täglich oder wöchentlich gegen den Live-Modell-Endpoint testet. Erkennt Vendor-side-Model-Updates ("Modell-Alias hat sich geändert"), die ohne Ihren Commit passieren. Ergebnisse werden in einem Dashboard (Phoenix, TruLens, oder eigenes Grafana) über Zeit getrackt.

Tools Mai 2026. Promptfoo (CLI-orientiert, sehr schnell zu integrieren), DeepEval (Python-pytest-ähnlich), Ragas (RAG-spezifisch), Phoenix (Hosted-Dashboard). Anthropic hat im April 2026 ein eigenes Eval-API beta veröffentlicht – direkt im Claude-Workbench-Bereich, gut für Anthropic-only-Setups.

Regression Testing einführen in 6 Schritten

1. 01Golden Dataset und Eval-Framework vorbereiten (DeepEval/Promptfoo/Ragas) – Mindest-Basis 100 Fälle, 2-4 Metriken.
2. 02Baseline-Lauf mit aktueller Modell-Version durchführen und Ergebnisse einfrieren (Faithfulness 0.91, Hallucination 3%, Latency P95 3.2s).
3. 03Toleranz-Schwellen definieren: typisch -3% absolute Verschlechterung als Fail-Schwelle.
4. 04CI-Workflow (GitHub Actions) bauen: bei PR-Trigger Eval-Lauf, Block bei Fail.
5. 05Scheduled Cron (täglich/wöchentlich) gegen Live-Endpoint für Vendor-Drift einrichten.
6. 06Drift-Dashboard aufsetzen (Phoenix oder eigenes Grafana): Metriken über Zeit, Alarm bei Anomalien.

Wann Regression Testing Pflicht ist

Sie brauchen Regression-Tests, sobald eine LLM-Pipeline produktiv ist und Outputs an Mandanten, Behörden oder direkte Buchungssysteme gehen. Konkret:

Bei jedem Modell-Update. Switch von dem aktuellen Claude-Modell auf 4.7, das aktuelle GPT-Spitzenmodell auf 5.2, Mistral-Large 2.0 auf 2.1 – Pflicht. Auch dann, wenn das Update nur "minor" heisst. Modell-Provider sind beim Beschreiben von Änderungen oft optimistisch.

Bei jedem Prompt-Change. Eine scheinbar harmlose Reformulierung kann die Antwort-Qualität verschieben. Regression-Test gegen das vorige Prompt-Verhalten zeigt es.

Bei jedem Retrieval-Parameter-Update. Änderung von top-k, Chunking-Size, Embedding-Modell, Reranker – alles muss durch den Eval-Lauf.

Bei jedem Library-Upgrade. Wechsel von LangChain 0.3 auf 0.4, Update der OpenAI-SDK – oft verändert sich Verhalten subtil.

Scheduled für Vendor-Drift. Mindestens wöchentlich, idealerweise täglich, gegen den Live-Modell-Endpoint laufen, um vendor-side Updates zu erkennen.

Für KMU-Treuhand-Setups (1-2 Pipelines, < 5 Mitarbeitende): einmal pro Woche Cron + Eval-Lauf bei jedem PR ist die untere Schwelle. Für Anwaltskanzleien mit haftungsrelevanten Pipelines: täglicher Cron + PR-Trigger.

Wann minimaler Aufwand reicht

Für Pilot-Projekte unter 4 Wochen Laufzeit ist eine voll integrierte CI/CD-Regression nicht nötig. Ein wuechentlicher manueller Lauf des Test-Skripts und kurze Notiz im Team-Kanal reichen.

Für interne Tools mit niedrigem Risiko (Brainstorming-Helfer, interne Stichwort-Suche, Wissens-Lookup) gilt: keine Regression-Test-Pipeline nötig, dafür aber ein Mechanismus, über den Mitarbeitende Probleme melden können ("Daumen runter"-Button).

Vorsicht vor "wir testen, wenn wir Zeit haben". Das passiert nicht. Wer einmal ohne Regression-Test deployt hat, deployt nie wieder mit Test, bis ein Vorfall passiert. Bauen Sie die Pipeline ein, bevor Sie productiv gehen.

Noch ein Punkt: nicht jeder Test-Lauf ist Regression-Test. Eine 5-Fälle-Schnellprüfung ist Smoke-Test, kein Regression-Test. Echte Regression braucht ein stabiles, statistisch belastbares Golden Dataset (mindestens 100 Fälle) und reproduzierbare Metriken. Sonst messen Sie Rauschen.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Promptfoo – Regression Testing for LLMs (docs) · 2026-05
2. DeepEval – CI/CD Integration Guide · 2026-04
3. EU AI Act, Article 17 – Post-Market Monitoring · 2024-07
4. Anthropic – Claude Workbench Eval API (beta) · 2026-04
5. Arize Phoenix – Drift Detection for LLM Apps · 2026-03