Choose an appropriate method for retrieval and indexing

Retrieval is where most grounded solutions actually fail, and it fails quietly. The model produces a fluent answer from the wrong material, and nothing in the response signals that search returned the wrong documents. This lesson covers the decisions that determine whether the right content reaches the model at all: how content gets in, how it is enriched, how it is queried, and who plans the query.

Why This Matters

Three properties make retrieval design consequential.

Retrieval failures are invisible downstream. If search returns the wrong three documents, a good model summarizes them faithfully. Groundedness scores well. The answer is wrong. Only a measurement aimed at the retrieval step — not the response — reveals it.

Ingestion decisions are expensive to reverse. Enrichment runs at indexing time: skillsets "chunk text, generate vectors, and apply other transformations" as content flows through. Adding chunking or vectorization later is not a configuration change; the documents already in the index were written without it, so the corpus must be reprocessed.

The access-control model is chosen here. Whether a user sees only what they are entitled to is decided by the knowledge source, not by anything downstream. Once a restricted document is in the context window, every later control is a mitigation rather than a boundary.

The exam tests this as a set of paired decisions — push or pull, vectors or not, classic or agentic, indexed or remote — each turning on one stated property.

Prerequisites

• What an index, a query, and a ranked result set are.
• That an embedding is a dense vector and vector search finds near neighbours in that space.
• The distinction between lexical matching (tokens) and semantic matching (meaning).
• That Azure AI Search is the retrieval engine underpinning Foundry IQ knowledge bases.

Learning Objectives

By the end of this lesson you will be able to:

1. Choose push or pull ingestion from the two documented conditions.
2. Decide whether a workload needs vectors at all, and configure integrated vectorization when it does.
3. Select among full-text, vector, hybrid, and multimodal queries, and add the semantic ranker appropriately.
4. Distinguish classic search from agentic retrieval, including their differing region support.
5. Choose indexed or remote knowledge sources, and identify which supports user-permission inheritance.

Building Blocks

The two workloads. Indexing "loads content into an index and makes it searchable. Internally, inbound text is tokenized and stored in inverted indexes, while inbound vectors are stored in vector indexes." Querying targets that populated index. The diagram separates them for clarity, but "in Azure AI Search, they're the same component operating in read-write and read-only modes."

The one format rule. "Azure AI Search can only index JSON documents." Push uploads JSON directly; pull "retrieve[s] and serialize[s] data into JSON."

Push and pull. Pull uses an indexer over a supported data source — Azure Blob Storage, Azure Cosmos DB, Microsoft SharePoint, Microsoft OneLake, and others. Push uploads from your own code. The rule: "If you don't have a supported data source, or if your content and index must be synchronized in real time, the push method is your only option."

Skillsets and enrichment. AI enrichment applies "custom or built-in skills for text, images, and layout", chunking, vectorizing, and transforming content during indexing. A custom skill calls your own endpoint from inside the skillset. Index projections control where enriched output is written.

Query types. Full-text, vector, hybrid, and multimodal — the last querying "content containing both text and images in a single multimodal pipeline". Integrated vectorization generates the embeddings so the application does not.

Relevance tuning. The semantic ranker, synonym maps, scoring configuration, filters, faceted navigation, and autocomplete — all aimed at "improv[ing] intent matching and result quality".

Classic search and agentic retrieval. Two engines on one service, differing in who plans the query.

Deep Dive

Getting content in

The push/pull decision has a default and two exceptions, and both exceptions push you the same way.

Use pull when the content lives in a supported data source and some staleness is acceptable. The indexer handles retrieval, change detection, serialization to JSON, and scheduling — work you would otherwise write and operate.

Use push when either exception applies: the source is not supported, or the index must track the source in real time. A line-of-business system with no indexer and a no-staleness requirement triggers both at once.

The operational consequence of pull is a monitoring obligation. An indexer run reporting Success with 0 documents has done exactly what it was told: change detection surfaced nothing. That is a statement about what the indexer saw, not about the index being correct — and it reaches users as omitted content, which nobody reports as an error. Ingestion health therefore needs the document count and item-level errors beside the status, not the status alone.

Do you need vectors?

The guidance here is deliberately sceptical, and it is worth quoting because the default assumption runs the other way: "Do you need vectors? LLMs and agents don't require vectors. Only use them if you need similarity search or if you have content that can be homogenized into vectors."

Vectors cost an embedding stage at ingest, storage for the vector index, and embedding of every query. They buy paraphrase matching. If your queries are identifiers, part numbers, codes, and exact phrases, that purchase returns very little — and vector search is actively weak there, because an identifier is a token to match rather than a meaning to approximate.

When you do adopt them, integrated vectorization means the service generates embeddings in-pipeline rather than the application embedding content before ingest and queries before search.

Choosing the query type

Full-text for lexical precision — identifiers, codes, exact phrases. Vector for similarity and paraphrase. Hybrid to "combine full-text search with vector search to balance precision and recall", which is the answer whenever a scenario names both query styles. Multimodal when text and images must be queried together.

Then separate retrieval from ranking. Hybrid decides what is retrieved; the semantic ranker decides what comes first. Relevance complaints frequently need the second even when the right document was already in the candidate set — so a stem complaining about ordering rather than absence is pointing at ranking.

