[Paper Review] RAGU: A Multi-Step GraphRAG Engine with a Compact Domain-Adapted LLM

• Metadata
• TL;DR
• Introduction
• Key Contributions
• Background and Related Work
  • The GraphRAG lineage
  • The NEREL schema
  • MERA, CheGeKa, MultiQ
• Method and Architecture
  • Separating two scaling curves
  • Multi-step graph construction
  • Five search engines
  • Engineering
  • Meno-Lite-0.1
• Training Objective
• Data and Evaluation Setup
  • Meno-Lite-0.1 training
  • Evaluation
• Results
  • GraphRAG-Bench (Medical)
  • Multi-hop QA: separating out the format effect
  • The IE benchmark
  • Case study: one paragraph to a graph
• Analysis and Ablation
  • Where did the fine-tuning gain go?
  • Wide recall vs. precise retrieval
  • The engineering comparison
  • Cost
• Limitations and Critical Assessment
• Takeaways
• Getting Started
• References
• Further Reading

Metadata

TL;DR

• Most GraphRAG systems build their knowledge graph in a single LLM extraction pass. RAGU splits extraction from consolidation: two-stage typed extraction, DBSCAN-backed deduplication, LLM summarization, then Leiden community detection.
• The more interesting claim isn’t the engine, it’s the hypothesis behind it. What an LLM actually does inside a RAG pipeline — comprehend, extract, reason over given context — are language skills, not world knowledge, and language skills scale much more weakly with parameter count. In the Qwen2.5-Instruct family, F1 on a world-knowledge quiz (CheGeKa) grows 21.1× from 0.5 B to 72 B, while MultiQ — where every needed fact is in-context — grows only 4× (log-linear slopes 0.65 vs. 0.26).
• Acting on that, the authors trained Meno-Lite-0.1, a 7 B extractor. On their own IE benchmark it beats Qwen2.5-32B by 12.5% relative on harmonic mean (0.468 vs. 0.416), driven almost entirely by relation extraction (F1 0.347 vs. 0.239).
• On GraphRAG-Bench (Medical) there is a clean cross-over. HippoRAG 2 wins single-fact lookup (AC 72.4 vs. 54.2), the gap closes monotonically as tasks shift toward synthesis, and flips on Creative Generation (AC 59.0 vs. 56.9, Coverage 57.4 vs. 34.7).
• HippoRAG 2’s apparent dominance on multi-hop QA turns out to be largely an answer-format artifact. Force terse answers and the 2WikiMultiHopQA gap shrinks from −19.3 pp to −5.5 pp, while BioASQ flips (72.9 vs. 72.4). MuSiQue, though, keeps a real gap (54.4 vs. 40.1).

Introduction

RAG is the standard recipe for grounding an LLM in external knowledge, but plain RAG retrieves flat chunks and never captures relationships that span documents. GraphRAG closes that gap by extracting entities and relations into a knowledge graph and traversing it at retrieval time. Since Microsoft’s GraphRAG, systems like LightRAG and HippoRAG 2 have pushed the idea far enough that the open question is no longer “does GraphRAG work” but “when is it worth the indexing cost”.

Put one into production, though, and three things get in the way. First, most systems treat graph construction as a single LLM extraction pass. If the same person shows up under a slightly different surface form in the next chunk, you get a second node, and nothing exists to merge them across chunk boundaries. Second, because extraction quality determines graph quality, practitioners reach for GPT-4-class API models by default. Third, engineering maturity in the open-source ecosystem is thin — installs break, and in at least one popular framework, eval() runs on raw LLM output.

What makes this paper worth reading is that it treats the second obstacle as a claim to be tested rather than an assumption to be paid for. The authors argue that the default rests on a false premise: what an LLM does inside a RAG pipeline is read context, pull out entities, summarize descriptions, and answer from what it was given. All of those are language skills, not factual recall. And those two capabilities, they claim, grow at very different rates with model size.

So the paper ships three things at once — a hypothesis, a 7 B extractor trained to match it, and a modular engine to run it in. It wears the clothes of a system-demo paper, but the parts that repay careful reading are the hypothesis test and the unusually honest reporting of how much (or how little) that fine-tuned extractor buys downstream.

