Retrieval strategies for data shape and query pattern

What you’ll be able to do

• Classify a workload by data shape (unstructured, semi-structured, tabular, relational) and query pattern
• Select among semantic, lexical, hybrid, structured-query and metadata-filtered retrieval
• Apply re-ranking, query rewriting and decomposition where they improve recall or precision
• Recognize when retrieval should be a tool the agent calls rather than a fixed pre-step

What you need to know

Two questions before choosing a method

Retrieval strategy follows from two properties of the workload:

• Data shape. Is it unstructured prose (policies, manuals, emails), semi-structured (tickets with fields, product catalogs), tabular (transactions, metrics) or relational (entities connected by ownership, dependency or hierarchy)?
• Query pattern. Are users asking conceptual questions ("how do we handle a chargeback dispute?"), exact lookups ("error E-4471"), filtered questions ("EU contracts signed in 2025 with auto-renewal"), aggregates ("total refunds by region last quarter") or multi-hop questions ("which customers are affected by the supplier that failed audit?")?

Most retrieval failures in exam scenarios come from a method that doesn't match one of these, typically a vector index answering a question it can't answer.

Matching methods to patterns

• Semantic (dense vector) search. Good for paraphrased, conceptual questions over prose, where users' words differ from the documents' words. Weak on exact identifiers, numbers and rare proper nouns.
• Lexical (keyword, BM25-style) search. Good for exact terms: SKUs, error codes, statute numbers, names. Weak on synonyms and paraphrase.
• Hybrid search. Runs both and fuses the results. A strong default for mixed enterprise corpora where both conceptual and exact queries show up.
• Metadata filtering. Restricts the candidate set by structured fields (date, region, product, tenant, document type) before or during ranking. Essential when queries carry hard constraints, and for access control.
• Structured queries. For tabular data, give the model a tool that runs a parameterized or validated query (SQL, an analytics API) and returns computed results. Similarity search can't sum, count or compare across rows. It returns rows that look relevant.
• Graph or relational traversal. For questions that follow relationships, query the system of record or a graph, or let an agent chain lookups. A single similarity search rarely joins entities correctly.

Improving precision and recall

• Re-ranking. Retrieve a wider candidate set cheaply, then re-order with a stronger relevance model and keep only the top few. This fixes precision without flooding the context. Simply raising the number of chunks passed to the model usually adds noise.
• Query rewriting. Turn conversational, underspecified queries ("what about for contractors?") into standalone ones using the conversation, or expand them with synonyms and domain terms.
• Decomposition. Split multi-part questions into sub-queries, retrieve for each, then combine.
• Routing. Classify the query and send it to the right index or method: the policy corpus, the ticket system, or the analytics tool.

Each adds latency and cost (see 3.3), so add them in response to measured failures, not as a default stack.

Freshness and volatility change the answer too

Data shape includes how fast the data changes. A handbook revised quarterly suits a pre-built index. Order status, inventory or ticket state changes by the minute, and indexing a copy of it guarantees stale answers. For volatile data, query the live system of record through a tool at request time, and keep the index for slow-moving reference content.

Retrieval as a pre-step or as a tool

A fixed pipeline (retrieve once, then generate) is predictable, cheap and easy to evaluate, and it fits single-hop Q&A over one corpus. For exploratory or multi-hop work, expose retrieval as one or more tools the agent calls. The agent can then rephrase, filter, follow up on what it found, or query the structured system when the question turns out to be an aggregate. The cost is more model turns and less predictable latency. Pick the pattern the queries actually need, and keep the tool interfaces specific (search policies, query orders) rather than one vague "search everything" tool.

Decide with a labelled query set

Build a set of real queries labelled with the documents or records that should answer them, and grouped by pattern (exact, conceptual, filtered, aggregate, multi-hop). Measure recall and precision per group for each candidate strategy. A strategy that wins on average can still fail an entire query class. Per-pattern results show that, and they're what justify the extra complexity of hybrid search or routing to stakeholders.

Key concept

Pick retrieval by data shape and query pattern: semantic for paraphrase, lexical for exact terms, hybrid for mixed corpora, filters for hard constraints, structured queries for aggregates, and agentic lookups for multi-hop questions.

Questions describe a retrieval system failing on one query class, such as part numbers, totals or cross-entity questions. The right answer changes the retrieval method for that class. Distractors tune chunk size, raise the number of chunks retrieved, or upgrade the generation model.

Practice scenario

Build exercise — Match retrieval to query classes

Advanced · 50 min

What you’ll learn

• Grouping real queries by pattern and labelling their correct sources
• Comparing semantic, lexical and hybrid retrieval per query class
• Replacing similarity search with a structured tool for aggregate questions

1. Collect 30–60 real or realistic queries for one assistant, label the document or record that should answer each, and tag each query as exact, conceptual, filtered, aggregate or multi-hop.

   • Why: Averages across mixed query types hide whole classes that fail.
   • You should see: At least three distinct patterns, often with exact and aggregate queries more common than expected.

2. Measure top-k recall per class for semantic-only, lexical-only and hybrid retrieval.

   • Why: Per-class results show which method each query type needs and justify the added complexity.
   • You should see: Lexical or hybrid clearly ahead on exact identifiers, and semantic competitive on conceptual queries.

3. For the aggregate queries, replace retrieval with a structured query tool the model can call, and compare answer correctness before and after.

   • Why: Similarity search can’t compute totals across records. A query over the source data can.
   • You should see: Aggregate answers that match the database instead of estimates from a few retrieved rows.

Exam traps

Embedding structured tables and answering aggregate questions with vector similarity

Similarity search returns rows that look relevant. It can’t count, sum or compare. Use a structured query tool.

Using pure semantic search for identifiers, codes and exact names

Embeddings blur near-identical strings. Add lexical or hybrid retrieval, or a direct lookup.

Retrieving more chunks to fix a precision problem

More chunks usually add noise and cost. Use re-ranking or better filtering to raise precision.

Forcing a single retrieval step on multi-hop questions that need several lookups

Relationship questions need chained lookups. Expose retrieval as tools the agent can call iteratively, or query the relational source.

Choosing a retrieval strategy without a labelled query set to compare options

Without per-pattern measurements, you can’t tell which method each query class needs or defend the choice.

Sources

• Claude Developer Platform Docs
• Anthropic
• Anthropic, Claude Certified Architect – Professional Exam Guide v1.0 (July 2026)