Design an off topic filter for a banking support chatbot

Short answer·Medium·4.0 · 0·~3 min·Asked atAi4bharat Razorpay Together Ai

Attempt it

Your bank deploys an LLM support chatbot. Product says it should only answer banking questions, not politics, not coding help, not therapy. Sketch the off topic gate: what signal do you use, where does it sit, and how do you handle false positives?

Free · 2 AI evals / day

The product rule is simple: the bot answers banking questions, nothing else. The design question is how to enforce that cheaply and without alienating users when the filter is wrong. The basic structure is a topic classifier sitting on the input rail, before the main model runs. The cheapest workable choice is embedding similarity, embed the user's query, compare against a small set of topic centroids built from canonical banking questions, and accept if the similarity to any centroid is above a threshold. This runs in single-digit milliseconds and is essentially free. For ambiguous cases (similarity in a middle band), you cascade to a heavier check: a small fine-tuned classifier, or an LLM-as-judge with a short policy prompt that returns yes/no with a one-line justification. The cascade keeps the average latency low while preserving accuracy on the hard cases. On a block, the worst thing you can do is silently refuse. Show a templated message that names the policy ('I can only help with account, card, and transaction questions') and offers two or three clarifying buttons. That way a false-positive turns into a one-click correction instead of a frustrated user. Log every block and review a sample weekly.

**Cascade two checks on the input rail; route blocks to a templated message, not a silent refusal.** Start with embedding similarity. Build a centroid per allowed topic (accounts, cards, transactions, loans, branches, security) from a few hundred canonical questions per topic. At runtime, embed the user query and check the maximum cosine similarity against any centroid. Above a high threshold, accept; below a low threshold, block; in the middle band, cascade to a heavier check. Total latency on the fast path is around 5 ms. For the middle band, route to an LLM-as-judge with a short policy prompt: 'Is the following query about a banking topic? Reply yes or no.' This costs around 100-200 ms and uses a small model. Accuracy on the ambiguous slice is much higher than the embedding alone would deliver. On a block, return a templated response that names the policy and offers options: 'I can only help with account, card, transaction, loan, branch, or security questions. Did you mean one of these?' with two or three clarification buttons. False positives become one-click corrections. Close the loop by logging every classification, sampling low-confidence blocks to a review queue, and retraining the classifier or updating centroids weekly against a versioned golden set. The off-topic rate and the false-positive rate are both worth a dashboard.

TL;DR

Cascade an embedding-similarity check then an LLM-as-judge on the input rail; on a block show a templated message naming the policy and offering clarifying buttons.

Memory aid

Easy to grasp

Picture the front desk of a bank. Before you reach a banker, a receptionist asks what you are here for. If you say 'I want to open an account,' you go through. If you say 'I want to discuss yesterday's election,' the receptionist politely says the bank only handles money questions and points you to the actual help you need. The receptionist is fast and friendly, not a closed door. If the receptionist makes a mistake, turning away a real customer, there is a manager nearby who can step in. The off-topic filter is the receptionist. The point is to keep the bankers focused without making real customers feel rejected.

Key concepts

Safety and Guardrails Embeddings LLM Evaluation

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

An off-topic filter looks deceptively simple. The product wants the bot to answer banking questions only. The temptation is to put the rule in the system prompt and hope the model obeys.

The production reality is different. A reasonable cost target rules out spending a main-model call on every off-topic query, the worst false positive is more expensive than the worst false negative for a customer-support bot, and the gate has to keep working as the product's scope evolves. The design that satisfies all three is a layered input rail with explicit feedback paths.

Why an input rail and not the main prompt

You could ask the main model 'is this banking? if not, refuse.' It works, but the economics are wrong. Every off-topic query costs a full main-model call. For a 100M-call per month product where 20% of traffic is off-topic, that is 20M wasted calls.

An input rail handles the same decision for a small fraction of the cost. It runs before the main model, blocks off-topic queries with a fixed template, and only pays the main-model cost on legitimate banking traffic. The savings compound over the year.

There is a second reason: the rail decision is auditable. The main model's chain-of-thought reasoning about whether something is banking is opaque and inconsistent across calls. A dedicated classifier with a logged confidence score gives the team a clean signal to dashboard and tune.

Three classifier choices and when to use each

Designing the user-facing block

Calibration, drift, and the feedback loop

What the off-topic rail does not do

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Approach	Latency	Cost per call	Accuracy
Embedding similarity to centroids	~5 ms	fractions of a cent	Good on clear cases, weak on mixed-intent
Fine-tuned BERT-class classifier	~20 ms on GPU	low if self-hosted	Strong if training data is fresh
LLM-as-judge (small model)	~100-200 ms	noticeable at scale	Strongest on ambiguous and rare intents

Real products, models, and research that use this idea.

Klarna's customer-support agent uses a fast embedding-similarity gate ahead of its main GPT-class model, falling back to a heavier judge for ambiguous intents.
Bank of America's Erica restricts intent to banking categories via a hierarchical classifier with explicit user-facing 'I can help with...' fallbacks on a miss.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you handle a user query that is borderline, say, 'is this Bitcoin payment legal?' for a bank that does not support crypto?

Talk about the middle band of the cascade, explicit out of scope copy that points to what the bot DOES handle, and logging the borderline case for product review of whether the scope should expand.

1 more follow-up an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Silently refusing off-topic queries. The user has no idea what happened, gets frustrated, and the team has no signal that the classifier is misfiring.

60 second bullets to scan on the way to the call.

Compare embedding-similarity, small classifier, and LLM-as-judge on latency, cost, accuracy
Explain why the off-topic gate sits on the input rail

Primary sources. Browse if you want the original framing.