Overview
This skill area covers two linked jobs. Knowledge mining with Azure AI Search: creating an index, connecting data sources through indexers, enriching content with skillsets that include built-in and custom skills, saving enrichments to a knowledge store, querying with filters, sorting and wildcards, and adding semantic ranking and vector search. Information extraction: pulling fields, tables and text from documents with Azure Document Intelligence (prebuilt, custom and composed models) and from documents, images, video and audio with Azure Content Understanding.
The two halves meet in real solutions. Document Intelligence or Content Understanding can run inside an indexing pipeline, and the resulting index is the retrieval layer for RAG in Domain 2 and the knowledge tool for agents in Domain 3. The exam tests whether you can wire each piece in the correct order and pick the model or query option that fits the data.
How it's tested
Questions mix pipeline design with exact configuration. Expect ordering steps for data source, index, skillset and indexer; JSON or REST fragments for index fields, skills and queries; and scenario choices between prebuilt, custom and composed Document Intelligence models or Content Understanding analyzers.
-
Pipeline assembly
You order or complete the objects of an enrichment pipeline: data source, index, skillset, indexer, field mappings and output field mappings.
-
Query construction
A search requirement is described and you build the query: search text, queryType, $filter, $orderby, $select, facets, wildcards, semantic or vector options.
-
Extraction model choice
A document set is described and you choose a prebuilt model, a template or neural custom model, a composed model, or a Content Understanding analyzer.
Users must filter hotel search results by city and sort by rating, but the query fails on the city filter. Searchable alone does not allow $filter; the field needs the filterable attribute, and rating needs sortable. Field attributes are fixed when the field is created, so you add the attributes by rebuilding the index and re-running the indexer. Check field attributes before suspecting query syntax.
Skill groups 3
Official skill groups from the Microsoft outline, in outline order.
6.1 Implement an Azure AI Search solutionIndexes, data sources, indexers, skillsets, custom skills, queries, knowledge store projections, and semantic and vector search.
- What it means
- Azure AI Search ingests content through an indexer that reads a data source (such as Blob Storage, Azure SQL Database or Azure Cosmos DB), optionally enriches it with a skillset of AI skills, and writes documents into an index whose fields carry attributes such as key, searchable, filterable, sortable, facetable and retrievable. Queries use simple or full Lucene syntax with OData filters, and semantic ranking and vector fields add meaning-based relevance.
- What to understand
- Field mappings move source fields into index fields; output field mappings move enriched values from the enrichment tree (for example /document/content/keyphrases) into index fields. A custom skill is a Web API skill, often an Azure Function, that receives a values array of records with recordId and data and must return the same recordIds. A knowledge store saves enrichments to Azure Storage as table, object (JSON blob) or file (image) projections, usually shaped with the Shaper skill. Hybrid search runs keyword and vector queries together and merges them with Reciprocal Rank Fusion (RRF); the semantic ranker then re-ranks the top results and can return captions and answers.
- How it shows up
- Expect an index definition with a missing attribute, a custom skill response that breaks the indexer, a query to complete, or a choice between keyword, vector, hybrid and semantic options.
- Common confusion
- Field mappings and output field mappings get swapped. Field mappings run before enrichment on source data; output field mappings run after skills and read from enrichment paths.
6.2 Implement an Azure Document Intelligence in Foundry Tools solutionProvision, prebuilt models, custom template and neural models, training and publishing, and composed models.
- What it means
- Document Intelligence extracts text, layout, tables, selection marks and labeled fields from documents. Prebuilt models handle common types such as invoices, receipts, ID documents, tax forms and contracts; the read and layout models return text and structure. Custom models learn your own fields from labeled samples, and a composed model groups several custom models under one model ID.
- What to understand
- Analysis is asynchronous: the analyze call returns an Operation-Location URL that you poll (the SDK wraps this in a poller) until the result is ready. Custom template models suit fixed layouts; custom neural models handle varied layouts and generally need more labeled samples for good accuracy. You label in Document Intelligence Studio, train, test against new documents, and the model ID becomes the deployed name you call. Each field returns a value and a confidence score that downstream code should check.
- How it shows up
- Expect a choice between prebuilt, template, neural or composed models for a described document set, the polling pattern in code, or the order of label, train, test and use.
- Common confusion
- Choosing a custom model for invoices or receipts when a prebuilt model already returns those fields, or choosing template for forms whose layout varies by supplier.
6.3 Extract information with Azure Content Understanding in Foundry ToolsOCR pipelines, summarization and classification, entity and table extraction, and multimodal ingestion.
- What it means
- Content Understanding uses analyzers that combine OCR, speech and vision extraction with generative models to return structured output from documents, images, video and audio. You define a field schema (for example summary, category or specific entities) or use prebuilt analyzers, and the service returns markdown content plus the requested fields, with confidence and source grounding where supported.
- What to understand
- It fits when one pipeline must handle several media types, or when fields must be generated or classified (summaries, categories, attributes) rather than only read from the page. Document Intelligence remains the precise choice for well-defined document fields and established prebuilt document types. Content Understanding output can feed an Azure AI Search index or a RAG solution.
- How it shows up
- A scenario mixes scanned contracts, call recordings and product videos and asks for one service to extract structured fields from all of them, or asks how to classify and summarize incoming documents.
- Common confusion
- Treating Content Understanding as just OCR. OCR is one stage; the service's value is schema-driven extraction, classification and summarization across media types.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Index field attributes
Each index field has attributes: key (unique document ID), searchable (full-text), filterable, sortable, facetable and retrievable.
- Remember
- Filters need filterable, $orderby needs sortable, and facets need facetable; adding these to an existing field requires rebuilding the index.
- Tested as
- Queries that fail on filter or sort usually trace back to a missing attribute.
- Trap
- Assuming searchable makes a field usable in $filter.
-
Indexer pipeline order
An indexer cracks documents from the data source, applies field mappings, runs the skillset, applies output field mappings and writes to the index.
- Remember
- Create the data source, index and skillset before the indexer that references them; indexers can run on demand or on a schedule.
- Tested as
- Ordering questions test this sequence.
- Trap
- Creating the indexer first.
-
Custom skill contract
A custom Web API skill receives JSON with a values array where each record has recordId and data, and must return values with the same recordId plus data, errors and warnings.
- Remember
- Returning a record without its matching recordId, or exceeding the timeout, makes enrichment fail for those documents.
- Tested as
- Code questions show a function response missing recordId or the values wrapper.
- Trap
- Returning a plain object instead of the values array.
-
Enrichment tree paths
Skills read and write nodes in an enrichment tree addressed by paths such as /document/content or /document/normalized_images/*.
- Remember
- Skill context sets where outputs are written; output field mappings copy those nodes into index fields.
- Tested as
- Questions show a skill input or mapping path and ask what is wrong.
- Trap
- Mapping enriched outputs with fieldMappings instead of outputFieldMappings.
-
Knowledge store projections
A knowledge store persists enrichments to Azure Storage as table projections, object projections (JSON in blobs) and file projections (images in blobs).
- Remember
- Projections in the same group keep relationships between them; use the Shaper skill to build the shape you project.
- Tested as
- Requirements for Power BI analysis point to tables; for full JSON documents point to objects; for extracted images point to files.
- Trap
- Expecting the search index itself to serve as a reporting store.
-
Simple vs. full Lucene syntax
Simple syntax supports basic operators and prefix search; queryType=full enables fuzzy (~), proximity, regular expressions, field-scoped search and wildcards in more positions.
- Remember
- Prefix searches such as lux* work in simple syntax; infix or suffix wildcards and fuzzy search need full syntax.
- Tested as
- Query completion items test which syntax a feature needs.
- Trap
- Using a fuzzy operator without setting queryType=full.
-
OData $filter and $orderby
$filter narrows results with expressions such as eq, gt, and search.in; $orderby sorts by sortable fields; $select limits returned fields.
- Remember
- Filters are exact and do not affect relevance scores; full-text matching belongs in the search parameter.
- Tested as
- Scenarios mixing a keyword and a category test what goes in search and what goes in $filter.
- Trap
- Putting a category value in search instead of $filter.
-
Vector fields
Vector fields are Collection(Edm.Single) with a dimensions value and a vector search profile that names an algorithm such as HNSW or exhaustive KNN.
- Remember
- Dimensions must match the embedding model; integrated vectorization can chunk and embed during indexing and vectorize queries automatically.
- Tested as
- Vector setup questions test the field type, dimensions and profile.
- Trap
- Mismatched dimensions between the index and the embedding model.
-
Hybrid search and semantic ranker
Hybrid search runs keyword and vector queries in one request and merges results with Reciprocal Rank Fusion; the semantic ranker re-ranks top results using language understanding.
- Remember
- Semantic ranking needs a semantic configuration naming title, content and keyword fields, and it can return captions and answers.
- Tested as
- Requirements for the most relevant RAG retrieval usually point to hybrid plus semantic ranking.
- Trap
- Expecting semantic ranker to find documents that keyword and vector retrieval never returned.
-
Document Intelligence async pattern
Analysis starts with a POST that returns 202 Accepted and an Operation-Location header, and you poll that URL until the status is succeeded.
- Remember
- In the SDK, begin_analyze_document (or the equivalent) returns a poller whose result holds pages, tables and fields.
- Tested as
- Code questions ask which header or method retrieves results.
- Trap
- Expecting the extracted fields in the response to the initial POST.
-
Template vs. neural custom models
Template models learn fixed layouts where fields sit in consistent positions; neural models learn semantic cues and handle varied layouts.
- Remember
- Choose neural when the same field appears in different places across suppliers; template is fast to train for one consistent form.
- Tested as
- Scenarios describing many layouts point to neural.
- Trap
- Training a template model on forms from dozens of different suppliers.
-
Composed models
A composed model combines several custom models under one model ID so a single call can process several document types.
- Remember
- In the current API version, a custom classifier routes each document to the right component model.
- Tested as
- A single endpoint for mixed custom document types points here.
- Trap
- Retraining one large model on every document type instead of composing.
-
Prebuilt document models
Prebuilt models extract known fields from common documents: invoice, receipt, ID document, tax forms, health insurance card, contract and others, plus read and layout for text and structure.
- Remember
- Use layout for tables, selection marks and paragraphs without labeled fields; use a prebuilt type when its named fields match the need.
- Tested as
- Most extraction questions start by checking whether a prebuilt model fits.
- Trap
- Labeling and training a custom invoice model unnecessarily.
-
Content Understanding analyzers
Analyzers define what Content Understanding extracts from a file type, including a field schema whose values can be extracted, classified or generated.
- Remember
- One service handles documents, images, audio and video with consistent structured output.
- Tested as
- Multimodal ingestion or summarize-and-classify requirements point here.
- Trap
- Building separate Speech, Vision and Document Intelligence pipelines when one analyzer per media type would do.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Field mappings vs. output field mappings vs. knowledge store projections
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Field mappings | Map source fields to index fields before enrichment | Work on raw source data | Using them for skill outputs |
| Output field mappings | Map enrichment tree nodes to index fields after skills run | Work on enriched data paths | Forgetting them, so enrichments never reach the index |
| Knowledge store projections | Save enrichments to Azure Storage tables or blobs | Persist data outside the index for analysis | Expecting them to populate the index |
Keyword vs. vector vs. hybrid vs. semantic ranking
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Keyword (full-text) | BM25 relevance on matching terms | Exact terms, codes and names | Expecting synonyms or paraphrases to match |
| Vector | Nearest neighbors in embedding space | Matches meaning across different wording | Missing exact identifiers such as part numbers |
| Hybrid | Keyword and vector results merged with RRF | Combines both strengths in one query | Thinking it needs two separate requests |
| Semantic ranker | Re-ranks top results with a language model | Improves order and adds captions; does not retrieve new documents | Treating it as a retrieval method |
Prebuilt vs. custom template vs. custom neural vs. composed vs. Content Understanding
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Prebuilt model | Ready-made fields for common document types | No training | Training custom models for invoices |
| Custom template | Learns fields at fixed positions | Consistent layouts only | Using it for varied supplier forms |
| Custom neural | Learns fields from semantic context | Handles varied layouts | Assuming it needs no labeled samples |
| Composed model | Several custom models behind one model ID | One call for many document types | Confusing it with a bigger single model |
| Content Understanding | Schema-driven extraction across documents, images, audio and video | Can generate or classify field values | Treating it as plain OCR |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Searchable is enough
- What candidates pick
- Mark the category field searchable so users can filter by it.
- Why it looks right
- Searchable sounds like it enables any query use.
- Why it's wrong
- Searchable enables full-text matching only; $filter needs filterable, and facets need facetable.
Clue to watch for Requirements to filter, facet or sort on a field.
-
Wrong mapping type
- What candidates pick
- Add a field mapping from /document/content/keyphrases to the keyphrases field.
- Why it looks right
- Field mappings are the familiar way to connect fields.
- Why it's wrong
- Enrichment paths exist only after skills run, so they must be mapped with outputFieldMappings.
Clue to watch for A mapping source that starts with /document/ and refers to a skill output.
-
Broken custom skill response
- What candidates pick
- Return the computed value directly as the function's JSON body.
- Why it looks right
- It is the simplest Azure Function response.
- Why it's wrong
- The indexer expects a values array with each record's recordId, data, errors and warnings; anything else fails the skill.
Clue to watch for Indexer errors mentioning missing records or invalid skill output.
-
Semantic ranker as retrieval
- What candidates pick
- Enable semantic ranking so conceptually related documents without matching keywords are found.
- Why it looks right
- Semantic sounds like meaning-based search.
- Why it's wrong
- The semantic ranker only re-orders results already retrieved; finding documents by meaning needs vector or hybrid search.
Clue to watch for Users search with wording that never appears in relevant documents.
-
Template model for many suppliers
- What candidates pick
- Train a custom template model on purchase orders from 40 suppliers.
- Why it looks right
- Template models train quickly.
- Why it's wrong
- Template models expect fields in consistent positions; varied layouts need a custom neural model or a composed set of models.
Clue to watch for Different layouts, suppliers or formats for the same document type.
-
Fields in the first response
- What candidates pick
- Read the invoice fields from the body of the analyze POST response.
- Why it looks right
- Most REST APIs return results directly.
- Why it's wrong
- Document Intelligence analysis is asynchronous; you poll the Operation-Location URL until the result is ready.
Clue to watch for A 202 Accepted status or an Operation-Location header in the snippet.
-
Separate pipelines per media type
- What candidates pick
- Use Speech for calls, Vision for images and Document Intelligence for PDFs, then merge outputs.
- Why it looks right
- Each service is the specialist for its medium.
- Why it's wrong
- When the requirement is one consistent field schema across documents, images, audio and video, Content Understanding analyzers deliver it with far less integration work.
Clue to watch for Mixed media and a single structured output or classification requirement.
Answer framework
Use this sequence for any search or extraction question on AI-102.
- Decide the goal: searchable discovery across many files points to Azure AI Search; structured fields from documents point to Document Intelligence or Content Understanding.
- For search, design index fields and attributes first, from the filters, sorts, facets and vector queries users will run.
- Assemble the pipeline in order: data source, index, skillset with built-in or custom skills, then indexer with field mappings and output field mappings.
- Choose the retrieval method from the queries: keyword for exact terms, vector or hybrid for meaning, plus semantic ranking to improve ordering.
- For extraction, try a prebuilt model first, then template or neural custom models by layout variety, a composed model for several types, or Content Understanding for mixed media.
Practice question
Want more like this? The AI-102 practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with Azure AI Search because it carries the most configuration detail. Use the import wizard once on a Blob Storage container of mixed files, then open every object it created: data source, index, skillset and indexer. Read the JSON and explain each field attribute, field mapping and output field mapping in your own words. Then rebuild the same pipeline through the REST API or SDK so the order and dependencies become clear.
Next, write one custom skill as an Azure Function and break it deliberately by dropping recordId; the indexer errors teach the contract better than reading does. Add a knowledge store with one table and one object projection, and run queries with filters, sorts, facets, wildcards and fuzzy search in full syntax. Finish the search work by adding a vector field and a semantic configuration and comparing keyword, hybrid and semantic results.
Commonly underestimated areas are on the extraction side: the asynchronous analyze pattern, template versus neural models, and composed models. In Document Intelligence Studio, try the invoice and layout models, label five sample forms and train a custom model. Then run one document and one audio file through Content Understanding.
Afterwards, revisit Domain 2's RAG topics, which rely on this index design.
FAQ
How much of AI-102 is knowledge mining and information extraction?
This skill area is weighted at 15-20% in the final AI-102 study guide. Its concepts also support RAG and agent questions in the generative AI and agentic skill areas.
What is the difference between field mappings and output field mappings?
Field mappings copy source data into index fields before any skills run. Output field mappings copy enriched values from the enrichment tree into index fields after the skillset runs.
Do I need to know Lucene query syntax?
Know when queryType=full is needed (fuzzy, proximity, regular expressions, field-scoped and infix wildcard queries), how to use $filter, $orderby, $select and facets, and which field attributes each requires.
When should I choose a neural model over a template model?
Choose neural when the same fields appear in different positions across layouts, such as forms from many suppliers. Choose template for a single form whose layout does not change.
What does a composed model do?
It bundles several custom models under one model ID so a single call can handle several document types, with a classifier routing each document to the right component model in the current API version.
How is Content Understanding different from Document Intelligence?
Document Intelligence extracts text, layout and fields from documents with prebuilt and custom models. Content Understanding applies schema-driven extraction, classification and summarization across documents, images, audio and video.
How does this domain connect to RAG?
Most RAG solutions on Azure retrieve from an Azure AI Search index, so chunking, vector fields, hybrid search and semantic ranking configured here decide how well grounded answers perform in Domain 2.
Other Artificial Intelligence & Machine Learning certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 6 knowledge
You have just assembled an enrichment pipeline, matched index attributes to query needs, compared keyword, vector, hybrid and semantic retrieval, and chosen between prebuilt, custom and composed extraction models. Practice questions test those details under time pressure.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the AI-102 AI tutor Get any concept explained your way