Un database di nuova generazione riduce le allucinazioni AI del 78%

Un team di KAIST e della startup GraphAI Co., Ltd. ha sviluppato un sistema di database che riduce le allucinazioni dei modelli di linguaggio del 78% rispetto ai sistemi RAG tradizionali. Il sistema si chiama AkasicDB ed è stato presentato il 2 giugno 2026 alla conferenza ACM SIGMOD di Bengaluru, una delle vetrine scientifiche più selettive nel campo dei database.

La notizia non riguarda il modello linguistico. Riguarda l’architettura dei dati che lo alimenta — e questa è la distinzione che la maggior parte delle discussioni sull’AI in azienda continua a ignorare.

Perché il RAG classico non basta: i dati aziendali non sono solo testo

Il RAG — “Retrieval-Augmented Generation” — è diventato lo standard de facto per connettere i modelli linguistici alle basi di conoscenza aziendali. Il funzionamento è semplice in teoria: prima di generare una risposta, il sistema recupera i documenti più rilevanti tramite ricerca semantica vettoriale e li passa al modello come contesto. Il modello risponde basandosi su quei documenti, non solo sul suo addestramento.

Il limite del RAG classico è strutturale, non implementativo: la ricerca vettoriale è efficace quando la domanda ha una risposta contenuta in un singolo frammento di testo. Diventa inadeguata quando la risposta richiede di attraversare relazioni tra entità (“tutti i fornitori del cliente X che hanno avuto ritardi negli ultimi sei mesi”), applicare filtri strutturati (“mostrami solo i contratti con clausola di esclusiva”), o combinare semantica con logica relazionale. I database vettoriali sono eccellenti nel trovare la vicinanza semantica, ma non sono nati per gestire grafi di relazioni o interrogazioni SQL strutturate.

Il risultato pratico è che un agente AI che usa RAG vettoriale su dati aziendali complessi sbaglia sistematicamente — non perché il modello sia scadente, ma perché il contesto recuperato è incompleto o scorretto. Le allucinazioni in produzione, quelle che costano, nascono quasi sempre da un dato mancante o mal recuperato, non da un’invenzione del modello a freddo.

AkasicDB affronta questo problema alla radice. Il sistema progettato dal prof. Min-Soo Kim (autore corrispondente) e da Geonho Lee (primo autore, dottorando) non è un wrapper che collega database esistenti. È un DBMS che integra nativamente tre paradigmi: ricerca vettoriale, traversal su grafo e filtraggio relazionale, eseguiti come singolo piano di query. Il metodo si chiama Omni RAG.

In un sistema tradizionale, gestire questi tre tipi di interrogazione richiederebbe di interrogare separatamente un database vettoriale, un graph database e un database relazionale, raccogliere i risultati e riconciliarli — con latenza cumulativa, rischio di incoerenza e complessità ingegneristica significativa. AkasicDB collassa le tre operazioni in un’unica esecuzione, il che riduce sia il tempo di risposta sia la probabilità che il contesto assemblato sia frammentato o contraddittorio.

Un secondo invece di ventuno: quando l’architettura conta più del modello

I numeri pubblicati nel paper sono netti. Le query complesse — quelle che richiedono tutti e tre i tipi di recupero — scendono da 21,3 secondi a meno di un secondo. Un miglioramento di circa venti volte che non deriva da hardware migliore o da ottimizzazioni di modello, ma dalla scelta di non separare ciò che non dovrebbe essere separato.

L’accuratezza delle risposte generate aumenta del 78% rispetto al RAG vettoriale puro, misurata su benchmark che includono query miste. Il dato è particolarmente rilevante perché il benchmark non testa casi limite costruiti ad arte: testa il tipo di domande che un agente AI in produzione riceve effettivamente su basi di conoscenza aziendali strutturate.

La latenza sotto il secondo non è solo un miglioramento di esperienza utente: è la soglia sotto la quale gli agenti AI diventano utilizzabili in flussi di lavoro sincroni. A 21 secondi per query, un agente che effettua più recuperi consecutivi diventa inutilizzabile in produzione. A meno di un secondo, diventa uno strumento.

