Evaluation and QA at Qoves

Every AI feature at Qoves ships behind an evaluation. Not a demo on a good image, a measured pass against known outcomes. This post is what that practice looks like day to day: the golden set, the gates, the human review, and what happens when a model drifts.

The golden set#

We keep a fixed set of customer-like images with known outcomes: faces with agreed landmark positions, skin tones across the range our customers actually have, lighting conditions from studio to phone selfie in a dark room. Every pipeline change runs against it.

dataset: golden-v4
images: 420
checks:
  - name: landmark_drift
    tolerance_px: 1.5
  - name: measurement_stability
    tolerance_pct: 2
  - name: report_sections
    required: [summary, findings, recommendations]
  - name: no_empty_fields

The set is versioned. When we add a failure case found in support, it goes into the set with the ticket reference, so the set grows with the product instead of being written once.

Gates, not dashboards#

Eval runs in CI on every pull request that touches a model, a prompt, or a pipeline stage. A regression past tolerance fails the build. Dashboards tell you what happened last week; a gate stops the bad change from reaching production at all.

Three rules make the gate honest:

1. Failures block merges. No override without a written reason in the pull request.
2. Tolerances come from customer impact. One pixel of landmark drift nobody can see passes. A measurement change that moves a report number by five points does not.
3. Eval runs on the same code path as production. A separate eval harness that imports different preprocessing will pass while production breaks.

Human QA on top of the machines#

Automated checks catch numbers. They do not catch a report that reads like a word salad. Each release candidate gets a sampled review: a person reads twenty generated reports end to end and scores clarity, correctness of explanations, and whether the recommendation follows from the measurements.

Reviewers score against a short rubric, not taste. Two consecutive releases with a falling rubric score trigger a look at prompts and models even when the automated gates stay green.

Watching production after release#

Offline eval proves a change is safe. Production proves the change survives reality. We log stage timings, failure categories, and output quality signals per report, and we alert when the distribution moves: more retries, longer render times, more support contacts per hundred reports.

When a customer reports a bad number, the report stores the pipeline version, model versions, and the eval run that approved them. That chain turns a support conversation into a reproducible failure in minutes, and the failure becomes a new case in the golden set.

What this costs#

Evaluation is unglamorous work that slows the first version of every feature. It is also why weekly AI releases did not become weekly incident responses. The platform lets us move fast because the gates, not our confidence, decide what ships.