Verträge für KI-Anwendungen: Änderungen an Modellen, SDKs oder Tools vor der Produktion erkennen

Eine Demo, die antwortet, beweist keine Kompatibilität

In einer KI-Anwendung kann eine Änderung keinen Transportfehler auslösen und dennoch das Produkt beschädigen. Das Modell kann weiterhin Text liefern, der für eine Person nützlich ist, aber ein Feld auslassen, das ein nachgelagerter Dienst verarbeitet, ein nicht erlaubtes Tool auswählen, die praktische Bedeutung eines Labels verändern oder eine Schlussfolgerung auf einen abgerufenen Ausschnitt stützen, der sie nicht belegt. Zu prüfen, dass es „weiterhin antwortet“, ist deshalb nicht dasselbe wie zu prüfen, dass das erwartete Betriebsverhalten erhalten bleibt.

Ein Vertrag ist eine überprüfbare Spezifikation der Eigenschaften, die an einer konkreten Grenze des Workflows erhalten bleiben müssen. Er ist weder das Versprechen, dass das Modell immer denselben Satz formuliert, noch der Versuch, generative Variabilität vollständig zu beseitigen. Er definiert, welche Eingaben zulässig sind, welche Form die Ausgabe haben muss, welche Geschäftsinvarianten nicht verletzt werden dürfen, welche Aktionen autorisiert sind und welche Belege nötig sind, bevor etwas behauptet oder eine Operation ausgeführt wird.

Die Analyseeinheit muss die konkrete inkompatible Änderung sein. Das kann ein Modellwechsel, ein SDK-Update, eine Änderung des Systemprompts, eine Schemaänderung, eine neue Tool-Definition oder eine aktualisierte Richtlinie des Anbieters sein. Das Ziel besteht darin, vor der Freigabe der Änderung zu beantworten: Ist der Vertrag erhalten geblieben? Liegt die Verschlechterung innerhalb einer akzeptierten Grenze? Muss der Workflow angepasst werden? Oder muss die Änderung blockiert werden?

Verträge ergänzen aggregierte Qualitätsbewertungen, lösen aber ein anderes Problem. Eine Bewertung kann zeigen, dass die durchschnittliche Nützlichkeit weiterhin hoch ist, obwohl einer von hundert Fällen einen Stornobefehl ohne Bestätigung ausgibt. Dieser Einzelfall ist eine kritische Inkompatibilität, wenn die Aktion externe Folgen hat. Ebenso beweist gültiges JSON weder, dass ein Argument sicher ist, ein Zitat der Quelle entspricht noch eine Klassifizierung ihre Bedeutung behält.

Inventar der Grenzen und Abhängigkeiten

Zeichnen Sie vor dem Schreiben von Tests den vollständigen Weg eines Nutzerfalls nach. Eine Grenze besteht dort, wo eine Komponente eine Darstellung übergibt, die eine andere Komponente interpretiert: die an den Anbieter gesendete Anfrage, die Modellkennung, die Modellantwort, der SDK-Adapter, der Kontextabruf, der Aufruf eines Tools, das Zielsystem und die externe Aktion. Jede Grenze kann einen eigenen Vertrag und einen eigenen Verantwortlichen haben.

Das Inventar muss effektive Versionen und Konfigurationen erfassen, nicht nur allgemeine Namen. Dokumentieren Sie das angeforderte Modell oder den Snapshot, die SDK- und gegebenenfalls API-Version, den Systemprompt, Generierungsparameter, das Ausgabeschema, die Tool-Liste, die Berechtigungsdefinition, die Version des Retrieval-Index und interne Adapter. Ohne diese Informationen lässt sich ein späterer Fehler kaum einer konkreten Ursache zuordnen.

