Open-source Knowledge Graph + Hybrid Retrieval: Making Multi-hop Reasoning Solid

A Reddit Project that Turned GraphRAG into a Runnable Scaffold

In the past two days, a project resurfaced on r/MachineLearning: a developer has turned the Knowledge Graph + Hybrid Retrieval approach—popularized by Microsoft’s GraphRAG—into an open-source, runnable, full-stack pipeline with a frontend. Django serves as the backend, React as the interface, connecting raw text all the way through to multi-hop question answering.

Those who have worked with RAG will know the background well. When standard vector search encounters questions like “First ask who A is related to, then ask what that person has done”—which require linking across multiple documents—it essentially falls apart: either you hit only the top few most relevant chunks and lose key clues, or you increase top-K to stuff the whole context, which then runs into the classic “lost in the middle” problem, where the model ignores the middle portion. The GraphRAG idea itself is fine, but it has a high barrier to entry: how to build the graph, how to split communities, how to mix retrieval—each step can be a pitfall.

The value of this project is that it brings this pipeline down from “academic paper” level to something an engineer can directly fork and study.

Breaking Down the Pipeline: Five Steps, Each with Trade-offs

The author’s flowchart is clear: Ingestion → Graph Construction → Community Detection → Indexing → Hybrid Retrieval. Let’s go through them one by one, discussing the engineering trade-offs behind each step.

1. Chunking: Overlapping Chunks Preserve Local Context

The first step is to clean and parse the raw text, then split it into chunks with overlap. This sounds basic, but it’s the foundation for everything that follows. Overlapping chunks are nothing new, but in a GraphRAG context, they matter even more—because entity co-occurrence is used later. If you split too cleanly, entities that should be recognized as co-occurring in the same sentence will be split apart, and you’ll lose a lot of edges in your graph.

In practice, chunk size is usually between 300–800 tokens, with 10–20% overlap. This project doesn’t enforce a specific value, leaving it to the user to tune—giving room for experimentation.

2. Graph Building: The Classic spaCy + NetworkX Combo

For each chunk, the author uses spaCy to extract named entities and then uses NetworkX to build a weighted co-occurrence graph: nodes are entities, edge weights represent “how many times the two entities appear together,” and each edge/node stores a reverse pointer—pointing back to which original chunks it came from.

This is the most crucial design in the system. It doesn’t use fancier LLM-based relation extraction (like OpenIE extracting predicates), instead falling back to straightforward co-occurrence statistics. The trade-off is weaker relational semantics, but the benefit is stability, controllability, and low cost. For corporate knowledge bases with lots of jargon, co-occurrence graphs already get you 80% of the way.

If you’ve done similar projects, you know how brittle the LLM triple-extraction route is—the same entity can have a dozen different references, alignment is a nightmare. This project directly uses spaCy’s entity boundaries as unique IDs, avoiding the alignment step.

3. Community Detection: Greedy Modularity Clustering + Preventing “Hub Node Bias”

After building the graph, the next step is to use greedy_modularity_communities to split it into thematic clusters. This NetworkX built-in algorithm maximizes modularity by grouping highly interconnected nodes.

After cutting, for each cluster, the author does something particularly noteworthy: Instead of stuffing all chunks from the cluster into an LLM to summarize, they randomly sample a few chunks to generate the thematic summary.

Why? Because if you rank by node degree and take the top chunks, super high-frequency entities (“company,” “system,” “user,” etc.) dominate the summary, making all clusters’ summaries look alike—this is the “hub node bias” the author mentions. Random sampling gives niche but distinctive chunks a chance to contribute, resulting in better distinction between cluster topics.

This is a very practical engineering insight that you rarely see in academic papers but will make practitioners nod in agreement.

4. Indexing: Dual-Track Parallel—Vector + BM25

After building the graph and generating community summaries, the author feeds all chunks into two indexes simultaneously:

• Dense vector store: encodes chunks with an embedding model and stores them in a vector database (the project provides a swappable interface; FAISS, Chroma, etc. can all be used)
• Sparse BM25 index: builds a classic term-frequency inverted index on the same corpus

These two indexes are complementary: vectors are good at catching semantically similar but lexically different content; BM25 is good at exact-term matches—terms, product names, error codes—that require literal matches. Using only one leaves blind spots; hybrid retrieval is essentially an industry consensus post-2024.

