Architettura GraphRAG e RAG

Il divario tra "chunk semanticamente simili" e "risposte corrette e complete" è il punto in cui la maggior parte dei deployment RAG aziendali fallisce. Lo Stanford AI Lab ha rilevato che il 40% delle risposte RAG presenta allucinazioni anche quando vengono recuperati i documenti corretti. Il recupero ha funzionato. Il grounding no.

Perché il RAG recupera documenti, non risposte

Ciò accade perché la normale similarità vettoriale non è in grado di distinguere tra un passaggio tematicamente pertinente e uno che risponde effettivamente alla domanda. Quando il vostro team di conformità chiede "quali sono i requisiti di notifica per una violazione dei dati che interessa residenti nell'UE con meno di 16 anni?" e il sistema restituisce tre chunk sulla notifica delle violazioni del GDPR privi delle disposizioni specifiche relative all'età, la risposta sembra corretta ma è pericolosamente incompleta.

Il nostro approccio consiste nel realizzare sistemi di recupero progettati per colmare questo divario. L'architettura che scegliamo dipende dai vostri documenti, dalle vostre query e dalla vostra tolleranza per le risposte errate. In alcuni casi si tratta di un recupero ibrido BM25 + denso con un reranker cross-encoder. In altri è una pipeline GraphRAG completa con estrazione di entità e sintesi delle community. In altri ancora è un loop di recupero agentico che scompone domande complesse, effettua recuperi iterativi e si autocorregge prima della generazione. Non ricorriamo per impostazione predefinita all'opzione più complessa: scegliamo quella che risolve il vostro problema di recupero a un costo che potete sostenere nel tempo.

Tre architetture di recupero, scelte in base ai vostri pattern di query

Adattiamo l'architettura ai vostri pattern di query invece di ricorrere per impostazione predefinita alla complessità. I tre pattern seguenti coprono la maggior parte delle esigenze di produzione.

Recupero ibrido con reranking

È qui che la maggior parte dei sistemi RAG in produzione dovrebbe iniziare. BM25 gestisce la corrispondenza esatta delle parole chiave (codici di errore, SKU di prodotto, riferimenti a citazioni normative), mentre gli embedding densi catturano l'intento semantico. La Reciprocal Rank Fusion (RRF, k=60) unisce i due insiemi di risultati senza i problemi di normalizzazione dei punteggi che affliggono gli approcci di fusione basati su apprendimento.

Al vertice si colloca un reranker cross-encoder: BGE-reranker-v2-m3 su GPU garantisce una latenza di 50–100 ms a zero costi continui di API, oppure Cohere Rerank per i team che preferiscono un'infrastruttura gestita. I benchmark di produzione mostrano che questa pipeline a due stadi supera tutti i metodi a stadio singolo. Il contextual retrieval di Anthropic si aggiunge come ulteriore livello, riducendo gli errori di recupero del 49% (67% con il reranking) anteponendo il contesto a livello di documento a ciascun chunk prima dell'embedding.

Recupero potenziato da grafi (GraphRAG)

Quando le vostre domande richiedono la sintesi di informazioni provenienti da più documenti o il ragionamento sulle relazioni tra entità, la sola similarità vettoriale non è sufficiente. Un team legale che chieda "quali controllate di AcquiringCo hanno procedimenti normativi pendenti nelle giurisdizioni in cui opera TargetCo?" necessita di entity resolution, attraversamento delle relazioni e ragionamento multi-hop.

Costruiamo knowledge graph a partire dai vostri documenti, impiegando un'estrazione basata sulle dipendenze che raggiunge il 94% delle prestazioni basate su LLM a una frazione del costo in token (dettagliata nella nostra ricerca sul GraphRAG con verifica delle citazioni). Il GraphRAG di Microsoft come approccio (clustering di Leiden + sintesi delle community) è efficace per le query di comprensione globale a livello di corpus, ma i suoi costi di indicizzazione sono da 4 a 8 volte superiori rispetto al RAG standard. Lo utilizziamo in modo selettivo:

• Sintesi delle community per query globali.
• Attraversamento di property graph per domande sulle relazioni tra entità.
• Recupero vettoriale standard per tutto il resto.

