Loading...🤓
April 14, 2026
Vector search finds similar text but never explicit relationships. GraphRAG models entities and their connections as a graph — and answers questions that require multiple hops through structured knowledge.
Instead of storing documents as isolated chunks, people, organisations, and concepts become nodes, and their relationships become edges in a graph database. A question like "Which projects has the CTO of Company X led?" is answered by traversing the chain Person → Role → Company → Projects directly — the kind of reasoning that semantic similarity alone cannot reproduce.
Rather than running a dedicated graph database with a community detection pipeline, GraphRAG here rides on the existing vector infrastructure (Qdrant + MongoDB). A query follows five steps. First, Qdrant returns the five most relevant documents via embedding search — the same retrieval step as standard RAG. Second, for each document the system checks whether triples (subject | predicate | object) have already been extracted and stored in MongoDB; these are populated by a backfill job after every re-crawl. If a document is missing from the store, a smaller grading LLM extracts triples live from its text, so the mode keeps working immediately for freshly indexed content. Third, the union of all triples becomes an ephemeral, per-query adjacency map (a table that lists, for every entity, all triples in which it appears as subject or object), with entities compared in lowercase and no automatic alias resolution. Fourth, the same grading LLM identifies the entities in the user's question and runs a breadth-first search (BFS): visit all direct neighbours of the question's entities first, then their neighbours, layer by layer — capped at two hops and 30 relationships in the prompt. Fifth, the actual answer LLM receives the relationship chains together with the source documents and produces a response that references both. If the BFS finds no seed in the graph, the system falls open — first to all extracted triples, then to plain vector search — so the user never sees a hard failure.
Microsoft's original architecture relies on a dedicated graph database, a periodic Leiden-clustering pass over the entire corpus, and pre-generated community summaries with map-reduce synthesis for global questions. It's impressive — and considerably oversized for a corpus this size. The variant described here delivers the core benefit of GraphRAG (explicit relationships rather than raw vector similarity) on the existing Qdrant + MongoDB stack, without operating an additional system or owning yet another scheduled clustering job. The trade-off: no global map-reduce mode, no community summaries, reasoning is bounded to two hops. For the typical knowledge questions that come up here — relationship chains between a few entities, neatly contained within the RAG-architectures content — that is an acceptable compromise; for corpora with millions of documents or requirements around global synthesis, the full pipeline is the better fit.
Consider the question "How do central bank interest rate decisions affect technology startup valuations?" A vector-based system would return documents that mention both topics. GraphRAG would trace a chain: central bank leads to rate decisions, which affect capital availability, which influences venture funding, which impacts early-stage valuations. The answer emerges from the relationship chain itself, not from document similarity.
Cause-and-effect reasoning is far more reliable than vector search alone, because the relationship chain comes from explicit triples rather than surface-level similarity. Multi-hop linking is native: the system can join information across nodes that never appear together in any single document. And outputs are highly explainable — every conclusion can be traced through the graph back to the source documents that produced its triples, and false positives caused by superficial semantic similarity drop noticeably.
Building and maintaining the triple corpus requires upfront investment. The LLM-driven extraction can be inconsistent, producing an incomplete or noisy graph. Indexing costs are markedly higher than for pure vector retrieval because every document must be analysed rather than just embedded. And keeping the graph current as source material changes means re-running the backfill — affordable for this corpus, but not free. For very open-ended or chit-chat-style queries, the architecture is overkill.
GraphRAG is only as good as the knowledge graph beneath it — and the graph is only as good as the source material. Three things matter in practice. First, relationships have to be stated explicitly in the source text. A sentence like "The ECB raised the base rate" gives the extractor a clean triple; vague writing drops out of the graph entirely. Second, entity naming must be canonical across the corpus. If "ECB" and "European Central Bank" both appear, the extractor produces two disconnected nodes — there is no automatic alias resolution, and the graph fragments. Third, chunks must stay long enough to preserve the relational context; a triple sliced in half during chunking is simply lost. A practical maintenance habit is therefore to pre-extract triples as a batch job (backfill) after each re-crawl, so production queries don't pay the LLM-extraction cost on every request and gaps in the graph surface before users hit them.
GraphRAG is the right choice when your knowledge base is rich in relationships and users routinely ask questions that link multiple entities. Typical use cases: compliance systems where regulatory connections must be traced, research platforms navigating scientific citation networks, or internal company wikis where people, projects, and departments interconnect. Wherever your data has rich relational structure and your use cases demand causal or multi-hop reasoning, GraphRAG delivers capabilities that no vector-only approach can match.
Edge et al. — From Local to Global: A Graph RAG Approach to Query-Focused Summarization (2024)
Microsoft — GraphRAG Open Source Implementation (GitHub)
https://www.mbnsoftware.de/en/chat?rag=graph