5. Hybrid Retrieval: Query In, Dual-Path Recall

When querying, the system runs the query down two paths: dense semantic recall and sparse keyword recall, then fuses the results (usually with Reciprocal Rank Fusion, RRF). At the same time, leveraging the graph built earlier, it can start at matched entities and do N-hop neighbor expansion to bring related chunks into the candidate set.

This is the core mechanism that enables multi-hop reasoning—using graph structure to bring chunks that are semantically distant but factually connected together.

What Real Problems Does It Solve?

Having explained the process, let’s return to the pragmatic question: What does this do better than standard RAG?

The two most painful cases for standard RAG:

1. Multi-hop QA: e.g., “Who was the CTO of Company X in 2023, and which startup did they later join?” This requires first finding Company X, then the CTO, then jumping to the new company. One-shot vector recall either hits only Company X-related chunks or only that person’s chunks, rarely the whole chain.
2. Global summarization: e.g., “How many core points are in this 500-page report?” Vector recall is local and cannot answer global questions.

This project tackles global questions with community summaries, multi-hop with graph expansion. The approach is sound. Microsoft’s GraphRAG paper reports a 30–80% improvement over vanilla RAG for multi-hop and summarization tasks (depending on the task). While this open-source project doesn’t provide a full benchmark, the architecture aligns.

A Few Critiques

It’s not without flaws.

First, spaCy’s NER isn’t enough for Chinese; you’d need to switch to LTP or use an LLM for NER, which increases cost and latency. The author mainly tested on English corpora; Chinese users will need to adapt it.

Second, greedy_modularity_communities slows down on large graphs—tens of thousands of nodes start to strain it; hundreds of thousands are basically a no-go. In production, you’d switch to Leiden (Microsoft GraphRAG uses Leiden), but NetworkX doesn’t natively support it—you need to integrate libraries like graspologic or cdlib.

Third, while random sampling in community summaries solves hub bias, it introduces instability—summaries differ after each rebuild, which hurts observability in production. You’d generally fix the random seed or sample multiple times and take the intersection.

Fourth, the React frontend looks good but the coupling with the Django backend isn’t suited for embedding directly into existing systems. It’s better as a demo; for production, it should be decoupled.

Practical Tips for Developers

If you plan to fork and adapt it, here are some pointers:

• Start small—run with a small corpus first (e.g., under 100k tokens) to get the pipeline working before scaling up
• Tune chunk size and overlap—varies by domain; smaller for technical docs (~300), larger for narrative text (~600+)
• Adjust hybrid retrieval weights—don’t use defaults; grid search based on query type; increase BM25 weight for keyword-heavy queries
• Control community granularity via the resolution parameter; the more fine-grained the domain, the smaller the clusters
• Use a better embedding model—don’t default to OpenAI’s old ada-002; switch to BGE-M3, E5, or Qwen3-Embedding; multilingual performance differs greatly

The pipeline only calls an LLM in two main spots: community summarization and final answering. It’s not tied to any one model—you can run GPT, Claude, Gemini, DeepSeek, etc. from OpenAI Hub with the same key, swapping models by just changing base_url and model name. This makes comparative experiments very easy.

Final Words

Since Microsoft’s 2024 paper, the industry has been chasing GraphRAG, but there’s a lack of truly runnable, hackable open-source implementations. LangChain and LlamaIndex have graph-related modules, but they’re either too heavy or too abstract, making it hard to quickly grasp what each step does.

This Reddit project’s strength is being complete yet not overcomplicated—it’s not packaged as a framework, just a runnable scaffold where each step is transparent. For developers who want to understand GraphRAG internals or adapt it to their own business, it’s a solid starting point.

Long-term, knowledge graph + hybrid retrieval will be more robust than pure vector RAG. Semantic recall has a ceiling; for enterprise-grade multi-hop reasoning and global understanding, structured elements will inevitably make a comeback.

References

• Original Reddit post: Open-source knowledge graph hybrid retrieval pipeline — author’s post and discussion on r/MachineLearning
• Advanced RAG: Improving accuracy with hybrid dense retrieval and knowledge graphs (Zhihu column) — Experimental analysis of improving RAG accuracy with hybrid retrieval + knowledge graph