Strukturierte KI-Ausgaben: Formate definieren, erzwingen und zuverlässig validieren

1. Das Schema vom nachgelagerten Anwendungsfall her entwerfen

Eine strukturierte Ausgabe ist eine Modellantwort, die einer vorgesehenen Datenform entspricht, etwa einem JSON-Objekt mit festgelegten Feldern. Das Ziel ist nicht bloß, dass die Antwort „wie JSON aussieht“, sondern dass das empfangende System sie konsistent interpretieren kann. Beginnen Sie deshalb beim nachgelagerten Verbraucher und arbeiten Sie rückwärts: Ermitteln Sie, welche Felder er benötigt, was er damit tun wird und was geschehen soll, wenn die Eingabe die angefragten Informationen nicht enthält.

Halten Sie das Schema so klein wie möglich, ohne den Anwendungsfall zu beeinträchtigen. Dokumentieren Sie für jedes Feld den Typ, die Pflichtangabe, zulässige Werte, Einheiten und die erwartete Herkunft. Legen Sie außerdem fest, wie fehlende Daten dargestellt werden. Ein Nullwert, eine leere Zeichenfolge und ein ausgelassenes Feld können unterschiedliche Bedeutungen haben. Verwenden Sie sie nicht ohne ausdrückliche Regel austauschbar. Soll ein Datum beispielsweise in eine Datenbank übernommen werden, ist ein normalisiertes Format mit definierter Zeitzone oft geeigneter als eine Angabe wie „am Freitag“.

Trennen Sie die Struktur von den semantischen Anweisungen. Ein Schema kann verlangen, dass `datum` eine Zeichenfolge ist; es verhindert jedoch nicht von selbst, dass das Modell ein Datum erfindet. Feldbeschreibungen und Prompt können die Extraktion lenken, doch die Anwendung muss festlegen, welche Belege sie akzeptiert und welches Ergebnis gilt, wenn sie keine findet. Eine sichere Möglichkeit ist ein expliziter Status wie `nicht_gefunden` oder ein Belegfeld, statt das Modell zu einer positiven Antwort zu zwingen.

Die Dokumentation zu Azure OpenAI beschreibt, wie eine JSON-Schemadefinition in einem Inferenzaufruf verwendet wird, und zeigt Beispiele mit Pydantic und Zod. Auch die Gemini-Dokumentation erläutert JSON-Antworten, die einem Schema folgen, und Beispiele zur Verwendung von Datenmodellen. Diese dokumentierten Funktionen gelten für die beschriebenen APIs und Konfigurationen; sie belegen nicht, dass alle Schemata, Modelle oder Anbieter dieselben Einschränkungen unterstützen.

2. Den Ausgabemechanismus passend zu Aufgabe und Anbieter wählen

Es gibt drei gängige Ansätze, die jedoch nicht gleichwertig sind. Beim reinen Prompting wird das Modell in natürlichsprachlichen Anweisungen aufgefordert, ein bestimmtes Format zurückzugeben. Das kann für einen Prototyp oder eine Ausgabe, die nur von Menschen gelesen wird, ausreichen. Das Format kann jedoch instabil werden: etwa durch Erläuterungen außerhalb des JSON, unerwartete Schlüssel oder Werte mit falschen Typen. Wenn das Ergebnis in Code einfließt, ist dieser Ansatz weniger kontrollierbar; die Antwort muss daher immer validiert werden.

Der JSON-Modus fordert eine JSON-Antwort an. Die Dokumentation zu Azure unterscheidet diesen Modus von strukturierten Ausgaben mit Schema: Er garantiert gültiges JSON, aber nicht die strikte Einhaltung des vorgegebenen Schemas. Dass sich eine Antwort als JSON parsen lässt, beweist folglich nicht, dass sie die Schlüssel, Typen oder Einschränkungen enthält, die die Anwendung benötigt.

Strukturierte Ausgaben mit Schema ermöglichen es, eine Definition bereitzustellen, die die Form der Antwort lenkt. Die Azure-Dokumentation zeigt diesen Mechanismus in Feldern für das Antwortformat sowie Beispiele für die Integration mit Pydantic und Zod. Auch Gemini dokumentiert die Konfiguration einer schema-basierten JSON-Antwort und Beispiele für Extraktion und Klassifizierung. Die konkrete Verfügbarkeit hängt von API, Modell und Konfiguration ab. Prüfen Sie deshalb die aktuelle Dokumentation des tatsächlich verwendeten Endpunkts, statt anzunehmen, dass ähnlich benannte Produkte identisch funktionieren.

