Your chatbot is making things up because it has nothing to read

A customer asks your chatbot about the refund window. It answers, politely and precisely: 60 days, no questions asked. Your policy is 14 days. The customer screenshots the reply, and now you are either honoring a policy you never had or arguing with someone your own website misled.

This is the chatbot problem we get called about most. It is also, most of the time, fixable without a rebuild.

Why a chatbot starts making things up

A language model does not look anything up. It continues text. Ask it about your refund policy and it produces the most plausible-sounding refund policy given everything it has read, and on the wider internet 30 and 60 day windows are common. Plausible and true overlap often enough to be dangerous.

It will not say "I don't know" on its own, because it has no way of knowing that it does not know. Confidence is a feature of its writing style. Adding "do not hallucinate" to the prompt does close to nothing, and we have inherited several bots where that line was the entire fix attempt. What works is changing what the model can see and what it is permitted to say.

Grounding

The standard approach is retrieval, usually called RAG. Before the model answers, the system searches your documents, puts the relevant passages into the prompt, and tells the model to answer from those passages only. Most broken chatbots we see either have no retrieval, or have retrieval that was set up once and then forgotten.

Forgotten is the part that hurts. One support bot we scoped was quoting a price list from 2024. The retrieval index had been built when the bot launched and never rebuilt after the product page changed, so the bot was faithfully citing a document that no longer existed anywhere except inside its own index. Retrieval was working perfectly. It was just retrieving the wrong year.

Done well, grounding needs a few things in place:

• Chunking that follows the document. Your documents get split into pieces before indexing. If the splitter cuts a pricing table in half, retrieval returns half a table and the model fills in the rest. One policy, one FAQ answer, or one product section per chunk, with the heading kept attached so the chunk still makes sense on its own.
• A rebuild schedule for the index. Whenever a source document changes, the index has to be rebuilt, either automatically on publish or on a fixed cadence with a named owner, which is precisely what a care retainer should cover. See the 2024 price list above.
• Citations on every answer. When the bot is wrong, you look at the retrieved passages and see straight away whether retrieval pulled the wrong document or the model ignored a right one. Those are different bugs with different fixes, and without citations you are guessing which one you have.
• A refusal path. When retrieval finds nothing relevant, the correct reply is a handoff: "I don't have that information, here is how to reach a person." A bot that answers most questions correctly and hands off the rest is a good product. A bot that answers everything, some of it invented, is a liability with a chat window.

Never let the model write a price

Even with good retrieval, some answers should never be generated at all. Prices, refund terms, legal commitments, stock availability. For these the model should pick a template and the system should fill it. The model classifies the question ("pricing, product X"), a fixed human-approved answer is loaded, and the numbers come from your database or a maintained table. The model chooses which template. It never writes the digits.

That is the one guarantee prompting cannot give you: a bot that is structurally unable to invent a price, because the price never passes through the generative step.

30 to 50 questions, scored

This is what separates bots that stay fixed from bots that break again next quarter, and nearly everyone skips it. Collect 30 to 50 questions your customers have asked, from chat logs, support tickets, or your team's memory, and write the correct answer for each. That is your eval set. Kept in a file and rerun on every change, it becomes an eval set that catches a model update before a customer does.

Run every question through the bot and mark each answer correct, wrong, or correctly refused. Do it before the fix for a baseline, after the fix to prove it worked, and again after every change: a new document, a prompt edit, a model version bump. Without this, every change is a gamble, and a model update can quietly move your quality in either direction until a customer notices first. With it, a regression shows up as a number the same day.

It is a spreadsheet and an afternoon.

Fix or rebuild

The answer decides your budget, so this is our triage in plain terms. If the bot has a knowledge base but the chunking is poor, refusal is missing, or the prompt invites improvising, the design is fine and only the configuration needs work; that is a small fix, $750 to $1,500, usually done in 2 to 5 days. If retrieval has to be added or rebuilt, templates need wiring to live data, and an eval set needs creating, that is a standard rescue at $1,500 to $4,000 over 1 to 2 weeks.

A rebuild at $4,000 to $10,000 is justified only when the platform cannot support retrieval or structured answers at all, which does happen with some no-code chatbot builders that give you a prompt box and nothing else. In that case the advice above will not help you, because there is no layer to configure. If someone recommends a rebuild without naming a specific missing capability, ask them to name it. The general version of that judgment, with the price bands attached, is when to fix and when to rebuild a broken AI system.

If you want certainty before spending anything, we do a written diagnostic for $500. Within 3 business days you get a document showing where your bot's wrong answers come from, an eval baseline, and a fixed quote, and the $500 is credited against the repair. Details at our rescue service, or send us a transcript of the bot being wrong.