Key Contributions

• The language/world-knowledge hypothesis. World knowledge scales near-linearly with parameter count; language skills scale markedly slower. Tested across six sizes of Qwen2.5-Instruct on MERA. This single claim underwrites every other design decision in the paper.
• Meno-Lite-0.1. A 7 B model derived from RuadaptQwen2.5-7B-Lite-Beta via continued pretraining plus SFT targeted at NEREL-schema extraction and multi-hop QA. Best harmonic mean on the IE benchmark, ahead of a 32 B model.
• The RAGU engine. A six-stage indexing pipeline that separates extraction from consolidation, five search engines, three swappable storage tiers. Installs with pip install graph_ragu, runs on one GPU, MIT licensed.
• Isolating the answer-format confound. Reporting multi-hop QA under both verbose and terse generation protocols shows how much of the between-system gap was formatting rather than retrieval. This is, in my view, the most valuable experiment in the paper.
• A reproducible engineering audit. Appendix A pins every claim about HippoRAG 2 to file and line at a fixed commit — eval() call sites, assert False used as control flow, absent storage abstractions.

Background and Related Work

The GraphRAG lineage

Microsoft GraphRAG (Edge et al., 2024) extracts entities and relations, runs community detection to build a hierarchy, then map-reduces community summaries to answer global questions like “what are the main themes here?”. It works, but indexing is LLM-heavy — the ~40 k tokens/document figure in the cost table later comes from this design.

LightRAG (Guo et al., 2025) trades in the other direction: free-form single-pass extraction plus dual-level retrieval (low-level entities, high-level themes) for speed. Without a schema constraint, the extracted structure is looser. That’s the authors’ explanation for why LightRAG sits last at all four GraphRAG-Bench difficulty levels on answer quality.

HippoRAG 2 (Gutiérrez et al., 2025) takes a different route entirely, drawing on hippocampal memory theory to traverse the graph with personalized PageRank. That approach is unusually good at following chains, which is exactly why it wins single-fact lookup and MuSiQue in the results below. Wikontic (Chepurova et al., 2026) builds Wikidata-aligned graphs, sharing RAGU’s instinct that typed constraints beat free-form output.

The NEREL schema

RAGU’s extraction isn’t free-form — it’s bound to the NEREL schema. NEREL (Loukachevitch et al., 2021) annotates 900+ Russian news articles with nested named entities, relations and events, defining 29 entity types and 49 relation types. RAGU uses that type set as the extractor’s output space, which structurally eliminates the problem of a free-form extractor emitting "creator", "created by" and "made" as three distinct relations.

The cost is real too. NEREL was built for Russian news. In the Dennis Ritchie case study later, “created the C programming language” comes out as WORKS_AS — apparently the closest fit available, since the 49-relation type set doesn’t cover authorship directly. The authors acknowledge in their bias statement that applying the schema to other languages or domains may require adaptation.

MERA, CheGeKa, MultiQ

The hypothesis is tested on Russian-language evaluation suites. MERA (Fenogenova et al., 2024) is a comprehensive Russian LLM benchmark; CheGeKa within it is a quiz-show task where the model has to remember the answer. MultiQ is the mirror image — multi-hop QA where every needed fact sits in the context, so it measures only reading and composing. That contrast produces the paper’s headline figure.

Method and Architecture

Separating two scaling curves

The first figure is effectively the whole argument. Six sizes of the same model family, two tasks:

• CheGeKa (world knowledge): F1 grows 21.1× from 0.5 B to 72 B. Log-linear slope 0.65.
• MultiQ (in-context composition): 4× over the same range. Slope 0.26.

The shape is more convincing than the slope numbers. MultiQ is already at 0.39 by 3 B, saturates around 0.58 at 32 B, and dips very slightly at 72 B. CheGeKa rises the whole way. If what your pipeline needs looks like MultiQ, spending 32 B on indexing is mostly waste.

Multi-step graph construction

Indexing runs in six configurable stages.

