Human-in-the-loop is a product decision, not a fallback
Every document-AI system eventually adds a human review step. It usually arrives as an engineering afterthought: the model is uncertain, so a person checks it. But if the review step is designed carelessly, it can make the whole system slower than the manual workflow it was meant to replace — while still costing you the model, the infrastructure, and the integration work.
The failure mode nobody benchmarks
Consider a form with twenty fields. The model is confident about nineteen and unsure about one. If the review interface shows the reviewer the whole document and asks them to confirm it, you have not saved them anything: they will read all twenty fields, because they have no reason to trust the nineteen.
The system's throughput is now bounded by human reading speed, exactly as before. The model's accuracy did not create the bottleneck. The interface did.
Review the field, not the document
The fix is to make the unit of review the smallest unit of uncertainty. Show the reviewer the one field the system is unsure about, with the cropped image beside the predicted value, and let them confirm or correct in a single action.
This only works if the confidence signal is trustworthy at field granularity. That is a modeling requirement that comes directly from a product decision — which is the point. You cannot design the review step after the pipeline is built and expect it to fit.
Global thresholds are a shortcut you pay for
A single confidence threshold across all field types is convenient and almost always wrong. A checkbox and a handwritten reference number fail in different ways, at different rates, with different costs when they are wrong.
Calibrating per field type takes more evaluation work, but it is what lets you route aggressively where the model is reliable and conservatively where it is not. The alternative is a threshold tuned to the worst field, which sends far too much to review, or tuned to the average, which lets real errors through.
- Set thresholds from the cost of an error, not from a uniform confidence score.
- Track how often reviewers accept the prediction unchanged — a high acceptance rate on a field means the threshold is too conservative.
- Track corrections as labelled data. A review step that does not feed back into the dataset is throwing away the most valuable signal you have.
Corrections are the dataset you did not have to pay for
The reviewer is producing perfectly labelled examples of exactly the cases your model finds hard. That is the highest-value training data in the system, and it arrives free as a byproduct of normal operation.
Capturing it requires deciding, up front, that the correction path writes somewhere structured — not just into the output record. It is a small architectural decision that determines whether the system improves over time or stays exactly as good as it was on launch day.