KI-Basismodell wechseln ohne Qualitätsbruch: Evals, Canary und Rollback

Ein neues KI-Basismodell verspricht oft bessere Antworten, geringere Kosten oder kürzere Reaktionszeiten. Für einen produktiven Website-Chatbot ist der Wechsel trotzdem kein Austausch eines beliebigen Softwarepakets. Schon eine neue Modellversion kann Anweisungen anders gewichten, Antworten ausführlicher formulieren, strukturierte Daten abweichend erzeugen oder Tools in einer anderen Reihenfolge aufrufen. Eine Migration ist deshalb erst dann erfolgreich, wenn der Chatbot seine konkreten Aufgaben mindestens so zuverlässig erledigt wie zuvor – und wenn das Team bei Problemen in Minuten zurückschalten kann.

Anbieter kündigen Modelle regelmäßig ab. Die OpenAI-Dokumentation zu Abkündigungen führt Abschalttermine und empfohlene Ersatzmodelle; Anthropic unterscheidet in seinem Modell-Lifecycle die Status „Active“, „Legacy“, „Deprecated“ und „Retired“. Solche Fristen sind der Anlass für die Migration, aber nicht ihr Qualitätsnachweis. Den liefert nur ein Test- und Rollout-Verfahren, das zum eigenen Chatbot passt.

Was beim Basismodellwechsel tatsächlich verändert wird

Dieser Prozess ist klar von einer Migration des Embedding-Modells zu trennen. Beim Embedding-Wechsel müssen Dokumente neu vektorisiert und Suchindizes kompatibel gehalten werden. Beim Basismodellwechsel bleibt der Retrieval-Index normalerweise bestehen; verändert wird das Modell, das aus Systemanweisung, Gespräch, gefundenen Quellen und Tool-Ergebnissen die Antwort erzeugt. Getestet werden daher Antwortverhalten, Quellenbindung, Format, Tool-Nutzung, Sicherheit, Latenz und Kosten.

Auch ein allgemeiner Shadow-Mode-Test vor dem Website-Launch löst nur einen Teil der Aufgabe. Shadow Traffic kann zwei Modelle mit denselben Eingaben versorgen, ohne die neue Antwort auszuliefern. Der hier beschriebene Basismodellwechsel geht weiter: Er definiert vorab eine Abnahmematrix, leitet einen kleinen Anteil echten Traffics zum Kandidaten, überwacht Nutzer- und Systemsignale und hält eine getestete Rückschaltung bereit.

Vor dem Test: einen eindeutigen Migrationsvertrag festlegen

Vergleiche sind wertlos, wenn sich währenddessen mehrere Dinge ändern. Halten Sie deshalb für die erste Runde Systemprompt, Retrieval-Konfiguration, Tool-Schemas, Temperatur, maximale Ausgabelänge und Sicherheitsregeln soweit kompatibel konstant und dokumentieren Sie unvermeidbare Parameteränderungen, etwa nicht unterstützte Sampling-Optionen. Dokumentieren Sie das bisherige Modell als Basis und das neue Modell als Kandidat. Nutzen Sie nach Möglichkeit explizite Modellversionen statt eines beweglichen Alias. Ein Alias kann später auf einen anderen Snapshot zeigen und den vermeintlich reproduzierbaren Vergleich verändern.

Der Migrationsvertrag enthält außerdem die Nutzergruppen und Funktionen, die zunächst ausgeschlossen bleiben. Ein FAQ-Chatbot darf beispielsweise früh in den Canary gehen, während Schreibzugriffe auf Bestellungen, Vertragsauskünfte oder besonders sensible Supportfälle länger auf der Basis bleiben. So wird das Risiko nach Geschäftswirkung begrenzt und nicht nur nach technischer Komplexität.

Das Testset muss den echten Traffic abbilden

Ein Golden Set sollte nicht nur saubere Standardfragen enthalten. Sammeln Sie anonymisierte oder synthetisch nachgebildete Fälle aus den wichtigsten Intents: eindeutige Fragen, mehrdeutige Formulierungen, Folgefragen, fehlende Dokumente, widersprüchliche Quellen, Tool-Fehler und Eingaben, die an einen Menschen übergeben werden müssen. Teilen Sie die Fälle nach Sprache, Gerät, Kundentyp und Risikoklasse auf. Dadurch bleibt sichtbar, ob eine gute Gesamtnote kleine, aber geschäftskritische Teilgruppen verdeckt.

