Wenn das Modell abgekündigt wird: Ihre Abhängigkeit steckt im Testdatensatz

Die klinische Leiterin eines KI-Gesundheitsbegleiters für Frauen in den Wechseljahren, den wir betreiben, leitete uns die E-Mail mit einer Zeile weiter: Können wir einfach umstellen? Darin kündigte unser Modellanbieter an, dass die Version, auf der der Begleiter lief, in wenigen Monaten zu einem festen Termin abgeschaltet wird. Der empfohlene Nachfolger war neuer, schneller und in allen veröffentlichten Benchmarks besser.

Noch am selben Nachmittag ließen wir den Nachfolger gegen den Abnahmedatensatz des Begleiters laufen: echte Nachrichten, bei denen wir die richtige Antwort bereits kennen. Die Gesamtgenauigkeit stieg. Aber das neue Modell leitete manche Nachrichten seltener an das Portal für Ärztinnen und Ärzte weiter, kürzte die Zusammenfassungen, sodass Details wegfielen, auf die sie sich verließen, und füllte ein fehlendes Detail in der Nachricht einer Nutzerin bereitwilliger mit einer plausiblen Vermutung. In einem Gesundheitsprodukt liegt genau dort das Risiko.

Die Abhängigkeit von einem Modell hat also weniger mit dem Vertrag des Anbieters zu tun als mit einer Frage: Gehört Ihnen eine Sammlung echter, geprüfter Fälle, mit der sich ein Nachfolger in wenigen Tagen testen lässt? Ohne sie bleibt ein Arbeitsablauf, wo er ist, bis das Abschaltdatum einen überhasteten Wechsel erzwingt.

Jedes gehostete Modell hat ein Ablaufdatum. Anthropic schreibt in „Commitments on model deprecation and preservation“ (November 2025), dass die Abkündigung älterer Modelle derzeit notwendig ist, um neue verfügbar zu machen, und verpflichtet sich, die Gewichte aller öffentlich veröffentlichten Modelle aufzubewahren. Aufbewahrte Gewichte bedeuten keinen weiteren Zugang.

Die genaue Version festlegen, samt allem, was darauf abgestimmt ist

Anbieter bieten einen allgemeinen Namen an, der immer auf ihr neuestes Modell zeigt. Im Alltag ist das gefährlich: Das Modell dahinter kann wechseln, ohne dass Sie etwas geändert haben. Ein laufender Arbeitsablauf nennt eine genaue, datierte Version und legt sie fest, zusammen mit allem, was darauf abgestimmt wurde: den Anweisungen, dem erwarteten Ausgabeformat, den Einstellungen und jedem Grenzwert, der entscheidet, wohin ein Fall geht. Dieses Paket ändert sich nur als Ganzes, und ein Zurückrollen stellt alles wieder her: Ein altes Modell unter neuen Anweisungen ist eine Kombination, die niemand getestet hat.

