Perché una risposta sicura può essere peggiore di nessuna risposta
Hai finito di costruire il chatbot interno. Lo nutri con ogni policy HR, specifica tecnica e documento di onboarding in possesso della tua azienda. Un nuovo dipendente chiede informazioni sul limite di rimborso spese per le cene con i clienti. Il bot risponde istantaneamente. Sembra sicuro di sé. Il limite che indica è di 75 $ a persona.
La policy reale prevede 50 $. Il bot ha inventato la risposta. Non ha mai aperto i tuoi file. Ha semplicemente tirato a indovinare, basandosi su pattern sepolti nei suoi dati di addestramento di anni fa. Questa è la dura realtà di far girare modelli linguistici di grandi dimensioni (LLM) puri su documenti privati. Non hanno accesso alla tua conoscenza interna. Quando i fatti di cui hanno bisogno si trovano al di fuori dei loro pesi di addestramento, fabbricano risposte invece di ammettere l'ignoranza. In produzione, questo smette di essere divertente e inizia a diventare un rischio.
La Retrieval-Augmented Generation, o RAG, è stata creata proprio per risolvere questo problema. Invece di chiedere al modello di ricordare tutto, gli permetti di cercare le informazioni.
Dal tirare a indovinare al leggere
Pensa a un LLM puro come a un collega brillante con una memoria fotografica, ma che ha lasciato l'azienda prima del tuo arrivo. Può scrivere prosa eloquente, risolvere enigmi logici e spiegare concetti in termini semplici. Chiedigli però delle modifiche alle API dell'ultimo trimestre e inventerà semplicemente qualcosa che suoni plausibile. Non ha altra scelta.
La RAG dà a quel collega l'accesso a un archivio. Quando un utente pone una domanda, il sistema non lancia la domanda ciecamente al modello. Prima recupera i documenti rilevanti, li inserisce nel prompt come contesto e solo allora chiede al modello di leggere e rispondere. Il modello passa dal richiamo di fatti alla comprensione di fatti che si trovano letteralmente davanti a lui.
Questo flusso si divide nettamente in due fasi: il lavoro preparatorio offline e la risposta online.
Fase 1: La fase di preparazione (Offline)
Molto prima che qualcuno digiti una domanda, devi trasformare la tua disordinata collezione di documenti in una base di conoscenza ricercabile. Questo lavoro preparatorio determina se il tuo sistema RAG prospererà o fallirà silenziosamente.
I document loader sono il tuo punto di partenza. Questi connettori estraggono testo grezzo da PDF, spazi di lavoro Notion, cartelle SharePoint, pagine web e wiki interne. È qui che la realtà colpisce per la prima volta. Un loader potrebbe estrarre testo pulito da un documento Word, ma bloccarsi su un PDF scansionato che è in realtà solo un'immagine senza un livello di testo incorporato. Il loader restituisce una stringa vuota, il tuo database non memorizza nulla e l'utente riceverà in seguito una risposta "Non lo so" senza alcun preavviso. Verifica sempre cosa hanno effettivamente estratto i tuoi loader. Esegui dei controlli a campione su un manipolo di documenti da ogni fonte prima di fidarti della pipeline.
Segue il text splitting, chiamato anche chunking. Non puoi inserire una policy di sicurezza di ottanta pagine in un prompt tutto in una volta; supereresti i limiti di contesto e sommergeresti il segnale nel rumore. Invece, dividi i documenti in chunk. Il trucco è scegliere la dimensione giusta. I chunk troppo piccoli, come singole frasi, spesso perdono il contesto critico. Un chunk che recita "Tutte le richieste devono essere approvate dal manager" dimentica di menzionare che questa regola si applica solo ai viaggi internazionali. I chunk troppo grandi, come interi capitoli, diluiscono l'embedding e confondono il recupero perché coprono quindici argomenti diversi contemporaneamente. In pratica, molti team iniziano con chunk compresi tra 300 e 500 token, con una sovrapposizione di 50 token in modo che le frasi che attraversano il confine non vengano stravolte. Regola questo parametro in base al tuo contenuto. La documentazione API tollera chunk più piccoli. I contratti legali spesso richiedono chunk più grandi per preservare la logica condizionale.
Una volta suddiviso, ogni pezzo viene convertito in un embedding. Ciò significa far passare il testo attraverso un modello che restituisce un elenco di numeri, un vettore, che rappresenta il significato semantico del chunk. Idee simili atterrano vicine tra loro in questo spazio matematico. "policy di matching 401k" e "regole per i contributi pensionistici" saranno più vicini tra loro rispetto a "policy di matching 401k" e "configurazione stampante ufficio". Questi vettori vengono memorizzati in un vector database, come Pinecone, Weaviate o un'alternativa open-source come Chroma. Il vector store non è solo un deposito. È un indice ottimizzato per la ricerca dei vicini più prossimi approssimata (approximate nearest-neighbor search), che ti permette di trovare i chunk più rilevanti in millisecondi, anche tra milioni di documenti.
Fase 2: Il percorso live (Online)
Quando un utente chiede finalmente: "Qual è la nostra politica di rimborso spese di viaggio per le cene con i clienti?", la pipeline live si attiva.
Il