Wenn eure Anwendung JSON immer noch mit einer Regex und einer Retry-Schleife aus Modell-Prosa herauszieht, löst ihr ein Problem, das Amazon Bedrock inzwischen auf der Decoding-Ebene löst. Structured Outputs, seit Februar 2026 allgemein verfügbar auf Bedrock, zwingen das Modell während der Token-Generierung auf ein JSON Schema, sodass die Antwort konstruktionsbedingt der gewünschten Form entspricht statt aus Hoffnung. Die Regex war nie die Lösung. Sie war das Symptom dafür, ein Modell zu bitten, "bitte JSON zurückzugeben", und dann aufzuräumen, wenn es das nicht tat.

Der Parsing-Ansatz scheitert auf eine Art, die genau deshalb ärgerlich ist, weil sie selten ist. Irgendwas über neunzig Prozent der Antworten parsen sauber. Der Rest wickelt das JSON in einen Markdown-Fence, fügt einen freundlichen Satz davor ein, hängt ein Komma an oder halluziniert ein Feld. Der Parser wirft dann in Produktion einen Fehler, bei einem Input, den man nicht getestet hat, im schlechtesten Moment. Constrained Decoding entfernt diese ganze Fehlerklasse, weil das ungültige Token erst gar nicht erzeugt wird.

Drei Wege zu Struktur, nach Stärke geordnet

Prompt-and-Pray

Man bittet im System-Prompt um JSON, gibt vielleicht ein Beispiel und parst den Text. Das funktioniert, bis es nicht mehr funktioniert. Es gibt keine Garantie, keine Durchsetzung, und die Fehlerrate ist genau der Tail, der in einer Demo nie auftaucht. Jede Stunde, die man in die Härtung des Parsers steckt, ist eine Stunde für ein Problem, das die Plattform beseitigen kann.

Tool Use als Schema

Lange vor nativen Structured Outputs war der zuverlässige Trick, ein Tool zu definieren, dessen Input-Schema die gewünschte Form ist, und dann die Tool-Call-Argumente statt des Nachrichtentexts zu lesen. Das Modell füllt die Tool-Inputs, und man erhält ein strukturiertes Objekt. Das ist immer noch ein gutes Muster, wenn derselbe Aufruf auch tatsächlich Tools aufrufen muss. Auf Bedrock kann man jetzt strict: true zu einer Tool-Definition hinzufügen, sodass Tool-Name und Inputs gegen das Schema validiert werden statt nur davon nahegelegt zu sein.

Native Structured Outputs

Der direkte Weg ist, die Antwortform als JSON Schema zu deklarieren und Bedrock sie während der Generierung erzwingen zu lassen. Es nutzt JSON Schema Draft 2020-12 und Constrained Decoding, sodass das Modell physisch kein Token ausgeben kann, das das Schema brechen würde. In der Converse API heißt das Feld outputConfig.textFormat, und das Schema braucht einen name. Es ist verfügbar über Converse, ConverseStream, InvokeModel und InvokeModelWithResponseStream für Anthropic Claude 4.5 und eine Reihe von Open-Weight-Modellen.

// Converse: enforce the shape instead of parsing for it
outputConfig: {
  textFormat: {
    jsonSchema: {
      name: "extraction",
      schema: {
        type: "object",
        properties: {
          invoice_id: { type: "string" },
          total_cents: { type: "integer" },
          currency: { type: "string", enum: ["USD", "EUR", "GBP"] }
        },
        required: ["invoice_id", "total_cents", "currency"],
        additionalProperties: false
      }
    }
  }
}

Was die Durchsetzung bringt

Der offensichtliche Gewinn ist, dass der Output parst. Der größere Gewinn ist, was man löschen darf: die Retry-on-invalid-Schleife, die JSON-Repair-Bibliothek, den defensiven Re-Prompt, der sagt "du hast ungültiges JSON zurückgegeben, versuch es nochmal", und den Alert, der feuert, wenn all das trotzdem scheitert. Jedes davon kompensierte einen probabilistischen Output. Sobald das Schema beim Decoding erzwungen wird, ist die Kompensation toter Code. Weniger Retries bedeutet auch weniger Tokens und niedrigere Latenz, weil man nicht für einen zweiten Aufruf bezahlt, um den ersten zu reparieren.

Man setzt additionalProperties: false und markiert Felder als required, damit das Schema eng ist. Ein loses Schema, das zusätzliche Keys erlaubt, gibt einen Teil der gerade erkauften Garantie wieder zurück, weil das Modell immer noch Felder anhängen kann, mit denen der eigene Code nicht rechnet.

Wo es nicht anwendbar ist

Structured Output ist für maschinenlesbare Antworten: Extraktion, Klassifikation, Routing, Funktionsargumente, alles, was ein nachgelagertes System konsumiert. Es ist das falsche Werkzeug für Prosa, die ein Mensch liest, wo ein starres Schema dem Zweck widerspricht. Und es erzwingt Form, nicht Wahrheit. Ein Schema garantiert, dass total_cents eine Ganzzahl ist, nicht dass es die richtige Ganzzahl ist. Die Validierung von Werten, Bereichen und Geschäftsregeln bleibt weiterhin eure Aufgabe. Das Schema beseitigt den Parsing-Fehlermodus. Es beseitigt nicht die Notwendigkeit zu prüfen, ob das Modell die Antwort korrekt hatte.

Das Fazit

Cleveres Parsing ist Aufwand, der eine Garantie umgeht, die das Modell nie gegeben hat. Bedrock Structured Outputs verlagern die Garantie in den Decoder: ein JSON Schema deklarieren, und die Antwort ist konstruktionsbedingt gültig. Man nutzt native Structured Outputs für reine Daten, Tool-Use-Schemas, wenn derselbe Aufruf auch handelt, und behält die wertebasierte Validierung in jedem Fall bei. Dann löscht man die Regex, die Repair-Schleife und den Retry. Sie waren Gerüst für ein Problem, das man nicht mehr hat.

Weiterlesen

Für die Plattform- und Delivery-Seite, das zuverlässig auszuliefern, gibt es die Cloud-Notizen auf ercan.cloud, und der Hub ist unter ercanermis.com.