Integration·Task 3.6·Bloom: evaluate·Difficulty 4/5·9 min read·Updated 2026-07-14

Matching Retrieval Strategy to Query Pattern in a Scenario

Apply retrieval strategies matched to data shape and query pattern

SUBy Solomon UdohReviewed by Solomon UdohAI-assisted · human-reviewed
In short
Given a described corpus and query mix, the task is to identify whether dense, sparse, hybrid, or direct structured-query retrieval is the best match, and justify the choice against the workload's shape. A query pattern dominated by exact-identifier lookups favours sparse or structured retrieval over pure embedding similarity, and a pattern requiring current, frequently changing values favours a live tool call over any indexed retrieval method. The justification must tie to the described pattern, not default to vectors or to what is easiest to implement.

Choosing the strategy the scenario actually calls for

This is the evaluate-level capstone of the retrieval task statement. Given a described corpus and query mix, you select the best retrieval strategy, dense, sparse, hybrid, or direct structured query, and justify it against the workload's shape. It pulls together everything in the topic: method selection by data shape, the live-state versus static distinction, and hybrid retrieval. The skill is reading the scenario for the properties that determine the fit, and matching a strategy to them rather than reaching for a default.

The exam rewards a justification tied to the described pattern, so a right answer names both the strategy and the workload property that makes it right. A strategy chosen for the wrong reason, even if it happens to be defensible, is not what is credited.

Matching retrieval strategy to query pattern
An evaluate-level task of selecting dense, sparse, hybrid, or direct structured-query retrieval to fit a described corpus and query mix, justified by the workload's shape, exact-identifier patterns favouring sparse or structured retrieval and frequently-changing-value patterns favouring a live tool call, rather than defaulting to vectors or to the easiest implementation.

Read the query pattern, then pick

The scenario's query pattern is the primary signal. A pattern dominated by exact-identifier lookups, product codes, citation numbers, account IDs, favours sparse or structured retrieval, because embeddings blur exact identifiers and a similarity match is the wrong tool for 'find exactly this code.' A pattern of conceptual, differently-worded questions favours dense retrieval, which matches meaning across vocabulary. A pattern that genuinely mixes both favours hybrid, accepting its latency and complexity for the coverage it buys. And a pattern requiring current, frequently changing values, balances, live prices, favours a direct live tool call over any indexed method, because an index can only be as fresh as its last refresh.

So the decision procedure is: characterise the queries (exact-term, conceptual, mixed, or live-state), then select the strategy whose strength matches that characterisation. Each property maps to a strategy, and the justification is that mapping made explicit.

Justify by the workload, not by the default

The traps here are both about choosing for the wrong reason. The first is defaulting to vector or dense retrieval as the universal answer regardless of the query pattern, treating embeddings as the always-correct RAG technique even when the queries are exact-identifier lookups or live-state reads that dense retrieval serves badly. The second is choosing a strategy based on what is easiest to implement rather than what matches the data shape and query pattern, letting convenience override fit. Both produce answers that sound reasonable but are not tied to the scenario.

The credited justification names the specific property. Not 'dense retrieval, because it is powerful,' but 'sparse or structured retrieval, because the queries are dominated by exact citation numbers that embeddings would blur,' or 'a live tool call, because the queries need current balances that any index would serve stale.' The property in the scenario is the reason, and stating it is what distinguishes analysis from a default.

exact identifiers → sparse/structured
embeddings blur exact terms
frequently changing → live call
indexes serve only last-refresh freshness
justify by shape
not by defaulting to vectors or to what is easiest

What the exam trips candidates on

Two traps. The first is defaulting to vector or dense retrieval as the universal answer regardless of the described query pattern, which ignores exact-identifier and live-state patterns that dense serves poorly. The second is choosing a retrieval strategy based on what is easiest to implement rather than what matches the data shape and query pattern described. The credited answer selects the strategy that fits the described pattern and justifies it by the specific workload property.

Worked example

A legal-research assistant serves a corpus where most queries are exact statute and case-citation lookups (for example 'find 17 U.S.C. section 106'), but a minority are conceptual questions about legal doctrine in varied wording. A live docket-status feed is also queried for the current status of ongoing cases. A team proposes dense vector retrieval across everything for simplicity. Choose and justify the strategy.

The proposal defaults to dense-everything for simplicity, which commits both traps at once, and the scenario has three distinct query properties that each call for a different strategy. Take them in turn. The dominant pattern is exact statute and case-citation lookups like '17 U.S.C. section 106,' and those are exact-identifier queries. Dense retrieval blurs exact identifiers into a semantic neighbourhood, so it would surface citations that look similar rather than the exact one, which is why exact-identifier patterns favour sparse or structured retrieval. So the primary strategy for the citation lookups is sparse (or a structured citation index), justified specifically by the exact-identifier dominance.

The minority of conceptual doctrine questions, phrased in varied wording, are genuine semantic queries that sparse retrieval would miss, so dense retrieval is right for that slice. Because the corpus mixes exact-citation and conceptual needs, the sound design for the document corpus is hybrid, sparse plus dense with re-ranking, which serves both slices where dense-alone would fail the citations and sparse-alone would fail the doctrine questions. Finally, the live docket-status feed is frequently changing live-state data, so the current status of an ongoing case must come from a direct live tool call against the docket feed at request time, not from any index, which would serve a stale status. The justified answer, then, is not 'dense everything for simplicity', that is the ease-of-implementation trap and the vector-default trap together, but a hybrid retrieval strategy over the citation-and-doctrine corpus (sparse-leaning for the dominant exact lookups, dense for the conceptual minority, with re-ranking) plus a separate live tool call for docket status, each choice tied to the specific query property that makes it correct.

Common misreadings to avoid

Misconception

Dense vector retrieval is the universal default and the safe choice for any corpus and query mix.

What's actually true

Dense retrieval serves exact-identifier and live-state patterns poorly. Exact-identifier queries favour sparse or structured retrieval, and frequently-changing values favour a live tool call. Match the strategy to the described pattern.

Misconception

Pick the retrieval strategy that is easiest to implement and apply it across the whole system.

What's actually true

Ease of implementation is not the selection criterion; fit to the data shape and query pattern is. The justification must tie the chosen strategy to the specific property of the workload, not to convenience.

How this shows up on the exam

Expect a described corpus and query mix, often with a tempting 'just use vectors' or 'use the simplest option' distractor. The reliable reading is to characterise the queries, exact-term, conceptual, mixed, or live-state, and select the matching strategy with a justification tied to that property. This capstone integrates method selection by data shape, live-state vs static retrieval, and hybrid retrieval and re-ranking, and it is monitored through retrieval quality metrics.

Check your understanding

A legal assistant is dominated by exact citation lookups, has a minority of conceptual doctrine questions, and also queries a live docket-status feed. A team proposes dense vector retrieval across everything for simplicity. What is the justified design?

People also ask

How do you choose a retrieval strategy for a scenario?
Read the corpus shape and query mix, then pick dense, sparse, hybrid, or direct structured-query retrieval to match, justifying the choice against the described workload rather than defaulting to vectors.
Which retrieval fits exact-identifier queries?
Sparse or structured retrieval, because embeddings blur exact identifiers, so exact-term or direct-query matching outperforms pure similarity.
What retrieval fits frequently changing values?
A live tool call at request time, because any indexed method serves a value only as fresh as its last refresh.

Watch and learn

Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.

No videos curated for this concept yet

We are still curating the best official and community videos for this topic.

Official prep for this domain

Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.

References & primary sources

Adaptive study

Master this concept with Archie

Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.

Start studying