Ricerca ibrida e reranking per chatbot AI: migliori risultati RAG

I chatbot per siti web raramente falliscono perché la loro base di conoscenza è completamente priva di informazioni. Più spesso, la fase di retrieval non riesce a trovare il passaggio che corrisponde alla domanda e al contesto specifico. I visitatori utilizzano nomi di prodotti, messaggi di errore e numeri di articolo, ma formulano anche richieste in modo spontaneo: «Perché il chatbot mostra la tariffa sbagliata?» oppure «Posso modificare un ordine già spedito?». Per questa combinazione di esigenze, né la semplice ricerca per parole chiave né la sola ricerca vettoriale rappresentano una risposta universale sufficiente. La ricerca ibrida unisce entrambi i segnali, consentendo a un chatbot RAG di includere fonti più solide nel proprio contesto di risposta.

La ricerca per parole chiave e la ricerca vettoriale svolgono compiti diversi

La ricerca per parole chiave è estremamente efficace quando i termini devono corrispondere esattamente. Questo vale per numeri d'ordine, denominazioni di prodotti, messaggi di errore specifici, nomi di contratti o versioni come «2.4». È in grado di mostrare in modo trasparente perché un documento è pertinente: la parola cercata si trova nel titolo, in un'intestazione o all'interno del testo. Il suo punto debole emerge con il linguaggio quotidiano, i sinonimi e le formulazioni incomplete. La domanda di un utente che cerca una «copia della fattura» non troverà necessariamente una pagina che parla soltanto di «scarica la ricevuta».

La ricerca vettoriale colma questa lacuna. Rappresenta la domanda e il contenuto sotto forma di prossimità semantica e può quindi identificare richieste simili anche quando mancano gli stessi termini. Questo aiuta nel caso di domande di supporto formulate in modo naturale, varianti multilingue e diverse denominazioni per la medesima procedura. Tuttavia, la vicinanza semantica da sola non è un assegno in bianco: un passaggio può essere tematicamente simile, ma riferirsi a un'altra versione del prodotto, a un altro mercato o a una regola ormai scaduta. Proprio per questo motivo, il controllo del contesto deve avvenire all'interno della pipeline di retrieval e non essere delegato direttamente al modello linguistico.

Perché la ricerca ibrida è un ottimo punto di partenza

Microsoft descrive la ricerca ibrida come una query combinata che include una componente full-text e una vettoriale. Entrambe le ricerche vengono eseguite in parallelo e i loro elenchi di risultati vengono successivamente uniti. Questo approccio è particolarmente vantaggioso per i siti web aziendali, poiché preserva i termini esatti e rende contemporaneamente accessibili contenuti correlati e ben formulati. Un chatbot non deve costringere i visitatori a scegliere tra una ricerca «tecnica» e una «semantica». La selezione avviene in background e può essere verificata per tutte le domande con lo stesso processo di qualità.

La ricerca ibrida migliora l'insieme dei candidati; non genera verità assolute. Il chatbot può utilizzare esclusivamente contenuti autorizzati per la situazione specifica. Pagine web pubbliche, bozze interne e dati protetti dei clienti non devono mai confluire in un contesto comune e non controllato. Altrettanto importante è definire un comportamento chiaro quando non è disponibile alcuna fonte adeguata: richiedere chiarimenti, fornire un link alla pagina di contatto o effettuare un human handoff è una scelta molto più sicura rispetto a una supposizione formulata in modo fluido.

Capire RRF: unire le classifiche dei risultati

I punteggi ottenuti dalla ricerca full-text e da quella vettoriale hanno significati e scale differenti. Sommarli direttamente o inventare una soglia fissa porta spesso a risultati instabili. Per questo motivo, la Reciprocal Rank Fusion (RRF) lavora sulla posizione occupata da ciascun documento nelle rispettive classifiche. Un documento che appare in alto in entrambi gli elenchi riceve un forte segnale combinato. Un documento presente in una sola lista può comunque essere preso in considerazione, ma senza scalzare automaticamente tutti gli altri.

L'RRF non è un valore standard magico né una formula sostitutiva per i test funzionali. Il numero di candidati di ciascuna ricerca che entrano nella fusione, i filtri applicati preventivamente e la soglia per considerare utile un risultato dipendono dal contenuto e dal livello di rischio. Per le domande frequenti sui prodotti può essere utile una finestra ridotta e mirata. Per le guide complesse o la diagnosi di errori potrebbe essere necessario un numero maggiore di candidati. Ciò che conta davvero è confrontare le modifiche su domande reali rispetto a un dataset di prova, anziché adottare un parametro universale tratto da un esempio isolato.

Il reranking semantico come secondo livello mirato

