How to Stop a Customer Chatbot From Making Things Up
By CodexierPublished 6 min read
A customer chatbot that confidently invents an opening hour, a price or a return policy is worse than no chatbot at all, because the customer believes it. The fix is not a smarter model. It is a set of guardrails: answer only from approved sources, refuse gracefully when the sources are silent, log every uncertain reply and test with trick questions before and after launch.
Why language models invent answers
The mechanism is simple. A model is trained to continue text in the most likely way. Ask it about your return window and it will produce something that sounds like a return window, because that is what such sentences look like online. Unless you have given it your actual policy and told it to answer only from that, it has nothing else to draw on.
Restrict answers to approved sources
The technique is usually called retrieval-augmented generation: before the model answers, the system searches a small library of your own documents and hands the relevant passages to the model with the instruction to answer from those passages only. What goes into that library decides everything.
- Start with the documents customers already argue about: prices, delivery times, return and cancellation terms, opening hours, service areas.
- One owner per document. If nobody is responsible for keeping the delivery-time page current, the bot will confidently repeat last winter's figures.
- Prefer short, dated, single-topic pages over one long PDF. Retrieval works on passages, and a passage that mixes three topics confuses it.
- Exclude anything you would not put on your website: internal notes, draft prices, old campaign pages.
This is the same preparation we do in a chatbot setup, and it takes longer than the technical configuration. Most companies discover their policies are scattered across email templates, a wiki and someone’s memory. Writing them down once is a benefit in itself.
Refusal and fallback wording
A bot that never says no will make things up, so the refusal has to be designed as carefully as the answers. The wording decides whether the customer feels helped or fobbed off.
| Situation | Poor response | Better response |
|---|---|---|
| No source covers the question | Guesses a plausible answer | Says it does not have that information and offers a human contact or a form |
| Question touches money or law | Quotes a number from memory | Quotes the source passage verbatim and links to the page it came from |
| Customer is upset or the case is unusual | Keeps answering in a loop | Hands off to a person with the conversation attached |
| Sources disagree | Picks one silently | States that the information is being checked and escalates |
Write the refusal messages yourself, in your own tone. Generic model refusals sound evasive and push customers to the phone.
The single most useful instruction is to make the bot cite where an answer came from. A reply that names the page it quotes is checkable by the customer and by you, and the discipline of citing makes unsupported answers far less likely.
Logging and weekly review
You cannot inspect every conversation, and you do not need to. What you need is a queue of the conversations most likely to contain an invented answer, and a fixed half hour each week to go through it.
- Log every reply where retrieval returned nothing or returned only weak matches. These are the prime candidates for hallucination.
- Log every hand-off and every refusal, so you can see which questions your documents fail to cover.
- Each week, read the queue, fix the source document behind each bad answer, and add the question to your test set.
- Keep the log inside the EU and set a retention period. Conversations often contain personal data, and GDPR applies to a chatbot exactly as it does to email.
This loop is where the value compounds: every corrected document removes a whole class of wrong answers, and after a couple of months the queue is mostly empty.
Testing with trick questions
Before launch, and after every change to the documents or the model, run the same fixed set of questions and compare the answers. The set should be built to provoke invention, not to flatter the bot.
Questions with no answer
Ask about a service you do not offer, a city you do not serve, a discount that does not exist. The only passing answer is a refusal.
Questions with a precise answer
Ask about a price, a deadline, a policy detail. The answer must match the source word for word, with a citation.
Leading questions
Ask as if a false premise were true, for example about the free returns you do not offer. The bot must correct the premise, not go along with it.
Persuasion attempts
Ask it to promise a delivery date or make an exception. It must decline and route to a person.
When you do not need this: if your customer questions are genuinely unique each time, or if you get only a handful a week, a well-written FAQ page and a fast reply routine beat any bot. We would rather tell you that on a free call than sell you guardrails for a system you do not need. If the volume is there, this checklist is exactly what we implement, and the full price list is on the pricing page.
Frequently asked questions
Can a chatbot be stopped from hallucinating completely?
Not to zero, but close enough to be safe. Restricting answers to retrieved passages, requiring citations and routing everything else to a refusal removes the large majority of invented answers. The weekly review loop catches the rest and turns each one into a document fix.
Does a bigger or newer model solve the problem on its own?
No. Larger models are more fluent, which makes their wrong answers more convincing, not less frequent. The guardrails matter far more than the model. A modest model with strict retrieval and refusals outperforms a top model with neither.
What should the bot do with questions about prices?
Quote the exact passage from your price page and link to it, or refuse and hand off. Never let it calculate, round or estimate a price. If pricing depends on details, collect them and pass them to a person.
Want a chatbot that only says what your company has actually written down?
Bring your current FAQ and the three questions customers ask most. In fifteen minutes we can tell you what documents are missing, what the guardrails would look like and whether a bot is worth it at your volume.
Book a free 15-minute call