So vergleichst du KI-Antworten zuverlässig nach einem Modellwechsel

Zuverlässig vergleichst du KI-Antworten nach einem Modellwechsel, indem du dieselben echten Eingaben durch altes und neues Modell schickst, die Antworten des alten Modells vorher als Vergleichswert sicherst und schon vor dem Lesen der neuen Antworten festlegst, woran du „gut genug“ erkennst. Ohne diese Reihenfolge passiert fast immer dasselbe: Man liest die neue Antwort, findet sie plausibel, und die Kriterien entstehen erst im Nachhinein — passend zu dem, was gerade vor einem steht.

Diese Anleitung zeigt das Vorgehen an einer fiktiven Übung. Sie ersetzt keine fachliche Freigabe bei rechtlich oder finanziell heiklen Antworten — wo diese Methode an ihre Grenzen stößt, steht am Ende.

Was du dafür brauchst

• Zugriff auf beide Modelle, solange das alte noch läuft. Bei Anthropic-Modellen kündigt der Anbieter laut eigener Dokumentation eine Abschaltung mindestens 60 Tage vorher per E-Mail und in der Dokumentation an; danach schlagen Anfragen an das alte Modell fehl. Wer erst nach dem Abschalttermin vergleichen will, hat keine Vergleichsantwort mehr — nur noch die Erinnerung daran, wie es „früher besser“ war.
• Eine feste Liste echter Eingaben aus dem eigenen Einsatz — anonymisierte Kundenanfragen, tatsächlich verwendete Vorlagen, wiederkehrende interne Aufgaben. Erfundene Testfragen sind kein Ersatz, weil sie oft genau die Formulierungen vermeiden, an denen es in der Praxis hakt.
• Eine Stelle, an der du dieselbe Eingabe unverändert an beide Modelle schicken kannst — die Konsole des Anbieters, ein einfaches Skript oder notfalls zwei geöffnete Chatfenster. Wichtig ist nur, dass Systemanweisung und Eingabetext bei beiden Läufen identisch bleiben.

Schritt 1: Die Vergleichsantworten des alten Modells sichern

Bevor irgendetwas mit dem neuen Modell passiert, werden die Antworten des alten Modells auf die komplette Testfall-Liste einmal erzeugt und wortgetreu gespeichert — als Textdatei, Tabelle oder Notiz, egal wie, nur nicht „im Kopf“. Das ist die Baseline, gegen die später verglichen wird. Diesen Schritt überspringen viele, weil das alte Modell ja „gerade noch da“ ist — bis es nach der Abschaltung nicht mehr da ist und der Vergleich nur noch aus Erinnerung besteht.

Schritt 2: Abnahmekriterien festlegen, bevor du die neuen Antworten liest

Für jeden Testfall — oder für die Testfallgruppe insgesamt — wird vorher notiert, was eine Antwort erfüllen muss, zum Beispiel:

| Kriterium | Beispiel | |---|---| | Inhaltlich korrekt | Alle genannten Fristen, Beträge oder Fachbegriffe stimmen mit der Vorlage überein | | Format eingehalten | Geforderte Feldstruktur, Aufzählung oder Länge wird eingehalten | | Tonfall passt | Duzen oder Siezen wie vorgegeben, keine unpassende Förmlichkeit oder Lässigkeit | | Ablehnungsverhalten gleich geblieben | Anfragen, die bisher korrekt abgelehnt wurden, werden weiterhin abgelehnt — und umgekehrt keine plötzlichen Fehlablehnungen |

Diese Liste muss vor Schritt 3 stehen. Genau das ist der Unterschied zur reinen Bauchgefühl-Prüfung: Man kann eine Antwort erst dann eindeutig als „schlechter geworden“ einstufen, wenn vorher klar war, wogegen sie gemessen wird.

Schritt 3: Dieselben Eingaben durch das neue Modell schicken

Jede Eingabe aus der Testfall-Liste geht unverändert an das neue Modell — gleicher Wortlaut, gleiche Systemanweisung, keine nachträgliche Präzisierung, „weil das neue Modell das ja besser versteht“. Wer die Eingabe für das neue Modell anpasst, vergleicht am Ende zwei unterschiedliche Aufgaben, nicht zwei Modelle.

Schritt 4: Alt gegen neu gegen Kriterien prüfen

Für jeden Testfall wird die neue Antwort gegen die vorher festgelegten Kriterien bewertet — bestanden oder nicht bestanden, nicht „fühlt sich anders an“. Ein Vorgehen, das genau diesem Muster folgt, beschreibt OpenAI im eigenen Cookbook zur Erkennung von Regressionen: Ein „Run“ mit der neuen Version wird gegen einen zuvor gespeicherten Baseline-Run bewertet, und ein deutlich niedrigerer Wert zeigt eine Verschlechterung an. Für einen manuellen Vergleich ohne eigene Auswertungs-Infrastruktur reicht dasselbe Prinzip in einer einfachen Tabelle: Testfall, Kriterium, bestanden ja/nein, Kommentar.

