Strukturierte KI-Ausgaben: So prüfen Sie Daten, bevor Sie sie speichern oder Aktionen auslösen

Ein maschinenlesbares Format garantiert keine korrekten Daten

Eine strukturierte Ausgabe ist eine Antwort eines Modells, die so organisiert ist, dass eine Anwendung sie vorhersehbar verarbeiten kann – zum Beispiel ein JSON-Objekt mit festgelegten Feldern und Datentypen. Das kann hilfreich sein, um Daten aus Dokumenten zu extrahieren, Anfragen zu klassifizieren oder Informationen für eine andere Komponente aufzubereiten. Der wesentliche Vorteil liegt darin, dass das Ausgabeformat weniger Interpretationsspielraum lässt. Der erzeugte Inhalt wird dadurch jedoch nicht automatisch zu einer überprüften Tatsache.

Es ist sinnvoll, vier Fragen getrennt zu betrachten: Lässt sich die Antwort als JSON parsen? Enthält sie die vereinbarten Felder und Datentypen? Stimmen die Werte untereinander und mit den Quelldaten überein? Und darf die Ausgabe für den vorgesehenen Zweck verwendet werden? Eine Antwort kann die ersten Prüfungen bestehen und bei jeder der folgenden durchfallen. Dass ein Objekt ein Datum im erwarteten Format enthält, beweist nicht, dass dieses Datum tatsächlich im Dokument steht. Dass es eine gültige Kategorie enthält, beweist nicht, dass die Klassifizierung korrekt ist.

Diese Unterscheidung hilft auch bei der Wahl des Ausgabemechanismus. Ein JSON-Modus oder eine durch ein Schema eingeschränkte Generierung zielt darauf ab, eine finale Antwort in einer bestimmten Form auszugeben. Bei einem Tool-Aufruf werden dagegen Argumente für eine Funktion übermittelt; anschließend entscheidet die Anwendung, ob sie die Funktion ausführt. Gut formatierte Argumente erteilen nicht automatisch die Berechtigung zur Ausführung. Die Kontrolle über die Ausführung bleibt beim integrierenden System.

Dieser Leitfaden konzentriert sich auf den Datenvertrag, der bei jeder Ausführung überprüft wird. Er ersetzt nicht das Management von Änderungen an Modellen, SDKs oder Tools, bei dem die Kompatibilität zwischen Versionen im Blick behalten werden muss. Auch ohne Änderung der API können eine mehrdeutige Eingabe, ein unvollständiges Dokument oder eine falsche Interpretation zu einem Ergebnis führen, das nicht als bestätigt gespeichert werden sollte.

Definieren Sie den Datenvertrag, bevor Sie den Prompt schreiben

Orientieren Sie sich zunächst an der Verwendung der Antwort und nicht an einer Liste von Feldern, die für das Modell bequem erscheint. Wenn ein anderes System das Ergebnis speichern soll, legen Sie fest, wofür jedes Feld steht, welchen Typ es hat und was die Anwendung damit tun wird. Ein brauchbarer Vertrag verringert das Risiko, dass Erzeuger und Verbraucher die Daten unterschiedlich interpretieren.

Entscheiden Sie für jedes Feld, ob es erforderlich, optional oder nullfähig ist. Verwenden Sie nicht pauschal eine leere Zeichenfolge, einen Platzhalter oder den Wert null, um „unbekannt“ darzustellen: Solche Werte können mit tatsächlichen Angaben verwechselt werden. Legen Sie außerdem Einheiten fest – etwa, in welcher Währung ein Betrag angegeben ist –, ebenso Datumsformate, zulässige Grenzen und erlaubte Aufzählungswerte. Wenn Kategorien verwendet werden, beschreiben Sie, wofür sie stehen und was zu tun ist, wenn keine davon passt.

Geschäftsregeln gehen häufig über die Datentypen hinaus. Ein Schema kann zulassen, dass zwei Beträge Zahlen sind; die Anwendung kann zugleich verlangen, dass die Summe innerhalb einer definierten Toleranz der Summe der Einzelpositionen entspricht. Ein Schema kann eine Vertrauensangabe als Zahl akzeptieren, ohne damit einen geeigneten Schwellenwert zur Bestätigung eines Datums festzulegen. Halten Sie solche Regeln ausdrücklich fest, statt anzunehmen, dass das Modell sie zuverlässig befolgt.

Der Standard JSON Schema kann Strukturen und Einschränkungen beschreiben. Ein bestimmter Anbieter unterstützt in einem bestimmten Kanal jedoch möglicherweise nur eine Teilmenge seiner Funktionen. Prüfen Sie die aktuelle Dokumentation des Modells und des gewählten Ausgabemodus, bevor Sie sich auf ein bestimmtes Schlüsselwort verlassen. Wenn eine Einschränkung in diesem Kanal nicht verfügbar ist, prüfen Sie sie in der Anwendung. Lassen Sie sie weder stillschweigend weg noch nehmen Sie an, dass das Modell sie allein aufgrund einer Prompt-Anweisung einhalten wird.

