"What are the main themes across these 500 pages?" — that question kills basic RAG. No single chunk contains the answer. Microsoft's Graph RAG (2024) solved it by building a knowledge graph of the entire corpus and summarizing topical communities. For multi-hop questions ("How is Einstein connected to Princeton's economy?"), graphs traverse what vectors can't: explicit relationships. This is the architecture behind Google's Knowledge Panel and the corpus-level answer quality basic RAG can never reach.
Learning Objectives
After this lesson, you will be able to:
Understand what a knowledge graph is -- a network of facts connecting people, places, and concepts -- and know when it works better than plain text search
Walk through how graph traversal finds answers by following connections (Einstein -> worked at -> Princeton) instead of searching for similar text
Explain how Graph RAG combines structured knowledge graphs with LLMs to answer relationship questions and global corpus-level questions that basic RAG cannot handle
Describe entity resolution -- the process of merging duplicate mentions of the same real-world entity -- and explain why it is the hardest part of automated knowledge graph construction
Knowledge graphs sound fancy but they are actually one of the most intuitive ideas in AI -- you have been making them your whole life every time you drew a mind map or a concept web. This lesson just formalizes what your brain already does naturally.
Knowledge graphs are like the difference between a pile of index cards and a mind map. The index cards contain all the information, but the mind map shows how everything connects. For questions about relationships, paths, and connections, the mind map wins every time.
Standard RAG retrieves text passages based on semantic similarity to a query. This works well for "what" questions but struggles with "how are these things connected?" questions. Knowledge graphs represent information as a network of entities and relationships, enabling a fundamentally different kind of retrieval: traversal rather than similarity search.
A corpus of documents is ingested -- research papers, internal docs, knowledge base articles. Unlike standard RAG which only chunks and embeds text, Graph RAG also extracts the structured relationships hidden within the unstructured text.
An LLM reads each document and extracts entities (people, organizations, concepts, products) and relationships between them (works_at, developed_by, treats, causes). Each fact becomes a triple: (subject, predicate, object). "OpenAI released GPT-4" becomes (OpenAI, released, GPT-4).
All extracted triples are assembled into a knowledge graph -- a network of nodes (entities) and edges (relationships). Entity resolution merges duplicates: "OpenAI," "Open AI," and "the company behind ChatGPT" all become a single node. The graph makes implicit connections explicit.
When a user asks a relational question like "Who are the co-founders of the company that developed GPT-4?", the system identifies the entities in the query and traverses the graph: GPT-4 --[developed_by]--> OpenAI --[co-founded_by]--> Sam Altman, Greg Brockman, etc. Multi-hop answers emerge from following edges.
The system extracts the local subgraph around the query's entities -- all nodes and edges within 1-2 hops. This subgraph captures the relational context that flat text retrieval would miss. For global questions, community summaries provide corpus-level themes.
The subgraph triples are serialized into text and combined with chunks retrieved from the vector store. The LLM receives both relational structure (from the graph) and detailed prose (from vector search), giving it a richer, more complete context for generation.
The LLM generates an answer grounded in both structured graph knowledge and unstructured text. For relational questions, the graph provides precise, auditable chains of reasoning. For semantic questions, the vector context fills in detail. The result is more accurate and more explainable than either approach alone.
Use an LLM to extract entities and relationships from unstructured text:
pythonreference · read-only
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
def extract_triples(text, llm):
prompt = f"""Extract all factual relationships from this text.
Format: (subject, relationship, object)
Text: {text}
Triples:"""
response = llm.generate(prompt)
return parse_triples(response)
# Example:
text = "OpenAI, founded by Sam Altman, released GPT-4 in March 2023."
# Extracted triples:
# (OpenAI, founded_by, Sam Altman)
# (OpenAI, released, GPT-4)
# (GPT-4, release_date, March 2023)
Try it! Pick any paragraph from Wikipedia and manually extract the facts as triples: (subject, relationship, object). For example, from "Marie Curie was born in Warsaw and won two Nobel Prizes" you get (Marie Curie, born_in, Warsaw) and (Marie Curie, won, Nobel Prize) x2. Draw them as a mini graph on paper. You just built your first knowledge graph!
What Do You Think?
What is the biggest challenge when using LLMs to automatically build knowledge graphs?
The hardest part of automated knowledge graph construction. "OpenAI," "Open AI," "the company behind ChatGPT," and "Altman's AI lab" all refer to the same entity. Without entity resolution, your graph has duplicate nodes and fragmented knowledge.
Knowledge graphs stored in graph databases (Neo4j, Amazon Neptune) use query languages like Cypher:
cypher
// Find where Einstein worked and the city
MATCH (p:Person {name: "Einstein"})-[:worked_at]->(org)-[:located_in]->(city)
RETURN p.name, org.name, city.name
// Find all people who worked at the same institution as Einstein
MATCH (einstein:Person {name: "Einstein"})-[:worked_at]->(org)<-[:worked_at]-(colleague)
RETURN colleague.name, org.name
Try it: Explore a knowledge graphInteractive
Click any node to highlight its subgraph. Edges show relationships between entities. Adjust hop depth to see more of the neighborhood. The triples panel below shows the structured facts captured by the graph.
Microsoft Research's Graph RAG (2024) introduces a powerful technique for answering questions that require understanding an entire corpus, not just retrieving specific passages.
Use an LLM to extract entities and relationships from every chunk in the corpus. Build a comprehensive knowledge graph from the entire document collection.
Apply graph community detection algorithms (e.g., Leiden algorithm) to identify clusters of densely connected entities. Each community represents a coherent sub-topic or theme.
Use the LLM to generate a summary for each community -- a concise description of what that cluster of entities and relationships represents. These summaries capture the high-level themes of the corpus.
Communities form a hierarchy: large communities contain sub-communities. This creates a multi-level index from corpus-level themes down to specific entity clusters.
For a query, retrieve relevant community summaries (for broad questions) or specific entity subgraphs (for narrow questions). The community summaries enable answering global queries like "What are the main themes in this document collection?" -- something standard RAG cannot do.
Knowledge graphs represent relationships that vector databases miss. While vectors capture semantic similarity between text passages, graphs explicitly model entities and their connections (e.g., "Einstein worked-at Princeton")
Graph traversal enables multi-hop reasoning. Questions like "What university did the inventor of general relativity work at?" require following chains of relationships that flat text retrieval cannot answer directly
Graph RAG combines structured and unstructured knowledge. By routing queries to both knowledge graphs (for relational questions) and vector stores (for semantic questions), systems handle a broader range of queries
Building knowledge graphs is expensive but high-value. Extracting entities and relationships from unstructured text requires NLP pipelines, but the resulting structured knowledge enables precise, auditable answers
What type of query does a knowledge graph handle better than standard vector-based RAG?
Knowledge graphs add relational intelligence to your RAG system. But how do you know if your RAG system is actually working well? Next up: RAG in Production -- evaluation, monitoring, caching, scaling, and cost optimization.