Blog ยท AI Quality

Evaluating hallucination risk in a domain assistant

2026-10-26ยท5 min readยทMD ABU SAYEED
In short: Hallucination risk is measurable: test a domain assistant against real and unanswerable questions, score every claim against a source, track refusal correctness, and keep monitoring live traffic after launch.
Person in blue hoodie programming late at night
Person in blue hoodie programming late at night

A domain assistant that answers ninety-five questions correctly and invents the ninety-sixth is more dangerous than one that admits ignorance, because users extrapolate trust from the confident wrong answer. Hallucination risk is not a vague worry you handle with a disclaimer โ€” it is a measurable property of your system, and you can put numbers on it long before your customers do.

Why domain assistants hallucinate

Language models generate the most plausible continuation of a prompt, not the most verified one. In a narrow domain your sources cover most questions well, but the edges โ€” rare products, outdated pricing, policy exceptions, unsupported configurations โ€” are exactly where the model fills gaps with fluent invention. Three failure modes dominate in practice:

Build a test set from real questions

An evaluation is only as honest as its questions. Collect between fifty and two hundred prompts that reflect what people actually ask, not what you hope they ask:

Score answers claim by claim

Do not grade a response as a single pass or fail. Split each answer into individual claims and check every claim against a source: does it appear in, or follow logically from, the retrieved context? Three metrics fall out of this, and they are worth tracking separately:

You can run claim checks with a strong evaluator model, but spot-check its judgements by hand. Evaluator models are themselves fallible, and an unexamined scorecard breeds false confidence.

Test refusal behaviour explicitly

The cheapest hallucination to fix is the one the assistant never produces. For every unanswerable question in your test set, record whether the model refuses, hedges or invents. A healthy domain assistant declines clearly, states what it cannot answer, and redirects to a human or a document โ€” it never guesses quietly. If refusal correctness is low, fix it with instructions and retrieval constraints before you touch training data.

Probe the edges before users do

Once the core set passes, attack it:

Keep watching after launch

A test set is a snapshot; production is a movie. Sample live conversations weekly and run them through the same claim-level scoring, route low-confidence answers to human review, and watch indirect signals such as thumbs-down clicks, repeated rephrasing and escalations. When the grounded-answer rate drifts down after a model update, a prompt change or a document refresh, treat it as a regression and roll back or patch โ€” exactly as you would with any other quality metric.

Constrain first, retrain second

When the numbers disappoint, the fastest fix is almost always architectural rather than statistical. Ground the assistant with retrieval so it answers only from supplied context, require citations, and cap generation length. Fine-tuning still earns its place โ€” it improves tone, format and refusal style โ€” but it does not guarantee factuality. Evaluate after every change, keep the scoreboard visible, and hallucination risk becomes an engineering metric you manage instead of a fear you live with.

Frequently asked questions

What is an acceptable hallucination rate for a domain assistant?
It depends on the stakes. For general support use, aim for a fabrication rate under a few percent on your test set and zero unsupported claims on questions with financial, safety or legal consequences, enforced through grounding constraints and human review rather than luck.
Can fine-tuning alone eliminate hallucinations?
No. Fine-tuning improves tone, formatting and refusal style, but it cannot guarantee factual accuracy. The bigger reductions come from retrieval grounding, instructions to answer only from supplied context, and claim-level evaluation that catches regressions.
How many test questions do I need to start?
Fifty to one hundred real questions is enough for a first scoreboard, as long as roughly one in five is unanswerable from your sources. Grow the set as failures show you where the model's edges are.
How often should hallucination checks be re-run?
Re-run the full evaluation before every model, prompt or retrieval change, and at least monthly in production. Also re-run whenever your source documents change, because stale sources create confident, grounded-looking errors.

Want a model trained on your own data?

Tell us what you want to build and we will send a scoped plan within 1โ€“2 business days.

Request a fit assessment

More from the blog

From Prototype to Production: Shipping an AI Feature Safely

From Prototype to Production: Shipping an AI Feature Safely

A practical checklist for taking an AI feature from prototype to production: evaluation gates, guardrails, staged rollouts, and monitoring after launch.
2026-10-26
Fine-Tuning for Classification Tasks: A Practical Walkthrough

Fine-Tuning for Classification Tasks: A Practical Walkthrough

Learn how to fine-tune a model for text classification step by step: dataset formatting, training, evaluation, and shipping a classifier you can trust.
2026-10-25
Why Your AI Pilot Stalled and How to Restart It

Why Your AI Pilot Stalled and How to Restart It

Most AI pilots never reach production. Learn the five real reasons an AI project stalls โ€” and the practical restart steps that get it shipped in weeks.
2026-10-25