GraphRAG in Practice: Giving Agents Relational Understanding with Knowledge Graphs

Traditional RAG splits documents into chunks and performs vector retrieval to find semantically similar text snippets. This approach struggles with multi-hop reasoning, cross-document relationships, and global summarization. GraphRAG addresses these limitations by extracting entities and relationships from text and building a knowledge graph, giving agents true relational understanding.

The Bottlenecks of Traditional RAG

Vector-similarity-based RAG has three structural limitations:

Flat chunk retrieval: Documents are cut into isolated chunks, each containing only local information. When an agent asks "Which countries are the core team distributed across?", it needs to aggregate information across multiple chunks or even multiple documents — vector search cannot guarantee coverage of all relevant fragments.

No cross-document linking: There are no relationship links between chunks. The facts "Company A acquired Company B" and "Company B's product is X" exist in different chunks. Vector search can find both but cannot establish the causal chain "acquisition → product".

Multi-hop reasoning difficulty: Questions requiring chained reasoning — "Which open-source projects are licensed under Apache 2.0 and have over 10K GitHub Stars?" — have no direct path in vector space.

Core Concepts of GraphRAG

GraphRAG operates in three steps:

1. Entity & Relationship Extraction — Use an LLM to extract entities (people, organizations, products, concepts) and their relationships ("acquired", "collaborates with", "depends on") from text
2. Knowledge Graph Construction — Store as (entity, relation, entity) triples in a graph database or graph-structured index
3. Retrieval Augmentation — When the agent asks a question, traverse the graph structure alongside vector similarity search to find information along relationship paths

Two retrieval modes complement each other:

Mode	Coverage	Typical Use Case
Vector similarity	Semantically similar text chunks	Recall specific facts
Graph traversal	Related entities along relationship paths	Infer indirect connections

When an agent needs to answer "Why are X and Y related?", graph traversal is essential.

Microsoft GraphRAG

Microsoft published the paper "From Local to Global: A Graph RAG Approach to Query-Focused Summarization" in 2024 and open-sourced the implementation on GitHub.

Pipeline Architecture

1. Document chunking — Split input documents by token count, ensuring each chunk fits the LLM context window
2. Entity & relationship extraction — Call the LLM on each chunk to extract entities and relationships, then deduplicate and merge by entity name
3. Leiden community detection — Run the Leiden algorithm on the entity graph to group tightly connected entities into communities
4. Hierarchical summarization — Generate summaries per community, then global summaries across community groups, forming a "local → global" hierarchical index
5. Dual-mode retrieval — Local Search: query at the entity level for specific facts; Global Search: query at the community summary level for overviews and trend analysis

Strengths

• Strong global question answering — Community summary hierarchy is naturally suited for "What are the main themes?" questions
• Leading benchmarks — In the paper's head-to-head tests, global summary quality significantly surpassed traditional RAG + prompt compression approaches
• Mature open-source ecosystem — Official Python package + Neo4j integration + Visual Studio Code extension

Weaknesses

• High indexing cost — Each document chunk requires multiple LLM calls (extraction + dedup + summarization). Processing 1M tokens costs approximately $100-200 in LLM fees
• Slow build speed — Leiden community detection and hierarchical summarization are serial; large corpora can take hours to index
• No incremental updates — Adding or removing documents requires a full rebuild
• Difficult to run locally — Heavy dependency on LLM APIs; quality degrades significantly with local models

pip install graphrag
graphrag init --root ./my_project
graphrag index --root ./my_project
graphrag query --root ./my_project --method local --query "What tech stack does the project use?"
graphrag query --root ./my_project --method global --query "What is the overall architectural design?"

LightRAG

LightRAG was released by a research team at the University of Hong Kong (MIT License), designed from the ground up to address Microsoft GraphRAG's pain points.

Core Design

LightRAG drops community detection and hierarchical summarization in favor of a lighter approach:

• Dual-level retrieval — Low-level entities + high-level concepts. During indexing, it additionally extracts descriptions of the concepts entities belong to
• Incremental updates — Add new documents progressively via the insert method with no full rebuild required
• Graph-structured index — Represents the knowledge graph in plain text with no graph database dependency, making initialization trivial
• Significantly fewer LLM calls — Only 1-2 LLM calls per document chunk

Installation & Usage

pip install lightrag-hku

from lightrag import LightRAG
from lightrag.llm import gpt_4o_mini_complete

rag = LightRAG(
    working_dir="./lightrag_data",
    llm_model_func=gpt_4o_mini_complete,
)

rag.insert("AgentList is an open-source AI Agent directory with over 200 listed projects.")
rag.insert("Microsoft GraphRAG is Microsoft's open-source graph-enhanced retrieval framework.")
rag.insert("LightRAG is developed by HKU and offers a lightweight knowledge graph retrieval solution.")