Der Preis: Ein festgelegtes Modell erhält keine späteren Verbesserungen des Anbieters. Für alles, was eine Ärztin oder eine Nutzerin erreicht, lohnt sich dieser Tausch. Ein Anbieter, der keine festen Versionen mit Vorlaufzeit vor der Abschaltung anbietet, bekommt keine folgenreiche Arbeit. Yan, Bischof, Frye, Husain, Liu und Shankar raten in „What We Learned from a Year of Building with LLMs“ (O'Reilly, Mai 2024) dasselbe und führen ein Team an, dessen Intent-Klassifizierung beim Wechsel zwischen zwei Versionen desselben Modells um rund 10 % schlechter wurde.

Das Modell austauschbar halten

Der Arbeitsablauf spricht nie direkt mit einem Modell, sondern mit einer kleinen, festen Verbindung je Aufgabe, etwa „diese Nachricht für das Ärzteportal zusammenfassen“, mit fester Ein- und Ausgabe, gegen die jede Antwort geprüft wird. Sonst weiß niemand, welches Modell arbeitet. Ein Wechsel ist also eine Änderung an einer Stelle, und zwei Modelle können parallel laufen.

Einen Nachfolger daran messen, was er neu falsch macht

Ein Kandidat läuft auf dem Abnahmedatensatz, dann auf aktuellen echten Fällen mit bekanntem Ergebnis. Die Gesamtnote zählt am wenigsten; zwei Dinge zählen mehr.

Erstens: welche Fälle das alte Modell richtig und das neue falsch löst, und wo sie liegen. Ein Nachfolger, der insgesamt besser ist, aber neuerdings bei Nachrichten in einer Sprache oder bei Nachrichten für eine Ärztin falsch liegt, geht nicht live, bis diese Fälle gelöst sind.

Zweitens: wie oft das neue Modell anders antwortet als das alte, ob richtig oder falsch. Die Genauigkeit kann steigen, während sich viele Antworten ändern, weil das neue Modell alte Fehler behebt und anderswo neue macht. Eine Ärztin, die gelernt hat, welche Nachrichten das System schlecht zusammenfasst, merkt, dass sich diese Liste still verändert hat. Viele geänderte Antworten bedeuten einen längeren Probelauf und eine Einweisung für die Prüfenden.

Nur Fälle, in denen die beiden Modelle sich unterscheiden, brauchen einen Menschen. Die klinische Leitung prüft diese Unterschiede, nach Art gruppiert, und gibt den Wechsel frei, so wie sie den ursprünglichen Start freigegeben hat.

Grenzwerte lassen sich nicht übertragen

Jeder Grenzwert, etwa der Wert, unter dem eine Nachricht an eine Ärztin geht, wurde am alten Modell eingestellt. Ein neues Modell verteilt seine Werte anders. Deshalb wird jeder Grenzwert an den Testfällen neu gesetzt, und auch das gibt die klinische Leitung frei.

Jeder Wert zeigt auf seine Quelle

Der gefährlichste Unterschied an jenem Nachmittag war das geratene Detail, denn ein plausibel erfundener Wert besteht jede Formatprüfung. Deshalb muss jeder Wert, den ein Modell ausliest, auf die genaue Textstelle in der Nachricht zeigen, und das System prüft, ob er dort steht. Ein Wert ohne Fundstelle gilt als fehlend. Die Prüfung funktioniert mit jedem Modell, und so wird das Raten eines neuen Modells zu einer sichtbaren Ausnahme.

Erst parallel laufen lassen und vom Datum rückwärts rechnen

Nach dem Test läuft der Kandidat parallel auf echten Nachrichten, lange genug, um die übliche Bandbreite zu sehen. Seine Antworten werden Feld für Feld verglichen, nichts davon erreicht eine Nutzerin, und er zeigt die echten Kosten je Fall bei vollem Volumen.

Die eigentliche Frist ist der späteste Tag, an dem die Arbeit beginnen und trotzdem sicher fertig werden kann: Abschaltdatum, minus Freigabe, minus Parallelbetrieb, minus Tests. Bei einem Produkt wie dem Begleiter liegt dieser Tag oft nur wenige Wochen nach der E-Mail des Anbieters. Die Übergabe hält die Rechnung fest.

Eine Abschaltung ist auch ein günstiger Moment für die Frage, ob die Aufgabe dieses Modell noch braucht. Manchmal besteht ein kleineres dieselben Fälle günstiger, oder gewöhnlicher Code kann einen Schritt inzwischen übernehmen.

Ein besseres Modell ist ein riskanterer Wechsel

Ist ein neues Modell klar stärker, lassen die Prüfenden nach, und der Sponsor will den Wechsel schnell erledigt haben. Ein schwacher Nachfolger fällt im Test durch und wird verbessert. Ein starker besteht, und seine wenigen neuen Fehler landen dort, wo das alte Modell zuverlässig war und die Prüfung längst aufgehört hatte. Die ersten Wochen nach einem Wechsel bekommen deshalb mehr Prüfung, gezielt bei den Fällen, deren Antworten sich am stärksten geändert haben.

Der Testdatensatz altert schneller als das Modell

Ein Testdatensatz vom Start beschreibt das Geschäft jenes Jahres, und das ändert sich. Deshalb wird er laufend aus der täglichen Arbeit erneuert: Jeder Fall, den ein Mensch korrigiert hat, ist ein Kandidat, und jedes Quartal ergänzen die Verantwortlichen aktuelle Fälle und nehmen solche heraus, die nicht mehr vorkommen.

Mit einem aktuellen Datensatz ist ein Wechsel eine Sache von Tagen. Ohne ihn ist er ein Projekt, das immer wieder verschoben wird: Das ist Abhängigkeit. Eine Schicht, die viele Anbieter anbindet, trägt weniger zur Unabhängigkeit eines Unternehmens bei als dieser Datensatz, aktuell gehalten und mit benannten Verantwortlichen.

Der Ausstieg gehört in die Übergabe

Der erneute Test ist ein Posten in den laufenden Kosten, mindestens einmal im Jahr, und das Team des Kunden führt ihn ohne uns durch. Die Übergabe nennt jedes Modell, das den Test bestanden hat; wo die Hosting-Regeln es erlauben, ist eines davon ein offenes Modell, das der Kunde auf eigenen Servern betreiben kann. Sie hält die Vorlaufzeit des Anbieters und die Rückwärtsrechnung fest. Und der Wechsel wird einmal geprobt, an einem echten Kandidaten, solange die Entwickler noch da sind.

Zwei Dinge lehnen wir ab: ein Upgrade, nur weil öffentliche Benchmarks besser wurden, denn sie enthalten keinen einzigen Fall des Kunden; und das Nachtrainieren eines gehosteten Modells, es sei denn, der Kunde akzeptiert, dass die angepasste Version mit ihrem Basismodell abgeschaltet wird.

Wenn die nächste Abkündigung eintrifft, rechnen Sie zurück bis zum spätesten sicheren Start und tragen Sie diesen Tag in den Kalender ein.