Nicht alle Grenzen erfordern dieselbe Art von Assertion. Bei der Modellanfrage müssen zulässige Parameter und normalisierte Werte geprüft werden. Eine strukturierte Ausgabe verlangt die Validierung von Schema und Pflichtfeldern. Beim Retrieval müssen Herkunft, Aktualität und ausreichende Beleglage geprüft werden. Tools erfordern neben Syntax auch Autorisierung und die Simulation von Auswirkungen. Das Zielsystem benötigt abhängig vom Risiko Idempotenz, Transaktionskontrolle oder Kompensation.

Die Dokumentation der Anbieter zeigt, dass sich Modelllebenszyklen und Schnittstellen ändern können. Insbesondere können Modellabkündigungen und bestimmte Parameteränderungen Anfragen, die zuvor gültig waren, in Fehler verwandeln. Daher muss eine Migration als Änderung einer Abhängigkeit getestet werden, selbst wenn sich der Geschäftscode nicht geändert hat.

Was zu einem Vertrag werden sollte

Beginnen Sie mit den deterministischen Elementen. Geeignete Kandidaten sind Typen, Pflichtfelder, numerische Grenzen, Enumerationen, Kennungen, das Vorhandensein einer Quelle, Datumsformate, erlaubte Tools und Autorisierungsregeln. Dazu gehören auch Geschäftsinvarianten: Eine Rückerstattung darf den gezahlten Betrag nicht übersteigen, ein Agent darf keine Daten eines anderen Kunden ändern, und eine Operation mit erforderlicher menschlicher Genehmigung darf ohne diesen Status nicht ausgeführt werden.

Fügen Sie anschließend operative Einschränkungen hinzu. Definieren Sie ein Latenz- und Kostenbudget pro Fall mit einer präzisierten Messmethode, etwa einem Perzentil über eine kontrollierte Stichprobe statt einem einzelnen Eindruck. Legen Sie Höchstwerte für Wiederholungsversuche, Tools pro Ausführung, abgerufene Dokumente und Kontextgröße fest. Ein Anstieg kann technisch kompatibel und für das Produkt dennoch untragbar sein; der Vertrag muss beide Ebenen voneinander trennen.

Labels verdienen eine explizite semantische Behandlung. Wenn eine Ausgabe `riesgo_alto` enthält, muss der Vertrag erläutern, welche Fakten dieses Label rechtfertigen und welche Folgen es auslöst. Eine wörtliche Übereinstimmung des Labels genügt nicht, wenn sich das Zuordnungskriterium verändert hat. Verwenden Sie Grenzfälle mit menschlicher Annotation und Assertions zu den beobachtbaren Bedingungen, die zu jeder Klasse führen müssen.

Bei Antworten mit Belegen muss der Vertrag zwischen einem Zitat und einer tatsächlich gestützten Aussage unterscheiden. Prüfen Sie mindestens, dass die abgerufene Quelle für die Domäne zulässig ist, ihr Datum die Aktualitätsrichtlinie erfüllt, die Passage ausreichende Belege für die Behauptung enthält und der Workflow unzureichende Informationen erklärt, wenn die Grundlage fehlt. Attribution darf nicht zu einer am Ende des Prozesses erzeugten Dekoration werden.

Die Änderung klassifizieren, bevor ihre Ergebnisse diskutiert werden

Ordnen Sie jede vorgeschlagene Änderung einer von vier Gruppen zu. Eine kompatible Änderung erhält alle anwendbaren Verträge. Eine Änderung mit akzeptabler Verschlechterung verletzt ein nicht kritisches Ziel innerhalb eines genehmigten Schwellenwerts, etwa bei einer begrenzten Latenzabweichung. Eine inkompatible Änderung verletzt eine zwingende Eigenschaft, etwa eine Aktionsberechtigung oder ein Pflichtfeld. Eine unbekannte Änderung liegt vor, wenn Fälle, Fixtures, Telemetrie oder eine ausreichende Definition fehlen, um zu einem Schluss zu kommen.