Come backing store per i grafi, FalkorDB gestisce carichi di lavoro RAG ad alta intensità di lettura a 6.693 QPS con cold start inferiori al millisecondo, mentre Neo4j rimane la scelta d'elezione quando sono necessari RBAC maturo, clustering e aggregazioni complesse.

Recupero agentico

Il pattern dalle capacità più elevate nel 2026, nonché il più costoso da implementare a regola d'arte. Un loop di recupero agentico scompone query complesse in sotto-query, instrada ciascuna verso la strategia di recupero appropriata (vettoriale, su grafo o database strutturato), valuta se i risultati siano sufficienti e itera fino al raggiungimento delle soglie di confidenza previste.

Implementiamo questa architettura su LangGraph, dove l'astrazione basata su macchina a stati offre diramazioni condizionali, nodi di interruzione human-in-the-loop e verificabilità deterministica. I livelli di Corrective RAG aggiungono 100–800 ms di latenza per query, ma intercettano gli errori di recupero prima che raggiungano l'LLM. Questo pattern è pronto per la produzione presso Morgan Stanley, PwC e ServiceNow. Non è invece adatto a team privi di capacità ML ops dedicate per monitorare e ottimizzare i loop di recupero.

Cosa accade prima dell'embedding: impostare correttamente il chunking

Il chunking è la fase in cui i sistemi RAG falliscono silenziosamente. Un chunking ingenuo a dimensione fissa produce punteggi di fedeltà (faithfulness) pari a 0,47–0,51. Il chunking semantico raggiunge 0,79–0,82, ma richiede la generazione di embedding per ogni singola frase del corpus. La strategia corretta dipende dalla tipologia dei vostri documenti:

• Documenti normativi strutturati — il parsing sensibile al layout preserva la gerarchia delle sezioni.
• PDF a contenuto misto con tabelle e grafici — il chunking guidato dalla visione artificiale (trattando ciascuna pagina come immagine per il rilevamento del layout ed estraendo successivamente le regioni di testo) migliora la precisione di recupero dell'8–15% rispetto al parsing basato su solo testo.
• Documenti narrativi estesi — il late chunking elabora prima l'intero documento attraverso il transformer in modo che l'embedding di ciascun token rifletta il contesto bidirezionale, applicando poi i confini dei chunk dopo il forward pass.

Testiamo da tre a quattro strategie di chunking sul vostro set effettivo di query prima di sceglierne una. L'harness di valutazione (metriche RAGAS di fedeltà + precisione del contesto, valutazioni di pertinenza specifiche per il dominio) fa parte integrante della pipeline, non è un ripensamento successivo. Il 60% dei nuovi deployment RAG include ora una valutazione sistematica fin dal primo giorno, rispetto a meno del 30% all'inizio del 2025. Integriamo la valutazione nella vostra CI/CD in modo che la qualità del recupero sia misurata a ogni rilascio, anziché essere scoperta quando gli utenti inviano reclami.

Quanto costa gestire un sistema RAG aziendale?

Un'azienda manifatturiera ha speso 400.000 $ per implementare un sistema RAG, per poi scoprire che le operazioni continue costavano 18.000 $/mese — più del doppio rispetto alle loro stime. La voce di costo trascurata: il reranking. Le API di embedding costano 20–120 $ per miliardo di token. L'hosting di database vettoriali per 10 milioni di vettori costa da 1,5 a 3 volte di più con servizi gestiti (Pinecone, Weaviate Cloud) rispetto al self-hosting (Qdrant, pgvector). Ma è il reranking sui volumi di query di produzione a far esplodere i budget: Cohere Rerank costa 2 $ per 1.000 query, mentre BGE-reranker-v2-m3 self-hosted su una singola GPU eguaglia tale latenza a zero costi per query — sebbene si paghi l'istanza GPU.

GraphRAG aggiunge un ulteriore livello di costo. La costruzione del knowledge graph consuma da 4 a 8 volte più token rispetto al testo originale per l'estrazione delle entità e la sintesi delle community. La manutenzione assorbe il 40–60% del budget ingegneristico del primo anno poiché entity resolution, deduplicazione e aggiornamenti dell'ontologia costituiscono un lavoro continuativo, non una configurazione una tantum. L'estrazione basata sulle dipendenze (NLP classico invece di chiamate LLM) riduce i costi di costruzione di circa il 90% mantenendo il 94% della qualità di estrazione. Definiamo l'ambito di ogni incarico con proiezioni esplicite del run-rate mensile relative a embedding, archiviazione, recupero, reranking e manutenzione del grafo.

