KI-Modell wechseln: Regressionen vor dem Rollout erkennen

Bevor Sie ein KI-Modell wechseln, sollten Sie die bisherige und die neue Konfiguration mit denselben fachlich geprüften Fällen vergleichen. Entscheidend sind dabei auch Aufgaben, die bisher funktioniert haben und nach dem Wechsel scheitern. Solche Regressionen können in einer insgesamt besseren Erfolgsquote verschwinden.
Die Freigabe sollte deshalb drei Fragen beantworten: Welche Fälle werden besser? Welche werden schlechter? Und sind die neuen Fehler innerhalb des vorgesehenen Einsatzbereichs akzeptabel?
Prüfen Sie zuerst, was tatsächlich geändert wird
Ein Modellwechsel kann weitere Anpassungen auslösen: einen anderen System-Prompt, geänderte Tool-Definitionen, neue Parameter oder einen anderen Umgang mit strukturierten Ausgaben. Halten Sie diese Änderungen fest. Sonst lässt sich ein besseres oder schlechteres Ergebnis später keiner konkreten Ursache zuordnen.
Erfassen Sie mindestens:
- Anbieter und genaue Modellkennung,
- Prompt- und Workflow-Version,
- verfügbare Werkzeuge und deren Schemas,
- Generationseinstellungen und Ausgabelimits,
- verwendete Datenquellen und Retrieval-Konfiguration,
- erlaubte Aktionen, Rollen und Freigaben.
Ändern Sie zunächst nur die für die Migration notwendigen Bestandteile. Zusätzliche Optimierungen können anschließend getrennt bewertet werden. Wenn eine Anbieterumstellung mehrere Änderungen zwingend zusammenführt, dokumentieren Sie diese als gemeinsame neue Konfiguration.
Eine Abschaltfrist ist ein Anlass, keine Qualitätsfreigabe
Anbieter veröffentlichen Fristen und Ersatzempfehlungen für auslaufende Modelle. OpenAI führt dafür eine Deprecation-Übersicht; Anthropic dokumentiert Modellstatus, Abschalttermine und empfohlene Nachfolger. Stand der Quellenprüfung: 22. Oktober 2026.
Eine Ersatzempfehlung beantwortet die Verfügbarkeitsfrage. Ob der Nachfolger Ihren Workflow ausreichend gut erledigt, muss anhand Ihrer Aufgaben geprüft werden.
Planen Sie vor Ablauf der Frist Zeit für Vergleich, Anpassung und kontrollierten Rollout ein. Bleibt das bisherige Modell danach nicht verfügbar, kann es auch nicht mehr als Rückfall dienen.
Vergleichen Sie auf Fallebene statt nur im Durchschnitt
Das folgende Beispiel ist vollständig fiktiv. Es beschreibt keinen Anbieterbenchmark und keinen Kundenfall.
Zwei Konfigurationen bearbeiten dieselben 100 Aufgaben:
| Ergebnis im direkten Vergleich | Anzahl |
|---|---|
| Beide Konfigurationen bestehen | 88 |
| Nur die bisherige besteht | 4 |
| Nur die neue besteht | 6 |
| Beide scheitern | 2 |
| Gesamt | 100 |
Die bisherige Konfiguration besteht 92 Aufgaben, die neue 94. Trotzdem erzeugt die neue Konfiguration vier Regressionen. Sind darunter falsche Empfänger, unzulässige Schreibaktionen oder fachlich kritische Beträge, kann der Wechsel trotz höherer Gesamtquote ungeeignet sein.
Die sechs Verbesserungen und vier Verschlechterungen müssen daher einzeln erklärt werden. Ein durchschnittlicher Qualitätsgewinn verrechnet keine kritische Grenzverletzung.
Legen Sie die Bewertungsregeln vor dem Vergleich fest
Für jeden Fall sollte erkennbar sein, was als akzeptiertes Ergebnis gilt. Je nach Aufgabe sind das ein korrekter Wert, eine belegte Antwort, eine notwendige Rückfrage oder eine ausdrücklich unterlassene Aktion.
Trennen Sie dabei:
- fachliche Richtigkeit: Die Aufgabe wurde korrekt erledigt.
- Prozessgrenzen: Rechte, Freigaben und erlaubte Aktionen wurden eingehalten.
- Betriebsgrenzen: Laufzeit, Kosten und Abbruchbedingungen liegen im vereinbarten Bereich.
Bewertungsregeln müssen zur Aufgabe passen. Ein exakter Textvergleich ist für eine strukturierte Kennung sinnvoll, für eine offene Zusammenfassung meist zu eng. Bei qualitativen Bewertungen benötigen Sie eine klare Rubrik und fachlich geprüfte Referenzfälle.
OpenAI empfiehlt in seinen Evaluation Best Practices, automatische Bewertungen mit menschlichen Urteilen abzugleichen und typische, ungewöhnliche sowie adversariale Fälle einzubeziehen. Daraus folgt keine universelle Bestehensquote für Ihr System. Die Grenzwerte müssen aus Ihrem Einsatzbereich entstehen.
Verwenden Sie eine kontrollierte Vergleichsbasis
Ein brauchbares Testset deckt die unterstützten Aufgaben und bekannte Fehlerklassen ab. Es sollte beispielsweise unterschiedliche Eingabelängen, Sprachen, Datenquellen und Berechtigungsrollen enthalten, soweit diese tatsächlich zum Workflow gehören.
Halten Sie Testset und Bewertungsregeln während des Vergleichs konstant. Veraltete oder falsche Referenzen müssen korrigiert werden; anschließend benötigen beide Konfigurationen denselben korrigierten Vergleich.
Verwenden Sie für die abschließende Prüfung auch Fälle, die nicht bereits für die Anpassung genutzt wurden. Wiederholen Sie ausgewählte Fälle nach einem vorher festgelegten Plan, um auffällige Schwankungen sichtbar zu machen. Wenige Wiederholungen beweisen allerdings keine seltene Fehlerrate.
Bei RAG-Anwendungen sollten Sie außerdem erkennen können, ob sich die gefundenen Quellen oder erst deren Verarbeitung verändert haben. Der Leitfaden zur RAG-Evaluation erläutert diese Trennung.
Prüfen Sie bei Agenten auch die ausgeführten Schritte
Eine richtige Abschlussnachricht zeigt noch nicht, ob ein Agent zulässige Werkzeuge mit korrekten Parametern verwendet hat.
Bewerten Sie deshalb auch:
- die gewählte Aktion und ihre Parameter,
- notwendige Rückfragen und Freigaben,
- Wiederholungen und Abbruchbedingungen,
- den tatsächlich erreichten Zustand im Zielsystem.
Führen Sie Vergleichsläufe in einer kontrollierten Umgebung aus. Schreibaktionen müssen dort verhindert oder gegen geeignete Testsysteme ausgeführt werden. Ein zusätzlicher Vergleichslauf darf keine zweite produktive Buchung oder Nachricht erzeugen.
Für die umfassendere Prüfung des Ablaufs dient der Beitrag zur Agent-Evaluation.
Ein Rückfallplan muss nach der Abschaltung noch funktionieren
„Bei Problemen wechseln wir zurück“ ist nur brauchbar, solange die bisherige Version verfügbar bleibt. Prüfen Sie diese Verfügbarkeit anhand der Anbieterangaben.
Für die Zeit danach brauchen Sie einen anderen Weg: eine bereits geprüfte Alternative, einen begrenzten Betrieb ohne die betroffene Funktion oder eine manuelle Bearbeitung.
Legen Sie außerdem fest, was mit laufenden Vorgängen passiert. Ein technischer Rückwechsel macht bereits ausgeführte Änderungen nicht rückgängig.
Dokumentieren Sie die Freigabe auf einer Seite
Die folgende Vorlage ist eine vorgeschlagene Arbeitshilfe:
| Entscheidungspunkt | Vor der Freigabe festhalten |
|---|---|
| Änderungsumfang | Modell sowie mitgeänderte Prompts, Einstellungen und Schnittstellen |
| Vergleichsbasis | Version des Testsets und der Bewertungsregeln |
| Neue Fehler | Betroffene Fälle, Auswirkungen und Behandlung |
| Betriebsgrenzen | Zulässige Laufzeit, Kosten und Fehlerbehandlung |
| Freigabe | Verantwortliche Person und freigegebener Einsatzbereich |
| Rückfall | Auslöser, verfügbare Alternative und Umgang mit laufenden Vorgängen |
Ein Wechsel kann für einen Teil der Aufgaben geeignet sein und für einen anderen noch nicht. Diese Grenze sollte ausdrücklich dokumentiert werden. Für die wirtschaftliche Bewertung ergänzt die Anleitung zu KI-Kosten pro erfolgreicher Aufgabe den Qualitätsvergleich.
Beginnen Sie mit dem nächsten tatsächlich betroffenen Ablauf
Wählen Sie eine Anwendung mit klarer Aufgabe und nachvollziehbarer Konfiguration. Erfassen Sie die verwendete Modellversion, prüfen Sie die Verfügbarkeitsfrist und vergleichen Sie den Kandidaten anhand Ihrer bestehenden Fälle.
Fehlen dafür brauchbare Testfälle, ist der nächste Schritt der Aufbau einer kleinen, fachlich überprüften Vergleichsbasis.
Wenn für Ihr vorhandenes System Vergleichsbasis und Freigabekriterien fehlen, unterstütze ich Sie bei einer begrenzten Production-Readiness-Prüfung.