Why Do Small Local Models Hallucinate More During JSON Output?

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

Small local models hallucinate more during JSON output because they must solve the task while also preserving a rigid schema and valid syntax.

A home AI workflow may ask a compact model to extract filenames, dates, tags, device states, or automation arguments and return them as machine-readable JSON. The model is not performing one job. It must identify the correct facts, map them to the intended fields, respect required types and enums, remember punctuation and nesting, and stop without adding commentary. When model capacity is limited, these constraints compete with the reasoning needed to keep the values grounded.

JSON Makes Correctness a Two-Layer Problem

The answer must be semantically correct and structurally valid at the same time. A free-form answer can express uncertainty or explain a missing value, while a JSON contract often requires the model to choose a field value even when the evidence is weak.

Research on the validity-correctness tradeoff shows why these measurements must remain separate: stronger output constraints can improve schema validity while the selected values become less accurate.

The pressure is more visible in a small local model because it has less spare capacity for instruction tracking, extraction, and serialization. A larger model can still invent a field, but a compact model reaches the point where format compliance displaces answer quality sooner.

A Valid Object Can Still Contain a Hallucinated Answer

Constrained decoding can prevent an illegal brace, unknown key, or invalid enum from being emitted. It cannot prove that the chosen customer ID, date, path, or status is present in the source material.

vLLM describes JSON-schema constraints as a way to restrict the form of generated output. The decoder narrows which tokens are legal next, but the model still supplies the meaning carried by those legal tokens.

This creates a dangerous failure mode for automation: the object parses successfully, so downstream code trusts it, yet one field is fabricated. Validate business rules and source evidence after schema validation instead of treating parse success as factual correctness.

Nested Schemas Increase Branching and State Tracking

Every required property, optional branch, nested array, nullable field, and enum adds state that the model must track across the generation. Similar key names or repeated object shapes make it easier to place a correct value in the wrong location.

The llama.cpp guide to grammar-constrained JSON distinguishes the allowed output grammar from the prompt that explains what the fields mean. A grammar can enforce structure, but the schema still needs clear semantic instructions.

Reduce the number of simultaneous decisions. Flatten deeply nested objects, remove unused optional fields, use distinct key names, and split a large extraction into smaller objects when the local model repeatedly swaps or fills unrelated fields.

JSON-Only Prompts Can Suppress Useful Reasoning

A strict “return JSON only” instruction pushes the model to package an answer immediately. For a difficult extraction, that can cause an early field choice before the model has compared competing passages or resolved an ambiguous date.

Hugging Face evaluations show prompt-format sensitivity: changing the expected structure and the space available for reasoning can change task performance even when the underlying question is the same.

Do not expose private chain-of-thought, but separate internal task resolution from final serialization. The workflow can first extract a compact evidence record or make a deterministic lookup, then ask the model to render only the verified fields.

Prompted JSON and Constrained Decoding Fail Differently

Prompt-only JSON can add code fences, commentary, duplicate keys, trailing commas, or an unfinished object. Constrained decoding removes many syntax failures, but it can force the model to choose among valid values when “unknown” was not allowed.

Fireworks explains how schema-restricted token choices keep generation inside an output contract while still requiring the prompt to describe the intended data accurately.

Track both failure families. Measure parse failures for prompt-only output, then measure wrong-but-valid fields, unwanted defaults, and false certainty after constrained decoding is enabled.

Sampling and Truncation Amplify Small Errors

Higher temperature can vary key choice and field values, while an insufficient token budget can cut off arrays or closing braces. Lower temperature reduces variation but does not make an unsupported value true.

A practical review of a local structured-output pipeline demonstrates why validation and constrained generation are separate components rather than a single prompting trick.

Reserve enough output tokens for the largest legal object, cap array length, and retry only the failed portion. Re-generating the entire object can replace fields that were already correct with new hallucinations.

Use a Two-Stage Local JSON Pipeline

First resolve the task into a minimal typed record: the exact source span, normalized date, selected identifier, confidence state, and any explicit missing value. This stage should be allowed to reject the request rather than invent required data.

Then render that record through a schema-constrained decoder, parse it, and run semantic checks such as file existence, date range, enum compatibility, and cross-field consistency. A validator should return targeted errors that identify the field to repair.

ZimaSpace’s explanation of why a smaller model can be more reliable provides the boundary: compact models work best when the task, context, tool set, and output contract are narrow enough to verify.

FAQ

Does valid JSON mean the model did not hallucinate?

No. Valid JSON proves that the object follows syntax or schema rules. It does not prove that the field values came from the source or match the real system state.

Will setting temperature to zero solve JSON hallucinations?

No. It can make output more repeatable, but a consistently selected unsupported value is still a hallucination.

Is constrained decoding enough for automation?

No. Use it with source-grounded extraction, schema parsing, semantic validation, and a safe rejection path for missing or ambiguous data.

Tech & AI HUB

More to Read

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.