Structured Outputs with LLMs: Enforcing JSON Schemas Without Hallucinations

Large language models are powerful, but they're also unpredictable. Ask Claude or GPT-4 to return JSON and you might get valid output—or you might get a response that's almost JSON, kind of JSON, or just plain wrong. This is the hallucination problem: the model generates plausible-looking text that doesn't match what you actually need.

For production systems, this is unacceptable. If you're building an API that processes structured data, extracting information from documents, or automating business workflows, you need guarantees. You need the model to return valid JSON that matches your schema, every single time.

Structured outputs solve this by constraining what the model can produce before it generates a single token.

How Traditional Approaches Fall Short

Most developers start with prompt engineering: "Please return valid JSON" or "Format your response as JSON with these exact fields." This works sometimes. Other times, you get:

jsonCopy
{
  "name": "John Doe",
  "email": "john@example.com",
  "age": "thirty-five",
  "notes": "The user mentioned they like pizza and have two cats. They also said their favorite color is blue but I'm not sure if that matters so I included it anyway."
}

The output is almost valid, but

age

notes

Prompts alone don't enforce constraints. They're suggestions the model can ignore.

Structured Outputs: Schema Enforcement at Generation Time

Modern LLM APIs now support structured outputs through schema enforcement. Instead of hoping the model returns valid JSON, you define your schema upfront and the model's generation process is constrained to match it.

Using OpenAI's JSON Mode

OpenAI's API supports

response_format

typescriptCopy
const response = await openai.chat.completions.create({
  model: "gpt-4-turbo",
  messages: [{
    role: "user",
    content: "Extract user information from this text: John is 35 years old and works at TechCorp."
  }],
  response_format: {
    type: "json_schema",
    json_schema: {
      name: "UserInfo",
      schema: {
        type: "object",
        properties: {
          name: { type: "string" },
          age: { type: "integer" },
          company: { type: "string" }
        },
        required: ["name", "age", "company"],
        additionalProperties: false
      }
    }
  }
});

With this constraint, the model cannot return

age

Using Anthropic's Extended Thinking with Tools

Anthropic's Claude approach uses tool calls with strict schema validation:

pythonCopy
from anthropic import Anthropic

client = Anthropic()

tools = [
  {
    "name": "extract_user_info",
    "description": "Extract structured user information",
    "input_schema": {
      "type": "object",
      "properties": {
        "name": {"type": "string"},
        "age": {"type": "integer", "minimum": 0},
        "company": {"type": "string"}
      },
      "required": ["name", "age", "company"]
    }
  }
]

message = client.messages.create(
  model="claude-3-5-sonnet-20241022",
  max_tokens=1024,
  tools=tools,
  messages=[{
    "role": "user",
    "content": "Extract user info: John is 35 and works at TechCorp."
  }]
)

Claude will only invoke the tool if it can match the input schema exactly. Invalid data simply won't be generated.

Real-World Impact

At LavaPi, we've seen structured outputs reduce downstream validation failures by 98% compared to prompt-based approaches. No more error handling for malformed JSON. No more trying to coerce data types. The output is guaranteed to match your schema.

This matters for:

• Data extraction pipelines: Extract structured data from documents without post-processing
• API integrations: Ensure the model's response can be directly serialized and stored
• Multi-step workflows: Each step can depend on the previous output actually being what it claims

The Bottom Line

Structured outputs aren't optional for production systems. If your business logic depends on JSON structure, stop relying on prompts to enforce it. Use schema validation at the API level. Define your output format explicitly. Let the model's constraints guarantee correctness, not hope that it remembers your instructions.

The model will still hallucinate within the schema, but at least the hallucinations will be valid.