Multi‑Hop Reasoning vs Document Parsing: Comparing GraphRAG, LightRAG, AgenticRAG and RAGFlow

Background and Classic RAG Limitations

The traditional vector RAG workflow consists of chunking, embedding, top‑K vector retrieval, and feeding results to an LLM. While sufficient for FAQ or single‑document Q&A, real‑world scenarios often require multi‑hop reasoning, global theme aggregation, and robust document parsing, which the basic pipeline cannot guarantee.

GraphRAG

Project Overview

Maintainer: Microsoft Research

Release: 2024 (v3.1.0)

Stars: 33.5k, Forks: 3.5k

License: MIT

Core Design

GraphRAG first extracts entities and relationships from each chunk, builds a graph (nodes = entities, edges = relations), performs Leiden community detection, and generates a summary for each community level. The index stores the graph, community summaries, and the original chunk vectors.

Processing Stages

Stage 1 (Indexing)
1) Text chunking
2) LLM entity & relation extraction → entity list, relation list, optional attributes
3) Graph construction (nodes + weighted edges, merge same‑name entities)
4) Leiden clustering → hierarchical communities (Level 0 … Level N)
5) LLM generates a natural‑language summary for each community
Store: graph + community summaries + chunk vector index

Stage 2 (Query) offers two paths:

Local Search : Identify key entities from the query, locate them in the graph, traverse edges, retrieve neighboring nodes and community summaries, assemble context, and let the LLM answer.

Global Search : Use an LLM to score communities, keep the most relevant (≈77 % token reduction), generate intermediate answers per community (Map), then combine (Reduce) into a final answer.

Key Trade‑offs

All multi‑hop and global reasoning costs are front‑loaded in the indexing phase; updates require re‑extracting entities, rebuilding the graph, and re‑running Leiden clustering, making incremental updates expensive for dynamic data.

LightRAG

Project Overview

Maintainer: HKU Data Science Lab

Release: 2024 (v1.5.0)

Stars: 36.2k, Forks: 5.1k

License: MIT

Core Design

LightRAG retains the graph‑based retrieval advantage but removes the costly community clustering and hierarchical summary generation. It introduces a dual‑indexing scheme that supports incremental updates.

Processing Stages

Stage 1 (Indexing)
1) Text chunking (configurable)
2) LLM entity & relation extraction (finer granularity than GraphRAG)
3) Graph indexing: entities → nodes (NetworkX/Neo4j/AGE), relations → edges (no Leiden clustering)
4) Vector indexing: entity/relationship descriptions + original chunks → embeddings (Milvus/OpenSearch/Qdrant/pgvector)

Query Modes (Four)

Naive : Pure vector retrieval, no graph.

Local : Graph‑only retrieval for precise entity queries.

Global : Vector‑only retrieval for macro‑theme inference.

Hybrid (default) : Parallel graph and vector retrieval followed by a reranker.

Key Trade‑offs

Incremental updates are efficient because only affected graph nodes and vector entries need refreshing. However, without pre‑computed community summaries, global theme coverage is weaker than GraphRAG, relying on high‑level vector search to approximate.

AgenticRAG

Concept

AgenticRAG is an architectural paradigm rather than a single repository; implementations include LangGraph and LlamaIndex. The core idea is to let an AI agent decide whether to retrieve, which tool to use, and whether to iterate, turning retrieval into a dynamic tool call.

Workflow Example (LangGraph)

The system is represented as a directed cyclic graph where each node is a tool (dense vector search, BM25, hybrid search, web search, SQL query, reranker, calculator, code executor, etc.). The agent invokes tools based on the query and intermediate results.

# Example tool list (MCP‑standardized)
tools = [
    dense_vector_search,   # default semantic similarity
    bm25_sparse_search,   # exact keyword match
    hybrid_search,        # BM25 + dense
    web_search,           # when corpus is stale
    sql_query,            # structured metric queries
    reranker,             # second‑stage ranking (Cohere/BGE)
    calculator,           # numeric calculations
    code_executor         # execute code snippets
]

Key Trade‑offs

Each tool call incurs an LLM inference, leading to higher latency and linearly increasing token consumption with iteration depth; budgets and step limits are required to avoid excessive cost. Additionally, hallucination can accumulate as the agent iterates on imperfect context.

RAGFlow

Project Overview

Maintainer: InfiniFlow

