NODES AI 2026 - EventKernel: Multi-Hop Reasoning and GraphRAG for AI-Powered Event Intelligence

This talk introduces the concept of building a graph rack system, also known as a knowledge augmented generator system. The speaker explains how this system differs from traditional vector rack systems by utilizing knowledge graphs for complex event management use cases. He uses a detective story as a metaphor to demonstrate how nodes and relationships in a knowledge graph can help uncover insights through traversal strategies such as depth-first and breadth-first searches. The session delves into the creation of a lexical graph derived from unstructured documents, emphasizing the importance of connecting this with a domain graph to enrich knowledge retrieval. Additionally, he outlines the benefits of applying a graph rack methodology in comparison to a conventional vector rack approach, highlighting the advantages of enhanced context and multi-hop reasoning. Finally, he proposes the integration of an agentic AI approach to further refine the system’s capabilities.

[music] >> Hello everyone. Welcome to my session. Today, I'm going to show you how to build a graph rack system or essentially you could call it as a cat system or knowledge augmented generator system. And at this point, I'm really not worried about all these new terminologies because now and then there are new terminologies coming up. And I would suggest you to stick with the same uh

because essentially you could all uh group them to graph rack. And we're going to see how it is different from a traditional vector rack system. And towards the end of the session, we will also see how we can repurpose the same architecture that we are going to see in a bit with the help of agentic AI approach to cover uh different use cases. So, if knowledge graph

is something new to you, um I highly doubt that because we are at the Neo4j conference, but even then I'm just going to continue with the story because I prepared for it. Um so, let me start with a story uh which we all are familiar with, a detective story. Uh take any detective movie, right? So, there will be always this one scene where a detective will be

um stuck on a case and right away he will be entering into a room and there will be a giant board um with a bunch of photos just like this. At the first glance, a detective might feel something is off once he saw this um giant board. Um and he can sense that is um that there is something missing from this giant board. And the missing part

is the strings. Earlier, we had jumbled photos onto the giant board with no story, no meaning, and no connection to it. But once we added the string back to the giant board, now you could see the detective is happy because he could make sense of uh why these connections are there, like what how one is related to one another. And essentially, he can um get on to

solve the case, right? And this is what knowledge graph is about. Every photo is a node and every string is a relationship. But the problem is there are different paths a detective can take in order to solve a case or in order to traverse this giant board. And essentially, that is the same with the knowledge graph as well. There are different graph traversal strategies that you could

take uh to traverse the graph. So, let's see what are those. Say suppose a detective wants to understand um every detail about one particular suspect. What he will do then is he will go into this giant board and uh from that particular suspect, he will be going deeper and deeper until he covers the entire history of that particular suspect. And this strategy is what we call as

depth-first traversal. This is a powerful strategy because it helps you to uncover hidden informations But this is not always the right strategy to solve a case or traverse a graph, right? Uh a detective could choose a different strategy where uh he would take a step back and he would uh see what who are the people who are involved in that case and he wants to know about

high-level details about all those suspects, right? Uh in that scenario, what he will do is like he will go level by level and until he goes to the depth of the graph. And this is what we call as breadth-first traversal. And in an ideal scenario, what a detective might choose is a combination of both these, uh breadth-first and along with that he might also depth-first search. For

example, he might start with a breadth-first um a traversal because he wants to um know the high-level understanding of all the different suspects in that particular case. And then based on the instinct, he can go all in on one particular suspect using the depth-first traversal. So, that is how we are going to approach our uh particular case in the uh graph rack Moving away from the uh

the detective story, uh let's get into the real-world domain. The domain that we are going to see today is uh a typical event management system. Uh the event is going to be at the center of this graph, um what we call as a domain graph, uh because everything revolves around this event. Uh a particular event could have multiple sessions and those sessions could have multiple CFPs, and

those CFPs could have multiple submissions. And obviously, the event is going to be held at a revenue, uh which is going to have multiple rooms. And what happens is like whenever a user is registered for an event, uh he he could also uh present for that particular topic, and the event is uh ultimately um uh going to be sponsored by different sponsors. So, this is how uh

