Disclosure: Advancer is an investor in Aiqbee. I am writing about research that informed that investment. I have made every effort to cite sources accurately, and where I am drawing my own conclusions rather than reporting findings, I will say so.

The Problem With Searching by Similarity

Most AI knowledge systems work the same way under the hood. They break your documents into chunks, convert each chunk into a vector (a list of numbers representing its meaning), and store those vectors in a database. When you ask a question, the system converts your question into a vector too, then finds the stored chunks whose vectors are closest. This is semantic search, and for straightforward lookups it works well. Ask 'what is our refund policy?' and it will find the chunk that states the refund policy.

The problem emerges with questions that require connecting information across multiple sources. Try asking 'what were the main technical decisions we made last quarter and how do they relate to each other?' That question does not match any single chunk. It requires pulling together architecture decision records, sprint retrospectives, design documents, and meeting notes, then synthesising them into a coherent answer. Vector search finds individual pieces that look similar to your question. It cannot reason across them.

What the Research Shows

In April 2024, a team at Microsoft Research published 'From Local to Global: A Graph RAG Approach to Query-Focused Summarization' (Edge et al., arXiv:2404.16130, revised February 2025). Instead of just storing chunks and vectors, their approach has an LLM read the source material and extract entities (people, concepts, decisions, systems) and the relationships between them, building a knowledge graph. The Leiden community detection algorithm then groups closely related entities into clusters at multiple levels of detail, from broad themes down to fine-grained specifics. An LLM generates summaries for each cluster.

The results against standard vector-based RAG were decisive. GraphRAG won on answer comprehensiveness in 72% to 83% of head-to-head comparisons, depending on the level of detail. On diversity of coverage, it won 62% to 82% of the time. Comprehensiveness results were significant at p < .001; diversity at p < .01 or better depending on the dataset.

The efficiency result caught my attention. At the broadest level of summarisation, GraphRAG used between 9 and 43 times fewer tokens than processing the source text directly, while still outperforming vector search. Better answers and lower token usage is not a trade-off you usually get to make.

Why Hierarchical Summaries Matter

The key insight in the Microsoft paper is that pre-computing summaries at different levels of abstraction solves a problem that vector search fundamentally cannot address. When you ask a broad question like 'what are the main themes in this dataset?', vector search has no good answer. There is no single chunk that contains 'the main themes.' The information is distributed across thousands of passages.

GraphRAG handles this by organising entities into communities (clusters of densely connected nodes) and generating a summary for each community. A broad question gets answered by combining a handful of high-level community summaries rather than trying to retrieve and stitch together hundreds of individual text fragments.

This mirrors how people actually think about complex domains. You do not understand a large software project by reading every file. You understand it by grasping the major subsystems and how they relate to each other, then drilling into specifics when needed. The hierarchical community structure provides exactly that: a zoom lens on knowledge that operates at different magnifications.

It Is Not Either/Or

A February 2025 study by Han et al. ('RAG vs. GraphRAG: A Systematic Evaluation and Key Insights,' arXiv:2502.11371) tested this more carefully and found the picture is more nuanced. For simple single-hop lookups, traditional vector RAG still performed better: 68.18 versus 65.44 F1 score on the Natural Questions benchmark. But for multi-hop questions that require reasoning across multiple pieces of information, GraphRAG pulled ahead: 71.17% versus 65.77% accuracy on MultiHop-RAG. On temporal reasoning, the gap was even larger: 49.06% versus 25.73%.

The most useful finding: combining both approaches pushed accuracy to 77.62%. Vector search catches the direct matches. The graph catches relationships that vector search misses. Separately, Sarmah et al. tested a hybrid approach on financial earnings call transcripts ('HybridRAG,' arXiv:2408.04948, published at ACM ICAIF 2024). Answer relevance improved from 0.91 with vector-only to 0.96 with the combined approach, while the graph component alone achieved 0.96 context precision versus 0.84 for vectors.

The Knowledge Problem in Software Teams

I spend most of my time working with software teams across New Zealand and Asia, and the same knowledge problem comes up everywhere. A typical product team of ten people generates enormous amounts of institutional knowledge: architecture decisions, incident post-mortems, customer feedback patterns, deployment runbooks, competitive analysis, integration quirks that only one person knows about because they debugged that particular API connector six months ago.

Where does all of this end up? Some of it lands in Confluence. Some in Notion. Some in Slack threads that nobody will find again. Some in a Google Doc that three people have bookmarked but nobody has updated since last quarter. A lot of it lives in people's heads, which works until those people go on holiday or leave the company. The knowledge exists. It is just scattered, disconnected, and impossible to query as a whole.

Why Version Control Does Not Solve This

I have watched teams try to solve this with the tools they already know. Git wikis. Markdown repositories with strict folder structures. Elaborate Confluence spaces with carefully designed page hierarchies. These approaches share a fundamental limitation: they treat knowledge as documents to be filed, not as connected ideas to be explored.

