RAG per il customer support: come rispondere ai ticket con fonti citate

Il RAG (Retrieval Augmented Generation) applicato al customer support significa collegare articoli di aiuto, policy e procedure interne a un motore che risponde ai ticket citando il passaggio esatto da cui arriva ogni informazione. Il risultato è una doppia vittoria: meno ticket ripetitivi perché i clienti trovano da soli la risposta, e operatori più rapidi perché smettono di cercare a mano nella documentazione interna.

Che cos'è il RAG applicato al customer support

Un sistema RAG non genera risposte a partire dalla memoria generica di un modello linguistico: cerca prima i passaggi pertinenti nei Suoi documenti (articoli del centro assistenza, condizioni di garanzia, policy di reso, procedure di escalation) e poi costruisce la risposta solo su quel materiale, indicando da dove proviene ogni affermazione. Se vuole capire il meccanismo nel dettaglio, passo dopo passo, può leggere la nostra guida su come funziona il RAG.

Nel customer support questo cambia due cose concrete. Primo, le risposte sono verificabili: un cliente che legge 'secondo la policy di reso, articolo 4.2, ha 30 giorni di tempo' può controllare l'articolo citato invece di fidarsi ciecamente. Secondo, il sistema non inventa condizioni commerciali che non esistono, un rischio reale quando un modello generico prova a 'ricordare' una policy senza averla letta davvero.

Deflection: ridurre i ticket senza frustrare i clienti

La deflection (deviazione dei ticket) è l'obiettivo più citato quando si parla di IA nel customer support, ma va fatta con criterio. Un chatbot che risponde in modo vago o, peggio, sbagliato su una policy di rimborso genera più lavoro di prima: il cliente scrive comunque, ma arrabbiato. Un sistema RAG ben costruito riduce questo rischio perché ogni risposta è ancorata a un documento reale e, se non trova nulla di pertinente, può dirlo esplicitamente invece di inventare.

• Risposte automatiche sulle domande a basso rischio: orari, stato spedizione, procedure standard, con citazione della fonte.
• Escalation trasparente: se la base di conoscenza non copre il caso, il sistema lo segnala e passa il ticket a un operatore invece di tentare una risposta approssimativa.
• Autoserve nel widget del sito o nell'email di conferma ordine, dove il cliente può fare domande prima ancora di aprire un ticket.
• Tracciamento dei casi di deflection fallita per capire quali articoli mancano o sono scritti male.

Agent assist: il copilota per gli operatori

L'altro uso, spesso sottovalutato rispetto alla deflection, è l'agent assist: lo stesso motore RAG, ma rivolto all'operatore invece che al cliente. Mentre legge il ticket, l'operatore vede suggerita la risposta con i passaggi della documentazione interna già citati, pronta da adattare e inviare. Questo accorcia il tempo medio di gestione (AHT) soprattutto per i nuovi assunti, che non conoscono ancora a memoria tutte le policy.

In pratica, molti team collegano la base di conoscenza al proprio strumento di helpdesk tramite API, oppure interrogano direttamente la base da un client compatibile MCP durante il lavoro quotidiano. Se non conosce ancora questo standard, la guida su cos'è MCP spiega come funziona il collegamento tra un assistente IA e una fonte di documenti esterna.

Come costruire la base di conoscenza di supporto

La qualità delle risposte dipende quasi interamente dalla qualità e dalla copertura dei documenti indicizzati, non dal modello usato per generare il testo. Per un team di customer support, i documenti da raccogliere sono in genere questi:

1. Articoli del centro assistenza pubblico, già scritti per i clienti.
2. Policy interne di reso, garanzia, rimborso e gestione reclami, spesso in versione più dettagliata di quella pubblicata online.
3. Procedure di escalation e matrice di responsabilità (chi gestisce cosa, quando coinvolgere un responsabile).
4. Changelog di prodotto e note di rilascio, utili per rispondere a domande su funzionalità recenti.
5. FAQ interne costruite dai ticket più ricorrenti, spesso la fonte più preziosa e meno sfruttata.

Su Kopik può caricare questi documenti (PDF, Word, testo, Markdown) in una base privata o pubblica e ottenere l'indicizzazione automatica per la ricerca ibrida, che combina corrispondenza testuale esatta (utile per codici prodotto, numeri di articolo contrattuale) ed espansione semantica (utile quando il cliente usa parole diverse da quelle del documento). Il meccanismo è descritto nel dettaglio nel nostro articolo su ricerca ibrida BM25 e vettori.

Chunking: perché la dimensione dei blocchi conta

Un errore frequente è caricare un intero manuale di policy come un unico documento gigante: il sistema troverà difficoltà a isolare il paragrafo preciso che risponde alla domanda, e la citazione sarà troppo generica per essere utile. Vale la pena leggere la nostra guida su strategie di chunking per RAG prima di caricare documenti molto lunghi, per capire come dividerli in sezioni logiche (per articolo di policy, per categoria di prodotto, per tipo di reclamo).

