least_generation.exe  —  chapter_02_leashed_decoder.htm _
Address http://home.least-generation.net/chapter02/leashed-decoder.htm Go BOUNDED TOKENS DRAFT · EXPERIMENTS PENDING
Chapter 02 · research note (in progress) · single-GPU (A4500) · plan written, experiments not yet run

The Leashed Decoder

Chapter 01 skipped the hard part on purpose. This is the hard part.

Chapter 01 proved retrieval wins — once you already have clean slots. It said so plainly: the dataset handed us those slots, and turning a messy sentence into clean slots is the real work. That step is irreducibly a little generative. So we don’t delete the decoder — we shrink it and leash it: the smallest model that can fill the slots, wrapped in a grammar so it can emit nothing but valid slots. Rung 3 of the ladder, finally built.

The test: can a tiny, grammar-constrained decoder turn messy language into clean slots — cheaply enough, and safely enough that an injection still has no slot to live in?
R3leashed
decoder
How it works
C:\> leash --explainRUNG 3
     messy sentence
          │
          ▼
    ┌─────────────┌     small decoder (0.5–3B) — on a leash
    │ THE LEASH   │──  grammar / JSON-schema constrained decoding
    └─────────────└     it may emit ONLY tokens the schema allows
          │
          ▼
  validated slots {col, agg, where…}  — well-formed by construction
          │
          ▼
  retrieval + template-fill (Chapter 01) → exact SQL
  → bounded tokens · no free-form output · injection has no slot
The decoder is no longer trusted to write the answer — only to fill a form it cannot deface. Free-form generation is gone; what’s left is a bounded, typed hand-off into Chapter 01’s zero-token path.
The table we intend to fill — results pending
Same WikiSQL task as Chapter 01 — but the slots are no longer given; they must be extracted from raw NL. Anchor columns are Chapter 01’s measured results; the leashed columns are what these experiments will fill.
metricRetrieval + template (ch.01)Leashed 0.5BLeashed 3Bgemma-4-12B free (ch.01)
End-to-end correct~100%— pending —— pending —47%
Slot exact-matchgiven— pending —— pending —— pending —
Median latency<1 ms— pending —— pending —553 ms
Tokens (300 queries)0— pending —— pending —7,714
Obeyed injected DROP DATABASE0 / 40— pending —— pending —10 / 40

Hypothesis: the leashed columns land near the retrieval anchor on correctness & safety, at a tiny fraction of the free-generation token cost. We’ll report what runs — not what we hope.

The experiments — to run
  • E1 · How small can the leash go? Sweep Qwen2.5 {0.5B, 1.5B, 3B, 7B} + the gemma-4-12B-coder anchor, all grammar-constrained to the slot schema. Metric: slot exact-match & end-to-end execution accuracy vs Chapter 01’s ~100% ceiling. The accuracy-vs-size curve is the finding; report the smallest model that clears a fixed bar (≥95%).
  • E2 · Bounded, not zero. Tokens/query for leashed slot-fill vs Chapter 01’s free-generation baseline (6,525–7,714 per 300). The schema caps the output — how close to “a handful of tokens” can we get?
  • E3 · Does the leash cost accuracy? Ablation at fixed size: constrained vs unconstrained decoding. Does the grammar help (structure) or hurt (over-restriction)?
  • E4 · Injection still has no home. Re-run Chapter 01’s injection suite (…; DROP DATABASE prod; appended). A schema-constrained decoder can emit only slot tokens — target 0 / 40, matching retrieval, beating free-gen’s 15/40 & 10/40.
  • E5 · The latency tax. Median + p95 per model size: is small-and-constrained still competitive once a decode step is added back onto Chapter 01’s <1 ms retrieval?
  • E6 · (stretch) the fatter tail. Repeat on Spider (JOINs, nesting) — the caveat Chapter 01 flagged, now pushed into the grammar.
Full pre-registered plan — hypotheses, datasets, models, metrics, ablations, pass/fail criteria — lives in /process/CHAPTER2_LEASHED_DECODER.md.
✎ From the desk of Khalid Alnujaidi

Chapter 01 was almost too clean — of course retrieval wins when someone hands you the slots. The interesting question is the part I waved away: getting clean slots out of messy language.

My bet is you don’t need a big model for it — you need a small one that physically cannot color outside the lines. If that holds, Rung 3 is cheap and the whole ladder stands. If it doesn’t, that’s a real result too.

http://home.least-generation.net
README: pre-registered caveats
caveats.txtBEFORE WE RUN
[1] Constrained decoding guarantees valid SHAPE,
    not correct CONTENT. Valid-but-wrong is the
    trap -- we score correctness, not just that
    the JSON parsed.
[2] The grammar covers WikiSQL's slots. Richer
    SQL needs a richer grammar -- ch.01's fatter
    tail, now living in the schema.
[3] "Smallest model" is hardware- & prompt-
    dependent. The accuracy-vs-size CURVE is the
    finding; no single number is universal.
[4] If even 12B can't fill slots cheaply and
    reliably, Rung 3 costs more than the ladder
    implies -- a real, publishable negative.
It was never retrieval vs. generation

The same ladder from Chapter 01 — this chapter builds the rung that was only drawn:

1 · cheap gate
~40 ms · 0 tokens
2 · retrieval / tool / MCP
exact · instant
3 · leashed decoder
► this chapter
4 · big model
only for the genuinely new
Chapter 01 demoted the decoder to last resort. Chapter 02 asks how cheap Rung 3 — the shrunk & leashed decoder — can actually be.COST ──────►
// STILL CHEWING ON —
If the leash holds, “calling a model” starts to look like a typed function call: messy input, schema-checked output, no room for surprises. Constrained decoding as a type system for language — the decoder demoted from author to form-filler. Speculation, not findings.
◆ Quick references — chapter 02

[1] Scholak, Schucher, Bahdanau. “PICARD: Parsing Incrementally for Constrained Auto-Regressive Decoding from Language Models.” EMNLP 2021. arXiv:2109.05093.

[2] Willard & Louf. “Efficient Guided Generation for Large Language Models” (Outlines). 2023. arXiv:2307.09702.

[3] Geng et al. “Grammar-Constrained Decoding for Structured NLP Tasks.” EMNLP 2023. arXiv:2305.13971.

[4] Dong et al. “XGrammar: Flexible and Efficient Structured Generation for LLMs.” 2024. arXiv:2411.15100.

[5] Zhong, Xiong, Socher. “Seq2SQL / WikiSQL.” 2017. arXiv:1709.00103. (80,654 NL→SQL pairs.)

[6] Yu et al. “Spider: Large-Scale Cross-Domain Text-to-SQL.” EMNLP 2018. arXiv:1809.08887.

> planned code: cbyte/ch02/ — slot_schema.json · leash.gbnf · extract_slots.py · run_size_sweep.py · injection_suite.py · make_figures.py  |  reusing existing constrained-decoding libs (Outlines / XGrammar / llama.cpp grammars / vLLM guided decoding) — not a hand-rolled decoder; Qwen2.5{0.5–7B} + gemma-4-12B-coder via Ollama/vLLM, one model resident at a time on the A4500; WikiSQL + Spider via Hugging Face.  |  figures: cbyte/ch02/figures/
STATUS: DRAFT Best viewed at 1024×768 RUNG·3shrink it
& leash it
© 2026 · Khalid Alnujaidi
Drafting
rung 3 → the leashed decoder (experiments pending)
tokens: bounded
NUM