Die fiktive Übung: Kundenantworten nach einem Modellwechsel

Fiktive Übung mit angenommenen Werten, kein gemessenes Kundenprojekt. Ein Betrieb beantwortet Standard-Kundenanfragen bisher mit einem älteren Modell und testet vor der Umstellung fünf echte, anonymisierte Anfragen aus dem eigenen Postfach gegen das neue Modell:

| Testfall | Kriterium „Frist korrekt“ | Kriterium „Ton passt (Duzen)“ | Kriterium „Format: 3 Sätze max.“ | |---|---|---|---| | Lieferverzögerung erklären | bestanden | bestanden | bestanden | | Reklamation ablehnen (berechtigt) | bestanden | nicht bestanden — Antwort siezt | bestanden | | Rückerstattung zusagen | bestanden | bestanden | nicht bestanden — 5 statt 3 Sätze | | Terminverschiebung anbieten | bestanden | bestanden | bestanden | | Nachfrage zu Garantiefall | nicht bestanden — falsche Monatsangabe | bestanden | bestanden |

Ergebnis dieser angenommenen Übung: 3 von 5 Testfällen bestehen alle Kriterien vollständig, 2 von 5 weichen in genau einem Punkt ab. Die Konsequenz ist nicht „Modellwechsel abbrechen“, sondern gezielt nachbessern: die Systemanweisung um eine feste Duz-Regel und eine harte Satzobergrenze ergänzen, die Monatsangabe bei Garantiefällen erneut prüfen — und danach genau diese zwei Testfälle erneut laufen lassen, nicht die ganze Liste von vorn.

Erwartete Unterschiede von gemessenen Ergebnissen trennen

Manches ändert sich bei einem Modellwechsel erfahrungsgemäß, ohne dass man es an den eigenen Daten neu prüfen muss — anderes lässt sich ausschließlich am eigenen Testfall-Set feststellen:

| Typischerweise ändert sich | Muss am eigenen Testfall-Set gemessen werden | |---|---| | Tonfall, Ausführlichkeit, bevorzugte Formatierung | Fachliche Korrektheit für die eigenen Aufgaben | | Reaktion auf Grenzfälle nahe der Ablehnungsschwelle | Umgang mit den eigenen Sonderfällen und Ausnahmen | | Technische Parameter — bei Claude-Modellen ab Opus 4.7 führt das Setzen von temperature, top_p oder top_k laut Anthropic zu einem Fehler statt zu einer stillen Änderung | Ob die neue Antwortqualität für die konkrete Aufgabe besser, gleich oder schlechter ist |

Der linke Teil der Tabelle erklärt, warum sich eine Antwort anders liest. Der rechte Teil beantwortet die eigentliche Frage, ob das neue Modell die Aufgabe noch genauso gut löst — und die lässt sich nicht aus einem Änderungsprotokoll ablesen, sondern nur aus dem eigenen Vergleich.

Fehlerprüfung: die häufigsten Stolperstellen

• Kein Baseline gesichert. Ohne gespeicherte Antworten des alten Modells bleibt nur der subjektive Eindruck „früher war das anders“ — nicht überprüfbar, sobald das alte Modell abgeschaltet ist.
• Kriterien erst nach dem Lesen aufgestellt. Dann werden sie unbewusst an das angepasst, was ohnehin schon vor einem liegt, und der Vergleich verliert seinen Wert.
• Eingaben zwischen den Läufen verändert. Auch eine kleine Umformulierung macht den Vergleich ungültig, weil dann zwei verschiedene Aufgaben verglichen werden statt zweier Modelle an derselben Aufgabe.
• Nur automatisiert bewertet, nirgends selbst gelesen. Ein zweites Modell als Bewerter beschleunigt die Vorprüfung, ersetzt aber bei folgenreichen Antworten nicht den eigenen Blick auf die auffälligen und eine Stichprobe der unauffälligen Fälle.

Wo diese Methode an ihre Grenzen kommt

Diese Methode prüft, ob ein neues Modell auf den eigenen Testfällen gleich gut oder besser abschneidet — sie ist keine rechtliche oder fachliche Freigabe. Bei Antworten mit Rechtsfolgen, etwa steuerlicher oder medizinischer Natur, muss eine fachlich zuständige Person die Abweichungen inhaltlich bewerten, nicht nur ein Kriterienraster abhaken. Und ein Testfall-Set von zehn oder zwanzig Fällen deckt nie alle künftigen Eingaben ab — es senkt das Risiko, schafft aber keine Garantie für Eingaben, die im Test schlicht nicht vorkamen.

Der nächste Schritt

Wer diese Übung nicht allein durchgehen will oder bei den eigenen Kriterien nicht weiterkommt, bekommt in der KI-Beratung und Hilfe beim Aufbau einen Blick von außen auf genau die Testfälle, die am meisten Unsicherheit bringen. Für die technische Seite von Testfällen und erwarteten Ergebnissen — nicht bei Modellwechseln, sondern bei fehlerhaften Automatisierungsschritten — hilft die Übung Automatisierung testen.