Wenn das Modell abgekündigt wird: feste Versionen, Qualifizierungsläufe und ein Ausstiegsplan

Das Finanzteam leitete uns die E-Mail mit einer Zeile weiter: Können wir einfach umstellen? Darin kündigte der Modellanbieter an, dass die Modellversion, auf der ihr Beleg-Workflow 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 Kunden laufen. Die Gesamtgenauigkeit stieg. Allerdings las das Modell manche europäischen Datumsangaben in anderer Reihenfolge, rundete Beträge bei einer Handvoll Rechnungslayouts anders und füllte eine fehlende Bestellnummer bereitwilliger mit einer plausiblen Vermutung auf. Im Schnitt besser, im Einzelfall anders. In einem Finanz-Workflow steckt das Geld im Einzelfall.

Jedes gehostete Modell hat ein Ablaufdatum, ob es schon angekündigt ist oder nicht. Wer einen Workflow auf einem Modell aufbaut, verbaut eine Komponente mit begrenzter Lebensdauer. Die Architektur muss deshalb fest mit dem Austausch rechnen.

Die exakte Version 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.

Jeder produktive Workflow, den wir bauen, verweist auf eine exakte, datierte Modellversion. Die Version ist Teil des Releases, wird in dessen Nachweisen dokumentiert und nur über ein neues Release geändert. Bietet ein Anbieter keine fest adressierbaren Versionen mit ausreichender Vorlaufzeit vor der Abkündigung, betreiben wir dort keinen folgenreichen Workflow.

Eine schlanke Schnittstelle macht das Modell austauschbar

Der Workflow spricht nie direkt mit einem Modell, sondern mit einer kleinen Schnittstelle je Aufgabe: diese Felder aus diesem Beleg auslesen, dieses Ticket einer dieser Queues 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.

Prompts gehören zu dem Modell, für das sie geschrieben wurden. Formulierungen, Beispiele und Formatvorgaben sind auf das Verhalten dieses Modells abgestimmt. Unverändert übernommen funktionieren sie oft, scheitern aber manchmal auf schwer erkennbare Weise. Ein Prompt wird deshalb zusammen mit dem Modell versioniert, auf dem er qualifiziert wurde, und jeder Modellwechsel schließt eine Prüfung der Prompts ein.

Die Qualifizierung vergleicht Fehler, nicht Kennzahlen

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. Entscheidend ist, wie sich die Fehler verschieben: 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 Datumsangaben aus einem Markt oder bei Gutschriften falsch liegt, geht nicht live, bis diese Fälle abgedeckt sind, durch eine Prompt-Änderung, eine Validierungsregel oder einen engeren Umfang. Der Verantwortliche im Finanzbereich sieht den Vergleich und gibt den Wechsel frei, so wie er den ursprünglichen Go-live freigegeben hat.

Jeder extrahierte Wert zeigt auf seine Quelle

Der gefährlichste Unterschied an jenem Nachmittag war weder die Datumsreihenfolge noch die Rundung. Beides fängt die Validierung ab, weil ein falsches Datum oder ein falscher Betrag meist beim Abgleich mit der Bestellung auffällt. Gefährlich war die erfundene Bestellnummer. Ein plausibel erfundener Wert besteht jede Formatprüfung, schon von der Anlage her.

Deshalb muss jeder Wert, den ein Modell ausliest, angeben, wo er im Originalbeleg steht: Seite und 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, über einen Zeitraum, der einen Monatsabschluss einschließt. Er bekommt dieselben Eingaben wie das Produktivmodell, seine Ausgaben werden Feld für Feld verglichen, und nichts davon gelangt ins ERP. Die Unterschiede werden nach Feld und Segment gruppiert. So prüft der Verantwortliche im Finanzbereich eine kurze Liste von Abweichungsarten und nicht Tausende einzelner Fälle.

Der Shadow-Betrieb misst außerdem die Kosten je abgeschlossenem Fall bei realem Volumen. 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.

Was ein Wechsel kostet, bestimmt der Abnahmedatensatz

Bei Anbieterabhängigkeit denken Führungskräfte meist an Verträge und APIs. Bei einem Modell ist beides der günstige Teil. Die oben beschriebene Schnittstelle macht den Austausch zu einer kleinen Code-Änderung. Die eigentlichen Kosten eines Modellwechsels stecken im Qualifizierungslauf, in der Prüfung der Unterschiede, in den Anpassungen der Prompts und in der Freigabe. All das hängt an einem einzigen Bestand: einer Sammlung echter, gelabelter Fälle, der der Kunde vertraut. Mit einem gut gepflegten Abnahmedatensatz ist ein Wechsel eine Sache von Tagen. Ohne ihn ist es ein kleines Projekt, und in der Praxis bleibt der Kunde dann lieber bei dem, was er hat. Genau das ist Abhängigkeit.

Um von jedem Modellanbieter unabhängig zu bleiben, braucht ein Unternehmen deshalb keine Abstraktionsschicht über mehrere Anbieter. Es braucht seinen eigenen Abnahmedatensatz, aktuell gehalten und mit benannten Verantwortlichen.

Der Ausstieg gehört zur Übergabe

Die erneute Qualifizierung planen wir in die laufenden Kosten jedes Workflows ein, den wir übergeben. Wir rechnen mindestens einmal im Jahr damit, und das Team des Kunden führt sie selbst durch. Ein Kunde, der einen Nachfolger nicht ohne uns qualifizieren kann, besitzt das System nicht vollständig.

Jede Ü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, damit jemand weiß, wann die nächste Qualifizierung beginnen muss. 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 Lieferanten, 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

Die Modellwahl fühlt sich an wie die zentrale Entscheidung in einem KI-Projekt. Über die Lebensdauer eines Workflows gesehen ist sie eine der vorläufigsten. Was bleibt, ist der Abnahmedatensatz. Mit ihm ist die nächste Abkündigungs-E-Mail ein Termin im Wartungskalender und kein Störfall.