BrainyBeeBrainyBee
ExploreBlogStart Studying
HomeDeveloping AI Apps and Agents on Azure (AI-103)Implement analyzers for generating structured or markdown outputs for downstream reasoning using Content Understanding
Lesson2,953 words

Implement analyzers for generating structured or markdown outputs for downstream reasoning using Content Understanding

AI-103 › Unit 5: Implement information extraction solutions › Extract content from documents › Implement analyzers for generating structured or markdown outputs for downstream reasoning using Content Understanding

Implement analyzers for generating structured or markdown outputs for downstream reasoning using Content Understanding

Designing an analyzer is four decisions: which prebuilt to start from, what output format to emit, how to segment the input, and what fields to define with which methods. The last is where most of the difficulty sits, because a field's description is its specification and the method choice determines how reliable the value will be.

Why This Matters

Output format follows the consumer. Markdown for "search and retrieval scenarios"; structured JSON matching your schema "for automation and analytics workflows".

Method choice determines reliability. classify returns a value from a closed set; generate returns free-form text. extract is documents only.

Segmentation costs tokens. "Setting segmentation will use the generative model, consuming tokens even if no fields are defined."

The four analyzer decisions

1. Prebuilt or custom — start from a prebuilt where one fits. 2. Output format — markdown for retrieval, JSON for automation, and one pass can give both. 3. Segmentation — whole input or divided, via enableSegment; it consumes tokens either way once enabled. 4. Fields — name, type, description as specification, and a method: extract (documents only), classify (with an enum), or generate.

Prerequisites

  • The analyzer's components and estimateFieldSourceAndConfidence.
  • The three field methods and the documents-only restriction.
  • Segmentation with enableSegment and contentCategories.
  • The API versions: 2025-11-01 GA and 2026-06-01-preview.

Learning Objectives

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

  1. Choose markdown, structured JSON, or both.
  2. Design a fieldSchema with the right method per field.
  3. Write field descriptions that function as specifications.
  4. Configure segmentation and account for its cost.
  5. Improve an analyzer with labelled examples.

Building Blocks

Output. "The final result is supplied in your chosen format. Content can be output as Markdown for search and retrieval scenarios, or as structured JSON matching your defined schema for automation and analytics workflows."

The field schema. Each entry "defines a field's name, type, and description". Each carries a method:

MethodProducesRestriction
extractValues "as they appear in the input content""Supported for documents only"
classifyA category "from a predefined set of categories"Needs an enum
generateValues "freely from input data"—

Segmentation. "Divides documents or videos into logical sections for targeted processing. Configured using the enableSegment property." Whole input — enableSegment: false. Custom — enableSegment: true with contentCategories describing the logic in natural language; for video, "only supports one contentCategories object". And: "Setting segmentation will use the generative model, consuming tokens even if no fields are defined."

Verification. estimateFieldSourceAndConfidence gives confidence scores 0–1 and grounding to source regions.

Models. "You bring your own deployments of supported generative models and text-embedding models for training examples."

Improvement. Custom analyzers support labelled training examples; 2026-06-01-preview "improves training behavior by distilling patterns into the built analyzer for improved privacy and efficiency". Content Understanding Studio "offers an experience optimized for analyzer performance improvement including improving custom analyzers using data labeling techniques".

Prebuilts. prebuilt-invoice, prebuilt-imageSearch, prebuilt-audioSearch, prebuilt-videoSearch, prebuilt-videoAnalysis, plus "industry-specific prebuilt analyzers… including tax preparation, procurement document processing, contract analysis, call center analytics, media analysis".

Versions. 2025-11-01 (GA) "recommended for production use"; 2026-06-01-preview for evaluation, adding agentic mode, in-page segmentation, signature detection, and document metadata extraction.

Choosing the method per field

Attribute
Value comes from

The content, verbatim

Your enum

The model

Modality

Documents only

Any

Any

Reliability

Highest

High — closed set

Varies — check confidence

Downstream use

Direct binding

Filtering, grouping, routing

Display, explanation, search

Example

Invoice date

Document type, outcome

Summary, rationale

Deep Dive

Format follows the consumer

The first decision is who reads the output.

Markdown is "for search and retrieval scenarios". It preserves readable structure — headings, lists, tables — so chunks make sense to a model and to a person reviewing what was retrieved. It needs no parser, which is the whole point.

Structured JSON is "for automation and analytics workflows", matching your schema so code binds to named fields, each with a confidence score.

The important observation is that these are not exclusive. A single analyzer pass can emit markdown for the retrieval path and typed fields for filtering and routing — one reading of the document producing both. That matters practically: two separate passes cost twice and can disagree about what the document contains.

A useful default for RAG-plus-automation pipelines: markdown as the indexed body, plus a small set of classify fields as filterable facets — document type, jurisdiction, status — so retrieval can be narrowed before semantic matching runs.

