Ein Dokumentationsassistent kann nach einer routinemäßigen Änderung am Retrieval-System die Antwortfrist überschreiten, obwohl das Modell unverändert, der Dienst intakt und die Bereitstellungsprüfungen erfolgreich sind. Der Grund kann darin liegen, dass die Änderung einen größeren Kontext an das Modell sendet, dadurch die Generierung verlängert und die Anfragen vor dem Inferenzserver aufstaut, während das Zurücksetzen des Anwendungskontainers die an anderer Stelle geänderten Retrieval-Einstellungen nicht wiederherstellt.
Dieses hypothetische Szenario verdeutlicht ein praktisches Problem beim Betrieb von KI-Anwendungen: Was wurde tatsächlich bereitgestellt? Bei generativen Anwendungen bestimmt die Modellversion allein nicht das Verhalten des Systems; Eingaben, Vorverarbeitung, Prompts, Index, Einbettungsmodelle, Tool-Verträge und Diensteinstellungen können sich jeweils unabhängig voneinander ändern.
Die Grenzen der Versionierung klar festlegen
Der Beitrag schlägt vor, mit einer versionierten Versionsbeschreibung zu beginnen, die Referenzen auf alle gemeinsam getesteten Komponenten enthält. Dazu können die Versionskennung, die Anwendungsversion, die Modellversion, die Prompt-Version, die Indexversion, die Einbettungsversion, die Pipeline für Segmentierung und Neuranking, die Laufzeiteinstellungen, der Evaluierungsdatensatz sowie die vorherige Version gehören.
Diese Referenzen sollten auf gespeicherte und prüfbare Konfigurationen oder Elemente verweisen; anstelle ihrer Werte sollten Geheimnisreferenzen gespeichert werden. Die Laufzeitversion sollte Token-Grenzen, Batching, Zeitüberschreitungen und Ressourcenverteilung abdecken. Anwendungen, die Tools aufrufen, sollten außerdem Versionen der Tool-Schemata und Adapter einbeziehen.
Diese Beschreibung garantiert keine bitgenaue Reproduzierbarkeit; externe Dienste können sich ändern, die Generierung kann weiterhin nichtdeterministisch sein, und manche Anbieter stellen keine festen Modell-Snapshots bereit. Daher sollten diese Einschränkungen ebenso dokumentiert werden wie ein zeitlicher Bezugspunkt für die Datenerfassung und die Indexeinstellungen, wenn sich die Daten kontinuierlich ändern. Das sequenzielle Aktualisieren mehrerer Konfigurationsspeicher stellt keine atomare Version dar.
Die vollständige Aufgabe testen, nicht nur den Modellaufruf
Ein erfolgreicher HTTP-Aufruf bedeutet nicht, dass der Nutzer eine korrekte Antwort erhalten hat. Das Evaluierungs-Gate sollte die eigentlichen Produktaufgaben messen, etwa die Zitierung einer zugänglichen Quelle, die Berücksichtigung der richtigen Produktversion und den Verzicht auf erfundene Anweisungen, wenn Belege fehlen.
Der Beitrag empfiehlt einen versionierten Datensatz mit gewöhnlichen Fragen, früheren Fehlern, mehrdeutigen Anfragen, Fällen ohne ausreichende Belege und Versuchen, Berechtigungsgrenzen zu umgehen; außerdem sollte ein Datensatz zurückgehalten werden, der nicht für die Feinabstimmung verwendet wurde. Deterministische Prüfungen können auf Schema-Gültigkeit, Tool-Argumente, Zitationskennungen und die Durchsetzung von Berechtigungen angewendet werden. Semantische Bewertungen benötigen dagegen einen klaren Maßstab und eine menschliche Prüfung; das Urteil eines anderen Modells kann bei der Priorisierung von Fällen helfen, ist aber keine Referenzwahrheit.
Die Version sollte über den vollständigen Ablauf ausgeführt werden – vom Retrieval über die Generierung und die Validierung der Ausgaben –, anschließend sollten die Ergebnisse nach wichtigen Segmenten geprüft werden, etwa nach Eingabelänge, Sprachen, Produktversionen und Fällen mit seltenen Belegen. Die Abnahmekriterien sollten außerdem festgelegt werden, bevor die Kandidatenversion betrachtet wird. Dazu gehören das Verbot jeglicher Berechtigungsverletzung, Grenzen für Qualitätsrückgänge sowie Budgets für Antwortzeit und Kosten.
Arbeitslast und Kosten so messen, wie der Nutzer sie erlebt
Es reicht nicht aus, die Anzahl der Anfragen pro Sekunde zu testen. Die Tests sollten auf Eingabe- und Ausgabelängen, Parallelitätsstufen, Zugriffsspitzen sowie das Verhalten bei warmem und kaltem Speicher verteilt werden. Bei gestreamten Antworten sollten die Zeit bis zum ersten Token, die Rate der nachfolgenden Token und die Abschlusszeit getrennt werden; außerdem sollte die Wartezeit in der Warteschlange gemessen werden.
Der Beitrag empfiehlt, mit umfassenden Anfrage-Traces zu beginnen und anschließend Retrieval, Neuranking, Warteschlangen, Initialisierungs- und Generierungsphasen sowie nachgelagerte Aufrufe zu untersuchen. Perzentile aus verschiedenen Phasen sollten nicht zusammengeführt und als ein Gesamtperzentil betrachtet werden; jede Messung kann unterschiedliche Anfragen beschreiben.
Die gleiche Identität sollte außerdem in Traces und strukturierten Anfrageprotokollen mit der Version verknüpft werden. Zu verfolgen sind Qualität, Antwortzeitverteilungen, Fehler, Token-Nutzung und Quoten der Weiterleitung auf alternative Pfade. Niedrigere Kosten pro Anfrage bedeuten nicht zwangsläufig niedrigere Kosten pro abgeschlossener Aufgabe. Daher schlägt der Beitrag vor, die Kosten einer erfolgreichen Aufgabe zu berechnen, einschließlich fehlgeschlagener Versuche, und klar anzugeben, wenn für den Erfolg Ersatzmetriken verwendet werden.
Ein Rollback stellt Abhängigkeiten wieder her, nicht nur Modellgewichte
Die Kandidatenversion kann einem begrenzten Anteil des Datenverkehrs angeboten werden, während die aktuelle Version verfügbar bleibt. Für einen erfolgreichen Stufentest müssen jedoch die Signale von Kandidat und Kontrollgruppe verglichen und die Abdeckung wichtiger Lastsegmente sichergestellt werden. Der Entscheidungsträger, die Abbruchbedingungen und die Mindestbeobachtungsdauer sollten festgelegt und die Wiederherstellung vor Beginn des Rollouts durchgeführt werden.
Wenn die Kandidatenversion den Retrieval-Index an Ort und Stelle ersetzt, reicht es nicht aus, die Anfragen an ein altes Anwendungs-Image weiterzuleiten. Es müssen kompatible Indexversionen vorgehalten oder migrierbare Strukturen entworfen werden, die sich umkehren lassen; dabei sind aktuelle Löschvorgänge und der Entzug von Berechtigungen zu berücksichtigen. Außerdem sollte eine Richtlinie für das Auslaufenlassen oder Abbrechen laufender Generierungen festgelegt werden. Nebenwirkungen von Tools wie dem Versand von E-Mails oder der Änderung von Datensätzen sollten durch Idempotenz und geeignete Genehmigungsgrenzen abgesichert werden.
Warum dieser Ansatz wichtig ist
Der praktische Wert dieser Empfehlungen liegt darin, dass sie die Verwaltung von KI-Anwendungen von der Frage „Welches Modell verwenden wir?“ zu einer umfassenderen Frage verlagern: Lässt sich die vollständige Version bestimmen, die eine schlechte Antwort erzeugt hat, und anschließend eine bekannte, kompatible Version wiederherstellen? Das bedeutet, dass das nützliche Minimum in einem bestehenden Repository liegen kann und aus einer Versionsbeschreibung, einer Evaluierungsaufgabe, einem repräsentativen Lasttest, versionsverknüpften Traces und einem tatsächlich durchgeführten Rollback-Training besteht.
Auch die Einschränkungen sind klar: Das Bestehen eines begrenzten Testsatzes beweist weder das Fehlen von Sicherheitsmängeln noch das Ausbleiben seltener Fehler. Produktionsfeedback ist selektiv und entspricht nicht immer der Richtigkeit der Antwort. Daher bleiben die menschliche Prüfung und die Festlegung von Verantwortlichkeiten an den Schnittstellen zwischen Anwendung, Plattform und Daten Teil der Betriebsarchitektur und nicht bloß Ergänzungen, die vollständig automatisiert werden können.