To investigate chatbot hallucinations, record the exact claim and the source passage supposed to support it. Tone alone tells you very little. An incomplete rule, misleading context or a promise of an action the assistant cannot perform may explain the error. These seven causes help you choose a correction that addresses the actual failure.
What counts as an invented chatbot answer?
An invented answer contains a fact or assurance that the available knowledge does not justify. That differs from a missing match: saying information is unavailable is not a false answer. Nor is every error a retrieval failure; the system can find a relevant passage and still interpret it incorrectly.
Begin with a claim you can check, such as “delivery is free”. Split a long answer into separate statements about cost, timing and customer action. One sentence may be correct while the next is unsupported. This record lets you repair the actual gap without discarding every useful part of an answer because its ending contains an error.
First organise source answers using the procedure for preparing a chatbot knowledge base.
What to prepare before making a change
Collect the question, preceding conversation, answer, citations and active knowledge version. Note whether the error followed a supplementary question. A screenshot of the final sentence cannot explain why the assistant assumed a particular service or condition.
- Mark the first unsupported fact, not only the final incorrect conclusion.
- Compare citations with active knowledge rather than an unpublished document.
- Separate a policy error from a claim that an operation was performed.
- Keep a repeatable test question with personal details removed.
Keep correct answers of the same type in the sample too. If cancellation is explained accurately for one offer but incorrectly for another, compare their names and conditions in the sources. That difference is more informative than a general judgement about the model. Replace sensitive details with neutral examples while keeping the structure needed to reproduce the failure.
A procedure your team can use
The list below contains exactly seven causes to investigate. It is not a frequency ranking or a universal diagnosis. Several may affect one case; first correct the cause that allowed the unsupported claim to appear.
- An incomplete source rule.The source says a return is possible but omits eligibility. The model may fill the gap with a familiar pattern. Put the condition beside the rule and test an ineligible case. Do not invent a business policy simply to make the document look complete.
- Conflicting knowledge versions.Two pages give different deadlines. A citation does not decide which one applies. Ask the policy owner to resolve the conflict, remove or correct the outdated version and inspect the active publication. Leaving both versions in place is not a reliable way to select the newest rule.
- A rule applied to the wrong service.A condition for an introductory consultation is applied to a longer meeting. Name both services and their differences in the sources. Test a question with no offer name; clarification is appropriate if the answer really depends on which service the customer means.
- An unsupported inference.A source confirms dispatch, but the chatbot claims delivery. Finding the right topic does not support every sentence about it. Separate the stages and remove conclusions that go beyond the evidence. Keep the verified dispatch fact and explain how the customer can check the next stage.
- A false premise in the question.A customer asks when they will receive the free express service, although no such offer exists. Test questions that assume discounts, guarantees or unavailable features. The answer should correct the premise rather than build a detailed scenario on top of it.
- Mixed conversation context.After a topic change, the assistant still answers for the previous service. Compare a fresh conversation with the multi-topic one and record the switch. Include “I am now asking about another offer” in a test to distinguish a content problem from misuse of the conversation context.
- Pretending an action was completed.“I booked the appointment” can be unsupported even when the policy explanation is correct. Separate instructions from confirmation of execution. If the assistant cannot make bookings or orders, it must direct the customer to the actual form or a person instead of announcing completion.
After each correction, ask the original question, a shorter version and a version with the opposite condition. Avoid changing the source, offer description and evaluation rule simultaneously. If the fix removes an unsupported promise but also creates a refusal for an ordinary question, record both outcomes. Reducing risk should not mean refusing every useful answer.
The actual automation boundary is explained in AI in customer support; a new instruction cannot create a missing capability.
A worked example and decision record
A customer asks about Saturday and receives “I booked you in for 10 am”. The source only explains how to choose a slot in a form. This is an execution claim, so adding another FAQ about opening hours does not address the cause. The expected answer explains where available slots are shown and leaves booking confirmation to the customer.
Scroll the table sideways to see all columns.
| Item | Working record | How to check |
|---|---|---|
| Claim | The appointment is booked | No execution evidence |
| Source | Instructions for using the form | Supports the method, not a booking |
| Correction | Explain slot selection | Retesting must not announce success |
Booking evidence in this example would need to come from an actually completed booking process, not the assistant’s own text. A customer may understand a polite “all done” as confirmation that a slot is reserved. Evaluate the meaning of the entire response: even without the words “I booked”, the message must not imply that an operation took place. Customers read such a sentence as your company speaking, not the software; the guide on chatbot liability for wrong information explains why that matters.
Exceptions you need to handle
A citation is not an automatic accuracy stamp. Open it and inspect the service name, condition and effective policy. Calm wording and correct grammar cannot compensate for an unsupported business statement.
An unsupported price, entitlement or operation claim needs correction before public use. A high writing-style score does not cancel that failure.
Do not repair an answer about someone’s order by placing private order details in general knowledge. The source explains a policy; checking an individual account needs an authorised process. If personal confirmation is needed, the assistant should direct the customer to that process. A detailed invented status cannot replace identity verification or access to the real record.
NIST describes confabulation as a generative AI risk. The seven causes are our own diagnostic checklist for support conversations. NIST: generative AI confabulation risk.
For contradictory content, use the editorial rules for a knowledge base and FAQ.
Put the prepared process into practice
In Meet AI, inspect private test answers alongside citations from active knowledge. Missing reliable knowledge produces NO_MATCH without generation, and Copilot never sends a suggestion by itself. The app needs an active installation and an eligible plan; tests share the generation allowance with the other AI features.
Group corrections by cause: missing condition, conflict, wrong service, inference, premise, context or pretended action. Add the test question and expected fact to each record. The next editor can then understand why an answer boundary was added and avoid deleting it as unnecessary caution when shortening the source. If a wrong amount comes from a table in a file, first check how to prepare a PDF price list for the knowledge base, because the document layout itself is often the cause.
After a correction, run chatbot launch testing questions rather than accepting one successful example.
Practical questions and answers
These answers clarify how to introduce when a chatbot invents answers and can help your team agree on the operating rules.
Do more documents eliminate hallucinations? No. More sources can introduce additional conflicts. Add material when a rule is genuinely missing, then check that it does not duplicate an outdated answer.
Is refusal a failure? Refusal can be correct when reliable knowledge is absent. Check that the explanation is honest and that any proposed route to human help is actually available.
Is asking the question again enough? Repeating a question shows variation but does not repair the source or operating rules. Record the error, choose a correction and compare the same case again.
