The Question

“Which employees in the Rome office report to managers hired before 2020?”

What This Requires

4 hops across different entities. No single chunk contains this.

Formal Definition

$\mathcal{G} = (\mathcal{V}, \mathcal{E}, \mathcal{R})$   where   $\mathcal{V}$ = entities,   $\mathcal{R}$ = relation types,   $\mathcal{E} \subseteq \mathcal{V} \times \mathcal{R} \times \mathcal{V}$

Each edge is a triple:   $(h, r, t) \in \mathcal{E}$   where   $h$ = head,   $r$ = relation,   $t$ = tail

Triples Extracted from Documents

Now You Can Answer

“Who is Mario’s manager?” → Mario reports_to → Luigi Bianchi

“Where does Mario work?” → Mario works_in → Engineering located_in → Rome

The Raw Text

Mario Rossi, hired in 2019, works in the Engineering department
under the supervision of Luigi Bianchi. He is eligible for the
2024 remote work policy. The Engineering department is located
in the Rome office.

What We Need

The Prompt

Extract all entities from this text.
Return JSON: [{"entity": "...", "type": "PERSON|ORG|POLICY|DATE",
               "description": "brief description"}]

Text: "Mario Rossi, hired in 2019, works in Engineering..."

LLM Output

The Prompt

Given these entities and text, extract relationships as triples:
[{"subject": "...", "predicate": "...", "object": "..."}]

Entities: Mario Rossi, Luigi Bianchi, Engineering, ...
Text: "Mario Rossi, hired in 2019, works in Engineering..."

LLM Output

Entity Resolution

“The employee” / “he” / “Mr. Rossi” / “the engineer” → all = Mario Rossi — LLMs handle this with overlapping chunks (L4)

Entity Matching Score

$\text{sim}(e_1, e_2) = \frac{\text{embed}(e_1) \cdot \text{embed}(e_2)}{\|\text{embed}(e_1)\| \times \|\text{embed}(e_2)\|}$    If $\text{sim} > \tau$ → merge   ($\tau \approx 0.85$)

You are a knowledge graph builder.
Given this text, extract:
1. All entities with their types
2. All relationships between entities as triples

Return JSON:
{
  "entities": [{"name": "...", "type": "...", "description": "..."}],
  "triples": [{"subject": "...", "predicate": "...", "object": "..."}]
}

Rules:
- Use consistent entity names (full names, not abbreviations)
- Predicate should be a short verb phrase (works_in, reports_to)
- Include temporal relationships (hired_in, valid_from)

Text: """[CHUNK]"""

import json, networkx as nx
from google import genai

client = genai.Client()
graph = nx.DiGraph()

def extract_and_add(chunk: str):
    response = client.models.generate_content(
        model="gemini-2.0-flash",
        contents=SCHEMA_PROMPT + chunk,  # our one-call prompt
        config={"response_mime_type": "application/json"}
    )
    data = json.loads(response.text)

    for e in data["entities"]:
        graph.add_node(e["name"], type=e["type"],
                       desc=e["description"])

    for t in data["triples"]:
        graph.add_edge(t["subject"], t["object"],
                       relation=t["predicate"])

# Process all chunks
for chunk in chunks:
    extract_and_add(chunk)

The Query

“What training courses are required for Mario’s role?”

How It Works

Start at Mario → look at direct edges → find Luigi Bianchi

How It Works

Hop 1: Mario → Luigi   |   Hop 2: Luigi ← Anna, Paolo, Sara

How It Works

Extract the full connected neighborhood of Mario — all nodes, all edges, all types

How It Works

Find the shortest path between two entities — reveals the chain of connections

Step 1: Parallel Retrieval

The Question

“What are the main themes across all 10,000 HR policy documents?”

Problem 1: Global Summarization

“What are the main themes across 10,000 documents?”

No starting entity. Need to summarize the entire corpus.

→ Solved by Microsoft GraphRAG (community detection) and RAPTOR (tree summarization)

Problem 2: Index Freshness

New documents arrive daily. GraphRAG requires full rebuild — hours of reprocessing.

→ Solved by LightRAG (incremental updates)

Problem 3: Multi-Hop Cost

Iterative retrieval needs multiple LLM calls per query: retrieve → reason → retrieve again → reason…

→ Solved by HippoRAG (single-step PageRank retrieval)

The Approach

Community Detection

The Leiden algorithm maximizes modularity $Q$:

$Q = \frac{1}{2m} \sum_{ij} \left[ A_{ij} - \frac{k_i k_j}{2m} \right] \delta(c_i, c_j)$

$A_{ij}$ = adjacency,   $k_i$ = degree of node $i$,   $m$ = total edges,   $\delta(c_i, c_j) = 1$ if same community

Step 1: Pre-compute community summaries (offline)

Each community gets an LLM-generated summary describing its members and relationships:

Step 2: At query time — search summaries, not raw graph

“What are the main themes?” → vector search over community summaries → returns top communities → LLM synthesizes global answer

How It Works

Build a tree of summaries. Search at all levels. Detailed answers come from leaves, overview answers from higher levels.

Search at Every Level

The Problem with GraphRAG

⏱ Hours of reprocessing. Hundreds of dollars in LLM calls.

LightRAG’s Solution: Incremental Updates

⏱ Seconds per document. Pennies in cost.

Five Query Modes

The Problem: Iterative Retrieval is Expensive

“What drugs interact with Patient X’s medications?”

3 retrieval steps × 3 LLM calls = slow and expensive

HippoRAG’s Solution: Retrieve by Association

1 step, 1 LLM call → 6–13× faster, 10–30× cheaper

The Analogy

Personalized PageRank (PPR)

$\text{PPR}(v) = (1 - \alpha) \cdot \mathbf{e}_q + \alpha \sum_{u \in \mathcal{N}(v)} \frac{\text{PPR}(u)}{\deg(u)}$

$\alpha$ = damping factor,   $\mathbf{e}_q$ = query entity indicator vector

PPR scores all nodes by how strongly they associate with the query entity. More paths = stronger association = higher rank.

Key Trade-off

HippoRAG cannot answer global “what are the themes?” queries (no community detection). But for multi-hop entity queries — fastest and cheapest option.