Knowledge graph temporale: perché Plutone rompe il grafo

Fino al 24 agosto 2006 Plutone era un pianeta senza discussione: il nono del sistema solare, lo insegnavano a scuola, lo scriveva la NASA. Quel giorno l'Unione Astronomica Internazionale ha votato una nuova definizione di pianeta, Plutone non ha superato il terzo criterio (non ha "ripulito" l'orbita dai corpi vicini), ed è diventato un pianeta nano. Da allora la NASA stessa lo classifica così.

Ora immagina un knowledge graph aziendale, o quello che fa da base a un assistente AI, con la tripla (Plutone, isA, Pianeta). Il 24 agosto 2006 qualcuno la aggiorna in (Plutone, isA, PianetaNano), sovrascrivendo la vecchia riga. Tecnicamente corretto oggi. Ma quella sovrascrittura ha appena cancellato un fatto che è stato vero per 76 anni, senza lasciarne traccia. Chiedi al sistema "Plutone era un pianeta nel 1990?" e non lo sa più dire: non perché manchi il dato, ma perché il dato di ieri non esiste più.

Questo non è un problema di astronomia. È il problema di ogni grafo che tratta i fatti come uno stato attuale invece che come una storia. E in azienda, la stessa identica dinamica, con un cambiamento vecchio anche solo di qualche settimana, produce risposte sbagliate che nessuno nota finché non costano care.

Cosa succede quando due sistemi scrivono lo stesso fatto?

Un cliente ha due sistemi che alimentano lo stesso grafo. Lunedì il CRM scrive (Azienda X, CEO, Alice). Giovedì l'ERP scrive (Azienda X, CEO, Bob). Senza timestamp, il grafo ha due fatti in conflitto sulla stessa relazione, e non ha modo di sapere quale scenario è quello vero:

• Il CRM ha un dato vecchio, non aggiornato da mesi: Bob è CEO da tempo, Alice è rumore.
• Bob ha davvero sostituito Alice giovedì: entrambi i fatti erano veri, in momenti diversi. Serve saperlo, non cancellare uno dei due.
• Sono co-CEO, e i due sistemi registrano prospettive diverse dello stesso momento, entrambe corrette.

Un grafo senza tempo tratta questi tre scenari, radicalmente diversi, come lo stesso problema: "due triple in conflitto, tieni l'ultima arrivata". È la scorciatoia più comune, ed è quasi sempre sbagliata.

Perché un grafo senza tempo produce risposte che si contraddicono?

C'è un problema ancora più subdolo di due fatti in conflitto: le catene di inferenza che attraversano il tempo. Prendi la sovranità del Kosovo. Fino al 1991 il Kosovo faceva parte della Jugoslavia. Dal 1991 al 2008 è stato parte della Serbia. Dal 2008 non è più parte della Serbia (pur restando contesa la sua piena indipendenza). Tre fatti, tutti veri, mai simultanei.

Se un grafo appiattisce questi fatti su un'unica riga per relazione, un motore di inferenza può concludere che "il Kosovo fa parte della Jugoslavia" e "il Kosovo non fa parte della Serbia" sono veri contemporaneamente, o mescolare una regola derivata da un periodo con un fatto vero solo in un altro. È la stessa famiglia di errore dell'illusione dell'ontologia: una struttura che sembra coerente ma ragiona su premesse che non sono mai state vere insieme.

Perché conta per chi lavora con l'AI in produzione

Fin qui sembra un esercizio da manuale di logica. Non lo è, per tre motivi molto concreti.

Primo: gli audit puntuali. Se un regolatore chiede "cosa sapeva l'azienda il 15 marzo?", un grafo che ha sovrascritto i fatti nel frattempo non può rispondere. Non è un problema di storicizzazione dei log, è che il grafo stesso ha smesso di sapere cosa credeva vero in quel momento.

Secondo: le decisioni sballate per dati scaduti che nessuno ha invalidato esplicitamente. Un fornitore alza il listino del 12% tre mesi fa, ma il grafo tiene ancora il prezzo vecchio: se qualcuno lo interroga oggi, un agente di procurement lo cita a un vicepresidente come se fosse la tariffa attuale, e la trattativa parte da un numero sbagliato.

