🤖 AI Summary
This study addresses the overlooked trade-off between output validity and factual correctness when small language models are subjected to hard structural constraints—such as JSON formatting or tool-call schemas—which significantly degrade answer accuracy. The authors introduce "constraint tax," a metric protocol that quantifies the performance penalty imposed by such constraints under fixed model, task, and input conditions, and propose a novel delayed-enforcement paradigm: first allowing unconstrained reasoning, then applying structural constraints post-hoc. Experiments on Qwen2.5 and SmolLM2 models reveal that while hard constraints achieve 100% format compliance, they reduce answer accuracy from 19.7% to 11.0%, with 88.9% of outputs being syntactically valid yet factually incorrect. In calendar-based tool-calling tasks, executable accuracy plummets from 91.5% to 48.0%.
📝 Abstract
Production LLM systems increasingly require machine-readable outputs: JSON objects, typed traces, regex-constrained fields, and tool-call schemas. This paper targets on-device and low-cost small language model (SLM) deployments, where sub-3B models are attractive for privacy, latency, and commodity hardware but have limited capacity to satisfy schemas while solving tasks. The usual engineering assumption is that hard output constraints improve reliability without changing the underlying answer. We show that this assumption is unsafe for small models. We introduce \emph{constraint tax}, a measurement protocol for isolating the answer and executable-accuracy loss caused by structured-output constraints at fixed model, fixed task distribution, and fixed problem instances. Across 15,000 commodity-GPU generations with Qwen2.5-0.5B, Qwen2.5-1.5B, and SmolLM2-1.7B, hard answer-only schema decoding raises schema validity from 61.5\% to 100.0\%, but lowers answer accuracy from 19.7\% to 11.0\% and increases wrong-valid-schema outputs from 49.5\% to 88.9\%. The strongest industry analogue is a deterministic calendar tool-call task: Qwen2.5-1.5B achieves 91.5\% executable accuracy with prompt-only JSON but only 48.0\% under the same hard tool-call schema, while both modes are 100.0\% schema-valid. The error is semantic, not structural. We also show that the 3B boundary still pays a direct-schema tax and that delayed packaging supports a constructive design pattern: reason free, constrain late. The practical conclusion is direct: production systems should report schema validity, answer accuracy, executable accuracy, and wrong-valid-schema rate separately.