Three ways to stop a support bot from making things up

A model asked a question will produce a plausible answer. That is the entire job description. It has no separate faculty for "and is this true" — truth has to be built around it, structurally.

Three mechanisms do most of the work. They compound, and none of them requires a better model.

1. Grounding: make the sources the only input

The instruction that matters is not "be accurate" or "do not hallucinate" — those are wishes. It is a constraint on where content may come from.

Answer using ONLY the passages below.

If the passages do not contain the answer, reply exactly:
"I don't have that in our documentation — let me get you
to someone who can help."

Do not use general knowledge. Do not infer values that are
not stated. Do not combine passages to produce a figure
that appears in none of them.

PASSAGES:
{{retrieved}}

QUESTION: {{question}}

The third paragraph is the one people leave out and then regret. Without it a model will happily add two numbers from different plans to produce a total that exists nowhere, and present it with the same fluency as a quoted fact.

2. Citations: make every claim traceable

Requiring a source link per claim does three separate jobs, and the second is underrated.

• For the customer: they can verify, and they can read further.
• For the model: having to attach a source to a sentence suppresses sentences that have no source. The requirement itself is a constraint on generation.
• For you: a wrong answer with a citation is instantly debuggable — either the source is wrong, or it was misread. Both are quick fixes. A wrong answer with no citation is an investigation.

3. Refusal: make "I don't know" a cheap, valid outcome

Most systems make declining the hardest path. The prompt says be helpful; the metrics reward containment; the retrieval layer always returns something, however weak. Answering is the path of least resistance, so the model answers.

Rebalance it deliberately:

1. 1Set a similarity floor. If the best passage scores below your threshold, return nothing to the model rather than the least-bad match. An empty context with a clear refusal instruction is far safer than a misleading one.
2. 2Give refusal a script. Provide the exact sentence, plus the escalation path. A model with a well-defined way to decline will use it; a model with only a vague permission will not.
3. 3Reward it in review. When you audit conversations, mark good refusals as successes. If your team treats every "I don't know" as a failure, that pressure ends up in the prompt.

The most trustworthy sentence a support bot can say is the one that admits the limit of what it knows. Design the system so that sentence is easy to reach.

Temperature, briefly

Keep it low — 0 to 0.3 for support. Creative variance is a virtue in marketing copy and a defect in a refund policy. There is no upside to a bot that phrases your SLA differently each time it is asked.

Test it adversarially

Build a small set of questions your documentation deliberately does not answer, and run it every time you change the prompt, the model or the index:

• Questions about features you do not have ("what's your SOC 2 status?" when you have no page on it).
• Questions with false premises ("why does the Enterprise plan cap at 3 seats?").
• Questions requiring arithmetic across sources ("what's the total for 4 seats billed annually with the education discount?").
• Questions about competitors, futures and prices you have never published.

The pass condition is not a clever answer. It is a clean refusal. A bot that scores 100 per cent on this set is one you can leave running unattended — which is, in the end, the only thing anyone actually wants from it.