22 – Quando l’IA dovrebbe dire “non ho elementi sufficienti”

Un assistente trova un documento che indica un tetto di spesa, ma non la spesa effettivamente sostenuta. Può produrre una cifra plausibile, chiedere un altro documento oppure dichiarare che gli elementi non bastano. La qualità del sistema dipende anche da questa scelta, non soltanto dalla capacità di formulare una risposta.

La domanda di questo episodio è precisa: come decidere quando rispondere e quando astenersi, senza trasformare la prudenza in un servizio che rinuncia a tutto? Progetteremo l’astensione come un comportamento verificabile: quali risposte conserviamo, quali errori evitiamo e quante risposte corrette perdiamo. La sicurezza del tono non entrerà come prova di correttezza.

In breve

• L’astensione per elementi insufficienti è diversa dal rifiuto di una richiesta vietata e dall’errore tecnico di un servizio.
• Un punteggio può aiutare a selezionare le risposte, ma non diventa una probabilità solo perché è compreso tra zero e uno.
• Occorre misurare insieme copertura, errori tra le risposte fornite e rinunce su domande a cui si poteva rispondere.
• Una soglia più alta riduce il numero delle risposte; non garantisce, da sola, una minore percentuale di errori.
• Una buona astensione indica che cosa manca e quale passo potrebbe rendere la domanda risolvibile.

Prima distinguere tre motivi per fermarsi

«Non ho elementi sufficienti» dovrebbe significare che il sistema non dispone di prove adeguate alla conclusione richiesta. Se invece una richiesta non è consentita dalle regole del servizio, il motivo è diverso. E se la ricerca fallisce per un timeout, non possiamo concludere che l’informazione non esista. Confondere questi casi impedisce di capire che cosa migliorare.

Nel nostro esempio documentale, una risposta utile potrebbe essere: «Il documento indica un massimo di 18.000 euro, ma non riporta il consuntivo. Non posso ricavare la spesa effettiva da questa fonte; serve il prospetto delle spese sostenute». Il sistema comunica il dato disponibile, limita la conclusione e propone un passo successivo. Non trasforma l’assenza di un dato nella prova che il valore sia zero.

Anche una richiesta di chiarimento è un esito distinto: «Di quale anno parliamo?» può risolvere un’ambiguità senza cambiare modello. Una risposta parziale, invece, deve separare le parti sostenute dalle fonti da quelle non risolvibili. Non basta aggiungere «potrei sbagliarmi» a una cifra priva di fondamento.

Generare la risposta e decidere se mostrarla

La ricerca sulla classificazione selettiva studia sistemi che possono rinunciare a una previsione per controllare il compromesso tra copertura e rischio. Geifman ed El-Yaniv lo affrontano per reti di classificazione. L’idea è pertinente, ma le garanzie di un metodo su specifiche ipotesi e dataset non si trasferiscono automaticamente a un assistente generativo con documenti, strumenti e risposte aperte.

Per un assistente proporrei due livelli. Il primo verifica condizioni necessarie: fonte accessibile, versione pertinente, presenza del dato e assenza di un conflitto decisivo irrisolto. Il secondo valuta se la risposta candidata supera i controlli del compito. Può usare verifiche deterministiche, un classificatore addestrato su esempi annotati o altri segnali validati. È una proposta progettuale, non un algoritmo universalmente affidabile.

La decisione può quindi appartenere all’applicazione, anche se il modello formula il messaggio finale. Un controllo può bloccare un importo che non compare nella fonte; non può però certificare da solo tutta la correttezza di una risposta lunga. Conviene definire l’unità di valutazione: l’intera risposta, un dato estratto o ciascuna affermazione.

Sicurezza verbale, ordinamento e calibrazione

Consideriamo tre cose diverse. Il tono «sono certo» è testo generato. Un punteggio di selezione serve a ordinare candidati o decidere quali mostrare. Una probabilità calibrata richiede invece che le frequenze di correttezza osservate siano coerenti con le probabilità dichiarate, nel contesto di valutazione specificato.

Per esempio, se molte risposte ricevono una probabilità vicina a 0,80, vorremmo osservare una correttezza vicina all’80% in quel gruppo, con campioni sufficienti e intervalli d’incertezza. Non significa sapere in anticipo quali singole risposte siano corrette. E non basta che la media globale coincida: possono restare differenze importanti tra tipi di domanda.

