MOTHRAG Open Source: Eliminate Knowledge Graphs—Multi-hop RAG Still Beats GraphRAG
MOTHRAG completely cuts out GraphRAG’s offline graph construction workflow, using query-time orchestration plus dense indexing to directly tackle multi-hop question answering. It scores 78.1 on HotpotQA, nearly 10 points higher than GraphRAG.
A Counterintuitive Conclusion: For Multi-Hop RAG, You Might Not Need a Knowledge Graph at All
Over the past two years, the multi-hop RAG community has largely converged on a consensus: if you want high scores on cross-document reasoning tasks like HotpotQA and MuSiQue, you need a graph. Since Microsoft open-sourced GraphRAG in July 2024, it has surged to 31K stars. Then came HippoRAG, RAPTOR, LightRAG, one after another, all following nearly the same path: first use an LLM to extract entity-relation triples from the corpus, then run community detection, and finally traverse the graph at query time.
This approach undeniably works well, but the cost is equally obvious: every time the data changes, you have to rerun the entire LLM indexing pipeline. For high-frequency corpora like pricing catalogs, internal tickets, daily news, and customer service logs, the cost of rebuilding the graph becomes a constant, visible bleed. Microsoft itself acknowledged this in LazyGraphRAG, delaying community summaries until query time and reducing indexing costs from hundreds of dollars to under $5, at the expense of an extra 2–8 seconds of latency per query.
The newly open-sourced Reddit project, MOTHRAG (Moth-Retrieval), pushes the idea even further:
Can we just get rid of the graph entirely?
The authors’ answer is yes: no graph, no GPU, no offline rebuilding. Everything runs through commercial APIs. And here’s the most striking part: on three multi-hop benchmarks, it outperformed GraphRAG, HippoRAG, and RAPTOR across the board.
Let’s Start With the Data
The authors released the following comparison table (combined Accuracy/F1 score):
| Benchmark | MOTHRAG | GraphRAG | HippoRAG | RAPTOR | |---|---|---|---|---| | HotpotQA | 78.1 | 68.6 | 75.5 | 69.5 | | 2WikiMultiHopQA | 76.3 | 58.6 | 71.0 | 52.1 | | MuSiQue | 50.5 | 38.5 | 48.6 | 28.9 |
MOTHRAG ranked first on all three datasets. On 2WikiMultiHop, it beat GraphRAG by nearly 18 points. On MuSiQue, by 12 points. On HotpotQA, by nearly 10 points.
This is not the kind of “we tuned hyperparameters and won by 0.5” result. This is a route-level domination.
More importantly, HippoRAG is currently considered the SOTA within the GraphRAG family, and MOTHRAG still outperforms it by 2.6–5.3 points. So this isn’t a case of padding results with outdated baselines.
Why Can We Eliminate the Graph? First Understand What the Graph Was Solving
To understand why MOTHRAG can discard the graph, we first need to understand what the GraphRAG camp was trying to solve.
The bottleneck of traditional vector RAG is this: once documents are chunked, cross-document entity relationships get fragmented.
You retrieve chunk A saying “Company X heavily invested in AI infrastructure,” and chunk B saying “AI infrastructure faces regulatory risks.” The model has no built-in mechanism to know these facts are connected. GraphRAG solves this by explicitly materializing the chain:
“X → invests in → AI infrastructure → faces → regulatory risk”
as graph edges ahead of time, then performing multi-hop traversal during retrieval.
What’s the cost?
- Indexing cost: Microsoft’s original approach can easily cost hundreds to tens of thousands of dollars for large enterprise corpora
- Update nightmare: changing one piece of data theoretically requires rerunning extraction and community detection
- Extraction quality bottleneck: using spaCy for relation extraction is cheap but crude; using LLMs is accurate but expensive
- Worse performance on simple queries: graph traversal introduces edge-context noise that can pollute semantic retrieval
MOTHRAG’s idea is this:
The “structure” required for multi-hop reasoning doesn’t necessarily need to be materialized into a graph beforehand. It can be assembled dynamically at query time.
What Exactly Is Query-Time Orchestration?
This is the core of MOTHRAG.
It shifts “multi-hop reasoning” from indexing time to query time, using the LLM as a retrieval controller—not for embeddings or extraction, but for deciding “what should I search next?”
You can think of it as a loop:
- Initial retrieval: run dense vector retrieval on the user query and fetch top-k candidate documents
- Gap analysis: let the LLM inspect the current context and determine “what information is still missing to answer this question?”
- Sub-query generation: generate the next-hop query based on the missing information (could be entity expansion, temporal constraints, reverse relation lookup, etc.)
- Retrieve again → reevaluate: repeat steps 2–3 until the LLM believes the evidence chain is complete
- Answer synthesis: generate the final answer from the aggregated context
Sounds a lot like an agent, right? Exactly. But the key point is this:
It bypasses the graph as an intermediate artifact.
A graph essentially pre-materializes structured entity-relation knowledge. MOTHRAG instead assumes the LLM can infer this structure dynamically at query time, as long as it’s given sufficiently relevant evidence.
The underlying assumption is:
The reasoning capabilities of 2025-era models are finally strong enough to handle online relation inference that GraphRAG previously had to solve offline with graphs.
Three years ago, this approach would not have worked because models were too weak. Today, GPT-4o, Claude Sonnet 4.5, Gemini 2.5, and similar models have sufficiently strong in-context reasoning to support this orchestration.
On the Indexing Side: An Extremely Ordinary Dense Index
The authors describe it as a “graph-free dense index,” which basically means: just a standard vector database.
No entity extraction. No relation extraction. No Leiden community detection. No hierarchical summaries. No GPU.
This means:
- Update cost = embedding new documents + append
- It can run on any managed vector DB: Pinecone, Qdrant, Milvus, pgvector, etc.
- Cold start is nearly zero: 100,000 documents can go live within tens of minutes
Compare that to Microsoft GraphRAG indexing 100,000 documents: LLM API costs alone can easily exceed thousands of dollars and take an entire day to run. LazyGraphRAG improves indexing costs somewhat, but adds 2–8 seconds of query latency.
MOTHRAG minimizes both costs simultaneously.
Why the Gains Are Larger on 2Wiki and MuSiQue
One interesting detail in the benchmark table:
MOTHRAG beats GraphRAG by around 10 points on HotpotQA, but by 12–18 points on 2WikiMultiHop and MuSiQue.
This is not accidental.
Most HotpotQA questions are relatively clean 2-hop reasoning tasks. 2Wiki and MuSiQue contain many more 3-hop and 4-hop compositions, along with heavier distractors.
GraphRAG-style systems have a hidden weakness on deep multi-hop reasoning:
Traversal paths explode exponentially.
Community summaries either omit important details or introduce too much noise. Query-time orchestration, by contrast, is adaptive:
If the LLM thinks the evidence is sufficient, it stops. If not, it performs another hop.
This naturally handles variable hop counts better.
It also explains why MOTHRAG scores 50.5 on the difficult MuSiQue benchmark while RAPTOR only reaches 28.9. RAPTOR-style hierarchical summaries suffer severe information loss on long reasoning chains.
When This Approach Makes Sense — and When It Doesn’t
First, some realism: MOTHRAG is not a silver bullet. Its applicability boundaries are fairly clear.
Suitable scenarios:
- Frequently updated corpora (finance, news, ticketing systems, monitoring logs)
- Budget-sensitive deployments that don’t want expensive indexing pipelines
- Teams without graph database operational expertise
- Workloads dominated by multi-hop factual QA
Unsuitable scenarios:
- Questions requiring global synthesis, such as “Summarize the overall trends across these 5,000 annual reports.” GraphRAG’s community summaries still have structural advantages here
- Extremely latency-sensitive applications. Query-time orchestration means multiple LLM calls per query, with end-to-end latency potentially reaching 3–10 seconds
- Situations requiring explainable relationship-path visualization for users (graphs are naturally visualizable; orchestration traces are not)
Another important caveat:
The money saved on indexing gets partially shifted to query-time LLM calls.
If your QPS is high, the economics need to be recalculated. MOTHRAG’s sweet spot is scenarios with “frequent updates + moderate query volume.”
Engineering Considerations: What to Watch Out For
If you plan to integrate MOTHRAG into a production system, there are several practical pitfalls the authors didn’t discuss in depth:
- Choosing the orchestration model
Weak models make poor gap-analysis decisions; expensive models struggle under high QPS. In practice, GPT-4o-mini and Claude Haiku 4.5 seem to offer the best cost-performance balance. Multi-model aggregation platforms like OpenAI Hub make it easy to run A/B tests across models and determine which orchestrates best on your data.
- Loop termination conditions
LLMs are not always reliable at deciding when “enough evidence” has been gathered. You should enforce hard limits such as:
- maximum hop count (recommended cap: 4–5 hops)
- token budget protection
- Recall quality of the dense retriever itself
MOTHRAG’s overall performance depends heavily on whether the underlying retriever can at least surface relevant candidates into the top-50 results. If recall@50 is below 70%, no amount of orchestration intelligence can rescue the system.
Strong embedding models like BGE-M3 or E5-Mistral are recommended as a baseline, and hybrid sparse+dense retrieval tends to be more robust.
- Cache strategy
Similar queries often trigger similar subqueries. A semantic-level subquery cache can significantly reduce costs.
This is an advantage GraphRAG doesn’t naturally possess.
A Bigger Trend: The Center of Gravity in RAG Is Shifting From Index-Time to Query-Time
MOTHRAG is not an isolated phenomenon.
Looking back over the evolution of RAG in the past year:
- First half of 2024: the focus was on index structures — GraphRAG, HippoRAG, RAPTOR, hierarchical summarization
- Second half of 2024: retrieval intelligence started shifting toward the query side — Self-RAG, Adaptive-RAG, Corrective-RAG
- Since 2025: Agentic Retrieval, LazyGraphRAG, and now MOTHRAG are all moving “intelligence” from offline pipelines into online orchestration
The underlying logic is straightforward:
As models become stronger, the marginal value of offline preprocessing decreases.
If models can already perform in-context reasoning tasks that previously required graph structures, insisting on building graphs means paying redundant costs for outdated model limitations.
Will GraphRAG disappear? Probably not in the short term.
For global synthesis, visualization, and auditability, graphs remain an excellent solution. But the consensus that “multi-hop QA requires graphs” has clearly been cracked open by MOTHRAG.
The project has already been open-sourced on Reddit’s r/MachineLearning. The repository integrates with standard commercial APIs and has no hard dependency on local models. Teams wanting to validate the approach on their own data could realistically get an end-to-end system running within an afternoon.
References
- Moth-Retrieval: Graph-Free Multi-Hop Retrieval via Query-Time Orchestration - Reddit: Original release thread from the MOTHRAG authors, including benchmark results and technical details
- GraphRAG: Ushering in a New Era of Relationship-Aware Intelligence with Knowledge Graphs and Generative AI - Zhihu: Chinese overview of the GraphRAG technical ecosystem
