Implement text analysis solutions Study Guide — AI-103

Implement text analysis solutions

This domain (13% of AI-103, roughly 6–8 scored items) tests whether you can pick and configure the right Microsoft service — Language in Foundry Tools (Azure AI Language), Translator, Speech, Content Safety, and Foundry Models (Azure OpenAI) — to extract meaning from text and audio, and to wire those capabilities into agentic solutions. Expect questions phrased as short business scenarios ending in "which service/feature/parameter should you use?", plus SDK/REST fragments where one property is missing. Microsoft has rebranded Azure AI services capabilities as Foundry Tools inside Microsoft Foundry / Azure AI Foundry; the exam may use either name, so memorise the mapping.

Extracting entities, topics, summaries and structured JSON

Prebuilt Language capabilities (no training, REST/SDK)

Hard limits you must recall: 5,120 characters per document (synchronous); 125,000 characters total per async request; F0 free tier = 5,000 transactions / 30 days, Standard S = 1,000 requests per minute. Sync operations POST to /language/:analyze-text?api-version=...; long-running operations (summarisation, health, custom, multi-task) POST to /language/analyze-text/jobs and return an Operation-Location header you poll.

There is no prebuilt topic-modelling API. Topics, themes, and open-ended taxonomy extraction are generative tasks — use a chat completion model with a prompt, not key phrase extraction.

Custom Language features

• Custom NER and custom text classification (single-label or multi-label) require an Azure Storage account for training documents, a project in Foundry/Language Studio, labelling, training (with automatic or manual train/test split), evaluation (precision, recall, F1, confusion matrix), then deployment to a named deployment before you can call it.
• Calls to custom features are always asynchronous and require projectName + deploymentName in the body.
• Custom features are not available on F0 at production scale and require a Language resource created with custom features enabled plus the storage connection.

Generative extraction and structured JSON

For entity/topic/summary extraction where the schema is domain-specific or the label set changes often, use a Foundry Model with prompting:

Structured Outputs requires gpt-4o (2024-08-06) or later and API version 2024-08-01-preview or later. strict: true requires additionalProperties: false and every property listed in required. Set temperature 0 (and optionally seed) for deterministic extraction.

Diagram caption: choosing between prebuilt Language skills, custom Language models, and generative prompting.

Common traps

• Key phrase extraction ≠ summarisation ≠ topic modelling. Key phrases return noun phrases only, with no scores.
• Extractive vs abstractive: "must use only wording from the original document / auditable" → extractive. "Must read as a concise new paragraph" → abstractive.
• sentenceCount applies to extractive summarisation; summaryLength applies to abstractive.
• Sync max is 5,120 characters per document, not per request; the per-request character cap is 125,000 for async.
• Custom NER cannot be called synchronously; distractors offer :analyze-text for custom models.
• JSON mode does not enforce a schema — only Structured Outputs does.
• Entity linking returns Wikipedia URLs; NER does not.

Worked scenario

A bank must pull loan-application fields (applicant name, loan amount, property type, risk flags) from free-text emails into a fixed JSON record consumed by a downstream API that rejects unknown fields. Prebuilt NER returns generic categories, not propertyType. Custom NER could work but needs labelled data and returns spans, not a document-level object. Correct answer: a Foundry chat model with Structured Outputs (json_schema, strict: true, additionalProperties: false) at temperature 0, because the requirement is guaranteed schema conformance with no unknown fields.