Classic or agentic

Classic search is "an index-first retrieval model for predictable, low-latency queries. Each query targets a single, predefined search index and returns ranked documents in one request–response cycle. No LLM-assisted planning, iteration, or synthesis occurs during retrieval." Your application composes and merges.

Agentic retrieval targets a knowledge base representing a domain: "one or more knowledge sources, an optional LLM for query planning and answer synthesis, and parameters that govern retrieval behavior." Each query "undergoes planning, decomposition into focused subqueries, parallel retrieval from knowledge sources, semantic reranking, and results merging", returning an answer or raw data plus an activity log and references.

Two practical differences decide real designs. First, who writes the planning code — the service, or you. Second, regional support: the comparison table marks region restrictions No for classic and Yes for agentic, and the getting-started checklist tells you to choose a supported region when using agentic retrieval.

Indexed or remote, and the access-control question

Knowledge sources come in two kinds: "indexed sources use the same indexing and query engines as classic search, while remote sources bypass indexing and are queried live." Remote costs a live query and is never stale; indexed is fast and as current as the last run.

That choice is also the access-control decision. The design checklist asks "Do you need user-based permission inheritance?" and answers: "Remote SharePoint is designed for this scenario, but you can also inherit user permissions attached to content in Azure Blob Storage or ADLS Gen2. For all other scenarios, you can use the security filter workaround."

This matters because trimming has to happen at retrieval. Once a restricted document is in the context window, the model has it, and filtering the generated answer is a mitigation applied after the boundary was crossed.

Worked Examples

Example 1 — an engineering catalogue. Users search exact part identifiers such as BRG-6204 and also ask descriptive questions about tolerances.

Two query styles in one requirement names hybrid search. Vector alone fails on the identifier — it returns conceptually similar bearings rather than the one asked for — and a synonym map cannot match a paraphrase that shares no terms with the document. If users then complain that the right document appears fourth rather than first, that is a ranking problem: add the semantic ranker.

Example 2 — two sources, two ingestion methods. Standards live in Blob Storage and may lag by an hour; live pricing lives in a system with no indexer and must never be stale.

Blob Storage is supported and an hour of lag is acceptable, so pull. The pricing system triggers both push exceptions — unsupported source, real-time synchronization — so push is the only option. One index, two ingestion paths, chosen per source rather than per system.

Example 3 — a scanned corpus with an enrichment bug. OCR then entity recognition; entities come back empty for scanned pages but work for digital PDFs.

The asymmetry localizes it. A digital PDF carries a text layer, so the entity skill finds content in the document's own text field. A scanned page has no text until OCR produces it, and OCR writes to its own output. If the entity skill still reads the original field it receives nothing — and returns nothing, with a Success status. Skills form a chain, and the chain is expressed by wiring each skill's input to the previous skill's output.

Visual Explanations

The ingestion and query pipeline:

Classic against agentic, and where knowledge sources sit:

Common Mistakes

Adopting vectors by default. They are for similarity search. On identifier-heavy corpora they cost more than they return and match worse.

Answering a ranking complaint with re-indexing. Freshness and relevance are different problems with different fixes.

Reading indexer Success as "content arrived". Success with zero documents means change detection found nothing — check the count and item errors.

Adding enrichment after the first full ingest. Skillsets run at indexing time, so the change requires reprocessing.

Trimming permissions after retrieval. Once the document is in context, the boundary has already been crossed.

Using classic search then writing the merge logic yourself when the requirement explicitly says the retrieval layer should plan — that is what agentic retrieval is.

Forgetting agentic retrieval's regional restrictions. Classic search has none; agentic does, and the design must choose a supported region.

Practice Exercises

1. Content is in Cosmos DB (supported) and may lag 30 minutes; a second source has no indexer and must never be stale. Which ingestion method for each, and which rule decides?
2. Users search exact SKUs and ask paraphrased questions. Which query type, and why does vector-only fail?
3. An indexer reports Success with 0 documents while new files are missing from answers. What is the most consistent explanation?
4. A requirement says the retrieval layer, not the application, should plan across four collections. Which engine, and what does the response carry beyond the answer?
5. Which knowledge-source kind supports per-user permission inheritance, and what is the fallback elsewhere?

Summary & Concept Map

Retrieval design is four paired decisions. Push or pull: pull for supported sources, push when the source is unsupported or the index must be real-time. Vectors or not: only for similarity search, because they cost a stage and match poorly on identifiers. Which query: full-text for tokens, vector for meaning, hybrid for both, with the semantic ranker deciding order rather than membership. Classic or agentic: who plans the query, at the cost of regional restrictions. Underneath all four sits the access-control choice, made when you pick indexed or remote sources — and enrichment, which runs at indexing time and is therefore expensive to add late.

Sources and freshness

Written against current Microsoft Learn documentation for the AI-103 skills measured (16 April 2026), reviewed 2026-08-20. Microsoft Learn controls every changing product contract — availability, preview status, quotas, limits, regional support, naming, and retirement dates all move independently of this lesson. Where a scenario turns on a specific number or a GA/preview boundary, confirm it against the product's own page before relying on it.