print(rag.query("What projects does AgentList list?", mode="local"))
print(rag.query("What are the mainstream GraphRAG implementations?", mode="global"))
print(rag.query("Compare Microsoft GraphRAG and LightRAG", mode="hybrid"))

Strengths

• Cost is 1/10 to 1/3 of Microsoft GraphRAG — approximately $10-30 for equivalent corpora
• Supports incremental insertion — ideal for continuously growing document collections
• Trivial initialization — runs in just a few lines of Python
• Multi-LLM backends — built-in adapters for OpenAI, Ollama, Anthropic, and Google
• Fast — no community detection or hierarchical summarization; indexing time is dramatically reduced

Weaknesses

• Global summary quality slightly inferior — lacks the hierarchical community summary structure, so "analyze trends across the entire document collection" tasks are weaker
• Limited deduplication — synonym entity merging accuracy is lower than Microsoft's hierarchical approach
• Smaller community — fewer docs and best practices available

Scenario Comparison

Scenario	Recommended Approach	Rationale
Global summarization / theme analysis — "What are the main topics discussed?"	Microsoft GraphRAG	Community summary hierarchy excels at macro-level overviews
Single-document Q&A — "What are the experimental conclusions?"	LightRAG	Cost-effective; no need to run global summaries for one document
Incremental multi-document collection — "100 new docs daily with ongoing queries"	LightRAG	Supports incremental insertion without full rebuild
Agent long-term memory — "Remember user preferences and update over time"	Graphiti / Zep	Temporal knowledge graphs with forgetting and priority support
Conversation context augmentation — "What project did the user mention earlier?"	LightRAG	Conversation is incremental text; fast insert and query

GraphRAG + Agent Integration

Both LangChain and LlamaIndex have built-in GraphRAG support:

from langchain_community.graphs import Neo4jGraph
from langchain.chains import GraphCypherQAChain

graph = Neo4jGraph(url="bolt://localhost:7687", username="neo4j", password="password")
chain = GraphCypherQAChain.from_llm(llm=llm, graph=graph)
chain.run("Which projects related to knowledge graphs are listed in AgentList?")

LlamaIndex provides GraphRAGQueryEngine that connects directly to Microsoft GraphRAG index output. Dify and Open WebUI have also added knowledge graph retrieval support in recent releases.

Temporal Knowledge Graphs: Agent Long-Term Memory

Traditional GraphRAG focuses on "static knowledge in documents," but an agent's long-term memory must handle "knowledge that changes over time." Graphiti and Zep introduce temporal knowledge graphs — every entity and relationship carries a timestamp, enabling queries like "what was the state at time X" and "what changed between periods."

from graphiti import Graphiti

g = Graphiti()
g.add_episode("User said: I like Python and Rust")
g.add_episode("A month later user said: I mainly use Go now")

g.search("User's favorite programming language", time_context="three months ago")
# → "Python, Rust"

g.search("User's favorite programming language", time_context="now")
# → "Go"

This is critical for building an agent's "memory layer" — the agent needs to know when user interests change rather than forever remembering outdated information.

Selection Guide

Choose based on budget, corpus size, and query type:

• Large corpus global analysis → Microsoft GraphRAG. Budget over $100 in LLM costs, millions of tokens, primary queries are macro summaries and trend analysis.
• Limited budget / fast iteration → LightRAG. Personal projects, small teams, budget under $30, need quick deployment and incremental updates.
• Agent long-term memory → Graphiti / Zep. Need to track user preferences over time with forgetting and temporal queries.
• Existing Postgres infrastructure → TypeGraph (TypeScript). Built on Postgres + pgvector, seamless integration with existing data stacks.
• Need a visual query interface → Add Neo4j Browser or GraphQL API on top of Microsoft GraphRAG or LightRAG.

Decision matrix:

Query type →    Global summary  Specific facts  Long-term memory
Corpus size ↓
Small (<10K)        LightRAG        LightRAG        Graphiti
Medium (10K-1M)     MS GraphRAG     LightRAG        Graphiti
Large (>1M)         MS GraphRAG     MS GraphRAG     Graphiti

Summary

GraphRAG is not a replacement for vector RAG — it is a complement. Vector retrieval finds "similar chunks," while graph retrieval finds "connected paths." Together, they give agents true relational understanding:

• Microsoft GraphRAG — best for global analysis and research; high indexing cost but leading quality
• LightRAG — best for rapid prototyping and small-to-medium projects; low cost, fast iteration
• Graphiti / Zep — solve temporal reasoning needs for agent long-term memory
• Mainstream frameworks (LangChain, LlamaIndex, Dify, Open WebUI) all have built-in GraphRAG support

The first step in choosing a solution is not comparing features — it's clarifying your query type. Do you need your agent to "retrieve facts" or "understand relationships"?

---

Prepared by AgentList Team. Explore more RAG and knowledge graph projects in our directory.