Entity Extraction and Relationship Mapping#

Building a knowledge graph from unstructured text requires 2 core processes that run during ingestion:

1. Entity Extraction: identifies meaningful objects in the text. Modern systems use LLMs or specialized NER models with the following approaches:

   • Schema-defined: Extract only entities matching predefined categories (consistent but limited)
   • Open extraction: Discover any entities present (comprehensive but noisy)
   • Hybrid: Core entities follow a schema, additional entities discovered dynamically

2. Relationship Mapping detects connections between extracted entities. These can be explicit (“Tim Cook is the CEO of Apple”), implicit (co-occurrence in the same context), temporal (“from 2011 to present”), or hierarchical (“Apple Inc. → Apple Hardware → iPhone”).

A critical refinement is entity disambiguation, meaning that the system is able to determine word meaning based on context. Without disambiguation, the graph fragments into disconnected clusters that defeat the purpose of graph-based retrieval.

Semantic Enrichment#

Advanced GraphRAG implementations go beyond raw entities and edges to add layers of semantic richness using the following methods:

1. Entity Embeddings: Each entity gets a vector representation, allowing a hybrid search that combines graph traversal with semantic similarity.

2. Community Detection: The Leiden algorithm (used in Microsoft’s GraphRAG) groups related entities into communities at multiple hierarchical levels. Each community gets an AI-generated summary, which allows efficient global search without visiting every node.

3. Property Graphs: Both entities and relationships carry metadata like confidence scores, source documents, temporal ranges, and embedding vectors, transforming the graph from a simple network into an annotated knowledge base.

Figure 4 - The Graph Construction Pipeline: Transforming unstructured documents into a richly annotated knowledge graph requires 4 stages: document ingestion, entity extraction, relationship mapping, and semantic enrichment. The quality of each stage directly determines GraphRAG performance. Garbage in, garbage out applies doubly when relationships are involved.

Stage 1: Graph Sourcing#

The first stage transforms unstructured text into a structured knowledge graph. Unlike traditional RAG that simply chunk and embed, graph sourcing involves entity extraction, relationship detection, and graph population. You can also use tools like PuppyGraph to map existing relational databases into graph structures without migrating data instead of using a dedicated graph database.

Stage 2: Graph Retrieval#

Instead of vector similarity search returning the top-k most similar chunks, graph retrieval executes structured queries that traverse relationships.

The retrieval process combines multiple strategies:

Graph-Enhanced Vector Search starts with semantic similarity to find initial entities, then expands outward through graph traversal to gather connected context. The nodes are found through embeddings and then their edges are followed to discover related information that wouldn’t be found in an embedding space.

Pattern Matching uses graph query languages like Cypher to find specific structural patterns. A query like “Find all products designed by people who left Apple” becomes a direct graph pattern: (person)-[:WORKED_AT]->(apple) WHERE person.end_date IS NOT NULL, (person)-[:DESIGNED]->(product).

Community-Based Retrieval identifies relevant clusters in the graph first, then explores entities within those communities. This is particularly powerful for broad thematic queries like “What are the main trends in AI research?” where no single entity anchors the question.

Stage 3: LLM Generation#

The final stage transforms retrieved graph data into natural language. Unlike traditional RAG that concatenates text chunks, GraphRAG provides the LLM with structured context using entities, their properties, the relationship paths connecting them, and supporting text evidence.

This structured context dramatically improves response quality. There is no inference required because all relationships are explicitly stated and the system doesn’t need to guess how entities relate because the path to answer the query is in the prompt. The LLM’s job shifts from “figure out the connections” to “explain the connections clearly.”

Figure 5 - The Three-Stage Architecture: GraphRAG’s pipeline transforms documents into a knowledge graph, executes multi-strategy graph retrieval, and generates relationship-aware responses. The middle stage is where GraphRAG diverges from traditional RAG.

GraphRAG makes the LLM’s job easier by providing explicit relationship paths instead of disconnected text chunks, shifting the burden from “infer the connections” to “explain the connections”.

Four Query Execution Patterns#

Different questions require different traversal strategies. There are 4 dominant approaches:

