Agentic GraphRAG: Simplifying Retrieval Across Structured & Unstructured Data — Zach Blumenfeld

Key Takeaways

[Music] I'm going to go over today graph rag particularly dealing with multiple data sources. Uh so both unstructured and structured data sources and kind of why you would want to ever do that in the first place even. So I prepared uh some notebooks here. I was going to make slides, but then I thought it would just be easier to walk through some of what this looks like in practice. Um, so there's a link here, and I can share it with you at the booth later, um, if you have follow-up questions. But basically, uh, what I wanted to show you first is just what a general graph architecture looks like, right? And so basically what we do is we have our agents, right? We have our tools just like you normally would. But then in the middle here, you see off to the side, we have this knowledge graph. In this knowledge graph, you can both extract data from documents and unstructured places and also have standard ETLs for structured data. And so there's a big question of why in the hell you would want this knowledge graph thing sticking in the middle there. And I could talk about accuracy and explanability, but I think what's really valuable to talk about is kind of what this means going forward with agents and how it's valuable for agentic workflows. And as we think about some of what agents can do with reasoning and decomposing questions, a lot of the retrieval that we're seeing is not so much just a straight shot vector search anymore. A lot of what we're seeing is a question being broken down and being handed multiple queries, right, to go and pull the data that you need. And the great thing about having a knowledge graph is that you can express a very simple data model to get started to your agent which can help it do that decomposition, pull information accurately, and then as you sort of expand, you can keep adding more and more data. The example that I'm going to show you here inside of these notebooks is going to be for a uh employee graph. So basically, think about a knowledge assistant that's responsible for helping pull information around skills analysis. um look for similarities or substitutions in a team and try to figure out who's collaborating, where skill gaps are, all that sort of stuff. And the data that we're going to start with today is just going to be in rums. I just have these PDFs, just like a folder of résumés, um that are pretty standard. It just lists people's professional experience and descriptions. Um it's for a company called uh what did we have here? Cyberdine Systems, if anyone's familiar with them. a little Terminator reference. All right. Um, so anyway, the first thing that I'm going to do to just show you what this looks like is I'm going to load documents into the Neo Forj graph database, but just sort of as like basically documents ch basically take every resume, put an embedding on it. What it looks like here, if I was to if I was to scroll here, is kind of like this. So basically, you know, I have these different nodes, but you'll see the nodes are basically just going to have some metadata, some text, which is the resume, and then an embedding. And basically what I'm going to do is I'm just going to create an agent inside of ADK, so Google's framework. And I'm going to start asking it some of those questions. And so basically what you're going to see here and I don't have time unfortunately to walk through all of the code but basically if you look at this agent that's been constructed right I have my agent I have some instructions to pull data and then I give it one tool which is a tool to go search documents right and so I'm going to ask it a question how many Python developers do I have you can imagine right this is probably not going to work out very well if all I have is just documents because basically it's going to tell me I five Python developers and that's because I set K equal to five right when I went to go pull my document. So obviously that's going to be wrong and I'm telling you that that answer that answer is wrong. So you could probably solve that with doing some entity extraction and putting more metadata right on your nodes. So that's so that's fine. So then I'm going to ask who is most similar to a particular person in terms of just their skill set or what they've done. Um and again here what you'll see and I've told it in the bottom to kind of explain what it's doing. Um, if I go down to the display here, um, it it'll tell me basically here that what it's doing is it's just going to be using search terms to go pull information. So, this might help you find similarity to a certain extent like it knows, you know, Lucas's as a full stack AI engineer and he does, you know, Python, JavaScript, and some machine learning stuff, I guess. Um, so you can search for that and you can find some similar people, but the logic is still a little bit hard to control. It's just sort of, you know, plain semantic similarity search. Um, and as I start to go down, I can ask questions like summarize my technical talent and skills distribution. It's not going to be able to answer that, right? Because it needs to be able to do an aggregation to answer a question like that. So, if I was to go up and look at the logic again, or I'll go down here. Um, it could say I search, you know, employees resumes using certain search terms and stuff, right? And it so it's basically if I go down and ask these questions, it's just going to be using search terms to find things. And so that's not really good enough for our use case because we want to do analytics, we want to do aggregations, and we want to try to find relationships between people. Um, and again, like in the last question, I basically asked it to find who's collaborating on lots of projects. And all it can do is search for collaborators, which is not really what I want. Like what I want is to find who's been collaborating with who on different projects, right? And the resume data, you know, might have that, but it's all, you know, sunk inside of the text and stuff. So, so it can't really do that. So the question is now well how do I think about basically explaining my data to my agent and then also making sure right that I have a data model that makes sense. So if you think about it, you can do this at the data layer. You can think about how do I want to model my data just to start for some of these beginning questions. And here it's basically like I want to know what a person is. So I need that. I want some concept of a person knowing skills and then the only other thing that I really care about is what do people do? Like what things do they do? Right? Very simple. That's just the data model that I want to express. So I'm going to do entity extraction of these documents to basically create this graph. And really it's going to be just slightly more complicated than that because basically what I need to do here is I actually need to create a graph where right I have instead of just doing things I have publish built one led managed optimized shipped things and then those things are going to belong to different domains and work types. um which is going to allow me to kind of connect similar things together inside of the graph. So it's it's a little bit more complicated, but it's it's the same exact concept. Um and basically the entity extraction workflows we use um are pretty um self-explanatory. They use um if I was to go here, I use paidantic classes to do that. So I have concept of enumerations on the types of accomplishments and domains that I want and work types as well. I define my things. I define how someone does a thing through an accomplishment. Um and then basically I put that through um another workflow. Um I think I use lang chain in this case uh to basically decompose those documents and spit out a bunch of JSON and inside of that JSON for example for this person I have their skills right that I get in here and I also have their accomplishments that I get inside of here. Um, so I can go ahead and load that as well into my graph. And now I have a much more expressive data model. So if I go back to here and scroll up and look at this guy, this is now kind of what my data model looks like, right? I have my people, but now you see how they're connected by all of these different skills that they have as well as the things that they're actually working on and how those things connect to higher level concepts like whether it's, you know, um building something for a system or shipping code, doing all those sorts of things. And now because I have that expressive data model, I'm able to start having a lot more precision around the way that I get my questions uh basically answered. So what I do here after all this graph construction which I already talked through is I create this other agent give it a similar set of instructions. I tell it a little bit about my data model in here and then I'm actually going to be using this MCP server that allows it to read the schema and also generate cipher statements. Um so this is an MCP tool that we just have you know out on GitHub that you can pull. Now when I ask how many developers I have now I can actually do a query that's going to match on person nose scale Python and because of that I get an answer that's much closer to correct which is 28 developers right that's very simple that's just aggregation but now I can ask a similarity question right like I did before who is most similar to Lucas Martinez and watch this is the same exact question and when I went to go uh calculate that I got an answer that it's Sarah and it will explain the reasoning that it did. It searched for people with who knew um the same skill sets. Sometimes when I ask this, it will also search for people who have similar accomplishments as well. Um and it will explain exactly like hey like I did an overlap calculation in the graph to figure out basically you know given the number of skill sets they had and the number of overlap this is the person that I think is the closest. So the benefit of doing this is that you have much more control and you can go in and filter exactly what skills people have. So for example, if I knew someone actually didn't have a certain skill or did have a certain skill, I can audit that. I can adjust the graph to be able to make that work. Um and then similarly as we go down to summarize a technical talent distribution, um again I can match on those skills and I can start to answer these questions and actually get numbers between how many people know different skills. Um, and it can also break down different accomplishments and other things of that nature. So, you just get much more refinement in the types of answers uh that you get for your questions. Um, I can also add additional tools. Uh, so instead of just generating uh cipher kind of um on the fly with a language model, I can also, and I'll show you what some of these look like in uh my bigger screen here. I can go ahead and move this up. So this is an example of finding people with similar skills here that I'm about to show you. And basically, right, I can do these very flexible queries in a graph database where I can say, hey, go from person ID to this other person ID. And as I do that, basically what I'm saying in that top syntax there is go out some, you know, zero to three hops, basically. And so what that allows me to do is I can traverse over both the skills over the common systems over the common domains they work at and all of their accomplishments. Um, and if I wanted to add something else to that data model, maybe there's a collaboration link or another project link that would all get picked up inside of that query. So there's a lot of flexibility and also higher performance um in a graph database when you start wanting to do those types of complex traversals. Um, and that allows me then when I go to find similar people again. So if I was just to scroll down to my uh question where I define my agent again, I give it more tools. And then I can actually look at who is most similar to Lucas Martinez and why. And it will start doing these queries. So what you see it get back is like all of the results of what I was just showing you earlier. And what that will help with if I scroll down to the response is now what will help me get all of these specific numbers around the skills and then also the domains now um between the different AI and analytics and data engineering and things that they were working on. So there's more explanability with the way that these questions are being uh answered. The last part that I wanted to show you and I only have a few minutes left so I'm going to go very quick is what happens now when you want to add more data to your graph. Right? So basically say that we had this resume data but now we have this internal data that comes from a human resource intelligence system and this tells me different projects that people are working on together and collaborating on. So I have basically the same people that came from resumeumés earlier but now I can see different projects that they were working on together. And the great thing about graph is that it allows you to add these things very flexibly. So if I go back to my um to my notebook here, when you expand a data model with something like if you're if you're in sort of RDBMS or tables, one of the assumptions that I made when I was ingesting the resumes initially was it was one person. An accomplishment only had one person. It was sort of this onetoone relationship or really it was one to many. But an accomplishment only had one person because it was just listed on their resume. But now that I um am doing this thing with this internal system, I can actually see people who are uh co- collaborating and what that would mean in a tabular environment is I would have to create another join table, right? So I'd have to do some sort of data model refactor. But the great thing about graph is that I don't have to do that at all. I can just sort of create new relationships. So this is very useful when you're going from one to many to many to many or when you're introducing completely new node and relationship types. It's very easy to do that which is super important as we move very very fast right with our agents and we want to ingest new data quickly and kind of build out our systems and pivot and all that sort of stuff. Um and once I have that information right I can start asking questions about who's collaborating with each other. Um so what I'm going to do is I'm going to create this is sort of what the tool creation looks like. This is a lot of the same tools that I had before. Um but the tool that I can create here to find collaborators will basically do this match um it's all the way down here. It will do this match to find people who are working on the same thing um within a certain set of domains. Uh so that's kind of what the graph looks like that I get returned. And when I now want since I've added that tool basically what it means is that when I ask a question like which individuals have collaborated with each other to in this says deliver the most AI things right it can go ahead and leverage that tool um and then it can now return an answer that's much more um you know exact and based on my data. So now I know that Sarah and Amanda have accompated on very specific um projects and as well as I have other collaborators here with supply chain and such. Uh so that was my short presentation. I hope it was helpful. Uh if you have any more questions, I would be happy to meet you at the booth and we can talk more. Um but that's it for me today. Thank you everyone. [Music]