Negli ultimi due anni ho aiutato diverse aziende a portare l’AI sui propri dati interni con RAG e ricerca semantica con vector database. Funzionano benissimo per trovare “il paragrafo giusto” dentro migliaia di documenti. Ma quando le domande diventano più complesse — “quali clienti del settore metalmeccanico hanno un contratto in scadenza e un ticket aperto ad alta priorità?” — il solo recupero per similarità semantica non basta più. Serve un knowledge graph aziendale: una struttura che rappresenta esplicitamente le relazioni tra entità (clienti, contratti, prodotti, persone, ticket) e che un agente AI può percorrere passo dopo passo per ragionare, non solo per recuperare testo simile.
Vector database e RAG: cosa risolvono, cosa no
Un vector database trasforma un testo in un punto in uno spazio ad alta dimensionalità: documenti “simili” finiscono vicini, e l’AI recupera i più pertinenti rispetto a una domanda. È perfetto per domande aperte su contenuti non strutturati (manuali, email, contratti, knowledge base). Il limite emerge quando la risposta richiede di collegare più fatti tra loro: il vector database non sa che il “Cliente X” del documento A è la stessa entità del “Cliente X” del documento B, né che quel cliente è collegato a tre contratti e a un referente commerciale specifico. Ogni relazione va dedotta di nuovo, in modo probabilistico, a ogni query.
Cos’è un knowledge graph aziendale
Un knowledge graph è un grafo di entità e relazioni: nodi che rappresentano oggetti del mondo aziendale (un cliente, un prodotto, un contratto, un dipendente, un ticket) e archi che rappresentano come questi oggetti sono collegati (“Cliente X → ha firmato → Contratto Y”, “Contratto Y → include → Prodotto Z”). A differenza di un database relazionale rigido, il grafo è pensato per essere navigato in più direzioni e per aggiungere nuovi tipi di relazione senza dover riprogettare lo schema ogni volta. Per un’azienda, questo significa poter modellare in modo naturale la rete di rapporti che esiste già tra CRM, gestionale, ticketing e documenti — ma che oggi vive sparsa in sistemi diversi che non si parlano.
Knowledge graph e agenti AI: il ragionamento multi-hop
La vera potenza si vede quando un agente AI con tool calling può interrogare il grafo con query strutturate (ad esempio in Cypher o SPARQL) invece di limitarsi a un recupero semantico. Una domanda come quella dell’esempio iniziale diventa una traversata del grafo: parti dal nodo “Contratti in scadenza nei prossimi 30 giorni”, segui l’arco verso “Cliente”, filtra per settore, poi segui l’arco verso “Ticket aperti” e filtra per priorità. È un ragionamento “multi-hop” che un vector database, da solo, non può fare in modo affidabile — mentre un grafo lo rende una query esplicita e verificabile. Questo si integra bene con l’infrastruttura che un agente aziendale usa già per accedere ai dati: la stessa pipeline dati per alimentare gli agenti AI che porta informazioni da CRM, ERP e fogli di calcolo può popolare e mantenere aggiornato il grafo, entità per entità.
Come costruire un knowledge graph aziendale (senza esagerare)
Non serve partire da zero con un progetto faraonico. Un percorso pragmatico che consiglio spesso:
- Parti da un dominio ristretto: ad esempio solo “clienti-contratti-prodotti”, non tutta l’azienda insieme.
- Estrai le entità dai sistemi esistenti: CRM, gestionale, ticketing — spesso i dati ci sono già, mancano solo i collegamenti espliciti.
- Scegli uno strumento adatto alla scala: un database a grafo dedicato (es. Neo4j) per volumi importanti, oppure una modellazione più semplice se il dominio è piccolo e i rapporti sono pochi.
- Aggiorna il grafo con automazioni, non a mano: ogni nuovo contratto o ticket deve creare o aggiornare nodi e archi automaticamente, altrimenti il grafo invecchia e perde valore in poche settimane.
- Versiona lo schema delle relazioni come faresti con un’API, così puoi far evolvere il modello senza rompere le query esistenti.
GraphRAG: unire grafo e vector database
Nella pratica, la soluzione migliore raramente è “grafo o vector database”: è entrambi insieme, un approccio noto come GraphRAG. Il vector database resta il modo più efficiente per trovare il testo non strutturato pertinente (email, contratti, documentazione); il grafo aggiunge il contesto relazionale che collega quei testi alle entità aziendali e permette query strutturate quando la domanda lo richiede. Un agente ben progettato decide da solo quale strumento usare in base al tipo di domanda — proprio come discusso a proposito della scelta dello strumento giusto per ogni compito.
Casi d’uso concreti nelle PMI
Alcuni scenari dove ho visto un knowledge graph fare davvero la differenza rispetto al solo RAG:
- Vista 360° del cliente: un agente di supporto che, prima di rispondere, “vede” in un colpo tutti i contratti, i ticket storici e i referenti collegati a quel cliente.
- Compliance e audit: tracciare chi ha accesso a cosa e perché, ricostruendo catene di autorizzazioni e responsabilità in modo verificabile.
- Ricerca prodotto avanzata: “prodotti compatibili con questa macchina, mai restituiti, con un fornitore alternativo disponibile” — una catena di filtri che il grafo gestisce in una query.
- Continuità della conoscenza: quando un dipendente lascia l’azienda, la rete di relazioni che aveva in testa resta scritta nel grafo, non se ne va con lui.
Un knowledge graph aziendale non è un progetto per multinazionali con team di data engineer: anche una PMI con pochi sistemi ben collegati può ottenere agenti AI molto più affidabili, capaci di ragionare sui rapporti reali tra i propri dati e non solo di recuperare testo simile. Se vuoi capire da dove partire nel tuo caso specifico — quali dati modellare per primi, quale strumento scegliere in base a volumi e budget, come far convivere grafo e vector database — contattami: costruisco automazioni e agenti AI su misura per aziende che vogliono passare da dati sparsi a conoscenza realmente utilizzabile.
