Lo stack RAG open source nel 2026: componenti, infrastruttura e build vs buy

Uno stack RAG open source nel 2026 è composto da cinque mattoni: un parser per estrarre il testo dai documenti, una pipeline di chunking, un modello di embedding, un vector store con ricerca ibrida e un livello di orchestrazione che genera la risposta. Montarli insieme funziona per un prototipo in un weekend, ma portarli in produzione richiede infrastruttura, monitoraggio e manutenzione continua: è qui che si gioca la vera scelta tra costruire e comprare.

Che cosa intendiamo per stack RAG open source

Negli ultimi anni l'ecosistema open source attorno al RAG (retrieval augmented generation) si è consolidato attorno a poche categorie di strumenti: librerie di parsing documentale, framework di orchestrazione (tipo LangChain, LlamaIndex, Haystack), database vettoriali autogestibili (Qdrant, Milvus, Weaviate, pgvector su PostgreSQL) e motori di ricerca full-text come Elasticsearch o OpenSearch spesso combinati con i vettori. Nessuno di questi componenti fa RAG da solo: è l'integrazione tra loro, più un modello linguistico per la generazione, a costituire lo stack completo.

La buona notizia è che oggi si può assemblare un prototipo funzionante in pochi giorni usando solo componenti gratuiti. La notizia meno buona è che il passaggio dal prototipo a un sistema affidabile, usato ogni giorno da colleghi o clienti, comporta costi e competenze che raramente vengono preventivati all'inizio.

I mattoni di uno stack RAG open source

Parsing ed estrazione dei documenti

Il primo problema pratico è trasformare PDF, Word, slide e pagine HTML in testo pulito. Librerie come Apache Tika o progetti più recenti nati specificamente per il RAG gestiscono tabelle, intestazioni ripetute, colonne multiple e OCR per i documenti scansionati. Qui si annida la prima fonte di errori silenziosi: un PDF con tabelle mal interpretate produce chunk incoerenti che nessun modello di embedding potrà salvare.

Chunking e preparazione del testo

Dividere il testo in porzioni (chunk) di dimensione adeguata è una decisione architetturale, non un dettaglio tecnico. Chunk troppo corti perdono contesto, chunk troppo lunghi diluiscono la rilevanza semantica e aumentano i costi di generazione. Le strategie più usate nello stack open source vanno dal chunking a lunghezza fissa con overlap fino a quello semantico basato su titoli e paragrafi. Abbiamo approfondito l'argomento in Chunking per RAG: come dividere i documenti per risposte migliori.

Modelli di embedding

I modelli di embedding open source (disponibili su hub pubblici) trasformano ogni chunk in un vettore numerico che cattura il significato. La scelta del modello influenza qualità del retrieval, costo di calcolo e supporto multilingue, un aspetto che in Italia pesa spesso più del previsto quando i documenti sono in italiano ma le domande arrivano anche in inglese o viceversa: ne parliamo in RAG multilingue: come interrogare documenti in lingue diverse dalla domanda.

Vector store e ricerca ibrida

Il database vettoriale conserva gli embedding e risponde alle query di similarità. Nello stack open source le opzioni più diffuse sono Qdrant, Milvus, Weaviate o semplicemente l'estensione pgvector su un PostgreSQL già esistente. La tendenza del 2026 è combinare sempre la ricerca vettoriale con quella lessicale classica (BM25): i soli vettori faticano con acronimi, codici prodotto o riferimenti normativi esatti. Il tema è centrale ed è trattato in dettaglio in Ricerca ibrida: perché BM25 e vettori insieme battono entrambi da soli.

Orchestrazione e generazione

L'ultimo livello recupera i chunk più pertinenti, li assembla in un prompt e li invia a un modello linguistico per generare la risposta finale, idealmente con citazione delle fonti. Framework come LangChain, LlamaIndex o Haystack offrono componenti pronti per questo orchestrazione, ma richiedono comunque di scrivere e mantenere il codice applicativo, gestire i timeout, i fallback e il logging delle risposte.

Cosa serve davvero per farlo girare in produzione

Montare lo stack è la parte più semplice. Farlo funzionare in modo affidabile nel tempo richiede attività che spesso restano fuori dai preventivi iniziali:

• Infrastruttura: server o istanze cloud per il vector store, storage per i documenti originali, eventuale GPU per l'inferenza degli embedding se non si usano API esterne.
• Pipeline di aggiornamento: quando un documento cambia bisogna ri-estrarre, ri-chunkare e ri-indicizzare, senza duplicare i vettori obsoleti.
• Monitoraggio della qualità: serve un modo per misurare se il retrieval recupera i chunk giusti e se le risposte sono corrette, non solo se il sistema risponde. Ne parliamo in Come valutare un sistema RAG: metriche, test set e monitoraggio.
• Sicurezza e conformità: controllo accessi, cifratura, gestione delle chiavi API, e per le organizzazioni italiane la verifica dei requisiti GDPR sulla localizzazione dei dati e sui sub-responsabili del trattamento.
• Patch e aggiornamenti delle librerie open source, che introducono regolarmente breaking change tra una versione e l'altra.
• Competenze interne: qualcuno in azienda deve capire embedding, retrieval e prompt engineering abbastanza da fare debugging quando le risposte peggiorano senza una causa ovvia.