Step 1 — Chunking. Three strategies: SimpleChunker (fixed-size with overlap), SemanticTextChunker (embedding-based split points), SmartSemanticChunker (cross-encoder reranking on top). Nothing novel, but everything downstream depends on chunk quality, so the choice is exposed.

Step 2 — Two-stage typed extraction. This is the first real idea. Unlike single-pass systems, RAGU separates entity extraction (Stage 1) from relation extraction (Stage 2):

1. Entities are extracted first and validated against the NEREL schema.
2. The validated entity set is fed back as a constraint on Stage 2 — every source_entity and target_entity in a relation must match a validated entity name.

Without that feedback, an LLM will quietly rename entities mid-extraction (the same person as “Ritchie” in one relation and “Dennis Ritchie” in another) or invent endpoints that never appeared as entities. That’s the standard route to dangling edges and ghost nodes. Splitting the stage and constraining the second pass removes the entire error class by construction. ICL examples can be injected at both stages, selected by semantic, BM25, hybrid, or random strategies.

Step 3 — Consolidation. The second idea, and the “multi-step” in the title. EntitySummarizer groups entities by (name, type) and, for entities with many duplicate mentions, applies DBSCAN clustering plus LLM summarization. RelationSummarizer does the same for relations.

Ordering matters here. Noise is reduced before community detection. Run Leiden on a graph where one real-world entity is still split across five nodes, and the community boundaries themselves come out contaminated. This is precisely the step absent from single-pass systems, and it’s where the authors locate their performance difference.

Steps 4–6 — Community detection, summarization, refinement. Hierarchical Leiden clustering partitions the deduplicated graph, an LLM generates structured community reports (title, summary, findings), and pluggable modules like RemoveIsolatedNodes optionally clean up.

Five search engines

All support cross-encoder reranking and hybrid dense+sparse retrieval via Qdrant. Worth noting: the NaiveRAG row in the results tables is this NaiveSearchEngine, sharing RAGU’s generation prompt. So the RAGU-vs-NaiveRAG comparison isolates the graph’s contribution with prompt differences removed.

Engineering

Four things carry the “production-ready” claim:

1. A three-tier storage abstraction (graph / KV / vector) with lifecycle callbacks, so swapping a backend is a constructor argument — NetworkX→Neo4j, NanoVDB→Qdrant.
2. An async-first API with semaphore-bounded concurrency, keeping throughput safe under API rate limits.
3. Pydantic v2 validation of all structured LLM output, which removes manual JSON post-processing and closes the code-injection surface.
4. Incremental upsert/update/delete with deterministic hash-based IDs, merge policies, and a consistency auditor that verifies cross-store integrity.

Roughly 374 tests plus a deterministic mock LLM server make CI runnable without API keys. Every domain object carries a deterministic MD5 identifier, so any retrieved result traces back to its source text.

Meno-Lite-0.1

Starting from RuadaptQwen2.5-7B-Lite-Beta (Tikhomirov and Chernyshev, 2025), two stages:

• Continued pretraining: 1.3 B tokens of Russian and English educational/scientific text.
• SFT: 50 M tokens covering NEREL-based extraction, multi-hop QA (MultiHop-RAG, mtRAG), and query logs.

The distinguishing move is in the instruction design: the model is taught to use context rather than recall facts — spending its capacity budget on language skills instead of world knowledge, exactly as the hypothesis prescribes.

Training Objective

There’s no new loss function here. Meno-Lite-0.1 is trained with the standard causal-LM objective — next-token cross-entropy for both continued pretraining and SFT — and the novelty lies in what data that loss is applied to, not in its form. So the thing worth formalizing in this section is the scaling hypothesis rather than the objective.

Model task performance $F_1$ against parameter count $N$ as a log-linear relation:

Here $\alpha$ governs how much performance you buy per doubling of parameters. The paper’s quantitative claim is that world-knowledge tasks have roughly 2.5× the exponent of language-skill tasks, and the observed ratios line up reasonably (21.1× vs. 4×, over a 144× parameter range).

