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 Modellversion, 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. Die Gesamtgenauigkeit stieg, und das war der einfache Teil. Allerdings leitete das Modell manche Nachrichten seltener an das Portal für Ärztinnen und Ärzte weiter, kürzte die Zusammenfassungen, die sie lesen, 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 auf. In einem Gesundheitsprodukt liegt das Risiko genau in diesen Einzelfällen.

Die Abhängigkeit von einem Modell wird weniger durch den Vertrag oder die API des Anbieters bestimmt als dadurch, ob Ihnen eine Sammlung echter, gelabelter Fälle gehört, mit der sich ein Nachfolger in wenigen Tagen qualifizieren lässt. Ohne eine solche Sammlung bleibt ein Workflow meist beim bisherigen Modell, bis das Abkündigungsdatum einen überhasteten Wechsel erzwingt.

Jedes gehostete Modell hat ein Ablaufdatum, ob es schon angekündigt ist oder nicht. Anthropic schreibt in „Commitments on model deprecation and preservation“ (November 2025), dass die Abkündigung älterer Modelle derzeit notwendig ist, um neue Modelle verfügbar zu machen, und verpflichtet sich, die Gewichte aller öffentlich veröffentlichten Modelle aufzubewahren. Aufbewahrte Gewichte bedeuten keinen weiteren Zugang. Wer einen Workflow auf einem Modell aufbaut, verbaut eine Komponente mit begrenzter Lebensdauer. Die Architektur muss deshalb den Austausch einplanen.

Das ganze Paket festlegen, nie einen Alias

Die meisten Anbieter bieten Aliasse an, die auf die jeweils neueste Version einer Modellfamilie verweisen. In der Entwicklung ist das bequem, im Produktivbetrieb gefährlich, denn das Modell hinter dem Alias kann wechseln, ohne dass Sie irgendetwas geändert haben. Der Workflow, der im letzten Monat den Abnahmelauf bestanden hat, läuft heute womöglich auf einem anderen Modell.

Ein produktiver Workflow verweist auf eine exakte, datierte Modellversion. Sie wird zusammen mit allem festgelegt, was auf sie abgestimmt wurde: dem Prompt, dem Ausgabeschema, den Decoding-Einstellungen und jedem Schwellenwert, der Fälle weiterleitet. Dieses Paket ist ein Release, wird in dessen Nachweisen dokumentiert und nur über ein neues Release geändert. Ein Rollback stellt das ganze Paket wieder her, nicht nur den Modellnamen. Ein altes Modell unter einem neuen Prompt ist eine dritte Konfiguration, die niemand getestet hat.

Das Festlegen hat seinen Preis. Ein fest vorgegebenes Modell erhält keine späteren Korrekturen des Anbieters, der Workflow tauscht also unbemerkte Drift gegen bekannte Veralterung. Für alles, was eine Ärztin, einen Arzt oder eine Nutzerin erreicht, lohnt sich dieser Tausch, und die Festlegung wird geprüft, sobald der Anbieter eine Korrektur veröffentlicht, die die Aufgabe betrifft. Bei einem internen Entwurf, den ein Mensch ohnehin umschreibt, wären wir weniger streng.

