{"id":7200,"date":"2026-06-12T09:38:00","date_gmt":"2026-06-12T07:38:00","guid":{"rendered":"https:\/\/rafaelpatron.com\/blog\/?p=7200"},"modified":"2026-06-12T09:38:00","modified_gmt":"2026-06-12T07:38:00","slug":"rag-locale-documenti-aziendali","status":"publish","type":"post","link":"https:\/\/rafaelpatron.com\/blog\/tool\/rag-locale-documenti-aziendali\/","title":{"rendered":"RAG locale per documenti aziendali: il setup minimo nel 2026"},"content":{"rendered":"<p>Le aziende italiane mi chiedono sempre pi\u00f9 spesso un RAG sui documenti interni. La domanda di partenza \u00e8 quasi sempre identica: &#8220;lo facciamo in casa o passiamo da Microsoft Copilot?&#8221;.<\/p>\n<p>La risposta dipende da tre variabili che pochi mettono in fila prima di scegliere. Quanti documenti, quanto sensibili, quanti utenti.<\/p>\n<p>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.<\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_86 counter-flat ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Indice dei contenuti<\/p>\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"Toggle Table of Content\"><span class=\"ez-toc-js-icon-con\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/rafaelpatron.com\/blog\/tool\/rag-locale-documenti-aziendali\/#quando-un-rag-locale-ha-senso-e-quando-no\" >Quando un RAG locale ha senso, e quando no<\/a><\/li><li class='ez-toc-page-1'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/rafaelpatron.com\/blog\/tool\/rag-locale-documenti-aziendali\/#i-quattro-pezzi-dellarchitettura\" >I quattro pezzi dell&#8217;architettura<\/a><\/li><li class='ez-toc-page-1'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/rafaelpatron.com\/blog\/tool\/rag-locale-documenti-aziendali\/#langchain-contro-llamaindex-la-scelta-vera\" >LangChain contro LlamaIndex, la scelta vera<\/a><\/li><li class='ez-toc-page-1'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/rafaelpatron.com\/blog\/tool\/rag-locale-documenti-aziendali\/#vector-database-le-opzioni-che-restano\" >Vector database, le opzioni che restano<\/a><\/li><li class='ez-toc-page-1'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/rafaelpatron.com\/blog\/tool\/rag-locale-documenti-aziendali\/#embedding-e-chunking-dove-si-vince\" >Embedding e chunking, dove si vince<\/a><\/li><li class='ez-toc-page-1'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/rafaelpatron.com\/blog\/tool\/rag-locale-documenti-aziendali\/#costi-reali-in-casa-contro-saas\" >Costi reali, in casa contro SaaS<\/a><\/li><li class='ez-toc-page-1'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/rafaelpatron.com\/blog\/tool\/rag-locale-documenti-aziendali\/#manutenzione-il-pezzo-dimenticato\" >Manutenzione, il pezzo dimenticato<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"quando-un-rag-locale-ha-senso-e-quando-no\"><\/span>Quando un RAG locale ha senso, e quando no<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Il RAG locale non \u00e8 ideologia. \u00c8 una scelta di trade-off.<\/p>\n<p>Ha senso quando i documenti contengono dati personali sensibili (sanit\u00e0, legale, HR), quando il volume di query \u00e8 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&#8217;uso \u00e8 &#8220;vorrei chiedere domande al PDF della guida HR&#8221;, che \u00e8 un caso d&#8217;uso da quattordici utenti al mese e che si risolve con un Custom GPT, come ho descritto nel pezzo sull&#8217;<a href=\"https:\/\/rafaelpatron.com\/blog\/ai\/chatgpt-marketing-aziende-italiane\/\">uso pratico di ChatGPT in azienda<\/a>.<\/p>\n<p>L&#8217;errore pi\u00f9 frequente che vedo: aziende che investono settantamila euro in un&#8217;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.<\/p>\n<p>Il secondo errore: scegliere on-prem solo perch\u00e9 &#8220;non vogliamo che i dati escano dall&#8217;azienda&#8221;. \u00c8 una motivazione legittima, ma da tradurre in requisiti concreti. Vincoli GDPR specifici? Clausole contrattuali con clienti che impongono data residency? Settori regolati (sanit\u00e0, finanza, difesa)? Se la risposta \u00e8 &#8220;non vogliamo perch\u00e9 non ci piace l&#8217;idea&#8221;, la spesa probabilmente non \u00e8 giustificata e una soluzione SaaS con DPA solido copre il rischio reale.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"i-quattro-pezzi-dellarchitettura\"><\/span>I quattro pezzi dell&#8217;architettura<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Un RAG operativo si regge su quattro componenti. Cambiano gli strumenti, non la struttura di base.<\/p>\n<p>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&#8217;inizio per caricare la knowledge base, e poi in modo incrementale ogni volta che cambia un documento.<\/p>\n<p>Seconda componente: vector database. Indicizza gli embedding e supporta retrieval semantico veloce. Le opzioni serie nel 2026 sono Qdrant, Pinecone, Chroma, Weaviate. Pi\u00f9 qualche soluzione integrata in PostgreSQL via pgvector per chi non vuole aggiungere un servizio dedicato.<\/p>\n<p>Terza componente: il retrieval layer. Quando arriva una query, viene trasformata in embedding, viene fatto match con i chunk pi\u00f9 rilevanti nel vector DB, viene composto un contesto e passato all&#8217;LLM. Qui si gioca la qualit\u00e0 del sistema pi\u00f9 che altrove. Un retrieval mediocre con un LLM eccellente produce risposte mediocri. Un retrieval eccellente con un LLM medio produce risposte buone.<\/p>\n<p>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.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"langchain-contro-llamaindex-la-scelta-vera\"><\/span>LangChain contro LlamaIndex, la scelta vera<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>LangChain e LlamaIndex sono i due framework dominanti nel 2026 per costruire pipeline RAG. Hanno funzionalit\u00e0 sovrapposte ma filosofie diverse.<\/p>\n<p>LangChain \u00e8 generalista. Buona per applicazioni AI complesse dove RAG \u00e8 solo un pezzo: agenti, tool calling, orchestrazione di chain multiple. Curva di apprendimento pi\u00f9 alta. API che cambiano pi\u00f9 spesso. Integrazioni con tool esterni pi\u00f9 estese.<\/p>\n<p>LlamaIndex \u00e8 specialista RAG. Buona per chi vuole solo &#8220;fammi parlare con questi documenti, bene&#8221;. Curva di apprendimento pi\u00f9 bassa. API pi\u00f9 stabili. Strumenti di valutazione retrieval pi\u00f9 maturi.<\/p>\n<p>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&#8217;uso evolve verso scenari agentici. In tre casi su quattro non serve nemmeno passare. Questo cambia se il progetto include flussi di <a href=\"https:\/\/rafaelpatron.com\/blog\/ai\/prompt-engineering-tecniche-marketing\/\">prompt engineering complessi con chain multiple<\/a>, dove LangChain ha un vantaggio strutturale.<\/p>\n<p>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 \u00e8 la stabilit\u00e0 di lungo periodo, un&#8217;implementazione minimale (cinquecento righe di Python che usano solo openai-python o anthropic-python pi\u00f9 il client del vector DB) \u00e8 pi\u00f9 mantenibile di una pipeline LangChain piena di astrazioni che cambiano ogni sei mesi.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"vector-database-le-opzioni-che-restano\"><\/span>Vector database, le opzioni che restano<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Le tre opzioni serie per il 2026 sono Qdrant, Pinecone e Chroma. Pgvector \u00e8 valida quando hai gi\u00e0 PostgreSQL in azienda e non vuoi aggiungere un servizio dedicato.<\/p>\n<p>Qdrant \u00e8 open source, self-hostabile, performance eccellenti, scritto in Rust. \u00c8 quello che consiglio quando il vincolo principale \u00e8 &#8220;i dati non escono dai nostri server&#8221;. Hosted su Hetzner o OVH si parte da circa 80 euro al mese per setup minimi.<\/p>\n<p>Pinecone \u00e8 SaaS only. Eccellente velocit\u00e0, scalabilit\u00e0 ottima, ma il costo cresce con il volume. Per progetti che partono piccoli con incognita di crescita, ha senso. Per progetti dove sai gi\u00e0 che processerai terabyte, costa parecchio.<\/p>\n<p>Chroma \u00e8 il pi\u00f9 leggero. Adatto a MVP, prototipi, casi d&#8217;uso piccoli. Su volumi seri va sostituito.<\/p>\n<p>Weaviate \u00e8 la quarta opzione, valida soprattutto per chi cerca multi-tenancy nativa. La cito solo per completezza, perch\u00e9 nelle scelte concrete dei miei clienti italiani non \u00e8 quasi mai entrata.<\/p>\n<p>Pgvector merita un paragrafo a parte. Funziona molto bene fino a qualche milione di embedding, \u00e8 gratis se hai gi\u00e0 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\u00e0 di filtraggio metadati complessi sono meno potenti. Per RAG aziendali di dimensione media, \u00e8 spesso la scelta pi\u00f9 ragionevole, e quella che richiede meno mantenimento operativo.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"embedding-e-chunking-dove-si-vince\"><\/span>Embedding e chunking, dove si vince<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Il 70 per cento della qualit\u00e0 di un RAG dipende da come spezzi i documenti e da quale modello di embedding usi. Tutto il resto \u00e8 hardware e ottimizzazione.<\/p>\n<p>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&#8217; pi\u00f9 di lavoro di configurazione.<\/p>\n<p>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\u00f9 lento).<\/p>\n<p>Per progetti in italiano consiglio voyage-3 multilingual o, se il vincolo \u00e8 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.<\/p>\n<p>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\u00e0 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.<\/p>\n<p>Sopra l&#8217;embedding c&#8217;\u00e8 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\u00e0 della risposta finale del 20-30 per cento nei progetti reali. \u00c8 il singolo intervento con miglior rapporto sforzo\/risultato sull&#8217;intera pipeline, ed \u00e8 quasi sempre saltato nelle implementazioni di fretta.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"costi-reali-in-casa-contro-saas\"><\/span>Costi reali, in casa contro SaaS<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Numeri grezzi su un caso reale di novembre 2025. Cliente legal, 12 GB di documenti, 80 query al giorno, 18 utenti.<\/p>\n<p>Opzione SaaS (ChatGPT Enterprise pi\u00f9 caricamento documenti): circa 60 dollari per utente al mese, totale 1.080 dollari\/mese, dati che escono dal perimetro aziendale.<\/p>\n<p>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\u00e0 dell&#8217;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).<\/p>\n<p>Break-even a circa 10-12 mesi se il caso d&#8217;uso \u00e8 stabile. Sotto i 6 mesi se cresce. Sopra i 18 mesi se gli utenti restano fermi a 18 o calano.<\/p>\n<p>La maggior parte delle aziende sbaglia il calcolo perch\u00e9 ignora il costo di manutenzione mensile. Lo aggiungo qui sotto perch\u00e9 \u00e8 la parte che salta sempre.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"manutenzione-il-pezzo-dimenticato\"><\/span>Manutenzione, il pezzo dimenticato<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Un RAG installato non \u00e8 un RAG finito. La manutenzione mensile \u00e8 il 20-30 per cento del costo totale di possesso, e quasi tutti la sottostimano in fase di business case.<\/p>\n<p>Cose da fare in modo ricorrente: monitorare la qualit\u00e0 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&#8217;LLM sotto cambia versione.<\/p>\n<p>Il set di query di controllo merita un&#8217;attenzione che pochi gli danno. Si costruisce all&#8217;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 \u00e8 una scommessa.<\/p>\n<p>Senza una persona dedicata almeno mezza giornata a settimana, il RAG degrada in sei mesi. Non smette di funzionare. Smette di funzionare bene. Che \u00e8 peggio, perch\u00e9 nessuno se ne accorge subito.<\/p>\n<p>Il segnale pi\u00f9 affidabile del degrado: feedback degli utenti. Quando le persone smettono di usare il sistema senza dare motivazione esplicita, qualcosa nella qualit\u00e0 \u00e8 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&#8217;\u00e8 un problema da indagare prima che il sistema diventi inutilizzato.<\/p>\n<p>Per chi entra in questo terreno per la prima volta, vale la pena confrontarsi con <a href=\"https:\/\/aipia.it\/\">AIPIA, la community italiana professionisti AI<\/a>, dove diversi soci stanno costruendo progetti RAG su domini regolati (sanit\u00e0, legale, PA) e condividono benchmark concreti. \u00c8 pi\u00f9 utile di sei white paper di vendor messi insieme.<\/p>\n<p>Un RAG locale non \u00e8 la scelta giusta per tutti. Quando \u00e8 la scelta giusta, vale tre volte la spesa. Quando \u00e8 quella sbagliata, vale tre volte meno. La differenza sta nel dimensionamento corretto del caso d&#8217;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.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Quando un RAG locale ha senso, architettura in quattro componenti, scelta tra LangChain e LlamaIndex, vector database, embedding, chunking e costi reali a confronto con il SaaS.<\/p>\n","protected":false},"author":10,"featured_media":2384,"comment_status":"","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_wds_title":"RAG locale 2026: setup, vector DB e costi reali","_wds_metadesc":"RAG locale per documenti aziendali nel 2026: architettura, LangChain vs LlamaIndex, vector DB, embedding, costi reali e manutenzione.","_wds_focus-keywords":"rag locale documenti","_wds_canonical":"","wds_primary_category":0,"footnotes":"","_wds_robots-noindex":"0","_wds_robots-nofollow":"0","_wds_opengraph-title":"","_wds_opengraph-description":"","_wds_twitter-title":"","_wds_twitter-description":""},"categories":[168,106],"tags":[578,575,576,574,577],"class_list":["post-7200","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai","category-tool","tag-ai-aziendale","tag-langchain","tag-llamaindex","tag-rag","tag-vector-database"],"_links":{"self":[{"href":"https:\/\/rafaelpatron.com\/blog\/wp-json\/wp\/v2\/posts\/7200"}],"collection":[{"href":"https:\/\/rafaelpatron.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rafaelpatron.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rafaelpatron.com\/blog\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/rafaelpatron.com\/blog\/wp-json\/wp\/v2\/comments?post=7200"}],"version-history":[{"count":1,"href":"https:\/\/rafaelpatron.com\/blog\/wp-json\/wp\/v2\/posts\/7200\/revisions"}],"predecessor-version":[{"id":7304,"href":"https:\/\/rafaelpatron.com\/blog\/wp-json\/wp\/v2\/posts\/7200\/revisions\/7304"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rafaelpatron.com\/blog\/wp-json\/wp\/v2\/media\/2384"}],"wp:attachment":[{"href":"https:\/\/rafaelpatron.com\/blog\/wp-json\/wp\/v2\/media?parent=7200"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rafaelpatron.com\/blog\/wp-json\/wp\/v2\/categories?post=7200"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rafaelpatron.com\/blog\/wp-json\/wp\/v2\/tags?post=7200"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}