Due modi diversi di rispondere alla stessa domanda
Chiedi a un assistente AI "come gestiamo l'autenticazione in questo progetto?". Un sistema RAG (Retrieval-Augmented Generation) classico cerca nei tuoi documenti i chunk di testo più simili semanticamente alla domanda, e li passa al modello come contesto aggiuntivo. Un knowledge graph fa una cosa diversa: cerca il nodo più rilevante, e poi può seguire i suoi collegamenti tipizzati per portare a galla anche il perché di quella scelta, non solo il testo che la descrive.
Non sono due implementazioni dello stesso problema. Sono due strumenti che rispondono bene a domande di forma diversa, ed è per questo che confrontarli non porta a un vincitore assoluto, ma a capire quando usare cosa.
Come funziona RAG vettoriale
Il RAG classico funziona in tre passaggi. Primo, si spezza la documentazione (o il codice, o i file di note) in pezzi più piccoli, i chunk. Secondo, ogni chunk viene trasformato in un vettore numerico (un embedding) che ne rappresenta il significato in uno spazio matematico dove testi simili nel significato finiscono vicini. Terzo, quando arriva una domanda, anche lei diventa un vettore, e il sistema restituisce i chunk il cui vettore è più vicino a quello della domanda.
Il punto di forza è la semplicità e la velocità di setup: bastano i documenti, un modello di embedding e un database vettoriale. Il limite è strutturale: un database vettoriale sa dirti "questo testo assomiglia alla tua domanda", ma non sa dirti "questo concetto dipende da quest'altro" o "questa decisione ha sostituito quella precedente". Se la relazione tra due informazioni non è scritta esplicitamente vicino nel testo, RAG vettoriale non la vede.
Come funziona un knowledge graph
Un knowledge graph applicato al coding organizza la conoscenza come nodi (un concetto, una decisione, un componente) collegati da archi tipizzati che dichiarano esplicitamente la relazione: usa, estende, dipende da, sostituisce. Quando cerchi qualcosa, il sistema non si ferma al nodo più simile alla domanda: può camminare lungo gli archi per raccogliere anche i nodi collegati, ricostruendo il contesto attorno alla risposta invece di restituire un frammento isolato.
Le implementazioni moderne, incluso il VibeCoded Orchestrator, combinano le due tecniche invece di scegliere: ogni nodo ha anche un embedding semantico, quindi la ricerca iniziale funziona come in un RAG vettoriale, ma da lì si può proseguire seguendo le relazioni tipizzate, cosa che un database vettoriale puro non permette.
Confronto diretto
| Aspetto | RAG vettoriale classico | Knowledge graph |
|---|---|---|
| Cosa recupera | Chunk di testo simili semanticamente | Nodi collegati da relazioni esplicite, non solo testo simile |
| Risponde bene a | "Cosa dice la documentazione su X?" | "Perché abbiamo scelto X invece di Y?" |
| Traccia relazioni tra concetti | No, solo similarità testuale | Sì, tramite archi tipizzati (usa, estende, dipende da) |
| Setup iniziale | Rapido: documenti + embedding + database vettoriale | Più lavoro: serve strutturare i nodi e le relazioni |
| Manutenzione nel tempo | Basso costo, ma qualità cala se i chunk sono mal tagliati | Richiede curation (nodi obsoleti, link mancanti) ma resta ispezionabile |
| Cross-project | Raro, richiede setup dedicato per collection condivise | Possibile nativamente con una collection condivisa tra progetti |
| Trasparenza dello storage | Dipende dal database vettoriale usato | File Markdown leggibili, nel caso di VCO, non uno store proprietario |
| Adatto a | Documentazione statica, FAQ, ricerca su grandi corpus di testo | Decisioni architetturali, pattern di progetto, memoria che deve sopravvivere alle sessioni |
Dove RAG classico basta, ed è la scelta giusta
Se il tuo problema è cercare in una grande quantità di documentazione statica (manuali, policy interne, contenuti editoriali) e le risposte che ti servono sono per lo più autocontenute in un singolo documento o paragrafo, RAG vettoriale è la scelta più semplice ed efficace. Non ha senso costruire un grafo di relazioni per contenuti che non hanno relazioni interessanti da tracciare: un FAQ non ha bisogno di sapere che una risposta "dipende da" un'altra, di solito.
Dove serve un knowledge graph
Il caso in cui RAG vettoriale mostra il limite è quando la domanda non riguarda "cosa dice il testo" ma "perché è così, e cosa altro è collegato". Un progetto software vive di decisioni che si costruiscono l'una sull'altra: una scelta di autenticazione influenza lo schema del database, che influenza l'API, che influenza il frontend. Un chunk isolato che descrive solo la scelta di autenticazione non porta con sé automaticamente quella catena di conseguenze. Un knowledge graph, seguendo gli archi tipizzati, sì.
Questo è anche il motivo per cui un sistema di memoria per assistenti AI di coding trae più valore da un grafo che da un RAG puro: le domande tipiche ("cosa abbiamo deciso su X e cosa ne dipende?") sono per natura relazionali, non solo di somiglianza testuale.
Non è una scelta binaria
Nella pratica, i sistemi più efficaci non scelgono uno dei due: usano l'embedding semantico per il primo aggancio (come farebbe un RAG) e la struttura a grafo per espandere il contesto una volta trovato il punto di ingresso giusto. Se vuoi vedere come questo si traduce in pratica, con i meccanismi concreti che rendono un knowledge graph utile ogni giorno e non solo in teoria, l'abbiamo scritto in dettaglio in knowledge graph per l'AI coding. Se invece ti interessa il passo pratico per collegarne uno al tuo progetto, la guida operativa è qui.