Die Klassifikation darf nicht davon abhängen, wer die Änderung vorschlägt oder wie überzeugend eine Demonstration wirkt. Sie muss an vorab veröffentlichte Regeln für die Freigabe gebunden sein. Stellt das Team fest, dass eine Regel den Produktbedarf nicht mehr abbildet, kann es den Vertrag ändern. Diese Entscheidung muss jedoch ausdrücklich, überprüft und versioniert erfolgen; sie darf nicht stillschweigend durch einen fehlgeschlagenen Test akzeptiert werden.

Das Festschreiben einer konkreten Modellversion verringert eine Variationsquelle und erleichtert die Reproduktion von Ergebnissen. Aliase oder Modelle, die Aktualisierungen unterliegen, können ihr Verhalten ändern, ohne dass sich der Client-Code verändert. Die OpenAI-Dokumentation empfiehlt, Modellversionen festzulegen und Evaluierungen auszuführen, weil Snapshots beim Prompting-Verhalten variieren können. Ein Vertrag muss daher sowohl die angeforderte Kennung als auch die vom Team akzeptierte Aktualisierungsrichtlinie erfassen.

Eine minimale, diagnostisch aussagekräftige Testsuite entwerfen

Eine nützliche Testsuite muss nicht jede denkbare menschliche Unterhaltung abbilden. Sie sollte feste Fälle enthalten, die kritische Pfade, Grenzfälle und historische Gegenbeispiele abdecken. Jeder Fall muss Eingabe, Ausgangszustand, Workflow-Konfiguration, erwartetes Ergebnis, Schweregrad und Assertions deklarieren. Halten Sie Testdaten frei von sensiblen Informationen und stellen Sie sicher, dass sie wiederholt ausgeführt werden können.

Verwenden Sie Fixtures für Tools und externe Abhängigkeiten. Eine Fixture muss kontrollierte Zustände zurückgeben, Aufrufe protokollieren und reale Effekte verhindern. So lässt sich prüfen, ob das Modell das richtige Tool gewählt hat, ob die Argumente durch den Adapter interpretiert wurden und ob keine verbotene Alternative ausgeführt werden sollte. Eine Testumgebung, die die Produktion aufruft, ist keine Fixture: Sie vermischt Kompatibilität mit Betriebsrisiko.

Snapshots eignen sich für bewusst stabile Artefakte, beispielsweise eine normalisierte Anfrage, ein Tool-Schema oder eine geordnete Liste abgerufener Kennungen. Für vollständig vom Modell erzeugte Prosa sind sie fragil. Bevorzugen Sie bei natürlicher Sprache begrenzte semantische Assertions: das Vorhandensein verpflichtender Fakten, das Fehlen verbotener Behauptungen, die Übereinstimmung mit Belegen und ein Abstentionsverhalten bei unzureichenden Daten.

Manche Messgrößen sind nicht deterministisch. Erfolgsrate, Latenzverteilung und Häufigkeit einer Klassifizierung können mehrere Ausführungen, eine festgelegte Stichprobe und ein vorab definiertes Intervall oder eine Toleranz erfordern. Machen Sie aus einer kleinen statistischen Differenz keine kritische Regression; lassen Sie aber auch nicht zu, dass statistische Unsicherheit eine deterministische Sicherheitsverletzung verdeckt.

Strukturierte Ausgaben und Tool-Aufrufe: Schema ist keine Autorisierung

Eine strukturierte Ausgabe muss zweimal validiert werden: zuerst gegen ihre Darstellung und danach gegen ihre Bedeutung. Die erste Validierung prüft JSON, Typen, Pflichtfelder, Bereiche und erlaubte Werte. Die zweite prüft Beziehungen zwischen Feldern und externem Zustand. Beispielsweise, ob ein Startdatum vor dem Enddatum liegt, ein Betrag zur angegebenen Bestellung gehört und ein Grundcode zum Fall passt.

