Sintesi
Molti progetti RAG non falliscono per colpa dell'IA in sé, ma perché si cercano troppi documenti senza un controllo sufficiente del contesto. Risposte precise dipendono da un buon context engineering, in cui informazioni rilevanti come il modello del prodotto, il tipo di cliente o la versione del software vengono prima identificate e solo dopo si effettua la ricerca. Limitando in modo mirato il perimetro di ricerca, è possibile ridurre in modo significativo falsi positivi, informazioni contraddittorie e allucinazioni. Il RAG diventa un sistema affidabile solo quando i documenti giusti vengono selezionati nel contesto giusto per il chiamante specifico.
RAG non è una bacchetta magica
Retrieval Augmented Generation, o RAG, è diventato una delle tecnologie più importanti per i moderni assistenti telefonici IA. Le aziende caricano le loro knowledge base, i manuali, la documentazione di prodotto o il materiale di supporto e si aspettano che l'IA risponda correttamente a ogni domanda.
In pratica, però, molti progetti RAG non falliscono per colpa dell'IA in sé, ma per una configurazione errata del contesto.
Un errore tipico è caricare tutti i documenti disponibili in un'unica knowledge base e presumere che il grande modello linguistico scelga automaticamente le informazioni giuste.
Purtroppo, questo funziona raramente in modo affidabile.
Il vero problema: context engineering
Chi sviluppa assistenti telefonici IA deve capire cosa significa context engineering.
Il context engineering è l'arte e la disciplina di fornire al modello linguistico esattamente le informazioni necessarie per il compito corrente, né più né meno.
Un modello linguistico risponde alle domande in base al contesto che riceve. Se quel contesto viene costruito male, le risposte errate diventano inevitabili.
Molte persone si concentrano solo sul retrieval, cioè sull'idea che "l'IA trova l'informazione". Dimenticano la domanda molto più importante:
L'IA trova l'informazione giusta nel contesto giusto?
Un classico esempio di assistenza clienti
Prendiamo un produttore o rivenditore di macchine da caffè.
Il sistema RAG contiene i manuali di tutti i modelli disponibili:
- Modello A
- Modello B
- Modello C
- Modello D
Un cliente chiama e chiede:
Dopo quante tazze devo fare la manutenzione?
Tecnicamente, il retrieval funziona inizialmente. L'IA trova diversi passaggi rilevanti nei manuali caricati.
Il problema è che ogni modello ha intervalli di manutenzione diversi.
- Modello A: manutenzione dopo 500 tazze
- Modello B: manutenzione dopo 1.000 tazze
- Modello C: manutenzione dopo 750 tazze
- Modello D: manutenzione dopo 1.500 tazze
Poiché tutti i documenti contengono informazioni simili, l'IA può usare per errore un passaggio del manuale sbagliato.
Il risultato è una risposta plausibile, ma potenzialmente errata.
Perché il retrieval da solo non basta
Molti pensano che il RAG risolva automaticamente il problema.
È un fraintendimento.
Il RAG risponde solo alla domanda:
Quali documenti potrebbero essere rilevanti?
Non risponde invece a:
Qual è il documento giusto per questo chiamante specifico?
Questo livello aggiuntivo deve essere creato dal flusso conversazionale dell'assistente telefonico.
L'approccio corretto: prima identificare, poi cercare
Invece di cercare subito nella knowledge base, l'assistente telefonico IA dovrebbe prima determinare l'informazione critica:
Di quale modello si tratta?
Il flusso di conversazione potrebbe essere così:
Chiamante: "Dopo quante tazze devo fare la manutenzione?"
Assistente: "Per quale modello le serve l'informazione?"
Chiamante: "Per la CoffeeMaster X200."
Solo allora la knowledge base dovrebbe essere interrogata.
Ma non più su tutti i documenti caricati. La ricerca deve essere limitata solo al manuale della CoffeeMaster X200.
Questo riduce drasticamente lo spazio di ricerca e aumenta notevolmente la probabilità di una risposta corretta.
Meno contesto spesso significa risposte migliori
Un altro equivoco comune è:
Più documenti carico, migliore sarà l'IA.
In realtà, spesso è il contrario.
Se sono disponibili molti documenti simili, aumenta il rischio di:
- informazioni contrastanti
- falsi positivi
- allucinazioni
- confusione tra varianti di prodotto
- risposte incerte
Un buon context engineering spesso significa escludere deliberatamente informazioni.
La risposta migliore non nasce dal contesto più ampio, ma dal contesto più rilevante.
Come implementarlo in VoiceBooker
In VoiceBooker, questo problema può essere risolto molto semplicemente.
Invece di cercare sempre globalmente nella knowledge base, il sistema può prima determinare il prodotto o modello corretto.
Successivamente, la ricerca viene limitata solo ai documenti rilevanti.
Per questo, VoiceBooker mette a disposizione la funzione kbLookup.
Con kbLookup è possibile passare un array di documenti che definisce la base di ricerca.
Questo permette di restringere la ricerca, ad esempio a:
- solo il manuale del modello X di lavatrice
- solo i documenti della macchina da caffè modello Y
- solo i manuali di una specifica serie di prodotti
L'assistente telefonico IA riceve così solo le informazioni rilevanti per il chiamante attuale.
Altri errori comuni nei sistemi RAG
1. Nessuna qualificazione preliminare del chiamante
Molti sviluppatori lasciano che l'IA cerchi subito, anche se mancano ancora informazioni importanti.
Esempi:
- Quale prodotto possiede il cliente?
- Quale versione del software viene utilizzata?
- Per quale paese vale la richiesta?
- Si tratta di un cliente privato o aziendale?
Senza queste informazioni, l'IA cerca spesso in un insieme di dati troppo ampio.
2. Mescolare diversi tipi di documenti
Spesso manuali, istruzioni interne, materiale marketing e specifiche tecniche vengono salvati insieme nella stessa knowledge base.
Questo crea conflitti, perché la stessa domanda può ricevere risposte diverse in documenti diversi.
3. Cercare in troppi documenti
Molte aziende caricano migliaia di documenti e si aspettano risultati perfetti.
Più grande diventa lo spazio di ricerca, più è difficile per il sistema di retrieval identificare le informazioni realmente rilevanti.
4. Non usare metadati
I documenti dovrebbero avere metadati come:
- nome prodotto
- numero di modello
- tipo di prodotto
- lingua
- paese
- versione del documento
Queste informazioni consentono di restringere le ricerche in modo molto più preciso.
5. Fidarsi ciecamente dei risultati di ricerca
Solo perché il sistema di retrieval ha trovato un passaggio non significa automaticamente che quel passaggio contenga la risposta giusta.
RAG aumenta la probabilità di risposte corrette, ma non sostituisce la necessità di una struttura dati pulita e di un dialogo ben progettato.
Conclusione
L'errore più grande nei progetti RAG non è caricare pochi documenti. È caricarne troppi senza controllare il contesto.
Un assistente telefonico IA non deve solo sapere quali informazioni esistono. Deve prima capire quali informazioni sono rilevanti per il chiamante attuale.
È qui che entra in gioco il context engineering.
Se prima si determinano i parametri necessari del chiamante, come numero di modello, variante di prodotto o tipo di cliente, e poi si restringe il retrieval di conseguenza, si ottengono risposte molto più precise e una soddisfazione cliente decisamente più alta.
RAG non è quindi solo una knowledge base per l'IA.
RAG diventa un sistema affidabile solo quando è combinato con un buon context engineering.
Chi comprende questo costruisce assistenti telefonici IA che non forniscono solo risposte, ma le risposte giuste.