Bietet ein Anbieter keine fest adressierbaren Versionen mit ausreichender Vorlaufzeit vor der Abkündigung, betreiben wir dort keinen folgenreichen Workflow. Yan, Bischof, Frye, Husain, Liu und Shankar raten in „What We Learned from a Year of Building with LLMs“ (O'Reilly, Mai 2024) ebenfalls, Modellversionen in Produktion festzulegen, und führen ein Team an, dessen Intent-Klassifizierung beim Wechsel zwischen zwei Versionen desselben Modells um rund 10 % schlechter wurde. Die Regel ist nicht neu. Schwieriger ist, die darauf folgende Abkündigung als geplantes Ereignis mit Termin und Budget zu behandeln.

Eine schlanke Schnittstelle macht das Modell austauschbar

Der Workflow spricht nie direkt mit einem Modell, sondern mit einer kleinen Schnittstelle je Aufgabe: diese Nachricht für das Ärzteportal zusammenfassen, diese Nachricht einem dieser Wege zuordnen. Jede Schnittstelle hat ein festes Ein- und Ausgabeschema, gegen das jede Antwort validiert wird. Hinter der Schnittstelle liegen das Modell, sein Prompt und seine Einstellungen.

Der Rest des Systems weiß nicht, welches Modell gerade arbeitet. Ein Wechsel ist eine Änderung hinter einer einzigen Schnittstelle, getestet mit deren Fällen, und zwei Modelle können parallel mit denselben Eingaben laufen. Genau so wird ein Nachfolger qualifiziert, bevor er echte Arbeit übernimmt.

Die Qualifizierung vergleicht Fehlerprofile und Abweichungen

Ein Kandidat läuft zuerst auf dem vollständigen Abnahmedatensatz und danach auf einer aktuellen Stichprobe von Produktivfällen mit bekanntem Ergebnis. Die Gesamtgenauigkeit ist dabei das am wenigsten aufschlussreiche Ergebnis. Zwei Zahlen zählen mehr.

Die erste ist das Fehlerprofil: welche Fälle das alte Modell richtig und das neue falsch löst, und welche Felder und Segmente betroffen sind. Ein Nachfolger, der insgesamt besser ist, aber neuerdings bei Nachrichten in einer Sprache oder bei Nachrichten, die eine Ärztin oder einen Arzt erreichen sollten, falsch liegt, geht nicht live, bis diese Fälle abgedeckt sind, durch eine Prompt-Änderung, eine Validierungsregel oder einen engeren Umfang.

Die zweite ist die Abweichungsquote: der Anteil der Fälle, in denen das neue Modell eine andere Antwort gibt als das alte, egal ob eine davon richtig ist. Die Genauigkeit kann steigen, während die Abweichungsquote hoch ist, weil das neue Modell einige alte Fehler behebt und an anderer Stelle neue macht. Die Abweichungen sind das, was die Menschen im Workflow spüren. Wer als Ärztin oder Arzt gelernt hat, welche Arten von Nachrichten das System schlecht zusammenfasst, stellt fest, dass sich diese Liste unbemerkt verändert hat, und die eigene Erfahrung ist plötzlich weniger wert. Eine hohe Abweichungsquote bedeutet einen längeren Shadow-Betrieb und eine Einweisung für die Prüfenden, selbst wenn die Genauigkeitskurve nach einer guten Nachricht aussieht.

Die Menge der Abweichungen macht die Prüfung außerdem bezahlbar. Nur Fälle, in denen sich die beiden Modelle unterscheiden, brauchen einen Menschen. Die klinische Leitung prüft also die Unterschiede, nach Art gruppiert, statt des ganzen Datensatzes, und gibt den Wechsel frei, so wie sie den ursprünglichen Go-live freigegeben hat.

Schwellenwerte lassen sich nicht übertragen

Jeder Schwellenwert im Workflow wurde am Verhalten des alten Modells ausgerichtet: der Wert, unter dem eine Nachricht an eine Ärztin oder einen Arzt geht, die Ähnlichkeit, ab der zwei Nachrichten als dieselbe Frage gelten. Ein neues Modell verteilt diese Werte anders. Ein unverändert übernommener Schwellenwert ist eine neue, ungetestete Regel mit einer alten Zahl. Deshalb wird jeder Schwellenwert auf den Qualifizierungsfällen neu kalibriert, und die Neukalibrierung ist Teil der Änderung, die die klinische Leitung freigibt.

Jeder extrahierte Wert zeigt auf seine Quelle

Der gefährlichste Unterschied an jenem Nachmittag war weder die Weiterleitung noch die kürzeren Zusammenfassungen. Beides fängt der Abnahmedatensatz ab, weil es sich als Abweichung von bekannten Antworten zeigt. Gefährlich war das geratene Detail. Ein plausibel erfundener Wert besteht jede Formatprüfung, schon von der Anlage her.

Deshalb muss jeder Wert, den ein Modell ausliest, angeben, wo er in der Originalnachricht steht: die genaue Textstelle. Die Validierungsschicht prüft, ob der Wert tatsächlich dort steht. Ein Wert ohne Fundstelle gilt als fehlend, nicht als gefunden. Diese Prüfung hängt nicht davon ab, welches Modell im Einsatz ist, und gerade deshalb ist sie beim Modellwechsel so wichtig. Sie macht aus dem kreativen Lückenfüllen eines neuen Modells eine gewöhnliche, sichtbare Ausnahme.

Nachfolger laufen zuerst im Shadow-Betrieb

Nach der Qualifizierung läuft der Kandidat im Shadow-Betrieb mit echten Daten, lange genug, um die übliche Bandbreite an Nachrichten zu sehen. Er bekommt dieselben Eingaben wie das Produktivmodell, seine Ausgaben werden Feld für Feld verglichen, und nichts davon erreicht eine Nutzerin oder das Ärzteportal. Der Shadow-Betrieb misst außerdem die Kosten je abgeschlossenem Fall bei realem Volumen, und ein neues Modell kann sie in beide Richtungen verschieben: ein anderer Preis pro Token, eine andere Tokenzahl für denselben Prompt, ein anderer Anteil an Fällen, die einen zweiten Durchlauf brauchen.

Vom Abkündigungsdatum rückwärts rechnen

Das Abkündigungsdatum ist nicht die Frist. Die Frist ist der späteste Tag, an dem die Qualifizierung beginnen kann und trotzdem sicher fertig wird. Rechnen Sie rückwärts: das Abkündigungsdatum, minus die Freigabe, minus einen Shadow-Betrieb, der lang genug ist, um die übliche Bandbreite an Fällen zu sehen, minus die Qualifizierung und die Arbeit an den Prompts. Bei einem Produkt wie dem Begleiter liegt der tatsächliche Starttermin dann oft nur wenige Wochen nach dem Eingang der E-Mail des Anbieters. Die Übergabe hält diese Rechnung fest, damit das Team des Kunden sie nicht erst einen Monat vor Schluss entdeckt.

Eine Abkündigung ist auch der günstigste Moment für die Frage, ob die Aufgabe das bisherige Modell überhaupt noch braucht. Qualifiziert werden muss der Workflow ohnehin. Manchmal besteht ein kleineres Modell dieselben Fälle zu geringeren Kosten je Fall. Manchmal lässt sich ein Schritt, den das Modell erledigt hat, inzwischen mit deterministischem Code erledigen, weil Informationen, die früher als Freitext kamen, heute in strukturierter Form ankommen. Der Nachfolger ist selten nur ein gleichwertiger Ersatz.

Ein besseres Modell ist eine riskantere Migration

Der Nachfolger, der am besten aussieht, verdient die genaueste Beobachtung. Ist ein neues Modell klar stärker, lassen die Prüfenden nach, Stichproben werden seltener, und der Sponsor will den Wechsel schnell erledigt haben, alles genau in dem Moment, in dem die Fehler an Stellen gewandert sind, an denen noch niemand hinzusehen gelernt hat. Ein schwacher Nachfolger fällt in der Qualifizierung durch und wird verbessert. Ein starker besteht, und seine wenigen neuen Fehler landen in Segmenten, in denen 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, nicht weniger, gezielt in den Segmenten mit der höchsten Abweichungsquote.

Der Abnahmedatensatz altert schneller als das Modell

Ein Abnahmedatensatz, der zum Go-live aufgebaut wurde, beschreibt die Menschen, Dokumente und Fragen jenes Jahres. Zwei Jahre später ist ein Teil des Geschäfts, das er beschreibt, verschwunden, und neue Teile sind hinzugekommen. Ein Nachfolger, der einen alten Datensatz besteht, wurde für ein Unternehmen qualifiziert, das es in dieser Form nicht mehr gibt. Der Datensatz wird deshalb laufend aus dem Produktivbetrieb erneuert: Jeder Fall, den ein Mensch korrigiert hat, wird zum Kandidaten, und jedes Quartal ergänzen die Verantwortlichen aktuelle Fälle und nehmen solche heraus, die nicht mehr vorkommen. Ein Datensatz, der sich ein Jahr lang nicht verändert hat, wiegt genau dann in falscher Sicherheit, wenn er gebraucht wird.

Was ein Wechsel kostet, bestimmt der Abnahmedatensatz

Bei einem Modell sind Vertrag und API der günstige Teil der Abhängigkeit, und mit der Schnittstelle ist der Austausch eine kleine Code-Änderung. Teuer sind der Qualifizierungslauf, die Prüfung der Unterschiede, die Neukalibrierung, die Anpassungen der Prompts und die Freigabe, und all das stützt sich auf eine Sammlung echter, gelabelter Fälle, der der Kunde vertraut. Mit einem gut gepflegten Datensatz ist ein Wechsel eine Sache von Tagen. Ohne ihn wird daraus ein kleines Projekt, das immer wieder verschoben wird, und so sieht Abhängigkeit im Alltag aus. Eine Abstraktionsschicht über mehrere Anbieter trägt weniger zur Unabhängigkeit eines Unternehmens bei als dieser Datensatz, aktuell gehalten und mit benannten Verantwortlichen.

Der Ausstieg gehört zur Übergabe

Die erneute Qualifizierung ist ein Posten in den laufenden Kosten des Workflows, mindestens einmal im Jahr eingeplant, und das Team des Kunden führt sie ohne uns durch. Die Übergabe nennt alle Modelle, auf denen der Workflow qualifiziert wurde, nicht nur das eingesetzte. Wo die Hosting-Vorgaben es zulassen, ist eines davon ein Open-Weight-Modell, das der Kunde auf eigener Infrastruktur betreiben kann. So gibt es immer einen Weg, der nicht von der Roadmap eines einzelnen Anbieters abhängt. Die Übergabe dokumentiert außerdem die Ankündigungsfrist des Anbieters und die oben beschriebene Rückwärtsrechnung. Und die Qualifizierung wird während der Übergabe einmal mit einem echten Kandidaten durchgespielt, solange die Entwickler noch da sind.

Zwei Dinge lehnen wir ab. Erstens ein Upgrade, nur weil sich öffentliche Benchmarks verbessert haben, denn darin kommt keiner der eigenen Fälle, keine der Sprachen und keines der Layouts des Kunden vor. Zweitens das Fine-Tuning eines gehosteten Modells, es sei denn, der Kunde nimmt in Kauf, dass das Fine-Tuning zusammen mit dem Basismodell abgekündigt wird.

Ein planbarer Wartungsschritt

Das Modell, mit dem ein Workflow startet, ist selten das, mit dem er endet, und was hinüberträgt, ist der Abnahmedatensatz. Wenn die nächste Abkündigungs-E-Mail kommt, rechnen Sie auf den spätesten sicheren Starttermin zurück und tragen Sie ihn in den Kalender ein.