Types of Search Queries: A Practical Map

Ask three search engineers what type of query nike waterproof running shoes under EUR 100 is, and you may get three different answers.

One may call it a keyword query. Another may call it a category query with attributes and a price constraint. A third may care that it is standalone, English-language, and written by a person rather than generated by an application.

All three can be right. They are describing different properties of the same request.

The property worth naming depends on the problem being solved. A relevance engineer may distinguish exact lookup from exploratory search. A query-understanding system needs to detect ambiguity and structure. A conversational system needs prior turns. A production engineer needs to know what work the resulting request creates.

A search query does not have one type. It has a profile of characteristics. This makes the idea of query shape more precise: a query profile records the characteristics that matter for a particular engineering decision.

Nine dimensions of a query

The information retrieval literature classifies queries by intent, ambiguity, target, session context, modality, language, and other properties. The map below brings those views together for practical system design. It is not a standard nine-part taxonomy, and the dimensions are not processing stages.

Some distinctions are longstanding in information retrieval; others have become more operationally important as conversational, multimodal, and agent-generated search have expanded.

Some characteristics are visible in the query. Others depend on the user, session, corpus, application, or task. Intent is often an inference, not an observed fact. A useful query profile preserves that uncertainty.

Why these distinctions matter

Query classification is useful when it changes a diagnosis, evaluation, or implementation decision.

Ambiguity can look like a ranking failure

Suppose jaguar returns wildlife documents when the user wanted the car brand.

Boosting or reranking may not solve the problem. The system may have selected the wrong interpretation before ranking began. The same visible failure can require query clarification, entity interpretation, personalization, or ranking, depending on where it originated.

Context can change the evaluation task

show me cheaper ones makes little sense without the previous result set and the meaning of "cheaper" in that interaction.

Putting the string into a relevance set without its preceding turn does more than add noise. It creates a different task. The evaluator is now testing a standalone query that no user actually issued.

Aggregate metrics can hide exact-query regressions

A system can improve semantic matching for broad discovery queries while becoming worse at product codes, patent numbers, legal citations, or known-item requests.

If those classes are averaged together, an apparently healthy aggregate result can conceal a serious product failure. Query profiles make it possible to evaluate the traffic segments that carry different success conditions.

Generated queries need their task context

An agent-generated subquery may look like an ordinary text query. Its role can still be different: it may fill one evidence gap inside a longer research task. Treating every generated request as an independent human information need can distort evaluation and traffic analysis.

The dimensions below provide vocabulary for locating these differences.

1. Form

Form describes how the request is expressed.

An identifier query such as AB-1234, WO2026123456, or an ISBN may contain one token and still identify its target precisely. Product codes, patent numbers, error codes, ticket numbers, document IDs, and legal citations often need dedicated recognition rather than ordinary text matching.

A keyword query such as nike running shoes or vector compression papers states the need telegraphically. Grammar and relationships are mostly implicit.

Here, keyword describes the query's expression, not whether the system uses lexical, vector, or hybrid retrieval.

A structured or fielded query makes part of the retrieval instruction explicit:

author:smith
brand:nike price:<100
year:[2024 TO *]

Boolean, phrase, proximity, exclusion, and wildcard syntax can encode much richer requests. These remain important in patent, legal, scientific, intelligence, and regulatory search. The open Introduction to Information Retrieval covers these established query constructs.

A natural-language query states the need directly:

comfortable waterproof shoes for walking all day

Natural language can be standalone or dependent on earlier interaction. That dependence belongs to the context dimension, not the surface form alone.

2. Target and specificity

Queries with the same form can express very different levels of target certainty.

• SKU-71829 is an exact lookup: the identifier names the target.
• the Brin and Page paper that introduced PageRank is a known-item query: the requester seeks one particular document believed to exist. This usage follows the established known-item retrieval task.
• running shoes names a category with many acceptable results.
• red waterproof hiking shoes under EUR 150 is attribute-constrained.
• methods for reducing hallucination in retrieval-augmented generation is conceptual: the need is clear, but the best documents may use different vocabulary.
• good resources for learning information retrieval is exploratory: search helps the requester discover the answer space.

These classes do not share one success condition. Missing the intended known item can make the search a complete failure. Exploratory search can return several different sets of useful results. Segmenting them can reveal regressions hidden by an aggregate metric.

3. Internal structure

Query length is a poor proxy for query complexity. jaguar is syntactically simple and semantically difficult. running shoes under EUR 100 is short but combines a category with a numeric constraint.

Common structural patterns include:

• Atomic: jaguar
• Entity plus attribute: Nike Air Max red
• Constraint-bearing: running shoes under EUR 100
• Exclusion-bearing: running shoes without Gore-Tex
• Comparative: Pixel versus iPhone battery life
• Relational: papers citing ColBERT
• Temporal: changes since January 2025
• Spatial: hotels within 5 km of Schiphol
• Compositional: waterproof hiking shoes for wide feet under EUR 150
• Multi-part: What changed between the original contract and the amendment, and which termination clauses still apply?

The last example contains several retrieval needs: find the correct versions, locate the clauses, compare them, and determine what remains effective. A RAG system or agent may decompose it into multiple searches, but the structure exists before that implementation choice.

Constraints can also arrive outside the visible text. A user may type running shoes and select a price facet in the interface. The semantic requirement resembles running shoes under EUR 100, but the application constructs it differently. That difference helps locate whether a failure came from query understanding, UI state, filtering, or serving logic.

4. Specification and ambiguity

Length does not tell us whether a query is well specified.

SKU-72918 is short and precise. running shoes is underspecified because use case, fit, size, terrain, and price remain open. jaguar is ambiguous because several distinct interpretations are plausible. iphnoe case is noisy: its likely meaning is specific despite the spelling error. nice laptop is vague because "nice" provides little operational guidance.

