Retrieval Method Selection by Data Shape

Three methods, three data shapes

Retrieval is not one technique but several, and the exam's foundational point for this task statement is that the right method depends on the shape of the underlying data. Dense vector retrieval, sparse keyword retrieval, and direct structured queries each excel at a different kind of matching, and choosing among them is a design decision, not a default. The common error is reaching for vector retrieval reflexively because it is the fashionable RAG technique, when the data's shape actually calls for keyword matching or a direct query. Matching method to data shape is the skill.

Each method's strength is tied to what kind of question it answers well. Getting the fit right is upstream of everything else in retrieval strategy, so it is where the topic starts.

Dense for meaning, sparse for exact terms

Dense vector retrieval represents both the query and the content as embeddings and matches by semantic closeness. Its strength is conceptual matching: when the query and the answer express the same idea in different words, dense retrieval finds the connection because the embeddings are near each other even without shared vocabulary. For questions phrased differently from the source text, this is exactly right.

Sparse or keyword retrieval matches on the actual terms. Its strength is exact-term matching: product codes, legal citations, proper nouns, part numbers, anything where the specific string must match rather than a paraphrase. Here dense retrieval can actually underperform, because embeddings blur exact identifiers into a semantic neighbourhood, and a query for part 'XR-4471' does not want the semantically nearest part, it wants that exact part. When the corpus is dominated by exact identifiers, keyword retrieval outperforms vectors.

Structured data wants a direct query

The third case is structured data, tables, databases, records with fields. Embedding a structured database into a vector index is usually the wrong move: it discards the structure that makes the data queryable and turns precise lookups into fuzzy similarity searches. Structured data is often far better served by a direct query, a SQL statement, an API call, that uses the structure to fetch exactly the right rows. Asking a database 'return orders where status = shipped and date > X' is precise and correct; embedding those rows and hoping similarity surfaces them is neither.

So the design instinct for structured data is to expose it through a direct-query tool rather than folding it into the vector index. The structure is an asset; a direct query uses it, and embedding throws it away. This connects to live-state retrieval, where a direct tool call is also the right answer for current, changing values.

What the exam trips candidates on

Two traps. The first is using vector retrieval alone for a corpus dominated by exact identifiers, where keyword matching would outperform it, because embeddings blur the exact terms the queries need. The second is embedding a structured database into a vector index instead of exposing it through a direct query tool, discarding the structure that makes precise lookups possible. The credited answer matches the method to the data shape.

Common misreadings to avoid

How this shows up on the exam

Expect a corpus with a specific shape, exact identifiers, structured records, conceptual text, and a retrieval method to evaluate. The reliable reading is to fit the method to the data: dense for meaning, sparse for exact terms, direct query for structured data. This foundational knowledge point unlocks live-state vs static retrieval and hybrid retrieval and re-ranking, relates to the RAG pipeline stages, and feeds the scenario-matching capstone.