Gleiche Modellversion, andere Antworten
Am Montag lief ein Schritt, der monatelang bei sechsundneunzig Prozent lag, bei zweiundneunzig. Kein Deployment, keine Konfigurationsänderung, keine Änderung an den Dokumenten — und in jeder Anfrage dieselbe Modellkennung.
Der Montag
Der tägliche Bewertungslauf meldete zweiundneunzig Prozent auf einem Set, das vier Monate lang sechsundneunzig geliefert hatte. Unsere erste Stunde ging in die Suche nach dem, was wir geändert hatten — der richtige Reflex, und er ergab nichts, denn wir hatten nichts geändert.
Die Dokumente waren identisch. Die Prompts waren identisch. Die Modellkennung in jeder Anfrage war dieselbe festgelegte Zeichenkette wie seit März. Geändert hatte sich etwas auf der anderen Seite des Netzwerkaufrufs, und wir konnten es nicht direkt beobachten.
Was eine Versionsangabe tatsächlich ist
Ein Name, den der Anbieter vergibt. Er entspricht meist einem Satz Gewichte und oft einer Serving-Konfiguration, und keine dieser Entsprechungen können wir überprüfen oder wird in den meisten Nutzungsbedingungen zugesagt.
Li und Kollegen veröffentlichten 2025 eine Arbeit zur Bewertung der Dienstgüte unter Verhaltensinstabilität auf Token-Ebene und behandeln die zeitliche Veränderung des Modellverhaltens als messbare Diensteigenschaft statt als zu ignorierendes Rauschen.
Was wir täglich laufen lassen
Das Referenzset, jeden Morgen, gegen jedes Modell, von dem wir abhängen, mit dem Ergebnis auf einem Dashboard und einem Alarm bei einem Abfall über einer Schwelle. Das kostet wenige Euro am Tag je System und ist der einzige Grund, warum wir davon binnen vierundzwanzig Stunden erfuhren und nicht über einen Kunden.
Wir archivieren außerdem die vollständige Antwort für zwanzig feste Eingaben, damit sich eine Verhaltensänderung ansehen und nicht nur erschließen lässt. Dieses Archiv erlaubte es, die Änderung als andere Behandlung optionaler Felder zu bestimmen statt als allgemeine Verschlechterung.
| Was wir tun | Warum |
|---|---|
| Täglicher Referenzlauf je Modell | Erkennt eine Änderung binnen eines Tages |
| Antworten fester Eingaben archivieren | Zeigt, was sich geändert hat, nicht nur dass |
| Über ein Gateway leiten | Eine Stelle, um unter Druck zu wechseln |
| Ein geprüftes Ersatzmodell | Damit der Wechsel eine Entscheidung ist, kein Projekt |
Was wir unternommen haben
Den Prompt so angepasst, dass das Verhalten bei optionalen Feldern ausdrücklich statt impliziert ist — das holte etwa drei der vier Punkte zurück, den vierten haben wir hingenommen. Die Alternative wäre ein Modellwechsel gewesen, zu dem wir bereit waren, weil es ein geprüftes Ersatzmodell gab, und der mehr gekostet hätte, als der Punkt wert war.
Wichtig ist, dass am Montag beide Optionen existierten. Ein System, dessen Ersatz nie bewertet wurde, hat keinen Ersatz — es hat den Plan, während eines Vorfalls einen zu bewerten.
Was wir Anbieter heute fragen
Ob sich das Verhalten einer festgelegten Version ändern kann, welche Vorlaufzeit wir bekommen und ob das frühere Verhalten verfügbar bleibt. Die Antworten schwanken und sind oft unbefriedigend, und Fragen lohnt trotzdem — denn die Antwort geht in das Systemdokument des Kunden statt in eine Annahme.
Wo die Antwort lautet, dass sich Verhalten ohne Ankündigung ändern kann, sagen wir das dem Kunden und bepreisen die Überwachung entsprechend. Das ist ehrlicher, als eine Stabilität anzudeuten, die wir nicht bekommen können — und kein Kunde hat Einwände dagegen erhoben.
Warum das weniger für Eigenbetrieb spricht, als es scheint
Ein selbst betriebenes Modell driftet nicht, ein echter Vorteil und ein kleinerer, als er aussieht. Die erlebte Drift kostete uns eine Prompt-Anpassung und einen Tag; Eigenbetrieb kostete dauerhaft eine Rufbereitschaft.
Für die meisten Kunden ist die tägliche Bewertung die günstigere Antwort auf dieses Problem, und Eigenbetrieb bleibt eine Entscheidung über Datenhaltung und Menge — dort haben wir sie immer verortet. Drift ist ein Grund zu überwachen, kein Grund umzuziehen.
Was Kunden daraus mitnehmen sollten
Dass jedes System auf einem gehosteten Modell eine Abhängigkeit hat, die sich ohne Deployment ändern kann — und dass die Frage an einen Anbieter nicht lautet, ob er Versionen festlegt, sondern was er täglich laufen lässt, um zu merken, wenn das Festlegen nicht genügt hat.
Unsere eigene Antwort war früher, mit einiger Zuversicht, dass wir Versionen festlegen. Das stimmte und war nicht die Antwort auf die Frage — und davon eingeholt zu werden ist der Grund, warum wir heute die Überwachung beschreiben und nicht das Festlegen.
Was wir nicht behaupten
Wir behaupten nicht, der Anbieter habe etwas falsch gemacht. Serving-Infrastruktur ändert sich aus guten Gründen, die Bedingungen ließen es zu, und vier Punkte auf einer schmalen Aufgabe sind kein Beleg für eine gebrochene Zusage.
Wir behaupten auch nicht, tägliche Bewertung fange alles. Sie fängt Änderungen, die groß genug sind, um ein Set aus achtzig Fällen zu bewegen — eine feine Verschiebung, die einen Dokumenttyp betrifft, kann lange unter dieser Schwelle liegen.