Quand une nouvelle tentative est utile, et quand elle ne l’est pas

When a model's output fails validation, the tempting move is to just try again. Sometimes that works beautifully. Sometimes it burns tokens and latency for nothing.

As an architect, your job is to know which failure you are looking at before you wire up a retry loop. Retry is a precision tool, not a blanket safety net.

This lesson draws a hard line: retry is excellent for format and structural errors, and useless when the needed information is simply absent from the source.

Extraction and structured-output pipelines fail in two fundamentally different ways:

• Format / structural / arithmetic errors — the answer exists in the source, but the model rendered it wrong: invalid JSON, a missing required field it actually had data for, a total that doesn't add up.
• Absent information — the source document simply does not contain the value. There is nothing to extract.

Retry-with-feedback can fix the first class. It cannot conjure data that was never there. Confusing the two is a classic anti-pattern.

A good retry is not "run the same prompt again and hope." It is a corrective retry. You send the model three things:

• The original source document
• The wrong output it produced
• The exact validation error that was raised

This gives the model the specific signal it needs to self-correct. Vague feedback like "that was wrong, try harder" performs far worse than handing it the precise validator message.

Format and structural problems are exactly where retry shines, because the correct answer is recoverable from the same input:

• Malformed JSON or a stray trailing comma
• A field present in the doc but missing from the output
• Wrong enum casing or an unexpected key
• Arithmetic that doesn't reconcile

On the second pass, armed with the validator's message, the model almost always lands the corrected structure. Even better: enforce structure up front with tool_use + a JSON Schema so most syntax errors never happen at all.

Arithmetic discrepancies are a format-class error retry can fix — but first you have to detect them. The technique: extract both the value the model computes and the value the document states, then compare.

Pull out calculated_total (sum of line items) AND stated_total (the printed total). If they diverge, you have a concrete, retryable validation error to feed back — not a vague hunch.

Now the hard limit. If a field is not present in the source, retrying does nothing useful. The model has two bad options on each loop:

• Return the same "missing" result — wasted latency and cost.
• Fabricate a plausible-looking value to satisfy the validator — far worse, because now you've injected a hallucination into trusted data.

Retry pressure on absent data actively encourages invention. No amount of re-prompting extracts a value that was never written down.

This is where a subtle schema design choice bites. Mark a field required ONLY if it is always present. Never require a field that may be absent — the model will fabricate it to satisfy the schema, and your retry loop will keep accepting garbage.

For optional data, make the field optional and let the model report absence honestly. A retry can't rescue a schema that forces invention.

The fix for absent data is not retry — it is letting the model say so explicitly. Distinguish a genuine access/format failure (maybe retryable) from a valid empty result (no value exists — stop, don't loop).

Use an enum with an "other"/"not_present" value plus a free-text detail field. That keeps the schema extensible and gives downstream code a clean signal to skip the field instead of triggering a doomed retry.

Mature pipelines branch on why validation failed. Structured errors enable this; generic ones ("Operation failed") block it.

• validation / format / arithmetic mismatch → retry-with-feedback.
• transient (timeout, rate limit) → retry locally, the value still exists.
• absent data / valid empty result → record "not present" and move on. Do NOT retry.

This mirrors structured MCP errors: an errorCategory and an isRetryable flag let your loop make an intelligent routing decision instead of blindly looping.

Even for genuinely retryable format errors, bound the loop. A retry budget of 2–3 attempts is plenty — if a corrective retry hasn't converged by then, the problem usually isn't format; it's missing data or an over-strict schema.

Treat the cap as a safety net, never the primary stop mechanism. The real terminator is "validation passed." If you find yourself relying on the cap to exit, that's a signal you're retrying something retry can't fix.

Two more honest limits an architect must respect:

• A fresh, independent reviewer beats same-session self-review. An author retains its own reasoning and won't challenge itself — so for a true second opinion, validate with a fresh instance, not another turn of the same context.
• Blocking, time-sensitive checks belong inline. The Batch API is 50% cheaper but has no latency SLA and a window up to 24h — great for overnight audits, wrong for a pre-merge or real-time validation gate.

Retry tuning can't compensate for the wrong validation architecture underneath it.

Key takeaways:

• Retry fixes format, structural, and arithmetic errors — send the original doc + the wrong output + the exact validation error.
• Retry can't fix absent data. If it's not in the source, looping only wastes cost and invites fabrication.
• Never require a possibly-absent field — make it optional and let the model report "not present."
• Route by error type: validation/arithmetic → retry-with-feedback; transient → retry locally; absent → record and stop.
• Cap attempts (2–3) as a safety net; the primary stop is "validation passed."
• For true second opinions use a fresh instance; keep blocking checks inline, not on the Batch API.