Wählen Sie den Ausgabekanal passend zum gewünschten Ergebnis

Eine finale strukturierte Ausgabe eignet sich, wenn die Anwendung organisierte Daten als Antwort benötigt. Ein JSON-Modus kann die allgemeine Form vorgeben; eine durch ein Schema eingeschränkte Generierung kann zusätzliche Einschränkungen durchsetzen, sofern Anbieter, Modell und Kanal sie unterstützen. Beides ist keine allgemeine Garantie für die Wahrheit der Inhalte und macht die Prüfung der empfangenen Antwort nicht überflüssig.

Ein Tool-Aufruf dient dazu, Argumente für eine der Anwendung bekannte Funktion vorzuschlagen. Mit dem Empfang dieser Argumente ist der Ablauf nicht abgeschlossen: Das System prüft sie, entscheidet über die Ausführbarkeit und führt die Operation gegebenenfalls aus. Diese Trennung sollte im Design sichtbar bleiben. Ein Feld wie „Zahlung_senden“ sollte nicht allein deshalb eine Aktion auslösen, weil das Modell es ausgegeben hat.

Prüfen Sie vor dem Produktivbetrieb, wie der Kanal normale Ergebnisse, unvollständige Antworten und Ablehnungen darstellt. Solche Zustände dürfen nicht als gültige Objekte behandelt werden, nur weil sie während einer Übertragung auftreten oder sich teilweise in Text umwandeln lassen. Bei gestreamten Antworten sollten Sie ein eindeutig erkennbares finales Ergebnis abwarten, bevor Sie eine geschäftliche Entscheidung treffen.

Wenn eine Schemaeinschränkung nicht unterstützt wird, wählen Sie eine ausdrücklich festgelegte Alternative: Validieren Sie die Einschränkung lokal, vereinfachen Sie den Vertrag, ohne wesentliche Kontrollen aufzugeben, oder wechseln Sie zu einem kompatiblen Kanal. Halten Sie die Abweichung fest. Ein Vertrag, der im Prompt streng wirkt, vom Kanal aber nicht durchgesetzt wird, kann ein trügerisches Sicherheitsgefühl erzeugen.

Prüfen Sie in mehreren Schichten statt mit einer einzigen Kontrolle

Die erste Schicht betrifft den Antwortstatus: Stellen Sie fest, ob eine verarbeitbare finale Antwort vorliegt oder ob der Anbieter eine Ablehnung, Unterbrechung oder Unvollständigkeit meldet. Ist das Ergebnis abgeschnitten oder noch nicht abgeschlossen, dürfen Sie es nicht als teilweise angenommen behandeln, es sei denn, Ihr Produkt hat dieses Verhalten ausdrücklich definiert und getestet.

Die zweite Schicht umfasst Parsing und Struktur. Prüfen Sie, ob sich der Text im erwarteten Format interpretieren lässt, ob das Wurzelelement den vereinbarten Typ hat und ob Felder, Datentypen, zulässige Werte und anwendbare Einschränkungen gültig sind. Behandeln Sie Parsing-Fehler. Wandeln Sie Werte außerdem nicht automatisch mit einer mehrdeutigen Konvertierung um – etwa Text in eine Zahl –, sofern dafür keine dokumentierte Regel besteht.

Die dritte Schicht prüft Bedeutung und Zusammenhänge zwischen Feldern. Validieren Sie Wertebereiche, Konsistenz, unvereinbare Kombinationen und Geschäftsbedingungen. In der vierten Schicht gleichen Sie den Vorschlag mit der ursprünglichen Eingabe ab: einer Rechnung, einem Ticket oder einer Anfrage. Bestätigen Sie relevante Angaben nach Möglichkeit anhand des Dokuments oder eines autorisierten Datensatzes. Die fünfte Schicht entscheidet, ob die Verwendung erlaubt ist: Einen Vorschlag anzuzeigen hat nicht dieselben Auswirkungen wie ein Konto zu ändern oder eine externe Operation auszuführen.

Halten Sie vorgeschlagene Werte und bestätigte Werte getrennt. Wenn ein Feld geprüft werden muss, sollten Oberfläche und Speicherung es als ausstehend oder ungeprüft kennzeichnen können. Wer unsichere extrahierte Daten über die ursprünglichen Belege schreibt, erschwert Korrekturen und die spätere Rekonstruktion der Entscheidungsgrundlage.

Drei praktische Abläufe

Die folgenden Beispiele zeigen, wie dasselbe Design zwischen der Form einer Antwort und ihrer Akzeptanz unterscheidet. Die Felder dienen der Veranschaulichung. In einer realen Implementierung müssen sie an die eigenen Dokumente, Buchhaltungsregeln, Taxonomie und Zugriffskontrollen angepasst werden.

contracts

Behandeln Sie Fehler kontrolliert

