Build a support bot that knows when it doesn't know

The hard part of a support chatbot is not answering. It is the moment it does not know the answer. Get that wrong and you have built a confident liar that invents a refund policy and sends it to your customer. Get it right and a question it cannot answer becomes a captured lead instead of a dead end.

Here is how I built one that knows its limits, without the brittle trick everyone reaches for first.

Ground it, do not let it free-associate

A support bot should never answer from the model's general knowledge. It answers from yours. So every question starts with retrieval: embed the question, pull the most relevant entries from the business's own Q&A, and hand those to the model as the only material it is allowed to use. The model writes the reply, but the facts are the owner's, not the internet's. This is the cheap, boring part that keeps it honest.

Do not gate on a similarity score

The obvious way to detect "I do not know" is a threshold: if the best match scores below some cosine number, declare defeat. Do not do this. Similarity scores are not calibrated. A perfectly answerable question can score low because it is phrased oddly, and an unanswerable one can score high because it happens to share words with an unrelated entry. Pick a threshold and you will spend forever tuning a number that is wrong for half your traffic.

Let the model decide instead. It is reading the retrieved entries and the question together. It is in a far better position to say "none of this actually answers what they asked" than a raw distance metric is.

Give it a clean way to say "I can't"

So I give the model an explicit escape hatch. If it cannot answer from the provided material, it starts its reply with a sentinel marker, a literal token at the very front of the message. The server sees that marker, strips it, and flips a "this was a fallback" flag in the response. The user never sees the token. They see a graceful "I am not sure about that, let me get you to someone who is."

A sentinel token sounds crude next to a clever confidence score. It works far better, because it is the model making a judgment with full context, not a number making one with none.

Escalate in stages, never dead-end

An "I do not know" is not a failure to hide. It is the most valuable moment in the conversation, because it is exactly when a real human lead is worth capturing. So the fallback escalates instead of giving up:

• The first time it cannot answer: just say so, plainly. Maybe the next message goes better.
• The second time: stop pretending. Show a contact form, a link, a handoff. Turn the gap into a captured email instead of a frustrated user closing the tab.

The bot's job was never to answer everything. It was to answer what it can, admit what it cannot, and make the admission useful.

What I would tell someone starting

• Retrieval is not optional. An ungrounded support bot is a liability, not a feature.
• The interesting logic lives in the "I do not know" path, so design that first, not last.
• Resist the threshold. Every hour you would spend tuning a cutoff is better spent letting the model judge and handling its verdict well.
• A confident wrong answer costs more than ten honest "let me get someone." Optimize for the honest ones.