Modell-Drift und die Stille Migration

Wer ein KI-System über Monate betreibt, erlebt einen schleichenden Wandel. Nicht im eigenen Code, nicht in den eigenen Daten, sondern im Modell des Providers. Eine neue Generation wird ausgerollt, die alte wird abgeschaltet, und das Verhalten des Systems ändert sich, ohne dass jemand eine Commit-Message geschrieben hat. Wer die ökonomische Seite dieses Themas noch nicht kennt, findet in Die wahren Kosten eines Tokens eine Bestandsaufnahme der Posten, die in klassischen KI-Budgets auftauchen.

Auf den Punkt

Wer die nächsten fünf Minuten nicht hat: Modell-Drift ist die unsichtbarste Quelle von Qualitätsverlust in KI-Workflows. Wer seine Anwendung nicht aktiv überwacht, merkt den Drift erst, wenn ein User sich beschwert oder eine regulatorische Anfrage kommt. Die Lösung kostet ein bis zwei Tage Implementierung und eine Stunde Wartung pro Woche, mehr nicht.

Glossar

Begriff

Distribution Shift

Bedeutung

Die schleichende Verschiebung zwischen der Datenverteilung, mit der ein Modell trainiert wurde, und der Verteilung, in der es heute eingesetzt wird. Wer ein KI-System über Monate betreibt, erlebt diesen Drift regelmäßig, oft unbemerkt, bis ein Output auffällt.

Begriff

Silent Migration

Bedeutung

Der Vorgang, dass ein KI-Provider sein Modell im Hintergrund aktualisiert, ohne den Kunden explizit zu informieren. Wer keine Modell-Pinning-Strategie hat, ist diesem Migrationsrisiko ausgeliefert.

Begriff

Golden Set

Bedeutung

Eine kuratierte Sammlung von Test-Anfragen mit bekannten, erwarteten Antworten, die regelmäßig gegen das Produktionsmodell laufen. Wenn die Antworten abdriften, hat sich das Modell verändert.

Begriff

Model Pinning

Bedeutung

Die Praxis, eine spezifische Modellversion explizit zu referenzieren (z. B. claude-3-5-sonnet-20240620) statt einer moving-target-Version (claude-3-5-sonnet-latest). Verhindert Silent Migration, erfordert aber bewusste Upgrades.

Wie Modell-Drift entsteht

Wer ein KI-System betreibt, geht eine implizite Wette ein: dass das Modell, das heute antwortet, morgen noch dasselbe antwortet. In neun von zehn Fällen geht die Wette auf, im zehnten Fall sieht das System am Montag anders aus als am Freitag.

Drei Mechanismen, durch die Drift entsteht.

Major Release. Der Provider veröffentlicht eine neue Generation. In den meisten Fällen ist sie besser, manchmal in einer Weise, die das eigene System bricht. Wer "das aktuelle Modell" verwendet, ohne die Version zu pinnen, bekommt das neue Modell am Tag des Releases.

Minor Update. Der Provider veröffentlicht ein Update innerhalb einer Generation. Diese Updates sind oft klein, können aber in einer Domäne, in der das System arbeitet, deutlich spürbar sein. Wer keinen Golden Set hat, merkt das nicht.

Deprecation. Der Provider stellt das alte Modell ab. Wer das Modell nicht gepinnt hat und es nicht aktiv überwacht, stellt eines Morgens fest, dass die Anwendung anders antwortet, ohne dass jemand etwas geändert hat.

Wie sich Drift zeigt

Modell-Drift zeigt sich nicht immer als offensichtlicher Fehler. Häufiger sind subtile Verschiebungen, die über Wochen passieren und erst im Aggregat sichtbar werden. Wer darauf wartet, dass ein User sich beschwert, hat den Drift schon drei Monate lang übersehen.

Vier typische Symptome:

Ton-Verschiebung. Das Modell antwortet knapper, formeller, weniger freundlich, oder umgekehrt. Wer keine Ton-Anker in seinem Golden Set hat, sieht das nicht.

