Passing acceptance on launch day says the feature worked on the data you tested. It says nothing about next quarter. Inputs change, products change, a provider updates a model, a form gets a new field. Without monitoring, quality decays quietly and you hear about it from an angry customer. Here is the small set of signals I would put in place before go-live.
1. Volume and shape of inputs
The cheapest early warning. Track items per day, average length, language mix, share of empty or malformed inputs, and the distribution of categories. A sudden shift (a new product launch, a changed template, a broken upstream feed) often precedes a quality drop.
def drift_alert(today, baseline, tol=0.25):
return {k: abs(today[k] - baseline[k]) / max(baseline[k], 1e-9) > tol
for k in baseline}
2. The confidence distribution
If you route by a confidence threshold, watch where the scores sit. A shrinking share above the threshold means the model is less sure than at launch: more items go to people, and the cost model starts to slip. A growing share above it with no improvement elsewhere is also a flag, because over-confidence is how silent errors get through.
3. The share going to humans
The simplest business metric of the system. Track it daily with a weekly trend. It should be stable around the number you measured in the pilot. Alert on a move of more than a few points in either direction.
4. The override rate
How often reviewers change the proposed answer. This is the most direct quality signal you get for free. Break it down by category: one weak category hides in an average.
5. Sampled audits
Automatic metrics miss what nobody reviews. Each week, pull a small random sample (20 to 50 items) from the automated path, the ones no person saw, and have someone check them against the correct answer. This is the only way to estimate the real error rate of what the system sends without supervision.
Keep the sample random, record the result, and plot the trend.
6. The golden set, rerun
Rerun the frozen golden set on a schedule and on every change (model version, prompt, threshold, upstream data). A drop on the golden set with unchanged inputs points at the model or the prompt, not the data. Keep a version log of scores.
7. Operational health
The boring part that causes most outages: latency, error rates, timeouts, queue age, cost per item, and API spend against a limit. Cost creep is quality decay's twin: a prompt change that doubles tokens is a regression too.
8. The feedback channel
Give users and reviewers an obvious way to flag a bad result, and read what comes in. It is rarely statistically useful, but it finds the failure types you did not think to measure.
A monthly review
Once a month, 30 minutes, same agenda:
- Trend of the key metrics above, against the launch baseline.
- The ten worst items from the sample and the review queue.
- Add 10 to 20 fresh items to the golden set.
- Decide on the threshold: tune it on fresh labels, or leave it.
- Note provider or data changes since last time.
Write down who owns each alert and what they do when it fires. An alert with no owner is a log line.
Takeaways
- Watch inputs, confidence, share to humans and override rate.
- Audit a random sample of the automated path every week.
- Rerun the golden set on every change.
- Track cost and latency as quality signals too.
- Give every alert an owner and a monthly review.
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
Top comments (0)