Configure RAG ingestion flow including documents and OCR
AI-103 › Unit 5: Implement information extraction solutions › Build retrieval and grounding pipelines › Configure RAG ingestion flow including documents and OCR
Configure RAG ingestion flow including documents and OCR
The RAG ingestion flow is a fixed sequence — crack, extract text including OCR, split, embed, map, index — and each stage has one decision that determines the quality ceiling of everything downstream. This objective is about getting that sequence right for documents, where scanned pages, embedded figures, and layout make text extraction less trivial than it looks.
Why This Matters
OCR is not automatic. Document cracking extracts text and images; turning the text inside those images into searchable content requires an OCR step you configure.
Chunk boundaries decide what can be retrieved. A fact split from its qualifying sentence is retrievable and misleading.
Order is load-bearing. Splitting before embedding, and OCR before splitting, are not stylistic preferences — each stage consumes the previous one's output.
Prerequisites
- Document cracking and the initial enrichment tree.
- Skill context, inputs, outputs, and the two mapping types.
- The Split skill's grains and integrated vectorization.
- Document Intelligence as an alternative document converter.
Learning Objectives
By the end of this lesson you will be able to:
- Sequence the ingestion stages and explain each dependency.
- Configure OCR over images extracted from documents.
- Choose a chunking strategy and preserve context across boundaries.
- Decide between a skillset pipeline and Document Intelligence or Content Understanding.
- Plan re-ingestion when the pipeline changes.
Building Blocks
Cracking. "Text and images are extracted from the source and made available for language or image analysis", producing /document/content and /document/normalized_images/* for blobs in default parsing mode.
OCR. A built-in skill performing "optical character recognition (OCR) on an image file" — the documented example of what a skill does. It runs over the normalized images branch, producing text nodes that did not exist in /document/content.
Merge. Merge and Shaper skills "create new nodes but only use data from existing nodes and don't create net new enrichments" — the merge skill's role in this pipeline is recombining OCR'd image text with the document's native text.
Split. Grains of pages — "approximately 5,000 characters" — and sentences. "Splitting large text into smaller chunks can produce better outcomes", and the skill is "typically first in a skillset" where chunking is required. The documented alternative is the Azure Content Understanding skill.
Embedding. Integrated vectorization generates embeddings "inside the indexing pipeline and at query time", removing the possibility of index-time and query-time drift.
Mapping. fieldMappings carry raw source fields; outputFieldMappings carry enrichment nodes. "Not all nodes in the enrichment tree need to make it to the index."
Document Intelligence as an alternative. prebuilt-read is the model that produces a searchable PDF; prebuilt-layout extracts paragraphs, tables, selection marks, and paragraph roles and can emit Markdown with outputContentFormat=markdown.
Caching. The enriched document "can be cached", which matters when re-running expensive enrichment over unchanged content.
Three routes to ingest documents
| Attribute | |||
|---|---|---|---|
| You configure | Each skill and its context | A model and add-ons | An analyzer and schema |
| Structure returned | Whatever skills produce | Tables, selection marks, paragraph roles | Markdown or schema JSON |
| Chunking | Split skill | By page or section | Segmentation |
| Fits | Custom enrichment chains | Structure-driven downstream logic | Clean RAG-ready representations |
| Runs | Inside the indexer | Before or within indexing | Before or within indexing |
Deep Dive
Where OCR belongs, and why it is missed
Cracking gives you two branches, and the second is the one teams forget.
/document/content holds text the format already exposed — a digital PDF's text layer, a Word document's body. /document/normalized_images/* holds images extracted from the file: scanned pages, photographs, and figures embedded inside otherwise-textual documents.
An OCR skill run over that images branch turns those pixels into text nodes. Without it, three classes of content are silently absent from the index: fully scanned documents (whose text layer is empty), the text inside charts and diagrams, and screenshots pasted into reports.
The failure mode is characteristic and worth recognising: the pipeline runs cleanly, the index populates, and a specific class of question returns nothing — because that content was never text. Because it is silent, the check belongs in the design: sample a scanned document and confirm its content appears.
Two follow-on details. Merge the OCR output back with the native text so a chunk contains the document's content in sensible order rather than two disconnected streams. And note that Office formats do not yield embedded images through Document Intelligence's page-unit handling — "embedded or linked images aren't supported" for DOCX, XLSX, and PPTX — so an image-bearing Word file needs a different route.
Configuring RAG ingestion for documents
Crack the documents
Confirm both branches:
/document/contentand/document/normalized_images/*.
Chunking, and what boundaries destroy
Chunk size is the decision that most affects retrieval quality, and both directions fail.
Too large and the embedding becomes diffuse — a 5,000-character page covering four topics produces a vector that matches all four weakly and none strongly. It also wastes context window when retrieved, since most of the chunk is irrelevant to the question.
Too small and context is severed. The sentence "This does not apply to accounts opened before 2020" is meaningless alone, and actively misleading if retrieved without the rule it qualifies. Sentence-grain splitting is precise and prone to exactly this.
Two mitigations are standard. Split on structure rather than character count where structure exists — which is an argument for Document Intelligence's paragraph roles, since title and sectionHeading mark natural boundaries far better than a character offset. And carry context into the chunk: including the section heading or document title in each chunk's text gives the embedding something to anchor on and the model something to orient by.
The reason this matters more in RAG than in general search: a human scanning results tolerates a partial passage and reads around it. A model receives only the chunk, so the chunk must be self-sufficient.
Choosing the route
Three ways to get documents into an index, and the requirement decides.
A skillset pipeline gives maximum control — you choose each skill, its context, and the chain. It suits custom enrichment: a proprietary classifier, an internal lookup, an unusual combination. The cost is that you assemble and debug the chain yourself.
Document Intelligence is right when structure drives downstream logic. prebuilt-layout extracts tables, selection marks, and paragraph roles — title, sectionHeading, footnote, pageHeader, pageFooter, pageNumber — and can emit Markdown with outputContentFormat=markdown. Those roles are also the best available chunk boundaries. And prebuilt-read is the only model producing a searchable PDF, which is a distinct deliverable from an index entry.
Content Understanding is right when you want a clean representation with minimal assembly — Markdown for retrieval or schema-shaped JSON, with confidence scores and grounding, plus "extensive support for figure description and analysis". Its video output "can drop straight into a vector store… no post-processing is required", and the same philosophy applies to documents.
These compose: Document Intelligence or Content Understanding can produce the text, and a skillset can enrich it further before indexing.
Provenance and verification
Two habits separate a pipeline that can be trusted from one that merely runs.
Carry provenance into every record. Source identifier, page number, and — where Document Intelligence or Content Understanding produced it — the boundingRegions or grounding region. That is what turns an answer's citation from "this document" into "this page, this paragraph", and it costs almost nothing at ingestion while being impossible to reconstruct later.
Verify by sampling, not by absence of errors. The pipeline's failures are silent: missing OCR produces no error, a bad chunk boundary produces no error, an unmapped enrichment produces no error. Sample deliberately — a fully scanned document, a report with figures, a long document's boundaries, and a record's provenance fields — before declaring the ingestion correct.
The connecting principle from the ingestion objective applies here too: whatever the pipeline did not capture is unanswerable later, and no amount of retrieval or prompt tuning recovers it.
Worked Examples
Example 1 — scanned contracts return nothing. Digital PDFs answer questions well; scanned ones return nothing, with no errors anywhere.
The scanned files have no text layer, so /document/content is effectively empty and everything is in /document/normalized_images/*. Add an OCR skill over that branch and merge its output with the native text. The absence of errors is expected — this failure is always silent, which is why sampling a scanned document belongs in the design.
Example 2 — a misleading retrieved chunk. Sentence-grain chunks return a rule without the exception that qualifies it.
Chunk boundaries severed the context. Move to a larger grain, or better, split on structure — Document Intelligence's paragraph roles (title, sectionHeading) mark natural boundaries — and carry the section heading into each chunk so it is self-sufficient. A model sees only the chunk, unlike a human who reads around a result.
Example 3 — a new embedding model. A team upgrades the embedding model and retrieval quality falls unevenly.
Existing vectors were produced by the old model, so the index now mixes two embedding spaces. This is a re-ingestion event: re-embed the corpus. Integrated vectorization prevents the query-side half of this problem by generating both in-pipeline, but it does not retroactively re-embed stored documents.
Visual Explanations
The ingestion sequence:
What each silent failure costs:
Common Mistakes
Omitting OCR and losing scanned pages and embedded figures.
Not merging OCR output with native text.
Chunking by character count where structure exists.
Sentence-grain chunks that sever qualifiers.
Assuming errors would surface a broken pipeline. Every failure here is silent.
Changing chunk size or embedding model without re-ingesting.
Dropping provenance — page numbers and bounding regions are cheap now, impossible later.
Expecting embedded images from Office formats. Not supported there.
Assembling a skillset chain where Content Understanding gives a clean representation directly.
Practice Exercises
- Give the canonical ingestion order and one dependency it enforces.
- Which content disappears without an OCR step, and why is there no error?
- Describe both chunking failure directions and two mitigations.
- Which route suits structure-driven downstream logic, and what does it return?
- Name three changes that constitute a re-ingestion event.
▶Answers
- Crack → OCR over images → merge → split → embed → map → index. A dependency: OCR must precede splitting, because chunking runs over text — image-derived text that has not been extracted yet cannot be chunked, and would be lost entirely.
- Fully scanned documents (empty text layer), text inside charts and diagrams, and screenshots pasted into reports — all of which live in
/document/normalized_images/*. There is no error because the pipeline succeeded: it indexed everything that was text, and the missing content was never text. - Too large — diffuse embeddings matching many topics weakly, plus wasted context window. Too small — facts severed from qualifiers, so a rule can be retrieved without its exception. Mitigations: split on structure (Document Intelligence paragraph roles such as
titleandsectionHeading) and carry the section heading into each chunk so it is self-sufficient. - Document Intelligence.
prebuilt-layoutreturns tables, selection marks, and paragraph roles (title,sectionHeading,footnote,pageHeader,pageFooter,pageNumber) and can emit Markdown viaoutputContentFormat=markdown;prebuilt-readis the only model producing a searchable PDF. - Changing the embedding model (existing vectors came from the old one), changing chunk size or boundaries, and adding or changing the OCR step or analyzer version — all are baked into the index at ingestion, so existing records keep the old treatment and the index becomes internally inconsistent.
Summary & Concept Map
RAG ingestion for documents is a dependent sequence: crack into /document/content and /document/normalized_images/*, OCR the images branch — without which scanned pages, figures, and screenshots are silently absent — merge the two text streams, split into chunks of pages (~5,000 characters) or sentences, embed with integrated vectorization, and map selectively with outputFieldMappings while carrying provenance. Chunking fails in both directions: too large gives diffuse embeddings, too small severs facts from their qualifiers, and the mitigations are splitting on structure — Document Intelligence's paragraph roles — and carrying headings into each chunk, because a model sees only the chunk. Choose the route by requirement: a skillset for custom chains, Document Intelligence when structure drives downstream logic, Content Understanding for a clean representation. And treat chunk size, embedding model, and OCR configuration as baked in — changing them is a re-ingestion event, verified by sampling rather than by the absence of errors.
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.