Cos’è Conversational Language Understanding
Conversational Language Understanding (CLU) è la feature di Azure AI Language che estrae il significato dal linguaggio naturale: classifica ogni utterance (frase dell’utente) in un intent e individua le entity rilevanti. È il motore di NLU che alimenta bot, assistenti virtuali e IVR: trasforma “prenota un volo per Roma domani” nell’intent BookFlight con entity destination=Roma e date=domani.
CLU è il successore ufficiale di LUIS (Language Understanding), ora deprecato: i nuovi progetti si creano in CLU tramite Language Studio e i modelli LUIS esistenti vanno migrati. Rispetto a LUIS, CLU usa modelli basati su transformer multilingue (training in una lingua, inference in molte), unifica tutto in un’unica risorsa Language e si integra nativamente con l’orchestration.
Intent ed entity
Intent
Un intent rappresenta lo scopo dell’utente. Si definisce fornendo utterance di training etichettate e variate: più esempi diversi (sinonimi, forme brevi/lunghe, ordini di parole differenti) migliorano la generalizzazione. Esiste sempre l’intent None per catturare frasi fuori dominio.
Entity
Le entity sono i dati estratti dall’utterance. CLU supporta più tipi di componenti, combinabili:
- Learned — apprese dagli esempi; richiedono di etichettare manualmente le occorrenze nelle utterance. Ideali per concetti dipendenti dal contesto (es. il nome di un prodotto).
- List — enumerazione chiusa di valori e sinonimi (es. città, categorie). Match esatto, nessun training necessario.
- Prebuilt — entity già pronte (
quantity,datetime,email,number,URL, ecc.) per dati comuni. - Regex — pattern deterministici (codici ordine, SKU, targhe).
Un’entity può combinare più componenti con logica Require all components (intersezione, alta precision) oppure Any component (unione, alto recall).
Training, test e deployment
Il ciclo è: etichettare le utterance → train del modello → valutare. In training si sceglie lo split dei dati (automatico 80/20 o set manuale). Dopo il training la scheda di valutazione mostra precision, recall, F1 e la confusion matrix, indispensabili per capire quali intent si confondono.
Il modello si pubblica poi come deployment con un nome (es. production, staging): questo permette di aggiornare il modello dietro un endpoint stabile senza toccare l’app. L’inference avviene via REST/SDK sull’endpoint della risorsa Language indicando project name e deployment name.
Integrazione con un bot
In un’app tipica (es. Bot Framework / Azure AI Bot Service), il bot invia il testo utente a CLU, riceve top intent + entity e instrada la logica. Il codice usa il Language SDK (ConversationAnalysisClient) o la REST API, autenticandosi con chiave/endpoint oppure con Microsoft Entra ID.
Orchestration workflow
L’orchestration workflow è un progetto CLU speciale che fa da router verso più progetti a valle. Un intent di orchestration può puntare a:
- un altro progetto CLU (dominio di intent diverso);
- un progetto di Custom Question Answering (per rispondere da una knowledge base / FAQ);
- un altro modello Language.
Così, con un unico endpoint, l’utente può porre domande gestite dalla QnA e comandi gestiti da CLU: l’orchestrazione classifica l’input e lo delega al progetto corretto. È la scelta giusta quando l’app copre domini eterogenei e vuoi evitare un unico modello monolitico sovraccarico di intent.
Trappole tipiche d’esame
- “Devo creare un nuovo modello NLU o migrare da LUIS” → usa CLU in Azure AI Language; LUIS è deprecato e non va proposto per nuovi progetti.
- “Il modello non riconosce un’entity contestuale (nome prodotto variabile)” → serve una learned entity con utterance etichettate manualmente; una list entity coprirebbe solo valori noti in anticipo.
- “Un chatbot deve gestire sia comandi sia FAQ da knowledge base” → usa un orchestration workflow che instrada tra progetto CLU e Custom Question Answering.
- “Accuratezza bassa o intent confusi tra loro” → aggiungi utterance di training più numerose e variate e ribilancia gli intent; verifica precision/recall e confusion matrix nella valutazione.
- “Voglio aggiornare il modello senza cambiare l’app” → ripubblica un nuovo modello sullo stesso deployment name; l’app punta a project + deployment, non alla versione interna del modello.