Build vs buy: come decidere

La domanda non è se l'open source funzioni, perché funziona, lo dimostrano moltissimi progetti interni avviati come proof of concept. La domanda è se la Sua organizzazione ha la capacità e la volontà di mantenere nel tempo un sistema che ha più componenti mobili di un semplice CRM. Ecco un confronto sulle dimensioni che contano davvero.

In pratica, costruire da zero conviene quando ha requisiti molto specifici (un modello di embedding proprietario, un'infrastruttura già esistente da riusare, vincoli di sovranità del dato molto stringenti) e un team capace di mantenerlo. Affidarsi a un servizio conviene quando l'obiettivo è avere risposte affidabili sui propri documenti in tempi brevi, senza assumere un ingegnere dedicato solo a tenere in piedi la pipeline.

Un esempio di stack minimale per iniziare

Se vuole comunque sperimentare con componenti open source prima di decidere, uno stack minimale ragionevole per una PMI con qualche centinaio di documenti potrebbe essere questo:

1. Un parser documentale open source per estrarre testo da PDF e Word.
2. Una strategia di chunking semantico basata su titoli e paragrafi, non a lunghezza fissa.
3. Un modello di embedding multilingue scaricabile da un hub pubblico, eseguito su CPU se i volumi sono contenuti.
4. PostgreSQL con estensione pgvector, già familiare a molti team, combinato con un indice full-text nativo per la ricerca ibrida.
5. Un framework di orchestrazione leggero per assemblare prompt e chiamare il modello linguistico, con logging delle risposte per poterle rivedere.

Questo stack minimale è un buon esercizio didattico e permette di capire davvero come funziona il RAG passo dopo passo, un percorso che raccontiamo in dettaglio in Come funziona il RAG, passo dopo passo: una domanda reale seguita dall'inizio alla fine. Ma resta un prototipo: prima di metterlo davanti a clienti o colleghi servono i presidi di monitoraggio e sicurezza visti sopra.

Quando scegliere l'open source puro, quando un servizio gestito

Alcuni fattori spostano la bilancia verso l'una o l'altra opzione. Se opera in un settore regolamentato e deve rispondere a domande precise su obblighi di trasparenza algoritmica, conviene prima chiarire cosa impone la normativa: lo trova spiegato in AI Act e assistenti RAG: quali obblighi riguardano le basi di conoscenza e in GDPR e RAG: cosa verificare prima di partire. Se invece il problema è semplicemente avere un confronto più ampio tra le piattaforme disponibili, può leggere Piattaforme RAG as a service a confronto: pipeline gestite, database vettoriali e marketplace di basi di conoscenza o, per chi valuta solo il database vettoriale, Alternative a Pinecone per piccoli team: pgvector, motori open source e basi di conoscenza ospitate.

Un servizio come Kopik nasce esattamente per chi vuole saltare la parte infrastrutturale: Lei carica i documenti, Kopik li estrae, li suddivide in chunk e li indicizza per la ricerca ibrida (full-text più espansione semantica), e può interrogarli dal sito, via API REST con chiavi dedicate, oppure tramite un server MCP collegabile a Claude, Cursor o ChatGPT. Le basi possono restare private, visibili solo a Lei e alle Sue integrazioni, oppure essere pubblicate nel catalogo e generare un ricavo per ogni domanda ricevuta, con il 70% trattenuto da chi ha creato la base.

Un'ultima considerazione: RAG non è sempre la risposta

Prima di investire tempo nell'uno o nell'altro approccio, vale la pena chiedersi se il problema richieda davvero il retrieval o se un modello a contesto lungo, che accetta l'intero documento nel prompt, possa bastare per i Suoi volumi. Abbiamo confrontato i due approcci in RAG vs modelli a contesto lungo: quando conviene l'uno e quando l'altro: in sintesi, sotto poche decine di pagine il contesto lungo è spesso più semplice, oltre quella soglia e con documenti che cambiano spesso il RAG resta la scelta più sostenibile.

In sintesi

Lo stack RAG open source nel 2026 è maturo, documentato e gratuito nella licenza, ma non nel tempo che richiede. La scelta tra costruirlo internamente e affidarsi a un servizio gestito dipende meno dalla disponibilità di strumenti e più dalla capacità della Sua organizzazione di mantenerli, aggiornarli e monitorarli nel tempo. Per molte PMI e professionisti, partire da un servizio pronto all'uso e passare all'open source solo quando emergono requisiti specifici è la strada più pragmatica.

Domande frequenti