Dopo una buona preselezione, un reranker può valutare nuovamente la cerchia ristretta dei candidati rispetto all'intera domanda. Microsoft definisce il ranking semantico come un ranking secondario applicato a un elenco di risultati già pre-ordinato. Allo stesso modo, Amazon Bedrock descrive il reranking come la valutazione della rilevanza dei documenti di testo rispetto alla query. Questo secondo livello è ideale per domande con condizioni multiple: ad esempio, se è possibile modificare la tariffa dopo che l'ordine è già stato spedito e per un determinato tipo di contratto.

Il reranking va limitato in modo consapevole. Comporta una latenza aggiuntiva e, a seconda del servizio utilizzato, può generare costi supplementari. Pertanto, è consigliabile non passare l'intera base di conoscenza al reranker, ma solo il gruppo dei primi risultati già filtrati e fusi. Definire un budget temporale e un piano di fallback è fondamentale. Se il budget viene superato, il chatbot può ad esempio mostrare l'elenco delle fonti più affidabili, chiedere una precisazione o trasferire la conversazione a un team di supporto. Un reranker non corregge contenuti obsoleti, mancanti o non autorizzati.

I filtri sui metadati proteggono il contesto

I metadati spesso influiscono sulla qualità delle risposte più di una qualunque opzione di modello aggiuntiva. Mantenete per ogni fonte almeno lingua, prodotto o servizio, versione, mercato, pubblico di destinazione e validità, qualora tali dati siano rilevanti per la consultazione. Un filtro applicato al tenant corretto o all'area di autorizzazione deve intervenire prima dell'emissione della risposta. Su un sito web pubblico, un chatbot può recuperare solo contenuti pubblici; per un'area riservata valgono autorizzazioni aggiuntive e verificabili.

Anche il fattore tempo è una questione di metadati. Listini prezzi, condizioni di consegna e manuali dovrebbero recare una data di aggiornamento chiara o uno stato di validità controllato. Se una fonte non è più affidabile, deve essere rimossa dall'indice o spostata in un percorso di verifica separato. I filtri devono soddisfare requisiti chiari e comprensibili per i visitatori, senza manipolare in modo invisibile l'ordine dei risultati. Documentate quindi quali filtri si applicano a ciascuna tipologia di domanda e come il team verifica le modifiche.

Una pipeline concreta dalla query al contesto

1. Normalizzare la domanda: identificare la lingua e il contesto evidente, senza salvare o alterare inutilmente dati personali.
2. Verificare accessi e metadati: determinare prima del retrieval quali fonti sono consentite per prodotto, mercato, ruolo e periodo di validità.
3. Eseguire il retrieval in parallelo: effettuare la ricerca full-text e vettoriale sullo stesso insieme di fonti autorizzate.
4. Unire le classifiche: combinare gli elenchi con RRF e conservare per ciascun candidato i segnali d'origine utili al debugging.
5. Applicare un reranking limitato: valutare la rilevanza solo sul ristretto gruppo dei migliori candidati e misurare la latenza.
6. Proteggere il contesto: verificare duplicati, stato delle fonti e una lunghezza adeguata prima di inviare i passaggi al modello di risposta.
7. Fornire risposte trasparenti: indicare le fonti, segnalare l'incertezza e utilizzare, se necessario, un passaggio di consegne sicuro.

Esempio pratico: stato della spedizione e cambio tariffa

Ipotizziamo che un utente chieda: «Posso ancora cambiare la mia tariffa anche se il pacco è già in viaggio?». La ricerca per parole chiave potrebbe trovare una pagina intitolata «Modificare la tariffa» e un articolo di supporto con la frase «pacco in viaggio». La ricerca vettoriale individua invece una guida che descrive la procedura come modifica successiva alla spedizione. L'RRF porta in alto i documenti che combinano entrambi gli aspetti. Successivamente, un reranker può verificare se il passaggio rilevante contiene davvero la combinazione di tariffa e spedizione.

Prima di rispondere, filtrate in base al mercato interessato, alla linea di prodotti e allo stato attuale di validità. Se le fonti sono contraddittorie o mancano dettagli fondamentali, il chatbot non deve tirare le somme basandosi su casi simili. Può invece chiarire in modo trasparente quale condizione sia ancora in sospeso e guidare il visitatore verso una modalità di contatto verificata e idonea. In questo modo la conversazione resta utile, senza inventare rassicurazioni non coperte dai fatti.

Gestione dei casi «nessun risultato» e debugging dei punteggi