Local Search focuses on specific entities and their immediate connections. For the query “Tell me about Tim Cook’s role at Apple”, the LLM would start at the Tim Cook node, traverse direct relationships, then aggregate properties. This approach is fast, focused, and ideal for entity-specific queries.

Global Search analyzes entire communities or the full graph to answer broad questions. The query “What are the main technological trends in AI?” requires synthesizing information across many entities. Microsoft’s GraphRAG addresses this through hierarchical community summaries which are pre-computed rollups that enable efficient global answers without traversing every node.

Path Finding discovers connections between entities that may be several hops apart. The query “How is Jony Ive connected to Stanford?” would traverse Jony Ive → WORKED_AT → Apple → FOUNDED_BY → Steve Jobs → SPOKE_AT → Stanford. The path is the answer.

Aggregation Queries collect and synthesize information from multiple related entities. The query “What are all the products Apple has released in the last 5 years?” aggregates data from every Product node connected to Apple within the temporal constraint.

Figure 6 - Four Query Execution Patterns: Each pattern addresses a different type of question. Local search zooms in on specific entities, global search uses community summaries for broad questions, path finding traces connections across hops, and aggregation queries collect and synthesize entity data.

Hybrid Retrieval: The Best of Both Worlds#

The most effective GraphRAG implementations do not rely on graph traversal alone. Instead, they combine multiple retrieval strategies in a single query:

Vector → Graph: Find static entities through embedding similarity, then expand through graph traversal. With this method, semantic search finds the starting point and graph structure provides the context.

Full-text → Vector → Graph: Keyword search for specific terms, vector search for semantic similarity, graph traversal for relationship exploration. This is a triple-layer approach that maximizes recall.

Adaptive Routing: Analyze the query intent first. Relationship-heavy questions get graph-first retrieval. Simple factual lookups get vector-first. Broad thematic questions get community-based retrieval. The system adapts its strategy to match the question.

Figure 7 - Adaptive Hybrid Retrieval: The most effective GraphRAG systems analyze the query and route to the optimal approach. Relationship-heavy queries go graph-first, factual lookups go vector-first, and broad questions use community summaries. The results merge into a unified context for the LLM.

Investigative Analysis and Fraud Detection#

A compliance analyst asks: “Explain all suspicious transactions involving companies connected to John Doe.” Traditional RAG retrieves documents mentioning John Doe and documents mentioning suspicious transactions but misses the 3-hop connection: John Doe → owns → Shell Company A → transacted with → Shell Company B → linked to → Known Fraud Ring. GraphRAG traces that path and generates a natural language explanation of the connection chain.

Financial Intelligence#

Consider the query “What companies in our portfolio have supply chain exposure to the semiconductor shortage?” This question requires traversing: Portfolio → Holdings → Companies → Supply Chain → Suppliers → Semiconductor Dependence. The answer is in the intersection of relationships across the graph.

Legal Document Analysis#

Legal texts are dense webs of references, precedents, and interconnected clauses. Consider the following query: “How might changing clause 3.2 affect our obligations under related agreements?” GraphRAG maps clause references as edges in a document graph, traversing the dependency network to identify downstream impacts that a human reviewer might miss.

Healthcare and Life Sciences#

Consider the query “What treatment options exist for patients with condition X who are already taking medication Y?” To answer this, the system must traverse: Condition X → Treatments → Drug Interactions → Medication Y → Contraindications. GraphRAG can navigate these multi-hop medical relationships while considering interaction constraints using structured relationship traversal.

Enterprise Knowledge Management#

The most immediate impact for many organizations is making vast internal knowledge bases conversational. Instead of writing queries to explore a dependency graph or a CRM, we can ask the system in natural language, making graph databases accessible to non-technical users.

Figure 8 - Five Domains Where GraphRAG Transforms Retrieval: Each application depends on multi-hop relationship traversal that traditional RAG cannot perform. For all applications, the answer is not in any single document but from the intersection of relationships across the knowledge graph.

Neo4j GraphRAG#

