Try asking an AI agent "what knowledge is needed to start beekeeping." The language model instantly provides fluent and accurate advice, from hive temperature management to the biological rhythms of bees. At this stage, the AI appears to be an exceptionally capable assistant. However, the moment you raise the resolution of the question to a practical business level and ask, "Find the clause concerning Company A in last year's contract, and explain how it relates to the current supply trouble with the bee colonies," everything changes.
The AI confidently begins spinning an entirely fictitious story, complete with plausible-sounding dates and the names of nonexistent staff members. This phenomenon, known in the industry as "hallucination," is the single greatest barrier preventing companies from unleashing generative AI on their confidential data and vast internal document repositories.
Until now, approaches to solving this problem have focused on developing larger and smarter large language models (LLMs) with more parameters, or relying on the sorcery of prompt engineering. However, the conclusion reached by a research team led by Professor Min-Soo Kim at the Korea Advanced Institute of Science and Technology (KAIST), along with the university's spin-off startup GraphAI Co. Ltd., points in an entirely different direction. They have determined that the root cause of AI's lies is not the computational ability of the "brain" (the LLM), but rather structural flaws in the "shelf of memory" (the database) from which facts are retrieved.
AkasicDB, the next-generation database technology they presented at ACM SIGMOD 2026, along with Omni RAG, a new retrieval-augmented generation method built upon it, fully synchronizes three distinct dimensions of data—semantic meaning, relationships, and facts—within a single engine. This article unpacks this paradigm shift in AI memory-processing architecture in full, along with the structural transformation it presents to the enterprise IT market.
Meaning, Relationships, Facts: The "Knowledge Gaps" Created by Fragmented Retrieval Pipelines
Many of today's enterprise AI agents are built on a technology called RAG (Retrieval-Augmented Generation). This mechanism converts a user's question into an array of numbers (a vector), searches for documents that are close in distance within a high-dimensional mathematical space, and passes them to the LLM as context.
This approach excels at scooping "semantically similar" content from an ocean of unstructured text. But real-world corporate data is not simply a straightforward list of text. It is a complex tangle of "relational maps of people and organizations within a specific project (graph structure)" and "strictly structured data such as dates, amounts, and categories (relational structure)."
When a conventional system attempts to investigate the aforementioned query about "last year's contract, its relationship to Company A, and the supply trouble," an extremely inefficient and fragile relay race occurs internally. First, the vector database identifies clauses that match "semantically." Next, the graph database maps "connections between companies and people." Then the relational database applies a filter for the condition "last year's contract."
When these are run as separate, dedicated systems and the results are ultimately stitched together at the application layer (Out-of-DB integration), a fatal problem arises. Since each database has no way of knowing which data will ultimately be needed in later stages, it errs on the side of caution and spits out far more intermediate data than necessary. Alternatively, there is a method of forcibly cohabiting extensions (such as pgvector or Apache AGE) onto a general-purpose relational database like PostgreSQL (non-native In-DB integration). In this case, the overarching query planner does not deeply understand the spatial characteristics of graphs or vectors, and forces all processing into the relational processing framework.
As a result, the retrieval process wastes enormous amounts of time, and in the process of reconciling conditions, even truly necessary facts end up falling through the cracks. When the LLM receives only incomplete fragments from the retrieval system, it uses its remarkable language-generation ability to smoothly infer the "blank spaces" and paper over the logical gaps. This is the true mechanism behind how AI tells plausible lies.
A Single Neural Network Connecting Three Cerebral Lobes: The Depths of Native Integration Implemented by AkasicDB
AkasicDB, developed by the KAIST team, fundamentally rebuilds this fragmented infrastructure from the ground up. They first laid the foundation with "Chimera," a dual-store architecture previously developed to process graph and relational data within a single engine. Onto this, they natively embedded a dedicated vector store supporting advanced approximate nearest neighbor (ANN) indexes such as HNSW, IVF, and Vamana, completing a robust triple-store design.
The core of AkasicDB lies in its ability to express complex searches spanning these three distinct data models as a single SQL/GQL (Graph Query Language) query, executed under one "unified query planner."
Internally, an innovative mechanism called the Traversal-Join-Similarity operator is at work. Translated into an everyday scenario: rather than three specialists—a linguist (vector), a detective (graph), and an accountant (relational)—each conducting independent investigations and later exchanging letters to reconcile their opinions (the conventional method), it is as if a single superhuman intellect possessing all their combined abilities advances every thought process simultaneously and without contradiction.
Through this integration, the system dynamically narrows down the range of vectors to be searched at the earliest stage of retrieval, factoring in both the "connections of the graph (topology)" and the "conditions of dates and categories (attributes)." It eliminates the waste of generating superfluous intermediate data and erases the latency of moving enormous volumes of data across a network. A single, meticulously refined execution plan dramatically increases the purity of the context handed to the LLM.
Empirical Data Backing Overwhelming Performance and the Disruptive Power of "Omni RAG"
The performance of Omni RAG, the new RAG method built on top of AkasicDB, vividly demonstrates just how severe a bottleneck the conventional architecture posed.
In experiments using the UltraDomain dataset (spanning agriculture, computer science, law, and mixed domains, totaling several million tokens), the effect was quantitatively proven. Complex retrieval queries that took existing systems (such as PostgreSQL combined with pgvector and AGE) as long as 21.3 seconds to answer—hampered by coordination and data transfer between databases—were processed on AkasicDB in under one second. This represents an astonishing speedup of over 20 times.
What deserves even more attention is the dramatic improvement in answer quality. Because context is extracted with an accurate grasp of structured conditions and relationships between entities, the room for the LLM to fill in gaps with speculative storytelling is thoroughly eliminated. As a result, answer accuracy improved by up to 78% compared to conventional RAG relying solely on vector search.
The table below compares RAG performance across different architectures.
| Architecture | Example System Configuration | Complex Query Processing Time (ms) | Accuracy Advantage | Structural Characteristics |
|---|---|---|---|---|
| Out-of-DB Integration | Neo4j + Milvus | 3,001 – 7,099 | Limited | Multiple independent systems. Bottlenecked by data transfer costs and excessive intermediate data generation. |
| Non-Native In-DB | PostgreSQL (pgvector + AGE) | 4,728 – 21,278 | Limited | Extensions bolted onto a single DB. Planner optimization is insufficient, resulting in markedly poor execution efficiency. |
| Native In-DB | AkasicDB (Omni RAG) | 583 – 942 | Up to 78% improvement | Three functions integrated at the lowest layer. Efficient, unified batch execution via a single planner. |
Of particular interest is the fact that Omni RAG achieves its largest accuracy gap—28 percentage points—over the vector-only approach precisely in questions where data sources are intricately entangled and span multiple domains (as in the Mix dataset environment underlying the table). The more convoluted the structure of the question at hand, the more the true value of the native integration approach shines through.
Hypothetical Simulation: Impact on Legal Affairs and Supply Chains
To imagine the real-world impact of this technology, let's consider a hypothetical use case in the procurement department of a global manufacturing company.
Suppose a staff member instructs the AI: "Among contracts signed over the past three years with Asia-Pacific parts suppliers, extract a list along with risk assessments of companies that both include a force majeure clause for natural disasters and are currently supplying parts to Project X."
A conventional RAG system would pull up contracts based on the similarity of keywords like "natural disaster" and "force majeure," and list company names that seem vaguely related to Project X. However, it would struggle to accurately determine whether a given contract has already expired, or whether the company in question is only indirectly involved as a subcontractor.
By contrast, AkasicDB equipped with Omni RAG first applies a rigorous filter based on hard facts from relational data—"past three years" and "Asia-Pacific." Next, it traces the topology of "the network of companies with direct or indirect supply relationships to Project X" from graph data. Within that tightly narrowed, rigorous framework, it uses vector data to pinpoint contract text that semantically matches "force majeure clauses for natural disasters." This entire process completes within milliseconds, presenting only well-grounded, unshakeable facts as the AI's context. In corporate legal affairs and risk management, the value delivered by this "absolute guarantee of fact" is immeasurable.
The Next Battlefield in the Fight for Data Infrastructure Supremacy, and the Macro Industry Context
Professor Min-Soo Kim has stated plainly that "AkasicDB is core data infrastructure for the age of AI agents." Their target is high-stakes domains—defense, manufacturing, finance, and legal affairs—where a "plausible lie" can directly translate into fatal business risk or legal liability.
However, before this paradigm can sweep across the market, it must overcome the barrier of industry dynamics dominated by massive database vendors. Currently, in the enterprise market, companies such as Oracle, Amazon Web Services (AWS), and Microsoft Azure have built robust ecosystems. Additionally, Neo4j holds sway in the graph database domain, while Pinecone and Milvus each command dominance in the vector database space.
Migrating data from existing systems to such a new triple-store structure and rebuilding core infrastructure is major surgery that carries enormous cost and risk for enterprises. Furthermore, this validation was a demonstration on a powerful on-premises server environment equipped with terabyte-class memory. How this integrated engine's performance holds up when scaled out as a distributed system on a public cloud remains an important verification challenge on the path to practical deployment.
Nevertheless, the message sent by the emergence of AkasicDB is extremely powerful. The global race in AI development is shifting from "enlarging the brain" by increasing model parameter counts, toward "unifying memory" by fundamentally redesigning information retrieval architecture. The cliff of hallucination that we have long faced is not a limitation of some inorganic intelligence. Through more organized, deeply coupled data infrastructure, it is now being steadily dismantled.