you could come up with the domain graph and you could you could see how the data is connected here, right? It is not just the data, it is the connected system that we are uh that we are seeing right now. And this allows you to approach the system with much richer questions than the data that is isolated in a different database, right? But in a typical event

management system or any conference or any meetups that you attend, um we all could agree on one thing, the knowledge or the the value that you we gain from those sessions are uh really high, right? But once we are done with the meetup, like we find it very difficult for us to uh get back those knowledge after the Uh because um uh it could be in various

other formats, um resources that are shared by the speakers or uh uh the conferences is going to be in different unstructured documents. Like it could be in an podcast format or it could be in a video format or it could be a slide. So, essentially it becomes hard for us to go back and refer those knowledge at later point in time. So, obviously there is a gap

here and that is the gap that I want to fill with the knowledge graph. So, what essentially we can come up with this uh lexical graph. So, um in order to create this lexical graph, what you need to do is like you need to extract the contents from those unstructured documents in the first place. Um and uh I have covered in detail on how to uh do

this extraction process from the unstructured documents in the previous Neo4j conference. So, I will try to uh add those references once this session is got over. Uh but the ultimate idea is to um build your own custom uh extraction pipeline for it uh without relying on any abstraction frameworks because you could uh get much flexibility and control over what schema you want for the lexical graph. For

example, if you look at this diagram, uh the document is going to be at the uh center of this uh lexical graph. And um a document can contain multiple sections and those sections could contain multiple subsections on its own. And obviously, these sections are going to be chunked into multiple parts. And you need to have relationship between those different chunks within the same section with the next

chunk uh similarity. And you could also come up with a different relationship called similar-to relationship. Um this one could span across different documents on the whole. It doesn't need to be really really on the same section. So, this kind of flexibility you will be able to get if you are building your own extraction pipelines. And obviously, you could um consolidate uh different concepts that you're covering in

those chunks into concepts. But the problem now is like we do have the domain graph and the lexical graph, but there is no way for us to uh traverse through um these two individual graphs uh at the same time because uh there is no way for us to connect these two different graphs. And for us to do that, we need to have something called as a bridge.

So, here what I've done is like I have chosen the user entity or node as uh the uh the bridge for us to connect between this lexical graph and the domain graph. So, uh from the document, you could have or establish a relationship called presented by uh and have a relationship against a user node. By this way, you could uh establish a bridge across a lexical graph

and domain graph. Or it could be multiple relationships that you could establish to create this link between the lexical graph and the domain graph. So, that when you are uh retrieving some information back from this knowledge graph, you could bring in the additional context from the domain graph as well, not just relying on the lexical graph or the uh context that you are going to uh ask

in the user query. Now, there are different strategies as I said before, um the vector rack and the graph rack. So, let's see how the uh traditional vector rack works. So, in the traditional vector rack, what happens is like once there is a user question, um it comes to our pipeline and what you will be essentially doing is like you will be having an uh embedding generator,

you will convert those question into a vector form, and that vector form will be run against the vector database that you have. In our case, it is the Neo4j. You will be doing similarity search against the vector index that you created, and you will be retrieving top end chunks or top key chunks from it, right? And these chunks are the one that will be having relevant text

attached to it, and you will be extracting those text, and you will be feeding that to the LLM, and you will be generating the final natural language which responds back to the user question. This is plain simple vector rack methodology. Now, let's look into the graph rack process. So, essentially, the graph rack process is also somewhat similar until the vector similarity search that we did. But, instead

of directly pumping those different chunks and different extracted text to directly to the LLM, what we will do in addition is that we will do the graph enrichment process, where, as we said in the deductive case, like we could either go with DFS or BFS, or we could go with a combination of DFS and BFS to enrich this graph and provide additional context to the user query,

