Graph-Enhanced RAG (GraphRAG) in Practice

From RAG to GraphRAG: Why Graphs Are Needed

Traditional RAG works by slicing documents, vectorizing them, retrieving similar chunks, and concatenating them to generate answers. This approach works well for simple factual queries, but it struggles when it comes to questions that require understanding relationships between entities and multi-hop reasoning. For example, "Which Nobel laureates were also cultivated by the university where the founder of quantum computing studied?" — this question requires first finding the "founder of quantum computing," then finding the "university," and finally querying "Nobel laureates from that university," involving three relationship hops. GraphRAG is designed to solve such problems by explicitly modeling entities and relationships with a knowledge graph, enabling retrieval with relational reasoning.

GraphRAG Architecture Design

The core of GraphRAG is adding a graph layer on top of traditional RAG. The complete architecture consists of three parts: Document Processing Layer (document parsing → entity recognition → relation extraction → graph construction), Graph Storage Layer (Neo4j/Neptune stores entities and relations, supporting Cypher queries and graph traversal), and Hybrid Retrieval Layer (fusion of vector retrieval and graph retrieval, dynamically selecting retrieval strategy based on query type). The key design is retrieval routing: simple factual queries go to vector retrieval, relational reasoning queries go to graph retrieval, and composite queries combine both.

Building a Knowledge Graph

from openai import OpenAI
from neo4j import GraphDatabase
import json

client = OpenAI(api_key="your-deepseek-api-key", base_url="https://api.deepseek.com")
driver = GraphDatabase.driver("bolt://localhost:7687", auth=("neo4j", "password"))

def extract_entities_relations(text):
    """Use DeepSeek to extract entities and relations from text"""
    prompt = f"""Extract entities and relations from the following text, return in JSON format:
{{
  "entities": [{{"name":"entity name","type":"person/organization/location/concept"}}],
  "relations": [{{"source":"entity A","target":"entity B","relation":"relation description"}}]
}}
Text: {text[:3000]}"""
    resp = client.chat.completions.create(model="deepseek-chat",
        messages=[{"role":"user","content":prompt}])
    return json.loads(resp.choices[0].message.content)

def build_graph(text):
    """Build Neo4j knowledge graph"""
    data = extract_entities_relations(text)
    with driver.session() as session:
        for ent in data["entities"]:
            session.run(
                "MERGE (e:Entity {name: $name}) SET e.type = $type",
                name=ent["name"], type=ent["type"]
            )
        for rel in data["relations"]:
            session.run(
                "MATCH (a:Entity {name: $s}), (b:Entity {name: $t}) "
                "MERGE (a)-[r:RELATES {desc: $desc}]->(b)",
                s=rel["source"], t=rel["target"], desc=rel["relation"]
            )

def graph_search(query, hops=2):
    """Graph multi-hop retrieval"""
    with driver.session() as session:
        result = session.run(
            f"""MATCH path = (start:Entity)-[*1..{hops}]-(related)
            WHERE start.name CONTAINS $query
            RETURN [n in nodes(path) | n.name] as entities,
                   [r in relationships(path) | r.desc] as relations
            LIMIT 10""", query=query
        )
        return [{"entities": r["entities"], "relations": r["relations"]} for r in result]

# Usage
text = "Alan Turing was born in London, studied mathematics at Cambridge University, and is known as the father of computer science."
build_graph(text)
results = graph_search("Turing")
print(json.dumps(results, ensure_ascii=False, indent=2))

Hybrid Retrieval Strategy

The core value of GraphRAG lies in hybrid retrieval—intelligently selecting retrieval paths based on query type. Implement a retrieval router: first use a lightweight classifier to determine the query type (factual/relational/composite), then route to different retrievers. Factual queries go to vector retrieval (fast and accurate), relational queries go to graph retrieval (supports multi-hop reasoning), and composite queries first use graph retrieval to find relevant entities, then vector retrieval to obtain detailed context, and finally fuse and rank. Fusion uses RRF (Reciprocal Rank Fusion) or weighted summation.

Limitations and Optimization of GraphRAG

Although GraphRAG is powerful, it has several practical challenges: High construction cost (entity extraction and relation construction are time-consuming and consume tokens, significant for large-scale documents), Graph quality (LLM extraction may have omissions and errors, requiring manual verification or high-quality extraction prompts), Cold start problem (new domains lack existing graphs, requiring large amounts of labeled data). Optimization suggestions: use batch extraction to reduce API call overhead, introduce entity linking for disambiguation, pre-build indexes for high-frequency entities, and set graph update strategies (incremental update vs. rebuild).

Application of GraphRAG in Enterprise Knowledge Management

We deployed GraphRAG in a multinational manufacturing enterprise to manage its technical documents and patents scattered across 50 countries. Traditional RAG completely failed here—users asked "What materials did the German gearbox design team use to reduce friction coefficient?"—this question spans organizational knowledge ("German team" → team info in HR documents), technical knowledge ("gearbox design" → in product documents), and materials knowledge ("reduce friction coefficient" → in patents and research papers). GraphRAG solved this by building a cross-document entity-relation graph: from HR documents it extracted (German team → responsible for → gearbox design), from product

Optimizing GraphRAG Index Construction Performance

Entity extraction for building knowledge graphs is the most time-consuming step—for a document set of 1 million Chinese characters, using LLM to extract segment by segment can take hours and incur significant API costs. Optimization approaches: Hierarchical extraction—first use lightweight NLP tools like spaCy for fast entity recognition (in seconds), then use LLM for relation extraction—reducing LLM calls from O(number of segments) to O(number of entity pairs, already filtered by spaCy); Batch extraction—package multiple segments into one prompt for one-shot extraction, leveraging LLM's batch processing capability; Incremental updates—when new documents are added, instead of rebuilding the entire graph, only extract entities and relations from the new documents and find connection points with the existing graph. After optimization, the graph construction time for 1 million characters was reduced from 6 hours to 45 minutes, and API costs dropped from $120 to $18.

Hybrid Deployment of GraphRAG and Traditional RAG

GraphRAG doesn't have to completely replace traditional RAG—they can coexist and be intelligently routed based on query type. Our hybrid routing strategy: after a query enters, it first passes through a lightweight classifier (based on DeepSeek's fast classification prompt, about 200ms) to determine the query type: Factual queries (e.g., "Python 3.12 release date") → traditional RAG (vector retrieval, fastest and most accurate); Relational queries (e.g., "Who created Python, and what other projects has he worked on?") → GraphRAG (graph multi-hop retrieval); Complex hybrid queries → first use GraphRAG to find relations, then traditional RAG for details. The classifier achieves 94% accuracy, with only 6% of queries routed to the wrong retriever—far lower than the failure rate of using a single method uniformly. This hybrid architecture improves accuracy from 72% (single RAG) to 89% in comprehensive query scenarios.