Blog • AWS / Bedrock

Claude-Structured Outputs auf Amazon Bedrock garantieren JSON-Form—warum brauchen Batch-Logs und kopierte Chats trotzdem eine lokale Drei-Schritte-Prüfung?

Am 19. Oktober 2026 kündigte AWS Structured Outputs für Claude auf Bedrock an: Constrained Decoding mit JSON Schema, Schema über output_config, strict tools, additionalProperties:false. Batch und Streaming eingeschlossen.

Ein vollständiger Vergleich der Structured-Output-Pfade steht in dem Structured-Output-Leitfaden 2026. Schema-gültig ersetzt keine Rechteprüfung—siehe den Artikel schema reicht nicht. Wie JSON Schema Tools und Antworten verbindet, steht in warum KI JSON Schema braucht. Dieser Artikel behandelt nur die drei lokalen Schritte nach Bedrock.

• Bedrock-Anfragen hängen JSON Schema unter output_config.format mit additionalProperties:false.
• Die API garantiert die Form einer Invoke-Antwort—not Logdateien, Batch-Ausgaben oder Konsolenkopien.
• Lokale Pipeline: (1) JSON Schema validate, (2) JSON repair nach markdown-Fences, (3) JSONL-Zeilenprüfung für Batch.
• Ein TICKET_SCHEMA für API-Samples, Logzeilen und Batch-Zeilen—enum-Fehler, fehlende und zusätzliche Keys lokal stoppen.

Was fügte Bedrock am 19. Oktober für Claude hinzu?

AWS schreibt in dem offiziellen What's-New-Post: Claude auf Bedrock unterstützt Structured Outputs mit Constrained Decoding, strict tools, Batch und Streaming.

Technische Details stehen im AWS-Machine-Learning-Blog. Die API-Garantie ist nicht das Ende der Log-Pipeline.

Wie hängen Sie JSON Schema in output_config?

Bedrock setzt output_config.format.type auf json_schema und legt die Objektdefinition in schema. additionalProperties:false am Root. Das Beispiel nutzt ticket_id, priority (enum), summary.

{
  "anthropic_version": "bedrock-2023-05-31",
  "max_tokens": 1024,
  "messages": [
    {
      "role": "user",
      "content": "Return one support ticket as JSON."
    }
  ],
  "output_config": {
    "format": {
      "type": "json_schema",
      "schema": {
        "type": "object",
        "additionalProperties": false,
        "required": ["ticket_id", "priority", "summary"],
        "properties": {
          "ticket_id": { "type": "string" },
          "priority": { "enum": ["low", "medium", "high"] },
          "summary": { "type": "string", "maxLength": 200 }
        }
      }
    }
  }
}

Batch landet oft als JSONL—eine Zeile pro Datensatz. Streaming-Antworten werden clientseitig zusammengefügt und eingefügt—ohne zweite Prüfung durch Bedrock.

Warum lokal validieren, wenn die API die Form garantiert?

Der Invoke-Body ist bei Bedrock schema-geformt, gespeicherte Artefakte verformen sich: Log-Präfixe, CloudWatch-Escapes, ```json-Fences, leere oder abgeschnittene Batch-Zeilen.

{
  "ticket_id": "TCK-1042",
  "priority": "high",
  "summary": "Bedrock batch row passed constrained decoding"
}

Wird priority urgent oder owner taucht auf, feuern SLA-Regeln falsch. SAMPLE_BAD zeigt enum-Verletzung—mit demselben TICKET_SCHEMA stoppen.

{
  "ticket_id": "TCK-1042",
  "priority": "urgent",
  "summary": "enum value not in schema"
}

Welches TICKET_SCHEMA lokal?

Nutzen Sie JSON Schema , um Felder und enums zu fixieren. priority nur low/medium/high; additionalProperties:false lehnt unbekannte Keys ab. Bestehen heißt nur gültige Form.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "additionalProperties": false,
  "required": ["ticket_id", "priority", "summary"],
  "properties": {
    "ticket_id": {
      "type": "string",
      "description": "Support ticket ID, e.g. TCK-1042"
    },
    "priority": {
      "enum": ["low", "medium", "high"]
    },
    "summary": {
      "type": "string",
      "maxLength": 200
    }
  }
}

Was behebt jeder Schritt der lokalen Pipeline?

Bedrock ist Online-Decoder, JSONNote die Offline-QA. Reihenfolge: schema-konformes JSON, Fence-Repair, JSONL-Zeilen.

Wie laufen die drei Schritte in JSONNote?

1. 1
   Schritt 1: Schema validate

   Öffnen Sie JSON Schema. TICKET_SCHEMA ins erste Feld, SAMPLE_OK oder Log-JSON ins zweite.

2. 2
   Schritt 2: Fence-Repair

   Öffnen Sie JSON Repair. Chat mit ```json-Fences einfügen, entfernen, erneut Schema prüfen.

3. 3
   Schritt 3: JSONL-Zeilen

   Öffnen Sie JSONL-Tool. Bedrock-Batch hochladen, jede Zeile parse prüfen; TICKET_SCHEMA für enum vs. Abschnitt.

Häufige Fragen

Kann ich lokales Validate mit Bedrock Structured Outputs überspringen?

Nein. Die API garantiert nur den aktuellen Invoke-Body. Logs, Batch, Kopien und Caches brauchen dieselbe schema-Prüfung in der App.

Wie hängen strict tools und output_config schema zusammen?

Beide nutzen JSON Schema beim Decoding, aber verschiedene Schichten: Tool-Argumente vs. output_config. Schemas getrennt für lokale Checks speichern.

Muss ich den ganzen Batch neu laufen lassen, wenn eine JSONL-Zeile scheitert?

Nicht zwingend. JSONL-Tool für Zeilennummern, TICKET_SCHEMA für enum, Abschnitt oder Syntax. Nur Fehlzeilen erneut—günstiger als ganzer Batch.

Sollte das lokale Schema auch additionalProperties:false setzen?

Ja. Bedrock-Request-schema und lokales TICKET_SCHEMA angleichen—sonst widersprechen API und Ingest.

Brauchen Streaming-Antworten auch JSONL-Checks?

Streaming: eine Antwort zusammenfügen, dann Schema + Repair. JSONL nur bei mehrzeiligen Batch-Dateien.

Fazit

Bedrock Structured Outputs sperren Claude-API-Antworten in JSON Schema; Batch, Streaming, Logs und Paste verformen weiter.

Die Entscheidung: online Bedrock output_config; offline dasselbe TICKET_SCHEMA, Repair für Fences, JSONL für Batch-Zeilen.

Zurück zum Blog