and then extract those um knowledge, and then provide it back to So, this is what we call it as graph Now, let me show you how this looks um in in the Neo4j console. So, this is essentially the graph that we've seen earlier in the presentation. So, what we have at the below is the domain graph, and what we have at the top end is the lexical

graph. And as I said before, each document is going to contain multiple sections, and those sections could have multiple check chunks, and it could have multiple relationships, as I said before. Similar relationship will be able to help you to achieve this breadth-first traversal because it can um gain knowledge from different documents on a whole, and you could relate them to a particular user question, which will be

really helpful for you to bring in lot other context to the user question. And obviously, you could also categorize those individual chunks into concepts. And as we say seen earlier, this is going to be the domain graph, which we already covered, So, let me see a complete graph, right? So, I what I did is I just populated this entire graph with around 50 documents or so, and

there are 100 different conferences 1,000 different events as I pumped it to this system. So, this is how the graph looks like for now, and these are the lexical graph at the top portion and the domain graph at the bottom portions. Let's see the relationship map. So, what we are doing in this query is group by the relationship, and we are going to pick the the top

one node from it, and then we are going to list it here. So, that it will give you at least a brief idea on what each node does. So, this is the document. This could be a slide, or it could be video presentation, or it could be a podcast, which we extracted and dumped into this knowledge graph, and it could have multiple sections, as I said before,

and this is presented by a user. And this is the essentially our link or bridge to the domain graph. Um and this could have different concepts, and these are the different chunks. If you look at the chunk, what it will be having is like it will be having an embedding, and this is the the vector format of whatever the text content that we have And whenever there

is an user question, like we run the similarity search against this index, and that is how you will be able to get the relevant entries out of the knowledge graph. And this is the example of the the domain graph. So, this is the event, and it could [clears throat] have multiple relationships with a different other nodes. So, let's visualize a single event from this entire graph. And

you could see a single event could have multiple do that particular event could have held at a different venues, and it could have multiple rooms, and there could be multiple sponsors, and it could have So, let's see how the bridge is being connected. So, for this, what I'm going to do is like I'm going to pick one of the particular user, and I'm going to show you

how the is connected to this particular user. Okay, let me zoom up it. Yeah. So, consider this is one of the documents from this entire event, and you could see this relationship, right? So, this is the presented by relationship, which links lexical graph and the domain graph, as you could see here. Now, the real benefits you you might bring out of these knowledge graphs that like the

multi-hop reasoning that you could do internally with these LLMs, right? So, let's understand those. This is the example for single-hop questions that you might get from your knowledge graph. This is to represent the relationship between the user and the session, and this is going to contain only one relationship, which is speaking at particular conference. if you go two hop from here, you could also get an event

to which it is tied to. So, earlier we just saw user tied to a particular session because he presented that session. But now, if you want to know under which event he published that session, you could do two hops, and you could get into the session. And if you going to do three hops, you could also get the concepts different concepts that he covered as part of

his sessions. And let me show you how the similarity search works. Um or the the similar to relationship that we had before. So, say suppose these are two different documents entirely done on different sessions, and these are related with this similar to relationship because what we had earlier is like the chunk node is having the similar to multiple documents. So, that is how you could even relate

completely different sessions that happened on different timelines as well. let me do this one. Okay, so what we are doing here is like we are we are querying this vector index. We are essentially passing the the vector representation into the chunk embedding, and then we are retrieving both the lexical graph and as well the domain graph, so that you get all these different nodes. There are around

243 nodes and 266 relationship that you could get out of five similar nodes. So, this is how the knowledge that you gain out of the knowledge graph will be more beneficial than the vector graph. And let's see a quick demo on this. Um I built a simple tool for this one, and for for the judge, what I'm going to do is like I I do have a

LLM to predict what which methodology has a better output based on different metrics. So, we will go through each one of those. So, let me do depth-first traversal with this particular question. So, So, this question is like about what has a particular session particular user has presented on event-driven architecture, and how did that relate to session at different conferences. So, this is the question that I'm going

