Architetture avanzate di RAG arricchite con graph: Oltre la ricerca vettoriale in produzione

Introduzione al RAG arricchito con graph

Il Retrieval-Augmented Generation (RAG) è diventato lo standard per fondere modelli linguistici su larga scala (LLMs) con dati privati. L'architettura standard — frammentare documenti, crearne embedding e recuperare i risultati top-k tramite similarità di coseno — è efficace per la ricerca semantica non strutturata.

Eppure, per domini aziendali che coinvolgono dati fortemente connessi (catena di fornitura, conformità finanziaria, rilevamento frodi), il RAG a sola ricerca vettoriale spesso non regge. Cattura la similarità ma perde la struttura. Si trova in difficoltà con domande complesse che richiedono ragionamento multistep, come: "Come influenzerà il ritardo nel Componente X la consegna Q3 per il Cliente Y?"

In questo articolo presenterò il modello RAG arricchito con grafici. Sfruttando esperienze personali nella costruzione di sistemi di log ad alta capacità in Meta e infrastrutture dati private in Cognee, esplorerò un'architettura di riferimento che unisce la flessibilità semantica della ricerca vettoriale con la deterministica strutturale dei database grafici.

Quando la ricerca vettoriale perde il contesto

I database vettoriali sono eccellenti per catturare il significato ma perdono la topologia. Quando un documento viene frammentato e incapsulato, le relazioni esplicite (gerarchia, dipendenza, proprietà) vengono spesso appiattite o rimosse del tutto.

Immagine un scenario di rischio nella catena di fornitura. Benché sia un esempio ipotetico, rappresenta esattamente la classe di problemi strutturali che costantemente osserviamo nelle architetture dati aziendali:

• Dati strutturati: Un database SQL che definisce che il Fornitore A fornisce il Componente X alla Fonderia Y.
• Dati non strutturati: Un rapporto di notizie che afferma: "Allagamenti in Thailandia hanno interrotto la produzione del sito del Fornitore A."

Una ricerca standard per "riflessi produttivi" recupererà il report di notizie. Probabilmente, però, mancherà contesto per collegare questo report all'output della Fonderia Y. Il LLM riceve la notizia ma non è in grado di rispondere alla domanda critica aziendale: "Quali stabilimenti a valle sono a rischio?"

In produzione, questo si traduce in errori o allucinazioni. Il LLM tenta di collegare la notizia al problema di stabilimento, ma non ha il collegamento esplicito, quindi azzarda relazioni o risponde "Non lo so" nonostante i dati siano presenti nel sistema.

Modello ibrido: Da RAG piatto a RAG a grafico

Per risolvere questa situazione, passiamo da un "RAG piatto" a un'architettura RAG a grafico. Questo richiede una pila a tre livelli:

Ingestion (La Lezione da Meta)

Nel lavoro presso Meta con le infrastrutture per i log di Shops, abbiamo imparato che la struttura deve essere impostata all'ingestion. Non puoi garantire analisi affidabili se provi a ricostruire la struttura da log disordinati in seguito. Analogamente, con il RAG dobbiamo estrarre entità (nodi) e relazioni (spigoli) durante l'ingestone. Si può utilizzare un modello LLM o un modello di riconoscimento di entità nominate (NER) per estrarre entità da frammenti di testo e collegarle a record esistenti all'interno del grafico.

Archiviazione

Utilizziamo un database di grafici (come Neo4j) per memorizzare i dati strutturali. Gli embedding vettoriali vengono immagazzinati come proprietà su nodi specifici (esempio: un nodo "Evento di rischio").

Recupero

Eseguiamo una query ibrida:

• Scansione vettoriale: Trovare punti di ingresso nel grafico in base alla similarità semantica.
• Trasverso di grafico: Trasversare relazioni da quei punti per raccogliere contesto.

Questo permette al LLM di ricevere un payload strutturato, non frammenti casuistici di testo:

[{'issue': 'Gravi allagamenti...', 'impactedsupplier': 'TechChip Inc', 'riskto_factory': 'Assemblaggio alfa'}]

Consente al LLM di rispondere in modo preciso:

"Gli allagamenti a TechChip Inc mettono a rischio l'assemblaggio alfa."

Lezioni in produzione: Latenza e coerenza

Portare questa architettura da un notebook alla produzione richiede di gestire compromessi.

• La tassa di latenza
  

  Gli spostamenti di grafico sono più onerosi di semplici accessi vettoriali. Dalla mia esperienza presso Meta nel lavoro sull'esperimento immagine, abbiamo affrontato budget di latenza strict dove ogni millisecondo impatti l'esperienza utente. La lezione architettonica si applica direttamente al RAG a Grafico: non puoi permetterti di calcolare tutto in tempo reale.
  

  • RAG a sola ricerca vettoriale: tempo di recupero ~50-100ms.
  • RAG arricchito con grafico: tempo di recupero ~200-500ms (dipendente dalla profondità dello spostamento).

Riduzione: Utilizziamo un'implementazione di caching semantica. Se un utente fa una domanda simile (similarità di coseno > 0.85) a una precedente, forniamo un risultato grafico cachato. Questo riduce la "tassa grafica" per richieste frequenti.
• Il problema dell'arco "non aggiornato"
  

  Nel caso dei database vettoriali, i dati sono indipendenti. Nel grafico, i dati dipendono l'uno dagli altri. Se il fornitore A non fornisce più la fonderia Y, ma l'arco è ancora nel grafico, il sistema RAG hallucinerà un collegamento che non esiste più.
  

  Riduzione: Gli spigoli grafici devono avere un Tempo di vita (TTL) o essere sincronizzati tramite pipeline di Capture di Dati di Modifica (CDC) da una fonte autorevole.

Modello decisionale per infrastruttura: Adottare RAG a grafico o no?

Ecco il framework che utilizziamo presso Cognee per decidere se adottare RAG a grafico:

Utilizzare RAG a sola ricerca vettoriale se:

• Il corpus è piano (esempio: un wiki caotico o dump di canali Slack).
• Le domande sono di ampio spettro ("Come resettare la mia VPN?").
• Leggi l'articolo originale →
  ← Torna alle news