Come costruire una pipeline RAG nel 2026 (guida passo passo)

La generazione con recupero aumentato (RAG) ha smesso di essere una semplice curiosità accademica molti anni fa. Nel 2026 è il metodo predefinito per mettere un modello linguistico di grandi dimensioni (LLM) a disposizione dei propri documenti senza dover pagare per il fine-tuning del modello o rischiare che fornisca risposte inventate con eccessiva sicurezza. Il principio è semplice da descrivere, ma pieno di insidie pratiche: individuare il testo più pertinente, fornirlo al modello e lasciare che quest’ultimo rediga la risposta.

Questa è una guida pratica alla realizzazione, non una panoramica teorica. Alla fine avrai una conoscenza precisa dei componenti necessari per una pipeline RAG funzionante nel 2026, degli strumenti specifici e delle versioni dei modelli da utilizzare, oltre a uno schema minimo di codice eseguibile in locale o tramite API. Abbiamo verificato ogni numero di versione, prezzo e benchmark riportati qui sotto confrontandoli con le fonti attuali — perché il peggiore bug RAG è quello che copi da un articolo scritto l’anno scorso per librerie ormai obsolete.

Come funziona effettivamente una pipeline RAG

Un sistema RAG opera in due fasi. Indicizzazione avviene una sola volta (o ogni volta che i tuoi documenti cambiano): suddividi i file sorgenti in blocchi, converti ciascun blocco in un vettore mediante un modello di embedding e memorizzi tali vettori in un database. Interrogazione avviene per ogni richiesta: trasformi la domanda dell’utente in un vettore tramite lo stesso modello di embedding, trovi i blocchi più simili, eventualmente li sottoponi a reranking, inserisci quelli migliori nel prompt e invochi un modello linguistico di grandi dimensioni.

Questo è l’intero concetto. La parte ingegneristica sta nei dettagli: dimensione dei blocchi, scelta del modello di embedding, numero di risultati da recuperare, necessità o meno di un reranker e modalità di valutazione dell’efficacia complessiva. Se desideri acquisire prima le basi concettuali, il nostro approfondimento su RAG tratta la teoria; questo articolo si concentra invece sulla sua implementazione pratica. Se invece stai ancora decidendo tra RAG e la personalizzazione diretta del modello, la comparazione tra fine-tuning e RAG è il punto di partenza ideale — per la maggior parte dei team che alimentano un LLM con dati privati e in continua evoluzione, RAG rappresenta la soluzione più economica e facilmente mantenibile.

Passo 1: Suddividi i tuoi documenti in blocchi

I modelli di embedding hanno un limite di contesto e, cosa ancor più importante, perdono precisione su passaggi lunghi. Pertanto, i documenti vengono suddivisi in blocchi. Il consenso del 2026, supportato da benchmark oggettivi e non da impressioni soggettive, è poco appariscente: usa uno splitter ricorsivo basato sui caratteri mirato a blocchi di circa 512 token con un’overlap del 10–20% (50–100 token).

Una valutazione condotta nel febbraio 2026 su 50 documenti reali ha rilevato che la suddivisione ricorsiva naïve in blocchi di 512 token ha ottenuto un’accuratezza di recupero pari al 69%, mentre la suddivisione semantica — che cerca di spezzare i testi lungo i confini del significato — ha raggiunto soltanto il 54%. Il motivo è banale: la suddivisione semantica ha prodotto frammenti di dimensione media pari a 43 token, troppo piccoli per fornire al modello un contesto sufficiente a rispondere correttamente. Nel frattempo, uno studio separato condotto nel gennaio 2026 con il sistema di recupero SPLADE ha evidenziato che l’aggiunta di sovrapposizione (overlap) incrementava i costi di indicizzazione senza apportare alcun beneficio misurabile sul relativo dataset. La conclusione onesta è questa: iniziare con blocchi ricorsivi di dimensione fissa e ricorrere alla suddivisione semantica o basata sulle pagine soltanto se le metriche di valutazione dimostrano inequivocabilmente che tale approccio è necessario per i vostri documenti specifici.