Format-Drift. Das Modell fängt an, JSON-Properties anders zu schreiben, Markdown-Formatierung subtil zu verändern, oder Whitespace anders zu setzen. Wer keinen Parser mit strenger Validierung hat, sieht das nicht.

Inhalts-Drift. Das Modell gibt andere Antworten auf dieselben Fragen, ohne dass es offensichtlich falsch wird. Wer keine Ground Truth hat, kann das nicht quantifizieren.

Performance-Drift. Das Modell wird langsamer, teurer, oder gibt weniger Antworten pro Token. Wer keine Metriken trackt, sieht das nur, wenn die Cloud-Rechnung explodiert.

Die Drei-Fragen-Diagnostik

Wer vermutet, dass Drift in seinem System eine Rolle spielt, kann mit drei Fragen anfangen.

Sind die Antworten noch dieselben? Wer einen Golden Set hat, kann diese Frage objektiv beantworten. Wer keinen hat, kann sie nur über User-Feedback beantworten, und das kommt zu spät.

Wann hat sich das Verhalten zuletzt geändert? Wer ein Audit-Log mit Modell-Version und Antwort-Hash hat, kann diese Frage in Minuten beantworten. Wer Logs nur für die letzten 30 Tage hat und die Antwort-Hashes nie gespeichert hat, kann sie nicht beantworten.

Wer hat das Modell zuletzt gewechselt? In den meisten Unternehmen ist die Antwort "niemand absichtlich", was die Frage noch dringlicher macht. Wer ein unkontrolliertes Modell verwendet, hat eine unausgesprochene Abhängigkeit von der Lieferanten-Roadmap.

Modell-Drift erkennen, bevor er teuer wird

Drei Praktiken, die zusammen funktionieren.

Golden Set mit Antwort-Hashes. Ein Set von 50 bis 200 repräsentativen Anfragen, jede mit einer erwarteten Antwort oder einem Antwort-Hash (z. B. Hash der ersten 200 Zeichen). Regelmäßig gegen das Produktionsmodell laufen, Abweichungen loggen. Wer das Daily gegen das eigene System laufen lässt, sieht Drift, bevor er einen User erreicht.

Modell-Pinning als Gegenmassnahme

Drift ist nicht immer schlecht. Es gibt Situationen, in denen eine unbeabsichtigte Modell-Aktualisierung das eigene System besser macht, ohne dass jemand etwas tun musste. Wer seinen Code eng an eine spezifische Modellversion schreibt, verschenkt diese Chance.

Drei Situationen, in denen Drift ein Geschenk ist:

Kostensenkung. Ein Provider reduziert die Token-Preise. Wer sein Modell gepinnt hat, zahlt weiter den alten Preis. Wer das Modell frei laufen lässt, bekommt die Reduktion automatisch.

Qualitätssteigerung. Ein Provider veröffentlicht eine verbesserte Modellversion. Wer sein Modell gepinnt hat, sieht die Verbesserung erst nach manuellem Upgrade. Wer das Modell frei laufen lässt, bekommt die Verbesserung sofort.

Neue Fähigkeiten. Ein Provider fügt eine neue Funktion hinzu, etwa Vision oder Function Calling. Wer das Modell gepinnt hat, muss manuell upgraden. Wer das Modell frei laufen lässt, bekommt die Funktion sofort.

Die Frage ist also nicht "pinnen oder nicht pinnen", sondern "welche Strategie passt zur eigenen Risikobereitschaft". Wer Sicherheit will, pinnt. Wer Beweglichkeit will, lässt es frei. Wer beides will, pinnt mit automatisiertem Upgrade-Test.

Modell-Pinning mit Eskalationsverfahren. Eine spezifische Modellversion in der Konfiguration festhalten. Bei Major Releases explizit upgraden, mit Golden Set im Test-Staging. Nie "latest" verwenden.