The design principle that falls out is simple: if a pipeline component demands a capability with a small $\alpha$, give it a small model. RAG indexing — read a chunk, pull out entities, summarize a description — is squarely in the small-$\alpha$ regime. Answer generation isn’t, which is why the paper still uses gpt-4o-mini there. So the hypothesis isn’t “small models are enough”, it’s “different pipeline stages need different capabilities, so they should use different models”.

Data and Evaluation Setup

Meno-Lite-0.1 training

All training corpora are publicly available datasets, with no personally identifiable information. The IE benchmark is a test-only derivative of NEREL, MIT licensed, and integrated into the LM Evaluation Harness under the nerel-bench task group.

Evaluation

Two design choices deserve credit. Fixing the answer-generation LLM across systems isolates graph-construction quality, and picking a judge from a different model family avoids evaluator–generator overlap — a control that LLM-as-judge setups skip more often than they should.

Results

GraphRAG-Bench (Medical)

GraphRAG-Bench has four levels of increasing difficulty. On Answer Correctness the cross-over is clean:

(all rows using Meno-Lite-0.1 as the indexing LLM)

Coverage — the metric that directly rewards retrieving all relevant material — widens the picture. RAGU leads 57.4 to 34.7 on Creative Generation and 71.1 to 51.7 on Contextual Summarize, and takes Faithfulness 34.2 to 26.6. LightRAG trails everywhere (Creative Generation AC 14.4, Coverage 3.9), which the authors read as the downstream consequence of a structurally poorer graph from free-form single-pass extraction.

Evidence Recall is where the mechanism shows. Fact Retrieval: RAGU 82.4, LightRAG 76.1, HippoRAG 2 75.6. In the same system order (RAGU / LightRAG / HippoRAG 2): Complex Reasoning 74.5 / 71.3 / 66.7, Contextual Summarize 74.8 / 70.2 / 71.8. So RAGU retrieves the most complete evidence and still loses on short-answer accuracy. The authors attribute that to the precision of HippoRAG 2’s chain traversal on single-fact queries. It’s the difference between casting a wide net and aiming a single shot, and which one wins depends entirely on which metric you’re reading.

Multi-hop QA: separating out the format effect

This is the best-designed experiment in the paper. BioASQ, MuSiQue and 2WikiMultiHopQA are pure factoid QA with short gold answers, and in that setting answer format dominates overlap-based metrics. So the authors report both protocols.

(a) Verbose — each system’s default prompt. HippoRAG 2 sweeps: BioASQ AC 74.1 vs. RAGU’s 56.0. But look at ROUGE-L alongside it — 12.2 vs. 48.8. RAGU’s long-form answers simply don’t overlap with terse gold references, depressing both metrics at once.

(b) Terse — single direct answer forced. The picture changes substantially:

BioASQ flips and 2WikiMultiHopQA shrinks to a quarter of its former size. MuSiQue, on the other hand, gets slightly worse. The authors accept that one as a genuine capability gap: MuSiQue is the hardest multi-hop benchmark, and personalized PageRank follows reasoning chains that consolidated retrieval doesn’t surface. Not writing off the one benchmark you lose as a formatting artifact is worth something.

One more thing: the difference between indexing RAGU with gpt-oss-20b (20 B) and with Meno-Lite-0.1 (7 B) is only 1–2 pp. Swapping a 20 B model for a 7 B one barely moves the end-to-end result, which is the hypothesis validated in practice.

The IE benchmark

This measures the extractor itself, not the pipeline. Meno-Lite-0.1 (7 B) tops the harmonic mean at 0.468, with Qwen2.5-32B second at 0.416 — 12.5% relative.

Reading column by column makes the story more specific:

The win is essentially one column wide. Meno-Lite-0.1’s NER (0.504) trails gemma-3-27b (0.544) and Qwen2.5-32B (0.536), and its relation definitions (0.558) trail the 32 B model’s 0.599. But relation extraction F1 is 0.347 against the runner-up’s 0.239 — 45% higher. The authors argue relation extraction is the sub-task most dependent on language comprehension. That’s plausible, but it’s hard to separate from the fact that a model SFT’d on NEREL is being scored on NEREL-schema relation extraction. The authors flag the distributional overlap themselves.

