10 AI Quality Benchmarks You Should Be Tracking

Error Rate per 1,000 Outputs

The most fundamental benchmark: how many errors does your system produce per thousand outputs? Define “error” precisely for your domain — factual inaccuracies, policy violations, safety failures, formatting issues, or tone breaches. A vague definition makes this number meaningless across reviewers and task types.

Formula:

Error Rate per 1,000 = (outputs with ≥1 substantive error) ÷ (total outputs) × 1,000

Track overall and segmented by output category, model version, prompt template, and time period. The absolute number matters less than the trend — a steady climb over four weeks is model drift even if you are still “under target.”

Example: Your customer-support drafting pipeline produced 18,400 outputs last month. Reviewers and automated checks flagged 92 with substantive errors. Error rate = 92 ÷ 18,400 × 1,000 = 5.0 errors per 1,000. Broken down: refund letters at 1.2, technical troubleshooting at 11.4. The aggregate looked acceptable; the breakdown revealed where to focus review budget.

Targets: Most production systems aim for fewer than 5 errors per 1,000 outputs. High-stakes domains — healthcare, legal, finance — often require fewer than 1. Set tiered thresholds: Tier 1 customer-facing content might target <2; Tier 3 internal drafts might accept 8–12 with selective review. Alert when week-over-week change exceeds 25% for any segment.

Mean Time to Detection (MTTD)

How long does an error exist before someone notices? This measures the gap between error generation and error detection — the window of exposure where bad outputs can reach users, pollute downstream systems, or compound into larger incidents.

Formula:

MTTD = timestamp(error_detected) − timestamp(output_created)

Report P50 (median) and P95 separately for automated detection and human review. Averages lie when a few errors sit undetected for days. Track detection source: automated pre-screen, human reviewer, customer report, or post-delivery audit.

Example: Last week’s incident batch: automated confidence filter caught 78% of errors at P50 12 seconds, P95 4 minutes. Human review caught the remainder at P50 47 minutes, P95 6.2 hours. The six-hour tail correlated with overnight batches routed to a US-only reviewer pool during EU peak hours. Fix: follow-the-sun routing or async coverage for overnight queues.

Targets: Real-time customer chat might require automated MTTD P95 <30 seconds and human MTTD P95 <10 minutes. Batch report generation might allow human MTTD P95 <4 hours. Document latency budgets alongside your review SLAs so product and ops share the same expectations.

Reviewer Agreement Score

When multiple reviewers evaluate the same output, how often do they agree? Measured using Cohen’s Kappa or simple percentage agreement, this benchmark tells you whether your review criteria are clear and consistently applied. Without agreement data, you cannot trust any other accuracy metric — reviewers may be measuring different things.

Formulas:

Percent Agreement = (paired reviews with same verdict) ÷ (total paired reviews) × 100%

κ = (Po − Pe) ÷ (1 − Pe), where P_o is observed agreement and P_e is expected agreement by chance.

Run double-review on 5–10% of tasks continuously — not just during onboarding. Agreement drifts when prompts change, new reviewers join, or edge cases accumulate without updated rubrics.

Example: You double-review 250 outputs monthly. Reviewers agree on pass/fail in 213 cases → 85.2% agreement. Cohen’s Kappa = 0.79 (substantial agreement). The 37 disagreements cluster on “tone too casual for enterprise clients” — criteria need concrete examples, not adjectives. After a calibration session with gold-standard samples, agreement recovers to 91%.

Targets: Aim for 85%+ percent agreement and κ > 0.70 for well-defined tasks. Below 0.6 suggests guidelines need refinement. Above 0.8 indicates strong calibration. A sudden drop in κ is often your earliest signal that a model or prompt update broke something reviewers can feel but dashboards have not caught yet.

False Positive Ratio

Of the outputs flagged as errors, how many were actually correct? High false positive rates waste reviewer time, increase costs, erode trust in the review process, and train reviewers to dismiss flags as noise. This benchmark measures whether your screening is too aggressive.

Formula:

False Positive Ratio = (flagged outputs marked acceptable) ÷ (total flagged outputs) × 100%

Measure at two points: automated pre-screen flags and reviewer-initiated flags. Each layer can be miscalibrated independently. Include opportunity cost — at 6 minutes per review, a 25% FPR on 2,000 weekly flags wastes 50 hours of capacity.

Example: Your confidence-based auto-flagger routed 620 outputs to mandatory review last week. Reviewers cleared 155 without edits — acceptable as-is. False positive ratio = 155 ÷ 620 = 25.0%. Shadow testing shows raising the confidence threshold from 0.71 to 0.77 drops FPR to 13% while catching 95% of true errors. Deploy the threshold change with a two-week parallel run before cutting production coverage.

