Che cos'è il RAG e come funziona (guida per principianti)
Che cos'è il RAG? La risposta breve: un sistema che collega un LLM ai tuoi documenti perché risponda con fatti reali invece di inventare. La risposta lunga è questa guida. Niente matematica, nessun framework imposto — solo i componenti (embedding, database vettoriale, LLM) e come si concatenano. Alla fine, saprai perché un RAG ben fatto produce molte meno allucinazioni e da dove iniziare in locale.
#Il RAG in 30 secondi
RAG significa Retrieval-Augmented Generation: generazione di testo potenziata dalla ricerca. Invece di chiedere direttamente al LLM «rispondi a questa domanda», si comincia cercando in una base di documenti i passaggi più pertinenti, poi li si incolla nel prompt dicendo: «ecco le fonti, rispondi basandoti su di esse».
Un'immagine efficace: un LLM da solo è uno studente brillante che risponde a memoria a un esame. Un RAG è lo stesso studente che può consultare il materiale del corso sul tavolo. Inventa meno, cita la pagina giusta e, se gli viene dato materiale di un corso che non ha mai visto (i tuoi PDF, le tue email, il tuo wiki interno), può comunque rispondere a domande su quel materiale.
#Perché (e quando) averne bisogno
I tuoi documenti, la tua IA: un RAG locale affidabile sui tuoi PDF, sulle tue note e sulle tue email — senza inviare nulla nel cloud.
- Spazio online a vita
- PDF + file
- Aggiornamenti a vita
Un LLM ha due grosse debolezze che emergono appena lo si usa seriamente: inventa quando non sa (le famose « allucinazioni ») e conosce solo i dati visti durante l'addestramento. Qwen 3.5 9B non ha mai letto il tuo contratto, il tuo wiki Notion, né il tuo archivio degli incidenti. Chiedergli di rispondere direttamente a domande su questi contenuti è come chiedere a qualcuno di immaginare il contenuto di un libro che non ha aperto.
Il RAG risolve entrambi contemporaneamente: si inseriscono gli estratti giusti nel prompt, il LLM li usa come base fattuale e le risposte diventano tracciabili — puoi visualizzare le fonti.
- Parlare con i tuoi PDF
- Documentazione tecnica, contratti, articoli scientifici, manuali: tutto ciò che è troppo voluminoso per rientrare in una finestra di contesto.
- Assistente interno per il team
- Wiki, base di conoscenza per l'assistenza, documentazione del prodotto. Al posto di un Ctrl+F approssimativo, una risposta in francese che cita le pagine corrette.
- Monitoraggio e sintesi
- Indicizzare centinaia di articoli o rapporti, porre domande trasversali, confrontare fonti.
- Dati recenti o privati
- Tutto ciò che il LLM non ha potuto vedere: il tuo codice, le tue email, pubblicazioni successive alla data limite delle sue conoscenze.
#La pipeline in 4 fasi
Un RAG comprende due fasi: l'indicizzazione (una sola volta, prima delle interrogazioni) e l'interrogazione (a ogni domanda). Ecco i quattro componenti che si susseguono.
- 011. Chunking — dividere i documentiI tuoi PDF, file Markdown o pagine web vengono prima suddivisi in blocchi (chunk) di circa 200–800 parole. Non si può generare l'embedding di un intero libro in una sola volta e, comunque, si vuole ritrovare il passaggio preciso che risponde alla domanda, non tutto il documento.
- 022. Embeddings — trasformare il testo in vettoriOgni chunk passa attraverso un modello di embedding che lo trasforma in un vettore di numeri (tipicamente da 384 a 1024 dimensioni). Due passaggi che parlano della stessa cosa genereranno vettori vicini in questo spazio — è questa la magia che permette la ricerca semantica.
- 033. Archiviazione in un database vettorialeI vettori + il testo originale vengono memorizzati in un database specializzato (Chroma, Qdrant, FAISS…) che sa rispondere velocemente alla domanda «quali sono i vettori più vicini al mio?».
- 044. Recupero + generazioneQuando l'utente pone una domanda, si calcola l'embedding della domanda, si recuperano da 3 a 10 chunk più vicini, si inseriscono nel prompt del LLM con un'istruzione del tipo «rispondi basandoti su questi estratti» e il LLM genera la risposta.
#Embeddings: il cuore del retrieval
Un modello di embedding è un piccolo LLM specializzato in una sola attività: trasformare un pezzo di testo in un vettore di numeri che cattura il suo «senso». Due frasi che parlano dello stesso argomento daranno vettori vicini, anche se non hanno nessuna parola in comune. È questo che distingue il RAG da un semplice Ctrl+F.
La qualità finale del RAG dipende dal modello di embedding tanto quanto — e spesso più che — dal LLM che lo affianca. Un embedding di scarsa qualità recupera i segmenti di testo sbagliati, e il miglior LLM del mondo non potrà rispondere correttamente a partire da brani fuori tema.
- nomic-embed-text
- 137M parametri, 768 dimensioni, contesto di 8192 token. Una scelta predefinita sensata proposta da Ollama. Buono in inglese, discreto in francese.
- mxbai-embed-large
- 335M parametri, 1024 dimensioni. Più preciso, 3 volte più lento. Utile quando la qualità del retrieval è il fattore limitante.
- multilingual-e5-large
- 560M, 1024 dimensioni. La scelta migliore se i tuoi documenti sono in francese o multilingui.
- bge-m3
- Eccellente in francese, supporta contesti lunghi. Più pesante da eseguire, ma di riferimento per contenuti plurilingui.
#Il database vettoriale: dove vivono i vettori
Un database vettoriale è un database specializzato in un'operazione: «trovami i N vettori più vicini a questo». Dietro le quinte, utilizza algoritmi (HNSW, IVF…) che rendono questa ricerca veloce anche su milioni di vettori. Per iniziare, non serve capire nulla di questi algoritmi: basta sapere quale database scegliere.
- Chroma
- Database vettoriale open source, integrato nel tuo progetto Python o eseguito come server. Ideale per iniziare: zero configurazione, persistenza su disco.
- Qdrant
- Più robusto per la produzione: server dedicato, filtri, multi-tenant. Funziona in un container Docker con un solo comando.
- FAISS
- Libreria di Facebook (Meta). Molto veloce, ma è solo un indice — senza gestione dei metadati. Adatta ai casi in cui le prestazioni sono cruciali.
- Archiviata nello strumento
- Open WebUI, AnythingLLM e LM Studio integrano un proprio database vettoriale. Tutto avviene in modo invisibile: carichi un PDF e viene indicizzato. Perfetto per iniziare senza programmare.
#L'LLM: generazione guidata
Il LLM è l'ultimo anello della catena. Riceve un prompt simile a questo: «Ecco 5 estratti dalla documentazione. Rispondi alla domanda basandoti esclusivamente su di essi. Se l'informazione non è presente negli estratti, dichiaralo.»
Questa impostazione cambia tutto. Senza contesto inserito, il LLM risponde attingendo alla memoria acquisita durante l'addestramento e inventa se questa è incompleta. Con gli estratti giusti nel prompt, ha una base fattuale sotto gli occhi e si limita a riformulare o a sintetizzare.
- Quale dimensione per il LLM?
- Per un RAG semplice, un piccolo modello del 2026 che rientri in 8 GB (Qwen 3.5 9B, Granite 4.2 8B) è più che sufficiente. La qualità del retrieval conta più delle dimensioni del LLM.
- Quale finestra di contesto?
- Almeno 4096 token. I chunk recuperati, la domanda e l'istruzione di sistema consumano rapidamente 2000-3000 token. Con 8192 o più, hai un buon margine.
- Quale system prompt?
- Qualcosa del genere: «Rispondi in francese basandoti esclusivamente sugli estratti forniti. Se l'informazione non c'è, dillo chiaramente.»
#RAG locale vs API cloud
Puoi costruire un RAG con l'API di OpenAI o di Claude (rapido da configurare, prestazioni massime) oppure interamente in locale con Ollama + un database vettoriale + un modello di embedding (nessuna fuga di dati, nessun costo d'uso). La scelta dipende dalla sensibilità dei documenti e dal tuo budget.
- RAG tramite API cloud
- I tuoi documenti vengono inviati al fornitore (OpenAI, Anthropic, Mistral…) durante l'indicizzazione e a ogni domanda. Prestazioni e qualità eccellenti, ma incompatibili con dati riservati (RGPD, segreto medico, contratti con i clienti).
- RAG 100% locale
- Ollama per il LLM, nomic o bge per gli embedding, Chroma o Qdrant per il database. Nessun dato lascia la macchina. Ideale per i professionisti (giuristi, medici, addetti alle risorse umane), le aziende soggette al GDPR e tutti quelli che vogliono mantenere il controllo.
- Ibrido
- Embedding locali, LLM tramite API: riduce l'esposizione (i documenti completi rimangono locali, solo i chunk pertinenti vanno in cloud in risposta alla domanda). Compromesso pratico ma non consigliato se i chunk stessi sono sensibili.
#Da dove iniziare concretamente
Tre percorsi in base al tuo profilo. Tutti e tre funzionano al 100% localmente sulla tua macchina.
- 01Senza programmare, con un'interfaccia (Open WebUI o AnythingLLM)Installi Ollama, avvii Open WebUI o AnythingLLM in Docker, carichi i tuoi PDF in una « Knowledge Base » e inizi a chattare. Tutto — chunking, embedding, recupero — viene gestito per te. 30 minuti dall'inizio alla fine.
- 02Senza dover scrivere codice, in modalità tutto in uno (LM Studio)Dalla versione 0.3, LM Studio dispone della funzionalità «Chat with Documents»: alleghi un file alla chat e il programma se ne occupa. Limite: 5 file per chat e una scelta limitata di formati (PDF testuali, DOCX, TXT, MD). Perfetto per domande occasionali su un documento.
- 03In Python con LangChain o LlamaIndexControllo totale: scelta del chunker, del modello di embedding, della banca dati, dell'LLM e del prompt. Prevedi mezza giornata per un primo prototipo ben fatto, di più se vuoi ottimizzare (reranker, ricerca ibrida, ecc.).
#Le trappole classiche quando si inizia
- Embedder in inglese, documenti in francese
- Causa numero 1 di risultati deludenti con il RAG in Francia. Verifica che il tuo modello di embedding supporti il francese (multilingual-e5, bge-m3).
- Chunk troppo grandi o troppo piccoli
- Una lunghezza di 500 parole è un buon punto di partenza. Se i chunk sono troppo piccoli (< 100 parole), perdono il loro contesto; se sono troppo grandi (> 1500), l'embedding fa la media di tutto e perde precisione.
- Cambiare l'embedder senza reindicizzare
- I vettori di un modello non sono compatibili con quelli di un altro. Se passi da nomic a bge, devi reindicizzare tutto — altrimenti il retrieval restituisce risultati senza senso.
- Troppi chunk nel contesto
- Oltre 8-10 chunk, il LLM comincia a perdersi. Meglio 5 chunk molto pertinenti che 20 mediamente pertinenti (è qui che entra in gioco un reranker, a un livello più avanzato).
- Nessuna citazione visualizzata
- Per verificare che un RAG funzioni davvero, mostra le fonti utilizzate per ogni risposta. Se non hai questa visibilità, non saprai distinguere una buona risposta da un'allucinazione convincente.
#Per approfondire
Ora che sai cos'è il RAG, ecco le guide che costituiscono il passo successivo per passare alla pratica.
- RAG locale con Ollama senza scrivere codice
- Guida passo passo Open WebUI + AnythingLLM per costruire il tuo primo RAG in 30 minuti, anche senza GPU.
- I migliori modelli di embedding FR
- Confronto dettagliato per scegliere tra nomic, multilingual-e5, bge-m3 e Solon in base al tuo corpus.
- RAG locale: introduzione
- Guida concettuale approfondita: chunking, retrieval, reranking, metriche di valutazione.
- Cos'è Ollama e come funziona
- Se non hai ancora installato Ollama, dai un'occhiata qui.
Un feedback, un errore, una precisazione? Facci sapere, così la guida migliora per tutti.