Quando vale la pena adottare GraphRAG (e quando no)

Il recupero potenziato da grafi è necessario quando le query richiedono un ragionamento multi-hop tra entità e relazioni:

• Due diligence per fusioni e acquisizioni (M&A) su centinaia di documenti di filiali societarie.
• Sintesi delle evidenze cliniche attraverso database di interazioni farmacologiche.
• Analisi del rischio nella supply chain che collega le reti di fornitori alle azioni normative.

GraphRAG offre la sua massima precisione di ricerca su query aziendali complesse a più livelli nei benchmark (si veda una demo funzionante di recupero legale con verifica delle citazioni). Non ne avete bisogno se le vostre query sono ricerche su un singolo documento, risposte in stile FAQ o ricerche basate su parole chiave — il recupero ibrido BM25 + denso con un reranker gestisce questi casi a una frazione del costo e della complessità. Se il vostro corpus contiene meno di 5 milioni di vettori e le vostre domande non oltrepassano i confini tra documenti, pgvector con indicizzazione HNSW è davvero sufficiente. Valutiamo questo aspetto prima di consigliare un'architettura e vi diciamo con trasparenza quando la soluzione più semplice è quella giusta.

Anche la domanda "abbiamo davvero bisogno del RAG?" è rilevante. Con finestre di contesto che superano 1 milione di token (Gemini 3 Pro a 10M), alcuni team valutano di inserire interi corpus nel prompt. Il problema: una singola query da 1 milione di token costa 2–10 $, il che è insostenibile sui volumi di query aziendali. La qualità del contesto si degrada oltre determinate soglie anche entro i limiti dichiarati. Il RAG rimane l'architettura idonea per qualsiasi sistema che gestisca query ricorrenti su insiemi di documenti ampi e variabili.

Qual è la superficie di attacco di una pipeline RAG?

La ricerca PoisonedRAG (USENIX Security 2025) ha dimostrato che cinque documenti accuratamente manipolati e iniettati in un corpus di un milione di documenti possono alterare le risposte dell'IA con oltre il 90% di successo. La vostra pipeline di recupero è un canale di ingresso per contenuti avversariali. L'OWASP riconosce ormai formalmente le vulnerabilità nei vettori e negli embedding (LLM08:2025) e la prompt injection tramite documenti recuperati (LLM01:2025) come primari rischi di sicurezza per gli LLM.

Integriamo nella pipeline di recupero il tracciamento della provenienza dei documenti, il rilevamento delle anomalie a livello di embedding e livelli di sanificazione dell'input. Ogni passaggio recuperato include metadati sull'origine e punteggi di affidabilità. Il livello di generazione è vincolato a citare passaggi specifici, e le affermazioni che non possono essere ancorate al contenuto recuperato vengono contrassegnate anziché trasmesse direttamente. Tutto ciò non è facoltativo per alcun sistema RAG operativo in ambienti regolamentati, come descritto in dettaglio nella nostra ricerca sulla sicurezza degli LLM aziendali privati.

Cosa forniamo

Ogni nostro incarico include:

• Un'architettura di recupero selezionata per i vostri specifici pattern di query e tipologie di documenti.
• Una strategia di chunking ed embedding sottoposta a benchmark sulle vostre query effettive.
• Un harness di valutazione di livello enterprise con metriche RAGAS e casi di test specifici per il vostro dominio.
• Proiezioni esplicite dei costi comprensive di embedding, archiviazione, recupero, reranking ed eventuale manutenzione del grafo.
• Hardening di sicurezza contro attacchi basati sul recupero.
• Uno stack di monitoraggio che rileva il degrado della qualità di recupero prima che lo facciano gli utenti.

Vi indichiamo inoltre chiaramente quando la vostra configurazione attuale è già adeguata e l'investimento in un recupero più complesso non si ripagherebbe.