Targets: Automated pre-screen FPR below 20% for most domains. Reviewer FPR below 15% — higher rates suggest criteria are too strict or reviewers lack authority to approve borderline cases. Anything above 20% deserves investigation: overly aggressive filters, unclear criteria, or poorly calibrated confidence thresholds.

False Negative Ratio

Of the errors that reached users, how many should have been caught? This is the more dangerous metric — it measures failures in your review process. A high false negative rate means your quality system is missing real errors that customers, auditors, or downstream systems eventually discover.

Formula:

False Negative Ratio = (errors that reached users) ÷ (total errors in system) × 100%

Estimate total errors by combining customer-reported issues, post-delivery audits, and reviewer-caught errors. If you only count what customers report, you undercount errors users silently abandon or work around.

Example: Post-delivery audit of 1,000 shipped outputs finds 28 substantive errors. Your review process caught 19 before shipment; 9 reached users. False negative ratio = 9 ÷ 28 = 32.1%. Root cause analysis: 7 of 9 slipped through Tier 2 technical summaries where review coverage was only 22% and error taxonomy did not include “incorrect API version cited.” Expand coverage and update criteria.

Targets: High-stakes Tier 1 outputs should target false negative ratios below 5%. Tier 2 might accept 15–20% with documented risk budget. Track by error category — systematic gaps in taxonomy produce predictable false negative clusters. Compare against review trigger signals to find routing blind spots.

Cost per Verified Output

How much does it cost to produce one verified output? Include compute costs for the AI model, human review costs (labor plus platform fees), infrastructure costs (APIs, storage, monitoring), and overhead (management, tooling, training). This benchmark helps you optimize the balance between automation and human review.

Formula:

Cost per Verified Output = (model compute + reviewer labor + platform fees + tooling overhead) ÷ (verified outputs shipped)

Count only outputs that passed your verification gate — not every model generation attempt. Segment by task type and risk tier; a blended average hides where spend is out of proportion to risk.

Example: Monthly spend: $62,000 model API + $41,000 reviewer labor + $4,800 platform + $1,200 tooling = $109,000. Verified outputs shipped: 24,600. Cost per verified output = $109,000 ÷ 24,600 = $4.43. High-complexity legal summaries cost $12.80 each; low-risk FAQ drafts cost $1.95. Increasing review coverage on Tier 2 from 31% to 55% adds $0.62 blended cost but cuts customer-reported errors 40%.

Targets: Cost per verified output should be stable or declining as your system matures. Spikes above 25% month-over-month warrant investigation — often a routing change sent simple tasks to expensive senior reviewers. Compare against expected error cost: if catching a $500 compliance failure costs $4 to verify, the math works. See our ROI analysis for human review for framing quality spend to leadership.

Time to Resolution

When an error is detected, how long does it take to fix? This includes time to assign the error to a reviewer, investigate and determine the correct output, apply the fix, and verify the fix worked. Long resolution times increase the window of exposure — errors that persist longer affect more users and compound reputational damage.

Formula:

Time to Resolution = timestamp(fix_verified) − timestamp(error_detected)

Break into sub-stages: assignment latency, investigation time, correction time, verification time. P95 matters more than average — one stuck ticket skews customer impact disproportionately.

Example: Critical customer-facing error detected Tuesday 09:14. Assigned at 09:22 (8 min). Corrected output drafted by reviewer at 10:05 (43 min investigation). Fix verified and redeployed at 10:18. Total resolution = 64 minutes. SLA for Tier 1 errors is 60 minutes — a near-miss. Post-incident: auto-assign rules now route Tier 1 errors to on-call reviewers instead of general queue.

Targets: Set SLAs by error severity: critical (customer-facing, safety, compliance) might require <1 hour; moderate <4 hours; low <24 hours. Track resolution time alongside MTTD — fast detection with slow resolution still leaves users exposed. Publish weekly P50/P95 resolution metrics in ops sync.

Customer-Reported Error Rate

How often do your users report AI errors? This is your most honest benchmark — it captures the errors that slipped through all your automated and human review processes. Internal metrics can improve while customer experience degrades if you are measuring the wrong errors or fixing outputs reviewers approve but customers reject.

Formulas:

Customer-Reported Error Rate = (user-reported AI errors) ÷ (total AI interactions) × 1,000

Also track raw count, error categories, and correlation with review status: Δ Report Rate = reportsunreviewed − reportsreviewed per 1,000 interactions.

Example: 142,000 AI-assisted interactions last month. Customers reported 89 quality issues tied to AI output. Customer-reported error rate = 89 ÷ 142,000 × 1,000 = 0.63 per 1,000. Reviewed outputs: 0.31 per 1,000. Unreviewed: 1.14 per 1,000. The gap justifies review spend on customer-facing surfaces — but 41% of reports cite “unhelpful tone,” a category your internal error taxonomy did not track until now.