Die offizielle Anthropic-Anleitung zu Erfolgskriterien und Evals empfiehlt spezifische, messbare und auf den Anwendungszweck bezogene Kriterien sowie realitätsnahe Randfälle. Auch die OpenAI-Anleitung zu Evals beschreibt Tests besonders beim Upgrade oder Ausprobieren neuer Modelle als wesentlichen Bestandteil verlässlicher Anwendungen. Da OpenAI auf derselben Seite die bisherige Evals-Plattform abkündigt, sollte das eigene Golden Set in einem portablen Format gespeichert und nicht an ein einzelnes Dashboard gebunden werden.

Eine Bewertungsmatrix statt eines einzigen Durchschnittswerts

Die folgenden Grenzwerte sind ein Beispiel, keine universelle Vorgabe. Legen Sie sie ausgehend von der bisherigen Produktionsleistung und dem Schaden eines Fehlers fest. Ein Kandidat darf einen günstigeren Tokenpreis nicht mit schlechterer Quellenbindung erkaufen.

Automatische Prüfungen eignen sich für JSON-Schemas, Pflichtformulierungen, Linkziele, Tool-Argumente und deterministische Geschäftsregeln. Für Ton, Vollständigkeit und nützliche Erklärungen braucht es zusätzlich eine klare Rubrik; Stichproben durch Fachpersonen kalibrieren einen LLM-basierten Bewerter. Die Ergebnisse sollten pro Intent und Risikoklasse gespeichert werden, nicht nur als ein Score. Wie ein solches Set grundsätzlich aufgebaut wird, zeigt auch unser Leitfaden zur Antwortqualität mit Golden Set.

Konkretes Beispiel: Modellwechsel im B2B-Support

Angenommen, ein B2B-Softwareanbieter betreibt einen Chatbot für Produktfragen, Kontoverwaltung und die Vorbereitung von Support-Tickets. Das Team erstellt 240 Testfälle: 120 häufige Wissensfragen, 40 mehrdeutige Folgefragen, 30 Fälle mit fehlender Quelle, 25 Tool-Simulationen und 25 Sicherheits- oder Übergabefälle. Beide Modelle erhalten exakt dieselben Prompts, Dokumenttreffer und simulierten Tool-Ergebnisse.

Der Kandidat beantwortet Standardfragen schneller und günstiger, verfehlt aber in fünf Folgefragen den Bezug zur vorherigen Nachricht. Die Gesamtnote wäre trotzdem besser. Die Segmentauswertung zeigt jedoch einen klaren Qualitätsbruch. Das Team ergänzt keine willkürliche Ausnahme, sondern präzisiert die Konversationsregel, erweitert das Testset um ähnliche Fälle und testet beide Modelle erneut. Erst nachdem der Kandidat alle harten Gates erfüllt, beginnt der produktive Canary.

Für den Start werden zwei Prozent der geeigneten neuen Gespräche dem Kandidaten zugeordnet. Die Zuweisung wird beim Gesprächsstart etwa aus einem Hash der Conversation-ID abgeleitet und für das gesamte Gespräch persistiert; höhere Canary-Stufen gelten nur für neue Gespräche. Schreibende Tool-Aufrufe und Hochrisiko-Intents bleiben zunächst auf der Basis. Nach einem ausreichend großen Beobachtungsfenster folgen zehn, 25, 50 und schließlich 100 Prozent – aber nur, wenn jedes Gate weiterhin grün ist. Stufen und Mindeststichproben werden vorab festgelegt, damit Zeitdruck nicht nachträglich die Regeln verwässert.

Online-Signale, die wirklich zählen

