What this covers
This 41-minute video walks through the architecture and practical workings of GraphRAG, Microsoft's approach to combining knowledge graphs with retrieval-augmented generation. Adam Lucik builds the case by first diagnosing why traditional vector-based RAG falters—semantic similarity retrieval on text chunks misses connections and broader themes—then demonstrates how structuring unstructured data into entities, relationships, and hierarchical communities enables richer, multi-hop reasoning. The presentation moves from conceptual framing into implementation, covering GraphRAG's full indexing pipeline: entity and relationship extraction via LLM, community clustering using the Leiden algorithm, and the generation of community reports that capture meaning at multiple levels of granularity.
The bulk of the runtime is devoted to the three retrieval modes GraphRAG provides. Local search starts with semantic lookups on node embeddings and traverses the graph to gather entities, relationships, and community summaries. Global search retrieves community reports from higher levels to answer thematic questions traditional RAG cannot—a capability grounded in the structured hierarchies the graph creates. DRIFT search (Dynamic Reasoning and Inference with Flexible Traversal) combines both, using hypothetical document embeddings to generate initial answers and follow-up questions, then conducting local searches on each. The video then runs side-by-side comparisons between GraphRAG's three modes and a simple vector database, showing where each excels. Lucik frames knowledge graphs not as a replacement but as complementary to traditional RAG, most valuable when relationships and context across complex unstructured information matter. Trade-offs are acknowledged: GraphRAG demands more computational resources, greater implementation complexity, and domain expertise in schema design, while traditional RAG remains simpler and faster for straightforward tasks.
Adam Lucik argues that knowledge graph RAG (specifically Microsoft's GraphRAG) overcomes the core limitation of traditional vector-based RAG—its inability to capture relationships and broad themes across chunked text—by structuring unstructured data into entities, relationships, and hierarchical communities that enable multi-hop reasoning and both global and local retrieval.
- Traditional RAG bottlenecks at the retrieval step because semantic similarity on chunks misses connections and broader themes
- LLMs now make automated knowledge graph creation feasible where it was previously a manual, resource-intensive process
- GraphRAG's community detection and community reports enable global-theme queries that traditional RAG cannot answer
This asset isn't compiled yet
You're seeing its claims, ranked. Compile it to build the argument threads, weight them, and check each claim against your library — the full view.
Drift search (Dynamic Reasoning and Inference with Flexible Traversal) combines global and local search by using hypothetical document embedding (HyDE) to start at the global level, generating an initial answer plus follow-up questions, then running local searches for each follow-up to create a pseudo-refinement loop—with relevance-scored follow-ups guiding traversal—aggregating all intermediate responses via map-reduce into a final ranked answer.
“drift search which is a novel idea introduced by Microsoft that stands for dynamic reasoning in inference with flexible traversal... it is going to go through hypothetical document embedding or hide... that hypothetical document instead of the query is going to be the one that's actually embedded and used to run the first stage of retrieval... for each of the follow-up questions... we switch over to our local search... This is going to create a pseudo refinement Loop”
Knowledge graphs are not a new concept—they were introduced by Google and power much of the advanced Google search used today—but traditionally their creation was very resource intensive, requiring either manual building and curation or conversion of relational databases into graph structures.
“knowledge graphs are not necessarily A New Concept per se they were actually introduced by Google and power a lot of the advanced Google search that we have today but the issue with knowledge graphs is that traditionally their creation and making a Knowledge Graph has been a very resource intensive process you either had to literally manually build and curate these things or convert some sort of traditional relational database into a graph based structure”
As you scale a knowledge base by adding topics or more text on the same topic, traditional RAG gets bottlenecked at the retrieval step because retrieving just N relevant chunks based on the query misses connections between similarities across the data and broader themes the information conveys.
“as you introduce more complexities into your knowledge base whether that be additional topics or just more text on the same topic we start to get bottlenecked by this retrieval step simply retrieving just the N number of relevant chunks based on the user's query can miss connections between similarities across your data or broader themes”
With the advent of large language models, knowledge graphs can now be created automatically by using LLMs' reasoning capabilities to read unstructured text (Word documents, PDFs, blog posts) to identify entities, infer relationships, and structure information—and LLMs can also update and maintain those graphs.
“now with the Advent of large language models we're actually able to start taking advantage of them for the automated creation of graph-based representations of data so now what we can do is use their Advanced reasoning capabilities across unstructured text... to identify entities infer relationships and actually automatically structure the information in a way that was previously a very intensive manual process”
Global search is something traditional RAG performs very poorly at, because it can only return specificities from unstructured text chunks; GraphRAG's embedded Community Reports allow it to answer queries about broad themes and ideas across the entire knowledge base.
“Global search is going to be something that traditional rag actually performs very poorly at... which allows us in turn to be able to answer queries about broad themes and ideas across our unstructured data as mentioned this is something that traditional rag really cannot do because it only has the ability to return back the specificities from our unstructured text chunks”
GraphRAG uses a lengthy prompt with examples to make the LLM identify all entities (name, type, description) from given entity types, then identify pairs of related source/target entities with a relationship description and an integer strength score from 1 to 10, which is later used when merging the subgraphs.
“it'll go through first and write down all the entity names The Entity types and the entity descriptions... what it's going to do is identify pairs of source and Target entities that are clearly related to each other so it'll say the source entity the target entity and then the relationship description between them and then what we also try and do is have some sort of integer score ranked 1 to 10 indicating the strength of the relationship this will come into play later when we actually merge all of the subgraphs”
GraphRAG's indexing data flow loads and splits text into chunks, extracts entities and relationships with an LLM per chunk, merges and summarizes the per-chunk subgraphs, creates embeddings for the nodes, performs community detection, and then generates Community Reports (summaries of information within communities) which are also embedded.
“it's loading and splitting the text first into chunks it is then going to extract entities and relationships with a language model for each chunk it is then going to merge and summarize the per chunk subgraphs... We will then create embeddings for the nodes... as well as do some form of community detection then finally... we're also going to create Community reports which are going to be summarizations of these the information actually within communities that are going to be embedded as well”
After building the basic graph, GraphRAG applies the Leiden algorithm to group nodes into hierarchical communities at different levels of granularity, and embeds nodes with the node2vec algorithm, so that communities capture obvious connections while embeddings capture subtle patterns.
“we can apply the AFF forementioned leaden algorithm to create and group these nodes into different hierarchical related entities or communities... what we'll be doing is actually also embedding the nodes using the node to VC algorithm so later on we'll be able to use the communities as well as the embeddings to allow us to look at both the subtle patterns through embeddings and the obvious connections through communities”
When merging per-chunk subgraphs, entities with the same name and type are merged by combining their descriptions into an array, relationships with the same source and target are likewise merged into an array, and then these arrays are summarized one final time by an LLM into a single explanation given all context across chunks.
“any entities with the same name and type are going to be merged by creating a simple array of their descriptions and then any relationships with the same source and Target are merged also by creating an array of their descriptions the final step is then summarizing these arrays or lists one more time into a single final explanation given all the context”
Global search retrieves the most similar community reports at a specified hierarchical level, then uses a map-reduce style approach: an LLM extracts key points from each report with relevance scores, ranks and filters out the least relevant points, and returns the most important points as context for generation.
“we can use the embedded Community reports at a specified hierarchical level to return back the nearest or most similar Community reports to that query we then run a series of generation steps... take the report and extract out the key points... attach with it a relevant score... This then goes through a map reduce style approach where what it does is it ranks and filters these intermediary points trying to remove the ones that are least relevant”
Local search first uses semantic search over node embeddings to find relevant entities, treats those as entry points, then traverses to connected text chunks, relevant community reports, related entities and their relationships, combining, filtering and ranking the results to fit the context window for the LLM's response.
“first search for the relevant entities to our query using semantic search... these nodes are going to become the entry points on our graph that we can now Traverse so starting at these points we look at the connected chunks of text... as well as different relevant Community reports... other entities and the relationships between all of them... are all going to be combined filtered and ranked to fit within our context window”
GraphRAG generates Community Reports by aggregating and summarizing the main concepts across communities and levels, capturing increasingly higher-level ideas as communities become broader, and embeds these reports into a vector store for use in broad retrieval.
“what graph rag implements is community report generation and summarization so with the clear Community groupings what we can do is actually aggregate all of the main Concepts across the different levels and across the different communities into summaries this will allow us to increasingly capture the groupings of the ideas and get to higher level and higher level ideas as those communities become more broad”
Traditional RAG benefits from simpler implementation/deployment, suits straightforward retrieval tasks, handles structured text data well, and has lower computational overhead, but loses structural information when chunking, can break related content, has limited ability to capture relationships, and struggles to reason across disparate facts—risking incomplete or fragmented answers.
“the benefits of traditional rag are much simpler implementation and deployment... lower comp computational overhead some of the drawbacks... it loses structural information when chunking the documents it can break up related content... struggles when it has to reason or connect multiple facts that might be disperate or strewn across a document so there are potentials for incomplete or fragmented answers”
Communities create a structured way of understanding different levels of granularity in the knowledge graph, ranging from broad overviews of concepts at the top level to very detailed local clusters at lower levels, aiding organization and navigation during retrieval.
“communities is that they create the structured way of understanding different levels of granularity within our knowledge graph from very broad overviews of Concepts at a top level to very very detailed local clusters at lower levels this will really help us in organizing and also navigating these knowledge graphs”
The three main components of knowledge graphs in GraphRAG are entities (distinct objects/persons/places/events/concepts extracted from text chunks, forming nodes), relationships (connections between entities, also extracted by LLM analysis), and communities (clusters of related entities identified through hierarchical community detection, typically the Leiden algorithm).
“the three main components of knowledge graphs this includes entities relationships and communities an entity in this case is going to be a distinct object person place event or concept that has been extracted from a chunk of text through a language model analysis... relationships then are going to be the different connections between two of our entities... communities so communities are more so going to be clusters of related entities and the relationships identified through some form of hierarchical community detection generally this is going to be using something like the leaden algorithm”
GraphRAG preserves structural relationships and hierarchies in unstructured knowledge, captures connections between related information better, provides more complete and contextual answers with improved retrieval accuracy, supports complex multi-hop reasoning, maintains document coherence, and offers more interpretability—at the cost of greater implementation/maintenance complexity, more processing to build and update the graph, higher computational overhead (notably slower retrieval), need for domain expertise to define schemas, and harder storage and scaling.
“graph rag on the other hand has the benefits of preserving a lot of the structural relationships and hierarchies... better at capturing the connections... much more complete and contextual answers as well as some improved retrieval accuracy... better supports complex reasoning across multiple facts... The drawbacks to graph rag are that it's much more complex to implement and maintain requires a little bit more of processing... higher computational overhead... may require some domain expertise to Define some schemas”
GraphRAG does not replace traditional RAG; it still relies on regular embeddings and retrieval methods, so the two methodologies are complementary and can be used in tandem, with graph-based approaches being most valuable when you need to maintain relationships and nuances between complex unstructured information.
“graph rag really still relies on on regular embeddings and retrieval methods themselves so these methodologies don't necessarily replace each other but they're more a complement to each other and can be used in tandem... graph rag is particularly valuable if you need to maintain relationships or nuances between complex information that you have that's unstructured but traditional rag is a lot easier to set up”
A knowledge graph is a knowledge base that uses a graph structure data model to represent and operate on data, storing interlinked descriptions of entities (objects, events, situations, or concepts) while encoding the free-form semantics or relationships underlying those entities.
“a knowledge graph is a knowledge base that uses a graph structure data model or topology to represent and operate on data knowledge graphs are often used to store Interlink descriptions of entities which are objects events situations or concepts while also encoding the free form semantics or relationships underlying these entities”
Knowledge graph RAG addresses the limitation of semantic similarity retrieval by introducing a structured hierarchical organization that lets the system start at and traverse different paths along the graph to retrieve the right information more effectively.
“knowledge graphs and Knowledge Graph rag approaches address this limitation by introducing a structured hierarchical approach to the actual information organization and the retrieval that we run on our knowledge base we can take advantage of this structured way of knowing how Concepts ideas and different entities... are actually connected by allowing our system to both start at and Traverse these different paths along this graph”
GraphRAG by default splits text into chunks of 1,200 tokens with 100-token overlaps, which for the fine-tuning guide produced about 53 chunks.
“it is first split by default into chunks of 1,200 tokens with 100 token overlaps so I've simulated this very quickly with the token teex Splitter from Lang chain and then when running this we can see that we have about 53 chunks”
In a local search for tools for model initialization, GraphRAG found relevant information beyond the document's explicit tools list (Hugging Face, PyTorch, TensorFlow), surfacing Nvidia Nemo and Optimum by Hugging Face through graph traversal—demonstrating it can pull related entities the explicit text section did not list.
“if you look back in the text at their explicit tools and libraries for model initialization you can see that it only has hugging face and Pie torch and tensor flow here but it also managed to find relevant information from things like Nemo and Optimum which talks about enhancing language model deployment efficiency”
Drift search produced markedly more specific and longer output for the RAG-vs-fine-tuning-vs-PEFT query than either global or local search alone, combining details strewn around the large document with the specifics from local granular searches.
“we can see a major difference we're starting to see a huge increase in the specificity of the output that we have here as well as the length... is able to combine a lot of really good details that are strewn all the way around the large document that we have with the specifics that are available in the local more granular searches”
When the same RAG-vs-fine-tuning-vs-PEFT query was run through a simple ChromaDB vector retrieval setup (chunked identically to GraphRAG), it returned a sparse, less specific list lacking detailed supporting arguments, inferior to GraphRAG's global, local, and drift responses.
“I have set up a very very simple instance of chroma DB and embedded all of the text documents... we get back what is a little bit of a sorry response in comparison to some of the earlier ones... not a lot of very specific information... then it says you know depends on the specific needs of the application without going into a lot of detail or supporting arguments”
Representing unstructured data as a graph is itself a good visualization aid because humans understand interconnected ideas and relationships, allowing one to see larger concepts, offshoots, and the overall structure of the data.
“right off the bat this is already a great way to visualize unstructured data because we as humans of course are going to understand a little bit more of how these ideas and relationships are interconnected... be able to just understand the structure of a lot of this stuff”
Knowledge graphs mirror human cognition by explicitly mapping relationships between objects, concepts and ideas through both semantic and relational connections, paralleling how brains understand information not as isolated facts but as interconnected concepts.
“we're trying to mirror a little bit of human cognition within our data structure by explicitly mapping relationships between objects Concepts and ideas through both their semantic and relational connections this very much so parallels how our brains actually understand and internalize information not so much as isolated facts but more as interconnected Concepts”
Setting up GraphRAG is made easy by Microsoft's no-code/low-code package: you initialize with 'graph rag init' specifying a root folder, insert your OpenAI API key (and embedding model key) into the generated settings.yaml, optionally switch the model to GPT-4o to save cost, and run 'graph rag index' to build the graph in a few minutes.
“Microsoft has made this very easy by just implementing a no code low code graph rag package... open up that yaml file and then insert in your open AI API key... if you're a little bit costc conscious you can change the model here to GPT 40... type in graph rag index and then say our root file”
Traditional retrieval augmented generation works by chunking documents, embedding them into a vector database, and at runtime embedding the user query, running a semantic similarity calculation to retrieve the top N relevant chunks, and passing those plus the original query to the language model as context.
“taking your document you chunk it into workable pieces of text that is all embedded into a vector database using an embedding model and then at runtime what happens is someone inputs a query that query is also embedded a semantic similarity calculation is ran across your vector database to retrieve semantically the top and relevant chunks”