to ask, and let's see how the vector rack is going to perform and the graph rack is going to perform. So, the vector graph is going to just do the similarity search against the vector index that we have in the Neo4j, and it is going to retrieve top five similarities chunks, and based on that, you will be getting the response back. But in case the graph rack,

as you could see, it is way more detailed, and let's see the the explanation what has been generated. So, I'm just going to quickly go through the comparative analysis here. So, what it says is the graph rack answer provided a more complete and useful response to the user question by identifying relevant named individuals. Earlier, like if if you are focusing on the vector rack, it doesn't know

which user presented particular session or under what event he presented on that particular topic, right? But if you look at the graph rack answer, it can clearly identify who presented on what and how different event-driven architecture sections has been presented all over different timelines. And this is one of the example, and let me run one for the breadth-first So here it is a generic question what I'm

asking here is like what are the different topics, organization, and speaker connected to the knowledge graph and rack at our conferences, right? So let's see how both of these two different methodologies is going to Here you could see there are 62 chunks it retrieved and there are 124 nodes it traversed and then 248 relationships it traversed across. So obviously the graph rack answer is going to be

better than the vector rack for the very reason what we seen earlier. So let's see like what are the vector rack limitations here. It was missing the metadata and there was lack of context, of course. With the similarity text you could utmost get the similar text or similar meanings of semantics that you could retrieve from those knowledge graphs, but you can't get these attributions like additional attributions

that you have in the domain graph, but because there is no link for you to establish that in the the vector graph until you have a definitive way to pump in those informations along with those unstructured documents, which will complicate your process. And also it won't give you better response than the graph rack approach. run across all the scenarios. I will try to open source this source

code right after the session. So you could try different scenarios I have built here for different traversal strategies like depth-first and breadth-first. And let me quickly show you how this works behind in the code, right? So this is the graph rack service. Here what I'm going to initially do is like call the vector index. I'm going to retrieve top similarity index, but that is not the only

thing that we do because this is the only thing that you do in the vector rack scenario, but in addition to this like what you could also do is like you could retrieve those domain graphs with the help of the user relationship that you established before, right? The bridge. So with that you now have the could be retrieved back to the user. And in case of vector

rack it's going to be too straightforward. It is just going to be retrieving top similar nodes from based on the the embeddings. So now let's see Let's go back to our presentation. Let's see how to improve this existing architecture that we have with this agentic AI approach. So say suppose instead of directly pumping our question into our pipeline, what you could additionally do is like you could

have a router agent in place that could act as an intermediary agent that could analyze the complexity of the question and route based on those complexities to two different paths. One is the graph traversal agent for which is the path you could take if you want to address generic questions or if you want to address DFS or BFS queries. And you could make use of graph retriever

agent in case of more structured queries like get me top five speakers from this particular conference or multi-hop questions like you could have multiple questions in the same single questions in that scenarios like you need to do a task decomposition on top of what you are doing as a retriever and that could be used in the retriever agent to bring back the answer. So let's see the

traversal agent. So traversal agent is nothing but like what we have the graph rack system. In addition to that like we do have all these different tools. You could switch between all these different strategies, DFS, BFS, or it could combine of both of these strategies. And ultimately you could also have an evaluator agent to finalize the the output whether it is or not hallucinating and it is

giving the right information. So you could also use this as an additional check for your system. And in case of a retriever agent, what you could do is like you convert the natural language into the Cypher because we are not magicians, right? Like we really know we we really don't know like what the user is going to ask as a question. So what you could do in

turn is like you could convert those natural language into Cypher so that you could directly run against them knowledge graph and you could retrieve those informations. And as I said the question that user is going to ask is not going to be a simple straightforward question. It could also contain multiple question in the same single question, right? So in that scenario you just need to decompose the

task. You need you just need to break those task into individual questions and you need to run this NL2Cypher tool to retrieve those individual metrics and you need to consolidate the result and finally get get back to the user. So this is how you could extend your graph rack system using an agentic cover different use cases. And thank you for listening to my session. If you have

any doubts, you can always reach out to me on this LinkedIn handle. >> [music]