Mantenere i contenuti freschi: il problema numero uno

Le policy di reso cambiano, i prezzi di spedizione si aggiornano, una promozione finisce. Un sistema RAG che cita ancora la policy del 2024 dopo che è cambiata è peggio di nessun sistema, perché dà un'illusione di autorevolezza a un'informazione sbagliata. Alcune pratiche aiutano a tenere la base di conoscenza allineata alla realtà:

• Assegnare un responsabile per ogni famiglia di documenti (reso, garanzia, fatturazione) che aggiorni il file sorgente appena cambia qualcosa, non una volta al trimestre.
• Ricaricare la versione aggiornata nella base appena pubblicata, invece di accumulare modifiche da fare 'quando c'è tempo'.
• Rivedere periodicamente le citazioni più usate nelle risposte automatiche: se un articolo torna spesso ma genera reclami o riaperture di ticket, probabilmente è scritto in modo ambiguo.
• Rimuovere o archiviare i documenti obsoleti invece di lasciarli nella base 'per sicurezza': un documento vecchio può essere recuperato per errore insieme a quello corretto.

Privacy, GDPR e fiducia del cliente

Un help desk basato su RAG tratta spesso dati di clienti europei, quindi le considerazioni del GDPR si applicano sia ai documenti caricati sia ai log delle conversazioni. Se il servizio clienti opera in Italia o nell'Unione Europea, conviene verificare dove sono ospitati i dati, quanto a lungo vengono conservati i log e chi può accedervi. Abbiamo trattato l'argomento in modo pratico nella guida su come costruire un chatbot conforme al GDPR, utile anche per un caso d'uso di customer support.

Dal punto di vista della fiducia del cliente, mostrare la fonte citata per ogni risposta automatica è anche una forma di trasparenza che riduce le contestazioni: il cliente vede da dove arriva l'informazione e può controllarla, invece di dover credere a un'affermazione senza riscontro. Il nostro articolo su come verificare una risposta IA con le fonti spiega come impostare questo controllo anche internamente, prima di pubblicare una risposta automatica.

Misurare il successo oltre il tasso di deflection

Concentrarsi solo sul numero di ticket evitati porta a ottimizzare la metrica sbagliata. Alcune metriche più robuste da monitorare insieme:

• Tasso di riapertura dei ticket risolti dall'IA: se un cliente riapre entro 48 ore, la risposta probabilmente non era completa.
• CSAT specifico per le interazioni gestite in autonomia, separato da quello degli operatori umani.
• Percentuale di risposte con citazione trovata vs risposte 'non so', che indica le lacune di copertura della base.
• Tempo medio di gestione per gli operatori che usano l'agent assist rispetto a quelli che non lo usano, per quantificare il guadagno reale.

Per avviare un primo esperimento senza una pipeline complessa, è possibile creare una base da /dashboard/bases/new, caricare gli articoli del centro assistenza più consultati e interrogarla in modalità 'risposte con fonti' per vedere subito la qualità delle citazioni prima di collegarla al proprio helpdesk.

Integrare il RAG nel flusso di lavoro esistente

La maggior parte dei team di customer support non vuole cambiare strumento di helpdesk, vuole aggiungere un livello di risposta sopra quello che già usa. Le due strade più comuni sono l'integrazione via API REST, dove ogni nuovo ticket viene inviato come domanda alla base di conoscenza e la risposta suggerita compare nell'interfaccia dell'operatore, oppure l'uso diretto da un client MCP durante la scrittura manuale delle risposte. La documentazione tecnica su /developers descrive entrambi gli approcci, incluse le chiavi API per basi private e il formato delle risposte con passaggi citati.

Per chi lavora già con strumenti come Claude o Cursor per compiti di supporto tecnico più avanzato (ad esempio un team di supporto prodotto che deve consultare anche la documentazione tecnica), la guida su collegare Claude, Cursor o ChatGPT a una base di conoscenza mostra i passaggi concreti di configurazione.

Ridurre le allucinazioni resta la priorità

Qualunque sia l'architettura scelta, il rischio da controllare sempre è quello di risposte inventate su policy commerciali, perché possono avere conseguenze economiche dirette (un rimborso promesso che non doveva esserci, una garanzia estesa non prevista). Impostare il sistema in modo che risponda solo sulla base dei documenti indicizzati, e che dichiari esplicitamente quando non trova una fonte pertinente, è la misura più efficace. Il nostro approfondimento su come ridurre le allucinazioni dell'IA raccoglie le tecniche principali, utili anche fuori dal contesto del customer support.

Infine, se il Suo centro assistenza riceve molte domande sotto forma di documenti allegati dai clienti (fatture, contratti, foto di prodotti difettosi con relativa scheda tecnica), può essere utile anche la logica descritta in chattare con i PDF: lo stesso principio di risposta con fonte citata si applica sia ai documenti interni sia a quelli che il cliente invia per spiegare il proprio caso.