Quando un’applicazione generativa peggiora, raramente lo annuncia con un errore: continua a rispondere, solo che le risposte sono meno pertinenti, o inventate, o arrivano più tardi. Per accorgersene servono due sguardi distinti, uno sul modello e uno sul recupero, perché si diagnosticano in posti diversi. E siccome la soluzione tratta dati aziendali, la seconda metà del lavoro è chiudere gli accessi.

Prestazioni del modello, eventi di sicurezza e deriva

Azure Monitor raccoglie da solo le metriche dei deployment. Per la salute operativa contano ModelAvailabilityRate, la percentuale di chiamate non finite in errore server, e ModelRequests con la dimensione StatusCode, che dice se stai raccogliendo 429 o 5xx. Per la reattività ci sono TimeToResponse, il tempo prima che compaia la prima parte della risposta in streaming, e NormalizedTimeBetweenTokens, il ritmo di generazione: se la latenza totale cresce ma il tempo fra i token è stabile, il problema è a monte.

Le metriche però non contengono il contenuto. Per quello servono i log, instradati con un diagnostic setting verso Log Analytics: RequestResponse registra ogni richiesta con codice e latenza, Trace serve al debug, Audit raccoglie le operazioni amministrative.

La deriva è il caso più insidioso perché non produce alcun segnale operativo. Un deployment può aggiornarsi automaticamente alla nuova versione del modello, oppure solo alla scadenza della versione corrente, oppure restare fisso: nelle prime due modalità il comportamento cambia sotto i piedi dell’applicazione senza che nessuno abbia toccato il codice. Per accorgersene servono un dataset di riferimento rivalutato periodicamente e una continuous evaluation che campiona il traffico reale ed esegue evaluator sulle risposte prodotte. La stessa impostazione copre gli eventi di sicurezza, e la dashboard dell’agente mostra insieme token, latenza, tasso di successo delle run e punteggi di valutazione. Prerequisito non negoziabile: Application Insights collegato al progetto.

Ingestione, indice e rilevanza: dove si diagnostica il RAG

Davanti a una risposta sbagliata la prima domanda è sempre la stessa: il contesto recuperato conteneva la risposta? Se sì il problema è nella generazione, se no nel recupero, e le due cose si misurano con evaluator diversi.

Sul lato generazione stanno groundedness, che verifica se la risposta è ancorata al contesto senza inventare, e relevance, che verifica se risponde davvero alla domanda; response completeness (preview) guarda il rovescio, cioè se trascura informazioni presenti nella ground truth. I primi due danno un punteggio da 1 a 5 con soglia predefinita a 3 e richiedono un deployment_name, perché usano un modello come giudice; groundedness pro (preview) usa il servizio Content Safety e restituisce un booleano.

Sul lato recupero l’evaluator retrieval giudica con un LLM quanto i chunk recuperati siano pertinenti alla domanda, senza bisogno di ground truth. Quando hai etichette di rilevanza umane c’è invece document retrieval, evaluator composito che calcola fidelity, NDCG, XDCG, max relevance e holes: è lo strumento del parameter sweep, in cui generi risultati con diverse configurazioni di ricerca (vettoriale o semantica, top_k, dimensione dei chunk) e tieni quella con il retrieval migliore.

Sulla qualità dell’ingestione c’è una trappola da memorizzare: se il servizio di ricerca sta dietro private endpoint ma l’indexer resta in esecuzione multitenant, non riesce ad attraversarli, l’indicizzazione fallisce in silenzio e l’indice risulta vuoto. Il rimedio è impostare l’ambiente di esecuzione dell’indexer su Private.

Credenziali keyless, identità gestite e politiche di ruolo

Foundry accetta due metodi di autenticazione, Microsoft Entra ID e chiavi API, ma non sono equivalenti. Le chiavi sono segreti statici sull’intera risorsa: non esprimono l’identità di chi chiama, non si restringono a una singola azione e sono difficili da controllare a posteriori. Entra ID porta accesso condizionale, identità gestite, RBAC a privilegio minimo e attribuzione per principal. E alcune capacità con la chiave non funzionano affatto: Agent Service, evaluations e toolbox richiedono Entra ID.

In codice significa DefaultAzureCredential: in locale usa la sessione dell’Azure CLI, in Azure l’identità gestita del servizio.

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

credential = DefaultAzureCredential()
project = AIProjectClient(endpoint=ENDPOINT_PROGETTO, credential=credential)

Le identità sono quattro: utente, service principal, managed identity assegnata dal sistema e managed identity assegnata dall’utente, condivisibile fra più risorse. Sui ruoli, Foundry distingue control plane — risorse, progetti, deployment, connessioni, private endpoint — da data plane, cioè inferenza, agenti, valutazioni e tracing: i primi sono RBAC actions, i secondi dataActions. I ruoli predefiniti sono Foundry User per chi consuma, Foundry Project Manager per chi gestisce progetti e deployment, Foundry Account Owner e Foundry Owner per l’amministrazione; sono stati rinominati di recente, quindi negli script conviene referenziarli per ID. Chiusa la migrazione, si disabilita l’autenticazione locale: finché la chiave esiste, qualcuno la userà.

Isolamento di rete

L’accesso in ingresso si governa col flag di public network access: abilitato, ristretto a indirizzi selezionati, disabilitato. Disabilitandolo la risorsa si raggiunge solo tramite private endpoint: Azure crea un record nel sottodominio privatelink e una zona DNS privata, così i client nella rete virtuale usano la stessa stringa di connessione e risolvono l’IP privato. L’errore classico è proprio il DNS: da fuori, o con un resolver personalizzato non delegato, il nome continua a risolvere l’indirizzo pubblico.

In uscita il modello è la virtual network injection del client agent in una subnet delegata, con storage, ricerca e database anch’essi su endpoint privati. Alcuni strumenti però restano pubblici — grounding con Bing, ricerca web, grounding su SharePoint — e dove si pretende traffico interamente privato non sono utilizzabili. Completano il quadro il network security perimeter, che si adotta prima in modalità learning e poi enforced, e le customer-managed key in Key Vault, che richiedono soft delete e purge protection sul vault.

Da ricordare per l’esame

  • Due assi distinti: groundedness e relevance misurano la generazione, retrieval e document retrieval misurano il recupero.
  • La deriva nasce spesso dalla policy di aggiornamento di versione del deployment: la intercettano un dataset di riferimento rivalutato e la continuous evaluation sul traffico campionato.
  • Metriche automatiche in Azure Monitor; il contenuto solo con un diagnostic setting verso Log Analytics (RequestResponse, Trace, Audit).
  • In produzione si usa Microsoft Entra ID con DefaultAzureCredential: Agent Service, evaluations e toolbox non accettano chiavi API.
  • Con private endpoint l’indexer di ricerca va messo in esecuzione Private, altrimenti l’indice resta vuoto senza errori visibili.