Neo4j’s Python package is the enterprise-ready choice for organizations already running Neo4j. It provides specialized retrievers that progressively add capability:

• VectorRetriever: Pure semantic similarity (traditional RAG)
• HybridRetriever: Combines vector and full-text search
• HybridCypherRetriever: Adds graph traversal on top of hybrid search (GraphRAG)
• Text2CypherRetriever: Converts natural language directly to Cypher queries

The HybridCypherRetriever is the sweet spot for most GraphRAG use cases. It finds seed entities through embeddings, then traverses 2-3 hops of graph relationships to expand context.

Microsoft GraphRAG#

Microsoft’s implementation takes a fundamentally different approach. Instead of focusing on real-time graph traversal, it pre-processes the entire document collection into a hierarchical community structure using the Leiden algorithm. Each community gets an AI-generated summary. When you ask a broad question like “What are the main technological trends in AI?”, the system searches community summaries in a map-reduce fashion without traversing the graph. This makes Microsoft GraphRAG particularly strong for global search queries over large document collections.

The trade-off: the pre-processing pipeline is compute-intensive, and the community summaries can become stale as data changes.

LlamaIndex PropertyGraph#

LlamaIndex offers the most flexible approach, using modular abstractions that integrate with your existing RAG pipeline. You choose your entity extractor, your relationship extractor, your embedding model, and your graph backend. This makes it ideal for teams that want GraphRAG capabilities without committing to a specific graph database.

Other Notable Implementations#

PuppyGraph offers “zero ETL” GraphRAG, meaning it creates virtual graph views over existing relational databases without data migration. Its Agentic GraphRAG can execute multiple queries while reasoning about intermediate results.

FalkorDB focuses on high-performance graph operations with deep LLM integration, particularly suited for real-time applications where query latency matters.

Amazon Neptune extends its cloud graph database with GraphRAG patterns, ideal for organizations already operating in AWS.

Where GraphRAG Excels#

Relationship-Aware Responses: GraphRAG explains how facts connect in addition to listing them. For example, “Tim Cook became CEO after Steve Jobs” is a relationship-aware response while “Tim Cook is CEO of Apple; Steve Jobs co-founded Apple” is not.

Multi-Hop Reasoning in Natural Language: Consider the query “Who are the investors in companies founded by MIT alumni in the biotechnology sector?” GraphRAG follows the path: MIT → Alumni → Founded → BioTech Companies → Investors. The response includes not just the answer but the reasoning chain.

Enhanced Explainability: Every GraphRAG answer has the exact graph traversal path that produced it. For example, “This account was flagged because Person A is connected to Company B through Transaction C, which shares a pattern with known Fraud Ring D.” The traversal path is the explanation.

Reduced Hallucination: The structured nature of graph data provides factual grounding. The LLM generates from explicit entities and relationships, not from vague semantic similarity. If the graph does not contain an edge, the system does not fabricate one.

Where GraphRAG Struggles#

Graph Construction Complexity: Building a high-quality knowledge graph requires accurate entity extraction, reliable relationship detection, effective entity disambiguation, and continuous maintenance as data changes. Each step introduces potential errors that cascade downstream.

Query Intent Understanding: Converting “What tech did ex-Googlers use at their startups?” into the right graph pattern: (Person)-[:WORKED_AT]->(Google), (Person)-[:FOUNDED]->(Startup), (Startup)-[:USES]->(Technology) This requires understanding intent, temporal constraints, and relationship types. This translation is not always correct.

Scalability at Multiple Levels: Large-scale graphs, high query volumes, complex multi-hop traversals, and real-time response requirements all compete for resources. Scaling all 4 simultaneously is almost impossible.

Implementation Expertise: GraphRAG systems require knowledge of graph databases, graph query languages, NLP pipelines, entity extraction, knowledge engineering, and traditional RAG components. It can be hard to find a team with all those skills or take time to train them.

Do not use GraphRAG because it sounds advanced. Use it because your users are asking questions that require relationship traversal. If your queries are simple factual lookups, traditional RAG is simpler, faster, and cheaper to operate. GraphRAG earns its complexity only when relationships are central to your use case.