Home / Query understanding / Query Intent Classification in Search

Query Intent Classification in Search

Query intent classification detects what a searcher wants, so the system can send the query to the retrieval method that serves it best. The goal may be a specific item, a topic, a filtered list, a count or an answer. An exact product code belongs to keyword search with a boosted identifier field, and a description such as “shoes for muddy trails” belongs to vector or hybrid search. “Vintage dresses under $200” needs a search plus a price filter, while “how many orders last week” needs an aggregation, not a ranked list. Intent can be detected with simple rules, a trained classifier or a language model that reads the query and the data schema. The classic web taxonomy, from Broder in 2002, split queries into navigational, informational and transactional, but application search usually needs finer, task-specific intents. Weaviate’s Query Agent does this routing with an LLM, choosing collections, building filters and deciding between search and aggregation.

What is query intent classification?

Query intent classification is the step that labels a query with the goal behind it, before or during retrieval, so the search system can choose the right method, filters and presentation. It is a core part of query understanding.

The same search box receives very different requests. One user pastes an order number, another describes a problem in a sentence, a third asks how many items match a condition. Treating them all the same way serves some well and others badly. A vector search for an order number returns similar-looking numbers; a keyword search for a vague description misses documents written in other words.

Intent classification adds a decision point. The system first decides what kind of request it is facing, then routes it. The label can change the retrieval method, the balance between keyword and vector search, the filters applied, or whether to generate an answer at all. The wider set of query-side steps is covered in query understanding.

Intent labels are a means, not an end. They are only worth defining if each one leads to a different, better way of handling the query.

Which intents should a search system recognise?

A search system should recognise the intents that change how it retrieves, typically lookups, descriptive searches, filtered searches, aggregations and questions that need an answer. Web-scale taxonomies are a starting point, not a fit for every application.

Andrei Broder’s 2002 taxonomy of web search remains the best-known framing. Navigational queries aim at a particular site, informational queries seek information on a topic, and transactional queries aim to do something, such as buy or download. Later work refined these categories, but the core insight held: the same words can carry different goals.

Inside an application, intents follow the data and the tools. Weaviate’s article on the Query Agent illustrates the distinction with two questions about a blog collection. One asks about the components of AI agents in a named post, which needs a filtered search; the other asks how many posts an author has published, which is a counting task. Each needs a different query type.

How does intent change the retrieval route?

Intent changes the retrieval route by deciding whether to use keyword, vector or hybrid search, which filters to extract, whether to aggregate instead of rank, and whether to generate an answer. Each route has different strengths.

Lookups favour exact matching. A product code, ticket number or exact title should match literally, so keyword search with a boosted identifier field, or a filter, is the right tool. Descriptive queries favour meaning, so vector search or hybrid search with a high vector weight serves them. The trade-off is discussed in when to use hybrid search.

Some intents need structure. “Vintage dresses under $200” contains a price constraint that belongs in a filter, not in the vector. “How many orders last week” needs a count, which Weaviate answers with its aggregate API rather than a search. Weaviate’s article on large language models and search makes the same point, noting that a question such as the average age of country singers is better answered by a structured aggregation than by semantic search.

Questions may need generation. A query phrased as a question can retrieve passages and pass them to a language model for a written answer. Complex questions may first be split into parts, as described in query decomposition.

How do you classify query intent?

You classify query intent with rules for clear patterns, a trained classifier for common phrasing, and a language model for complex queries, often in that order so the cheapest method handles most traffic. Each has a different cost and accuracy profile.

Rules catch the obvious cases. A regular expression recognises order numbers, SKUs or ticket IDs; a leading “how many” or “average” signals an aggregation. Rules are instant and easy to audit, but they only cover what someone thought to write down.

A trained classifier generalises. A small model, or embeddings fed to a simple classifier, learns intents from labelled examples and handles new phrasings of familiar requests. It needs labelled example queries for each intent, often taken from search logs. A language model handles the long tail: given the query and a description of the data, it can return a route and the filters to apply. It is the most flexible option and the slowest and most expensive per query.

How does Weaviate’s Query Agent route queries?

Weaviate’s Query Agent routes queries with an LLM that reads the query and the structure of the available collections. It then decides which collections to use, which filters to build and whether to search, aggregate or both. It returns the actions it took alongside the results.

Weaviate’s documentation describes the Query Agent as transforming natural language queries into searches and aggregations across one or more collections, dynamically choosing collections, filters, group-bys, sorts and search types. It has two modes: Ask Mode returns a written answer, and Search Mode returns the matching objects. In the documented example, a request for vintage clothes under $200 became a search for “vintage clothes” on the Ecommerce collection with a price filter of less than 200.

The agent is available on Weaviate Cloud; its documentation notes that locally running instances do not support it. Weaviate’s recipe comparing the agent with a do-it-yourself pipeline lists what a custom router must handle. The list includes more filter operators, aggregations as a second pipeline, search-method selection among vector, hybrid and keyword, multi-collection routing, and schema sampling so the model sees example values. The same capabilities support query rewriting and query expansion, which the agent also performs.

How do you build a simple intent router?

You build a simple intent router by classifying each query with rules or a model, then mapping each intent to a specific Weaviate call. Keyword search handles lookups, aggregation handles counts and hybrid search handles everything else. Start small and add intents as logs show the need.

import re

ID = re.compile(r"\b[A-Z]{2,}-\d+\b|\b\d{5,}\b")
AGG = re.compile(r"^(how many|count|average|total)\b", re.I)

def classify(q):
    if ID.search(q):  return "lookup"
    if AGG.search(q): return "aggregate"
    return "semantic"

def route(items, q, q_vec):
    intent = classify(q)
    if intent == "lookup":
        return items.query.bm25(query=q, query_properties=["sku^3", "title"], limit=3)
    if intent == "aggregate":
        return items.aggregate.over_all(total_count=True)
    return items.query.hybrid(query=q, vector=q_vec, alpha=0.75, limit=10)

The router was run on Embedded Weaviate 1.30.5 with two toy products as an API check. “SH-2210” went to keyword search and returned the matching product, “how many products are there” went to an aggregation and returned a count, and “shoes for muddy trails” went to hybrid search. Real aggregations would also extract filters from the query, which is where a model or the Query Agent helps.

Typos and partial input complicate classification. Misspelled codes defeat exact rules, as discussed in typo tolerance and spelling correction, and incomplete queries arrive while users type, as covered in semantic autocomplete.

How do you measure intent classification?

You measure intent classification by labelling a sample of real queries, checking how often the router picks the right intent, and checking whether routed queries retrieve better results than a single default route. The second test is the one that matters.

Classification accuracy is easy to compute on a labelled sample, and a confusion matrix shows which intents get mixed up. But a router can be accurate and still unhelpful if its routes are no better than the default. Compare retrieval quality for each intent with and without routing, using the methods in how to evaluate semantic search.

Watch the cost of mistakes. Sending a lookup to vector search can bury the exact item; sending a description to keyword search can return nothing. A safe fallback, such as hybrid search when confidence is low, limits the damage. Techniques that generate several query variants, such as multi-query retrieval and HyDE, can also reduce reliance on a single intent label.

Query intent classification decides what a searcher wants so the system can answer the right way. Lookups go to keyword search, descriptions to vector or hybrid search, constraints to extracted filters, counts to aggregations and questions to generated answers. Classify with rules for obvious patterns, a trained classifier for common phrasing and a language model for complex requests. Weaviate’s Query Agent routes with an LLM, choosing collections, filters and search or aggregation. Measure routing by retrieval quality per intent, not just label accuracy, and fall back to hybrid search when unsure.