Im Canary reichen HTTP-Fehler und mittlere Latenz nicht aus. Beobachten Sie No-Answer-Rate, Abbruch nach der ersten Antwort, Wiederholungsfragen, Handoff-Quote, Quellenklicks, Schemafehler und Tool-Abbrüche getrennt nach Basis und Kandidat. Ein gemeinsamer Trace verbindet Modellversion, Promptversion, Retrieval-Treffer und Tool-Schritte, ohne unnötige personenbezogene Inhalte zu speichern. Unser Beitrag zu Chatbot-Observability erklärt diese Prüfspur im Detail.

Vergleichen Sie außerdem Kosten pro erfolgreich gelöstem Fall statt nur Kosten pro Million Tokens. Ein günstigeres Modell, das öfter Rückfragen oder menschliche Nacharbeit erzeugt, kann betrieblich teurer sein. Umgekehrt darf eine leichte Latenzerhöhung vertretbar sein, wenn sie in einer wichtigen Risikoklasse nachweislich präzisere Antworten bringt.

Rollback ist eine Funktion, kein Dokument

Der Rückweg muss vor der ersten Canary-Stufe technisch getestet sein. Modell-ID und zugehörige Parameter gehören in versionierte Konfiguration oder ein kontrolliertes Feature Flag. Solange der Anbieter die bisherige Version noch unterstützt, bleibt sie während des Canarys als Rückfallziel verfügbar; vor ihrem Abschalttermin braucht es zusätzlich ein unterstütztes Fallback. Bestehende Gespräche sollten entweder konsistent auf ihrem ursprünglichen Modell bleiben oder nach einer ausdrücklich getesteten Regel wechseln.

Definieren Sie harte Auslöser: beispielsweise ein Schemafehler bei einer schreibenden Aktion, eine Verschlechterung eines sicherheitsrelevanten Intents, ein deutlicher Sprung der Fehlerquote oder eine Überschreitung des Latenzbudgets. Bei einem solchen Signal wird automatisch oder durch eine klar benannte Rufbereitschaft zurückgeschaltet. Danach bleiben Logs, Kandidatenversion und betroffene Stichprobe erhalten, damit die Ursache analysiert werden kann. Ein vorbereiteter Ablauf ist wesentlich belastbarer als ein spontaner Code-Deploy; ergänzend hilft ein vollständiges Incident-Response-Playbook.

Checkliste für die Freigabe

• Abschalttermin, Ersatzmodell und betroffene Endpunkte aus der offiziellen Anbieter-Dokumentation erfassen.
• Basis und Kandidat mit unveränderter Prompt-, Retrieval- und Tool-Konfiguration festschreiben.
• Golden Set nach Intent, Sprache und Risikoklasse aufteilen; Randfälle und echte Fehlerbilder ergänzen.
• Harte Gates für Quellenbindung, strukturierte Ausgaben, Tools, Sicherheit und Handoff definieren.
• Latenz, Fehlerrate, Tokens und Kosten pro gelöstem Fall messen.
• Canary-Zuweisung für ganze Gespräche stabil halten und sensible Funktionen zunächst ausschließen.
• Stufen, Mindeststichprobe, Beobachtungsdauer und Abbruchgrenzen vor dem Rollout dokumentieren.
• Rollback technisch testen, Verantwortliche benennen und ein vom Anbieter unterstütztes Rückfallziel verfügbar halten.
• Nach 100 Prozent weiter beobachten und das Golden Set um neu entdeckte Produktionsfälle erweitern.

Fazit: Der Modellname ist nur der Anfang

Ein kontrollierter Basismodellwechsel verbindet Produktqualität und Betriebssicherheit. Offizielle Lifecycle-Hinweise liefern die Frist, Evals liefern Evidenz für die Eignung, Canary-Traffic begrenzt die Auswirkung unbekannter Fehler und ein getesteter Rollback verkürzt die Reaktionszeit. Wer diese vier Bausteine als wiederholbaren Prozess etabliert, kann neue Modelle nutzen, ohne seinen Website-Chatbot zum Experiment für alle Nutzerinnen und Nutzer zu machen.

Möchten Sie Modellversion, Qualitätsgates und Rollout Ihres Website-Chatbots strukturiert planen? ChatReact unterstützt Sie dabei, Wissensbasis, Antwortverhalten und Übergaben so aufzusetzen, dass Änderungen messbar und kontrollierbar bleiben.