structured-outputlisted

# Structured Output ## Purpose Get reliably parseable, correctly typed data out of a language model. The naive approach — asking for JSON in the prompt and calling `json.loads` — fails often enough to be a production incident. ## When to Use - Extracting fields from unstructured text. - Classification with a fixed set of labels. - Any LLM output consumed by code rather than read by a human. - A pipeline that fails intermittently on parse errors. ## Capabilities - Schema design that models follow reliably. - Native structured output: JSON schema mode, tool calling, constrained decoding. - Validation, repair, and retry. - Confidence and abstention: letting the model say it does not know. - Extraction from long, messy, or partially irrelevant documents. ## Inputs - The target schema and the semantics of each field. - The input text and how messy it actually is. - What should happen when a field is genuinely absent. ## Outputs - Validated, typed objects. - An explicit representation of absence, distinct from a guess. - A measured extraction accuracy per field. ## Workflow 1. **Use the API's native mechanism** — JSON schema mode or tool calling constrains the decoder so that malformed output is structurally impossible. Asking for JSON in prose does not. 2. **Design the schema for a model, not a database** — Descriptive field names, enums instead of free strings, and a description on every field explaining what belongs in it. The schema is documentation the model reads.