Chatbot / IA conversazionale / Modelli linguistici di grandi dimensioni / Alfabetizzazione sull'IA
Come funzionano davvero i chatbot: regole, recupero delle informazioni, LLM, strumenti e passaggio a un operatore umano
Una conversazione con un chatbot può sembrare semplicissima fino al momento in cui qualcosa va storto. Chiedi dove si trova un pacco. Il bot ripete una generica politica di consegna. Fornisci il numero dell'ordine. Te lo chiede di nuovo. Dopo tre cicli, la piccola finestra di chat che prometteva comodità è diventata una porta chiusa tra te e la risposta.
L'esperienza opposta passa quasi inosservata. Il chatbot riconosce che vuoi tracciare un ordine, acquisisce il numero corretto, consulta un dato aggiornato, spiega il risultato in una frase e propone l'intervento di una persona se il caso è insolito. La differenza non consiste semplicemente nel fatto che un bot disponga di più intelligenza artificiale. Un sistema conversazionale ha un compito più chiaro, uno stato meglio gestito, strumenti affidabili, limiti più sicuri e un percorso di recupero pianificato.
Questa guida guarda dietro la finestra della chat. Spiega le principali tipologie di chatbot, segue un messaggio attraverso un'architettura reale e mostra perché la fluidità del linguaggio è solo una parte di una conversazione affidabile.
Che cos'è un chatbot?
Un chatbot è un software che scambia messaggi con una persona tramite testo, voce o un altro canale conversazionale. Interpreta un input, decide che cosa deve accadere dopo e restituisce una risposta o esegue un'azione. Questa ampia definizione comprende un menu fisso in un widget di assistenza, un flusso vocale che raccoglie un numero di account, un assistente informativo che cerca nei documenti e un sistema basato su un modello linguistico capace di formulare risposte aperte.
La conversazione è l'interfaccia, non la tecnologia sottostante. Due chatbot possono sembrare identici pur funzionando in modi completamente diversi. Uno segue un albero decisionale. Un altro riconosce un intento e chiama un webhook. Un terzo recupera documenti e chiede a un modello linguistico di grandi dimensioni di formulare una risposta. I sistemi più utili spesso combinano diversi approcci.
La lezione di ELIZA, sessant'anni dopo
Nel 1966 Joseph Weizenbaum pubblicò ELIZA, un programma per la conversazione in linguaggio naturale. Il suo noto script DOCTOR utilizzava schemi e trasformazioni per convertire parti delle affermazioni dell'utente in una risposta. Una frase come “Sono infelice” poteva essere riconosciuta, riorganizzata e riproposta sotto forma di domanda. Lo scambio poteva sembrare attento, anche se il programma disponeva di poche informazioni sulla vita della persona e non utilizzava alcun modello linguistico moderno.
ELIZA è ancora rilevante perché le persone reagiscono socialmente al linguaggio. Una domanda posta al momento giusto, una frase comprensiva o una risposta sicura possono creare un'impressione di comprensione superiore a quella consentita dai meccanismi sottostanti. I modelli moderni sono molto più capaci, ma l'interfaccia favorisce ancora lo stesso errore: giudicare ciò che un sistema sa in base alla naturalezza con cui si esprime.
Un chatbot professionale dovrebbe quindi conquistare la fiducia completando correttamente i compiti, mostrando chiaramente i propri limiti e consentendo di recuperare dagli errori. La personalità può migliorare un'interazione, ma non può sostituire l'accesso alle informazioni corrette o un processo sicuro.
Tre principali architetture per chatbot
I chatbot sono più facili da comprendere se distinguiamo tre famiglie architetturali. Non si tratta di generazioni rigide in cui ciascuna novità rende obsolete le precedenti. Sono strumenti con punti di forza diversi.
1. Regole e flussi di conversazione
Un chatbot basato su regole segue percorsi progettati in anticipo. Può mostrare pulsanti, riconoscere parole chiave, compilare un modulo o passare da uno stato all'altro quando vengono soddisfatte determinate condizioni. La logica può essere esplicita: se l'utente vuole modificare una data di consegna, il sistema raccoglie il numero dell'ordine, verifica se il pacco è idoneo, mostra le date disponibili e chiede conferma.
Le regole sono preziose quando il processo è circoscritto e le azioni consentite sono note. Rendono più facili da controllare le procedure di conformità e le azioni distruttive. Il loro limite emerge quando le persone formulano richieste in modi imprevisti o escono dal percorso progettato. Un buon sistema di regole ha bisogno di soluzioni alternative, correzioni e vie d'uscita, non soltanto di un percorso ideale perfetto.
2. Riconoscimento degli intenti e recupero delle informazioni
Un sistema basato sugli intenti stima ciò che l'utente sta cercando di fare, quindi estrae dettagli utili chiamati entità o parametri. “Traccia l'ordine 4821” può essere associato a un intento di tracciamento dell'ordine e a un parametro contenente il numero dell'ordine. La documentazione di Dialogflow sugli intenti di Google Cloud descrive questo schema come il confronto tra un input e frasi di addestramento per trovare una corrispondenza.
Il recupero delle informazioni aggiunge un livello di ricerca. Invece di rispondere soltanto con una frase predefinita, il sistema trova passaggi pertinenti, voci di policy, articoli di assistenza o record. Un chatbot basato sul recupero può citare direttamente una risposta nota oppure passare il materiale selezionato a un generatore. La qualità dipende da ciò che è stato indicizzato, da come è stata formulata la query, dall'aggiornamento della fonte e dalla capacità del sistema di trovare il passaggio corretto.
3. Modelli linguistici, strumenti e sistemi ibridi
Un modello linguistico di grandi dimensioni può interpretare formulazioni diverse e produrre risposte naturali per una gamma molto più ampia di input. Può riassumere, spiegare, tradurre, porre una domanda di chiarimento o trasformare l'output strutturato di uno strumento in un testo leggibile. Per una spiegazione più approfondita della generazione dei token e dei limiti dei modelli, consulta Che cos'è davvero l'IA?.
Il modello ha comunque bisogno di assistenza per conoscere fatti aggiornati e compiere azioni. Non può sapere dove si trova ora l'ordine 4821 se l'applicazione non fornisce questa informazione tramite il contesto, il recupero delle informazioni o uno strumento. Non può emettere in sicurezza un rimborso solo perché è in grado di scrivere la frase “Il rimborso è stato completato”. L'applicazione deve collegare il modello a servizi autorizzati e verificare il risultato.
Per questo molti chatbot moderni sono ibridi. Le regole proteggono i passaggi critici. Il recupero fornisce conoscenze aggiornate. Un modello linguistico gestisce un linguaggio flessibile. Gli strumenti leggono o modificano uno stato esterno. Il codice convenzionale convalida autorizzazioni e output. Una persona gestisce i casi che richiedono giudizio o autorità.
Che cosa accade durante un turno di conversazione con un chatbot
Seguiamo un semplice messaggio: “Dov'è l'ordine 4821?”. Un'implementazione reale può combinare o rinominare i passaggi, ma le responsabilità sottostanti restano riconoscibili.
- Ricevere e normalizzare l'input. Il canale può fornire testo digitato, parlato trascritto, selezioni tramite pulsanti, lingua o metadati della sessione.
- Identificare l'obiettivo. Il sistema determina se la richiesta riguarda il tracciamento, l'annullamento, il pagamento, un altro argomento o qualcosa che non è supportato.
- Estrarre i dettagli necessari. In questo caso, il numero dell'ordine è 4821. Se manca o è ambiguo, il bot dovrebbe porre una domanda invece di inventarlo.
- Controllare lo stato della conversazione. Il sistema determina ciò che già conosce, quali informazioni è autorizzato a conservare e quale passaggio è attivo.
- Recuperare informazioni o chiamare uno strumento. Un servizio di tracciamento restituisce lo stato attuale. Il chatbot non dovrebbe ricavare tale stato da schemi linguistici.
- Comporre e convalidare la risposta. L'applicazione trasforma il risultato in un linguaggio chiaro, controlla i campi obbligatori ed evita di esporre dati interni o personali.
- Rispondere, recuperare o passare la conversazione a un operatore. Un risultato normale viene restituito all'utente. Un errore, un caso non supportato o la richiesta di parlare con una persona seguono un percorso diverso.
Google Cloud usa il termine fulfillment per indicare la parte di un turno di conversazione che restituisce una risposta statica, chiama un webhook per ottenere informazioni dinamiche, imposta parametri o compie un'azione. La documentazione di Dialogflow sul fulfillment introduce una distinzione importante: comprendere la richiesta e soddisfarla sono responsabilità separate.
Lo stato della conversazione non è memoria umana
Un chatbot ha bisogno di uno stato sufficiente per evitare di ricominciare da capo a ogni turno. Lo stato della sessione potrebbe registrare che il compito attuale è tracciare un pacco, che il numero dell'ordine è 4821 e che l'utente ha già confermato un codice postale. Senza stato, la domanda “E il secondo pacco?” non avrebbe alcun riferimento utilizzabile.
Quello stato è costituito da dati progettati, non da un ricordo umano. Alcuni sistemi conservano soltanto la sessione corrente. Altri memorizzano la cronologia della conversazione, riepiloghi, preferenze o informazioni sull'account. Un modello può inoltre ricevere solo una parte di una lunga conversazione, perché il suo contesto ha una capacità finita o perché l'applicazione limita deliberatamente ciò che viene inviato.
Gli utenti non dovrebbero presumere che un chatbot dimentichi quando si chiude una finestra o che ricordi solo perché parla come se lo facesse. Conservazione, collegamento all'account, uso per l'addestramento ed eliminazione dipendono dal servizio specifico. Prima di condividere informazioni sensibili, consulta l'informativa sulla privacy del servizio e usa soltanto i dati strettamente necessari al compito.
Come funziona la generazione aumentata dal recupero
I parametri di un modello linguistico sono un luogo poco adatto a conservare una politica sui resi che cambia spesso. La generazione aumentata dal recupero, generalmente abbreviata in RAG, affronta il problema cercando materiale pertinente in una raccolta esterna e inserendo i passaggi selezionati nel contesto del modello prima che questo formuli la risposta.
L'articolo originale sulla Retrieval-Augmented Generation combinava un generatore preaddestrato con una memoria non parametrica esplicita recuperata da un indice. Oggi lo schema generale compare in molti assistenti informativi: prima la ricerca, poi la generazione.
Una pipeline RAG utile presenta almeno quattro possibili punti di errore. La raccolta di origine può essere incompleta. Il documento può essere obsoleto. Il recupero può selezionare un passaggio irrilevante. Il generatore può interpretare male o abbellire ciò che ha ricevuto. Le citazioni sono utili solo se rimandano alla fonte esatta che sostiene l'affermazione e se l'utente può consultarla.
La RAG migliora quindi l'accesso a conoscenze aggiornate e verificabili, ma non garantisce la verità. Va valutata nel suo insieme: la fonte corretta è entrata nell'indice, la ricerca l'ha trovata, la risposta è rimasta entro i limiti delle prove disponibili e la citazione sostiene davvero l'affermazione?
Risposte e azioni richiedono livelli di controllo diversi
Un chatbot che spiega una politica di rimborso non equivale a un chatbot che emette un rimborso. Il secondo sistema può modificare uno stato esterno. Può chiamare un servizio per gli account, un calendario, un sistema di pagamento, uno strumento di messaggistica o il controllo di un dispositivo. Questa capacità viene talvolta descritta come agentività, ma la domanda pratica è più semplice: che cosa può fare questa applicazione oltre a produrre testo?
Un percorso sicuro per le azioni dovrebbe mantenere i controlli importanti al di fuori del testo prodotto dal modello:
- Autenticare l'utente e confermare che l'account o la risorsa gli appartengano.
- Autorizzare l'azione specifica invece di concedere al chatbot un accesso esteso.
- Convalidare con codice convenzionale gli argomenti degli strumenti, gli importi, le destinazioni e gli intervalli consentiti.
- Richiedere una conferma esplicita prima di azioni irreversibili o costose.
- Restituire il risultato verificato dello strumento invece di presumere che un'azione sia riuscita.
- Registrare informazioni sufficienti per indagare sugli errori senza esporre dati sensibili non necessari.
L'illustrazione mostra un'architettura di riferimento, non una promessa riguardante uno specifico chatbot. Un modello linguistico può suggerire quale strumento chiamare, ma l'applicazione circostante dovrebbe decidere se la chiamata è consentita. Una maggiore autonomia aumenta l'importanza di limiti delle autorizzazioni, rate limit, conferme, monitoraggio e supervisione umana.
Prompt injection: quando il contenuto cerca di trasformarsi in un'istruzione
Un chatbot che usa strumenti o recupera informazioni può leggere testi forniti da utenti, siti web, email o documenti. Alcuni di questi testi possono contenere istruzioni rivolte al modello, per esempio richieste di ignorare le regole precedenti, rivelare informazioni nascoste o chiamare uno strumento in modo non previsto. Questo fenomeno è chiamato prompt injection.
L'OWASP GenAI Security Project considera la prompt injection uno dei principali rischi per le applicazioni basate su modelli linguistici. Il problema fondamentale è che i modelli elaborano le istruzioni e i contenuti ordinari attraverso lo stesso canale linguistico. Un documento non attendibile può somigliare grammaticalmente a un'istruzione proveniente dall'applicazione.
Nessun prompt può sostituire i controlli a livello di sistema. Le applicazioni dovrebbero considerare non attendibili i contenuti recuperati e quelli forniti dagli utenti, limitare gli strumenti disponibili, applicare il principio del privilegio minimo, convalidare le chiamate agli strumenti, isolare le operazioni sensibili e richiedere conferma quando le conseguenze sono importanti. Il modello non dovrebbe ricevere una chiave universale soltanto perché l'interfaccia è conversazionale.
Perché i chatbot danno risposte errate o frustranti
Fraintendono la richiesta
Il linguaggio è ambiguo. “Chiudi il mio account” potrebbe significare uscire, eliminare un profilo, annullare un abbonamento o chiudere un conto finanziario. Un chatbot affidabile riconosce quando il costo di un'ipotesi errata è superiore a quello di una domanda di chiarimento.
Non dispongono delle informazioni necessarie
Un modello può conoscere il vocabolario generale delle spedizioni ma non avere accesso al record dell'ordine dell'utente. Il recupero può non trovare la policy pertinente. Uno strumento può non essere disponibile. La risposta corretta consiste nel dichiarare il limite o usare una soluzione alternativa, non nel colmare il vuoto con una storia plausibile.
Generano informazioni false con sicurezza
Il NIST definisce confabulazione un contenuto generativo falso o errato presentato con sicurezza. Il suo Profilo per l'IA generativa osserva che questo comportamento può includere ragionamenti o citazioni inventati. La fluidità rende questi errori più difficili da notare, non meno importanti.
Perdono lo stato o mantengono quello sbagliato
Una sessione può dimenticare un dettaglio, confondere due ordini, conservare un'ipotesi errata o applicare a un compito informazioni provenienti da un altro. Lo stato dovrebbe essere abbastanza visibile da poter essere corretto e abbastanza circoscritto da evitare commistioni indesiderate.
Non offrono una via d'uscita efficace
Il ciclo più esasperante è spesso un errore di progettazione. Il bot ha raggiunto il limite delle proprie capacità ma continua a riformulare la stessa risposta. Una soluzione alternativa dovrebbe cambiare percorso: chiedere un solo dettaglio mancante, mostrare un'opzione supportata, aprire una pratica o trasferire la conversazione.
Il passaggio a una persona fa parte del sistema, non è un'ammissione di sconfitta
Alcune richieste sono ambigue, emotive, eccezionali o comportano conseguenze importanti. Altre richiedono un'autorità che il chatbot non dovrebbe avere. Uno specialista umano può interpretare il contesto, negoziare un'eccezione, assumersi la responsabilità o riconoscere che il processo documentato non è adatto al caso.
Il passaggio funziona solo se porta con sé il contesto. La persona dovrebbe ricevere l'obiettivo dell'utente, i dettagli confermati, i risultati pertinenti degli strumenti e il motivo dell'escalation. Costringere l'utente a ripetere l'intera conversazione trasforma un trasferimento tecnicamente riuscito in un'esperienza scadente.
La documentazione di Dialogflow sul passaggio a un operatore umano considera il passaggio una transizione esplicita. Questo principio di progettazione va oltre una singola piattaforma: l'escalation dovrebbe essere un percorso verificato con una responsabilità definita, non una frase improvvisata dal bot quando rimane bloccato.
Come valutare la qualità di un chatbot
È facile preparare una demo convincente. Un chatbot affidabile deve gestire le normali variazioni e gli errori visibili. La valutazione dovrebbe partire dal compito che l'utente desidera completare.
- Completamento del compito: l'utente ha ottenuto la risposta o completato correttamente l'azione?
- Ancoraggio alle fonti: le affermazioni fattuali derivavano dalla fonte fornita o dal risultato verificato di uno strumento?
- Recupero dagli errori: le informazioni mancanti, le mancate corrispondenze e gli errori degli strumenti hanno portato a un passo successivo utile?
- Sicurezza: autorizzazione, conferma, trattamento dei dati e limiti degli strumenti hanno resistito a input avversari?
- Qualità del passaggio: la conversazione ha raggiunto la persona giusta con un contesto sufficiente?
- Lingua e accessibilità: il flusso ha funzionato nelle lingue supportate, con diversi stili di digitazione, condizioni vocali, navigazione da tastiera e tecnologie assistive?
- Impegno dell'utente: quanti turni, ripetizioni e correzioni sono stati necessari per completare il compito?
Le conversazioni di test dovrebbero includere più del percorso ideale. Usa numeri d'ordine mancanti, due numeri nello stesso messaggio, errori di ortografia, richieste non supportate, documenti obsoleti, timeout degli strumenti, richieste di cambiare argomento, richieste dirette di parlare con una persona e istruzioni dannose nascoste nei contenuti recuperati. La guida alla progettazione degli agenti di Google Cloud raccomanda analogamente una progettazione iterativa e casi di test, invece di tentare di progettare ogni percorso in una sola volta.
Come usare un chatbot senza rinunciare al proprio giudizio
- Esponi l'obiettivo e il minimo contesto pertinente. Una richiesta precisa riduce i turni non necessari.
- Non incollare password, codici di autenticazione, credenziali di pagamento, chiavi private o documenti sensibili, a meno che lo specifico servizio attendibile non richieda e protegga esplicitamente tali dati.
- Distingui una spiegazione da un risultato in tempo reale. Chiedi se la risposta proviene da un record aggiornato, da una fonte citata o dalle conoscenze generali del modello.
- Apri le citazioni e verifica le affermazioni che comportano conseguenze importanti. Il link a una fonte può essere irrilevante, obsoleto o incoerente con la risposta.
- Controlla ogni azione prima di confermarla. Verifica l'account, l'importo, la destinazione, la data e se la modifica può essere annullata.
- Chiedi di parlare con una persona quando il bot si ripete, non dispone dell'autorità necessaria, fraintende una questione delicata o non può mostrare da dove proviene la risposta.
Il modello mentale da ricordare
Un chatbot non è una personalità che vive dentro una finestra. È un'interfaccia conversazionale collegata a una combinazione di flussi, classificatori, ricerca, modelli linguistici, record, strumenti, policy, controlli di sicurezza e persone. La risposta visibile è l'ultimo passaggio di questo sistema più ampio.
La domanda migliore non è “Questo bot sembra umano?”. Chiediti se ha compreso il compito, usato le prove corrette, rispettato le autorizzazioni, recuperato dagli errori con trasparenza e lasciato a te il controllo. Il linguaggio naturale rende il sistema più accessibile. Una progettazione solida lo rende degno di essere usato.
Riferimenti primari e tecnici
- Joseph Weizenbaum, ELIZA: A Computer Program for the Study of Natural Language Communication Between Man and Machine, 1966.
- Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020.
- NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, 2024.
- Google Cloud, documentazione di Dialogflow CX su intenti, fulfillment, progettazione degli agenti e passaggio a un operatore umano.
- OWASP GenAI Security Project, LLM01:2025 Prompt Injection.