Il modulo è stato inviato con successo.
Ulteriori informazioni sono contenute nella vostra casella di posta elettronica.
Assumeteci
Assumeteci
Assumeteci Selezionare la lingua
Chi siamo 
Tecnologie Portafoglio
Assumeteci 
Se avete già provato un chatbot LLM al lavoro, conoscete il punto di rottura: sembra sicuro di sé, poi qualcuno chiede un dettaglio di una politica, una regola di un prodotto o l'ultimo processo interno e la risposta è sbagliata o vaga. Il vostro team finisce per ricontrollare tutto, cercare comunque nei PDF e nei wiki e preoccuparsi di chi ha appena visto cosa nella chat.
Un chatbot RAG collega un LLM alle vostre conoscenze aziendali approvate al momento della domanda. Estrae i passaggi giusti dai vostri documenti, li usa come base per la risposta e può mostrare il testo di partenza in modo che le persone possano verificarlo. Le regole di accesso possono far parte della configurazione, in modo che il bot non faccia apparire contenuti sensibili alle persone sbagliate.
In questa guida, vi spiegherò il Definizione di chatbot RAG, Come funziona la Generazione Aumentata di Recupero, dove si adatta meglio e come implementarla passo dopo passo, comprese le caratteristiche e i controlli di sicurezza di cui i team hanno solitamente bisogno negli ambienti reali.
Un chatbot RAG, oppure recupero generazione aumentata chatbot, è un assistente di chat che risponde con i dati dell'utente davanti a sé. Prima di rispondere, cerca i documenti, i database o le API dell'utente per trovare i dati più rilevanti, quindi LLM scrive la risposta utilizzando il contesto estratto. Il contrasto è semplice. Un LLM semplice risponde in base a ciò che ricorda (dai dati precedentemente inseriti). A Chatbot RAG AI risposte dopo verifica le fonti, riducendo le allucinazioni, e aggiunge citazioni a sostegno delle sue affermazioni.
Per comprendere il Significato del chatbot RAG senza gergo, immaginate questo. Lunedì mattina. State prenotando un volo di 9 ore per un viaggio di un cliente e (sicuramente) volete fare in fretta, quindi inviate un messaggio in chat per verificare se la vostra azienda copre la premium economy per i voli superiori alle 6 ore. Il bot di base risponde subito di sì. Si prenota. Fatto.
Due settimane dopo, la richiesta di rimborso spese viene respinta. Perché, a vostra insaputa, la politica è cambiata lo scorso trimestre, aggiungendo una nuova fase di approvazione. Ora avete un botta e risposta con l'ufficio finanziario, il vostro manager è stato chiamato in causa e voi state scavando nel wiki per cercare di capire quale sia la regola.
A Chatbot alimentato da RAG gestisce la stessa domanda controllando prima la polizza di viaggio, citando la regola esatta e lasciando cadere il link. Si prenota la cosa giusta o si ottiene prima l'approvazione. In ogni caso, non ci sono sorprese dopo.
Le differenze sono più facili da comprendere se si considerano esempi comuni:
Di solito è possibile capire già alla prima settimana se un chatbot resisterà. Se le persone non si fidano delle risposte, smettono di usarle. Se non possono verificare la fonte, smettono ancora più rapidamente. Il RAG dà loro qualcosa di solido su cui appoggiarsi. Ecco i risultati che vedo più spesso quando funziona:
Abbiamo costruito un sacco di sistemi che pesano sui documenti per i team interni: policy, basi di conoscenza, portali, tutto il resto. Quindi sappiamo cosa si rompe per primo. Se state progettando un chatbot RAG per un'azienda, queste sono le funzionalità che i team chiedono di più. Non perché sembrano belle. Perché vi salvano quando si presentano gli utenti reali.
Quando un bot risponde senza indicare la fonte, le persone esitano perché non possono fidarsi completamente. L'attribuzione della fonte aggiunge un link o una nota al documento e alla sezione esatta da cui proviene la risposta. Così, quando qualcuno chiede: “Da dove viene questa risposta?”, il bot può indicare la ricevuta invece di costringere le persone a scavare nel wiki.
Alcune domande sono parole chiave, come l'errore 0x801c03f3, il numero di parte o l'ID di un criterio. Altre sono semplicemente il modo in cui le persone parlano, ad esempio: “Perché non funziona dopo l'aggiornamento?”. La ricerca ibrida copre entrambi gli aspetti. Esegue la ricerca per parole chiave (BM25) insieme alla ricerca vettoriale, in modo che il bot possa rispondere alla stringa esatta e cogliere comunque l'intento della domanda. Senza di essa, si verificano i fastidiosi fallimenti. Si chiede un codice o un ID esatto, il documento ha quel codice esatto, e il bot continua a visualizzare la pagina sbagliata o a dire che non ha trovato nulla.
Le persone non parlano ai bot come a una barra di ricerca. Scrivono velocemente, saltano i dettagli e lasciano perdere i follow-up vaghi. La riscrittura delle query risolve questo problema prima ancora che inizi la ricerca. Pulisce gli errori di battitura, inserisce il contesto mancante dove può e trasforma una domanda confusa in qualcosa che il sistema può effettivamente cercare. In questo modo, si evitano le Chatbot LLM RAG afferrare il documento sbagliato fin dal primo passo.
La ricerca raramente restituisce una corrispondenza perfetta. Ci consegna una pila di corrispondenze abbastanza vicine. E il modello tende a prendere la prima cosa che vede e a costruirci intorno la risposta. La riclassificazione risolve questo problema. Prende i risultati migliori, li classifica di nuovo e mette i migliori al primo posto prima che il modello inizi a scrivere. La differenza è evidente nell'uso reale. Si ottengono meno deviazioni strane e meno risposte basate sul paragrafo sbagliato.
La maggior parte dei documenti aziendali è lunga e la parte utile raramente si trova nel primo paragrafo. Senza la compressione, il bot inserisce interi paragrafi e la risposta inizia a vagare. Grazie alla compressione, il bot riduce la fonte alle poche righe effettivamente importanti per la domanda e lascia perdere il resto. In questo modo si ottiene una risposta più pulita.
Un link alla citazione è meglio di niente, ma vi manda comunque in un PDF gigante e passate cinque minuti a cercare una frase. Le anteprime delle citazioni riducono questo dolore. Si passa il mouse sulla citazione e il Chatbot LLM RAG mostra le linee esatte utilizzate. Si controlla in due secondi e si va avanti.
La chat reale è una catena, non una singola domanda. Si chiede qualcosa, si riceve una risposta e si continua. La memoria conversazionale mantiene il bot sul filo del discorso, in modo che capisca a cosa ci si riferisce e possa continuare senza resettare. Senza di essa, il bot dimentica, voi ripetete tutto e la chat inizia a sembrare un modulo con passaggi aggiuntivi.
I team conservano le informazioni chiave in tabelle, grafici, screenshot e PDF scansionati. Un bot di solo testo non è in grado di leggere questi contenuti, quindi può perdere i dettagli che determinano la risposta. Il supporto multimodale consente al bot di leggere questi formati e di utilizzarli nella risposta. Questa funzione è importante nei manuali e nei rapporti finanziari, dove la risposta è spesso contenuta in una cella della tabella.
Il chatbot con RAG deve seguire le vostre regole di accesso, come qualsiasi altro dipendente, compresi i casi difficili in cui un documento ha sezioni aperte e sezioni riservate. Se si sbaglia, il lancio viene bloccato. Se lo fate bene, le persone possono usare la chat senza preoccuparsi che si rovesci qualcosa che non dovrebbe.
Alcuni ambienti necessitano di controlli più severi sull'integrità e sull'uso improprio. Un approccio che ho visto in un'implementazione di riferimento è l'aggiunta di un livello blockchain per la governance. Può memorizzare i record in modo esclusivamente append, mentre gli smart contract eseguono le regole di governance utilizzando il voto e il consenso per l'applicazione delle regole. Ma non è necessario per ogni progetto. Si può prendere in considerazione quando si desidera un controllo più forte sul modo in cui i contenuti e le autorizzazioni cambiano nel tempo.
I sistemi RAG vengono attaccati in modi specifici. L'iniezione di prompt e il contenuto avvelenato sono comuni. È possibile aggiungere un monitoraggio che esamina i registri delle chat per individuare modelli rischiosi, scansiona i documenti per individuare segni di avvelenamento e osserva il flusso di dati per rilevare attività insolite. Se qualcosa sembra strano, lo segnala e lo indirizza verso un percorso di risposta, come il blocco della fonte, l'avviso alla sicurezza o la forzatura di una fase di revisione.
Non c'è bisogno di un motivo sofisticato per costruirlo. Se il vostro team continua a chiedere le stesse cose e la risposta è già scritta da qualche parte, state pagando la tassa sulla ricerca. Un bot in grado di citare la fonte riduce rapidamente questo problema. Ho raccolto i casi d'uso in cui questa lacuna si manifesta maggiormente.
I chatbot tradizionali di solito si attengono a un menu fisso di domande. Se si allontana da esso, si blocca. Un chatbot alimentato da RAG può cercare la risposta nelle fonti collegate, in modo che le risposte corrispondano a ciò che i documenti e i sistemi dicono effettivamente.
Scegliete prima un ambito mirato, come i documenti di supporto, le politiche interne o i runbook IT. Scrivete le domande principali che volete coprire e definite cosa conta come risposta corretta. Decidete cosa fa il bot quando le fonti non supportano una risposta. Ad esempio, indirizza l'utente alla sezione giusta del documento o pone una domanda successiva per restringere la richiesta.
Iniziate con l'elencare tutte le fonti che vi aspettate che il Chatbot LLM RAG da utilizzare, chi lo possiede, quanto è aggiornato e quali sono le regole di accesso. Quindi ripulire le cose che si recuperano in un secondo momento:
Se le policy cambiano spesso, concordate una semplice regola di versione per evitare che le vecchie bozze continuino a vincere. Inoltre, memorizzate le autorizzazioni insieme ai documenti e applicatele ogni volta che il bot recupera i contenuti.
La qualità del recupero dipende da due fattori: come si suddividono i contenuti e come li si etichetta. Per le politiche e le procedure, suddividete i contenuti in base alle sezioni e alle intestazioni, in modo che il testo recuperato sia leggibile da solo. Aggiungete una piccola sovrapposizione per evitare di tagliare una regola su due parti. Deducete le ripetizioni in modo che i paragrafi copiati non dominino il recupero. Una volta suddivisi e puliti, questi blocchi di testo vengono passati attraverso un modello di incorporazione per convertirli in numeri vettoriali, che consentono al database di effettuare ricerche in base al significato e al contesto.
Aggiungete i metadati che filtrerete in seguito (titolo, sezione, data, team, regione, prodotto, versione). Impostate dei trigger di reindicizzazione, come un aggiornamento del documento, una nuova versione o una modifica dell'autorizzazione. Per i PDF e le scansioni, eseguite l'estrazione del testo e i controlli di qualità per evitare di indicizzare il testo interrotto.
Come già sapete, un chatbot RAG ha bisogno di alcune parti che lavorano insieme:
Ora avete una scelta reale: scegliere una configurazione pronta per l'uso o costruire uno stack personalizzato.
La configurazione con un solo clic consente di ottenere rapidamente una demo. Tuttavia, rende anche dolorose le modifiche successive. Uno stack controllato dall'utente consente di muoversi. Ad esempio, un'interfaccia utente React con servizi Python alle spalle consente di cambiare il provider LLM o il livello di recupero senza dover ricostruire tutto.
In questo caso, vi consiglio di scegliere la seconda opzione se volete mantenere il controllo quando le cose cambiano.
La perdita di autorizzazioni è un fallimento da cui è difficile riprendersi. Ad esempio, un dipendente giovane fa una domanda innocua sugli stipendi. Il Chatbot alimentato da RAG fa una ricerca, prende una riga dalla cartella privata dell'amministratore delegato e la inserisce nella chat. Ora è un problema dell'azienda.
Ecco perché le autorizzazioni devono far parte del recupero. Filtrate durante il recupero utilizzando gli elenchi di accesso ai documenti, l'appartenenza a gruppi e i tag dei metadati. Eseguite nuovamente gli stessi controlli quando l'utente apre un link di origine.
Pianificate anche l'accesso parziale. Alcuni utenti possono vedere una sezione di un documento ma non un'altra, e questo influisce sul chunking e sui metadati. Se gli utenti chiedono codici, ID o numeri di polizza esatti, il recupero ibrido (semantico più parola chiave) spesso funziona meglio del solo embedding.
Dopo aver impostato il recupero e i permessi, decidete cosa mostrare nella risposta. Le persone vogliono due cose: la risposta e la prova sotto di essa.
Un default solido si presenta così:
Quindi impostare la regola del "no-guess". Se ciò che il bot ha estratto non corrisponde alla risposta, il bot deve dirlo e porre una domanda di approfondimento mirata o inviare l'utente alla sezione di partenza.
Prima del lancio, testare il Chatbot alimentato da RAG con domande reali di utenti reali. Cercate i punti deboli, ad esempio quando il reperimento sbaglia sezione, non trova il documento giusto o la risposta va oltre quanto indicato dalla fonte. Utilizzate questi risultati per regolare le dimensioni dei pezzi, le impostazioni di recupero, i filtri dei metadati e i suggerimenti.
Semplificate il processo di valutazione suddividendolo in due parti. Innanzitutto, verificate se il recupero ha trovato il passaggio giusto. Poi, verificare se la risposta è rimasta all'interno di quel passaggio. Tracciate il tasso di successo del recupero, la copertura delle citazioni e il numero di risposte supportate dalla fonte per misurare i progressi nel tempo.
Aggiungete controlli per la prompt injection, registrate chi ha chiesto cosa e salvate le fonti utilizzate per ogni risposta. Se il vostro ambiente è ad alto rischio, osservate i contenuti dannosi e gli strani flussi di dati che sembrano fuori luogo. Riducete i segreti e i dati personali quando necessario, impostate regole di conservazione chiare per i log di chat e gli snippet recuperati e conservate i log di audit che mostrano l'utente, le fonti recuperate e la risposta finale.
Spedire in piccole versioni. Iniziate con una versione pilota, leggete le chat reali, correggete ciò che non funziona, quindi ampliate l'accesso. Dopo il lancio, nominate i proprietari per gli aggiornamenti dei contenuti, la messa a punto del recupero e la modifica dei permessi. Senza proprietari, i documenti cambiano, le cartelle si spostano e il bot inizia lentamente a dare risposte di cui non ci si fida più.
In base alla mia esperienza, un piccolo progetto pilota di solito viene realizzato in 4-8 settimane. Si tratta di un dominio, un flusso di chat che funziona da un capo all'altro, fonti e citazioni, oltre a controlli di accesso di base. Abbastanza per dimostrare che il bot può rispondere e mostrare il suo lavoro. Non abbastanza da trasformarsi in un'intera ricerca secondaria.
Un'implementazione più ampia richiede solitamente dalle 10 alle 16 settimane. Il tempo supplementare è necessario per attingere a più tipi di fonti, gestire permessi più severi, aggiungere il monitoraggio e i registri e testare con le domande disordinate che le persone digitano realmente.
Di solito la squadra si presenta così:
È inoltre possibile inserire un ingegnere di sicurezza ML quando l'iniezione di prompt e il contenuto avvelenato sono rischi reali. Oppure aggiungere competenze in materia di blockchain, ma solo quando la governance con un record di sole appendici fa parte del piano.
Quando un chatbot RAG entra in funzione, i team possono ottenere un aumento della produttività di 41% e un salto di 20% nel rilevamento dei tentativi di violazione. Davvero incredibile.
Certo, non posso promettere che vedrete gli stessi numeri. Quei risultati provengono da costruzioni specifiche e i dettagli sono importanti. Almeno non prima di aver esaminato il vostro campo di applicazione. Il punto è sempre lo stesso. Quando il bot risponde da fonti approvate e le regole di accesso sono rigide, il lavoro si velocizza e le attività rischiose vengono individuate prima.
Se volete verificare se un chatbot RAG è adatto al vostro team, vi mostreremo cos'è un chatbot basato su RAG, Condividiamo casi simili, esaminiamo i vostri casi d'uso e le vostre fonti di dati e vi aiutiamo a progettare una build che si adatti ai vostri vincoli.
Può utilizzare documenti interni, articoli della knowledge base, pagine wiki, contenuti di supporto e altre fonti di testo approvate dall'azienda. L'importante è che siate voi a controllare le fonti e le regole di accesso.
Un esempio comune è quello di un chatbot all'interno di uno strumento di collaborazione interna in cui i dipendenti chiedono riassunti, estraggono clausole e confrontano documenti, mentre il bot restituisce frammenti di fonti e impone limiti di visualizzazione.
Non sempre. Molti progetti utilizzano modelli esistenti per l'embedding e la generazione, per poi concentrare gli sforzi sulla preparazione dei dati, sulla qualità del recupero, sulle autorizzazioni e sul monitoraggio.
I problemi più comuni includono il recupero del chunk sbagliato, la mancanza di un contesto chiave e la possibilità di lasciare che sia l'iniezione di prompt a guidare il modello. Le verifiche di sicurezza e il monitoraggio sono di aiuto, così come i formati di risposta che rimandano al testo di partenza.
