An Azure service that turns documents into usable data. Previously known as Azure Form Recognizer.
Content Understanding and Document Intelligence are different services, even if they share similar analyzer names like prebuilt-layout. The behavior described is consistent with Content Understanding’s design and limitations rather than a generic OCR failure.
Key points from the service behavior and limitations:
- Content Understanding document analyzers are grounded and schema-driven
- Content Understanding “forces grounding – anchoring outputs in the text of the input documents – and will not return answers if they cannot be grounded.” In some cases, “the value of the field may be missing.”
- Extraction quality is “heavily dependent on the way you name the fields and description of the fields.”
- This means that, unlike Document Intelligence’s
prebuilt-layout, Content Understanding may return very sparse or empty structured output (including markdown) if it cannot confidently ground content according to its internal models and expectations.
- Different engine and purpose from Document Intelligence
- Document Intelligence
prebuilt-layoutis optimized for general OCR and layout extraction (pages, words, bounding boxes) and will typically return text for any reasonably legible PDF. - Content Understanding prebuilt analyzers are designed for higher-level content extraction, RAG, and domain-specific scenarios, not as a drop-in replacement for raw OCR. The documentation positions them for “content ingestion in search and retrieval-augmented generation (RAG) workflows” and intelligent document processing, with strong emphasis on grounding and contextualization.
- As a result, a document that works fine with Document Intelligence OCR can legitimately produce little or no usable output in Content Understanding if the system cannot confidently ground or structure the content.
- Document Intelligence
- Service limits and document behavior apply
- Content Understanding’s document behavior is governed by the documented service limits and behaviors for different document types. For example, the Azure Content Understanding skill in Azure AI Search calls the same document analyzer and notes that “all documented service behaviors for different document types apply to its output,” and that DOCX vs PDF can produce different results.
- If the PDF’s layout, resolution, or embedded text quality is marginal for the underlying layout model, Content Understanding may effectively return empty content even though Document Intelligence still returns OCR.
- RAG and prebuilt analyzers focus
- RAG-oriented analyzers like
prebuilt-documentSearchare optimized to “extract paragraphs, tables, and figure descriptions” and produce markdown for search and retrieval. They are not guaranteed to mirror Document Intelligence’s low-level OCR output. - Domain-specific analyzers (finance, tax, procurement, contracts) similarly focus on extracting structured fields, not raw text.
- RAG-oriented analyzers like
- What this implies for the scenario
- The described behavior (empty markdown, zero pages/words) on Content Understanding while Document Intelligence returns full OCR is consistent with:
- Different extraction objectives (grounded, schema- and context-driven vs raw OCR), and
- Document/field characteristics that do not meet Content Understanding’s grounding and extraction thresholds.
- The current workaround of continuing to use Document Intelligence for OCR is aligned with the documented positioning: Content Understanding is not documented as a full replacement for all Document Intelligence OCR scenarios.
- The described behavior (empty markdown, zero pages/words) on Content Understanding while Document Intelligence returns full OCR is consistent with:
Given the current documentation, the practical guidance is:
- Continue using Document Intelligence
prebuilt-layoutfor general-purpose OCR and layout extraction where full text is required. - Use Content Understanding prebuilt analyzers when the goal is:
- RAG ingestion (markdown paragraphs, tables, figure descriptions) or
- Domain-specific structured extraction (finance/tax, procurement/contracts) or
- Agentic workflows that rely on grounded, structured outputs.
- When designing Content Understanding custom analyzers, pay close attention to field naming and descriptions, since extraction quality depends on them and the system will omit values it cannot confidently ground.
If the same PDF consistently returns empty content across multiple Content Understanding analyzers and the document is clearly legible and simple, this would be a candidate for a support ticket, but the fallback to Document Intelligence is currently the documented and appropriate approach for robust OCR.
References:
- What is Azure Content Understanding in Foundry Tools?
- Document analysis: Extract structured content
- Prebuilt analyzers in Azure Content Understanding in Foundry Tools
- Transparency note: Azure Content Understanding in Foundry Tools
- Azure Content Understanding skill
- What's new in Azure Content Understanding in Foundry Tools?
- Quickstart: Use Azure Content Understanding in Foundry Tools (programming-language-csharp)