AI Engineer World's Fair 2025
Practical GraphRAG: Making LLMs Smarter with Knowledge Graphs
Read the talk
Practical GraphRAG: From Similar Text to Connected Evidence
GraphRAG combines index search with explicit relationships, preserving document structure and enterprise entities so retrieval can return the context an answer needs.
From a talk by Michael Hunger, Stephen Chin and Jesús Barrasa
Before you start: Familiarity with basic RAG, text embeddings and Python will help; graph concepts are introduced as they appear.
Why similar text is not enough
How can an LLM answer an enterprise question when it does not know the enterprise’s data? A fluent response does not establish that the model knows the relevant products, customers or internal processes—or that it can explain where its answer came from. Missing domain knowledge, unverifiable answers, hallucinations and bias are the opening problems for GraphRAG.
Retrieval-augmented generation supplies external information at answer time. That makes data quality central: the model needs accurate, contextual evidence to work with. But a basic vector search retrieves only a selection of fragments, chosen by similarity. Similarity is not the same as relevance, and a group of passages about the right topic can still omit the facts needed to answer the question.
Stephen Chin also questions the maturity, resilience and scalability of some vector database offerings. Those are his assessments of the systems under discussion, rather than inherent limitations of vector indexing. The more general retrieval problem is that similar fragments alone can be incomplete and difficult to explain.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Who owns the car, and who drives it?
GraphRAG adds explicit knowledge and context to the language model’s ability to generate responses. Chin introduces this through a creative-versus-logical brain analogy; the concrete implementation is a knowledge graph made of nodes, relationships and properties. Nodes represent things, relationships connect them, and properties record their attributes.
Consider two people who live together and share a car. The person who owns the car is not necessarily the person who drives it. A graph preserves that distinction through separate OWNS and DRIVES relationships, alongside connections such as LIVES WITH. Retrieving information about the people and the car is useful, but answering a question about ownership requires preserving which person has which relationship.
The Stack Overflow graph expands this idea from a tiny household example to connected content with rich metadata. Retrieval can start with a relevant item and follow graph relationships to gather related information. The result carries explicit structure and semantics that can be inspected, visualized, analyzed and logged. Security and role-based access can also be applied to the retrieval process. These capabilities support grounding and explanation; they do not automatically make every generated answer correct.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What the cited results actually measure
Microsoft Research’s From Local to Global provides an early example of using graph community summaries for questions about an entire collection. Its evaluation found improvements in comprehensiveness and diversity on global sensemaking questions over podcast and news corpora. Its token savings compare community-summary context with map-reduce summarization over source text, not the total cost of every GraphRAG system against vector RAG. Building the graph remains an upfront investment.
The data.world benchmark supplies a more specific interpretation of the talk’s roughly threefold accuracy claim. In an insurance-domain enterprise benchmark, GPT-4 zero-shot question-answering accuracy rose from 16% over SQL to 54% over a knowledge-graph representation. That graph represented the enterprise SQL database using an ontology and mappings, so the result concerns a particular representation and question-answering task, not a general database performance contest.
Chin then turns to Gartner’s 2024 hype-cycle discussion and enterprise adoption as signs of growing interest. These provide market context, rather than controlled evidence of effectiveness. His account of analyst claims about resolving hallucinations is best understood as advocacy for grounding responses in facts, not a guarantee that adding a graph eliminates hallucinations.
The LinkedIn customer-service study measures a practical support outcome. In LinkedIn’s production comparison against traditional manual methods, median per-issue resolution time fell from seven to five hours, a 28.6% reduction. The customer-service team was randomly split between the two approaches across multiple product lines. This production result is distinct from the paper’s offline retrieval comparisons; the talk closes its evidence section by returning to data.world’s accuracy result.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Build the graph before querying it
Michael Hunger separates GraphRAG into two activities: constructing the knowledge graph and retrieving from it. Construction proceeds through three layers:
- Document structure: Turn unstructured information into a lexical graph containing documents, chunks and their relationships.
- Domain knowledge: Use a graph schema to guide extraction of entities and relationships from the text.
- Enrichment: Apply graph algorithms and summarization, including PageRank and community summaries.
The resulting graph becomes the basis for local, global and other search approaches. Those search modes are introduced here as options, rather than fully specified algorithms.
This is data engineering work: richer retrieval requires more effort at ingestion. The payoff is reusable structure that can supply context for many later queries. The GraphRAG pattern catalog collects approaches observed in applications and research, with names, descriptions, usage context, example graphs and queries. A pattern can combine a lexical graph with a domain graph, letting a query move between source passages and the entities those passages describe.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep the structure around each chunk
A lexical graph represents documents and their constituent elements. A book can contain chapters, chapters can contain sections, and sections can contain paragraphs. A semantically cohesive paragraph may be a good embedding unit, while its graph relationships preserve the surrounding structure that an embedding alone does not express.
| Relationship | Context it preserves |
|---|---|
| Parent–child | The section or document containing a passage |
| Predecessor–successor | The material immediately before or after it |
| Weighted similarity | Other chunks close in vector or text similarity |
Parent and sequence links make document context directly retrievable. A k-nearest-neighbor graph adds similarity relationships between chunks, with a weight recording their similarity. Retrieval can then expand by document membership, sequence or similarity instead of treating every chunk as an isolated result.
The RFP example follows the same procedure: divide the request for proposal into meaningful subsections, connect those elements, attach their text and compute embeddings. Repeating that process across the collection produces a lexical graph. The important decision is not merely where to split text, but which relationships to preserve so a later query can recover its context.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Connect source text to entities and recurring topics
The next layer extracts entities and relationships. LLMs extend established NLP extraction techniques with flexible instructions and multilingual understanding. The input combines source text, an instruction prompt and a graph schema. Hunger mentions extraction inputs of ten thousand or a hundred thousand tokens as possibilities with large context windows, not as measured operating recommendations.
Existing structured data can make this task more precise. If products, genes, partners or clients already have established records, supply those records as ground truth. The model can recognize known entities in the text instead of creating every entity from scratch, then extract relationships and attach additional facts to entities or relationships.
This also provides a route into an existing enterprise graph. A CRM may already contain customers and leads; call transcripts can add information connected to those established records. The lexical graph retains the source structure, while the domain graph connects the extracted information to the business entities it concerns.
Enrichment then looks beyond individual documents. Graph clustering groups related entities into communities, and an LLM can summarize each community. Where a document gives one ordered presentation of information, a community can expose a topic recurring across many documents. This is the basis for gathering context about a collection-wide theme instead of locating only one relevant passage.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Find entry points, then follow relationships
A graph retriever begins with an index search. Vector, full-text, hybrid, spatial or another search method identifies entry points in the graph. It then follows relationships from those starting points, stopping at a chosen depth or relevance threshold. Vector search remains useful; it becomes the beginning of retrieval rather than its entire scope.
For a small RFP illustration, suppose index search selects a passage describing support hours. A one-hop expansion can also include its parent section and the next passage containing an exception. This Python example shows that expansion after index search has supplied the entry-point ID:
python
nodes = {
"support": {"kind": "section", "text": "Support requirements"},
"hours": {"kind": "chunk", "text": "Provide support every weekday."},
"exception": {"kind": "chunk", "text": "Critical incidents need weekend coverage."},
}
edges = [
("hours", "PART_OF", "support"),
("exception", "PART_OF", "support"),
("hours", "NEXT", "exception"),
]
def retrieve_context(entry_ids, max_hops=1):
selected = set(entry_ids)
frontier = set(entry_ids)
for _ in range(max_hops):
neighbors = set()
for source, relation, target in edges:
if source in frontier:
neighbors.add(target)
if target in frontier:
neighbors.add(source)
frontier = neighbors - selected
selected.update(frontier)
return {
"nodes": [{"id": key, **nodes[key]} for key in sorted(selected)],
"relationships": [
{"source": source, "type": relation, "target": target}
for source, relation, target in edges
if source in selected and target in selected
],
}
context = retrieve_context(["hours"], max_hops=1)
The selected evidence now includes the weekday requirement, the weekend exception and their structural connections. The example uses a fixed hop limit; a real retrieval policy can also restrict which relationships are relevant to the question.
The question is only one input to that policy. External user context also influences which information to retrieve and how much to include. Someone in finance may need different context from someone in engineering, even when looking at the same underlying data. Context selection should therefore reflect the user’s task as well as the initial search match.
The LLM receives text together with a contextual subgraph: explicit node–relationship–node structures rather than only disconnected fragments. Hunger notes that modern LLMs can process these additional structures, although no comparative benchmark is shown for that claim. Clustering, link prediction and PageRank can supply further enrichment signals for the graph used in retrieval.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Inspecting the evidence behind a DeepMind answer
The Neo4j LLM Knowledge Graph Builder makes the construction workflow concrete. It accepts PDFs, YouTube transcripts, local documents, web articles and Wikipedia articles. In the demonstration, several sources have already been uploaded, including material about Google DeepMind. The tool supports different LLMs and an optional graph schema. A pattern such as person–works for–company tells the extraction model which kinds of relationships to look for.
The DeepMind Wikipedia extraction exposes both layers of the graph. One part contains the document and its chunks; the other contains connected entities, including companies, locations, people and technologies. The schema guides which entity types are extracted. For querying, the interface offers vector, graph, full-text and entity retrieval options. The builder is an open-source project.
Hunger opens a previously run answer to the question, “What has DeepMind worked on?” The query was run before the presentation because venue internet was unreliable. The useful part of the walkthrough is the evidence inspection:
- Sources: Inspect the source material used, including AlphaFold, Google DeepMind, Wikipedia and another PDF.
- Chunks: Examine the text passages retrieved through the search process.
- Entities: Inspect the graph entities supplied to the LLM alongside their connected text.
This makes the retrieved context visible. It explains what evidence the generator received, rather than proving that every sentence in the answer is correct.
The builder also offers evaluation with Ragas. The demonstration mentions this capability without presenting evaluation scores.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Turn domain queries into agent tools
An agentic approach packages individual retrievers as domain-specific tools. Each tool has a query, inputs and a description. An agent can call a tool, inspect its response and make a deeper call when the first result reveals a need for more information. Each call performs a bounded retrieval operation over the relevant domain.
The tooling is presented as available through open-source libraries, including Python. Hunger also shows NeoConverse, which can return charts and network visualizations as well as text. The output format can therefore reflect the structure of the retrieved information rather than always becoming a prose answer.
The orchestration procedure is to break the user’s question into individual tasks, extract the parameters each task needs, and run the corresponding tools in sequence or in a loop. Responses can guide subsequent calls. This extends retrieval from one search into a series of targeted queries, while keeping each query’s purpose and inputs explicit.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Construction and retrieval in Python
The final implementation example brings construction and retrieval together through Neo4j GraphRAG for Python. The package supports building knowledge graphs, implementing retrievers and assembling pipelines. Hunger supplies PDFs and a graph schema, imports the resulting graph into Neo4j, and shows that the data can then be visualized in a Python notebook. The repository’s current examples are an implementation entry point; their API signatures should not be assumed to match the notebook shown in the recording.
The closing destination is the GraphRAG pattern catalog: graph models, retrieval patterns, papers and resources, with an invitation to contribute additional patterns. Chin credits Hunger’s team with building tools including Knowledge Graph Builder. Further questions move to the conference booth, leaving the recording’s practical endpoint at a working construction-and-retrieval workflow and the tools for extending it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Concepts, construction guides and patterns for graph models and graph-based retrieval.
Microsoft's original study of community summaries for answering questions across large text collections.
An insurance-domain benchmark comparing GPT-4 question answering over SQL and a knowledge-graph representation with business semantics.
LinkedIn's study of ticket structure, graph retrieval and customer-support outcomes. This is the May 6, 2024 revision.
Source code and setup instructions for Neo4j's tool for constructing knowledge graphs from unstructured material.
Guide to interacting with Neo4j databases through natural-language questions and generated Cypher queries.
Official Python package and examples for building GraphRAG applications with Neo4j.
Updates since the talk
Current catalog of metrics for retrieval quality, generated responses and agent workflows.
Read the complete timestamped transcript
- 0:00
[upbeat music] We are talking about GraphRAG today.
- 0:16
That's the GraphRAG track, of course. Uh, and we want to look at patterns for successful GraphRAG applications, uh, for, um, making LLMs a little bit smarter by putting knowledge graphs into picture.
- 0:27
My name is Michael Hunger. I'm VP at-- of Product Innovation at Neo4j.
- 0:32
My name is Stephen Chin. I lead the Developer Relations at Neo4j, and, um, actually, we're, we're both co-authoring. This is fun-
- 0:40
Yeah
- 0:40
... 'cause we're both already authors, and finally, we've been friends for years, and we-
- 0:43
Yeah
- 0:43
... finally get to co-author a book. We're co-authoring GraphRAG: The Definitive Guide for O'Reilly. So-
- 0:49
Yeah
- 0:50
... basically, we didn't sleep this past weekend- [laughs] ... 'cause we have a book deadline.
- 0:53
Mm-hmm. Yep.
- 0:55
So, um, I'm gonna talk a little bit about kind of at a high level what GraphRAG is, why it's important, what we're seeing in the media, and then Michael's gonna drill down into all of the details and patterns, and give you a bunch of takeaways and things you can do.
- 1:09
This is probably if, if you wanna know how to do GraphRAG, Michael's quick- [laughs] ... dive, deep dive on this is the best introduction you can get, so I'm also excited.
- 1:19
Awesome. Let's get going.
- 1:20
Okay. So the case for GraphRAG is where we're gonna start, and the challenge with using LLMs and using other patterns for this is basically they, they don't have the enterprise domain knowledge.
- 1:33
They don't verify or explain the answers, they're subject to hallucinations, um, and they've ethical and data bias concerns. And you can see that very much like our, our friendly parrot here, um, they are all the things which parrots behave and act like, except a cute bird.
- 1:51
So we wanna do better than this with GraphRAG and figure out how we can use domain-specific knowledge, accurate, contextual, and explainable answers. And really, I think, like, what a lot of companies and what the industry is figuring out is it's really a data problem.
- 2:06
You, you need good data, you need to have data you can power your system with. Um, one of the patterns you can do this with is RAG. So you can stick your external data into a, into a RAG system.
- 2:16
You can get stuff back from a, um, a database for the pattern. But vector databases in RAG fall short because it's, it's lacking kind of your full data set.
- 2:28
It's l- it's only pulling back a fraction of the information by vector similarity algorithms. Typically, a lot of the, especially modern vector databases which everyone's using, they're, they're easy to get started with, but they're not robust, they're not mature.
- 2:40
They're not something which has scalability and fallback, and gives you that, what you need to get into build a strong, robust, um, enterprise system. And vector similarity is not the same as relevance.
- 2:52
So results you get back from using a basic RAG system, they're-- they give you back things which are related to the topic, but it's not complete, and it's typically also not very relevant.
- 3:04
And then it's very hard to explain what's coming out of the system. So we need an answer. Lifeline.
- 3:11
Yeah. GraphRAG.
- 3:12
GraphRAG. [laughs] And what GraphRAG is, is we're bringing the re- we're bringing the knowledge c- and the context and the environments to what LLMs are good at. So you can think of this kinda like the human brain.
- 3:23
Our, our, um, left brain is, um, our right brain is more creative, it does more like a, uh, like building things, it does more, um, extrapolation of information. Whereas our left brain is the logical part.
- 3:35
That's what actually has reasoning, has facts, and can enrich data, and it's built off of knowledge graphs. So a knowledge graph is a collection of nodes, relationships, and properties.
- 3:47
Here's a really simple example of a knowledge graph where you have two people, they, they live together, you have a car. But when you look into the details, it's actually like a little bit more complex than it seems at first because s- they, they both have a car, but the owner of the car is not the person
- 4:03
who drives it.
- 4:03
Yeah.
- 4:04
This, this is kinda like my family. [laughs] [laughs] My, my wife does all the bills, but then she hands me the keys whenever we get on the freeway. She, she hates driving.
- 4:12
So knowledge graphs also are a great way of getting really rich data. Um, here's an example of the Stack Overflow graph built into a knowledge graph, where you can see all of the rich metadata and the complexity of the results.
- 4:24
And we can use this to evolve RAG into a more complex system, basically GraphRAG, where we get better relevancy. We're getting b- more relevant results. We get more context because now we can actually pull back all of the related information by graph closeness algorithms.
- 4:39
We can explain what's going on because it's no longer just, um, vectors, it's no longer statistical probabilities coming out of a vector database. We actually have nodes, we have structure, we have semantics we can look at, and we can add in security and role-based access on top of this.
- 4:54
So it's context rich, it's grounded. This gives us a lot of power, and it gives us the ability to start explaining what we're doing, where now we can, we can visualize it, we can analyze it, and we can log all of this.
- 5:06
Now, um, this is one of the, the initial papers, the, the GraphRAG paper from Microsoft Research, where they went through this and they did, they showed that you could actually get not only better results, but less token cost.
- 5:17
It was actually less expensive to do a GraphRAG algorithm. Um, there have been a lot of papers since then which show all of the different research and interesting work which is going on in the GraphRAG area.
- 5:30
And, um, this is just a quick view of the different studies and results which are coming out. But even from the early Data.World study, where they showed a three times improvement in GraphRAG capabilities, and the analysts are even showing how GraphRAG is trending up.
- 5:46
So this is the, um, Gartner, um, kinda hype cycle from, from twenty twenty-four, and you can see generic AI is kind of, you know, on the downtrends. RAG is getting over the hump, but GraphRAG and a bunch of these things actually are providing and breathing more life into the AI ecosystem.
- 6:03
So a lot of great reports from, from Gartner showing that it's grounded in facts, it resolves hallucinations. Together, knowledge graphs and AI are solving these problems, and it's getting a lot of adoption by different industry leaders, by big organizations, um, who are taking advantage of this and actually producing production applications and making it work.
- 6:22
Like LinkedIn customer support, where they actually wrote this great research paper where they showed that using a knowledge graph for customer support scenarios actually gave them better results and allowed them to improve the, um, quality and reduce the response time for getting back to customers.
- 6:40
Um, median per issue resolution time was reduced by twenty-eight point six percent. I mentioned the Data.World study, which basically was a comparison of doing, um, RAG on SQL versus RAG on graph databases, and they showed a three times improvement in accuracy of LLM responses.
- 6:56
And let's chat about patterns, Michael, 'cause I think everyone's here to learn how to do this.
- 7:01
Exactly. So let's, let's look at how to do this actually, right? So, and, um, if you look at GraphRAG, uh, there are actually two sides to the coin. So one, of course, you don't start in a vacuum.
- 7:12
You have to create your knowledge graph, right? So-- And we see basically multiple steps to get there. Initially, you get unstructured information, you substructure it, you put it into a lexical graph, which represents documents, chunks, and their relationships.
- 7:25
In a second step, you can then extract entities using, for instance, LLMs with this graph schema to extract entities and their relationships from that graph. And in a third phase, you would enrich this graph, for instance, with graph algorithms doing things like, you know, page rank, uh, community summarization, and, and so on.
- 7:42
And then when you have this, uh, built up knowledge graph, then you do GraphRAG as the, as the search mechanism, um, either with local search or global search and, and, um, other ways, right?
- 7:54
So let's first look at the first phase of, like, knowledge graph construction a little bit. Um, so like always in data engineering, there's-- if you want to have higher quality outputs, you have to put in more effort at the beginning, right?
- 8:06
So it's basically nothing comes for free. There's no free lunch after all. But what you do at the beginning is basically paying off multiple times because what you get out of your unstructured documents is actually highly-- high quality, high structured information, which you then can use to extract contextual information for your, for your queries, which allows rich
- 8:24
retrieval at the end. Okay. And so a-after seeing, uh, GraphRAG being used, uh, by a number of users, customers, we've seen, uh, we looked at research papers. We, we saw that a number of patterns emerging, uh, in terms of like how we structure our graphs, how we query these graphs, and so on.
- 8:43
And so we started to collect these patterns and put them on graphrag.com. Um, and we want to-- I wanted to show what, what this looks like. So we have basically, uh, example graphs, uh, in the pattern.
- 8:55
The pattern has a name, description, uh, context, and we see also queries that are used for extracting this information, right? So for instance, here's an, uh, mix of a lexical graph and a domain graph, and then we can have the query that fetches, uh, this, uh, information.
- 9:09
Let's look at the three steps in a little bit more detail on the, um, on the graph model side. So on one side, we have, uh, for lexical graphs, you represent documents and their elements.
- 9:19
So that could be something as simple as a chunk. But if you have structured element, uh, documents, you can also do something like, okay, I have a book which has chapters, which have, uh, sections, which have paragraphs, where the paragraph is a semantically cohesive unit that you would use to, for instance, create a vector embedding of-- that
- 9:35
you can use, uh, later for vector search. But what's really inter-interesting in the graph is basically you can connect these things all up, right? So you know exa-exactly who's the predecessor, who's the successor to a chunk, who's the parent of an element.
- 9:47
And using something like, uh, vector or text similarity, you can also connect these, uh, chunks as well by, uh, an k-nearest neighbor or similarity graph, where you basically store similarities, uh, between chunks, and then you put on the relationship between them and, and, and weighted score, basically how similarity two chunks.
- 10:04
And then you can use all these relationships when you extract the context in the retrieval phase to, for instance, find what are related chunks by document, by, uh, temporal sequence, by similarity and other things, right?
- 10:16
So that's on the, on the lexical side. Um, this looks like this. So for instance, you have an, uh, RFP and you want to break it up in a structured way.
- 10:24
Then you basically create the relationships between, uh, these chunks, uh, or the, the, these, uh, subsections, uh, add the text, do the vector embeddings, and then you do it at scale, and then you get a full, uh, lexical, uh, gra-graph out of that.
- 10:38
Next phase is entity extraction, uh, which is also something that has been around for quite some time with NLP. But LLMs actually take this to the next level with their multi-language understanding, with their high flexibility, good language skills for extraction.
- 10:52
So you basically provide an, uh, graph schema and an, um, instruction prompt to the LLM, plus your pieces of information, pieces of text. Now with large context windows, you can then p-put in ten thousand, a hundred thousand tokens for extraction.
- 11:09
If you have, you can also put in already existing ground truth. So for instance, if you have exis-existing structured data where your entities, let's say products or genes or partners or clients are already existing, then you can also pass this in as part of the prompt so that the LLM doesn't do an extraction, but more an recognition
- 11:28
and, and finding, um, approach. There you find your entities, and then you extract relationships, uh, from them, and then you can store additional facts and, and, uh, additional information into store, uh, as part of relationships and entities as well.
- 11:41
So basically, in the first part, you have the lexical graph, which is representing document structure. But in the second part, you extract the relevant entities and their relationships. If you have already an existing knowledge graph, you can also connect this to an existing knowledge graph.
- 11:53
So imagine you have an, um, CRM where you already have customer clients, uh, and, and leads in your knowledge graph, but then you want to enrich this with, for instance, uh, protocol from call transcripts, and then you basically connect this to your existing structured data as well.
- 12:08
So that's also a possibility. And then in the next phase, what you can do is you can run graph algorithms for enrichment, which then, for instance, can do clustering on the entity graph, and then you generate, uh, something like, uh, communities where, uh, an LLM can generate summaries, uh, across them as such.
- 12:26
Right. And, uh, for especially last one, it's interesting because what you identify is actually cross-document, uh, topics, right? So because it's basically each sh- document is in basically temporal, uh, v- vertical representation of information.
- 12:40
But what this is, is actually it looks at which topics are reoccurring across many d- different documents. So you find these kind of topic clusters a- across, uh, documents as well.
- 12:50
Cool. So if you look at the, the second phase, the search phase, which is basically the retrieval, uh, um, part of RAG, what we see here is basically that in a graph retriever, you don't just do a simple vector lookup, uh, to get, uh, returns, uh, results return.
- 13:06
But what you do, you do an i- initial index search. It could be vector search, full text search, hy- hybrid search, spatial search, rather kinds of searches to find the entry points in your graph.
- 13:15
And then you basically, uh, can take, as you can see here, um, starting from these entry points, you then follow the relationships up to a certain degree or up to a certain relevancy to f- f- fetch in, uh, additional context.
- 13:28
And this context b- can be coming from the user question, it can be external user context that comes in. For instance, when someone from, let's say, your, uh, finance department is looking at your data, you return different information than if someone from the, let's say, engineering department is, is looking at your data, right?
- 13:44
So it also takes this external context into account, how much and which context you retrieve. And then you return to the LLM to generate the answer, not just basically text fragments like you would do in vector search, but you also create, uh, return these, um, more complete, uh, subset of the, of the contextual graph, uh, to the
- 14:04
LLM as well. And modern LLMs are actually more trained on, uh, graph processing as well, so they can actually deal with these, uh, additional pattern structures where you have, uh, node relationship, node patterns, uh, that you provide as additional context, uh, to the LLM.
- 14:20
Um, and then of course, I mentioned that you can enrich it using graph algorithms. So basically, you can s- do things like, uh, clustering, link prediction, PageRank, and other things to enrich your data.
- 14:30
Cool. Let's look at some, uh, practical examples. We don't have too much time left. Uh, so one is, uh, knowledge graph construction from unstructured sources. So there's a number of libraries.
- 14:39
Uh, you've already heard some, uh, today from people that, uh, do these kind of things. Um, so one thing that we built is an, a tool that allows you to take PDFs, uh, YouTube, uh, transcripts, uh, local documents, web articles, Wikipedia articles, and it extracts your, uh, data into a, an, a graph.
- 14:59
And let me just switch over to the, to the, uh, demo here. Uh, so this is the, this is the tool. Uh, so I, uh, uploaded, uh, information from different Wikipedia pages, YouTube videos, articles, and so on.
- 15:13
And here's, for instance, an Google DeepMind, uh, extraction. So you can use a lot of different LLMs here, and then you can also, if you want to, in graph enhancement, provide a graph schema as well.
- 15:24
So you can, for instance, say a person, uh, works for, uh, a company and, uh, add these patterns, uh, to your, um, to your schema, and then the LLM is using this information to drive the extraction, uh, as well.
- 15:38
And so if you look at the data that has been extracted from, uh, DeepMind, it is this one here. We can actually see
- 15:48
from the Wikipedia article, um, two aspects. One is the document with the chunks, which is this, uh, part of the, of the graph, right? And then the second part is the entities that have been extracted from, from this, uh, article as well.
- 16:01
So you see actually the, uh, connected knowledge graph of entities, which are companies, locations, people, and technologies. So it followed our, um, followed our schema to extract this. And then if I want to run GraphRAG, you have here a number of different retrievers.
- 16:15
So we have vector retriever, graph and full text, entity retrievers, and others, uh, that you can select. Uh, all of this is also an open source project, so you can just go to GitHub and have a look at this.
- 16:25
And so I just ran this before because internet is not so reliable here. So what has DeepMind worked on? And I get a detailed explanation. And then if I want to, I can here look at, uh, details.
- 16:36
So it shows me which sources did it use. AlphaFold, Google DeepMind, Wikipedia, another PDF. I see which chunks have been used, which is basically the full text and hybrid search.
- 16:45
But then I also see which entities have been used from the graph. So I can actually really see from an explainability perspective, these are the entities that have been retrieved by the GraphRAG retriever passed to the LLM in addition, uh, to the text that's connected to these entities, so it gets a richer response, uh, as such.
- 17:01
And then you can also do eval on that with the Ferragas as well.
- 17:06
Um, so while I'm on the screen, uh, let me just show you another thing, uh, that we worked on, which is more like an agentic approach, where you basically put these individual retrievers into, uh, an, an configuration where you have basically domain-specific retrievers, uh, that, uh, are, um, running individual separate queries.
- 17:26
So for instance, if you look at, uh, let's say this one, it has, uh, the query here and basically a tool with inputs and a description. And then you can have an agentic, um, loop using these tools, basically doing, uh, graphic with each individual tool, taking the responses, and then doing, uh, deeper, uh, tool calls.
- 17:46
Uh, I'll show you a deeper example in a, in a minute. So this is basically what I showed you. This is all available as, uh, open source, uh, libraries.
- 17:54
You can use it yourself in, from Python as well. Uh, I showed, um, Neo Converse, which was also able not to just output text, but also, uh, charts and other visualizations, uh, networks, uh, visualizations as well.
- 18:07
And what's interesting here in the agentic approach, you don't j- just use vector search to retrieve your data, but you basically break down the user question into individual tasks and extract parameters and run these individual tools, um, which then are either run in sequence or in a loop to, uh, return the data, and then you get basically
- 18:25
these, uh, outputs back. And, uh, basically for each of these things, div- individual tools are called and, and used here. And the last thing that I want to show is the, uh, GraphRAG Python package, uh, which is basically also encapsulating, uh, all of this in construction and the retrieval in, into one package.
- 18:43
So you can build your knowledge graph, you can implement the retrievers and create the pipelines here. And here's an example of where I pass in, uh, PDFs plus a graph schema, and then basically, uh, it runs, uh, the import into Neo4j, and then I can, uh, in the Python notebook visualize, uh, the data later on.
- 19:03
And with that, I leave you with, one second,
- 19:07
uh, the takeaway, which is on GraphRAG.com you find all of these resources, a lot of the patterns, and, uh, we'd love to have contributions and love to talk more.
- 19:17
I'm outside at the, at the booth if you have more questions.
- 19:21
Yeah.
- 19:21
Thank you so much.
- 19:22
No, that was great, and I think you're getting it all from the expert with all the tooling. Actually, Michael's team builds a lot of the tools like Knowledge Graph Builder.
- 19:29
Um, very excited you all came to the GraphRAG track and hope to chat with you all more. If you have questions for me and Michael, just meet us in the Neo4j booth across the way.
- 19:38
Thank you.
- 19:38
Thank you. [audience applauding] [upbeat music]