Similarity to each intent
Routing log (last 8)
No messages routed yet.
No messages routed yet.
Before a customer-support chatbot can answer anything, it has to figure out what you're actually asking for. This first step is called intent classification: the system reads your message and assigns it to one of a fixed set of categories — "track my order", "I want a refund", "reset my password" — each of which triggers a different downstream workflow. Modern systems do this by embedding text into a high-dimensional vector space with a transformer model and comparing distances, but the underlying geometric idea is the same one this simulation shows in two dimensions: each intent occupies a region of space, and a new message is routed to whichever region it lands closest to.
This simulation defines six fixed support intents, each with a small hand-built keyword dictionary and a precomputed 2D centroid position. Typing a message tokenises it, scores keyword overlap against every intent, and places your message at the similarity-weighted average of the six centroids — a real, working nearest-centroid classifier, just compressed to a vocabulary small enough to see. Watch the point fly to its position, connect to the winning intent with a line, and check the live similarity bar chart and routing log. Flip on "ambiguous mode" to see what happens when a message doesn't clearly belong to just one category.
What is an intent classifier and why do support chatbots use one?
An intent classifier is a model that reads a piece of free-form text and assigns it to one of a fixed set of categories — "intents" — such as tracking an order or resetting a password. Support chatbots use one as the very first step in a conversation: before any answer can be generated, the system has to decide which of a few dozen possible workflows the customer actually wants. Routing to the wrong intent means the bot answers the wrong question entirely, so this classification step is treated as a hard gate before any reply is produced.
How does this simulation turn text into a 2D position?
Each intent has a small hand-built dictionary of keywords with weights, for example "track" and "package" score highly for the "Track order" intent. Your message is tokenised into words, and each token is compared against every intent's dictionary (including simple prefix matching so "charged" still matches "charge"). This produces a raw similarity score per intent, which is normalised into a probability-like distribution. The point's 2D position is then the weighted average of the six fixed intent centroids, weighted by those normalised scores — so a message that scores highly on one intent lands right on top of that cluster, while an ambiguous message lands somewhere in between.
How would a real system embed text instead of keyword matching?
Production systems rarely hand-code keyword lists. Classic approaches use TF-IDF vectors over a large vocabulary combined with a linear classifier or nearest-centroid rule, essentially a higher-dimensional version of what this simulation does. Modern systems use transformer sentence embeddings (models like BERT or sentence-transformers) that map an entire sentence to a dense vector of 384–1536 numbers, trained so that semantically similar sentences land close together even without shared words — so "my parcel hasn't arrived" and "where's my order" end up near each other despite sharing almost no vocabulary. This simulation compresses that idea down to 2 dimensions and a tiny keyword list so the geometry stays visible.
Confidence is the normalised similarity score of the winning intent — if "Track order" scores 0.72 and every other intent shares the remaining 0.28, the router is fairly confident. When the top score is low (roughly below 0.4 in this simulation) it usually means the message contains keywords from two or more intents, or none of the known intents at all. Real systems handle low confidence by falling back to a clarifying question ("Did you mean tracking an order, or a return?") or by routing straight to a human agent rather than guessing and giving a wrong answer.
Ambiguous mode builds example messages that deliberately mix keywords from two different intents, for example combining tracking and billing language in one sentence. Because the similarity score is split roughly evenly between the two matching intents, the normalised confidence of the "winner" drops sharply and the point is pulled to a position between the two clusters instead of sitting on top of either one. This mirrors real support tickets, where customers often describe a problem that spans two categories, such as "my refund was charged back to the wrong card".
Each message here is classified independently, with no memory of what was said before — exactly like a single-turn intent classifier. Real conversational systems maintain dialogue state across turns: if a user says "track my order" and then "actually cancel it", a stateless classifier might misroute the second message because "cancel it" alone is ambiguous. Production chatbots solve this by feeding recent conversation turns into the embedding step or by maintaining an explicit slot-filling dialogue state, which is considerably more complex than the single-message lookup shown here.
Nearest-centroid classification represents each class by a single summary point (the centroid, or mean, of that class's examples) and assigns a new point to whichever centroid is closest. k-Nearest Neighbours instead compares a new point against every individual training example and takes a majority vote among the k closest ones. Nearest-centroid is faster and simpler — exactly one distance comparison per class — but assumes each class forms a single compact, roughly convex blob; k-NN can handle classes with irregular or multi-modal shapes at the cost of storing and searching the entire training set.
Yes, and it's one of the hardest parts of designing an intent taxonomy. Words like "card" or "account" show up in billing, password-reset, and fraud-related intents alike. Real systems reduce this overlap by training on thousands of labelled real customer messages rather than hand-written keyword lists, letting the model learn which combinations of words — not individual words — are actually diagnostic. Teams also regularly review "confusion pairs" (intents the model frequently mixes up) and either merge them, add more contrastive training examples, or split them into finer sub-intents.