Skip to lesson

AnthropicClaude Certified Architect – Professional2026-103.6 Apply retrieval strategies matched to data shape and query pattern

Classify sources and questions before retrieval

Completed by the knowledge check

Learning objective

Characterize data shape (unstructured, semi-structured, relational, code) and query pattern (exact lookup, conceptual, aggregation, multi-hop).

Core idea

Before choosing an index, specify what information exists and what a correct answer must establish. Data shape describes the source’s structure; query pattern describes the operation the question requires. These are independent dimensions. A relational database can hold narrative notes, and a prose document can contain an exact identifier.

For an architect, the deliverable is a source-and-query inventory that exposes unsupported answer types before they become confident production responses. It records the authoritative source, usable fields, required relationships, and completeness requirement for each request class. Method selection belongs to 3.6.2; here you decide what that method must accomplish.

How it works

Characterize the source without flattening it

Unstructured data carries meaning principally in prose: policies, reports, manuals, and transcripts. A relevant passage can explain a concept, but its interpretation may depend on surrounding sections. Inventory the document’s title, scope, version, and effective dates as well as its text. Chunking and indexing decisions belong to subsection 3.5; identifying what those chunks must preserve comes first.

Semi-structured data combines stable fields with variable content. A support ticket can have an account identifier, opening date, product version, and narrative description. Ask which fields are reliable enough to filter or compute over. “Reported a billing problem” in free text is different from a validated issue_category field. Counting the latter does not automatically count every ticket whose prose describes the former.

Relational data represents records and their connections through tables and keys. Identify the unit represented by one row, the keys used to join sources, and the definitions behind measures. Anthropic’s text-to-SQL cookbook supplies the database schema to Claude before generating queries. That schema is essential context: a question about departments and employees cannot be translated reliably without knowing how the tables relate.

Code has text, exact symbols, module structure, and executable relationships. A filename or matching function name can locate a candidate without establishing which behavior runs. Distinguish a request for a definition from a request about its callers or dependencies. Anthropic’s context-engineering guidance describes loading code through lightweight references and targeted exploration rather than materializing every file into the prompt.

Do not force each source into one exclusive category. A code repository includes prose documentation; a relational ticket store includes narrative fields. Record the structure relevant to the requested answer, including which source owns updates. A flattened text copy can remain useful for discovery while the underlying records remain authoritative for computation.

Define the answer requirement

The four query patterns impose different obligations:

PatternWhat makes an answer correctDiagnostic question
Exact lookupThe requested key identifies the intended record or passageWould a one-character difference change the answer?
ConceptualThe evidence expresses the requested idea despite different wordingMust synonyms or paraphrases retrieve the same evidence?
AggregationThe computation covers the defined population with the intended measureDoes the answer require every qualifying record?
Multi-hopConnected facts establish the required relationship or dependencyDoes finding one fact reveal the next fact needed?

An exact lookup such as “What does fault code R-218 mean?” has a different correctness test from “Why does the device restart under load?” Anthropic’s Contextual Retrieval article explains why semantic embeddings can miss an exact error code even when they retrieve broadly relevant error documentation. Conceptual similarity is useful evidence for the second question, but insufficient proof of identity for the first.

Aggregation requires a population definition. Specify date bounds, counting unit, inclusion rules, and deduplication. Ten relevant passages establish that ten passages were retrieved, not that ten incidents occurred. A top-ranked subset cannot establish the total unless a separate completeness guarantee covers the entire qualifying population. The text-to-SQL cookbook illustrates database aggregations and joins rather than asking the model to infer totals from retrieved prose.

Multi-hop requires connected evidence. Anthropic’s knowledge-graph cookbook represents entities as nodes and typed relationships as edges, then uses serialize_subgraph(center, hops=2) to supply a relevant neighborhood. That function is a cookbook example, not an API parameter. Its significance here is the answer requirement: relationships must meet at the same resolved entity, and the path must retain its supporting facts.

Record combinations and unresolved assumptions

A question can combine all four patterns: identify an account, interpret a complaint category, count its qualifying cases, and follow subsidiaries to a parent organisation. Record the compound requirement rather than choosing the first recognizable phrase. “How many” identifies a computation but leaves its population unresolved.

Treat missing structure as a design assumption to test. If a business concept exists only in narrative text, decide whether the answer is illustrative or requires a governed classification process before aggregation. Do not silently convert uncertain semantic matches into authoritative rows. Record what an unanswered or ambiguous request should return, so the delivery team can distinguish missing evidence from a zero result.

Key distinctions and trade-offs

Shape versus pattern: The storage format does not determine the question. Tables support conceptual discovery through text columns; documents support exact lookup through identifiers.

Relevance versus completeness: A passage can be highly relevant while the result set omits most of the population. Completeness is central to counts and exhaustive relationship questions.

Observed relationship versus shared wording: Two passages mentioning the same company do not establish a supplier relationship. A relationship answer needs the particular connection and resolved entities, not co-occurrence alone.

Preserving source structure adds integration work, but flattening it can discard the very keys and measures that make answers defensible. The inventory makes that cost visible before the team optimizes retrieval latency.

Architecture / decision scenario

A healthcare equipment provider wants an internal maintenance assistant with a four-second response target. Its pilot searches manuals, ticket exports, a device registry, and source code through one vector index. On a held-out set, conceptual explanations pass at 94%, exact fault-code answers at 78%, and population counts at 61%. These are hypothetical pilot measurements.

The architect rejects a proposal to classify every question as “document search” and fix the weaker classes by increasing context. The architect inventories manuals as prose, tickets as semi-structured records, the registry as relational data, and diagnostic software as code. Exact fault-code interpretation requires identity; symptom explanations require conceptual evidence; monthly failure totals require complete qualifying records; tracing an installed component to a software dependency requires connected hops.

A ticket question combining “this device,” “power loss,” and “last quarter” receives both an identity requirement and a population definition. The service owner must decide whether the ticket category is reliable enough for a count; if not, the assistant reports illustrative cases rather than an authoritative total. The architect owns the routing requirements, while registry and ticket owners approve their keys and measures. Only then does the team compare retrieval methods against the four-second target.

Common exam traps

  • Treating every source that contains text as unstructured data.
  • Choosing retrieval from file format without analyzing the answer requirement.
  • Treating a similar identifier as the requested identity.
  • Reporting a count from a top-ranked subset without establishing completeness.
  • Assuming a join or entity relationship from shared wording.
  • Classifying a compound question by only one of its clauses.

What to remember

Classify both the source and the required answer. Preserve keys, fields, measures, and relationships that a flattened text index cannot replace. Decide whether the result needs identity, conceptual relevance, complete computation, or connected facts before selecting a retrieval path.

Knowledge check

References