GraphRAG adds structured knowledge, relationships, and access controls to retrieval so LLM answers have more context and can be explained.
2
Building a useful graph starts with document structure, then entity and relationship extraction, followed by graph-based enrichment such as clustering and PageRank.
3
Graph retrieval combines an initial search with relationship traversal, while agentic systems can break questions into tasks and call domain-specific Cypher tools.
Summary
Michael Hunger and Stephen Chin explain why vector-only RAG often returns related fragments without enough context, complete coverage, or an explanation of the answer. GraphRAG adds a knowledge graph containing nodes, relationships, properties, document structure, entities, and domain facts. The talk describes a construction pipeline: turn unstructured sources into a lexical graph, extract entities and relationships with an LLM, connect the results to existing structured data, and enrich the graph with algorithms such as clustering and PageRank. Retrieval starts with vector, full-text, hybrid, or other index searches, then follows graph relationships to collect a larger contextual subgraph. The speakers also show open source tools for importing PDFs, videos, and web pages, inspecting retrieved entities and sources, and building agentic retrievers with Cypher queries. The practical message is that graph quality depends on effort during data preparation, while the resulting structure supports richer retrieval, access control, visualisation, and explanation.
Vector similarity does not provide complete or explainable retrieval
Stephen Chin argues that basic vector RAG pulls back only a fraction of the available information. Results can be related to a topic without being fully relevant, and the system has difficulty explaining why those results produced an answer. GraphRAG adds nodes, relationships, and semantics that can be inspected, visualised, analysed, and logged. It can also include security and role-based access. Chin frames the underlying problem as a data problem: an LLM needs accurate, contextual domain knowledge to answer questions about an enterprise.
A knowledge graph gives LLMs structured context around facts
The speakers describe a knowledge graph as a collection of nodes, relationships, and properties. Their simple example contains people, cars, shared living arrangements, ownership, and driving relationships. The point is that relationships can capture distinctions that are easy to miss in isolated text. A Stack Overflow graph shows how the same approach can retain rich metadata and connected results. GraphRAG combines this structure with the language abilities of an LLM, allowing retrieval to return related information and a contextual explanation rather than only a set of statistically similar text fragments.
Knowledge graph construction has three preparation phases
Michael Hunger outlines a construction process before search begins. First, unstructured information becomes a lexical graph containing documents, chunks, and their relationships. Next, an LLM extracts entities and relationships using a supplied graph schema and instructions. Existing ground-truth data, such as products, genes, partners, clients, or CRM records, can guide recognition and connect new information to an existing graph. Finally, graph algorithms enrich the entity graph. Clustering can identify communities, and an LLM can summarise recurring topics across documents.
Document structure makes lexical retrieval more useful
A lexical graph can model a book, its chapters, sections, and paragraphs, with the paragraph used as a semantically cohesive unit for embeddings. The graph can connect each chunk to its predecessor, successor, and parent. It can also store a similarity graph in which chunks are connected to their nearest neighbours with a weighted similarity score. During retrieval, these relationships allow the system to find context by document structure, sequence, or similarity instead of treating every chunk as an isolated result.
Graph retrieval starts with search and then follows relationships
A graph retriever can begin with vector search, full-text search, hybrid search, spatial search, or another index to find entry points. It then follows relationships to a chosen degree or relevance threshold to collect more context. The retrieved context can depend on the question and on external user information. Hunger gives the example of finance and engineering users receiving different information from the same data. The result passed to the LLM can include a contextual graph with node-relationship-node patterns alongside text fragments.
Graph algorithms enrich the data before questions are asked
Hunger lists clustering, link prediction, and PageRank as ways to add information to the graph. Clustering can group related entities and support summaries across communities. These groups can reveal topics that recur across multiple documents, rather than topics visible within only one document. Enrichment gives retrieval more material to work with and can support answers that depend on connections spanning documents.
Open source tools expose sources, entities, and retrievers
The demonstration tool imports PDFs, YouTube transcripts, local documents, web articles, and Wikipedia pages. Users can provide a graph schema, such as a person working for a company, to guide extraction. In the DeepMind example, the resulting graph contains document chunks plus entities such as companies, locations, people, and technologies. The interface shows the sources and chunks used, as well as the graph entities retrieved and passed to the LLM. Available retrievers include vector, graph, full-text, and entity retrievers.
Agentic GraphRAG can call domain-specific Cypher tools
The agentic approach places individual retrievers into a configuration of domain-specific tools. Each tool has inputs, a description, and a Cypher query. An agent can break a user question into tasks, extract parameters, and call tools in sequence or in a loop. The outputs are then used for deeper calls or for the final answer. Hunger also mentions a GraphRAG Python package that combines graph construction, retrievers, and pipelines, with support for loading PDFs and visualising the resulting data in a notebook.
"You can build the knowledge graph, you can implement the retrievers and create the pipelines here."18:40
Who should watch
You are building a RAG application and need retrieval to include connected facts, document structure, or user-specific access rules.
Your team has enterprise data in documents and existing systems such as a CRM, and you need a path from that data to a queryable knowledge graph.
You want to inspect which sources, chunks, and entities produced an answer, or experiment with agentic retrieval through domain-specific Cypher tools.
