Fallback per Chatbot AI: Riconoscere e Gestire le Lacune di Conoscenza in Modo Sicuro

Un chatbot per siti web non deve rispondere a ogni singola domanda. L'importante è che riesca a riconoscere quando la base di conoscenza non offre un fondamento solido e che continui a essere d'aiuto per i visitatori. Riempire una lacuna con un'ipotesi apparentemente plausibile genera un problema di fiducia: un tempo di consegna errato, una regola di prodotto inventata o un'indicazione di supporto inappropriata possono causare più lavoro di quanto non faccia un limite chiaro e conciso.

Perché l'assenza di risultati è un vero e proprio problema di prodotto

In un chatbot AI basato su una knowledge base, ci sono almeno tre diverse cause per la mancata generazione di una risposta. In primo luogo, l'informazione potrebbe effettivamente mancare. In secondo luogo, potrebbe essere presente ma non venire trovata a causa della lingua, della formulazione, dei metadati o del ranking. In terzo luogo, l'informazione è reperibile ma non è sufficiente per fornire una risposta sicura. Nel flusso della chat questi casi appaiono simili a prima vista, ma nell'operatività quotidiana richiedono interventi differenti.

I sistemi di retrieval non valutano automaticamente se una risposta sia sostenibile dal punto di vista aziendale. La panoramica ufficiale sulla Retrieval-Augmented Generation in Azure AI Search descrive come combinare ricerca testuale e vettoriale per fornire fonti utili a una risposta. Questa combinazione migliora la ricerca, ma non sostituisce una regola che stabilisca quando un risultato possa considerarsi sufficiente. Per questo motivo, prima della generazione del testo, un chatbot necessita di una decisione chiaramente definita: rispondere, chiedere chiarimenti o inoltrare in modo sicuro.

Una mancata risposta (No-Answer) non è un vicolo cieco

Una risposta di fallback efficace non si limita a dire "Non ho informazioni al riguardo". Si compone di quattro elementi chiave: definisce il limite senza scuse tecniche, evita affermazioni infondate, offre una domanda di chiarimento precisa o un'alternativa sicura e, se necessario, indica la strada per parlare con un operatore umano. Il tono può essere cordiale, ma non deve nascondere l'incertezza.

• Limite: "Non riesco a trovare un'informazione attendibile al riguardo nelle fonti autorizzate."
• Contesto: "Si tratta di un ordine, di un contratto o di una configurazione tecnica?"
• Passo successivo: "Se mi fornisce il nome del prodotto, posso verificare nuovamente la documentazione disponibile."
• Handoff: "Per una verifica definitiva, inoltriamo la sua richiesta al team competente."

In questo modo la chat rimane utile senza inventare prezzi, scadenze, conseguenze legali o garanzie. In particolare quando si tratta di dati personali, pagamenti, offerte personalizzate e questioni legate alla sicurezza, la regola di handoff dovrebbe scattare tempestivamente. La guida già pubblicata sull'Human Handoff nel supporto via sito web aiuta a strutturare il passaggio all'operatore come un processo chiaro anziché come un'uscita d'emergenza.

Rendere operativa la decisione prima della risposta

I team non dovrebbero limitarsi a copiare una soglia arbitraria vista in una demo. Lo score restituito dalla ricerca è solo un segnale e può variare a seconda dell'indice, del modello, della lingua e del mix di query. La documentazione del Semantic Ranking evidenzia che la distribuzione degli score di re-ranking può oscillare. Per questo motivo, una soglia deve sempre essere legata a un set di dati testato e a una classe di errore concreta.

Una decisione adatta alla pratica può combinare diversi controlli. Esiste almeno una fonte all'interno di un'area di contenuto consentita? Corrisponde alla lingua e alla versione attuale del prodotto o del contratto? Contiene una giustificazione diretta per la risposta pianificata? I risultati principali sono in contraddizione tra loro? Solo quando questi criteri sono sufficientemente soddisfatti il generatore è autorizzato a formulare una risposta. In caso contrario, il bot pone una domanda mirata o attiva il fallback.

Esempio: Informazioni vincolanti sulla consegna

Se un utente chiede la data di consegna di un prodotto specifico, un articolo generico sulle spedizioni non è sufficiente. Il bot può spiegare di non riuscire a trovare un'informazione vincolante, chiedere il numero d'ordine o la variante del prodotto e indirizzare al supporto. Una risposta come "Il suo pacco arriverà domani" non sarebbe invece supportata dalla base di conoscenza. Lo stesso principio vale per garanzie, disdette, questioni di salute e accessi all'account: maggiore è il danno potenziale, più solida deve essere la prova.

Verificare il retrieval prima di riscrivere i contenuti

Una mancata risposta è spesso un ottimo segnale di misurazione. Prima che un team si metta a scrivere un nuovo prompt, dovrebbe esaminare l'intera catena: domanda originale, lingua rilevata, query di ricerca normalizzata, filtri applicati, risultati principali, versioni delle fonti utilizzate ed esito finale scelto. In questo modo si capisce chiaramente se manca un documento o se è la fase di retrieval a fallire.

1. Classificare domanda e intento in forma anonima (es. prodotto, supporto, account o note legali).
2. Confrontare le fonti attese con i risultati effettivamente recuperati.
3. Registrare nei log i filtri relativi a lingua, validità, autorizzazioni e versione del prodotto.
4. Verificare se i primi risultati supportano davvero la domanda o contengono solo termini simili.
5. Contrassegnare il caso come lacuna documentale, problema di retrieval, regola di sicurezza o handoff legittimo.