Designing an analyzer

  1. 1

    Start from a prebuilt if one fits

    Including industry-specific analyzers for tax, procurement, contracts, call centre, and media.

Method choice is a reliability decision

Every field gets a method, and the choice determines how much you can trust the value.

extract is the most reliable because the value is in the content — the analyzer locates it rather than producing it. It is also the most restricted: "supported for documents only". For a text document this is the right method for dates, totals, reference numbers, and named parties.

classify is next, because the answer must come from an enum you defined. A closed set means the value is one of a known list, which is what downstream code can switch on and analytics can group by. Whenever a category exists — document type, status, outcome, jurisdiction, risk band — this beats asking for free text, which yields synonyms that nothing can group.

generate produces free-form values and is right for summaries, descriptions, and rationales — genuinely open outputs. It carries the most variance, which is exactly why the confidence score matters most here.

The pattern that recurs: classify for the facet, generate for the explanation. A clean groupable category plus a human-readable justification, each with its own confidence, gives filtering and reviewability from one field pair.

And the discipline: every field is generated output across every input, so speculative fields multiply cost over a large corpus. Define what will be consumed.

Descriptions as specifications

A field's description is not documentation — it is the instruction that produces the value, and the difference between a vague and a precise one is the difference between usable and not.

A weak description says "the effective date". A specification says: "The date the agreement takes effect, as stated in the document, in ISO 8601 format. If several dates appear, use the one governing commencement. If no effective date is stated, return an empty string."

Four things are doing work there: the format, the disambiguation rule for multiple candidates, and the explicit absent case — which is "give the model an out" applied to extraction, and the reason a field returns nothing rather than a plausible invention.

For classify fields, the enum carries much of the specification, but the description should still say how to choose when a document could plausibly fit two categories. For generate fields, state length, what to include, and what to omit — speculation, unverifiable inference, restatement of other fields.

Segmentation, and its cost

enableSegment decides whether the analyzer treats the input whole or divides it, and the documentation gives both the mechanism and the warning.

Whole input (false) suits questions about the document as a whole — a classification, an overall summary, a compliance sweep looking for an issue anywhere.

Custom segmentation (true) creates sections from a natural-language contentCategories description — chapters, topics, clause groups. Fields are then filled per segment, which is what produces per-section conclusions rather than one aggregated answer. For video, "only supports one contentCategories object".

The cost note is explicit and easy to miss: "Setting segmentation will use the generative model, consuming tokens even if no fields are defined." So segmentation is generative work, not free structural preprocessing — enabling it "just to get sections" has a real bill attached across a large corpus.

For documents specifically, there is often a cheaper alternative: Document Intelligence's paragraph roles — title and sectionHeading — give structural boundaries deterministically, without generative segmentation. Where the required division follows the document's own headings, that is both cheaper and more predictable; where it follows meaning that headings do not express, generative segmentation earns its cost.

Free-text categories cannot be grouped

A generate field asked for "the document type" will return Agreement, Service Agreement, MSA, and master services agreement across a corpus — all correct, none groupable. A classify field with an enum returns one of a known set every time, which code can switch on and analytics can aggregate. Whenever the answer belongs to a closed vocabulary, classify; reserve generate for genuinely open output.

Improving an analyzer

When a schema alone does not reach the accuracy needed, there is a path short of building a trained model.

Labelled training examples are supported for custom analyzers, and Content Understanding Studio "offers an experience optimized for analyzer performance improvement including improving custom analyzers using data labeling techniques". This is a middle rung: better than schema-only, cheaper than training a custom NER model, and it keeps the analyzer's confidence and grounding.

In 2026-06-01-preview, training "improves training behavior by distilling patterns into the built analyzer for improved privacy and efficiency" — worth knowing as a preview-only capability.

Two other preview additions matter for document reasoning: in-page segmentation, which divides within a page rather than only between documents, and signature detection and document metadata extraction. All are 2026-06-01-preview, so a production-constrained scenario keeps them out and stays on 2025-11-01 GA.

Worked Examples

Example 1 — categories that will not aggregate. A contract pipeline generates a document-type field and analytics cannot group the results.

The field uses generate, returning synonyms. Change it to classify with an enum — a closed set returning one known value every time, which code can switch on and analytics can group. Keep a generate field beside it for the rationale if reviewers need to see why.

Example 2 — an invented date. An effective-date field returns a plausible date for documents that do not state one.

The description lacks an absent case. Specify it: "…If no effective date is stated, return an empty string." — "give the model an out" applied to extraction. Since these are documents, prefer extract, which locates the value in the content rather than producing it, and enable estimateFieldSourceAndConfidence so a low-confidence date is visible.

Example 3 — sections at generative cost. A team enables segmentation purely to split documents at their headings, and token spend rises across the corpus.