Release: 2024 (v0.25.6)

Stars: 81.9k, Forks: 9.4k

License: Apache 2.0

Core Design

RAGFlow focuses on the front‑end of the RAG pipeline: ensuring documents are correctly understood before retrieval. It treats many RAG failures as data‑quality issues rather than retrieval algorithm problems.

Full Pipeline

Stage 1 (Document Ingestion)
1) Parser – DeepDoc deep document understanding
2) Transformer – template‑based chunking
3) Indexer –
   • Embedding → vector index (Elasticsearch/Infinity)
   • Keyword extraction → BM25 index
   • Metadata extraction (optional)
   • Knowledge graph construction (optional, GraphRAG mode)
   • Tree‑structured summaries (optional, TreeRAG mode)

TreeRAG (Resolving Recall‑Generation Conflict)

Offline:
- Chunk → LLM analysis → hierarchical summary tree (like a book index)
- Store: summary nodes → pointers to original chunks
Query:
- Precise chunk retrieval → expand upward along the summary tree for context
Benefit: decouples retrieval granularity from generation granularity

Retrieval & Generation

1) Hybrid retrieval: vector (semantic) + BM25 (keyword) in parallel → RRF fusion
2) Reranker: cross‑encoder re‑ranking
3) Citation grounding: each retrieved chunk carries page/position metadata for traceability
4) LLM generates answer with citations

Agentic Extension

RAGFlow includes a visual Agent builder (Canvas) that exposes the retrieval workflow as nodes, supporting multi‑turn memory, MCP tool calls, and cross‑source synchronization.

Key Trade‑offs

It is a platform/SaaS; adopting it binds you to its tech stack.

DeepDoc parsing is resource‑intensive; benefits are highest for complex PDFs, scanned documents, or mixed layouts.

By default it does not build an explicit knowledge graph, so multi‑hop reasoning is weaker than GraphRAG/LightRAG.

Changing embeddings, vector stores, or chunking strategies requires deep understanding of the data flow.

Comparative Limitations

GraphRAG

Full‑scale indexing remains costly for very large corpora; LazyGraphRAG reduces indexing cost but its open‑source progress is uncertain.

Domain‑specific entity schemas demand careful design.

Leiden clustering is sensitive to graph construction and may produce slightly different results across runs.

LightRAG

Graph quality depends on the extraction model; smaller models introduce more noise.

Global mode lacks community summaries, reducing coverage of corpus‑wide themes.

Future work (e.g., E²GraphRAG) may challenge LightRAG’s latency advantage at massive scale.

AgenticRAG

Latency and token usage grow with each iteration; step and budget limits are essential.

Early retrieval errors can be amplified over multiple rounds.

Non‑deterministic execution paths hinder reproducibility.

RAGFlow

Without explicit knowledge graphs, cross‑document multi‑hop reasoning is limited.

Switching embeddings, vector stores, or chunking strategies requires deep configuration.

DeepDoc/OCR consumes significant resources; asynchronous processing is recommended for large corpora.

Guidance for Practitioners

Data constraints first : For complex document formats (scanned PDFs, mixed layouts), prioritize RAGFlow to ensure high‑quality parsing before any retrieval.

Query characteristics dictate structure : Use GraphRAG for static corpora with heavy relational queries; choose LightRAG for dynamic corpora needing hybrid queries.

Task openness determines control flow : When queries vary widely and external tool integration is needed, AgenticRAG offers flexibility at the cost of latency and expense.

Start with a baseline : Deploy an Advanced RAG setup (Hybrid retrieval + reranker) as a reference point before moving to specialized graph‑based solutions.

Combination Strategies

RAGFlow + LightRAG : Use RAGFlow’s high‑quality parsing to feed clean chunks into LightRAG, which then builds a graph and dual index for stronger retrieval.

AgenticRAG invoking Graph/LightRAG : The agent treats GraphRAG or LightRAG as a tool for relational reasoning while falling back to vector search for simpler queries.

Adaptive routing : Classify queries (e.g., via a lightweight LLM or heuristic) and route Naive RAG for simple factoid questions, graph retrieval for relational queries, and AgenticRAG for open‑ended or tool‑rich tasks.

Conclusion

Choosing the right RAG framework depends on document quality, query complexity, and operational constraints. Evaluate data parsing needs, graph‑related reasoning requirements, and flexibility versus cost before committing to a specific solution.