Terzo, ed è il più urgente nel 2026: un agente AI che si appoggia al grafo per rispondere o agire non ha modo di sapere che sta usando un fatto scaduto, a meno che il grafo stesso non porti quell'informazione. Un RAG grounded su un knowledge graph senza tempo può citare con sicurezza assoluta un dato che era vero l'anno scorso e non lo è più, e la risposta suona autorevole esattamente come quella corretta.

Un solo passaggio obsoleto nel contesto costa ai principali LLM almeno il 20% di prestazione, anche quando l'informazione aggiornata è stata recuperata correttamente: lo misura il benchmark HoH, presentato ad ACL 2025, su 96.124 domande costruite da versioni successive di fatti reali. Il problema non è il modello: è che gli hai dato una mappa senza date.

La correzione: modellare il tempo, non solo i fatti

La soluzione ha un nome preciso e non è nuova: il modello bitemporale, mutuato dai database relazionali e portato nei grafi. Distingue due assi del tempo, e non vanno confusi:

• Valid time (tempo di validità): quando il fatto era vero nel mondo reale. Plutone è stato un pianeta per valid time dal 1930 al 2006.
• Transaction time (tempo di registrazione): quando il fatto è stato scritto nel sistema. Se il tuo grafo importa quel dato solo oggi, il transaction time è oggi, anche se il valid time parte dal 1930.

I due assi rispondono a domande diverse. "Cosa era vero il 15 marzo?" è una domanda sul valid time. "Cosa sapeva il sistema il 15 marzo, coi dati che aveva allora?" è una domanda sul transaction time, ed è quella che serve per un audit onesto: puoi aver saputo una cosa sbagliata, in buona fede, con i dati disponibili in quel momento.

Come si implementa un knowledge graph bitemporale?

Il principio bitemporale si traduce in tecniche concrete, e conviene sceglierle in base a cosa già usi, non correre dietro all'ultimo strumento di moda:

• Named graphs e RDF-star, due strumenti distinti. Un "grafo con nome" raggruppa un insieme di triple sotto un contesto comune, tipicamente la provenienza: quale sistema o quale fonte ha asserito quel lotto di fatti. Per annotare il singolo fatto, con una finestra di validità o un livello di confidenza specifici, serve un meccanismo più fine: lo standard emergente RDF-star permette di annotare direttamente il singolo fatto: non solo "Plutone è un pianeta", ma "Plutone è un pianeta, secondo l'IAU, valido dal 1930 al 2006". I due si combinano bene: il grafo con nome dice da dove viene il fatto, RDF-star dice quando era vero.
• Reificazione basata su eventi. Invece di modellare "Alice è CEO" come una tripla statica, modelli l'evento come un nodo di prima classe: "nomina di Alice a CEO", con data di inizio, data di fine (se c'è), e la fonte che l'ha registrato. Il fatto diventa una relazione col proprio ciclo di vita, non una riga da sovrascrivere.
• Livelli di query temporale. Alcuni database a grafo lo offrono già come funzionalità nativa: TerminusDB tratta il valid time come dato e il transaction time come parte del proprio grafo di commit, e permette query del tipo "cosa credeva vero il grafo alla data X" senza doverlo ricostruire a mano. TigerGraph va nella stessa direzione collegando eventi temporali alle entità che toccano, invece di trattare i dati con timestamp come una serie isolata. Nessuna delle due è l'unica scelta possibile: sono un punto di riferimento, non un vincolo di piattaforma.

Vale lo stesso principio già visto per ontologie e knowledge graph: il metodo conta più dello strumento scelto. Un modello bitemporale si costruisce su un grafo RDF, su un property graph, o dentro uno schema relazionale ben progettato. La piattaforma non è il punto.

In due righe

Un grafo che sovrascrive i fatti invece di storicizzarli non sbaglia quasi mai in modo rumoroso: sbaglia in silenzio, rispondendo con sicurezza a una domanda sul passato usando dati del presente. Plutone smette di essere un pianeta nel 2006, ma lo è stato per 76 anni: un grafo degno di fiducia deve saperlo dire entrambe le cose, con due date diverse. Il modello bitemporale, i named graphs con RDF-star e la reificazione a eventi sono la differenza tra un grafo che descrive solo l'oggi e uno che tiene la memoria di come ci si è arrivati, l'unico che un agente AI può interrogare senza il rischio di scambiare un fatto morto per uno vivo.