What are AI chatbot hallucinations?
A hallucination is a confident, plausible-sounding output the model fabricates — with no basis in its retrieved sources or verified training data. Unlike ordinary errors (misreading a passage, transposing a number), hallucinations are unanchored: the model invents a fact from scratch and presents it as certain.
The risk is not theoretical. In Moffatt v. Air Canada (2024 BCCRT 149), Air Canada's website chatbot told passenger Jake Moffatt he could retroactively apply for a bereavement fare after his travel was complete. The airline's actual policy said the opposite. When Moffatt followed the chatbot's instructions and was denied the refund, he filed a complaint with the British Columbia Civil Resolution Tribunal. The tribunal ruled against the airline and awarded $812.02 in damages and fees — a landmark decision establishing that businesses are legally responsible for every statement their chatbots make, regardless of how those statements were generated.
Hallucinations occur across all large language model deployments, but their frequency and severity depend heavily on how the chatbot is architected and instructed. The good news: this is an engineering problem with known solutions.
Why do hallucinations happen in the first place?
Hallucinations are an emergent property of how language models work, not a simple bug you can patch out. Three root causes matter most in a small-business chatbot context.
- Parametric memory gaps: LLMs are trained on broad corpora and store knowledge in their weights. When a question touches a topic that is absent or ambiguous in training data — your pricing, your service area, your refund terms — the model fills the gap by plausibly extrapolating rather than admitting ignorance.
- Missing retrieval grounding: Without a document retrieval layer, the model has no mechanism to check its output against authoritative sources. It generates from statistical patterns alone.
- Ambiguous or open-ended prompts: Vague system instructions ("be helpful, answer anything") encourage the model to attempt responses even when it has no reliable basis for them. Overly broad scope invites fabrication.
- Confidence without calibration: Standard LLMs do not have built-in uncertainty estimates. The model presents a hallucinated answer with the same surface confidence as a well-grounded one — making errors invisible to the visitor.
Stanford HAI researchers studying hallucinations in deployed AI systems have noted that LLMs can hallucinate in two distinct ways: producing factually incorrect content, or producing content that is broadly correct but cites sources that do not support the claim — a form of misgrounding that is particularly hard to catch in production.
What are the 6 controls that actually reduce hallucinations?
The controls below are ordered from highest to lowest impact. Applying the first three together — RAG, refusal prompts, and scope limits — will eliminate the large majority of hallucinations in a well-defined business chatbot. The remaining three add depth for higher-stakes deployments.
- 1
Ground answers in RAG (Retrieval-Augmented Generation)
RAG retrieves the most relevant passages from your own documents and feeds them to the model as context before generating a reply. The model is then instructed to answer only from that context. Lewis et al. (NeurIPS 2020) demonstrated that RAG models generate "more specific, diverse and factual language" than parametric-only models — because the answer is anchored in real content, not statistical extrapolation. For a small business, this means uploading your service pages, FAQs, pricing, and policies so the chatbot can cite them directly.
- 2
Write explicit refusal prompts
The system prompt must explicitly instruct the model to say it does not know rather than guess. A minimal version: "If the answer is not contained in the documents provided, respond with: 'I don't have that information. [Fallback action].' Do not invent an answer." Without this instruction, the model will attempt to be helpful by generating a plausible response — which is where hallucinations live. The refusal prompt is the cheapest, highest-leverage control available.
- 3
Set strict scope limits
Define exactly what the chatbot is and is not allowed to discuss. A chatbot for a plumbing company should not attempt to answer medical questions, legal advice queries, or competitor pricing questions. Narrow the topic surface in the system prompt ("only answer questions about [Company Name]'s plumbing services, pricing, and booking") and add a catch-all fallback for anything outside it. Narrow scope also makes it easier to test: you can enumerate the domain and verify coverage.
- 4
Show source attribution
Configure your chatbot to display which document passage it used to generate each answer. Inline citations ("according to our FAQ…" with a link) do two things: they force the model to locate a real source before answering (suppressing fabrication), and they give visitors a way to verify and correct the answer if it is wrong. Visible sourcing also builds trust — especially on higher-stakes queries about pricing, policies, or eligibility.
- 5
Apply confidence thresholds with fallback to human
Most RAG implementations produce a retrieval confidence score alongside each answer — how closely the retrieved passages matched the query. Set a minimum threshold below which the bot should not attempt an answer and should route to a human or capture form instead. This catches the residual cases that pass the refusal-prompt filter: queries that are plausibly in-scope but where the retrieved evidence is weak or contradictory.
- 6
Monitor conversations and correct knowledge continuously
Hallucination reduction is not a one-time setup. Review a sample of chatbot conversations weekly, flag answers that are wrong or vague, and update the underlying knowledge base. The most reliable signal is when a visitor says "that's wrong" or asks a follow-up that makes no sense given a previous answer. Build a correction workflow: identify the gap, add or update the source document, and re-index. Over time, this closes the long tail of edge-case hallucinations that static controls miss.
How do the controls compare on effectiveness vs. implementation cost?
Not all controls are equal. The table below ranks each control by its estimated impact on hallucination rate and the typical effort to implement it on a small-business chatbot. "Impact" is assessed relative to a baseline prompt-only chatbot with no retrieval grounding.
| Control | Hallucination reduction | Implementation effort | Best for |
|---|---|---|---|
| RAG grounding | Very high — removes the primary cause | Medium (requires doc ingestion pipeline) | All chatbots with factual Q&A |
| Refusal prompts | High — eliminates confident fabrication | Low (system prompt edit) | All chatbots, no exceptions |
| Scope limits | High — shrinks the surface area for errors | Low (system prompt edit) | Domain-specific bots (support, lead capture) |
| Source attribution | Medium — creates accountability, speeds correction | Low–medium (UI + prompt change) | Support bots, policy queries |
| Confidence thresholds | Medium — catches weak-retrieval edge cases | Medium (platform configuration) | Higher-stakes deployments |
| Continuous monitoring | Cumulative — closes the long tail over time | Ongoing (human review) | Any production chatbot |
What does a responsible refusal look like in practice?
A clean refusal is more useful to the visitor than a fabricated answer. When the chatbot lacks reliable information, it should: (1) acknowledge the gap honestly, (2) avoid hedging language that still implies a factual claim ("I think it might be…"), and (3) route the visitor to a concrete next step.
- "I don't have that information in our current docs. You can reach our team at [contact link] and they'll get back to you within one business day."
- "That's outside what I'm set up to help with — for [topic], the best resource is [specific URL or person]."
- "I'm not certain enough to give you a reliable answer on that. Let me connect you with someone who can." (followed by a calendar link or form)
What to avoid: answers that start with "I believe," "I think," or "typically" when the bot has no sourced basis for the claim. These hedges feel polite but still create a factual impression the visitor may act on. The Air Canada chatbot did not say "I'm not sure" — it gave a specific, actionable instruction that turned out to be wrong. That is exactly the failure mode a well-written refusal prompt prevents.
How does Knobot handle hallucination risk by design?
Knobot is built on a RAG architecture — every answer is generated from your uploaded content (service pages, FAQs, policies) rather than from general model knowledge. The system prompt includes a default refusal instruction so the bot will decline out-of-scope queries from day one. Source passages are surfaced in the conversation for visitors who want to verify an answer.
The dashboard's conversation review screen lets you spot hallucinations quickly: you can see which source passage the model cited alongside the reply it generated. If a passage is missing or outdated, you can edit it directly and the change takes effect on the next query. This closes the monitoring-and-correction loop that most off-the-shelf chatbots leave open.
Scope limits and confidence thresholds are configurable per bot — useful if you deploy Knobot on a single-purpose page (e.g., a booking flow) where the acceptable topic surface is narrow. Multi-business accounts can configure different scope rules per location or brand.