Passo 2: Scegli un modello di embedding

Questa è la decisione più determinante dell’intera pipeline, e la differenza tra le opzioni disponibili è reale. Di seguito sono elencate le scelte degne di considerazione a metà 2026, corredate da dati verificati.

Per un prototipo, iniziate localmente con nomic-embed-text — è veloce, gratuito, si adatta facilmente su un laptop da 16 GB ed è riportato battere l’ormai obsoleto text-embedding-ada-002di OpenAI. Per ambienti di produzione, il settore open source ha effettivamente raggiunto i leader commerciali: BGE-M3 è il modello affidabile, rilasciato con licenza MIT, adottato di default dalla maggior parte degli stack self-hosted, mentre Voyage-3.5 e Gemini Embedding guidano le classifiche dei servizi gestiti tramite API. Esiste però una regola fondamentale: qualsiasi modello usiate per incorporare i vostri documenti, dovrete utilizzare esattamente lo stesso modello anche per incorporare le query. Mescolare modelli distrugge silenziosamente le prestazioni del recupero.

Passo 3: Memorizza i vettori in un database vettoriale

Una volta ottenuti gli embedding, questi devono essere memorizzati in un sistema in grado di supportare ricerche rapide dei k vicini più prossimi. Nel 2026 avete tre livelli ragionevoli tra cui scegliere.

Un’analisi più approfondita è disponibile nel nostro guida ai database vettoriali, ma per la maggior parte dei team l’albero decisionale è semplice: già su PostgreSQL → pgvector; necessità di filtri pesanti o di miliardi di vettori → Qdrant o Milvus; semplice sperimentazione → Chroma.

Passo 4: Recupera e applica il reranking

Il recupero vero e proprio consiste in una singola chiamata: si genera l’embedding della query e si chiede al database di restituire i k frammenti più vicini (k tipicamente compreso tra 20 e 50). Tuttavia, la semplice similarità vettoriale è uno strumento grossolano. Un reranker — un cross-encoder che valuta individualmente ogni coppia query-documento — riordina tali candidati e porta in primo piano quelli realmente pertinenti, prima che raggiungano il modello linguistico.

Il pattern standard è: recuperare i primi 50 risultati con il bi-encoder, applicare il reranking e mantenere i primi 5–10. Cohere Rerank 3.5 costa $0,002 per ricerca ($2 ogni 1.000) e aggiunge tipicamente una latenza nell’ordine dei 100–300 ms. Se disponete di una GPU e desiderate azzerare i costi per ogni query, il modello open source BGE-reranker-v2-m3 impiega circa 50–100 ms ed è multilingue. Il reranking rappresenta uno degli upgrade più efficaci e meno impegnativi che si possano implementare — la maggior parte delle pipeline che «recuperano spazzatura» ne è priva.

Passo 5: Arricchisci il prompt e genera la risposta

A questo punto si compila il prompt: una breve istruzione di sistema che indica al modello di rispondere esclusivamente in base al contesto fornito, ai frammenti riordinati e alla domanda dell’utente. Quindi si invoca il modello linguistico.

Per il modello generativo potete optare per una soluzione locale o per un’API. Localmente, tramite Ollama, il compromesso ideale nel 2026 è un modello di classe 8B — ad esempio Qwen3 8B o Llama 3.1 8B quantizzato in Q4_K_M — che occupa 8–12 GB di VRAM e raggiunge velocità di generazione superiori a 40 token/secondo su una GPU moderna. Qwen3 14B (~8–9 GB in Q4) rappresenta un notevole passo avanti, con una finestra di contesto di 128K token, utile per inserire testi recuperati più lunghi. Per una soluzione ospitata con prestazioni più elevate, un modello API di ultima generazione funziona bene; il nostro tutorial sulla chatbot API Claude illustra dettagliatamente questo percorso. Un promemoria utile proveniente dagli esperti: nel caso di RAG, la qualità del recupero conta generalmente più della dimensione del modello — frammenti ben puliti, un buon embedder e un modello linguistico piccolo battono un modello enorme alimentato da un contesto scadente.