Targets: Trend matters more than absolute number — a sudden spike often indicates model degradation or a gap in review coverage. Investigate any week-over-week doubling. When internal error rate improves but customer-reported rate is flat, your taxonomy likely does not match what customers care about. Trust the customer signal when it diverges from internal dashboards.

Model Drift Score

Is your model’s performance changing over time? Model drift occurs when the distribution of real-world inputs shifts away from training data, upstream retrieval goes stale, or provider-side model updates change behavior silently. Subtle drift is easy to miss without consistent tracking — especially in language models, where degradation often manifests as quality loss, not catastrophic failures.

Formula:

Drift Score = (error_ratecurrent − error_ratebaseline) ÷ error_ratebaseline × 100%

Supplement with input distribution monitoring: compare embedding clusters weekly, track confidence score distributions, and run periodic evaluation against a fixed golden test set. A drift score above threshold triggers investigation — not automatic retraining.

Example: Baseline error rate after January prompt v4.1 launch: 2.1 per 1,000 on product-description tasks. By March, same task type at 4.6 per 1,000 with no intentional changes. Drift score = (4.6 − 2.1) ÷ 2.1 = 119% relative increase. Root cause: catalog feed schema changed — model now hallucinates discontinued SKU attributes. Fix the data pipeline, not the model weights.

Targets: Alert when drift exceeds 25% for two consecutive weeks or error rate crosses an absolute threshold. After any model migration, run parallel shadow evaluation for two weeks before declaring success — see handling model migrations for a full playbook.

Review Coverage Percentage

What percentage of your AI outputs are reviewed by humans? This benchmark tells you how much of your output pipeline is verified. Track overall and by risk category. High-risk outputs should have near-100% coverage. Low-risk outputs might have 10–20% coverage through spot-checking. The goal is not maximum coverage — it is optimal coverage on outputs where errors cost the most.

Formulas:

Review Coverage = (outputs human-reviewed) ÷ (total outputs produced) × 100%

Risk-Weighted Coverage = Σ(reviewed × risk_weight) ÷ Σ(total × risk_weight)

Risk weights might be 3× for customer-facing, 2× for client deliverables, 1× for internal drafts. Pair coverage with false negative ratio — low coverage with high FNR is a conscious risk you have not documented.

Example: 62,000 outputs produced, 7,440 human-reviewed → 12.0% raw coverage. Risk-weighted: Tier 1 customer-facing at 96% coverage, Tier 2 at 38%, Tier 3 internal at 3%. The low raw number is intentional. Uncovered Tier 2 at 62% is the documented risk budget — revisit quarterly as model error rates improve.

Targets: Tier 1 should approach 100% coverage. Tier 2 depends on error rate and customer-reported errors — expand coverage when FNR or customer reports spike. Revisit coverage quarterly as models improve and risk tolerance shifts. Document why uncovered tiers remain uncovered; “we ran out of reviewers” is not a strategy.

Using These Benchmarks Together

These ten benchmarks are not independent — they interact. Improving reviewer agreement reduces false positives and false negatives. Increasing review coverage reduces customer-reported errors but raises cost per verified output. Tightening automated screening lowers MTTD but can inflate false positive ratio. The art is finding the balance that meets your quality requirements at an acceptable cost.

Do not instrument all ten on day one. Start with the trio that answers: Are outputs good? Can we trust reviewers? How fast do we catch problems?

1. Error rate per 1,000 outputs — baseline quality signal, segmented by task type
2. Mean time to detection — exposure window and pipeline health
3. Reviewer agreement score — confidence that other benchmarks mean something

Add cost per verified output and review coverage once you have four weeks of stable data. Layer in false positive ratio, false negative ratio, and time to resolution when optimizing routing and incident response. Add customer-reported error rate and model drift score when you are ready to connect internal benchmarks to business outcomes and long-term stability.

Review the full stack weekly in a 30-minute ops sync. Red benchmarks get owners and deadlines; green benchmarks still get spot-checked — complacency is how drift accumulates. Publish a one-page summary for leadership: three headline numbers, two trends, one action item. Executives do not need ten charts; they need to know if quality is improving and what you are doing about it.

Benchmarks are not goals — they are instruments. Error rate without reviewer agreement is noise. Low MTTD with high false positive ratio is expensive theater. Customer-reported errors trending up while internal dashboards stay green means you are measuring the wrong things. Track these ten together, set tiered targets, and revisit definitions before each model migration. That is how teams ship AI they can defend — not AI they can only hope works.

Start with error rate per 1,000 outputs, mean time to detection, and reviewer agreement score. Those three give you a solid foundation. Add the others as your quality operation matures. Wire them into a dashboard, set alert thresholds, and treat benchmark definitions as living documents — not one-time spreadsheet rows.

• Use the visual builder to configure quality gates and routing rules that feed your benchmarks pipeline.
• Open the sandbox to submit sample tasks and see how review outcomes map to quality KPIs.
• Reference the API reference for webhook payloads and analytics endpoints.