Intent Detection

A system maps an utterance and, when needed, conversation context to one or more intent categories such as checking a delivery or changing an address. Classifiers, embedding matching, rules or prompted models can implement this mapping. Slot or entity extraction supplies arguments such as an order number, but does not replace the intent decision. Closely related intents require clear boundaries based on different downstream handling. Out-of-scope detection identifies messages that do not belong to the supported inventory. Multi-intent requests and changes of goal within a conversation need an explicit policy. The taxonomy is an application design choice, rather than a universal list of human intentions.

Start from supported workflows and write label definitions that specify different next actions. Collect realistic wording, short replies and confusing near-neighbor requests. Split by conversation and paraphrase family, and reserve unsupported requests for evaluation. Compare routing accuracy by intent, confusion between consequential actions and false acceptance of out-of-scope input. Tune clarification or abstention thresholds on development data. Evaluate extracted arguments and routing separately, then test their combination. The deliverable is an intent model and routing policy with documented ambiguity handling, including when the system asks a question before proceeding.

A forced-choice classifier can assign a confident supported label to an unfamiliar request. Keywords alone miss negation, indirect questions and changing context. Overlapping categories create annotation disagreement and unstable routing. High accuracy on templated utterances may not transfer to natural conversations. Intent labels do not establish identity, permission or complete arguments. Evaluate rejection and clarification alongside classification, and keep the semantic interpretation separate from the controls that permit consequential actions.