Building a Chatbot That Doesn't Make Things Up
Grounding, retrieval and refusal rules — the three things that separate an impressive demo from a bot you can put in front of customers.
A chatbot that guesses is worse than no chatbot. A wrong price quoted confidently costs more than an unanswered message, because the customer acts on it. The fix is structural, not a clever prompt.
Rule 1 — Never answer from memory
The model's training data must never be the source of a factual answer about your business. Every fact — price, availability, opening hours, policy, order status — comes from a retrieval step against your live records, injected into the context at answer time.
If retrieval returns nothing, the correct behaviour is to say so. This has to be stated explicitly and repeatedly in the system instructions, because a language model's default behaviour is to be helpful, and being helpful without data means inventing.
Rule 2 — Make retrieval good before making the model good
Most "hallucination" in production is actually retrieval failure: the answer existed in the knowledge base and the search did not find it. Improving the prompt does nothing for that.
Chunk documents semantically — by section, not by fixed character count that splits a price table in half.
Combine keyword and vector search; pure vector search regularly misses exact product codes and part numbers.
Keep structured data structured. Prices and stock belong in a database queried by a tool, not in prose embedded as text.
Re-rank the top results before they enter the context window.
Rule 3 — Force citation
Require the model to return which record or document section each claim came from. Even when you do not show the citation to the customer, requiring it internally changes behaviour measurably: a claim with no source is far more likely to be dropped than invented.
Citations also make evaluation possible. When an answer is wrong, you immediately know whether the retrieval was wrong or the reasoning was.
Rule 4 — Give it a rewarded way to refuse
"I don't have that information — let me connect you to the team" must be a first-class success path, not a failure. Write it into the instructions with examples, and make sure the handoff actually works: a live channel, a ticket, or a callback request with context attached.
Escalate on uncertainty, on repeated misunderstanding, on anything involving money changing hands, and on anything the customer flags as urgent or a complaint.
Rule 5 — Constrain scope out loud
Tell the user what the bot can do in the first message. "I can check prices, availability and order status" sets expectations and cuts the volume of out-of-scope questions dramatically. A bot that pretends to do everything gets tested until it fails.
Testing before launch
Build a fixture set of fifty real questions with known-correct answers, taken from your actual support history. Run it after every change. Track three numbers: correct, refused, and wrong. Refusals are acceptable; wrong answers are not, and the wrong-answer count is the only one that must be driven to zero before launch.
Add adversarial cases deliberately: questions about products you do not sell, prices that changed last week, and requests to "just estimate" something. Those are exactly the inputs that produce confident nonsense.
After launch
Log every unanswered and every escalated question. Review that log weekly. It is simultaneously your content roadmap, your retrieval bug tracker, and the most honest product feedback you will ever receive — customers tell a bot things they would never put in a survey.