"Setting segmentation will use the generative model, consuming tokens even if no fields are defined." Where the division follows the document's own headings, Document Intelligence's paragraph roles — title and sectionHeading — give the same boundaries deterministically and more cheaply. Reserve generative segmentation for divisions that follow meaning rather than headings.

Visual Explanations

The four decisions:

Loading Diagram...
Figure 1 — Mermaid diagram

Method selection:

Loading Diagram...
Figure 2 — Mermaid diagram

Common Mistakes

Using generate where a closed set exists. Synonyms cannot be grouped.

Using extract on non-document input. Documents only.

Writing a vague description. It is the specification that produces the value.

Omitting the absent case. The model invents a plausible value.

Enabling segmentation for structural splits that paragraph roles give deterministically.

Forgetting segmentation consumes tokens even with no fields defined.

Defining fields nobody consumes. Every field costs output across the corpus.

Choosing one output format where markdown and JSON serve different consumers.

Using preview versions in production. 2025-11-01 is GA.

Practice Exercises

  1. Name the four analyzer design decisions.
  2. Which method for each: an invoice date; a risk band; a summary?
  3. What four things belong in a strong field description?
  4. State the cost note on segmentation, and a cheaper alternative for documents.
  5. What is the middle rung between a schema and a trained model?
▶Answers
  1. Prebuilt or custom; output format (markdown for retrieval, JSON for automation, or both from one pass); segmentation via enableSegment; and fields with methods — each field's name, type, description, and method.
  2. Invoice date → extract (the value is literally in a document, and extract is documents only). Risk band → classify with an enum (a closed set, groupable and switchable). Summary → generate (genuinely open output, so watch its confidence score).
  3. The format the value should take, a disambiguation rule when several candidates exist, what to omit, and the absent case — what to return when the value is not present, which prevents a plausible invention.
  4. "Setting segmentation will use the generative model, consuming tokens even if no fields are defined." For documents, Document Intelligence's paragraph roles — title and sectionHeading — give structural boundaries deterministically and more cheaply; reserve generative segmentation for divisions that follow meaning rather than headings.
  5. Labelled training examples for custom analyzers, with Content Understanding Studio's data labeling techniques — better than schema-only, cheaper than training a custom NER model, and it keeps confidence and grounding. In 2026-06-01-preview, training also distils patterns into the built analyzer for privacy and efficiency.

Summary & Concept Map

Implementing an analyzer is four decisions. Start from a prebuilt where one fits, including the industry-specific set. Choose the output format by consumer — markdown for search and retrieval, structured JSON for automation and analytics, and note one pass can produce both. Configure segmentation with enableSegment and contentCategories, remembering it "will use the generative model, consuming tokens even if no fields are defined" — and that for structural splits, Document Intelligence's paragraph roles are cheaper and deterministic. Then define fields, choosing methods by reliability: extract where the value is literally in a document, classify with an enum wherever a closed set exists so results are groupable, and generate for genuinely open output — with each description written as a specification including the absent case. Enable estimateFieldSourceAndConfidence, and improve with labelled examples before reaching for a trained model.

Loading Diagram...
Figure 3 — Mermaid diagram
Loading flashcards…

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.

All Developing AI Apps and Agents on Azure (AI-103) Study Resources

Related Notes

  • Choose an appropriate method for retrieval and indexing2,778 words
  • Quick Note — Choose an appropriate method for retrieval and indexing888 words
  • Choose an appropriate model for each task, including LLMs, small language models, multimodal models, and Foundry Tools3,097 words
  • Quick Note — Choose an appropriate model for each task, including LLMs, small language models, multimodal models, and Foundry Tools1,041 words
  • Choose appropriate memory, tool, and knowledge integration services for agent solutions2,815 words
  • Quick Note — Choose appropriate memory, tool, and knowledge integration services for agent solutions949 words
  • Choose the appropriate Foundry services for generative tasks, grounding, vector search, agent workflows, or multimodal processing2,733 words
  • Quick Note — Choose the appropriate Foundry services for generative tasks, grounding, vector search, agent workflows, or multimodal processing901 words
  • Apply responsible AI instrumentation, including evaluators, safety evaluations, and explanation tooling2,891 words
  • Configure safety filters, guardrails, risk detection, and content moderation2,795 words
  • Govern agent behavior with oversight modes, constraints, and tool-access controls2,863 words
  • Implement auditing through trace logging, provenance metadata, and approval workflows2,624 words

Ready to study Developing AI Apps and Agents on Azure (AI-103)?

Practice tests, flashcards, and all study notes — free, no sign-up.

Start Studying

Ready to study Developing AI Apps and Agents on Azure (AI-103)?

Practice tests, flashcards, and all study notes — free, no sign-up needed.

Start Studying — Free
Developing AI Apps and Agents on Azure (AI-103) ResourcesExplore All HivesBlogHome