Passo 6: Uno schema minimo di codice

Di seguito è riportata un’intera pipeline locale basata su LangChain 1.x, Chroma e Ollama. Indicizza un documento ed elabora una domanda — nessuna chiave API richiesta.

# pip install langchain langchain-community langchain-chroma langchain-ollama
from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_ollama import OllamaEmbeddings, ChatOllama
from langchain_chroma import Chroma

# 1. Caricamento + suddivisione (~512 token, ~15% di sovrapposizione; le dimensioni sono in caratteri)
docs = TextLoader("handbook.txt").load()
chunks = RecursiveCharacterTextSplitter(
    chunk_size=2000, chunk_overlap=300
).split_documents(docs)

# 2. Embedding + 3. Memorizzazione
embeddings = OllamaEmbeddings(model="nomic-embed-text")
store = Chroma.from_documents(chunks, embeddings)

# 4. Recupero (primi 4)
retriever = store.as_retriever(search_kwargs={"k": 4})

# 5. Arricchimento + generazione
llm = ChatOllama(model="qwen3:8b")
question = "Qual è il periodo di rimborso?"
context = "nn".join(d.page_content for d in retriever.invoke(question))
prompt = (f"Rispondi utilizzando ESCLUSIVAMENTE il contesto fornito. Se l’informazione non è presente, indicarlo esplicitamente.nn"
          f"Contesto:n{context}nnDomanda: {question}")
print(llm.invoke(prompt).content)

Questo è l’intero ciclo. Per aggiungere il reranking, inserite un ContextualCompressionRetriever con un cross-encoder tra i passaggi 4 e 5. Con LlamaIndex 0.14.x lo stesso flusso richiede tipicamente meno codice grazie alle sue astrazioni di recupero progettate appositamente: è la scelta migliore per applicazioni fortemente orientate al recupero, mentre il runtime LangGraph di LangChain eccelle quando sono necessari agenti con stato e multi-step. (La scelta di un livello di orchestrazione è un argomento a sé stante; vedi la nostra comparazione dei framework per agenti AI.)

Passo 7: Valuta — non saltare questo passaggio

La differenza tra una demo e un prodotto reale sta nella misurazione. Lo strumento standard è RAGAS, che valuta la fedeltà (l’output si è attenuto al contesto fornito?), la precisione del contesto e il richiamo del contesto utilizzando un modello linguistico come giudice. Crea un piccolo set di 20–50 coppie domanda-risposta estratte dai tuoi documenti reali ed eseguilo ad ogni modifica.

Questo è anche il modo per prendere onestamente ogni decisione precedente. Dovresti passare al chunking semantico? Aggiungere un reranker? Aumentare k da 4 a 8? Non indovinare: modifica una sola variabile, riesegui RAGAS e mantieni la modifica solo se i risultati migliorano. Senza questo ciclo, stai ottimizzando alla cieca.

Domande frequenti

Quanto costa eseguire una pipeline RAG?

Quasi gratis per la fase di prototipazione. Con gli embedding locali Ollama, Chroma e un LLM locale, l’unico costo è quello dell’elettricità. A scala industriale, le voci principali di spesa sono il database vettoriale (un’istanza self-hosted di Qdrant o pgvector su una tua VM è notevolmente più economica rispetto alle soluzioni gestite, il cui costo può superare i 5.000 dollari al mese per 100 milioni di vettori) e, qualora tu utilizzi API, gli embedding (OpenAI text-embedding-3-large costa 0,13 dollari per milione di token) oltre alle chiamate di generazione.

