Il dominio dell’analisi del testo vale il 10-15% di AI-103, ma quasi ogni domanda che contiene è la stessa domanda travestita: con quale strumento risolvi questo compito? In Microsoft Foundry lo stesso risultato — tirare fuori entità, temi, un riassunto o un JSON pulito da testo libero — si ottiene per due strade diverse, e l’esame verifica che tu sappia scegliere invece di applicare sempre la stessa.

Prompt generativo o capacità preconfezionata

Un modello generativo distribuito su Foundry copre più compiti in una sola chiamata: gli descrivi lo schema che vuoi e ti restituisce entità, temi e sintesi insieme, adattandosi a un dominio che nessun catalogo aveva previsto. Una capacità preconfezionata di Azure Language in Foundry Tools fa invece una cosa sola, ma la fa in modo ripetibile e restituisce metadati che il modello generativo non produce spontaneamente: offset e lunghezza esatta del frammento riconosciuto, confidence score per singola entità, categorie fisse e documentate.

Da qui i criteri di scelta che l’esame si aspetta:

  • Serve la posizione nel testo — redigere, evidenziare, sostituire sul posto: capacità preconfezionata. Chiedere gli offset a un LLM è l’errore classico, perché li inventa in modo plausibile e sbagliato.
  • Lo schema è tuo e cambia col dominio, oppure servono più compiti in una chiamata sola: prompt generativo con output strutturato.
  • Serve determinismo e auditabilità, la stessa risposta per lo stesso input: preconfezionata.
  • Serve giudizio, riscrittura, registro linguistico: generativo.
  • Costo e latenza: le feature di Azure Language si fatturano a text record da 1.000 caratteri, il modello a token. Su volumi alti e compiti semplici la feature preconfezionata resta spesso più economica e più prevedibile.

Core e legacy: la distinzione che decide un progetto nuovo

Azure Language divide oggi le proprie funzionalità in due gruppi espliciti. Le core capabilities, raccomandate per il nuovo sviluppo, sono PII detection, language detection, named entity recognition (prebuilt e Custom NER) e Text analytics for health. Le legacy capabilities, supportate per le implementazioni esistenti, sono conversational language understanding, custom text classification, entity linking, key phrase extraction, orchestration workflow, question answering, sentiment analysis con opinion mining e summarization.

Non è una sfumatura editoriale: le pagine legacy portano un avviso di ritiro dal servizio fissato al 31 marzo 2029, con l’invito a migrare i carichi esistenti e a indirizzare i progetti nuovi sui modelli di Microsoft Foundry. Se lo scenario descrive un sistema da costruire adesso che deve riassumere o classificare testo, «usa summarization» o «usa custom text classification» non è più la risposta di default: lo diventa solo se il requisito è esplicitamente coperto da quella feature e da nulla d’altro.

Della NER prebuilt conviene ricordare il modello di output attuale: type è la classificazione più granulare (per «Seattle» il tipo è City), tags è una lista di etichette gerarchiche ciascuna con il proprio confidence score, e metadata è un oggetto che cambia forma a seconda del tipo rilevato. I parametri inclusionList ed exclusionList filtrano a granularità diverse: solo Location, oppure solo il tag GPE, oppure GPE escludendo Continent e CountryRegion. Le chiamate sincrone sono stateless; in asincrono i risultati restano recuperabili 24 ore.

I limiti contano perché determinano il chunking a monte: 5.120 caratteri per documento in sincrono, 125.000 caratteri complessivi in asincrono su un massimo di 25 documenti, 1 MB per richiesta, e un tetto di documenti per richiesta che cambia per feature (5 per NER e PII, 10 per sentiment e key phrase extraction, 1000 per language detection).

Output strutturato che arriva sempre

Quando la scelta cade sul prompt generativo, il punto non è scrivere il prompt: è vincolare la forma della risposta con uno schema, così che il parsing a valle non sia una scommessa.

schema = {
    "type": "object",
    "properties": {
        "fornitore": {"type": "string"},
        "importo_totale": {"type": "number"},
        "temi": {"type": "array", "items": {"type": "string"}},
        "riassunto": {"type": "string"},
    },
    "required": ["fornitore", "importo_totale", "temi", "riassunto"],
    "additionalProperties": False,
}

risposta = client.chat.completions.create(
    model="il-tuo-deployment",
    messages=[
        {"role": "system",
         "content": "Estrai solo ciò che è presente nel testo. Nessun campo inventato."},
        {"role": "user", "content": documento},
    ],
    response_format={
        "type": "json_schema",
        "json_schema": {"name": "estratto", "schema": schema, "strict": True},
    },
)

Tre errori ricorrenti: mandare al modello un documento più lungo della finestra di contesto senza segmentarlo; non prevedere il caso «campo assente», che spinge il modello a riempirlo comunque; e non valutare mai il risultato. Un’estrazione generativa va misurata come qualsiasi altra componente, con gli evaluator di Foundry su un dataset di riferimento.

Sentiment, tono, sicurezza e dati sensibili

Questi quattro segnali sembrano lo stesso problema e non lo sono. Sentiment analysis assegna le etichette positive, neutral e negative con confidence fra 0 e 1, e lo fa sia a livello di documento sia a livello di singola frase; l’opinion mining è la sua variante aspect-based, che collega il giudizio all’aspetto specifico di cui si parla. Entrambe stanno però fra le capacità legacy con ritiro al 2029.

Il tono non ha un’API dedicata: si ottiene con un prompt generativo guidato da una rubrica esplicita, e si verifica con una valutazione, non a occhio. Le safety issues non sono affatto un compito di Azure Language: la classificazione di contenuto dannoso, i prompt shield e il blocco appartengono ai guardrail di Microsoft Foundry e a Content Safety, e agiscono in punti di intervento definiti sul flusso dell’applicazione.

Il contenuto sensibile ha invece una capacità core dedicata, PII detection, con tre feature type da non confondere. Text PII lavora su stringhe in modo sincrono ed è il caso di prompt, log e ticket. Conversation PII lavora su input a turni ed è asincrona, con un limite di 1.000 caratteri per turno. Document-based PII lavora su file .pdf, .docx e .txt, è asincrona su storage e restituisce il documento redatto preservando la struttura più i metadati in JSON.

Da ricordare per l’esame

  • Se il requisito parla di offset, span o redazione sul posto, la risposta è una capacità preconfezionata di Azure Language, non un prompt generativo.
  • Core: PII detection, language detection, NER prebuilt e custom, Text analytics for health. Tutto il resto è legacy con ritiro il 31 marzo 2029 e migrazione consigliata verso i modelli di Microsoft Foundry.
  • NER usa type più tags più metadata, e si filtra con inclusionList ed exclusionList a granularità diverse.
  • Limiti da tenere a mente: 5.120 caratteri per documento in sincrono, 125.000 su massimo 25 documenti in asincrono, 1 MB per richiesta, fatturazione a text record da 1.000 caratteri.
  • Sentiment, tono, safety e PII sono quattro problemi distinti: il terzo appartiene ai guardrail di Foundry, non ad Azure Language.