Article · Evaluation & assurance

Measuring a grounded assistant: context recall and faithfulness

"Does it make things up?" is the only question a business owner asks about an assistant built on their own content. It has a numeric answer, and the number should be on the dashboard before the assistant is on the phone.

Source code on a dark screen

An assistant that answers from a company’s own content, whether a catalogue, a policy folder or a scraped website, is sold on one promise: it will say what the content says and nothing else. Owners are right to be sceptical of the promise, because the failure is invisible in a demo and expensive in production. A warranty invented on a phone call is a warranty the business will be asked to honour.

The promise is testable. Two numbers, computed the same way before every release, say how well it is kept.

Context recall

The first question is whether the assistant found the right facts. For each test question, we know which passages in the content hold the answer. Context recall is the share of those passages that the assistant’s retrieval actually brought into the model’s context before it answered.

Low recall means the assistant is answering without the facts, which it will do fluently, and the fix is in retrieval: the way the content is chunked, the search over it, the number of results returned. For a reseller with a catalogue of several hundred items, the retrieval is a search tool the model calls, and recall is measured on the tool’s results.

Faithfulness

The second question is whether the answer stayed within those facts. Faithfulness is judged by splitting the answer into claims and checking each claim against the retrieved context. A claim that is supported by the context counts; a claim that is not, however plausible, does not. The score is the share of supported claims.

The judge is a model, instructed narrowly and run with the same inputs every time. We treat its verdicts the way a regulatory team treats a rule-based screener: a second opinion that makes disagreements visible, and one we audit by hand on a sample.

The test set is the client’s

The questions are not ours. They come from the client: the questions customers actually ask on the phone and in chat, including the awkward ones (does the warranty cover shipping, do you finance used instruments, what are your hours on the holiday). Each question has reference passages marked. The set grows when a new kind of question appears in the logs.

A test set the vendor wrote measures the vendor’s imagination. A test set the client wrote measures the business.

What the numbers do

They sit on the dashboard. When a prompt is edited, the content folder re-scraped, or the retrieval changed, the evaluation is re-run and the numbers move or do not. A change that improves fluency and lowers faithfulness is rejected, and the reason is a number rather than a feeling.

They also set expectations honestly. No grounded assistant scores a hundred on faithfulness over a real question set, and a client who has seen the number is a client who can decide whether ninety-four is good enough for a phone line and whether it is good enough for a quote.

The pattern

Any assistant built on a body of content should ship with this harness: a question set from the client, reference passages, context recall, faithfulness, a judge whose verdicts are sampled by a person, and a dashboard where the numbers live. It takes a few days to build and it is the difference between a demo and a product.


About the authors. Neugent Consulting designs and builds AI systems for operators. The examples in this piece come from client work; clients are anonymised and details are simplified.

Talk to the people who built it

Every piece we publish describes a system we have built. We can show it running.