Implement solutions to extract entities, topics, summaries, and structured JSON outputs using generative prompting and Foundry Tools
AI-103 › Unit 4: Implement text analysis solutions › Apply language model text analysis › Implement solutions to extract entities, topics, summaries, and structured JSON outputs using generative prompting and Foundry Tools
Implement solutions to extract entities, topics, summaries, and structured JSON outputs using generative prompting and Foundry Tools
Azure Language now divides its features into core and legacy, and the split is counterintuitive enough to be the single most examinable fact in this topic. Named entity recognition is core; key phrase extraction and summarization are legacy. Knowing which is which — and when a generative approach replaces either — is what this objective tests.
Why This Matters
The core/legacy line does not follow usefulness. Legacy features are "supported for existing implementations", while core features are "recommended for new development". A new project should not be built on a legacy feature by default.
Two summarization approaches produce different artefacts. Extractive selects existing sentences and preserves their positions; abstractive writes new ones.
Structured JSON is a schema decision. A guaranteed shape comes from a schema — Content Understanding's fieldSchema — not from asking a model nicely.
Prerequisites
- What named entity recognition and key phrase extraction produce.
- That Content Understanding defines a
fieldSchemawith typed fields. - The three field methods, and that
extractis documents only. - Prompt techniques: specify output structure, give the model an out.
Learning Objectives
By the end of this lesson you will be able to:
- Place a feature correctly as core or legacy.
- Choose prebuilt or custom NER for an extraction requirement.
- Distinguish extractive and abstractive summarization.
- Produce guaranteed structured JSON.
- Decide between a Language feature and generative prompting.
Building Blocks
Core capabilities — "the primary, actively evolving features… recommended for new development and long-term planning": PII detection, Language detection, Named entity recognition (NER) with Custom NER and Prebuilt NER, and Text analytics for health.
Legacy capabilities — "established features that provide a stable, supported base for existing workloads… supported for existing implementations": Conversational language understanding, Custom text classification, Entity linking, Key phrase extraction, Orchestration workflow, Question answering, Sentiment analysis and opinion mining, Summarization.
Customizable against preconfigured. Customizable — you "train an AI model using our tools to fit your data": Custom NER, Custom text classification, CLU, Orchestration workflow, Question answering. Preconfigured — "the AI models it uses can't be changed": prebuilt NER, key phrase extraction, sentiment, summarization, language detection, entity linking.
Summarization shapes.
| Approach | Produces |
|---|---|
| Extractive | "Creates a summary by selecting key sentences from the document and preserving their original positions" |
| Abstractive | "Generates a summary by producing new, concise, and coherent sentences or phrases that aren't directly copied from the original document" |
Also conversation summarization, which "recaps and segments long meetings into timestamped chapters", and call center summarization, which "summarizes customer issues and resolution".
Access surfaces. REST APIs and client libraries, Microsoft Foundry for most features without code, and the Azure Language MCP server — "available both as a remote server in the Microsoft Foundry Tool Catalog and as a local server for self-hosted environments".
Containers. Sentiment analysis, language detection, key phrase extraction, custom NER, text analytics for health, and summarization.
Language feature against generative prompting
| Attribute | ||
|---|---|---|
| Output shape | Fixed, typed, documented | Whatever you schema or prompt for |
| Categories | Predefined, or trained by you | Defined in words |
| Consistency | High — deterministic model | Depends on schema use |
| Setup | None, or labelled training data | A schema or prompt |
| Fits | Standard categories, PII, health, on-premises via containers | Bespoke fields, mixed extraction and reasoning |
Deep Dive
The core/legacy split, and what it means in practice
The documentation is explicit about the intent. Core features "receive ongoing investment and feature updates, and are recommended for new development and long-term planning… If you are starting a new project or designing a future architecture, use core capabilities as the foundation." Legacy features are "supported for existing implementations and established use cases".
Note what this is not: legacy does not mean deprecated, unsupported, or scheduled for retirement. Sentiment analysis and summarization work, are documented, and several have containers. But a scenario describing a new build and offering a legacy feature alongside a core or generative alternative is testing whether you noticed.
The list that surprises people most: key phrase extraction ("extract main topics and important phrases") and summarization are both legacy, while NER is core. So "extract topics from these documents" — the classic key-phrase task — is a legacy answer for a new project, and the modern equivalent is a generative approach with a defined schema, or custom NER if the targets are entity-like.
Choosing the extraction approach
Check whether it is a core feature
PII, language detection, NER, text analytics for health — core, and the default for new work.
Entities: prebuilt, custom, or generative
Three routes, decided by whose categories they are.
Prebuilt NER "identifies different entries in text and categorizes them into predefined types" — preconfigured, so "the AI models it uses can't be changed". Zero setup, standard categories: people, places, organisations, dates, quantities.
Custom NER lets you "build custom AI models to extract custom entity categories (labels for words or phrases), using unstructured text that you provide". It is customizable, meaning labelled training data, and it is the core-capability answer when the categories are yours — part numbers, policy references, internal identifiers.
Text analytics for health is the specialist: it "extracts and labels relevant health information from unstructured text", and is core. A clinical extraction requirement should not be rebuilt with custom NER when this exists.
A generative approach — a Content Understanding fieldSchema, or a model prompted with a defined structure — needs no labelled data and can express categories in words. It is the pragmatic answer when training data does not exist, when the categories change often, or when extraction is mixed with judgement ("the obligation described, and whether it is met").
The discriminator to carry: labelled data available and categories stable → Custom NER. No labelled data, or categories fluid → a schema-driven generative approach.
Summarization: two shapes, two uses
The distinction is precise and worth quoting.
Extractive summarization "creates a summary by selecting key sentences from the document and preserving their original positions". Nothing is reinvented, so every sentence in the summary appears verbatim in the source. That property matters where wording is legally or clinically significant, and where a reader may need to locate the passage.
Abstractive summarization "generates a summary by producing new, concise, and coherent sentences or phrases that aren't directly copied from the original document". It reads better and can synthesise across sections — and it introduces the possibility of a statement that no sentence in the source supports.
Two specialised forms exist. Conversation summarization "recaps and segments long meetings into timestamped chapters" — note the timestamps, which make it navigational rather than merely descriptive. Call center summarization "summarizes customer issues and resolution", a structure shaped to that domain.
All of this sits under legacy, so for a new build the alternatives are a generative summary against a schema — which can also carry confidence and grounding — or these features where their specific output shape is exactly what is wanted.
Structured JSON, and the extract restriction
Producing reliable structured output has one platform rule worth restating: Content Understanding's extract method — values "as they appear in the input content" — is "supported for documents only". For any other modality, values are classified (from an enum) or generated.
For text documents, that makes the full toolkit available: extract for literal values, classify for closed vocabularies, generate for summaries and judgements, all in one schema and one pass, with confidence and grounding attached via estimateFieldSourceAndConfidence.
The pairing that works well in practice is a classify field for the category alongside a generate field for the rationale — a clean facet for filtering plus a human-readable justification, each with its own confidence score.
Reaching the features
Three surfaces matter for the exam.
Microsoft Foundry "enables you to use most of the… service features without the need to write code".
The Azure Language MCP server is the agent integration path: "available both as a remote server in the Microsoft Foundry Tool Catalog and as a local server for self-hosted environments". Remote for cloud-hosted deployments, local "for developers who prefer to host the server in their own environment" — the discriminator being where the server runs, not what it does.
Containers bring features on-premises "for compliance, security, or other operational reasons", and the list is specific: sentiment analysis, language detection, key phrase extraction, custom NER, text analytics for health, and summarization. A data-residency requirement that names a feature outside that list rules the container option out.
Worked Examples
Example 1 — topics from a new document corpus. A new project must extract the main topics from unstructured documents.
Key phrase extraction is the classic fit — "extract main topics and important phrases" — but it is a legacy capability, "supported for existing implementations", while core features are "recommended for new development". For a new build, prefer a generative approach with a defined schema, or Custom NER if the targets are entity-like and labelled data exists.
Example 2 — summarising regulated correspondence. Summaries must contain only wording that appears in the source, so a reviewer can locate each statement.
Extractive summarization, which "creates a summary by selecting key sentences… preserving their original positions". Abstractive produces "new… sentences… not directly copied", which is exactly what this requirement forbids.
Example 3 — extraction with no labelled data. Fields must be pulled from contracts, the categories are organisation-specific, and no labelled training set exists.
Custom NER is customizable but needs labelled text. With none available, use a Content Understanding fieldSchema — extract is available because these are documents, alongside classify and generate — giving typed fields plus confidence scores and grounding with no training data.
Visual Explanations
Core and legacy at a glance:
Choosing an extraction route:
Common Mistakes
Building new work on a legacy feature by default.
Assuming legacy means deprecated. It means supported for existing implementations.
Thinking key phrase extraction or summarization is core. Both are legacy.
Thinking sentiment is core. It is legacy; PII detection is core.
Choosing abstractive where wording must be preserved.
Choosing Custom NER without labelled data. It is customizable, so it needs training.
Rebuilding clinical extraction where text analytics for health exists.
Prompting for JSON where a schema is required.
Assuming every feature has a container. The list is specific.
Practice Exercises
- List the four core capabilities and any four legacy ones.
- Distinguish extractive and abstractive summarization, and give a requirement that forces each.
- When is Custom NER right, and what does it require?
- Which Language features have containers?
- What are the two Azure Language MCP server options and how do they differ?
▶Answers
- Core: PII detection, Language detection, NER (custom and prebuilt), Text analytics for health. Legacy (any four of): CLU, custom text classification, entity linking, key phrase extraction, orchestration workflow, question answering, sentiment analysis and opinion mining, summarization.
- Extractive "creates a summary by selecting key sentences… preserving their original positions" — forced when the wording must be verbatim and locatable, as in regulated or clinical text. Abstractive produces "new, concise, and coherent sentences… not directly copied" — forced when the summary must synthesise across sections rather than quote.
- When the entity categories are your own rather than predefined, and the categories are stable. It is a customizable feature, so it requires labelled unstructured text to train on. Without labelled data, use a schema-driven generative approach.
- Sentiment analysis, language detection, key phrase extraction, custom NER, text analytics for health, and summarization — used to "bring the service closer to your data for compliance, security, or other operational reasons".
- A remote server, "available through Foundry Tool Catalog for cloud-hosted deployments", and a local server, "available for developers who prefer to host the server in their own environment". The difference is where the server runs, not the capabilities exposed.
Summary & Concept Map
Azure Language splits into core — PII detection, language detection, NER (custom and prebuilt), and text analytics for health, "recommended for new development" — and legacy — CLU, custom text classification, entity linking, key phrase extraction, orchestration workflow, question answering, sentiment and opinion mining, and summarization, "supported for existing implementations". The surprises are that topics (key phrase extraction) and summarization are legacy while NER is core. Summarization itself splits into extractive, which selects existing sentences and preserves their positions, and abstractive, which writes new ones — plus conversation summarization with timestamped chapters and call centre summarization. For entities, choose prebuilt for predefined types, Custom NER where categories are yours and labelled data exists, and a Content Understanding fieldSchema where it does not — the only route that guarantees structured JSON with confidence scores and grounding. Reach features through Foundry, the remote or local MCP server, or the specific container list.
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.