Knowledge Graph e Ontology Engineering di Dominio

La tua AI non può ragionare su ciò che non conosce

La ricerca vettoriale trova elementi che suonano simili. I knowledge graph trovano elementi che sono veri. Questa distinzione è la differenza tra un sistema di AI che tira a indovinare e uno che ragiona.

I benchmark clinici lo rendono concreto: gli LLM ancorati a knowledge graph strutturati su ontologie hanno ridotto i tassi di allucinazione dal 63% fino all'1,7%, mentre il retrieval puramente vettoriale si assesta intorno al 70% di accuratezza sui compiti di conoscenza complessi, rispetto all'85%+ degli approcci ibridi vettoriale-più-grafo (vedi la nostra ricerca sull'AI ancorata alla conoscenza in ambito sanitario).

La maggior parte dei team che tentano di realizzare knowledge graph finisce con qualcosa di completamente diverso: un labeled property graph in Neo4j senza semantica formale, senza capacità di inferenza e senza tracciamento della provenienza. Quello è un database, non un knowledge graph. Funziona finché non hai bisogno di rispondere a domande che i progettisti dello schema non avevano previsto, di risalire da un output dell'AI ai fatti di origine, o di far evolvere il tuo modello di dominio senza rompere ogni consumatore a valle.

Il nostro approccio consiste nel costruire la cosa reale: ontologie formali con inferenza, infrastruttura grafica di produzione con provenienza a livello di tripla, e framework di manutenzione progettati per mantenere aggiornata la conoscenza quando il tuo dominio inevitabilmente cambia.

Property graph, RDF triple store, o entrambi: scegliere l'architettura giusta

Il dibattito Neo4j-contro-RDF consuma più cicli di ingegneria di quanto dovrebbe, di solito perché la decisione viene presa prima che i requisiti siano compresi.

Il vantaggio di RDF è il ragionamento automatizzato: dichiara che ogni Farmaco che interagisce con un inibitore delle MAO è controindicato per i pazienti in terapia con SSRI, e il reasoner deduce ogni specifica controindicazione senza enumerazione manuale.

Il nostro approccio predilige sistemi ibridi in cui l'ontologia formale risiede in un RDF store per il ragionamento e la conformità, mentre un property graph gestisce le query di traversamento, con un layer di sincronizzazione che li mantiene coerenti. Aggiungi embedding vettoriali (TransE, CompGCN o reti neurali su grafo) per la similarità semantica, e ottieni un sistema di retrieval che gestisce corrispondenze esatte, inferenza logica e similarità fuzzy in un'unica pipeline.

Ontology engineering: la parte che tutti sottovalutano

Acquistare un graph database è facile. Costruire l'ontologia che lo rende utile è dove i progetti si arenano. Un'ontologia di dominio è una specifica formale di ciò che esiste nel tuo dominio, di come le cose sono correlate e di quali vincoli governano tali relazioni.

Farlo bene richiede due tipi di competenza che raramente coesistono: una profonda conoscenza del dominio (ciò che uno specialista di affari regolatori farmaceutici sa sulle classificazioni delle sostanze IDMP) e competenze di rappresentazione formale della conoscenza (come esprimere quella conoscenza in OWL 2 DL senza creare colli di bottiglia nel ragionamento), approfondite in il nostro whitepaper sull'AI neuro-simbolica in un dominio clinico regolamentato.

Inizia dalle competency question

Il nostro processo di ontology engineering parte dalle competency question: le specifiche interrogazioni a cui il knowledge graph deve essere in grado di rispondere. Non requisiti vaghi come "supportare l'analisi della sicurezza dei farmaci", ma requisiti precisi come "data la lista dei farmaci di un paziente e una nuova prescrizione, identifica tutte le controindicazioni transitive attraverso le interazioni delle vie metaboliche entro 200 millisecondi". Queste competency question guidano ogni decisione di modellazione e diventano la suite di test di regressione per l'evoluzione dell'ontologia.

Scegliere il formalismo giusto

Scegliamo il formalismo giusto per il compito:

• OWL 2 DL — domini che richiedono un ragionamento completo di Description Logic (farmaceutico, legale, regolatorio).
• OWL 2 EL — ontologie di grandi dimensioni in cui la classificazione trattabile è importante (SNOMED CT ha oltre 350.000 concetti e funziona bene in EL).
• SKOS — tassonomie e vocabolari controllati in cui servono gerarchia ed etichette ma non l'inferenza logica.
• SHACL — vincoli per le regole di validazione dei dati che affiancano l'ontologia.

La maggior parte dei sistemi di produzione usa più formalismi in combinazione, e sapere quale applicare e dove è una parte significativa di ciò che un progetto fornisce.

Entity resolution: il moltiplicatore di budget 3x che nessuno mette in conto

Prima che un knowledge graph possa ragionare sui tuoi dati, quei dati devono essere puliti, deduplicati e collegati. La entity resolution — determinare che "JPMorgan Chase", "JP Morgan", "JPMC" e "J.P. Morgan Chase & Co." sono la stessa entità — sembra semplice ma è genuinamente difficile su scala aziendale.

La difficoltà si moltiplica con sorgenti eterogenee. Unire la conoscenza proveniente da 10-15 diversi sistemi sorgente significa affrontare schemi in conflitto, diverse convenzioni sugli identificatori, qualità dei dati variabile e incoerenze temporali (un sistema dice che l'azienda è stata acquisita nel Q3, un altro dice nel Q4). I team sottovalutano abitualmente il costo della entity resolution di 3-5 volte.

Progettiamo pipeline di entity resolution che combinano matching basato su regole, modelli di similarità appresi e verifica human-in-the-loop per i casi limite. La pipeline è architettata per produrre un grafo canonico delle entità con link di provenienza fino a ogni record di origine, così puoi sempre risalire al perché due record sono stati uniti o tenuti separati.

Questa catena di provenienza diventa cruciale per la tracciabilità regolatoria nell'ambito di framework come l' EU AI Act, dove gli Articoli 12-13 richiedono di dimostrare la lineage dei dati che alimentano i sistemi di AI ad alto rischio.

Perché i progetti di knowledge graph falliscono (e come evitarlo)

Il pattern di fallimento del settore è ben documentato: il 95% dei progetti pilota aziendali di GenAI fallisce, e i progetti di knowledge graph hanno le loro specifiche modalità di fallimento.

1. La trappola del POC. Un piccolo proof-of-concept ha successo con un dataset curato e uno schema semplice, così la leadership dà il via libera alla costruzione completa. Poi il team scopre che i dati reali sono 10 volte più disordinati, che l'ontologia ha bisogno di 50 volte più concetti, e che i pattern di query per cui avevano ottimizzato coprono appena il 30% dei casi d'uso reali. Il nostro approccio dimensiona i progetti attorno a campioni di dati di produzione e carichi di query reali fin dal primo giorno.
2. Sovra-assiomatizzazione. Gli ontology engineer con background accademico aggiungono ogni possibile assioma e restrizione, e il reasoner rallenta da secondi a ore su knowledge base modeste. Profiliamo le prestazioni del reasoner presto e in modo continuo, applicando il principio della minima assiomatizzazione: aggiungi vincoli solo quando servono a una specifica competency question.
3. Deriva dell'ontologia. Il knowledge graph viene lanciato, funziona bene, poi si degrada lentamente man mano che il dominio evolve — SNOMED CT rilascia aggiornamenti trimestrali, le tassonomie regolatorie cambiano, emergono nuove categorie di prodotto e nessuno è titolare della manutenzione. Un progetto è dimensionato per produrre framework di manutenzione dell'ontologia con rilevamento delle modifiche, analisi d'impatto e test di regressione, validando ogni nuovo concetto o relazione rispetto all'intera suite di competency question prima del deployment.
4. Nessuna titolarità a livello dirigenziale. I knowledge graph sono infrastruttura — abilitano le capacità di AI a valle ma non producono funzionalità visibili da soli. Senza una sponsorship dirigenziale che colleghi la qualità del grafo agli esiti di business (riduzione delle allucinazioni, conformità più rapida, migliore rilevamento delle interazioni farmacologiche), il progetto perde i finanziamenti al secondo anno. Aiutiamo i team a costruire il business case con metriche concrete legate ai loro specifici casi d'uso.

Collegare i knowledge graph a LLM, RAG e AI agentica

GraphRAG di Microsoft (e la sua variante a costo ridotto LazyGraphRAG, che abbatte i costi di estrazione allo 0,1% dell'originale) ha dimostrato che il retrieval strutturato su grafo supera quello puramente vettoriale sulle query complesse e multi-hop. Ma GraphRAG in produzione è più difficile di quanto suggeriscano i paper: la community detection crea artefatti di retrieval, le pipeline di estrazione necessitano di tuning specifico per il dominio, e non c'è tracciamento della provenienza integrato.

Progettiamo un retrieval ancorato al KG in cui ogni fatto recuperato porta con sé la sua tripla di origine, il punteggio di confidenza e la validità temporale. Quando l'LLM genera un'affermazione, il sistema la verifica rispetto al grafo e cita le specifiche triple che la supportano o la contraddicono (vedi una demo funzionante della verifica delle citazioni rispetto al grafo). Con il RAG vettoriale, "il modello ha trovato un passaggio simile" è la più solida attribuzione che puoi ottenere.

I knowledge graph come strumenti accessibili agli agenti

Per le architetture di AI agentica, i knowledge graph fungono da sorgenti di conoscenza accessibili come strumenti. Neo4j ha lanciato un knowledge layer per i sistemi agentici su Google Cloud ad aprile 2026, e l'adozione del Model Context Protocol (MCP) sta accelerando come standard di connettore tra agenti e conoscenza.

Il nostro approccio consiste nel costruire knowledge graph interrogabili dagli agenti fin dal primo giorno: endpoint SPARQL, API strutturate o interfacce compatibili con MCP che permettono agli agenti di AI di accedere alla conoscenza di dominio come una tool call anziché come un'iniezione nel prompt, un approccio approfondito in la nostra ricerca sul liability firewall per gli agenti AI aziendali.

Cosa forniamo

Ogni progetto è dimensionato in base al tuo dominio, al tuo panorama dei dati e ai requisiti dell'AI a valle. I deliverable includono:

• Un'ontologia di dominio formale (OWL, completamente annotata) validata da reasoner automatizzati.
• Il knowledge graph popolato con pipeline di ingestione per sorgenti strutturate e non strutturate.
• Servizi di entity resolution con provenienza completa.
• Definizioni di vincoli SHACL per la validazione dei dati.
• Una suite di test di competency question (pattern SPARQL o Cypher) come test di regressione per l'evoluzione dell'ontologia.
• Interfacce di integrazione per RAG, grounding di LLM o accesso come strumento per l'AI agentica.
• Un framework di manutenzione dell'ontologia con rilevamento delle modifiche e deployment versionato.

Forniamo anche una valutazione onesta dei casi in cui un approccio più semplice ti servirebbe altrettanto bene.