When you file a document about a technical decision into a folder called 'Architecture,' you lose the connections to the customer research that prompted it, the alternative options considered, the cost analysis that influenced the choice, and the follow-up decisions it triggered. Those connections exist in the heads of the people who were in the room. They do not exist in the filing system.

Git falls over for knowledge management in specific ways. It is designed for asynchronous editing with explicit merge points, not for ten people simultaneously curating shared understanding in real time. It requires technical proficiency that excludes most of the people whose knowledge you actually want to capture. And its diff-and-merge model, which works brilliantly for source code, produces absurd conflicts when applied to prose documents that multiple people are reorganising at the same time.

Neurons and Synapses

This is the problem Aiqbee set out to address. Rather than treating knowledge as documents, Aiqbee models it as a brain. Individual units of knowledge are neurons. The connections between them are synapses. Together they form what Aiqbee calls a Brain: a living knowledge graph that a team can query, contribute to, and curate through conversation.

The metaphor maps directly to how GraphRAG works. In the Microsoft paper, the LLM extracts entities and relationships to build a graph, and communities of related entities get summarised at multiple levels. In Aiqbee, those entities are neurons and the relationships are synapses, but the underlying structure is the same: a network of interconnected knowledge that can be traversed, summarised, and queried at different levels of detail.

What makes this practical rather than academic is the interaction model. You do not need to learn a graph query language or design an ontology. You ask your LLM to reorganise and ingest new information, and the Brain updates. You curate connections through chat, linking ideas that a human recognises as related but that an automated system would miss. Tom Gruber, the creator of Siri, described something very similar in 2008 when he wrote about 'collective knowledge systems' (Web Semantics, Volume 6, Issue 1): as people collaborate in virtual spaces, 'everything they did was kept and could be shared. As a consequence of working online together, they contributed to a collective knowledge of what they knew and knew how to do.'

The Human Curation Gap

There is a finding in the recent research that does not get enough attention. Han et al. (2025) found that only 65.5% to 65.8% of the entities needed to answer questions existed in the automatically constructed knowledge graphs. Automated extraction misses roughly a third of what matters.

The things it misses tend to be the implicit connections: the reason two apparently unrelated projects share a dependency, the historical context behind a particular technical choice, the customer relationship that connects a support issue to a product roadmap item. These are the connections where human judgement adds the most value.

This is why fully automated knowledge management falls short, and why the curation model matters. The LLM handles the heavy lifting of extraction and organisation. Humans curate the connections that the machine does not see. In Aiqbee's model, your team looks at the Brain, spots missing connections between neurons, and adds synapses that link ideas the system would not have connected on its own. The research from Peng et al. ('Graph Retrieval-Augmented Generation: A Survey,' ACM Transactions on Information Systems, 2024) supports this: combining human-curated graph structure with automated retrieval 'enables more precise and comprehensive retrieval, capturing relational knowledge.'

Concurrent Knowledge, Not Sequential Commits

One angle the academic papers do not address directly, but that matters enormously in practice, is concurrency. Software teams do not learn things one at a time. On any given day, the frontend developer discovers something about browser compatibility, the backend developer learns something about database performance under load, the product owner gets feedback from three different customers, and the architect spots a dependency between two planned features that nobody had noticed. All of this happens simultaneously.

A knowledge system built on documents and file versioning forces this into a queue. Someone writes it up, submits a pull request, gets it reviewed, merges it. By the time it is merged, the context has moved on. A Brain, by contrast, accepts concurrent contributions from the entire team. Ten people can add neurons and create synapses at the same time without merge conflicts, because a graph has no inherent serialisation requirement. This is the same property that makes graph databases popular for social networks and recommendation systems: relationships can be added concurrently without locking the whole structure.

What This Means in Practice

The research paints a clear picture. For simple lookups, vector search works fine. For anything that requires reasoning across multiple pieces of information, connecting ideas, understanding themes, or answering questions that span documents, graph-based approaches produce substantially better results. The best results come from combining both, which is precisely what GraphRAG does.

For software teams, the practical question is not whether knowledge graphs work better than document retrieval for complex questions. The research has answered that. The question is how to get your team's scattered, largely undocumented institutional knowledge into a structure that AI tools can actually use. That means a system easy enough for non-technical team members to contribute to, structured enough to support graph-based retrieval, and connected enough to work with whatever AI tools the team prefers.

Aiqbee is one answer to that question, and it is the one we invested in because it gets the balance right between automated extraction and human curation, between structure and accessibility, and between keeping knowledge private and making it useful. For organisations that need their data to stay on-premises, Aiqbee's Hive Server provides self-hosted deployment without sacrificing the Model Context Protocol integration that connects it to Claude, ChatGPT, and other AI tools.

If your team's knowledge currently lives in a dozen different tools and about fifty people's heads, the research suggests there is a better way to organise it. And the sooner you do, the more value you will get from every AI tool you adopt.