Ho davvero bisogno di un database vettoriale, oppure posso usare un database tradizionale?

Hai bisogno della ricerca vettoriale, ma non necessariamente di un prodotto dedicato. pgvector aggiunge questa funzionalità a PostgreSQL e gestisce 1 milione di vettori con bassa latenza p95 (pochi millisecondi su NVMe, leggermente superiori su SSD cloud); quindi, se già utilizzi PostgreSQL, puoi evitare completamente nuove infrastrutture. Opta per un database dedicato come Qdrant solo quando hai bisogno di filtri avanzati sui metadati o devi gestire miliardi di vettori.

Qual è la dimensione ideale dei chunk?

Inizia con circa 512 token e un sovrapposizione del 10–20% usando uno splitter ricorsivo. Un benchmark del 2026 ha rilevato che questo approccio supera il chunking semantico in termini di accuratezza del recupero nel 69% dei casi contro il 54%. Passa a tecniche di chunking più sofisticate solo se le metriche di valutazione dimostrano un effettivo miglioramento sui tuoi documenti specifici.

Un reranker è davvero necessario?

Non per ottenere un sistema funzionante, ma rappresenta uno degli interventi più economici per migliorare la qualità. Recupera un ampio insieme (top 50), applica il reranking con Cohere Rerank 3.5 o con il modello open-source BGE-reranker-v2-m3, e conserva solo i primi 5–10 risultati. La maggior parte delle pipeline che restituiscono chunk irrilevanti semplicemente omette questo passaggio.

Posso costruire una pipeline RAG senza LangChain o LlamaIndex?

Sì. Il ciclo fondamentale — embedding, ricerca, prompt, generazione — richiede circa 40 righe di Python puro che chiamano direttamente il tuo modello di embedding, il client del database vettoriale e il modello linguistico. I framework risparmiano tempo su loader, reranker e orchestrazione di agenti, ma sono opzionali; costruire tutto da zero ti offre il pieno controllo su ogni singolo passaggio.

Devo usare un modello locale o un’API per la generazione?

Un modello locale (tramite Ollama, con un modello da 8B su 8–12 GB di VRAM) è ottimo per privacy, controllo dei costi e uso offline. Un’API ti garantisce invece una qualità superiore e zero operazioni da gestire. Molte squadre sviluppano inizialmente in locale per iterare a basso costo, poi scelgono caso per caso, in base alla sensibilità dei dati e al budget disponibile.

Come mantengo aggiornato l’indice man mano che i documenti cambiano?

Rigenera e inserisci (upsert) solo i contenuti modificati, anziché ricostruire l’intero indice. Tieni traccia di un hash del contenuto o della data di modifica per ogni documento sorgente e, in caso di aggiornamento, elimina i vecchi chunk associati a quel documento e inseriscine di nuovi. La maggior parte dei database vettoriali supporta upsert e cancellazioni basate su filtri sui metadati, rendendo così gli aggiornamenti incrementali semplici e affidabili.

Conclusione

Costruire una pipeline RAG nel 2026 è davvero accessibile: sei fasi, un numero limitato di strumenti consolidati e circa 40 righe di codice per arrivare a un prototipo funzionante. Le insidie non risiedono nell’architettura, bensì nei valori predefiniti. Usa chunk noiosi da 512 token, assicurati che gli embedder per query e documenti coincidano, aggiungi un reranker e non ottimizzare mai senza avere RAGAS integrato nel ciclo di valutazione. Inizia in locale e gratuitamente con nomic-embed-text, Chroma e un modello Ollama da 8B; sostituisci progressivamente singoli componenti con pgvector, Qdrant, Voyage o un’API all’avanguardia solo quando sono i tuoi numeri di valutazione — e non un articolo su un blog — a indicartelo. Ottieni un recupero accurato e persino un modello di piccole dimensioni ti porterà molto lontano.