A document extraction service defines a single tool, extract_invoice, and reads the structured fields from the tool_use block of the response. Production logs over one week show that in 3.1 percent of requests the model returns only prose, usually a clarifying question about a poorly scanned line, with stop_reason end_turn and no tool_use block present, and the downstream consumer raises an unhandled error each time. Compliance requires that every extraction request return a structured payload. Which change most effectively meets that requirement?
- AAdd a line in capitals to the system prompt instructing the model to reply with the structured payload and to ask no clarifying questions of any kind.
- BCatch the parse failure in the consumer and reissue the identical request up to three times, treating the run as failed only if all attempts return prose.
- CLeave tool_choice at auto and supply four few shot exchanges that show a structured tool call made against a badly scanned invoice.
- DSet tool_choice to the named tool extract_invoice on the extraction request so the response is required to contain a call to that tool. Correct
Why A is wrong: Tempting because emphatic instructions usually reduce the behaviour, but prompt guidance is probabilistic and a compliance requirement stated as every request needs a guarantee the API itself enforces.
Why B is wrong: Reasonable resilience engineering, but it adds latency and cost on every affected document while still leaving a residual failure rate that the compliance wording does not permit.
Why C is wrong: Few shot examples do shift behaviour and are cheap to add, but auto keeps the prose reply available to the model, so the guarantee the requirement asks for is still missing.
Why D is correct: Correct because naming the tool in tool_choice forces the model to emit a call to it, which removes the prose only response as a possible outcome rather than merely discouraging it.