RAGU: A Multi-Step GraphRAG Engine with a Compact Domain-Adapted LLM
Graph retrieval-augmented generation (GraphRAG) enhances large language models with structured knowledge, yet existing systems construct knowledge graphs in a single extraction pass, producing noisy entities and brittle retrieval. RAGU, an open-source modular GraphRAG engine, addresses this by separating extraction from consolidation: entities and relations pass through two-stage typed extraction, DBSCAN-backed deduplication, LLM summarization, and Leiden community detection. A key insight motivates a compact extractor: the skills an in-pipeline LLM needs—comprehension, extraction, reasoning over context—are language skills that grow only weakly with model size, unlike factual world knowledge. Accordingly, we train Meno-Lite-0.1, a 7 B model optimized for language skills, which outperforms Qwen2.5-32B on knowledgegraph construction (+12.5% relative harmonic mean) and matches it on English GraphRAG tasks. On GraphRAG-Bench (Medical), RAGU retrieves the most complete context at every factoid level (evidence recall up to 0.84 vs. ≤0.76) and overtakes HippoRAG 2 on synthesis tasks; on multi-hop factoid QA, the apparent HippoRAG 2 advantage is shown to be largely an answer-format artifact.
Introduction. Retrieval-augmented generation (RAG) grounds large language models (LLMs) in external knowledge (Lewis et al., 2020; Gao et al., 2023). Traditional RAG retrieves flat chunks without capturing cross-document entity relationships. Graph RAG (GraphRAG) (Edge et al., 2024; Guo et al., 2025; Gutiérrez et al., 2025) addresses this by building a knowledge graph and using graph traversal during retrieval, but practical adoption faces three obstacles. Obstacle 1: Single-pass extraction. Current systems treat knowledge graph construction as a single LLM extraction pass, producing noisy, duplicated entities with no mechanism to consolidate information across chunks. Obstacle 2: Dependence on expensive LLMs. Extraction quality determines graph quality, so practitioners default to large API models (GPT-4-class). This rests on a false premise: the capabilities an LLM needs inside a RAG pipeline—comprehension, extraction, reasoning over context—are language skills, not factual recall. As we show next, language skills grow weakly with model size, while world knowledge scales steeply.
Discussion / Conclusion. We argued that the LLM inside a RAG pipeline needs language skills—not world knowledge—and that these skills scale weakly with model size. RAGU operationalizes this insight via a modular multi-step pipeline that retrieves the most complete context at every factoid level of GraphRAG-Bench and overtakes HippoRAG 2 on synthesis tasks (Creative Generation AC and Coverage); HippoRAG 2 conversely excels at retrieval precision—leading single-fact AC and chain-following multi-hop reasoning on MuSiQue. The wider multi-hop gap seen under verbose prompts is largely an answerformat artifact. Practically: prefer RAGU when answers must synthesize broad context (summarization, creative generation, long-form QA) under a single-GPU budget, and prefer chain-traversal systems for precise multi-hop fact lookup. Both artifacts are released under open-source licenses.
Lines of inquiry this paper opens 24
Research framings built by reading the notes related to this paper — the questions it feeds into.
How do knowledge graphs enable efficient multi-hop reasoning over alternatives?- How does LLM-PKG compare to mining product relations directly from interaction data?
- How do community summaries and selective traversal differ as graph scaling strategies?
- What graph structures better support multi-hop reasoning than pairwise edges?
- Why does community detection in knowledge graphs outperform pure retrieval or pure summarization?
- Can hierarchical entity extraction from books enable both textual and visual reasoning?
- How do LLMs and knowledge graphs work together in different integration patterns?
- How do community-based summaries differ from retrieval-based traversal in knowledge graph RAG?
- How does map-reduce over communities compare to flat multi-hop retrieval architectures?
- Can inference-time query decomposition replace pre-built knowledge graph structures?
- Why do binary edges lose information when representing multi-entity relations?
- What is the computational cost of constructing and traversing hypergraphs?
- How does hypergraph accumulation differ from single-pass graph retrieval?
- Which knowledge structure types best fit different query types?
- How does knowledge graph structure enable multi-hop reasoning in recommendations?
- How does GraphRAG differ from HippoRAG despite both using knowledge graphs?
- Can query-time logic graphs match the efficiency of pre-built knowledge graph indexing?
- What makes graph traversal superior to vector embeddings for relational reasoning?