← Voltar aos guias

Reliable LLM Output: A Practical JSON Guide

Why LLM output becomes inconsistent

Large language models are designed to generate useful language, not to behave like traditional functions. If you ask for customer data, one response might use email, while another uses email_address. A model may also add an introduction before the JSON, omit a field, return a number as text, or use a different date format.

This inconsistency becomes a problem when your application needs to parse responses automatically. The most reliable solution is to treat the model response as structured data with explicit rules, validation, and a recovery path.

1. Define the output contract first

Before writing a prompt, decide exactly what your application expects. Document the field names, data types, required fields, allowed values, and formatting rules.

• Use stable field names such as customer_name and order_total.
• Specify types: string, number, boolean, array, or object.
• Define what happens when information is missing, such as returning null.
• Choose one date format, preferably ISO 8601, such as 2026-04-15.
• List allowed values for categories instead of accepting arbitrary text.

A simple contract might require an object with sentiment, confidence, and reasons. Sentiment could be limited to positive, neutral, or negative; confidence could be a number from 0 to 1; and reasons could always be an array of strings.

2. Make the prompt explicit and boring

Prompts that ask for a format indirectly often produce unreliable results. State the output rules near the end of the instruction, where they are easy for the model to follow.

For example: Return exactly one JSON object. Do not include Markdown, explanations, or code fences. Use these keys: sentiment, confidence, reasons. If the sentiment cannot be determined, use neutral and explain why in reasons.

Include a small valid example when the format is unfamiliar. Examples should show the exact types you expect, including empty arrays and null values. Avoid showing several competing formats, because models may combine them.

3. Use structured response features when available

Prompt instructions help, but native structured-output features are stronger. Depending on the model and SDK, you may be able to provide a JSON Schema or request JSON mode. A schema can enforce required properties, reject unexpected keys, and constrain values with an enum.

For instance, a classification schema can require sentiment to be one of three strings and confidence to be a numeric value between 0 and 1. Check the model documentation before assuming every model supports every schema feature. Some APIs support valid JSON but do not enforce every schema constraint.

4. Validate every response in your code

Never assume that a response is valid because the prompt requested JSON. Parse it and validate it at the application boundary. In JavaScript, libraries such as Zod or Ajv can validate objects against a schema. In Python, Pydantic is a practical choice.

Validation should check both syntax and meaning. A response can be valid JSON but still contain an empty customer ID, an impossible date, or a confidence value of 8 instead of 0.8. Log validation failures with a request ID, model name, and schema version, while removing private user data from logs.

5. Add a controlled retry strategy

When validation fails, send a repair request that includes the specific error rather than repeating the original prompt unchanged. Tell the model to return only the corrected object. Limit retries to one or two attempts so a malformed response cannot create an expensive or infinite loop.

For higher-risk workflows, use a fallback path: place the item in a review queue, return a safe default, or ask a human to confirm it. Do not silently transform uncertain model output into trusted data.

6. Keep model and generation settings stable

Use a low temperature for extraction, classification, and other tasks where repeatability matters. Keep the model version, system prompt, schema, and token limits under version control. Small changes to any of these can alter output behavior, so test representative inputs before deployment.

Run a small evaluation set containing normal cases, missing information, unusual wording, long inputs, and adversarial instructions. Measure valid-output rate, field-level accuracy, and retry rate rather than judging a few examples manually.

Use a cost-effective API connection

Consistent formatting depends on your contract and validation code, but API cost also affects how often you can test and improve the system. 59API provides pay-as-you-go access to native Claude models, including Opus, Sonnet, Haiku, and Fable, as well as GPT models. It is compatible with Claude Code, Codex, and OpenAI SDKs through the base URL https://api.59api.com.

Because 59API is positioned as a low-cost relay without downgrading the underlying official-quality models, it can be a practical choice for running evaluation sets, retries, and production workloads. Its referral rebate can also reduce costs for eligible users. Sign up for 59API when you are ready to test a structured-output workflow with real requests.

Preços · Docs