Die Tool-Schnittstellen der Anbieter können Parameter mit JSON Schema beschreiben und strikte Modi für die Schemaeinhaltung anbieten. Das hilft maßgeblich, fehlerhaft formatierte Argumente zu reduzieren, ersetzt aber nicht die Validierung durch die Anwendung. Ein Argument kann korrekt typisiert sein und dennoch ein falsches Konto bezeichnen, eine Operation außerhalb der Richtlinie darstellen oder eine Aktion auslösen, die eine Genehmigung benötigt. Der Ausführer muss Berechtigungen, Vorbedingungen und Grenzen anwenden, bevor er Effekte erzeugt.

Der Vertrag muss auch die Reihenfolge festlegen. In einem Workflow, der zunächst die Berechtigung prüft und anschließend eine Rückerstattung ausstellt, darf keine umgekehrte Sequenz akzeptiert werden, nur weil beide Aufrufe einzeln gültig sind. Pro Schritt sind erlaubte Tools, die maximale Zahl der Aufrufe, normalisierte Argumente, die Fixture-Antwort und das Ausbleiben nicht autorisierter Aufrufe zu protokollieren. Damit lassen sich Änderungen erkennen, bei denen das Modell die Aufgabe scheinbar löst, aber einen operativ gefährlichen Abkürzungsweg nimmt.

Wenn der Anbieter das Modell, die Tool-Definition oder den SDK-Adapter verändert, führen Sie dieselben Fixtures aus. Ein Test auf gültiges JSON würde ein falsch geformtes Objekt erkennen; diese Testsuite kann feststellen, dass ein anderes Tool gewählt, die vorherige Prüfung ausgelassen oder eine bereits bestätigte Aktion wiederholt werden sollte.

Verträge für Retrieval und Antworten mit Quellen

In einem RAG-Workflow beginnt der Vertrag vor der Formulierung. Legen Sie fest, welche Sammlungen ein Fall abfragen darf, welche Mindestmetadaten jeder Ausschnitt zurückgeben muss und wie Aktualität aufgelöst wird. Hängt eine Antwort von einer aktuellen Richtlinie ab, kann ein altes Dokument technisch abrufbar, zur Begründung aber unzulässig sein. Der Test muss die Herkunft prüfen, nicht nur den Endtext.

Definieren Sie Mindestbelege pro Art der Behauptung. Eine normative Schlussfolgerung kann eine explizite Passage aus einer autorisierten Quelle verlangen; eine Zusammenfassung kann mehrere konsistente Ausschnitte erfordern; eine Zahl kann eine exakte Übereinstimmung mit dem Dokument voraussetzen. Erfüllen die Ergebnisse diese Bedingung nicht, kann das korrekte Verhalten darin bestehen, mehr Kontext anzufordern, Unsicherheit zu erklären oder die Behauptung nicht zu beantworten. Diese Enthaltung ist eine vertragliche Ausgabe und nicht standardmäßig ein Fehler der Nutzererfahrung.

Testen Sie Widersprüche und unzureichenden Kontext. Nehmen Sie Fixtures mit veralteten Dokumenten, Quellen geringerer Autorität, Ausschnitten mit ähnlichen Begriffen und Mengen mit widersprüchlichen Informationen auf. Der Vertrag muss angeben, ob der Workflow einer Quelle Vorrang gibt, den Konflikt sichtbar macht oder zur Prüfung eskaliert. Es ist nicht vertretbar, ein Zitat allein deshalb als korrekt zu bezeichnen, weil es Wörter mit der Antwort teilt.

Bewahren Sie für jede Ausführung die Menge der Kandidatendokumente, die ausgewählten Dokumente, ihre Kennungen und relevanten Metadaten, die Indexversion, die transformierte Abfrage und das Endergebnis auf. Diese Telemetrie erlaubt es, zu unterscheiden, ob die Verletzung beim Retrieval, bei der Interpretation durch das Modell oder bei der Darstellung der Belege entstanden ist.

Integration in CI/CD, Entscheidung und Rücknahme