Funktions- oder Tool-Aufrufe eignen sich, wenn das Modell Argumente für eine in der Anwendung verfügbare Operation vorschlagen soll, etwa für die Abfrage einer Bestellung. Sie sind weder mit der Ausführung der Funktion noch mit der Prüfung ihrer Sicherheit gleichzusetzen: Der Server muss die Argumente validieren und eigene Kontrollen anwenden, bevor er handelt. Für den in der Azure-Dokumentation beschriebenen Einsatz strukturierter Ausgaben bei Funktionsaufrufen gilt der Hinweis, dass parallele Aufrufe nicht unterstützt werden und in dieser Konfiguration deaktiviert werden sollten. Übertragen Sie diese Einschränkung nicht ohne Prüfung auf andere APIs.

Als Auswahlregel gilt: Verwenden Sie eine schemabasierte Ausgabe, wenn das Hauptziel ein Objekt nach einer Definition ist; verwenden Sie einen Funktionsaufruf, wenn das Modell eine Operation auswählen und Argumente dafür vorschlagen soll; und setzen Sie reines Prompting eher in weniger kritischen Umgebungen oder dann ein, wenn eine strikte lokale Validierung die geringere Steuerbarkeit ausgleicht. In jedem Fall muss die Antwort Anwendungsprüfungen bestehen, bevor sie ein nachgelagertes System erreicht.

3. Die Struktur prüfen, bevor die Antwort verarbeitet wird

Die erste Schranke ist ein Parser für das erwartete Format. Bei JSON muss er ungültigen Text, abgeschnittene Werte und Inhalte zurückweisen, die sich nicht in ein Objekt umwandeln lassen. Liefert der Anbieter eine Antwort bereits durch ein SDK geparst, prüfen Sie trotzdem den Abschlussstatus, Ablehnungen und Felder, die auf eine unvollständige Antwort hindeuten können. Gehen Sie nicht davon aus, dass immer ein verwendbares Ergebnis vorliegt.

Die zweite Schranke ist die Validierung anhand eines lokalen Schemas. JSON Schema kann unter anderem Typen, Pflichtfelder, Wertelisten, Längenbeschränkungen und Regeln für zusätzliche Eigenschaften ausdrücken. Validierungsbibliotheken können daraus konkrete Fehler machen, bevor die Ausgabe eine Datenbank oder API erreicht. Die genaue Implementierung hängt von Sprache und Schema-Version ab. Prüfen Sie, ob die gewählte Bibliothek mit den Schlüsselwörtern und dem Dialekt Ihres Vertrags kompatibel ist, und testen Sie die Kombination in der Continuous Integration.

Übernehmen Sie das vom Anbieter akzeptierte Schema nicht ungeprüft als endgültigen Anwendungskontrakt. Ein Anbieter kann nur eine Teilmenge der Regeln akzeptieren oder ein Datenmodell aus einer Bibliothek in eine API-kompatible Definition umwandeln. Pflegen Sie eine maßgebliche Version Ihres Vertrags. Wenn der Anbieter eine vereinfachte Darstellung verlangt, erzeugen oder übertragen Sie das Schema für den Aufruf, ohne kritische lokale Regeln zu entfernen.

Validieren Sie an den Systemgrenzen strikt. Lehnen Sie unerwartete Eigenschaften ab, wenn sie das Verhalten beeinflussen könnten. Konvertieren Sie Typen nur, wenn die Umwandlung eindeutig und dokumentiert ist, und versuchen Sie nicht, zweifelhafte Werte automatisch zu „reparieren“. Muss ein Feld eine Ganzzahl sein, ist die Umwandlung von `12,5` in `12` keine harmlose Korrektur: Sie kann die Bedeutung verändern. Speichern Sie den Fehler, die Anforderungskennung und die Schemasversion, damit sich Fehler untersuchen lassen, ohne fehlerhafte Daten stillschweigend anzunehmen.

4. Inhalte prüfen und Unsicherheit abbilden

Eine strukturell korrekte Antwort kann semantisch falsch sein. Um diesen Unterschied zu messen, prüfen Sie die Felder anhand der ursprünglichen Eingabe und verfügbarer Referenzquellen – nicht anhand der sprachlichen Flüssigkeit der Modellerklärung. Bewahren Sie bei der Extraktion ausreichend Textbelege auf, damit sich die Fundstelle im Dokument finden lässt. Speichern Sie bei einer Klassifizierung die Regel oder das Signal, das die Kategorie begründet. Kennzeichnen Sie bei Anreicherungen, welche Werte aus der Eingabe stammen und welche von einer autorisierten externen Quelle abhängen.