Il lavoro On Calibration of Modern Neural Networks di Guo e colleghi analizza la calibrazione nella classificazione e metodi per correggerla. Non autorizza a trattare una percentuale scritta liberamente da un chatbot come una probabilità validata. Kadavath e colleghi studiano l’autovalutazione dei modelli linguistici con formati e compiti precisi, trovando risultati incoraggianti ma anche difficoltà di generalizzazione della calibrazione a nuovi compiti.

Per decidere una soglia può essere utile anche un segnale che ordina bene i casi senza essere calibrato. Se invece vogliamo usare quel valore in un calcolo di rischio atteso, la sua interpretazione probabilistica diventa essenziale. La probabilità di un token o la somiglianza di un documento non coincidono automaticamente con la probabilità che la risposta completa sia corretta.

Tre misure da leggere insieme

Su N richieste, chiamiamo A il numero di risposte fornite ed E il numero di risposte errate tra quelle fornite. Per semplicità, nell’esempio ogni candidato sarà giudicato soltanto corretto o errato:

• Copertura = A / N: quanta parte delle richieste riceve una risposta.
• Rischio selettivo = E / A: quota di errori tra le risposte effettivamente mostrate, se A è maggiore di zero.
• Rinunce = N − A: richieste sulle quali il sistema si astiene.

Se A è zero, il rischio selettivo è non definito, non zero. Un assistente che tace sempre evita di mostrare errori, ma non risponde ad alcuna domanda. Per valutare l’utilità servono inoltre etichette sulla risolvibilità delle richieste: quante rinunce erano appropriate e quante hanno scartato una risposta che le fonti permettevano?

Un esempio numerico: la soglia non fa miracoli

Costruiamo dieci risposte candidate con punteggi e giudizi di correttezza interamente inventati. Non sono misure di un LLM. Il punteggio è un segnale sintetico di selezione: una risposta passa se il suo punteggio è almeno uguale alla soglia. L’esempio è costruito apposta con un errore al punteggio 0,96, per evitare l’illusione che tutti gli errori stiano in fondo alla graduatoria.

Alla soglia 0,80 forniamo 5 risposte: 4 corrette e 1 errata. La copertura è 50% e il rischio selettivo 20%. Salendo a 0,95 conserviamo soltanto due candidati, uno dei quali è ancora errato: la copertura scende al 20% e il rischio sale al 50%. Gli errori in valore assoluto non aumentano, ma la loro quota tra le risposte fornite sì. La soglia 1,10, superiore a tutti i punteggi, rappresenta l’astensione totale.

Non abbiamo dimostrato che una politica reale peggiori alzando la soglia: abbiamo costruito un controesempio alla pretesa che migliori sempre. Il comportamento dipende dalla qualità del segnale e dai dati. Anche una buona graduatoria deve essere verificata sul traffico che incontrerà davvero.

Ripetere il calcolo in Python

Questo codice usa soltanto la libreria standard. È stato eseguito per l’articolo: calcola i risultati della tabella e verifica tre casi limite. Il secondo valore di ogni coppia vale 1 per una risposta corretta e 0 per una errata. Non interroga un modello né stima una probabilità:

# Dati sintetici inventati, non misure di un LLM.
# (punteggio di selezione, risposta corretta)
data = [
    (.98, 1), (.96, 0), (.93, 1), (.87, 1),
    (.82, 1), (.74, 0), (.68, 1), (.57, 0),
    (.41, 1), (.22, 0),
]
def evaluate(threshold):
    kept = [ok for s, ok in data if s >= threshold]
    n = len(kept)
    errors = n - sum(kept)
    abstain = len(data) - n
    risk = errors / n if n else None
    loss = 3 * errors + abstain
    return n, sum(kept), errors, abstain, risk, loss
for t in [0, .5, .8, .95, 1.1]:
    print(t, evaluate(t))
assert evaluate(.8) == (5, 4, 1, 5, .2, 8)
assert evaluate(.95)[4] == .5
assert evaluate(1.1)[4] is None

