«Funziona bene» non è un criterio di rilascio. In un’applicazione generativa la stessa domanda può ricevere risposte diverse, e un giudizio dato su qualche output a campione è indistinguibile dall’impressione. Valutare significa fissare un insieme di casi, misurarli con criteri ripetibili e confrontare i numeri fra una versione e l’altra. Solo dopo ha senso toccare i parametri: altrimenti non sai se un cambiamento ha migliorato qualcosa o ha solo spostato il problema.

Cosa misurare, e con quale evaluator

Gli evaluator integrati di Foundry sono raggruppati in famiglie, e sapere quale risponde a quale sintomo è metà del lavoro. I general purpose (Coherence, Fluency) misurano la qualità linguistica. Quelli di similarità testuale (Similarity, F1 Score, BLEU, GLEU, ROUGE, METEOR) confrontano la risposta con una ground truth, quindi servono dove esiste una risposta attesa: traduzione, riassunto. Gli evaluator RAG coprono il caso più frequente: Retrieval e Document Retrieval sul recupero, Groundedness, Relevance e Response Completeness sulla risposta. Gli agent guardano il comportamento: Intent Resolution, Task Adherence, Tool Call Accuracy, Tool Selection. Quelli di rischio e sicurezza coprono odio e iniquità, contenuti sessuali, violenza, autolesionismo, materiale protetto, attacco indiretto (XPIA), vulnerabilità del codice e attributi non ancorati. Restano i grader di Azure OpenAI, gli evaluator rubric a criteri pesati e i custom.

Sulle risposte inventate va tenuta ferma una distinzione che ricorre nelle domande. Groundedness ha un giudice LLM: punteggio da 1 a 5, soglia predefinita a 3, richiede un deployment_name. Groundedness Pro (preview) usa il servizio Content Safety, è binario e non richiede un deployment. Entrambi sono valutazioni offline, su un dataset o su una run: cosa diversa dalla groundedness detection, filtro a runtime applicabile ai modelli ma non agli agenti. Groundedness misura la precisione (non inventare oltre il contesto), Response Completeness il richiamo (non tralasciare informazioni critiche).

Gli evaluator si combinano: su un’applicazione RAG, Retrieval più Groundedness più Relevance più sicurezza; su una agentica, Tool Call Accuracy più Task Adherence più Intent Resolution.

Eseguire la valutazione: dataset, criteri e target

Dal portale si scelgono dataset o target ed evaluator, ma dall’SDK il flusso è più ripetibile: un dataset JSONL con i campi che i criteri richiamano, l’oggetto di valutazione con i testing_criteria, infine la run.

testing_criteria = [
    {
        "type": "azure_ai_evaluator",
        "name": "groundedness",
        "evaluator_name": "builtin.groundedness",
        "initialization_parameters": {"deployment_name": model_deployment},
        "data_mapping": {
            "context": "{{item.context}}",
            "response": "{{sample.output_text}}",
        },
    },
]

I segnaposto sono tre e vanno saputi a memoria: {{item.campo}} punta a un campo del dataset, {{sample.output_text}} alla risposta generata dal target durante la run, {{sample.output_items}} all’output strutturato con le chiamate agli strumenti. Il target può essere un modello o un agente: nel primo caso il dataset contiene le domande e la risposta nasce al volo, nel secondo la run esercita l’agente vero. Gli evaluator di rischio e sicurezza girano sul servizio ospitato e non richiedono deployment_name; quasi tutti quelli con giudice LLM sì.

Infine, ogni evaluator dichiara i livelli supportati — turn sul singolo scambio (default) e conversation sull’intera interazione — e in una run non si mescolano livelli incompatibili.

Parametri e prompt: cosa cambia davvero il comportamento

L’ordine degli interventi segue il costo crescente. Prima il prompt: formato d’uscita esplicito, vincoli dichiarati, obbligo di dire «non lo so» quando il contesto non basta, uno o due esempi. Poi il contesto: recupero migliore, meno rumore, metadati per la citazione. Solo dopo i parametri, e alla fine il fine-tuning, che fissa stile e formato ma non aggiorna i fatti — quelli restano lavoro del RAG.

Sui parametri la distinzione è fra modelli classici e modelli di ragionamento. Su un modello classico temperature e top_p governano quanto si allarga il campionamento: si abbassano quando l’output deve essere stabile e verificabile, si alzano solo per compiti creativi, e non si muovono entrambi nello stesso esperimento, altrimenti non sai quale ha agito. Su un modello di ragionamento non esistono: si regola reasoning_effort e si dimensiona il tetto di token di output, ricordando che i token di ragionamento occupano il contesto e si pagano. Per quella famiglia bastano obiettivo, vincoli e formato atteso, senza prescrivere i passi intermedi, e reasoning_effort è una manopola di taratura, non la prima cosa da alzare quando la qualità cala.

Riflessione e auto-critica, con le dovute cautele

I cicli di auto-critica sono un secondo passaggio in cui il modello, o un altro modello, esamina la risposta appena prodotta rispetto a criteri espliciti e la corregge. Funzionano quando la critica ha qualcosa di oggettivo da controllare — cita solo le fonti fornite, rispetta lo schema, non viola un vincolo — e molto meno quando si chiede genericamente «è una buona risposta?», perché il modello tende a confermarsi.

Per la catena di ragionamento la piattaforma offre il reasoning summary sulla Responses API. Estrarre il ragionamento grezzo per altre vie non è supportato, può violare la policy d’uso accettabile e portare a limitazioni dell’accesso: nelle domande la risposta corretta è sempre il summary, mai l’aggiramento. Il summary non è disponibile quando è attiva l’orchestrazione multi-agente.

Resta il limite: l’auto-critica è una mitigazione, non una garanzia, e va misurata come ogni altra modifica, confrontando i punteggi prima e dopo su un dataset fisso. La stessa cautela vale per i punteggi di sicurezza, che la documentazione presenta come indicatori e non come prova di conformità. In produzione la valutazione continua con campionamento sul traffico reale scopre le regressioni che il dataset di test non aveva previsto.

Da ricordare per l’esame

  • Groundedness dà un punteggio 1-5 con soglia predefinita 3 e richiede deployment_name; Groundedness Pro usa Content Safety, è binario e non richiede un deployment.
  • I segnaposto del data mapping sono {{item.campo}}, {{sample.output_text}} e {{sample.output_items}}; il target può essere un modello o un agente.
  • Gli evaluator di rischio e sicurezza girano sul servizio ospitato: non serve indicare un deployment di modello.
  • Ordine degli interventi: prompt, contesto, parametri, fine-tuning. Il fine-tuning fissa stile e formato, non aggiorna i fatti.
  • Sui modelli di ragionamento non esistono temperature e top_p, e il ragionamento si ispeziona solo con il reasoning summary: estrarlo per altre vie non è supportato.