人機協作：如何設計審核佇列

"Doubtful cases go to a human" is easy to say and easy to get wrong. If the review queue is slow, confusing or endless, people stop trusting it, start rubber-stamping, and the accuracy you measured in the pilot quietly disappears. Here is how I would design the queue so it holds up.

What goes into the queue

Two kinds of items belong there:

1. Low confidence. Anything below the threshold you agreed on. In my ticket-triage demo (public data, test numbers) about 24% of tickets fall below the line, and that share is a design input, not a surprise.
2. Hard rules. Items that must always be checked regardless of confidence: amounts above a limit, a failed checksum, a customer flagged as sensitive.

Keep the two reasons separate in the record. They have different fixes later.

Size the queue before you build it

A queue is a workload, so do the arithmetic early:

items_per_day × share_to_review × minutes_per_review / 60 = reviewer_hours_per_day

If that number is bigger than the people available, either the threshold or the scope is wrong. Better to find out on paper.

Show the reviewer what they need in one screen

• The item itself, and the system's proposed answer.
• Why it is in the queue: low confidence, which rule fired.
• The evidence: the cited passage, the extracted field highlighted in the source, the runner-up answer.
• One-click actions: accept, correct, reject. Correcting should take fewer clicks than rewriting.

If the reviewer has to open three other systems to decide, the average review time doubles and your cost model breaks.

Order and age

Don't sort by arrival only. Sort by deadline and by risk. Show the age of each item and alert when anything sits longer than your service level. An unattended queue is an outage in slow motion.

Make the queue teach the system

Every correction is a labelled example. Store the original proposal, the final answer, who changed it and when. Then:

• Re-tune the threshold monthly on the fresh labels.
• Look at the top confusions (the pairs the model mixes up) and fix those first.
• Track the override rate: how often reviewers change the proposal. A rising rate is an early warning that quality is drifting.

Guard against rubber-stamping

If reviewers accept 99.5% of items in two seconds each, they are not reviewing. Seed a small share of known-answer items into the queue and measure whether they are caught. It is an honest check on the human half of the system.

Takeaways

1. Define why an item enters the queue, and record the reason.
2. Compute reviewer hours before building.
3. Give the reviewer evidence and one-click actions on one screen.
4. Treat every correction as training data and track the override rate.
5. Test the humans too, with seeded items.

Portfolio and contacts: @Kotenev01_bot.

I write about practical, measurable AI adoption for business: demos on test data, no invented case studies. Telegram channel: @kotenev01_en