L’ultima quantità restituita, loss, assegna per ipotesi un costo di 3 unità a ogni errore e di 1 a ogni rinuncia; una risposta corretta costa zero. I totali per le cinque soglie sono rispettivamente 12, 11, 8, 11 e 10. In questo campione e con questi pesi la soglia 0,80 ha il costo minore tra quelle provate. Cambiando i costi o i dati potrebbe cambiare la scelta. Non sono prezzi, stime operative o una raccomandazione di soglia universale.

Come scegliere la politica su dati reali

Occorre un insieme annotato con domanda, fonti disponibili, risposta candidata, esito di correttezza e possibilità di rispondere. Inserirei casi risolvibili, dati assenti, documenti contrastanti, date ambigue e guasti tecnici. Le categorie vanno tenute separate: un servizio non disponibile richiede un recupero operativo, non una dichiarazione di ignoranza sul contenuto.

Per addestrare un selettore, scegliere una soglia e valutare il risultato userei dati separati, evitando di ottimizzare e giudicare la politica sugli stessi esempi. Sul test riporterei copertura e rischio per più soglie, intervalli d’incertezza e risultati per categorie di domanda. Verificherei anche quante risposte corrette vengono perse e quante astensioni avvengono dove mancavano davvero le prove.

Il lavoro di Kamath, Jia e Liang sul question answering selettivo mostra perché il cambio di dominio è rilevante: un modello può essere troppo sicuro su richieste diverse da quelle note e una politica basata soltanto sulle sue probabilità può essere insufficiente. Sono risultati su modelli e dataset specifici, ma motivano un controllo pratico: una soglia valutata su un archivio non va trasferita senza verifica a un altro.

Un’astensione che aiuta a proseguire

Proporrei tre elementi nel messaggio: il limite riscontrato, ciò che resta sostenibile e il prossimo passo utile. Per esempio: «Ho trovato due versioni con scadenze diverse e non ho un’indicazione verificata di quale sia vigente. Posso confrontarle, ma non confermare una scadenza unica. Serve la versione ufficiale aggiornata». La frase descrive il problema, senza inventare certezze o nascondere il conflitto.

Se la risposta contiene più punti, possiamo fornire quelli verificati e sospendere gli altri, rendendo visibile la separazione. Una rinuncia parziale non dovrebbe diventare una risposta apparentemente completa. Chiedere un chiarimento, recuperare una fonte o inviare il caso a revisione ha un costo: anche quel percorso va misurato, fino all’esito finale per l’utente.

Una checklist prima della messa in esercizio

• Definire che cosa significa corretto per il compito e quale unità viene valutata.
• Separare assenza di prove, ambiguità, conflitti e indisponibilità tecnica.
• Verificare il selettore e la soglia su dati separati e rappresentativi, senza attribuire valore probabilistico a un punteggio non validato.
• Misurare errori, copertura e rinunce evitabili, anche per categorie di utenti e documenti pertinenti al servizio.
• Registrare motivo dell’astensione, fonti e versioni; riesaminare i risultati dopo cambi di modello, prompt, archivio o distribuzione delle richieste.

Una buona astensione non serve a far sembrare il modello prudente: serve a fermare una conclusione che le prove disponibili non sostengono, lasciando chiaro come proseguire.

DALLA MIA BIBLIOTECA

Ingegneria dell’IA di Chip Huyen, censito nel catalogo Libri del blog, offre il quadro per collegare qualità delle risposte, valutazione e costi del sistema. I riferimenti specifici per selezione e calibrazione sono i lavori primari seguenti.

Per approfondire

Fonti primarie, i risultati della ricerca sono distinti dalla simulazione didattica di questo articolo.

• Geifman ed El-Yaniv — Selective Classification for Deep Neural Networks, 2017.
• Guo e colleghi — On Calibration of Modern Neural Networks, ICML 2017.
• Kamath, Jia e Liang — Selective Question Answering under Domain Shift, ACL 2020.
• Kadavath e colleghi — Language Models (Mostly) Know What They Know, versione 4, 21 novembre 2022.

Episodi propedeutici: 02 — Perché un modello allucina; 19 — Prima del RAG; 21 — LLM come giudice.

← Torna al percorso Dentro l’IA