The polite sentence that broke my model

This story describes a practical engineering failure and fix while training small language models to call external tools. The team used a procedure called GRPO to teach the models to produce tool calls. A seemingly harmless, polite sentence caused the model to emit output the downstream parser could not handle. The eventual fix was to enforce the strictest output rule and validate outputs against the expected schema.

Small models often mimic surface patterns in prompts and examples instead of reliably following implicit structural constraints. Two related failure modes appear across similar cases in the literature:

• Schema vs description mismatch: Models tend to obey the schema shown in examples more than the prose description of a parameter. If the schema in the prompt is underspecified, the model will fill in a plausible shape that can vary across runs.
• Format fragility: Parsers require exact keys. A single capitalization or renaming can turn a valid-looking response into unparseable JSON. Larger models may be more consistent, but small models remain sensitive to prompt wording, ordering, and incidental text like polite closings.

The team applied a strict rule: require the model to emit only the exact, schema-constrained output with no extra prose. That meant:

• Explicitly provide a minimal schema in the prompt and examples, using precise keys and types.
• Tell the model to output only the machine-readable block—no framing text, no thanks, no confirmations.
• Validate the returned JSON against the schema before handing it to downstream code.

Enforcing this rule eliminated the failure mode caused by the polite sentence. The strict rule reduced flexibility in model behavior but increased reliability for tool invocation.

• Put format validation and schema checks between the model and downstream systems. Treat any deviation as a failure mode to be handled explicitly.
• Prefer concrete examples that show the exact token-level output you expect rather than relying on descriptive text alone.
• If you use small models, prioritize stricter constraints and more explicit schema examples—these improve consistency even if they reduce naturalness.

• How strict should schema enforcement be for my app? Aim for exactness on required keys and types for any fields your downstream code consumes.
• Is this only a problem for small models? The issue is more acute with small models but format fragility can affect any model if prompts and validation are lax.
• What testing helps catch these failures? Regression tests that validate the exact output shape across model versions catch silent regressions such as capitalization or renamed keys.