Nicht jeder Fehler erfordert dieselbe Reaktion. Bei einem Formatfehler kann eine neue Generierung mit einer enger gefassten Anweisung sinnvoll sein. Bei einer unvollständigen Antwort muss sie möglicherweise erneut angefordert oder der Prozess angehalten werden. Ein Widerspruch zur Quelle kann eine menschliche Prüfung erfordern. Fehlende Berechtigung muss die Aktion blockieren und darf nicht zu einem erneuten Versuch führen, der lediglich eine passendere Antwort hervorbringen soll.

Legen Sie im Voraus fest, wann eine Ausgabe angenommen, erneut angefordert, in Quarantäne gestellt oder abgelehnt wird. Begrenzen Sie Wiederholungsversuche und speichern Sie das fehlgeschlagene Ergebnis, damit nachvollziehbar bleibt, was passiert ist. Wenn das System einen neuen Versuch unternimmt, darf es keine widersprüchlichen Antworten zusammenführen und nicht einfach die vollständigste auswählen. Der erneute Versuch braucht ein konkretes Ziel – zum Beispiel ein fehlendes Feld zu ergänzen – und muss dieselben Validierungen erneut durchlaufen.

Vermeiden Sie stillschweigende Korrekturen, die einen sichtbaren Fehler in scheinbar verlässliche Daten verwandeln können. Leerzeichen oder eine eindeutige Schreibweise zu normalisieren, kann sicher sein, wenn es dokumentiert ist. Ein fehlendes Feld zu erfinden, zwischen zwei widersprüchlichen Beträgen auszuwählen oder eine Kategorie passend zu einer Regel umzudeuten, ist es nicht. Bewahren Sie genügend Informationen auf, um ursprüngliche und normalisierte Werte unterscheiden zu können.

Testen und protokollieren Sie den gesamten Ablauf

Ein aussagekräftiger Test umfasst normale Beispiele und Grenzfälle: fehlende oder nullfähige Felder, Werte außerhalb zulässiger Bereiche, unscharfe oder widersprüchliche Dokumente, unpassende Kategorien, unvollständige Antworten und Anfragen, die verfügbare Berechtigungen überschreiten. Testen Sie außerdem jede Stufe separat. So können Sie einen Fehler des Ausgabekanals von einem Validierungsfehler oder einer zu restriktiven Geschäftsregel unterscheiden.

Messen Sie den Anteil der Antworten, die ohne Eingriff verwendbar sind, Fehler je Feld, erkannte Widersprüche, Ablehnungen, erneute Versuche und Fälle, die zur Prüfung weitergeleitet werden. Eine hohe Schema-Konformität entspricht nicht automatisch einer hohen semantischen Korrektheit. Halten Sie diese Kennzahlen getrennt und vergleichen Sie eine Stichprobe der akzeptierten Ergebnisse mit den ursprünglichen Quellen.

Um Fehler zu untersuchen, ohne unnötige Daten zu speichern, halten Sie die Schema-Version, gegebenenfalls die Kennung von Kanal und Modell, den finalen Antwortstatus, das Ergebnis jeder Validierungsschicht und die anschließende Entscheidung fest. Speichern Sie die Eingabe oder eine sichere Referenz darauf nur, wenn die Datenrichtlinie dies erlaubt. Bewahren Sie sensible Informationen nicht standardmäßig auf, wenn eine Referenz, eine technische Zusammenfassung oder ein Fehlersignal ausreicht.

Versionieren Sie den Datenvertrag und ordnen Sie Änderungen nach ihrer Wirkung. Ein optionales Feld hinzuzufügen kann kompatibel sein, wenn Verbraucher darauf vorbereitet sind, es zu ignorieren. Den Datentyp eines Feldes zu ändern, die Bedeutung einer Kategorie zu verändern oder ein optionales Feld verpflichtend zu machen, kann Verbraucher hingegen beeinträchtigen. Testen Sie Verbraucher und Migrationen vor der Bereitstellung von Änderungen. Bewahren Sie außerdem genügend Protokolldaten auf, um festzustellen, welche Version die jeweiligen Daten erzeugt hat.

Abschließender Maßstab: Akzeptieren Sie nur, was für den jeweiligen Zweck geprüft wurde

Ob eine Ausgabe akzeptiert werden kann, hängt davon ab, wofür sie bestimmt ist. Ein für eine Person sichtbarer Entwurf kann Unsicherheit zulassen, wenn er eindeutig gekennzeichnet ist. Für bestätigte Buchhaltungsdaten oder eine externe Operation sind strengere Kontrollen erforderlich. Ein einzelnes Schema kann diese Unterschiede nicht abbilden: Der Vertrag beschreibt die Form, Geschäftsregeln prüfen die Bedeutung, und Berechtigungen steuern die Aktion.

Bevor Sie den Ablauf in Betrieb nehmen, sollten Sie beantworten können, was geprüft wird, wo die Prüfung stattfindet, welche Belege die einzelnen Werte stützen, was bei einem fehlgeschlagenen Check passiert und wer den nächsten Schritt freigeben darf. Wenn die Anwendung nicht zwischen Vorschlag, verifiziertem Datum und genehmigter Aktion unterscheiden kann, ist sie noch nicht bereit, der Ausgabe zu vertrauen.

Weiter entdecken

Korrekturen und Transparenz

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