© 2026 BrainyBee. Free AI-powered exam prep.

Loading Diagram...
Flowchart, top to bottom. Analyzer design connects to 1. Prebuilt or custom. Analyzer design] --> D1[1. Prebuilt or custom connects to 2. Output format. Analyzer design] --> D1[1. Prebuilt or custom connects to 3. Segmentation. Analyzer design] --> D1[1. Prebuilt or custom connects to 4. Fields and methods. D2 connects to Markdown: search + retrieval. D2 connects to JSON: automation + analytics. D2 connects to One pass can give BOTH. D3 connects to enableSegment false: whole input. 5 more statements.
Loading Diagram...
Flowchart, top to bottom. A field to define connects to Is the value literally<br/>in a document?. Q1 connects to EXTRACT - highest reliability (Yes). Q1 connects to Closed set of answers? (No). Q2 connects to CLASSIFY with an enum -<br/>groupable, switchable (Yes). Q2 connects to GENERATE - specify length,<br/>inclusions, exclusions,<br/>and the ABSENT case (No). CL connects to Common pair:<br/>classify the facet,<br/>generate the rationale. GE connects to PAIR.
Loading Diagram...
Flowchart, top to bottom. Implementing analyzers connects to Start point. Implementing analyzers] --> ST[Start point connects to Output format. Implementing analyzers] --> ST[Start point connects to Segmentation. Implementing analyzers] --> ST[Start point connects to Fields. Implementing analyzers] --> ST[Start point connects to Improvement. ST connects to Prebuilt incl. industry-specific. OF connects to Markdown: retrieval. OF connects to JSON: automation. 12 more statements.

Implementing analyzers — retrieval

Card 1 of 6

Front of flashcard 1 of 6

Output format by consumer

easy

Markdown for "search and retrieval scenarios" — no parser needed. Structured JSON matching your schema for "automation and analytics workflows". One analyzer pass can produce both, from a single reading.

output

Implementing analyzers — retrieval

Card 1

Front

Output format by consumer

Back

Markdown for "search and retrieval scenarios" — no parser needed. Structured JSON matching your schema for "automation and analytics workflows". One analyzer pass can produce both, from a single reading.

Card 2

Front

Choosing the field method

Back

extract where the value is literally in a document — most reliable, documents only. classify with an enum wherever a closed set exists — groupable and switchable. generate for genuinely open output — highest variance, so watch confidence.

Card 3

Front

Why free-text categories fail

Back

A generate field returns Agreement, Service Agreement, MSA, master services agreement — all correct, none groupable. A classify field with an enum returns one of a known set every time, which code can switch on and analytics can aggregate.

Card 4

Front

What belongs in a field description

Back

The format the value should take, a disambiguation rule for multiple candidates, what to omit, and the absent case — what to return when the value is not present. The last is "give the model an out" applied to extraction.

Card 5

Front

The segmentation cost note

Back

"Setting segmentation will use the generative model, consuming tokens even if no fields are defined." For structural splits in documents, Document Intelligence's paragraph roles (title, sectionHeading) give the same boundaries deterministically and more cheaply.

Card 6

Front

Improving an analyzer short of training a model

Back

Labelled training examples for custom analyzers, with Content Understanding Studio's data labeling techniques — keeping confidence and grounding. In 2026-06-01-preview, training distils patterns into the built analyzer "for improved privacy and efficiency".

Implementing analyzers — retrieval

Card 1

Front

Output format by consumer

Back

Markdown for "search and retrieval scenarios" — no parser needed. Structured JSON matching your schema for "automation and analytics workflows". One analyzer pass can produce both, from a single reading.

Card 2

Front

Choosing the field method

Back

extract where the value is literally in a document — most reliable, documents only. classify with an enum wherever a closed set exists — groupable and switchable. generate for genuinely open output — highest variance, so watch confidence.

Card 3

Front

Why free-text categories fail

Back

A generate field returns Agreement, Service Agreement, MSA, master services agreement — all correct, none groupable. A classify field with an enum returns one of a known set every time, which code can switch on and analytics can aggregate.

Card 4

Front

What belongs in a field description

Back

The format the value should take, a disambiguation rule for multiple candidates, what to omit, and the absent case — what to return when the value is not present. The last is "give the model an out" applied to extraction.

Card 5

Front

The segmentation cost note

Back

"Setting segmentation will use the generative model, consuming tokens even if no fields are defined." For structural splits in documents, Document Intelligence's paragraph roles (title, sectionHeading) give the same boundaries deterministically and more cheaply.

Card 6

Front

Improving an analyzer short of training a model

Back

Labelled training examples for custom analyzers, with Content Understanding Studio's data labeling techniques — keeping confidence and grounding. In 2026-06-01-preview, training distils patterns into the built analyzer "for improved privacy and efficiency".