How do I stop my customer-facing chatbot from hallucinating?

How do I stop my customer-facing chatbot from hallucinating? You do not stop it fully. You make it happen less often, you catch most of the cases that remain, and you decide in advance what the bot does when it is not sure. First, give the bot only the documents it may quote. Second, score every answer against those documents. Third, send each score to one of three actions: answer, hedge or hand to a human. Most guides stop after the second step. The third step is where the money is saved. A wrong answer that reaches a customer is your answer, in law and in the customer’s mind.

How do I stop my chatbot from hallucinating? The short answer

Why does a wrong chatbot answer cost so much?

Your company owns what the chatbot says. In February 2024, a Canadian tribunal ruled on Moffatt v. Air Canada. The chatbot told a customer that he could ask for a bereavement fare after the flight. The airline policy did not allow this. Air Canada argued that it could not be held liable for what the chatbot said. According to reports of the ruling, the tribunal member rejected that argument. He found that the chatbot is part of the airline’s website, and that the airline did not take reasonable care to make sure the bot was accurate.

The award was small. The principle applies to every company. You cannot tell a customer that the bot made a mistake and that the bot is a separate party. I use this case when a client says that a disclaimer under the chat window is enough. It is not enough.

Can you detect hallucinations reliably?

No. You can detect many of them, and the quality depends on the method you choose. The Dataiku guide to hallucination detection says that no single method catches all types of hallucination. Production systems layer several methods. I agree with this, and I would add one point. Each layer has a different cost, so the order of the layers matters.

Langfuse describes a good order. First, run cheap deterministic checks on all traffic. These checks find missing citations and numbers in the answer that do not appear in the retrieved text. They cost nothing. Then send only the flagged traces to a judge model. The judge reads the user input, the retrieved context and the answer. It needs no reference answer. Langfuse suggests that you run the judge on sampled live traffic.

Openlayer lists three similar layers. They are deterministic checks, semantic scoring and real-time guardrails. Semantic scoring uses embedding similarity or an LLM as a judge. The guardrail blocks an answer when its groundedness falls below a threshold. The threshold is the important part. I come back to it below.

How good are the best detectors today? The HalluDetect paper is an EMNLP 2025 industry paper. It tests detection on a consumer grievance chatbot. The authors report an F1 score of about 69 percent for their detector. The ACL Anthology listing gives 68.92. The two versions of the paper differ on how much better it is than the baseline detectors. Thus read the number as a detector that misses real cases. This is a result on one chatbot in one domain. Your result will differ.

The authors of Luna state the requirement well. A detector must catch a hallucination before it reaches the user. It needs high accuracy, low cost and low delay. The paper also says that retrieval-augmented generation (RAG) reduces hallucinations. It does not say that RAG removes them. That leads to the next question.

Why does grounding help, and where does it stop?

Grounding means that the bot answers from documents that you retrieve, not from its memory. The model does not need to guess your refund policy. It reads the policy in the prompt. This removes the largest source of wrong answers. A model that guesses a policy will guess wrong with confidence.

Grounding stops in three places. First, retrieval can return the wrong document. The bot then quotes a real policy for a different product. Second, the right document can be old or can contradict another document. Third, the model can add a claim that no document supports. This last case is the one that detectors look for.

I wrote about the first two cases in RAG beyond the tutorial. The main point is that you must treat your corpus as a product. Someone must own it, date it and remove old versions. If two documents give two refund windows, the bot will pick one, and the detector will pass it, because the answer matches a source.

Thus a detector that compares the answer to the retrieved text does not find a bad corpus. It finds only a gap between the answer and the text. Keep this limit in mind when you read vendor claims.

What do you do with a flagged answer?

This is the question that most guides skip. A detector gives you a number. Your product needs a decision. I use three actions.

The first action is to answer. The score is high, the question is low risk, and the bot sends the answer as written. The second action is to hedge. The bot sends a shorter answer that quotes the source and says what it does not know. For example: “Our policy page says refunds take 5 to 7 days. I cannot see your order. Do you want me to ask a person to check it?” The third action is to hand off. The bot stops, tells the customer that a person will reply, and sends the chat with the draft answer and the sources to a human.

