KI-Modell wechseln: Warum Sie die Modellversion festschreiben sollten

Fortsetzung unserer Serie über eigene Experimente mit Entscheidungsmodellen.

TL;DR: Wir haben ein KI-Entscheidungsmodell gegen sein neues Release getauscht und sonst nichts verändert: gleiche Schnittstelle, gleicher Prompt, gleiche Optionen, gleicher Code. Dann haben wir 21.636 gespeicherte Anfragen unverändert erneut gestellt. Ergebnis: Nur 20 % der Kniffel- und 35 % der Tic-Tac-Toe-Entscheidungen blieben gleich. Das neue Release hängt viel weniger an der Reihenfolge der Optionen, ist aber kaum kompetenter. Und an einer festen Schwelle von 0,5 wandern 894 von 4.298 Entscheidungen von „automatisch“ zu „Prüfung durch einen Menschen“. Wer KI-Modelle in Prozesse einbindet, sollte Modellversionen deshalb festschreiben und vor jedem Wechsel testen.

Ein Update, das jeder kennt

Ein Anbieter veröffentlicht ein neues Modell-Release. Die Schnittstelle bleibt gleich, die Ankündigung verspricht Verbesserungen, und der eigene Code läuft ohne eine Änderung weiter. Was passiert mit den Entscheidungen, die das Modell bisher getroffen hat?

Die Frage ist alltäglicher, als sie klingt. Modelle werden ständig ausgetauscht, teils sogar automatisch: GitHub Copilot wählt mit Auto und HydraFusion das Modell selbst aus, und ältere Modelle werden regelmäßig abgekündigt. Wer ein Modell in einen Geschäftsprozess eingebunden hat, bekommt das neue Verhalten oft ohne eigenes Zutun.

Wir haben das an einem Modell gemessen, das wir aus den ersten Teilen der Serie gut kennen.

Der Versuch

In den bisherigen Teilen haben wir das Entscheidungsmodell Strands Decider 2B in Version 19 untersucht: beim Framing-Effekt, beim Kniffel und beim Training gegen den Positionsbias. Zusätzlich haben wir es Tic-Tac-Toe spielen lassen. Alle Anfragen und Antworten haben wir dabei gespeichert.

Inzwischen gibt es ein neues Release derselben Modellfamilie, v1-2610, veröffentlicht am 9. Oktober 2026. Laut Modellkarte teilen sich beide Releases das Basismodell, den Tokenizer und den Code, der die Antworten in Wahrscheinlichkeiten umrechnet. Neu sind Trainingsdaten, Lehrermodell und Adapter.

Unser Vorgehen:

• Alle gespeicherten Anfragen erneut stellen, Byte für Byte unverändert: 21.636 verschiedene Eingaben aus Kniffel und Tic-Tac-Toe.
• Nur das Modell-Release tauschen. Beide Releases sind auf eine feste Revision gepinnt.
• Sauber prüfen: Vor dem Lauf haben wir das alte Release erneut geladen und seine gespeicherten Ergebnisse exakt reproduziert. Das neue Release liefert bei Wiederholung bitgleiche Wahrscheinlichkeiten. Jeder Unterschied geht also auf das Modell zurück, nicht auf Zufall.
• Wahrheit: Für beide Spiele gibt es einen exakten Solver, der in jeder Situation die beste Entscheidung kennt.

Der Lauf dauerte 15,2 Stunden auf einer gewöhnlichen CPU, ohne Grafikkarte.

Ergebnis 1: Die meisten Entscheidungen sind andere

Bei identischen Eingaben wählte das neue Release nur bei 20 % der Kniffel-Entscheidungen und bei 35 % der Tic-Tac-Toe-Stellungen dieselbe Option wie das alte. Zwei von drei bis vier von fünf Entscheidungen fielen also anders aus, obwohl sich an der Anwendung nichts geändert hatte.

Beim Kniffel wechselten die meisten geänderten Entscheidungen von einer nicht optimalen Option zu einer anderen nicht optimalen. Anders heißt hier also nicht automatisch besser.

