Sfoglia altri articoli simili con le etichette:
Le aziende italiane mi chiedono sempre più spesso un RAG sui documenti interni. La domanda di partenza è quasi sempre identica: “lo facciamo in casa o passiamo da Microsoft Copilot?”.
La risposta dipende da tre variabili che pochi mettono in fila prima di scegliere. Quanti documenti, quanto sensibili, quanti utenti.
Sotto i 50 GB di documentazione, sotto le 30 query al giorno, con dati non particolarmente sensibili: Copilot o ChatGPT Enterprise vincono per costo totale di possesso. Sopra quelle soglie, oppure quando i documenti contengono informazioni che non possono uscire dal perimetro aziendale per ragioni normative, un RAG locale ha senso eccome.
Quando un RAG locale ha senso, e quando no
Il RAG locale non è ideologia. È una scelta di trade-off.
Ha senso quando i documenti contengono dati personali sensibili (sanità, legale, HR), quando il volume di query è sostenuto, quando vuoi tracciare nel dettaglio ogni chiamata al modello, quando hai un team tecnico in grado di mantenerlo. Non ha senso quando il caso d’uso è “vorrei chiedere domande al PDF della guida HR”, che è un caso d’uso da quattordici utenti al mese e che si risolve con un Custom GPT, come ho descritto nel pezzo sull’uso pratico di ChatGPT in azienda.
L’errore più frequente che vedo: aziende che investono settantamila euro in un’infrastruttura RAG per poi usarla con sei persone, due query al giorno, su documentazione che non era nemmeno sensibile. Sopravvalutazione del problema, sottovalutazione del costo totale.
Il secondo errore: scegliere on-prem solo perché “non vogliamo che i dati escano dall’azienda”. È una motivazione legittima, ma da tradurre in requisiti concreti. Vincoli GDPR specifici? Clausole contrattuali con clienti che impongono data residency? Settori regolati (sanità, finanza, difesa)? Se la risposta è “non vogliamo perché non ci piace l’idea”, la spesa probabilmente non è giustificata e una soluzione SaaS con DPA solido copre il rischio reale.
I quattro pezzi dell’architettura
Un RAG operativo si regge su quattro componenti. Cambiano gli strumenti, non la struttura di base.
Prima componente: ingest pipeline. Legge i documenti dalla loro fonte (filesystem, SharePoint, Drive, S3), li parsa, li ripulisce, li spezza in chunk, genera embedding e li scrive in un vector database. Va eseguita all’inizio per caricare la knowledge base, e poi in modo incrementale ogni volta che cambia un documento.
Seconda componente: vector database. Indicizza gli embedding e supporta retrieval semantico veloce. Le opzioni serie nel 2026 sono Qdrant, Pinecone, Chroma, Weaviate. Più qualche soluzione integrata in PostgreSQL via pgvector per chi non vuole aggiungere un servizio dedicato.
Terza componente: il retrieval layer. Quando arriva una query, viene trasformata in embedding, viene fatto match con i chunk più rilevanti nel vector DB, viene composto un contesto e passato all’LLM. Qui si gioca la qualità del sistema più che altrove. Un retrieval mediocre con un LLM eccellente produce risposte mediocri. Un retrieval eccellente con un LLM medio produce risposte buone.
Quarta componente: il modello LLM. Locale (Llama 3 70B, Mistral Large) oppure via API (Claude Sonnet 4, GPT-4o, Gemini 2.5). La scelta dipende da costi, latenza, requisiti di privacy.
LangChain contro LlamaIndex, la scelta vera
LangChain e LlamaIndex sono i due framework dominanti nel 2026 per costruire pipeline RAG. Hanno funzionalità sovrapposte ma filosofie diverse.
LangChain è generalista. Buona per applicazioni AI complesse dove RAG è solo un pezzo: agenti, tool calling, orchestrazione di chain multiple. Curva di apprendimento più alta. API che cambiano più spesso. Integrazioni con tool esterni più estese.
LlamaIndex è specialista RAG. Buona per chi vuole solo “fammi parlare con questi documenti, bene”. Curva di apprendimento più bassa. API più stabili. Strumenti di valutazione retrieval più maturi.
Per i progetti su cui ho lavorato negli ultimi mesi, parto da LlamaIndex per il primo MVP, e passo a LangChain solo se il caso d’uso evolve verso scenari agentici. In tre casi su quattro non serve nemmeno passare. Questo cambia se il progetto include flussi di prompt engineering complessi con chain multiple, dove LangChain ha un vantaggio strutturale.
Esiste una terza opzione che pochi considerano: usare i framework solo per i pezzi che ti servono e scrivere il resto a mano in Python. Per progetti dove il vincolo è la stabilità di lungo periodo, un’implementazione minimale (cinquecento righe di Python che usano solo openai-python o anthropic-python più il client del vector DB) è più mantenibile di una pipeline LangChain piena di astrazioni che cambiano ogni sei mesi.
Vector database, le opzioni che restano
Le tre opzioni serie per il 2026 sono Qdrant, Pinecone e Chroma. Pgvector è valida quando hai già PostgreSQL in azienda e non vuoi aggiungere un servizio dedicato.
Qdrant è open source, self-hostabile, performance eccellenti, scritto in Rust. È quello che consiglio quando il vincolo principale è “i dati non escono dai nostri server”. Hosted su Hetzner o OVH si parte da circa 80 euro al mese per setup minimi.
Pinecone è SaaS only. Eccellente velocità, scalabilità ottima, ma il costo cresce con il volume. Per progetti che partono piccoli con incognita di crescita, ha senso. Per progetti dove sai già che processerai terabyte, costa parecchio.
Chroma è il più leggero. Adatto a MVP, prototipi, casi d’uso piccoli. Su volumi seri va sostituito.
Weaviate è la quarta opzione, valida soprattutto per chi cerca multi-tenancy nativa. La cito solo per completezza, perché nelle scelte concrete dei miei clienti italiani non è quasi mai entrata.
Pgvector merita un paragrafo a parte. Funziona molto bene fino a qualche milione di embedding, è gratis se hai già PostgreSQL in produzione, non aggiunge servizi nuovi da monitorare. Limiti: sopra i 5-10 milioni di vettori le performance calano sensibilmente rispetto a Qdrant, e le funzionalità di filtraggio metadati complessi sono meno potenti. Per RAG aziendali di dimensione media, è spesso la scelta più ragionevole, e quella che richiede meno mantenimento operativo.
Embedding e chunking, dove si vince
Il 70 per cento della qualità di un RAG dipende da come spezzi i documenti e da quale modello di embedding usi. Tutto il resto è hardware e ottimizzazione.
Il chunking ingenuo (spezzo ogni 1.000 caratteri) funziona male. Il chunking semantico (spezzo per paragrafi, per sezioni, per significato) funziona molto meglio. LlamaIndex ha un semantic splitter pronto. LangChain richiede un po’ più di lavoro di configurazione.
Sul modello di embedding, nel 2026 le scelte serie sono tre. OpenAI text-embedding-3-large (potente, in cloud, circa 0,13 dollari per milione di token). Voyage AI voyage-3 (eccellente per contenuti tecnici e legali). BGE-large multilingual (open source, gira su una GPU consumer, gratuito ma più lento).
Per progetti in italiano consiglio voyage-3 multilingual o, se il vincolo è 100 per cento on-prem, BGE-large fine-tunato sul dominio del cliente. Il fine-tuning del modello di embedding sul vocabolario specifico del cliente migliora la retrieval del 15-25 per cento nei casi concreti che ho misurato.
Un dettaglio operativo che fa differenza: il chunk size ottimale dipende dal tipo di documento. Per testi giuridici, 512-768 token funziona meglio (mantengono unità logiche tipo articoli di legge). Per documentazione tecnica, 256-512 token (preserva il dettaglio delle istruzioni). Per email e ticket di customer support, 128-256 token (le interazioni sono brevi e ogni chunk grosso include rumore). Testare su un set di query reali prima di congelare il valore.
Sopra l’embedding c’è un secondo livello che fa molta differenza: il reranking. Dopo aver recuperato venti chunk dal vector DB, si passano a un modello di reranking (Cohere Rerank, Voyage Rerank, oppure soluzioni open come bge-reranker) che li riordina per pertinenza effettiva alla query. Aggiunge cento millisecondi di latenza e migliora la qualità della risposta finale del 20-30 per cento nei progetti reali. È il singolo intervento con miglior rapporto sforzo/risultato sull’intera pipeline, ed è quasi sempre saltato nelle implementazioni di fretta.
Costi reali, in casa contro SaaS
Numeri grezzi su un caso reale di novembre 2025. Cliente legal, 12 GB di documenti, 80 query al giorno, 18 utenti.
Opzione SaaS (ChatGPT Enterprise più caricamento documenti): circa 60 dollari per utente al mese, totale 1.080 dollari/mese, dati che escono dal perimetro aziendale.
Opzione RAG in casa: server Hetzner da 200 euro/mese, Qdrant self-hosted, LlamaIndex su Python, Claude Sonnet via API per generazione (circa 250 euro/mese di chiamate a quei volumi). Setup iniziale dai 12.000 ai 22.000 euro a seconda della complessità dell’ingest. Costo ricorrente totale: circa 500 euro/mese. Dati che restano in casa per la parte di indicizzazione, mentre il modello di generazione resta in API (versione fully on-prem aggiunge 800-1.500 euro/mese di GPU rental, e va calcolata a parte).
Break-even a circa 10-12 mesi se il caso d’uso è stabile. Sotto i 6 mesi se cresce. Sopra i 18 mesi se gli utenti restano fermi a 18 o calano.
La maggior parte delle aziende sbaglia il calcolo perché ignora il costo di manutenzione mensile. Lo aggiungo qui sotto perché è la parte che salta sempre.
Manutenzione, il pezzo dimenticato
Un RAG installato non è un RAG finito. La manutenzione mensile è il 20-30 per cento del costo totale di possesso, e quasi tutti la sottostimano in fase di business case.
Cose da fare in modo ricorrente: monitorare la qualità del retrieval con un set di query di controllo (almeno 30, riviste ogni mese), aggiornare la knowledge base quando i documenti cambiano, ri-embeddare quando esce un modello migliore di embedding, aggiornare il codice quando LlamaIndex o LangChain rilasciano breaking change, ottimizzare i prompt quando l’LLM sotto cambia versione.
Il set di query di controllo merita un’attenzione che pochi gli danno. Si costruisce all’inizio del progetto, con almeno trenta domande reali raccolte dagli utenti previsti, ognuna abbinata alla risposta attesa e ai documenti che dovrebbero essere recuperati. Questo set diventa la suite di test automatici: ogni modifica al sistema (nuovo modello di embedding, modifica al chunk size, aggiornamento prompt) viene validata contro il set prima del rollout. Senza questa suite, ogni modifica è una scommessa.
Senza una persona dedicata almeno mezza giornata a settimana, il RAG degrada in sei mesi. Non smette di funzionare. Smette di funzionare bene. Che è peggio, perché nessuno se ne accorge subito.
Il segnale più affidabile del degrado: feedback degli utenti. Quando le persone smettono di usare il sistema senza dare motivazione esplicita, qualcosa nella qualità è cambiato. Va monitorato il volume di query settimanale, non solo le metriche tecniche di retrieval. Se le query calano del trenta per cento in due mesi, c’è un problema da indagare prima che il sistema diventi inutilizzato.
Per chi entra in questo terreno per la prima volta, vale la pena confrontarsi con AIPIA, la community italiana professionisti AI, dove diversi soci stanno costruendo progetti RAG su domini regolati (sanità, legale, PA) e condividono benchmark concreti. È più utile di sei white paper di vendor messi insieme.
Un RAG locale non è la scelta giusta per tutti. Quando è la scelta giusta, vale tre volte la spesa. Quando è quella sbagliata, vale tre volte meno. La differenza sta nel dimensionamento corretto del caso d’uso prima del kickoff, non nella tecnologia che scegli dopo. Investi due settimane in discovery prima di firmare, non due settimane di selezione vendor dopo aver firmato.
