Skip to main content
VectisFlow
VectisFlow
All services

Service 04

Evaluation and assurance

Evaluating a model and contracting a dataset are the same discipline pointed at different objects. Both answer one question: can this be relied on, and how would you know.

The problem this solves

Most GenAI systems in production are evaluated by the people who built them, on examples they chose, at a point in time. That is not evidence. It is a demonstration with a sample size.

The consequences arrive later: nobody notices when a model update moves behaviour, a prompt change silently degrades a subset of queries, or a new document family enters the corpus that the retrieval configuration handles badly. Without a regression suite, all three are invisible until a user complains.

For regulated buyers there is a second problem. The system will eventually need to be explained to someone with the authority to stop it: an internal auditor, a regulator, a court. That conversation goes very differently when there is a measured error rate and a documented method.

The same holds one layer down, and is more often missed. A published figure carries the same obligation as a generated answer: you have to be able to say where it came from and when it was last true.

Method

How we build it

Evaluation is built as infrastructure, not run as an exercise. It should be cheaper to check the system than to argue about it.

  1. 01 · Question set construction

    Several hundred real questions drawn from logs, interviews and the awkward cases people remember, labelled with acceptable answers and their supporting passages by someone with the authority to adjudicate.

  2. 02 · Retrieval evaluation

    Recall@k, mean reciprocal rank and answer-supported rate measured per document family, because aggregate scores hide the family that fails completely.

  3. 03 · Generation evaluation

    Faithfulness to retrieved context, citation correctness, and appropriate abstention. Scored with a rubric and an LLM judge, calibrated against human scores on a sample so the judge's own error rate is known.

  4. 04 · Adversarial and permission testing

    Prompt injection through document content, attempts to elicit unsupported claims, and synthetic users probing whether restricted content can be surfaced or inferred. Run on every release.

  5. 05 · Regression in CI

    The suite runs on every pipeline or prompt change, with thresholds that fail a build. Quality becomes something the team defends automatically rather than remembers to check.

  6. 06 · Production monitoring

    Sampled live scoring, drift detection on retrieval quality, and a feedback control wired into the interface so real corrections flow back into the labelled set.

  7. 07 · Data contracts

    Expectations about shape, range, freshness and referential integrity, declared next to the data they describe and run on every load. The point is that a breach stops something rather than being recorded somewhere.

  8. 08 · Lineage and freshness

    Column-level lineage from source to consumed artefact, and a freshness SLA per dataset with an owner attached. When a figure looks wrong, the question is which upstream change caused it, and that needs an answer in minutes rather than an afternoon.

A repeating grid of windows across a building facade, a few panes picked out in black against the rest.

Deliverables

What you are left holding.

  • A labelled evaluation set

    Owned by you, versioned, and growing from production feedback rather than frozen at handover.

  • A regression suite in CI

    With thresholds, so a change that degrades retrieval quality fails before it reaches users.

  • An assurance pack

    Method, measured error rates, known failure modes, and the mitigations in place, written for a risk committee rather than for engineers.

  • Monitoring in production

    Dashboards and alerts on retrieval quality, abstention rate and cost per answered question.

The hard parts

The questions worth asking us.

If a supplier cannot answer these specifically, they have not shipped one of these systems.

Can an LLM judge be trusted to score another LLM?

Only with its own error rate measured. We calibrate every judge against human scores on a stratified sample, report the agreement rate, and treat the judge as an instrument with known precision rather than an oracle. Where agreement is poor, usually on nuanced faithfulness judgements, those categories stay human-scored.

How large does a labelled set need to be?

Smaller than teams fear, and it needs to be stratified rather than large. Two to three hundred well-chosen questions covering each document family and each question type will detect the regressions that matter. Ten thousand unstratified questions will not, and will cost far more to maintain.

What error rate is acceptable?

That is your decision, not ours, and it depends entirely on what the answer is used for and how reversible the consequence is. Our job is to make the number real, break it down by failure mode, and be explicit about the confidence interval, so the decision is made on evidence rather than on comfort.

Related engagement

How this looks in practice.

A bank of analogue gauges and levers across an industrial control desk, in black and white.

Central government

Making a data platform trustworthy enough to publish from

Contracts, column level lineage and freshness SLAs added to the platform behind an official statistics publication, after a release had to be corrected because a source system quietly changed what one column meant.

UK government department, ~6,000 staff · 22 weeks

Read the engagement

Usually engaged alongside

Start here

Talk to us about evaluation & assurance.

Bring the estate, the constraint and the question you want answered. Forty-five minutes is usually enough to tell whether this is viable, and we would rather say so early.

Response time
One working day, from a person who has read it.