MERA overall comes in at 0.555, with LIBRA passkey retrieval at 0.98 at the 128 K mark. Read that alongside the limitation they state later — multi-hop reasoning degrades past 32 K tokens. Finding a passkey and reasoning across a long context are different capabilities.

Case study: one paragraph to a graph

The paper walks the full pipeline over a two-sentence passage, using the example script shipped with the repository:

Dennis Ritchie, the creator of the C programming language, and the co-creator of the Unix operating system, died on October 12, 2011, at the age of 70. His father, Alistair E. Ritchie, worked for many years at Bell Laboratories in Murray Hill, New Jersey.

Stage 1 (entities). Nine typed entities under the NEREL schema:

Stage 2 (relations). Eight relations, every endpoint constrained to that validated set. The five shown in the paper are Dennis Ritchie —WORKS_AS→ C Programming Language, Dennis Ritchie —WORKS_AS→ Unix Operating System, Dennis Ritchie —DATE_OF_DEATH→ October 12, 2011, Alistair E. Ritchie —PARENT_OF→ Dennis Ritchie, and Bell Laboratories —LOCATED_IN→ Murray Hill.

Communities and retrieval. Leiden clustering partitions the graph into two communities and an LLM writes a structured summary for each. On top of that, LocalSearchEngine answers questions that need several edges — “Where did the father of the creator of the C programming language work?” resolves by chaining PARENT_OF and WORKPLACE to return Bell Laboratories.

Small as it is, the example makes two things concrete. First, what two-stage extraction actually prevents: every relation endpoint is a name fixed in Stage 1, so a partial surface form like “Ritchie” can’t leak out as a separate node. Second, the price of a typed schema — “created the C programming language” lands as WORKS_AS. Plainly wrong to a human reader, but probably the nearest available option among the 49 permitted relation types. Consistency bought at the price of expressiveness, and the paper doesn’t confront the trade directly.

Analysis and Ablation

Where did the fine-tuning gain go?

The ablation surfaces the most interesting tension in the paper:

• Swapping the indexing model from 3 B to 14 B moves AC by ≤1.5 pp.
• ICL injection and entity validation each contribute <1 pp.
• Meno-Lite-0.1 and Qwen2.5-7B are within 1 pp in every configuration.

A model that beat Qwen2.5-32B by 12.5% on standalone extraction is indistinguishable from stock Qwen2.5-7B end to end. And this holds in every pipeline tested — RAGU, HippoRAG 2, and LightRAG alike (compare each system’s two rows in Table 1).

The authors’ reading: this isn’t a failure of the fine-tuning, it’s evidence that graph-RAG QA quality is largely robust to extractor choice once consolidation is present. Meno-Lite-0.1 delivers 32B-class extraction at 7 B cost; the consolidation pipeline delivers downstream robustness; the two artifacts are complementary.

It’s a smooth framing, but flip it around and the paper’s two contributions undercut each other. If the pipeline is robust to extractor quality, the case for training a dedicated extractor weakens; if the extractor really is that good, the pipeline is failing to propagate its advantage. The paper picks the first horn. For a practitioner, though, the more actionable conclusion might be “with a proper consolidation pipeline, a 3 B indexing model is enough” — which, if anything, supports the authors’ hypothesis more strongly than their own framing does.

Wide recall vs. precise retrieval

The divergence between Evidence Recall and Answer Correctness deserves its own note. On Fact Retrieval, RAGU recovers 82.4% of the evidence and lands at AC 54.2; HippoRAG 2 recovers 75.6% and lands at 72.4. Retrieving more of the right material does not translate into short-answer accuracy.

That points at the generation stage more than at retrieval. Hand gpt-4o-mini a broader context and there’s more room for it to fold in relevant-but-off-target material instead of committing to the short answer. The terse-prompt experiment touches exactly this nerve: leave retrieval untouched, tighten only the generation instruction, and RAGU’s BioASQ AC jumps from 56.0 to 72.9 — nearly 17 pp from the same context. If that much moves on generation alone, the factoid-level gaps on GraphRAG-Bench shouldn’t be read as pure retrieval differences either. It’s a shame the paper never connects the two analyses.