Gestalten Sie Unsicherheit ausdrücklich. Je nach Anwendungsfall kann das ein Nullwert mit Status, eine Liste möglicher Kandidaten oder eine Markierung zur Prüfung sein. Fordern Sie keinen Konfidenzprozentsatz an, ohne festzulegen, was er bedeutet und wie er kalibriert wird: Eine vom Modell selbst erzeugte Zahl ist für sich genommen keine überprüfte Wahrscheinlichkeit. Wenn Sie einen Score verwenden, messen Sie ihn anhand eines gelabelten Datensatzes und bestimmen Sie Schwellenwerte nach den Kosten von Fehlern und Prüfungen, nicht nach dem Bauchgefühl.

Die menschliche Prüfung sollte ein normaler Pfad der Pipeline sein und keine improvisierte Ausnahme. Leiten Sie mehrdeutige Fälle, Fälle ohne Belege, Verstöße gegen Geschäftsregeln und Entscheidungen mit hohen Auswirkungen zur Prüfung weiter. Die prüfende Person benötigt Eingabe, vorgeschlagene Ausgabe, Beleg und Grund für die Eskalation. Wird eine menschliche Korrektur als Trainingsdatum oder Regressionstest gespeichert, dokumentieren Sie auch ihre Herkunft und die anwendbare Richtlinie.

Die hier verfügbare Evidenz belegt schema-basierte Ausgabefunktionen für Azure OpenAI und Gemini, quantifiziert aber nicht die Fehlerraten bei Format gegenüber semantischen Fehlern. Sie erlaubt auch keine Festlegung eines universellen Konfidenzschwellenwerts. Messen Sie deshalb beide Fehlerarten für Ihre konkrete Aufgabe: Eine niedrige Rate ungültigen JSONs beweist keine korrekte Extraktion, und ein gutes Ergebnis auf einer kleinen Stichprobe garantiert kein entsprechendes Verhalten in der Produktion.

5. Das System testen und sein Verhalten im Betrieb überwachen

Erstellen Sie vor der Bereitstellung eines geänderten Prompts, Schemas, Modells oder SDKs einen Regressionstestdatensatz mit repräsentativen Beispielen und Grenzfällen. Nehmen Sie saubere, unvollständige und widersprüchliche Eingaben, unerwartete Zeichen, lange Dokumente und Fälle auf, in denen die richtige Antwort „nicht gefunden“ lautet. Halten Sie für jeden Fall eine überprüfbare Erwartung fest: erwartetes Ergebnis, Felder, die fehlen müssen, und Bedingungen, die eine Eskalation auslösen.

Messen Sie syntaktische Gültigkeit, Schemakonformität, Genauigkeit einzelner Felder und Eskalationsrate getrennt. Eine einzige zusammengefasste Kennzahl kann verbergen, dass das System perfektes JSON ausgibt, aber falsch klassifiziert, oder die meisten Felder richtig erkennt und ausgerechnet bei besonders folgenreichen Feldern versagt. Segmentieren Sie Ergebnisse nach Eingabetyp, Modellversion, Promptvorlage und Schemasversion.

Erfassen Sie in der Produktion Metriken, mit denen sich Verschlechterungen erkennen lassen: nicht parsebare Antworten, Validierungsfehler, Nullfelder, Werte außerhalb des erlaubten Bereichs, Abweichungen von Referenzquellen und Anteil menschlicher Prüfungen. Definieren Sie Alarme und einen Wiederherstellungspfad, etwa das Zurückhalten zweifelhafter Datensätze oder die Rückkehr zu einer früheren Version. Speichern Sie in Protokollen nicht unnötig sensible Daten; bewahren Sie nur das auf, was zur Fehlersuche, Prüfung und Einhaltung der geltenden Richtlinie erforderlich ist.

Wiederholen Sie vor einem Anbieter- oder Mechanismuswechsel die Tests mit derselben Stichprobe und denselben Abnahmekriterien. Dokumentierte Funktionen sind nicht in allen Einzelheiten austauschbar, und eine Migration kann verändern, welche Einschränkungen unterstützt werden oder wie Antworten dargestellt sind. Behandeln Sie die Produktionskonfiguration als Teil des Vertrags: Anbieter, Endpunkt, Modell, Schema, SDK, Prompt und Wiederholungsrichtlinie müssen versioniert und nachvollziehbar sein.

Weiter entdecken

Korrekturen und Transparenz

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