Skip to main content
Adrean Jan Quidor (Kofeejan)
All blogs

Taming AI Support Bots with a Retrieval Confidence Gate

PythonRAGChromaDBGeminiAISupport Automation

[ WHY THIS MATTERS ]

Naive RAG pipelines trust the LLM to decide when evidence is good enough — and hallucinations slip through on weak semantic matches.

A retrieval confidence gate short-circuits low-evidence tickets before model invocation, turning unpredictable guesses into safe escalations.

Building an AI support ticket triager sounds straightforward: connect a Large Language Model (LLM) to your knowledge base using Retrieval-Augmented Generation (RAG), and let it answer customer questions.

But as soon as you put it in production, you encounter the classic RAG trap: out-of-domain hallucinations. When a user asks a question that isn't covered by your documentation, semantic search still returns the closest chunks it can find. The LLM, eager to help, looks at these barely relevant chunks and confidently invents a policy, fabricates a feature, or gives a dangerously wrong answer.

Telling the LLM via its system prompt — only use the provided context, do not fabricate — helps, but it is not bulletproof. LLMs are generative by nature; they want to answer. The solution is a Retrieval Confidence Gate: move the responsibility of deciding whether to answer out of the LLM's prompt and into deterministic code.

The flaw of prompt-only routing

In a naive implementation, the flow looks like this: the user submits a ticket, the system retrieves the top 5 chunks from the vector database, and the LLM is prompted to read the chunks and either answer or say it does not know.

The problem is that you are trusting a probabilistic model to make a binary routing decision based on ambiguous text. If retrieval returns a 10% match, the LLM might still latch onto a single keyword and guess.

The retrieval confidence gate approach

Instead of relying on the LLM to judge the quality of retrieved evidence, measure it mathematically before the LLM ever sees the prompt.

Vector databases calculate a distance metric (e.g., cosine distance) between the user's query and the retrieved documents. A lower cosine distance means a higher semantic match. A deterministic gate evaluates these distances — if the best retrieved document is not close enough, short-circuit the process and auto-escalate the ticket to a human. The LLM never gets called.

The core logic checks two rules: the best match must be below a strict distance threshold, and the average of the top 3 matches must also be solid. If either fails, the pipeline returns a pre-canned escalation response with an internal reason code — skipping the LLM entirely.

Concrete examples: a tale of two tickets

Case 1 — the standard FAQ: a user asks whether coding tests expire automatically after assignment. Retrieval finds chunks about test expiration settings and candidate invitations. The best cosine distance is 0.21 — well below a 0.45 threshold. The gate returns proceed, and the LLM generates a grounded, accurate reply.

Case 2 — the off-topic curveball: a user asks who played Tony Stark in the Iron Man movies. The database has nothing on Marvel movies and retrieves random chunks containing words like man, play, or name. The best cosine distance is 0.85 — far above threshold. The gate returns auto-escalate immediately. The LLM is never invoked, guaranteeing zero chance of hallucination and saving compute costs.

Tradeoffs

  • Tuning distance thresholds requires effort — too strict and you auto-escalate tickets the LLM could have answered (false negatives); too loose and hallucinations slip through (false positives). Analyze a sample dataset of real tickets to find the Goldilocks zone for your embedding model.
  • Extra retrieval latency — if you previously relied on an LLM agent to decide when to search via function calling, you now run a bootstrap retrieval step upfront to evaluate confidence. This adds slight latency at the start of the pipeline.
  • Loss of creative troubleshooting — sometimes a complex, multi-part question has no single perfect semantic match, but the LLM could synthesize a great answer from pieces. A strict distance gate might block these edge cases. Mitigate with a retry loop: if confidence is low, retry with a broader filter or rewritten query before finally escalating.

Conclusion

By shifting the burden of should I answer this from the generative LLM to deterministic code, you gain predictability and safety. A retrieval confidence gate ensures your AI support agent only speaks when it actually has the evidence to back it up, turning unpredictable hallucinations into safe, graceful escalations.