The engineering comparison

Appendix A organizes the comparison by production risk rather than by feature: silent data loss on crash, backend migration cost, API-bound throughput, code execution from LLM output, transient failure recovery, regression detection, incremental maintenance, reproducible deployment, modularity.

Two of them are genuinely serious:

1. eval() on model output. HippoRAG 2 parses LLM responses by running Python’s eval() on a regex-filtered substring of the raw output (openie_openai.py:36,88). That’s an arbitrary-code-execution surface if the model ever emits hostile content, and a source of opaque exceptions far from the call site on any syntactic deviation.
2. assert False as control flow. The offline indexing path terminates with assert False (HippoRAG.py:216). Run under python -O and the assertion is stripped, so the offline path silently proceeds into indexing without the online vLLM server the rest of the pipeline expects. That’s the worst class of production bug.

Every claim is anchored to commit d437bfb1 (2025-09-04), so it’s independently verifiable. It is, of course, an audit written by a competing system’s authors.

Cost

Indexing cost is a one-time per-document operation, separate from query-time generation (identical across systems, gpt-4o-mini):

At 100 k documents, that’s roughly USD 10,000 for MS-GraphRAG against ~USD 100 for RAGU. Read the table carefully, though, and the comparison is local serving vs. API serving, not a RAGU-specific win. HippoRAG 2 and LightRAG sit in the same GPU-cost class, and HippoRAG 2 actually uses fewer tokens per document (6 k vs. 8 k).

Limitations and Critical Assessment

Acknowledged by the authors

• The scaling evidence rests on a single model family (Qwen2.5) and selected tasks. Robust across six sizes, but a well-supported hypothesis rather than a universal theorem.
• Meno-Lite-0.1 trades parametric recall for contextual grounding and shouldn’t be used as a standalone knowledge base. Its multi-hop reasoning degrades beyond 32 K tokens, typical of 7 B-class models.
• There’s a distributional-overlap caveat on the IE benchmark: SFT uses NEREL’s train and validation splits while the benchmark uses only the held-out test split with different instruction wordings. The overlap is confined to schema and text domain, not documents — but a residual advantage can’t be fully ruled out.
• The default NetworkX backend doesn’t scale to millions of nodes, and final graph quality remains sensitive to the extraction LLM.

What I’d add

• The hypothesis is validated on a different domain than it’s applied to. The language-vs-world-knowledge evidence comes from Russian benchmarks (CheGeKa, MultiQ); the GraphRAG evaluation is entirely English. The hypothesis looks language-independent, but the paper never shows the same slope separation in English.
• The Evidence Recall numbers disagree between text and figure. The abstract and body report “evidence recall up to 0.84 vs. ≤0.76” and “84 vs. ≤76%”, while the highest value in Figure 3(b) is 82.4. The comparison baseline (76.1) matches the figure, so 0.84 looks like a rounding or transcription error. It’s more conspicuous for sitting in the abstract.
• Single domain, single seed. GraphRAG-Bench was run on Medical only, and no table reports confidence intervals, standard deviations, or seed counts. Calling a −0.9 pp difference “parity” needs a variance estimate.
• The cost comparison’s counterpart never appears in the quality tables. The USD 100 vs. USD 10,000 claim is against MS-GraphRAG, which shows up in neither Table 1 nor Table 2. “100× cheaper than the most expensive system” and “competitive quality” are claims about different comparison sets.
• No query-time cost or latency. Only indexing is analyzed. But MixSearch and QueryPlanEngine issue multiple LLM calls per query by design, and pushing a wide context into gpt-4o-mini shows up on the query bill too. That’s the missing half of the operational story.
• No prescription for the MuSiQue gap. Having diagnosed that personalized PageRank finds paths consolidated retrieval misses, the natural next move is an ablation that bolts PPR-style traversal onto RAGU. If the approaches are complementary, that experiment is the one you want, and it isn’t there.
• Different embedding models across benchmark families. bge-large-en-v1.5 for GraphRAG-Bench, gte-multilingual-base for multi-hop QA, with no stated reason. Controlled within each table, but it makes cross-table reading harder.
• The schema’s semantic imprecision is visible in the paper’s own demo. “Dennis Ritchie created the C programming language” is extracted as WORKS_AS — no authorship relation appears to exist among the 49 permitted types. Schema constraints buy consistency at the cost of expressiveness, and the paper never confronts that trade-off directly.