Auch die Wahrscheinlichkeiten selbst verschoben sich deutlich: Die größte Änderung einer einzelnen Optionswahrscheinlichkeit lag im Median bei 0,15 (Kniffel) und 0,17 (Tic-Tac-Toe). Das neue Release ist insgesamt weniger „spitz“, es verteilt seine Wahrscheinlichkeiten breiter.

Ergebnis 2: Robuster, aber kaum klüger

In einem Punkt ist das neue Release klar besser: Es hängt weit weniger an der Reihenfolge der Optionen. Kehrt man die Liste um, kippte beim alten Release die Wahl in 88 % der Tic-Tac-Toe-Stellungen, beim neuen nur noch in 40 %. Bei den Kniffel-Halteentscheidungen sank der Wert von 94 % auf 64 %.

Die starke Vorliebe für die erste Option ist verschwunden. Stand der beste Tic-Tac-Toe-Zug ganz vorn in der Liste, gewann er beim alten Release in 83 % der Fälle, ganz hinten nur in 6,5 %. Beim neuen Release sind es 20 % vorn und 41 % hinten. Aus der Vorliebe für die erste Option ist eine schwächere Vorliebe für die letzte geworden.

Bei der eigentlichen Kompetenz hat sich dagegen wenig getan:

• Tic-Tac-Toe: 50,2 % optimale Züge statt 48,4 %. Eine zufällige Wahl käme auf 46,8 %.
• Kniffel: 18 % optimale Entscheidungen statt 13 %. Der Unterschied ist bei 114 Entscheidungen statistisch nicht signifikant. Immerhin wurden die schlimmsten Fehler kleiner: Der größte Punktverlust einer einzelnen Entscheidung sank von 54 auf 22 Punkte.
• Brettsymmetrie: Dreht oder spiegelt man das Tic-Tac-Toe-Brett, ändert sich die Wahl beim neuen Release sogar etwas häufiger als beim alten. Robustheit gegen das eine überträgt sich nicht auf das andere.

Das neue Release ist also in einer Eigenschaft deutlich besser und in den anderen ähnlich gut oder schlecht. Das ist kein Urteil über das Modell. Es zeigt nur: Was „besser“ heißt, muss man für den eigenen Anwendungsfall messen. Annehmen reicht nicht.

Ergebnis 3: Schwellen verschieben sich

Viele Prozesse arbeiten mit einer Schwelle: Ist sich das Modell sicher genug, wird automatisch ausgeführt, sonst prüft ein Mensch. Genau diese Grenze verschiebt ein Modell-Update.

Bei einer unveränderten Schwelle von 0,5 auf die Wahrscheinlichkeit der gewählten Option wären nach dem Update 894 von 4.298 Tic-Tac-Toe-Entscheidungen von „automatisch“ in die Prüfung gewandert, 89 in die Gegenrichtung. Bei 0,6 wären es 713 und 140.

Für den Betrieb heißt das: Ohne eine Zeile Code zu ändern, landet plötzlich ein Fünftel mehr Arbeit in der Prüfwarteschlange. Bei einem Modell, das spitzer wird statt breiter, wäre es umgekehrt gekommen: mehr ungeprüfte Automatik. Beides fällt nur auf, wenn man hinsieht.

Wichtig ist dabei ein Detail, das oft übersehen wird: Die Wahrscheinlichkeit, die ein Modell für seine Wahl ausgibt, ist nicht die Wahrscheinlichkeit, dass diese Wahl richtig ist. Sie beschreibt, wie sicher sich das Modell ist, nicht, wie oft es recht hat.

Was Sie daraus machen sollten

Das Experiment ist mit einem kleinen Entscheidungsmodell und zwei Spielen bewusst überschaubar. Der Mechanismus dahinter gilt aber für jedes Modell, das hinter einer gleichbleibenden Schnittstelle ausgetauscht wird. Deshalb unsere Empfehlungen:

1. Modellversion festschreiben. Nutzen Sie eine feste Version oder Revision statt „latest“, wo der Anbieter das erlaubt. Updates spielen Sie dann bewusst ein, nicht nebenbei.
2. Eingaben und Ausgaben speichern. Die echten Anfragen Ihres Prozesses sind Ihr bester Testdatensatz. Speichern Sie sie datenschutzgerecht, zusammen mit der Antwort und der Modellversion.
3. Vor dem Wechsel vergleichen. Schicken Sie die gespeicherten Anfragen an das neue Modell und vergleichen Sie: Wie viele Entscheidungen ändern sich? Wo es eine richtige Antwort gibt, werden sie besser oder schlechter? Was passiert an Ihren Schwellen?
4. Schwellen neu einstellen. Eine Schwelle gehört zu einem Modell, nicht zu einem Prozess. Nach dem Wechsel wird sie neu kalibriert.
5. Einen Rückweg behalten. Das alte Modell sollte sich zurückholen lassen, bis das neue sich bewährt hat.
6. Exakte Aufgaben nicht dem Modell überlassen. Wo es eine eindeutige Lösung gibt, also eine Regel, eine Berechnung oder einen Solver, entscheidet besser der Algorithmus. Dann kann ein Modell-Update dort auch nichts verschieben.

Und mit Augenmaß: Das gilt vor allem für Entscheidungen, die etwas auslösen, also buchen, freigeben, sortieren oder weiterleiten. Für einen Textvorschlag, den ohnehin ein Mensch liest, reicht weniger Aufwand.

Checkliste: Modell-Update im Prozess

1. Ist die Modellversion festgeschrieben?
2. Werden Eingaben, Ausgaben und Modellversion gespeichert?
3. Gibt es vor jedem Wechsel einen Vergleich mit gespeicherten Anfragen?
4. Werden Schwellen nach dem Wechsel neu eingestellt?
5. Gibt es für wichtige Entscheidungen eine Wahrheit zum Vergleich (Regel, Solver, Stichprobe durch Menschen)?
6. Lässt sich das alte Modell zurückholen?

Häufige Fragen

Wird ein neues Modell-Release nicht einfach besser? Es kann besser werden, muss aber nicht, und schon gar nicht überall. In unserem Versuch wurde das neue Release deutlich robuster gegen die Reihenfolge der Optionen, kaum kompetenter, und es traf die meisten Einzelentscheidungen anders.

Gilt das auch für große Sprachmodelle? Gemessen haben wir es an einem kleinen Entscheidungsmodell. Der Mechanismus ist derselbe: Ein neues Modell hinter derselben Schnittstelle bringt neues Verhalten mit. Wie groß die Unterschiede bei einem bestimmten Modell sind, zeigt nur ein eigener Vergleich.

Wie aufwendig ist so ein Vergleichstest? Weniger, als man denkt. Unser Lauf mit 21.636 Anfragen dauerte 15,2 Stunden auf einer CPU, ohne Grafikkarte. Wer seine Anfragen ohnehin speichert, hat den Testdatensatz schon.

Was ist der Unterschied zwischen API-kompatibel und verhaltenskompatibel? API-kompatibel heißt: Ihr Code funktioniert weiter. Verhaltenskompatibel hieße: Das Modell trifft dieselben Entscheidungen. Das Erste sagt nichts über das Zweite.

Fazit

Ein Modell-Update ohne Codeänderung ist kein kleines Update. In unserem Versuch blieb die Schnittstelle gleich, der Code auch, und trotzdem fielen die meisten Entscheidungen anders aus. Das neue Release war in einem Punkt klar besser, in anderen nicht, und es verschob die Grenze zwischen Automatik und menschlicher Prüfung.

Wer KI-Modelle in Prozesse einbindet, sollte sie deshalb behandeln wie jede andere Abhängigkeit: Version festschreiben, vor dem Update testen, Rückweg behalten.

Sie möchten KI-Modelle so in Ihre Abläufe einbinden, dass ein Update Sie nicht überrascht? Mehr zu KI-Agenten für Unternehmen – oder sprechen Sie uns direkt an.

Quellen: Hugging Face – Strands Decider 2B (Version 19) · Hugging Face – Strands Decider 2B (v1-2610)