Ambiguous queries are a distinct research problem. Song et al. study how to identify ambiguity and separate it from more specific queries in Identification of Ambiguous Queries in Web Search.

Long requests create a different challenge. They may contain hard constraints, use-case context, preferences, and explanatory language, all with different retrieval importance. More words can add information without removing uncertainty.

Ambiguity, underspecification, noise, vagueness, and verbosity call for different responses. Combining them into one "difficult query" class removes information an engineer can act on.

5. Context dependence

A standalone query such as waterproof hiking shoes carries most of its meaning in the expression itself.

A session-dependent query may rely on an earlier search:

electric cars
used under 30k

The TREC Session Track studied retrieval over sessions using earlier queries, results, clicks, and dwell time rather than treating every query in isolation.

Conversational dependence is more explicit:

what about the cheaper one?

The TREC Conversational Assistance Track defines effective response selection as requiring the question's dialogue history.

Other queries depend on user context (my recent invoices), environmental context (coffee near me, what is open now?), or task state (recall notices for the remaining SKUs). Location, time, identity, permissions, previous results, and workflow state can all be part of the effective query even when they are absent from the text.

6. Intent and goal

Intent describes what the requester is trying to accomplish. It is the best-known query taxonomy, but it is only one dimension.

Broder's web-search taxonomy distinguishes informational, navigational, and transactional needs. ORCAS-I further separates informational queries into factual and instrumental subclasses, with an abstain category for uncertain cases.

Intent classes can also be domain-specific. Research on e-commerce query taxonomies derives shopping-oriented classes from commercial search behavior. Enterprise, legal, support, and RAG systems may need different labels because they serve different decisions.

Intent is usually inferred. The query jaguar does not reveal whether the user wants information, a website, a product, an animal, a car, or something else. Context and behavior may change the estimate.

7. Modality

Queries are not limited to text.

An image may retrieve visually similar products. Speech may express the same need as typed text while introducing recognition errors and more conversational phrasing. Inputs can also combine modalities:

[shoe image] + "something like this, but in black"

Neither part contains the complete request alone.

Query modality and result modality are separate properties. red Ferrari used to retrieve images is a text query against an image corpus. A photograph used to retrieve similar images is an image query. A photograph plus a text constraint is multimodal.

In cross-modal image-text retrieval, the query and retrieval collection belong to different modalities. Naming both sides avoids using "image search" for several different system shapes.

8. Language relation

Language becomes a relational property when the query and corpus differ.

A system may serve one language, accept several languages against a multilingual corpus, receive code-switched queries such as beste noise cancelling headphones onder EUR 300, or handle transliteration and mixed scripts.

In cross-language information retrieval, the query and documents use different languages:

Dutch query -> English documents

Kishida's review of cross-language information retrieval defines the problem in those terms and surveys the translation and matching choices it creates.

Identifiers such as WO2026123456, BRCA1, and ERR_CONNECTION_RESET may require little or no linguistic translation. The system still needs to preserve them accurately across tokenization, normalization, and matching.

9. Origin and generation path

Origin records how a query or retrieval request was produced. It is provenance, not meaning.

A request may be:

• Human-authored, through typed or spoken input.
• UI-derived, when facets, map movement, sorting, or a saved view contribute structured parameters.
• Application-generated, for recommendations, related items, dashboards, monitoring, or enrichment jobs.
• Agent-generated, as one search inside a longer plan.

Consider a user asking:

Which of our products had safety recalls in Europe this year?

An agent may identify products, search regulatory sources, inspect the evidence, and issue follow-up searches for missing jurisdictions or product variants. One intermediate query might be:

EU safety recall notices for Model X in 2026

Nothing in that string makes it intrinsically agentic. Its distinguishing property is its origin and role inside a larger task. A person and an agent can issue identical text while creating different context, evaluation, and traffic assumptions.

Build a query profile, not a single label

A profile combines only the dimensions relevant to the engineering problem.

Not every value is observable ground truth. Form and modality are often visible. Intent, target, and ambiguity may be hypotheses. Store confidence or an unknown value where certainty matters instead of forcing every query into a complete profile.

Query profile is not query workload

A query is the expression or input supplied by a person, application, or agent. A retrieval request is broader. It may add filters, permissions, ranking configuration, candidate depth, sorting, grouping, timeout, and other serving parameters.

The same logical query can therefore execute as:

BM25

or:

BM25 + filtered ANN
-> fusion
-> reranking

Its semantic profile may be unchanged while its execution cost, candidate coverage, filtering behavior, and latency change substantially.

A query profile describes the query's meaning, expression, context, and provenance. A query workload describes the distribution of retrieval requests and the work they create under production traffic.

The distribution of query length, clause count, filters, candidate depth, QPS, concurrency, latency budgets, and requests per task helps define that workload. Corpus size alone does not.

Keeping the concepts separate prevents two different questions from collapsing into one:

• What must the system understand about this request?
• What must the system do to serve it under production conditions?

Both feed into the wider Retrieval Foundation, but they lead to different diagnostics and design decisions.

Use the dimensions that change a decision

The map is not a requirement to build nine classifiers.

Classify a dimension when it changes what the system should do or how it should be evaluated. Form can change parsing. Target specificity can change matching and success metrics. Structure can trigger filters or decomposition. Context can determine whether an evaluation example is valid. Intent can influence ranking and presentation. Modality and language determine available representations. Origin can affect provenance, traffic analysis, and task-level evaluation.

Use the query profile to describe what the request means and what context it needs. Use the workload profile to describe what serving those requests makes the system do.

That is enough precision to stop asking for one universal query type and start asking which characteristics matter for the decision at hand.