 Hey everyone, welcome back to another episode of the Lama Index webinar series. Today is shaping up to be one of our most popular webinars slash workshops ever with property graph indexes in Lama Index in partnership with Neo4j. And so this is going to be a special workshop on teaching you how to build advanced knowledge graph rag and you'll be able to learn how to use our brand new property graph abstractions both to construct an existing graph as well as to query a graph. And so we're excited to host Tomas from Neo4j, as well as Logan from our side. And without further ado, feel free to kick it off. Okay, so like I said, I'm happy to be here and talk about graphs. So as mentioned, today, we're going to talk about the new property graph index integration in Lama Index. And if you might be wondering, property graph, what actually is that, right? Because most of the time, I don't know if I can remove this. I don't know if I can remove this. So most of the time when dealing with graphs, especially in the REC, like frameworks, what we see is usually triples, just like subject, relationship type, and then object, and the other way around. But actually, property graphs have now got an actual standard. There's the new GQL standard, which is part of the ISO committee. And that's very exciting. But basically, property graph, as you might imagine, means that nodes have properties and relationships have properties as well. So for example, here we have one node and it has properties name, Amy Peters, date of birth, employee ID, right? But it also has this one special property that we call label in property graph models. And as you can see, for example, the green node has an employee node label, right? And node labels are used to put nodes into sets of categories. For example, in this example, we have three node labels. We have employee, company, and city. As mentioned before, relationships can also have properties. It's a slightly different data representation than what you might be used to, like from the previous, let's say, implementation in Lama Index, the knowledge graph implementation, where we only dealt with triples. So that's about property graphs. And now let's talk a little bit about property graph index integration. So the flow that most of the time you will follow when you're using property graph index integration, you start with a bunch of documents. And Lama index has great support for various types of documents. So I will not go into that. But basically documents, you can think of them as just wrappers around text. And so basically, we take a bunch of documents and we pass the text from those documents to graph constructors. So in the integration that Logan did, you can use one or multiple graph constructors to create a knowledge graph. And we'll talk a little bit more about them create a knowledge graph and we'll talk a little bit more about them later. I'll show you what we showed available out of the box. And so the property, the graph constructors extract like structured information from documents and store them as a graph in the knowledge graph. So and store them as a graph in the knowledge graph. So there are a couple of integrations that Lama Index already has. As I'm from Neo4j, I will focus on the Neo4j integration. But there are others as well and probably more coming up. So once you've built your knowledge graph, on the other side, we have the so-called graph retrievers. The graph retrievers, their job is to basically based on the user question, they have some logic they can use to retrieve data from the knowledge graph. And again, there are a couple of out-of-the-box retrievers that you can use and we'll also show how easy it is to define a custom graph retriever in the workshop later. So that's basically the kind of the flow that you can think of. And what Lama Index does is it provides graph constructors and graph retrievers. I mean, obviously also the other parts, just that the graph constructors and graph retrievers are part of the new property graph index integration. And the idea is that they are very modular and customizable. So that if you're a beginner, you can just use something out of the box. But if you're like advanced user and you need something it's very easy to customize the pipeline for your needs. Let's like at high level property graph construction, as I said, we take a bunch of documents and we construct a knowledge graph. Here I have an example, documents where like for more open AI employees founded new companies. Right. So for example, here you would have four different documents mesh with some information. But the nice thing about knowledge graphs is that you kind of condense that information and unify it, right? So that basically the information that was previously spread across multiple documents is now easily accessible and nicely represented in a knowledge graph. And then I prepared a couple of slides what is available out of the box in Lama index. So out of the box, we have three graph constructors. The first one is the so-called implicit path extractor. And what it does, it just, we have a new word for it. It's called a lexical graph. But what it actually does, you just take the green note is the original document. And what it does, it just chunks the documents. So the what's this like gray-ish notes, text chunks, right? And text chunks are connected to the source document. And then also we have an ordered list of text chunks so that we know how do they follow each other. So this is the implicit path extractor, graph constructor, and it doesn't require an LLM because it's just basically chunking up and then creating a linked list of text chunks. And then the next one is the simple LLM Patek selector. And as the name would suggest, you need an LLM for that. And from what I've been digging around in the implementation, how the simple LLM Patek selector works is basically to do prompt engineering. So, you in the prompt, you define what like how the output should look like and then you provide a parsing function that extracts that output from an LLM and creates a knowledge graph. So it's, I would call it like a prompt based solution. And by default, all nodes have the same label, or like the default implementation, all nodes have the same label. And again, the purple one is the text chunk. same label. And again, the purple one is the text chunk. So we always store the reference text in the graph as well. And then the entities that were mentioned in the text chunk, we have the mentions relationships to those entities. And then obviously, entities can have relationships between each other. Right? So for example, Amelia Earhart was American aviation pioneer. Right? And this is kind of the simpler version of graphics selection. Now obviously you can customize it and make it more advanced, but by default all nodes have the same label. Then the more advanced is the schema RLM path extractor. So here you have the ability to define which nodes and node labels and relationship types you can extract. This one we'll also use in the workshop so you'll get to see in So you'll get to see in practice how do we define the schema. But basically, as you can see, by different colors of nodes, means that they have different node labels. And again, the purple ones are the text chunks, the reference text chunks. And then the text chunks mention the entities that appeared in those text chunks. And then obviously we have a bunch of relationships between those entities as well. And this one works best with LLMs that provide function calling, like native function calling, like the commercial LLMs, like OpenAI, Gemini, Mistral, probably some others. Grog is a nice one as well. Grok is actually a really nice one because it's really fast and that's really nice for the knowledge construction. But yeah, so it works best with LNS, with native function calling, but Logan told me that it will also work with models that don't provide native function calling, just not as well. Or maybe the schema should be simpler in those using those LLMs. But as I said, I haven't tested it out. But maybe you can test it out and let us know how it works. So this is basically the out-of-the-box graph constructors that you can use. And then what's not in the Lama index yet, but since Lama index provides low level connections to graph stores, Neo4j in this example, if we can also come up with custom entity disambiguation, which we will do in this workshop as well. And entity disambiguation just means that if you have multiple nodes in the knowledge graph that reference the same real world entity, you kind of want to merge them together into a single node so that you have a better structural integrity. So here in this example, this node ends with a limited, this one has abbreviation limited and this one doesn't have limited. It all references the same node. So that means that's why we want to merge it into a single node so that we have better selection integrity. And in the workshop, we'll use a combination of text embeddings and word distance heuristics to find potential candidates and then merge them and then merge them together. Here is basically, if you're anxious, you can follow this link and this is basically the notebook that we'll be using today. Then on the other side, we have property graph retrievers. As you see, I just took the previous image and just slice it up because here we have the remaining of the arrow. But the graph retrievers, as I said, based on the user input, they have some logic how to retrieve information from the knowledge graph and then pass that information to an LLM so that the LLM can generate the final answer. Basically, a typical reg pipeline. And we have, I think, four out-of-the-box retrievers that you can use. Here, I didn't have time to draw nice diagrams. So I just summarize them quickly. So the first one is the LLM synonyms retriever. It takes the user query, generates synonyms using an LLM, and then it finds the relevant nodes using exact keyword match. So that's really important because LLM is not aware of any values in the database when it's generating the synonyms. So it's not a given that the LLM will know how to construct the keywords so that they will match any nodes in the graph. So because it uses at least the Neo4j integration uses exact keyword match, we could basically optimize this to allow some misspelling or stuff like that. But at the moment, it's using exact keyword match. And then once it finds relevant nodes, it returns basically the direct neighborhood or basically you have an option to decide how many or like what's the distance, what's the neighborhood size of the nodes that you want to return. So by default, we return just direct neighbors of that node. And then the second one is the vector context editor. So in the previous one, we used exact keyword search to find relevant nodes. But here in this example, we're using vector search. So that means it's more robust and less reliable on exact keyword match, because with keyword, with vector search, you will always get some results from the database because you take top end. And then hopefully some relevant nodes are identified using vector search. And then we just do the same thing as we did in the previous one. We just return the direct neighborhood of relevant nodes that were found using the vector search. Then another one is the text to cipher. So as the name implies, we take the text and use an LLM to generate cipher statements. So this is very flexible approach because the LLM can construct any sorts of cipher statements. So for example, with vector context, when you're just finding for searching for relevant nodes using vector search and then returning the neighborhoods, it's very hard to answer questions like how many nodes are in the graph because it's like an aggregation query and vector context retrieval is not suitable for aggregation queries. At least not like on the global scale. But like, for example, with text cipher, you could ask it questions like how many nodes are in the graph or like how many people are in the graph. And the LLM will generate appropriate cipher statements and return that information for you. So text cipher is much more flexible than the previous tools. But there's obviously always a trade-off that it's less reliable because we're using LLM to generate cipher statements. And that's at the moment how I see it. It's mostly correct, but not like always. So you're kind of trading off flexibility for a bit of accuracy. But then on the other side, what you have is also some different, like Texas Cypher allows you to also do aggregations and stuff like that, which the previous retrievers didn't allow you. And then the last one is the so called cipher template retriever. And here instead of generating cipher statements with an LLM, you basically define the cipher statements you want to be executed and you just parameterize like a parameterized cipher template. So basically you have a cipher statement with like one or more parameters. And then at credit time, basically the LLM, you provide instruction to an LLM how to populate those parameters. And then at credit time, LLM extracts relevant parameters it needs to use with the cipher template, populates the template, and then executes the predefined cipher template. So that's where the template comes from because it's predefined. Then here I have questions, for them because it's pretty defined. And then here I have questions, but let's do a demo. Tomas, I'm just going to read through some questions in the chat so far just to make sure we cover some of them before the workshop. The first is, I think one question is actually about using LLMs. And if you have a set of recommended LLMs that you think are better for, say, knowledge graph construction, as well as the cost of running LLMs across a large corpus of documents to construct a knowledge graph. I'm curious to get your initial takes there, as well as recommendations for some of these users. Some of them are thinking about using like Rock, for instance. like recommendations for some of these users. Some of them are thinking about using like rock, for instance. Yeah. So what you will see is that graph construction, like LNMs and graph construction is very model dependent. So different models will generate different graphs. And it's very like even different versions of GPT-4 will behave differently. So I did some testing, like I'm not like an expert in all of the airlines, but for example, what I will tell you when you're using like a predefined schema, like the GPT 3.5 will try to fit all that information into the schema so that it kind of over fits information into the schema where it's not really where it wouldn't really fit in reality. But then GPT for turbo and for low0 are much better at ignoring the information that is not part of the schema. For example, if you want to use, I would really recommend using LLMs that are fast. So for example, GPT-4, just throw it out of the window because it takes forever and it's costly. before just throw it out of the window because it takes forever and it's costly that's in that like grok is really nice because it's really fast but then the problem with grok is they don't want to take our money just yet so hopefully when they will be taking our credit cards that's something I would definitely look into. But in general, it's like the better the model, the better will be the results. The more it will follow the prompt instructions. Great. And just following up with just one more quick question is this might not actually quite exist in some of our abstractions right now, but one of the questions around like dealing with missing information from the graph, which sort of implies this, like maybe you do some LLM construction paths. It's not completely exactly where you want it to be. And so you do some human in the loop paths to try to like modify and shape graph to better reflect what you want out of that data. Have you seen that kind of human in the loop approach towards graph construction? So it's not really human in the loop. It's more like they have some heuristics, because I didn't really mention, but if you want to take a look, the graph lag by Microsoft paper is really nice. And it deals with some of these questions. So the first one is also like what types of, what's the size of text chunks you should use right and the thing is the it's kind of funny like the number of nodes and relationships is kind of irrelevant to the chunk sizes so that just means if you're using smaller text chunks more information will be extracted and if you're using bigger text chunks like the the overall number of extractions will be the extract information will be the same. But since you're using larger text chunks, right on the like in summary, less information will be extracted from larger text chunks. So that's one thing they mentioned in the paper. And then the second thing they mentioned, they have some sort of heuristics where they can decide, okay, not enough information was extracted from the text. And then they do a second run. So basically, instead of having a human in the loop, it's kind of automated and saying, okay, you didn't do a good enough job. Now, let's do a second pass on the graphics selection. Oh, OK. Yeah, super interesting. Any other questions? Feel free to carry on. There's a ton of questions, but I think we'll.. Yeah, I mean, because the extraction part will take a couple of minutes, and we can answer questions. So here I define my graph. So OK, just seconds. OK, that's fine. And one thing I also noticed is that people are sometimes confused by documents because like all Lama index mostly deals with the documents, right? But document is just a wrapper around the text. So it's very easy to go from text to document. We just instantiate the document with a text property and that's about it. Right. So here in this example, we're gonna create a bunch of documents based on the news. So we have a bunch of news. And we're going to use GPT-4.0. And for example, one thing that's also interesting, there's like a lot of things that comes popping up. And one thing I noticed today or yesterday, somebody did some benchmarks and they said basically that if you're using slightly higher temperature than zero, even for the deterministic tasks, you get better results. It was specifically for GPT-4. Again, that's very interesting and we're all learning as we go along. But as mentioned, we're going to use the schema LLM path extractor in this workshop. So with schema LLM path extractor, you have to define the types of nodes you want to extract. So here I went for person, location, organization, product and event. So it's mostly a very typical extraction. And then there's the event, which is kind of more ambiguous and allows the LLM to extract a lot of information, right? Because event can be anything basically. And then I also, we also have to define the types of relationships we want to extract. So here I focused more on the like organization business part where we have suppliers, competitors, acquisitions, subsidiaries, CEOs, stuff like that. So we are going to hopefully extract some business relevant slash financial information, hopefully, from the knowledge graph. And then, so this is the first part of the, when we are defining the schema. And then the second part is we also have to define which information, which relationships is assigned to each person, right? Because not all relationships can be part of all node labels, right? So we have to define, so for example, a product only has provides relationship and then provides is only on the organization. So then ideally, the RLM would generate only provides relationships between organizations and products. Because it doesn't really make sense to have provides relationship from location to let's say a product. So this is a little bit more granular schema definition that we need to provide and then we just pass the possible entities, relationships, and validation schema to the LLM. Here you have the strict mode. Strict mode, even if you provide instructions to the LLM, which types of nodes and relationships it should use, it doesn't really mean that it will follow them. Oops, where are you? 100 percent correct, right? Because LLMs are just LLMs, they do what they want. Then Logan implemented a strict mode. So it means that, but since we know the types of relationships and nodes we expect, we can filter them out. If we want to in the code, right, or we can leave any other nodes in the relationship to LLM identified. So in this case, let's just allow any information the LLM decides additionally to extract. Now GPT-40 is quite good at following the provided schema, right? But other models, and this is also because, as I said, GPT-4 is a native function calling model. So when you're using functions or tools to extract information, it will have much better accuracy, whereas like Lama3, have much better accuracy, whereas like Lama free, which is not GROK. So Lama free via Lama doesn't have function calling. It's still a really good model, but it might not follow the schema always. So that's why you have the option to filter it in post-processing if you want to or not. And here we'll go for the not. And we're going to extract information from 100 articles and it's going to take like two or three minutes, I think. So we have time for a couple of questions. So we have time for a couple of questions. Yeah, for sure. I'm trying to figure out what questions to ask. Maybe one thing is actually going back to the retrieval side. So, you know, there is vector search with the vector context retriever. And then there's also a text to cipher. You mentioned some limitations of text to Cypher, like in your mind, like what are some of the, maybe like tips and tricks you see in getting text to Cypher working a little bit better for users in terms of making it, making sure it generates more reliable Cypher queries, how to make sure it actually retrieves relevant context. So, but I mean, this is kind of a hard question. contacts. So what I mean this is kind of a hard question so text deciphered works good for like the when the user knows what's in the database right and knows how to ask the questions that fits the schema. So that's one thing and then how to ask the questions that fits the schema. So that's one thing. And then how do you achieve that? So what you could do is you could have some query rewriting steps that take the user input and rewrites it into more of a question that fits the graph schema and it's a little bit more, it will both or implicit on how it wants the information to be retrieved. So that's one thing, obviously providing it with few short examples is very helpful because by default it uses zero shot generation, right? We just give it the graph schema and then hope for the best. But what you can also do is you can also provide it a few short examples and then hope that it follows those examples. And obviously the thing is like with more complex graph schemas, there's like just how to describe those schemas takes a lot of tokens. So when like, and then maybe not linearly, but the bigger the size of the schema, the less it will. I mean, yeah, the worse the accuracy will be. So what you can also do is then just provide parts of the schema. So instead of having one text to cipher that deals with the whole graph schema, what you can do is you can have an agent with several tools, and then each of those tools focus on different parts of the schema. So you kind of lower the complexity of the task. Cool. Yeah, that makes a lot of sense. Yeah, that makes a lot of sense. I know it's about to finish up, but maybe just another question and we can also carry this over after things are done, but is Neo4j designed to work with technical document use cases like patents and scientific papers? Will it help in identifying and building relationships between you know science technical concepts uh that's one of the questions from the audience yeah so uh yeah how you say neo4j is domain agnostic so you can store any information you want in it that being said it's's quite funny that you mentioned patents and technical documentation because that's really relevant, or at least what we see a lot of pharmaceutical or biomedical companies, right? There's a lot of money in patents and for me it was also interesting for example biomedical companies when they have this great idea what we should do or what we should research you know what they first do they check if there's already a patent and then if it's already a patent they don't research it because it won't make money. You can't patent it. So I've seen basically like big pharmaceutical companies, they all have their patent graph. They all like scrape like PubMed. You don't actually have to scrape it because it has APIs, right? But it's like you can think of it like biomedical technical documentation, like with all the latest research, and they generate knowledge graphs from those and then use it to inform or recommend. So one thing that they do is basically they generate graphs from all the latest research, then they use recommendations to recommend to doctors based on their specialization, which articles they should read. So yes, definitely Neo4j can be used for patents and is actually used by existing customers for patents and technical implementation. Okay, yes. So now that we've imported the graph, we can also take a look at it. Right. Graph visualization is usually quite nice. So let's see. We have, okay. So we can see that, for example, let's see why we have an award. We have two awards, no labels, so that's kind of funny. But it wasn't in our description. So even GPT Photo can decide, ooh, awards are really nice nice of the FA Cup and English League title. So let's see, basically probably will be who won. So it was Gordon McQueen was awarded the FA Cup. So probably there should be a football team in there. But it's interesting, you can see that even, and we have a disease as well. So even GPT-4O can decide to add some information that wasn't in the schema. So that's why we have the strict mode right if we use strict mode to do we wouldn't see those these nodes in the graph because obviously we would filter them out programmatically right and then let's Let's try to see if we have, I'm trying to find if there's anything more connected, but basically unfortunately. Okay, cool. So, and let's, so we have, for example, United Health Group is a node. And now we can see a bunch of competitors, right? And we can also see probably it's not doing so well because it had a stock sell-off and stock price decline, right? And this is, as I mentioned, event is kind of ambiguous and it can be a lot of things so in this case it was stock has invest the stock price uh declined and john rex works at united health group right so like or or overall uh the gpt photo uh followed uh the uh GPT followed the schema quite nicely. And we can see a nice graph over here. And let's go forward. And then as I mentioned before, entity retopogration is kind of a must. I think it's often overlooked, but you kind of want to find entities like nodes in the graph that reference the same real world entity and merge them. And here we have a kind of involved cypher query, which took like eight hours to come up by multiple people. But in the end, we found a nice way of using text embedding. Here we have the cosine similarity threshold and then word-heading distance. How many characters can you change in the string to have it the same? And you can see it works quite well. Like for example, Bank of America and Bank of America Corporation, Violin Music, Violin Music Group, like Newcastle, Newcastle United, Coinbase. So overall, it works really nicely to find these duplicates, but obviously it's not perfect because nothing in life is perfect. So for example, this one is kind of, I mean, it's the same, it's still jeffrey's virtual space summit right but one is fireside chat which is yeah maybe not really but fine and for example baltimore this one also right okay i can understand that these two should be merged but maybe this is a city and shouldn't be merged together. As always, you have the option to tweak these two parameters and you also have the option to then do some manually like human in the loop. Here, human in the loop is kind of important to know what entities are you merging. But I think like just having like some sort of baseline to start with is really nice. And I think this ciphered credit is really nice because you can see a lot of entities that should be merged together. And let's just merge them together. And then for the last part, as we said, we're going to implement a custom retriever and we have the four existing ones. But here we're going to implement a retriever that first identifies all the relevant entities in the text. Because, for example, the vector context retriever just takes the whole string, embeds it, and then finds the relevant node. embeds it and then finds the relevant node. But what if multiple entities are mentioned in the text? Then vector index might not be the greatest because it will embed the both entities into a single embedding. Then who really knows what happens with those numbers? There's a bunch of zeros and ones. And what do they actually represent? Who knows? So what we'll do is- Really quick before the retrieval piece. Actually, quick question on the entity disambiguation. That cipher query, I mean, given how involved it is, but given the fact that I imagine a lot of people probably need to do some sort of dedupe, is this a template that's just shared publicly? Because it seems like it would be generally useful for a lot of people. Yeah, this is part of the block. This is all available over here. I mean, we can add a link in the webinar if you know how to, but it's this one. So if I know how to do chat. Let me spam it a little bit. To everyone in the room. I think we shared the notebook. Yeah, we shared the notebook in the chat. But basically, to the audience, it's like if you want just a nice Cypher query to do, and to see a dedupe, obviously there's some limitations. You probably need to tweak the word similarity and those types of things a little bit. But if you want an existing template to go off of, you can just copy and paste from this notebook. Because it's a pretty long cipher string. So I would imagine a lot of people are going to be able to write this themselves. It's also, I would make it a model in Lama index. It's just that then it's like very Neo4j specific. And then like, it doesn't fit the best into Lama index, because you guys want to have things that, I say integration agnostic. So, but maybe we can figure out that in the coming months how to add that, because it would be nice to have that out of the box. You just expose these two parameters and let it do the magic. But maybe this is something for them. Yeah, no worries. I think even the Ross cipher is useful for the audience. And then just doing a quick check on time, I know we have technically five to 10 minutes left, but I know the last section is just like the custom retrieval section. But maybe we can just like walk through the high-level concepts, maybe just like go through the overall class and then that should be a good conclusion to this workshop. Yeah, we can do this actually quite fast. So as I said, we select entities from the user input and we use an OpenAI Pydentic program. So basically again, I would imagine we kind of use function calling behind the scenes, right? We say, this is your input parameter and it's a list of named entities in the text. Then we ask GPT for O to extract it. So basically, so then, okay, I'm rambling a bit, but so how do you define your custom editor lever? So your custom editor lever just needs two methods or actually just one. But the init is also quite nice if you want to instantiate, for example, some other functions or classes. And in the init here, we instantiate the entity extraction, which is the OpenAI PyIdentic program to define, to extract relevant entities from text. And then we also extract, define or instantiate existing vector context retriever. We can use it. And then in the custom retriever, it's actually the code is very simple, right? We just extract or find, detect is maybe the best word. If there are entities in the text, so if there are entities in the text, we just run a vector retrieval for every entity in the text. And if the LLM doesn't find any specific entities, we just use the vector retrieval on the whole text, right? And that's basically it. And then you have a couple of options. Then you have a couple of options on the structure or format of the results that you can pass back to the LLM. Here in this example, we just pass back the text. We can remove this because we don't need to change anything. this because we don't need to change anything. Yeah. And then we just basically instantiate the whole thing. And let's see what happens. So if you ask what do you know about Maliak or Dara, basically the LLN detects two entities, right? And then for each of those two entities, it runs vector retriever separately so that it kind of ensures that we will get more information for both entities, right? Because if you just use vector retriever on the whole string, text and bearing on the whole string. You might just get it for one entity, but not the other, right? Because if you use topk4, maybe one is more significant in the text and bearings. But with this approach, we make sure to cover all the entities so we get nice answers for both entities. So yeah, that's like a high level overview of the data lever and now we can answer a couple of questions again. Yeah and maybe just kind of like say a few words to help wrap this up. I think, you know, what Tamaz really showed you was an end-to-end process of both like constructing a knowledge graph and then also retrieving from it. a beginner user for knowledge graphs and llms and llama index and neo4j you know you can basically get do all this stuff in about like five lines of code or if you really want to go in you're an advanced user you're pretty familiar with knowledge graphs we offer a lot of opportunities for you to define your own custom extractors right with our core abstractions um like a robust like property graph store like the underlying low level like storage system. I think a lot of people are interested in knowledge graphs. We basically see it as like a superset, a potential superset of existing RAG solutions, especially if you're able to leverage these like properties and relations to help augment your retrieval. And there's a lot of very interesting. Like an enterprise developer, you're building knowledge graphs within the company, feel free to, you know, reach out to one of us for any sort of like blog posts, case study. We're always happy to feature like really interesting use cases of like knowledge graphs, LLMs, like LOM index and Neo4j. Right. And so always happy to showcase like very interesting applications. But hopefully this workshop was, was useful to all of you today., and you know, we'll have this on our YouTube, um, channel and then basically, hopefully we'll do, you know, maybe even like a series covering like other types of topics, um, as we go forward, but we're definitely looking forward to, to new types of applications, um, built with like, uh, knowledge graphs, KGs and other ones.LMs. So I think with that said, it's probably a good time to wrap up and really sorry. I think a lot of you had a lot of questions in the chat. We weren't able to get through all of them, but we'll have this YouTube video out and basically feel free to comment there as well. So thank you everyone. Thank you Tomas and Logan, for hopping in.
LlamaIndex Webinar: Advanced RAG with Knowledge Graphs (with Tomaz from Neo4j)
​In this webinar, you’ll learn how to use LlamaIndex property graph abstractions with Tomaz from Neo4j: 

​1️⃣ High-level property graph index + neo4j to easily construct/query knowledge graphs

​2️⃣ Low-level details on graph construction 

​3️⃣ Low-level details on graph retrieval/querying

​4️⃣ Knowledge graph agents that can reason over complex questions.

Documentation: https://docs.llamaindex.ai/en/latest/module_guides/indexing/lpg_index_guide/

[GitHub](https://github.com/run-llama/llama_index)
[Discord](https://discord.gg/dGcwcsnxhU)
[Twitter](https://twitter.com/llama_index)
[Linkedin](https://www.linkedin.com/company/llamaindex)

#knowledgegraph #llamaindex #llms #ai