AI hallucinations: when a convincing answer is wrong.

What are AI hallucinations?

An AI hallucination is an output that presents invented or unsupported information as though it were established. In a business application, that might be a false product capability, a made-up explanation or a reference that does not support the answer. Fluent wording can make the error harder to spot.

For recovery work, the important question is which claim is wrong, what evidence should support it and where the system departed from that evidence.

Three failures that can look similar

Wrong information was retrieved.

A RAG assistant may receive material that is irrelevant to the user’s question. Inspect the actual retrieved passages before changing the answer instructions. If the needed source was never supplied, the failure may begin in content preparation or retrieval.

The answer goes beyond its sources.

The right document can be present while the model adds an unsupported detail. Compare the material claims with the supplied context. Citation presence alone does not establish that an answer is grounded.

The system invents a product promise.

An answer may sound plausible while describing something the product cannot do. Product capability is a separate boundary to check: a useful assistant needs to describe the actual application accurately.

Can RAG stop hallucinations?

RAG supplies retrieved information that can help ground an answer. It is not a guarantee of accuracy: incorrect retrieval or unsupported generation can still produce a bad result. Microsoft describes these limitations in its RAG guidance.

If your system already uses a vector database, the next step is to inspect what it retrieves and how the response uses it. Adding more documents without understanding the failure may not resolve the problem.

A practical way to investigate

1. Save a representative example. Keep the question, response, retrieved material and expected behaviour together.
2. Identify the unsupported claim. Be specific about what is false, missing or beyond the product’s capabilities.
3. Locate the first failure. Check whether the source was available, whether it was retrieved and whether the answer followed it.
4. Choose a targeted change. Investigate content, retrieval, context or answer boundaries according to the evidence.
5. Repeat meaningful checks. Include ordinary questions, previous failures and requests the system cannot answer.

Measure the behaviour that matters.

Agree how you will assess supported claims, relevant sources and suitable treatment of uncertainty. Separate these checks from response speed and cost. Microsoft’s RAG evaluation guidance explains why several quality measures may be needed to judge an answer.

A repaired example is a useful starting point; it does not demonstrate the behaviour of every question. Include a representative set and record the remaining limitations.

Get help with an unreliable AI product.

Our RAG consulting and chatbot recovery starts with the actual failure. For an agent or integration problem, explore AI system rescue. The free initial assessment is a first conversation; detailed evaluation and engineering are scoped separately.