Misurare sistemi di IA stocastici: perché un singolo test non dimostra nulla e come funzionano le verifiche multi-giro

Aggiornato a novembre 2026 · CODLAB Team

Risposta diretta: Poiché i modelli linguistici campionano distribuzioni di probabilità, una singola dimostrazione riuscita non garantisce affidabilità operativa. Valutare seriamente un sistema IA richiede esecuzioni ripetute per ciascun quesito (almeno tre giri indipendenti per stimare la varianza), metriche separate per recupero, fedeltà alle fonti e rifiuto, oltre a controlli di regressione ad ogni aggiornamento.

Quando le abitudini del software deterministico incontrano modelli probabilistici

Nell'ingegneria del software gestionale o industriale vale un presupposto deterministico: se una funzione di calcolo contabile restituisce l'importo atteso per un determinato input, mille esecuzioni successive con lo stesso stato produrranno esattamente lo stesso valore. Un singolo test automatico verde certifica quel percorso logico.

I modelli linguistici di grandi dimensioni (LLM) e gli assistenti RAG operano su basi diverse. Ad ogni passo di generazione il modello stima una distribuzione di probabilità sul token successivo. Anche impostando temperature basse (ad esempio temperature = 0.2 come nell'assistente di riferimento ragbot nel codice di codlab.de — demo pubblica di chat spenta da ottobre 2026 — o persino 0.0 nominale), minime variazioni nell'ordine dei passaggi recuperati, leggere riformulazioni dell'utente o non-determinismo in virgola mobile nei calcoli paralleli su GPU possono far sì che una condizione di sicurezza sia esplicitata al primo giro e omessa al secondo.

Nel lavoro di ricerca applicata e sviluppo di CODLAB su IA sovrana e controllo dei dati distinguiamo perciò nettamente tra dimostrazione e collaudo: un prototipo può convincere durante una presentazione di dieci minuti e manifestare comunque comportamenti erratici sui casi limite. Sia l'Ufficio federale tedesco per la sicurezza informatica (BSI, Generative KI-Modelle, v2.0, 2025) sia il profilo NIST per l'IA generativa (NIST AI 600-1, 2024) evidenziano che prove episodiche non sostituiscono un protocollo di misura strutturato.

1. Glossario e statistica delle prove multi-giro: pass@k contro pass^k

Eseguire una sola volta un sistema probabilistico equivale a osservare un campione di ampiezza uno. Nella letteratura di valutazione occorre distinguere con rigore due metriche opposte: pass@k (diffusa nella generazione di codice filtrata da test automatici, Chen et al., 2021, arXiv:2107.03374) misura la probabilità che almeno uno su k tentativi abbia successo (any) — utile solo quando un verificatore esterno scarta i tentativi errati prima di mostrarli. Quando invece l'utente riceve direttamente una singola risposta, la metrica operativa pertinente è la consistenza stretta pass^k (Yao et al., τ-bench, 2024, arXiv:2406.12045), che richiede il successo in tutti i k giri indipendenti (all).

Occorre dichiarare con altrettanta trasparenza il limite statistico dei piccoli campioni: se una pipeline rispetta una clausola critica con probabilità per singolo giro p = 2/3, tre esecuzioni indipendenti superano comunque tutte e tre la verifica con probabilità (2/3)³ ≈ 29,6%. Tre giri rappresentano quindi in CODLAB una soglia minima operativa di sviluppo per far emergere instabilità grossolane, non una garanzia statistica. Prima del rilascio servono campioni più ampi valutati con consapevolezza degli intervalli di confidenza, separando due esperimenti distinti:

• Ripetizioni identiche a contesto congelato (varianza di campionamento): la stessa identica query sullo stesso snapshot di recupero verifica se vincoli essenziali (scadenze, limiti tecnici, ruoli) e fonti citate reggono su tutti i k giri.
• Perturbazioni controllate tramite parafrasi (sensibilità all'input): misurate separatamente dalle ripetizioni pure, le riformulazioni realistiche (abbreviazioni, lessico operativo, refusi) quantificano la sensibilità congiunta di ricerca e generazione.

# Schema metodologico (check_domain_criteria è uno stub illustrativo per i validatori di dominio):
# Separazione netta tra almeno un successo (pass@k) e successo su tutti i giri (pass^k)
def evaluate_case_stability(pipeline_fn, test_case, k=3):
    outcomes = []
    for run_idx in range(k):
        result = pipeline_fn(test_case.query)
        outcomes.append({
            "run": run_idx + 1,
            "retrieved_urls": [s["url"] for s in result["sources"]],
            "grounded": result["grounded"],
            "passes_rubric": check_domain_criteria(result["answer"], test_case.criteria),
        })
    flags = [item["passes_rubric"] for item in outcomes]
    return {
        "any_passed_at_k": any(flags),   # logica pass@k: almeno 1 successo
        "all_passed_hat_k": all(flags),  # logica pass^k: tutti i k giri superati
        "pass_rate": sum(flags) / k,
        "runs": outcomes,
    }

2. Quattro dimensioni diagnostiche distinte al posto di un unico voto

Dichiarare una percentuale generica come «l'assistente è preciso all'X per cento» è tecnicamente fuorviante perché confonde guasti di natura opposta. In linea con framework di valutazione come RAGAS (Es et al., 2023/2024, arXiv:2309.15217), le architetture con auto-verifica (Asai et al., Self-RAG, arXiv:2310.11511) e la nostra nota Valutare un sistema RAG: separare retrieval e risposte, articoliamo la diagnosi su quattro dimensioni distinte (causalmente collegate nell'esecuzione, ma da misurare separatamente):

1. Completezza del recupero (Recall@k): il passaggio documentale indispensabile compare effettivamente tra i primi k frammenti estratti? Se manca qui, occorre intervenire su chunking, filtri o ricerca ibrida, non sul prompt.
2. Precisione del contesto (rapporto segnale/rumore): quanta parte del contesto passato al modello è davvero pertinente? Troppi paragrafi marginali aumentano il rischio di confondere procedure di linee o contratti simili.
3. Fedeltà alle fonti (Faithfulness / Grounding): ogni singola affermazione della risposta è rigorosamente deducibile dai passaggi estratti, senza aggiunte arbitrarie né omissioni di riserve documentate?
4. Accuratezza dell'astensione (Refusal Accuracy): di fronte a domande prive di copertura documentale, ambiti riservati o versioni in conflitto, il sistema dichiara correttamente il limite anziché indovinare?

Separare questi quattro indicatori permette decisioni ingegneristiche mirate: se un nuovo modello di embedding alza il Recall@5 ma trascina nel contesto bozze superate riducendo la fedeltà, il compromesso emerge immediatamente dai dati.

3. Uso consapevole e distorsioni del paradigma «LLM-as-a-Judge»

Poiché la revisione manuale di centinaia di risposte multi-giro a ogni modifica tecnica non scala, molti team impiegano un secondo modello linguistico come valutatore automatico («LLM-as-a-Judge»). Lo studio di Lianmin Zheng et al. ne ha documentato tanto l'utilità quanto le distorsioni sistematiche (Zheng et al., NeurIPS 2023, arXiv:2306.05685):

• Verbosity bias (preferenza per la prolissità): i giudici automatici tendono a premiare risposte lunghe e ben formattate anche quando una risposta sintetica è più rigorosa o quando il testo esteso introduce dettagli non supportati.
• Position bias (distorsione di posizione): nei confronti tra una risposta A e una risposta B, il verdetto cambia sensibilmente in base a quale opzione viene mostrata per prima.
• Self-enhancement bias: i modelli tendono a valutare con maggiore indulgenza testi generati dalla propria famiglia di modelli.

In CODLAB vincoliamo perciò la valutazione automatica a tre regole: primo, tutto ciò che è verificabile via codice viene controllato in modo deterministico (presenza degli URL attesi, attivazione del rifiuto, assenza di promesse o cifre vietate); secondo, i prompt di valutazione verificano criteri binari espliciti («La risposta specifica l'obbligo di approvazione scritta: Sì/No?») invece di voti soggettivi da 1 a 10; terzo, la griglia viene tarata su campioni validati da referenti di dominio invertendo sistematicamente l'ordine nei confronti a coppie.

4. Integrare gate deterministici e gate statistici

Un sistema IA in produzione comprende interfacce web, permessi, limiti di frequenza API, citazioni e accessibilità. Nelle nostre Engineering Notes la nota Playwright e axe: un test capace di diventare rosso esprime una regola cardine di CODLAB: un controllo automatico ha valore solo se è stato dimostrato che diventa rosso davanti a un difetto reale.

Applichiamo lo stesso principio combinando due livelli di sbarramento:

• Gate deterministici (tolleranza zero): isolamento dei dati tra tenant, protezione same-origin delle API, blocco deterministico sopra la soglia di distanza coseno, validità dei dati strutturati, navigazione da tastiera e contrasto visivo su mobile e desktop. Un singolo errore ferma il rilascio.
• Gate statistici su esecuzioni multiple: prima di promuovere modifiche a chunking, parametri di ricerca, prompt o versione del modello, un catalogo bloccato di domande reali, casi limite e contro-esempi viene eseguito almeno tre volte per quesito. Ogni regressione su avvertenze critiche o capacità di rifiuto blocca l'aggiornamento, e i nuovi casi emersi nell'uso vengono aggiunti stabilmente alla suite.

5. Esempio sintetico: cambio di modello senza procedere alla cieca

Nota metodologica: l'esempio seguente è interamente sintetico e illustra esclusivamente il metodo di verifica; non descrive un incarico cliente né metriche rilevate presso clienti.

Supponiamo che un laboratorio di analisi industriale utilizzi un assistente interno sulle proprie procedure di qualità e valuti il passaggio a un modello open-weights più compatto per ridurre i tempi di risposta sul server aziendale. Senza un protocollo strutturato si rischierebbe di provare dieci domande estemporanee e aggiornare il sistema sulla sola impressione di velocità.

Con una valutazione multi-giro il confronto segue passaggi verificabili:

1. Il catalogo di riferimento comprende 60 quesiti: 35 ricerche ordinarie con fonte univoca, 10 casi con deroghe recentemente aggiornate e 15 domande fuori perimetro che richiedono astensione.
2. Entrambi i modelli vengono eseguiti sullo stesso indice documentale congelato per tre giri indipendenti ciascuno (180 valutazioni per modello).
3. Nello scenario dimostrativo il modello più piccolo supera i casi ordinari al primo giro, ma nei giri successivi trascura talvolta l'etichetta «bozza superata» quando due versioni compaiono insieme nel contesto.
4. Il difetto viene intercettato prima del rilascio operativo, permettendo di escludere le bozze già tramite filtro SQL in PostgreSQL oppure di mantenere il modello più capiente.

Il presidio continuativo su aggiornamenti documentali, cambi di modello e test di regressione fa parte di Esercizio e manutenzione per sistemi IA. Per definire un piano di misura oggettivo su un progetto IA esistente o in valutazione, scriveteci tramite Contatto e primo colloquio.

Approfondimenti nella serie di ricerca: per esaminare come segmentazione e ranking influenzano a monte le metriche di recupero si veda lo studio su architettura RAG ibrida, chunking strutturale e reranking; per estendere i test di affidabilità pass^k alle chiamate a strumenti esterni rimandiamo all'analisi su agenti IA vincolati e guardrail deterministici.

Fonti primarie verificate

• Chen, M., Tworek, J., Jun, H. et al. (2021): Evaluating Large Language Models Trained on Code (arXiv:2107.03374).
• Yao, S., Shinn, N., Razavi, P. & Narasimhan, K. (2024): τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045).
• Es, S., James, J., Espinosa-Anke, L. & Schockaert, S. (2023/2024): RAGAS: Automated Evaluation of Retrieval Augmented Generation (EACL 2024, arXiv:2309.15217).
• Zheng, L. et al. (2023): Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023, arXiv:2306.05685).
• Asai, A. et al. (2023/2024): Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection (ICLR 2024, arXiv:2310.11511).
• National Institute of Standards and Technology (2024): Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1).
• Bundesamt für Sicherheit in der Informationstechnik / BSI (2025): Generative KI-Modelle — Chancen und Risiken für Industrie und Behörden, Versione 2.0 del 17.01.2025.

Guida operativa correlata (in tedesco): KI im Unternehmen einführen: Vom Arbeitsauftrag zur überprüfbaren Freigabe.