Führen Sie die Testsuite aus, wenn sich eines der erfassten Artefakte ändert: Modellversion, SDK, Systemprompt, Parameter, Schema, Tool-Definition, Retriever, Index oder Richtlinie. Die Änderung muss ein vergleichbares Manifest erzeugen, das Versionen, Hashes oder interne Kennungen, Ergebnisse je Fall, Dauer, gemessenen Verbrauch, soweit verfügbar, sowie Tool- und Retrieval-Traces enthält. Verhindern Sie, dass eine implizite Aktualisierung der Änderungskontrolle entgeht.

Organisieren Sie CI-Gates nach Schweregrad. Kritische Assertions wie Autorisierungen, nicht erlaubte Effekte, Mandantentrennung oder zwingende Belege müssen blockieren. Assertions mit hohem Schweregrad blockieren normalerweise, bis eine genehmigte Anpassung vorliegt. Qualitäts- oder Leistungsmetriken mit Toleranz können eine Überprüfung erfordern. Ein unbekanntes Ergebnis darf nicht mangels Signal automatisch als kompatibel gelten.

Wenn ein Vertrag fehlschlägt, lokalisieren Sie zuerst die Grenze. Vergleichen Sie die normalisierte Anfrage, das Modellartefakt, die Rohantwort, die SDK-Anpassung, die abgerufenen Dokumente und das Tool-Protokoll. Entscheiden Sie dann zwischen der Korrektur der Integration, der Anpassung des Vertrags aufgrund eines legitimen geänderten Bedarfs, der Versionierung des Workflows zur Unterstützung beider Verhaltensweisen oder der Ablehnung der Änderung. Dokumentieren Sie, warum die Entscheidung gültig ist und wer sie genehmigt hat.

Die Rücknahme muss vor der Freigabe geplant sein. Bewahren Sie die vorherige Konfiguration auf, mit der sich Modell, Prompt, Schema, Tools und kompatible Adapter wiederherstellen lassen. Zieht der Anbieter eine Version zurück, ist eine exakte Rücknahme möglicherweise nicht mehr möglich; dann besteht die Alternative in einem versionierten Workflow mit getesteter Anpassung. Von Anbietern veröffentlichte Abkündigungsrichtlinien sind ein zusätzlicher Grund, Migrationen vor dem Stichtag zu planen und nicht erst nach einem Vorfall.

Vorlage für ein Vertragsmanifest pro Workflow

Ein kurzes Manifest macht die Absicht zu einem überprüfbaren Artefakt. Es sollte gemeinsam mit dem Workflow leben und denselben Review-Prozess wie der Code durchlaufen. Es muss weder Geheimnisse noch alle Testunterhaltungen enthalten; es sollte auf interne Fixture-Kennungen verweisen und präzise bestimmen, welche Eigenschaften es regelt.

Nehmen Sie Folgendes auf: Name und Zweck des Workflows; technische und Produktverantwortliche; Vertragsversion; Kennungen von Modell, SDK und Konfigurationen; Prompt oder Verweis auf dessen Version; Ausgabeschema; erlaubte Tools und Berechtigungen; Retrieval-Abhängigkeiten; Fallliste; Leistungs- und Kostenschwellenwerte; Schweregrad jeder Regel; Freigaberichtlinie; erforderliche Telemetrie; Rücknahmestrategie; und Überprüfungsdatum. Fehlt einer Regel ein Verantwortlicher oder ein Fehlerkriterium, ist sie noch kein betrieblicher Vertrag.

Die Vorlage ersetzt kein technisches Urteilsvermögen. Die verfügbaren Quellen dokumentieren Mechanismen für Versionierung, Abkündigungen, Schemata und die strikte Nutzung von Tools, können aber nicht entscheiden, welche Belege für Ihre Domäne ausreichen oder welche Aktion menschliche Genehmigung braucht. Diese Entscheidungen liegen beim verantwortlichen Team und müssen als überprüfbare Richtlinien formuliert werden. Der Vorteil des Manifests besteht darin, sie sichtbar zu machen, bevor ein Update ihnen widerspricht.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.