I settori identificati come target principali — difesa, manifattura, finanza, diritto — condividono una caratteristica: lavorano con dati che sono contemporaneamente semi-strutturati, relazionali e semantici. Un caso giuridico coinvolge documenti testuali, relazioni tra parti, date, giurisdizioni, precedenti. Una supply chain manifatturiera ha componenti, fornitori, specifiche tecniche, contratti, certificazioni. Nessuno di questi scenari si presta a un recupero puramente vettoriale — eppure è su architetture vettoriali che la maggior parte dei sistemi RAG aziendali oggi gira.

Il professor Kim ha dichiarato che “AkasicDB è una tecnologia di database di nuova generazione per l’era degli agenti AI”. La formula è calibrata: non parla di LLM migliori, parla di infrastruttura. La qualità di un agente AI si decide al livello del data layer, non al livello del modello che genera la risposta finale. Su questo l’AI agentica che parte dai dati è un tema che il mercato sta cominciando a vedere chiaramente, ma che la maggior parte delle implementazioni aziendali non ha ancora incorporato nelle decisioni architetturali.

KAIST, Corea, e la geopolitica silenziosa dell’infrastruttura AI

ACM SIGMOD non è una conferenza di secondo piano. È la principale vetrina scientifica internazionale sui sistemi di gestione dei dati, e la presentazione di AkasicDB il 2 giugno a Bengaluru ha avuto visibilità immediata nella comunità dei ricercatori. Il fatto che venga da KAIST — l’istituto coreano che ha prodotto alcune delle ricerche più rilevanti in informatica degli ultimi vent’anni — aggiunge peso alla validazione scientifica del lavoro.

C’è una lettura più ampia che vale la pena fare. Il dibattito pubblico sull’AI si concentra quasi sempre su tre poli: americano (OpenAI, Google, Meta, Anthropic), cinese (DeepSeek, Qwen, Baidu) ed europeo (Mistral, il quadro regolatorio). La Corea del Sud sta costruendo un’infrastruttura di ricerca AI di base che produce risultati concreti, e lo fa in modo sistematico — Samsung, SK Hynix, LG, KAIST e POSTECH formano un ecosistema che non ha equivalenti in Europa per densità e investimento. AkasicDB è un prodotto di ricerca, non un prodotto commerciale maturo, ma la traiettoria è chiara.

GraphAI Co., Ltd. è la startup che commercializzerà il sistema: la distanza tra paper e prodotto non è necessariamente breve, ma il fatto che una struttura commerciale esista già suggerisce che il percorso verso il mercato è pianificato, non lasciato alla casualità accademica.

Per chi gestisce implementazioni AI in azienda, la lezione operativa di AkasicDB è semplice e scomoda. Aggiungere un LLM più potente sopra un’architettura RAG inadeguata non risolve il problema delle allucinazioni: lo maschera temporaneamente e lo sposta. Se i dati aziendali sono eterogenei — e quasi sempre lo sono — l’architettura di recupero deve essere eterogenea di conseguenza. Questo significa valutare soluzioni ibride che combinino vettoriale, grafo e relazionale, invece di assumere che il vettoriale copra tutto.

Non è una raccomandazione a migrare immediatamente su AkasicDB, che al momento è un sistema di ricerca in fase di commercializzazione. È una raccomandazione a rivedere i presupposti architetturali con cui si progettano i sistemi RAG in produzione. La domanda da fare non è “quale modello usiamo?”, ma “il nostro sistema di recupero è in grado di rispondere alle domande che gli agenti dovranno fare sui nostri dati?”.

Se la risposta non è immediata e sicura, il problema delle allucinazioni non è del modello. È dell’architettura. E l’architettura si può cambiare — come dimostra che gli agenti AI senza una forma definita trovino il loro percorso nel data layer prima ancora che nel reasoning.

Il paper completo è disponibile tramite ACM Digital Library. La copertura tecnica è su TechXplore e il comunicato originale su EurekAlert.