Un assistente AI che trova una procedura in un PDF può essere utile. Un sistema che sa collegare quella procedura al codice prodotto, al cliente, alla distinta base, al contratto e allo stato di una commessa può cambiare il modo in cui l’azienda lavora. È qui che knowledge graph e GraphRAG diventano rilevanti: trasformano informazioni disperse in conoscenza con relazioni esplicite, interrogabile e utilizzabile nei processi.
Per imprese con ERP, CRM, repository documentali, email, database e applicazioni proprietarie, il problema non è quasi mai la mancanza di dati. Il problema è che i dati vivono in silos, usano identificativi diversi e descrivono solo una parte del contesto. Un modello linguistico può sintetizzare bene ciò che recupera, ma non può inventare una struttura affidabile dove quella struttura non esiste.
Perché il RAG tradizionale non basta sempre
Un sistema RAG classico indicizza documenti dividendoli in porzioni, le trasforma in vettori e recupera i passaggi semanticamente più vicini a una domanda. Per molte richieste è un approccio efficace: trovare una clausola contrattuale, riassumere un manuale tecnico, rispondere a una domanda su una policy interna.
Il limite emerge quando la risposta richiede di seguire relazioni distribuite tra fonti diverse. Pensiamo a una domanda come: quali clienti hanno acquistato prodotti che dipendono da un componente soggetto a una modifica tecnica, e quali ordini aperti possono subire ritardi? La risposta non è contenuta in un singolo documento. Richiede di attraversare anagrafiche, distinte base, revisioni tecniche, ordini, disponibilità e regole operative.
Il retrieval vettoriale restituisce contenuti simili alla domanda, non necessariamente il percorso logico necessario per risolverla. Può recuperare il manuale corretto ma non sapere che due codici articolo sono equivalenti, che una sede appartiene a un gruppo cliente o che una revisione ha sostituito un componente in una data precisa.
Questo non rende il RAG tradizionale inutile. Al contrario, resta una scelta pragmatica per knowledge base documentali ben delimitate. Ma quando il valore dipende dalle connessioni tra entità, serve un livello architetturale ulteriore.
Che cos’è un knowledge graph
Un knowledge graph rappresenta la conoscenza aziendale come una rete di entità e relazioni. Le entità possono essere clienti, fornitori, impianti, prodotti, documenti, persone, ordini, ticket, contratti o normative. Le relazioni spiegano come questi elementi sono collegati: un prodotto utilizza un componente, un cliente appartiene a un gruppo, un ordine riguarda una commessa, un documento approva una procedura.
La differenza è sostanziale. In un archivio tradizionale, un dato può essere presente ma isolato. In un grafo, la relazione diventa un’informazione gestita, interrogabile e governata. Questo permette di costruire risposte fondate non solo sulla somiglianza testuale, ma anche su regole, gerarchie, dipendenze e percorsi verificabili.
Un buon knowledge graph non è una copia indiscriminata di tutti i database aziendali. È un modello progettato per i casi d’uso prioritari. Se l’obiettivo è supportare il service post-vendita, il grafo dovrà rendere espliciti collegamenti tra cliente, installazione, seriale, contratto di manutenzione, ticket, ricambi e documentazione tecnica. Se l’obiettivo è il controllo della supply chain, conteranno maggiormente fornitori, materiali, alternative, lead time, ordini e vincoli produttivi.
Il dato deve avere identità e provenienza
La qualità del grafo dipende dalla disciplina con cui vengono gestite identità, fonti e aggiornamenti. Lo stesso cliente può comparire con codici differenti nel CRM, nell’ERP e in un portale B2B. La stessa macchina può essere identificata da un seriale nei documenti tecnici e da un asset ID nel gestionale.
Senza normalizzazione, deduplicazione e regole di riconciliazione, il grafo amplifica l’ambiguità invece di ridurla. Per questo la fase di data engineering non è un dettaglio preparatorio: è parte della qualità della risposta AI. Ogni relazione rilevante dovrebbe poter indicare fonte, data di validità, livello di confidenza e, quando necessario, responsabile aziendale.
Come funziona GraphRAG
GraphRAG combina un knowledge graph con la capacità generativa dei modelli linguistici. Invece di chiedere al modello di rispondere soltanto sui frammenti di testo più simili, il sistema può individuare le entità citate, attraversare relazioni pertinenti, recuperare documenti di supporto e costruire un contesto più completo.
Il modello linguistico resta il componente che interpreta la domanda e formula una risposta comprensibile. Il grafo gli fornisce però una struttura: quali oggetti sono coinvolti, come sono connessi, quali vincoli devono essere considerati e quali evidenze giustificano la conclusione.
In pratica, una richiesta può attivare più modalità di recupero. La ricerca semantica trova istruzioni o note tecniche non strutturate. Le query sul grafo verificano relazioni e dipendenze. Le interrogazioni ai sistemi sorgente, come ERP o CRM, recuperano dati aggiornati che non è opportuno duplicare. Un orchestratore decide quali strumenti usare e in quale sequenza, rispettando permessi e regole di processo.
Questa è la differenza tra un chatbot informativo e un sistema AI integrato, controllabile e pronto per la produzione. L’AI non soltanto risponde: consulta i dati autorizzati, ricostruisce il contesto e può preparare un’azione entro confini definiti.
I casi in cui GraphRAG produce valore reale
GraphRAG è particolarmente indicato per domande multi-hop, cioè richieste la cui soluzione richiede più passaggi relazionali. Nella manifattura può aiutare a valutare l’impatto di una non conformità su prodotti, ordini e clienti. Nei servizi professionali può collegare pratiche, contratti, scadenze, interlocutori e precedenti. In logistica può mettere in relazione spedizioni, magazzini, vincoli doganali, fornitori e livelli di servizio.
Un copilot commerciale può rispondere non solo con l’ultimo listino disponibile, ma con una lettura del cliente: storico acquisti, macchine installate, contratti attivi, opportunità aperte, margini e documentazione negoziale autorizzata. Un agente per il procurement può identificare fornitori alternativi considerando certificazioni, componenti compatibili, condizioni contrattuali e ordini in ritardo.
Il valore non sta nell’effetto dimostrativo di una risposta articolata. Sta nella riduzione del tempo necessario per ricostruire un contesto, nella minore dipendenza dalla conoscenza informale delle singole persone e nella capacità di rendere ogni risposta verificabile.
Progettare un’architettura GraphRAG affidabile
Un progetto efficace parte dal processo, non dal database a grafo. Occorre identificare una decisione o un’attività che oggi richiede ricerche manuali, passaggi tra sistemi, interpretazione di documenti e coinvolgimento di più funzioni. Da lì si definiscono domande, utenti, dati, azioni consentite e criteri con cui misurare il risultato.
Sicurezza e autorizzazioni non sono opzionali
Un sistema GraphRAG può collegare dati molto sensibili. Proprio per questo deve rispettare gli stessi confini dell’organizzazione, e non introdurre scorciatoie. I permessi non possono essere applicati solo all’interfaccia: devono governare il retrieval, le query sul grafo, l’accesso agli strumenti e la visibilità delle fonti nella risposta.
Serve inoltre tracciabilità. Per ogni risposta rilevante, l’azienda deve poter sapere quali fonti sono state consultate, quali relazioni hanno contribuito alla risposta, quale versione del dato era valida e quali azioni sono state eventualmente proposte o eseguite. Nei processi ad alto impatto, la supervisione umana resta una scelta progettuale intelligente, non un limite tecnologico.
Il grafo non sostituisce i sistemi transazionali
ERP, CRM e gestionali rimangono le fonti operative per ordini, anagrafiche, disponibilità e transazioni. Il knowledge graph non dovrebbe diventare un duplicato incontrollato di questi sistemi. Può invece offrire uno strato semantico che mette in relazione le informazioni, conserva la provenienza e accelera le interrogazioni complesse.
La scelta tra sincronizzazione, federazione in tempo reale o modello ibrido dipende dal caso d’uso. Per analisi e assistenza operativa può essere accettabile un aggiornamento periodico. Per disponibilità di magazzino, stato ordini o prezzi, può essere necessario interrogare la fonte transazionale al momento della richiesta. La progettazione corretta nasce dal compromesso esplicito tra freschezza, performance, costo e affidabilità.
Come misurare la qualità oltre la demo
La valutazione non può limitarsi a chiedere se la risposta sembra convincente. Un sistema enterprise va misurato su accuratezza fattuale, copertura delle fonti, correttezza delle autorizzazioni, qualità delle citazioni interne, tempo di risposta e tasso di escalation verso un operatore.
È utile costruire un set di domande reali, incluse richieste ambigue, casi limite e domande per cui il sistema deve dichiarare di non avere informazioni sufficienti. Un GraphRAG ben progettato non cerca di rispondere a ogni costo. Sa distinguere tra evidenza disponibile, inferenza plausibile e dato assente.
PurpleSoft affronta questi progetti come architetture operative: software, dati e intelligenza artificiale in un unico sistema, con integrazioni, controlli e metriche definiti fin dall’inizio. Perché una risposta credibile è utile; una risposta che può entrare in un workflow, essere verificata e generare un’azione misurabile è ciò che rende l’AI un’infrastruttura aziendale.
Il primo passo concreto non è scegliere un database a grafo o un modello linguistico. È individuare il punto del processo in cui la conoscenza esiste già, ma resta frammentata e lenta da usare. Da quella frizione può nascere un sistema che restituisce alle persone tempo, contesto e capacità decisionale.