Each action has a price. An answer costs nothing and carries risk. A hedge costs a little trust, because the customer wanted a clear answer. A hand-off costs a person’s time and adds delay. Your job is to put each question in the cheapest action that you can accept.

I use the same pattern in other work. In Jev at a cybersecurity firm, a model scores a pentest report before the customer reads it. The system has three tiers of escalation, and the cost is about $0.05 a day. The model does not need to be perfect. It needs to know when to stop and ask. I describe the reason for this design in human in the loop. In that post, the main risk is a design bug. The fix is a system that you can reverse and check.

How do you set the escalation threshold?

Start with this fact: one threshold is not enough. The same score should lead to different actions for different questions. A wrong answer about opening hours is a small problem. A wrong answer about a refund, a medical dose or a contract term is a large problem. Thus the threshold depends on the cost of an error, not only on the score.

The first figure shows this. The distribution has three options, and the bars show their probabilities. The bot picks the top option. The confidence gate on the right shows how peaked the distribution is. The figure uses an agent that edits files, but the idea is the same for a chatbot: you do not act on the top answer if the distribution is flat.

Watch the top option. It stays the same when you drag the ambiguity slider, but the confidence falls. Then switch to the destructive action. The answer is the same, and the bar for acting without a human moves from 0.5 to 0.9. In a chatbot, a refund answer is the destructive action. A question about opening hours is the read-only action.

The second figure shows the three tiers. It uses a risk score and a confidence value. Below the first line, the flow passes. Between the lines, the flow continues with a flag. Above the second line, the flow stops until a person approves it. The figure labels the score as the probability of misuse. For a chatbot, you use the probability that the answer is not supported by the sources.

Watch what happens when you drop the confidence below 0.6 while the risk is low. The request can no longer pass. It goes to the flag tier, and a person looks at it. This is the rule I trust most. A detector that is unsure must not give a green light.

You do not take the numbers in the figures as final values. They are examples. Set your own numbers with data, in this order:

1. Collect 200 to 500 real or realistic conversations, and label each answer as supported or not supported by the sources.
2. Run the detector and plot the score for the two groups.
3. Choose the hand-off line so that the detector catches the wrong answers that matter most.
4. Count how many correct answers the line sends to a human. If the count is too high, the team will ignore the queue.

The fourth step is where many projects fail. A human queue with too many false alarms is a queue that nobody reads. I set the line with the team that will work the queue. I ask them how many items they can review each day, and I work back from that number.

How do you test it before launch?

Test the whole path, not only the detector. The path has retrieval, generation, scoring and the action. A bug in any part gives a wrong answer to a customer. I test four things.

The questions with no answer are the most useful. A bot that always finds an answer is a bot that hallucinates. Count how often the bot says “I do not know” on these questions. If the count is zero, you have a problem.

For checks on actions, such as a refund that the bot starts, I use delta verification. A test can pass when the system already held the answer. Delta verification takes a baseline first. Then it asserts on the change. It is the best fix I know for tests that are green without cause.

Add guardrails on input and output as well. The design of those checks is in how to build LLM guardrails. Put the groundedness check in the same layer as the other output checks, so that one component owns the decision to send or block.

Last, plan the weekly review. A detector drifts when your documents, your products or your customers change. Read the flagged items each week, and read a random sample of the passed items. The passed items show you what the detector misses. This is the only way to learn the real miss rate.

So how do you stop a chatbot from hallucinating?

You lower the rate with grounding, you catch most of the rest with layered checks, and you send every uncertain answer to a hedge or a person. The detector is one part. The calibrated threshold and the human queue are the parts that make the system safe. Test them before launch with questions that have no answer, and review the flagged and passed samples each week. I build this layer for clients as a fractional AI CTO. If you need help, see my page for an agentic AI engineer.