Per questi confronti è utile creare un piccolo Golden Set composto da domande reali e precedentemente ripulite. L'articolo sulla misurazione della qualità delle risposte dei chatbot AI spiega perché le domande critiche e rare non debbano scomparire all'interno di una valore medio. Includete intenzionalmente domande prive di una risposta corrispondente: solo così è possibile verificare se il chatbot reagisce in modo controllato anche quando non conosce la risposta.

Trasformare le lacune di conoscenza in un flusso di lavoro redazionale

Una singola conversazione non giustifica subito la creazione di una nuova FAQ. Tuttavia, diversi fallback sicuri dello stesso tipo possono indicare che un'informazione importante manca oppure è difficile da reperire. Per farlo è sufficiente un elenco essenziale in termini di dati, contenente intenzione, classe di errore, lingua interessata, ID delle fonti presenti e stato. I contenuti completi delle conversazioni, i nomi o i dati bancari non devono finire in una dashboard di analisi generale.

Lo specialista responsabile deciderà poi se integrare una FAQ, precisare una pagina di prodotto, migliorare i metadati o aggiornare il testo del fallback. Ogni integrazione necessita di un referente (owner), di una fonte e di una data. Per le informazioni critiche dal punto di vista temporale, come disponibilità o promozioni, è consigliabile impostare anche una data di scadenza. In questo modo il team evita che un articolo scritto con buone intenzioni si trasformi esso stesso nella prossima fonte obsoleta.

Non utilizzare il tasso di allucinazione come metrica di qualità

Un basso tasso di errori visibili può trarre in inganno se il bot evita la risposta troppo spesso. Al contrario, un alto tasso di risposta non è un successo se le risposte non sono supportate dalle relative fonti. È preferibile utilizzare un set ridotto di indicatori chiave (KPI): percentuale di richieste con risposta sicura, percentuale di fallback motivati, tasso di handoff per intenzione, tempo necessario per la decisione operativa, lacune ricorrenti e risultati di verifiche campionarie manuali. L'analisi deve poter essere filtrata per lingua, area di prodotto e classe di rischio.

Il NIST AI Risk Management Framework raccomanda di gestire i rischi nel contesto e di stabilire processi di misurazione e gestione. Per i team che gestiscono siti web, questo non significa salvare ogni singola conversazione, ma disporre di responsabilità chiare e criteri verificabili per risposte sicure.

La verifica dovrebbe inoltre adattarsi a situazioni di utilizzo reali. Una breve domanda inviata da smartphone contiene spesso meno contesto rispetto a una richiesta dettagliata da desktop. Refusi, abbreviazioni di prodotti e un mix di lingue sono input prevedibili, non casi eccezionali. Testate quindi non solo la domanda formulata in modo ideale, ma anche varianti con numeri d'ordine mancanti, nomi di prodotti multipli o indicazioni temporali poco chiare. Ogni variante deve generare una risposta documentata, una richiesta di chiarimento sensata o un handoff sicuro. Un fallback che funziona solo con domande di test formulate alla perfezione non offre alcuna protezione nell'uso quotidiano.

Altrettanto importante è il riscontro dal team di supporto. Quando gli operatori rispondono a una richiesta inoltrata, possono categorizzarne brevemente la motivazione: informazione mancante, informazione obsoleta, necessità di autorizzazione o richiesta che richiedeva una decisione individuale. Queste categorie collegano sito web, redazione della conoscenza e servizio clienti, senza trasformare la persona dietro la richiesta in un oggetto di analisi. Un controllo mensile delle categorie più frequenti è solitamente sufficiente per pianificare i miglioramenti prioritari.

Checklist per un fallback sicuro

• Le risposte appaiono solo con fonti pertinenti, approvate e aggiornate.
• Le soglie e le combinazioni di segnali sono state verificate tramite un Golden Set.
• Le classi di rischio elevate dispongono di regole dedicate per chiarimenti e passaggio all'operatore umano.
• I testi di fallback spiegano il limite senza simulare dettagli tecnici interni o una falsa sicurezza.
• I log contengono solo le informazioni diagnostiche strettamente necessarie, nel rispetto della minimizzazione dei dati.
• I casi ricorrenti vengono assegnati a un responsabile e tracciati con uno stato di miglioramento verificabile.
• Le nuove fonti vengono verificate prima della pubblicazione, dopo eventuali modifiche e alla scadenza.

Conclusione: limiti trasparenti migliorano la qualità delle risposte

Un chatbot AI professionale non cerca di rispondere a quante più domande possibile, ma fornisce solo ciò che è supportato dalla sua base di conoscenza verificata. La migliore risposta di fallback è concreta, utile e trasferisce le richieste vincolanti senza intoppi. Quando i team trattano i casi di mancata risposta come dati di test e segnali redazionali, sia il retrieval che i contenuti migliorano in modo misurabile. Iniziate con dieci domande fondamentali, dieci domande intenzionalmente prive di risposta e un flusso di handoff chiaro per ogni classe di rischio. Questo approccio crea una base solida prima che il chatbot assuma maggiori responsabilità.

Fonti

• Microsoft Learn: RAG and Generative AI in Azure AI Search
• Microsoft Learn: Semantic Ranking Overview
• Microsoft Learn: Create a Full-Text Query
• NIST: AI Risk Management Framework