Quality-Dashboard mit Alert. Eine Sicht auf die Golden-Set-Ergebnisse über Zeit, mit Alert, wenn die Pass-Rate unter 95 Prozent fällt. Wer das hat, bemerkt Drift, bevor er die User erreicht.

Diese Praktiken sind nicht aufwendig. Sie kosten ein bis zwei Tage Implementierung und eine Stunde Wartung pro Woche. Wer sie nicht hat, zahlt den Preis in Incident-Stunden, die um eine Größenordnung teurer sind.

Konkret: ein Setup, das in einem Tag steht

Wer morgen anfangen will, kann mit folgendem Setup beginnen. Es ist nicht perfekt, aber es ist besser als der Status quo der meisten Teams.

Schritt 1: Golden Set kuratieren. 50 Anfragen aus der Produktion der letzten 30 Tage auswählen, jede mit ihrer erwarteten Antwort oder einem Hash. In einer JSON-Datei versionieren.

Schritt 2: Tägliche Ausführung. Ein Cron-Job oder GitHub Action, der das Golden Set gegen das Produktionsmodell laufen lässt und die Ergebnisse in einer Datei oder Datenbank ablegt. Dauer: zehn Minuten pro Lauf, abhängig vom Modell.

Schritt 3: Dashboard. Eine einfache HTML-Seite, die die Pass-Rate der letzten 30 Tage zeigt, mit roten Markierungen bei Tagen unter 95 Prozent. Oder ein Alert in Slack.

Schritt 4: Modell-Pinning. In der Konfiguration die spezifische Modellversion festhalten. Nicht "latest", sondern "claude-3-5-sonnet-20240620" oder was auch immer das aktuelle gewählte Modell ist. Bei einem geplanten Upgrade: Golden Set vorher ausführen, Modell wechseln, Golden Set nachher ausführen.

Wer das hat, ist in einer deutlich besseren Position als 90 Prozent der Teams, die KI in Produktion betreiben.

Eine kleine Geschichte aus der Praxis

Im Frühjahr 2025 hatten wir ein KI-System in Produktion, das JSON-Responses für ein internes Dashboard generierte. Das System lief seit sechs Monaten stabil. Eines Morgens stellten wir fest, dass das Dashboard plötzlich leere Felder zeigte. Investigation: das Modell hatte ein Update bekommen, und es antwortete jetzt mit einer leicht anderen JSON-Struktur, die der Parser nicht mehr verstand. Der Fix dauerte vier Stunden. Die Behebung der Daten, die in der Zwischenzeit verloren gegangen waren, dauerte zwei Wochen.

Der Fix nach dem Drift war einfach: Golden Set aufgesetzt, Modell gepinnt, Parser an die neue Struktur angepasst. Was wir daraus gelernt haben: jede Stunde, die wir vorher in Drift-Erkennung investiert hätten, hätte uns dreißig Stunden nach dem Drift gespart.

Die Lektion ist nicht "richte mehr Monitoring ein". Die Lektion ist: Drift ist eine Dauererscheinung, die genau dann teuer wird, wenn man nicht hinschaut. Wer hinschaut, hat ein kontinuierliches kleines Problem. Wer nicht hinschaut, hat alle paar Monate eine mittlere Katastrophe.

Weiterführend

• NIST AI Risk Management Framework (NIST), die umfassendste öffentliche Sammlung von Praktiken zur KI-Qualitätssicherung. Wer seinen Drift-Prozess ernst nimmt, findet hier die Vorlage.
• Machine learning model monitoring: Best practices (Datadog Engineering Blog), eine praxisorientierte Einführung in das Monitoring von Modellverhalten, geschrieben für Engineering-Teams, die nicht aus dem ML-Bereich kommen.
• Claude Model Deprecations (Anthropic), die offizielle Dokumentation, wie Anthropic Modell-Upgrades handhabt. Lesenswert, um zu verstehen, was die andere Seite der API ankündigt, bevor sie passiert.