L'assenza di risultati è spesso il segnale di una lacuna nella conoscenza, non di un motore di ricerca guasto. È opportuno distinguere almeno quattro scenari: non esiste alcuna fonte autorizzata, esistono fonti ma nessun risultato è sufficientemente pertinente, la domanda è ambigua oppure un errore tecnico impedisce il retrieval. Ogni scenario richiede una reazione dedicata e chiara. Rispondere «Non trovo informazioni affidabili tra i dati autorizzati per questa domanda» è più onesto rispetto a una frase generica priva di un'azione successiva.

Per il debugging, i punteggi finali da soli non bastano. Per ciascuna domanda di prova, i team dovrebbero poter verificare quali filtri sono stati applicati, quali documenti sono emersi dalla ricerca per parole chiave e vettoriale, come sono stati fusi e se il reranking ha modificato l'ordine. In questo processo, salvate solo i dati strettamente necessari alla qualità, elaborati nel rispetto della privacy. Cercate schemi ricorrenti: mancano determinati sinonimi? Una vecchia fonte sovrascrive contenuti più recenti? Una localizzazione esce dalla logica dei metadati? Solo l'individuazione della causa concreta permette di capire se occorre intervenire su chunking, metadati, gestione delle fonti o ranking.

Dataset di test, metriche e budget di spesa

Un piccolo «Golden Set» composto da 30-50 domande realistiche rappresenta un eccellente punto di partenza. Per ciascuna domanda, definite le fonti attese, le fonti non consentite e la reazione desiderata in caso di mancanza di informazioni. Misurate separatamente se tra i candidati figura la fonte corretta, se il suo posizionamento è sufficientemente alto e se la risposta finale impiega solo informazioni documentate. Arricchite intenzionalmente i test con refusi, termini esatti, espressioni naturali, varianti multilingue e casi negativi critici.

A ogni sessione di test modificate una sola variabile: un filtro, il numero di candidati, la profondità di reranking o la struttura dei chunk. Annotate inoltre il tempo di risposta e il numero di chiamate verso modelli esterni. Un punteggio di rilevanza più alto perde di valore se la risposta arriva troppo in ritardo o se i costi per le domande standard ricorrenti aumentano eccessivamente. Stabilite quindi un budget di latenza e di costo per ciascuna categoria di domanda. Risposte standard rapide e ben documentate, affiancate da passaggi di consegne cautelativi, portano più valore a molti siti web rispetto a un sistema di ranking estremamente complesso.

Errori comuni in fase di implementazione

• Confrontare direttamente i punteggi grezzi delle parole chiave e dei vettori, nonostante le loro scale differiscano.
• Indicizzare bozze, vecchi listini prezzi o contenuti protetti senza applicare i dovuti filtri di stato e autorizzazione.
• Applicare il reranking a un numero eccessivo di candidati, perdendo il controllo su latenza e costi.
• Considerare una demo con poche domande ben riuscite come una prova di qualità sufficiente.
• Generare una risposta plausibile quando manca una fonte, anziché prevedere una segnalazione d'incertezza, una richiesta di chiarimento o l'handoff umano.
• Non tracciare le versioni delle modifiche apportate a fonti, chunking e ranking, trovandosi nell'impossibilità di giustificarle in seguito.

Checklist per l'integrazione

• Stabilire le fonti consentite e i limiti di autorizzazione prima dell'indicizzazione.
• Mantenere aggiornati i metadati per lingua, prodotto, versione, mercato e validità.
• Eseguire la ricerca full-text e vettoriale in parallelo, unendo poi i risultati tramite RRF.
• Utilizzare il reranking solo su un insieme ridotto e autorizzato di candidati.
• Valutare nel dataset di test i link alle fonti, le risposte in assenza di risultati e l'handoff umano.
• Misurare latenza, costi e risposte errate critiche per ogni modifica apportata.

Considerazioni finali

La ricerca ibrida costituisce un punto di partenza solido per i chatbot per siti web chiamati a gestire domande con formulazioni molto diverse. La ricerca per parole chiave preserva i segnali di precisione, la ricerca vettoriale individua le richieste simili, l'RRF fonde le rispettive classifiche e un reranker ben calibrato affina la selezione finale. Tuttavia, il miglioramento duraturo della qualità nasce da fonti ben curate, metadati idonei, test trasparenti e una logica di risposta che riconosce i propri limiti. In questo modo, il retrieval diventa verificabile anziché essere soltanto un esercizio di stile tecnico.

Fonti e approfondimenti

• Microsoft Learn: Hybrid Search
• Microsoft Learn: Rilevanza e RRF nella ricerca ibrida
• Microsoft Learn: Semantic Ranking
• Amazon Bedrock: Reranking
• ChatReact: RAG-Chunking per chatbot AI
• ChatReact: Misurare la qualità delle risposte con il Golden Set
• ChatReact: Mantenere aggiornata la base di conoscenza