Takeaways

• Different pipeline stages need different capabilities. The decomposition — language skills for indexing, world knowledge for answering — is a thinking tool that generalizes well past RAG. When sizing a model for a stage, ask what the scaling exponent of that stage’s required capability actually is.
• Separating extraction from consolidation buys a lot on its own. Fixing entities first and feeding them back as constraints on relation extraction eliminates the dangling-edge error class by construction. A textbook case of splitting the pipeline being cheaper and more reliable than growing the model.
• A large share of a benchmark gap can be answer formatting. Simply reporting under two prompt protocols turned −19.3 pp into −5.5 pp. If your system is losing a benchmark, check whether your prompt matches the gold answer format before you touch retrieval. As a reviewer, treat any gap claim built on overlap metrics as suspect until format is controlled.
• Broad recall and precise retrieval are different objectives. Leading Evidence Recall on Fact Retrieval (82.4) while sitting 18 pp behind on Answer Correctness shows how much metric choice drives system evaluation. Optimize Coverage-family metrics for summarization and long-form; optimize precision-family metrics for short-answer lookup.
• A reproducible engineering critique can be a real contribution. Pinning a commit hash and anchoring every claim to file and line turned the kind of observation that usually ends up in a blog post into a verifiable academic appendix — while remaining, as readers should note, an audit of a direct competitor.

Getting Started

pip install graph_ragu

Meno-Lite-0.1 serves on a single consumer GPU via vLLM:

vllm serve bond005/meno-lite-0.1 --max-model-len 131072

The pipeline is configured by injecting the three storage tiers as constructor arguments. Moving from a prototype (NetworkX + NanoVDB) to production (Neo4j + Qdrant) being an argument swap is the central claim of that design.

# Conceptual sketch — see the repository for exact API signatures
from graph_ragu import RAGU, Settings

ragu = RAGU(settings=Settings(language="en"))
await ragu.index(documents)                  # the six-stage indexing pipeline
answer = await ragu.search("...", engine="local")

Full API documentation and runnable examples live in the repository, along with a demo web frontend and a walkthrough video.

References

• Paper: arXiv:2607.11683
• Code: github.com/RaguTeam/RAGU (MIT)
• Model: bond005/meno-lite-0.1 (Apache 2.0)
• Demo video: youtu.be/bicJDMJuQfg

Further Reading

• From Local to Global: A Graph RAG Approach to Query-Focused Summarization (Edge et al., 2024) — The original Microsoft GraphRAG paper, which introduced community detection plus map-reduce community summarization for global questions. RAGU’s Steps 4–6 sit directly in this lineage.
• LightRAG: Simple and Fast Retrieval-Augmented Generation (Guo et al., 2025) — Single-pass free-form extraction with dual-level retrieval, built to cut GraphRAG’s indexing cost. It serves here as the control for “what happens without a consolidation step”.
• From RAG to Memory: Non-Parametric Continual Learning for Large Language Models (Gutiérrez et al., ICML 2025) — HippoRAG 2. Personalized PageRank traversal gives it precision on single facts and strength at chain-following. The main comparison target here, and the system that keeps MuSiQue.
• When to Use Graphs in RAG: A Comprehensive Analysis for Graph Retrieval-Augmented Generation (Xiang et al., ICLR 2026) — The GraphRAG-Bench paper. Its four-level difficulty design (fact retrieval → creative generation) is what makes the cross-over in this review visible at all.
• NEREL: A Russian Dataset with Nested Named Entities, Relations and Events (Loukachevitch et al., 2021) — Source of the 29-entity, 49-relation schema RAGU uses as its extractor output space. That it was designed for Russian news is the key to understanding the schema limitations discussed above.