The 7 Levels of Claude Code & RAG

Let's solve the problem of clawed code and memory. Getting AI systems to reliably and accurately answer questions about past conversations or giant troves of documents is a problem we have been trying to solve for years. And the typical response has been RAG, retrieval augmented generation. And while this video is titled the seven levels of clawed code and RAG, what this video is really about is deconstructing that problem of clawed code and really AI systems in general and memory. And even more importantly, this video is about giving you a road map that shows you where you stand in this fight between AI systems and memory and what you can do to get to the next level.

So as we journey through these seven levels of Claude code and RAG, we are going to hit on a number of topics, but we are not going to start here in graph RAG or anything complicated. We're going to start at the beginning, which is just the basic memory systems that are native to Claude code because, sad as it is to say, this is where most people not only begin, but it's where they stay. From auto-memory and things like Claude MD, we're going to move to outside tools, things like Obsidian, before we eventually find ourselves with the big boys, with the through RAG systems. At these levels, we'll talk about what RAG actually is, how it works, the different types of RAG: naive RAG versus graph RAG versus agentic RAG, things like rerankers, and everything in between. And at each level, we're going to break it down in the same manner. We're going to talk about what to expect at that level, the skills you need to master, the traps you need to avoid, and what you need to do to move on to the follow-on level.

What this video will not be is a super in-depth technical explanation of how to necessarily set up these specific systems because I've already done this in many instances when we talk about graph RAG and light RAG, for example, or even more advanced topics like RAG anything and these different sort of embedding systems. I've done videos where I break down from the very beginning to the very end how to set that up yourself. So when we get to those sections, I will link those videos. And this is for both our sakes. So this video isn't 5 hours long. But for those levels, we're still going to talk about what that actually means, what each system buys you, and when you should be using it.

So now let's start with level one, and that's auto-memory. These are the systems that Claude code automatically uses to create some sort of memory apparatus to actually remember things that you've talked about. And you know you're here if you've never set anything up intentionally to help Claude code remember context in general about previous conversations or just stuff that's going on in your codebase. And when we talk about auto-memory, that is quite literally what it is called. The auto-memory system, which is automatically enabled when you use Claude code, essentially allows Claude code to create markdown files on its own that sort of lists out things it thinks are important about you and that particular project. And this is purely based off of its own intuition based on your conversations. And I can see these memory files it's created. Again, it does this on its own. If you go into your Claude folder, you go into projects, you will see a folder there that is called memory. And inside that file, you'll see a number of markdown files. Here, there are four of them. And they're like Claude code's version of Post-it notes saying, "Oh yeah, he mentioned this one time about his YouTube project growth goals. Let's write that down." And inside of everyone's memory folder, there will be a memory file. So you see in this memory file, it has a little note about one of my skills. And then it has, you know, essentially an index of all these sub-memory files saying, "Hey, there's a YouTube growth one in here, a revenue one, a references one, and here's what's inside of it." So, if I'm just talking to Claude code in my vault file and I mention something about YouTube and sort of my goals with growth, whatever, it's going to reference this and say, "Oh, yeah, Chase is trying to get, you know, X amount of subscribers by the end of 2026." It's cute, but ultimately it's not that useful. It's kind of like when you're inside of ChatGPT and it will bring up random stuff about previous conversations and it almost like shoehorns it in. It's like, "Okay, I get it. You remember this, but I don't really care." Aaron, honestly, it's a little weird you keep bringing that up. I prefer if you didn't.

And unfortunately, this is where most people stay in their memory journey. And it's built upon a somewhat almost abusive past that we all have when it comes to using these chatbots because these chatbots don't have any sort of real memory from conversation to conversation. And so, we're always scared to death of having to exit out of a chat window or exit out of a terminal session because you think, "Oh my gosh, it's not going to remember my conversation." And this is actually a real problem because what is everybody's answer to the chat window not being able to remember anything? Well, the answer is you just keep that conversation going forever because you don't want to get to a scenario where you have to exit out and it forgets everything. This is a fear that is born here inside of these chat windows, beginning with ChatGPT, and same thing with Claude's web app. And honestly, it used to be infinitely worse with Claude's web app because I think we all remember before the days of the 1 million context window where you would have like 30 minutes to talk with Claude and be like, "Well, see you in four hours." The issue is people have brought that sort of psychotic neurotic behavior to the terminal. And what they do in large part because you now can get away with it with a 1 million context window is they never clear. They just keep talking and talking and talking with Claude code because they never want it to forget what they're talking about because of these memory problems. And the issue with that is your efficiency goes way down over time the more you talk with Claude code inside of the same session. And this is the fundamental idea of context rot. If you don't know what context rot is, it's the phenomenon that the more I use an AI system within its same session, within its same chat, and I fill up that context window, the worse it gets. You can see that right here. Claude code 1 million context window at 256k tokens. Aka I've only filled up about a quarter of its context window. We're at 92%. By the end, I'm at 78%. So, the more you use it in the same chat, the worse it gets. And that's one of the primary issues people have with AI systems and memory. I have Claude code. It has a million contexts now. And yet, I do not want it to forget about the conversation I'm having. So, I just never exit the window. I just fill it up and fill it up and fill it up. And two things happen. One, effectiveness goes down, like you just saw. Two, your usage fills up a ton. Because the amount of tokens that are used at 1 million at 800,000, you know, context is way more than at 80,000 context. So this isn't the only issue, but kind of off-topic, we in a current ecosystem where everyone complains about Claude code being nerfed and my usage just gets run up automatically. There's a number of reasons for that, but one of them undoubtedly is the fact that since 1 million context got introduced, people have no clue how to manage their own context window. And they aren't nearly, they aren't nearly as aggressive with clearing and resetting the conversation as often as they should. But that's kind of off-topic. The point of that whole discussion is that when it comes to memory in this discussion about RAG in Claude code, we have to keep context rot in the back of our mind because we're constantly trying to deal with this tension of, okay, I want to ingest context so Claude code can answer questions about a number of things, yet at the same time, I don't want the context to get too large because then it's worse. So we just, that always needs to be something we're thinking about in this conversation about memory.

But to bring this back to the actual video in level one, what are people doing at level one? The answer is they're not really doing anything. And because they're not doing anything, they just rely on a bloated context window to remember things. So you know you're here when you've never edited a Claude.md file and you've never created any sort of artifact or any sort of file that allows Claude code to realize what the heck is going on, what it's actually done in the past, and what it needs to do in the future. So what do we need to master at this level? Well, really all you really need to master, despite everything I've wrote here, is you just need to understand that auto-memory isn't enough and we need to take an active role when it comes to Claude code and memory because a trap at this level, if you don't take an active role, you have no control. And we need to control what Claude code considers when it answers our questions. And so to unlock level one and move on to level two, we need memory that's explicit and we need to figure out how to actually do that. What files do you need to edit and understand that they even exist in order to take an active role in this relationship?

Now, level two is all about one specific file, and that is the Claude.md file. When you learn about this thing, it feels like a godsend. Finally, there is a single place where I can tell Claude code some rules and conventions that I always wanted to follow, and it's going to do it. And in fact, I can include things that I wanted to remember, and it always will. And it definitely feels like progress at first. So here's a template of a standard Claude.md file for a personal assistant project. Now, Claude code is going to automatically create a Claude.md file, but you have the ability to edit this or even update it on demand by using a command like slash init. And the idea of this thing is, it is again like the holy grail of instructions for Claude code for that particular project. For all intents and purposes, Claude code is going to take a look at this before any task it executes. So if you wanted to remember specific things, what are you going to do? You're going to put it in the Claude.md, theoretically. It's a bit smaller scale than something like RAG, you know, we aren't putting in, you know, complete documents in here, but it's things you want Claude code to always remember and conventions you want it to follow. So for this one, we have an about me section. We have a breakdown of the structure of the file system and how we want it to actually operate when we give it commands. And like I said, because this is referenced on essentially every prompt, Claude code is really good at following this. So the idea of like, hey, I wanted to remember specific things. This seems like a great place to put it. But we got to be careful because we can overdo it.

When we look at studies like this one, evaluating agents.md, and you can swap agents.md for Claude.md, they found in the study that these sort of files can actually reduce the effectiveness of large language models at large. And why is that? Well, it's because the thing that makes it so good, the fact that it's injected into basically every prompt, is what also can make it so bad. Are we actually injecting the correct context? Have we pushed through the noise and are we actually giving it a proper signal? Or are we just throwing in things that we think are good? Because if it isn't relevant to virtually every single prompt that it's going to do in your project, should it be here in the Claude.md? Is this a good way to let Claude code remember things? I would argue no, not really. And that goes contrary to what a lot of people say about Claude.md and how you should structure it. Based on studies like that and based on personal experience, less is more. Context pollution is real. Context rot is real. So if something is inside of Claude.md and it doesn't make sense for, again, virtually every single prompt you give it, should it be in there? The answer is no. But most people don't realize that and instead they fall into this trap of a bloated rule book. Instead, the skills we should be mastering are: how do we create project context that is high signal? How do I make sure what I'm actually putting inside this thing makes sense? And with that comes the idea of context awareness, like we talked about in the last level. And you take all that together, and level two feels like you've been moving forward, like, hey, I'm taking an active role in memory. I have this Claude.md file. You realize it's not really enough. And when we talk about level three and what we can do to move forward there, we want to think about sort of not a static rule book, but something that can evolve and it's something that can include Claude.md instead of relying on Claude.md to do everything. What if we use Claude.md as sort of like an index file that points Claude code in the right direction instead?

So what did I mean about Claude.md acting as sort of an index and pointing towards other files? Well, I'm talking about an architecture within your codebase that doesn't just have one markdown file trying to deal with all the sort of memory issues in the form of Claude.md. I'm talking about having multiple files for specific tasks. I think a great example of this in action is sort of what GSD, the get done orchestration tool, does. It doesn't just create one file that says, hey, this is what we're going to build and these are the requirements and this is what we've done and where we're going. Instead, it creates multiple. You can see over here on the left, we have a project.md, a requirements.md, a roadmap, and a state. So the requirements exist. So Claude code always knows and has memory of what it's supposed to be building. The roadmap breaks down what exactly we are going to be creating, not just now, but what we've done in the past and in the future. And the project gives it memory, gives it context of what we are doing at a high-level overview. What is our north star? And by breaking up memory and context and conventions in this sort of system, we're fighting against the idea of context rot and the idea brought up in that study, which is injecting these files into every prompt all the time, like we do in Claude.md, it's actually counterintuitive. This doesn't help us get better outputs. Furthermore, breaking it down into these chunks and having a clear path for Claude code to go down and says, like, hey, I want to figure out where this information is. Oh, I go to Claude.md. Oh, Claude.md says, "These are my five options." Okay, here's that one. Let me go and find it. That sort of structure is what you're going to see 100% in the follow-on level when we talk about Obsidian. And really is sort of like a crude reimagining of the chunking system and the vector similarity search that we see in true RAG systems. But obviously, this is kind of small scale at this level. We're talking about four markdown files here. We're not talking about a system that can handle thousands and thousands and thousands of documents. But like you're going to hear me talk about a lot, what does that mean for you? Do you need a system that we're going to talk about in levels four, five, six, seven that can handle this many documents? The answer is maybe not. And so part of this RAG journey is understanding not just where you stand, but like where do you actually need to go? Do you always need to be at level seven and know how to do an agentic RAG system of Claude code? It's probably good to know how to do it, but it's also just as good to know when you don't need to implement that. Sometimes what we see in these systems like this is enough for a lot of people. So it's just as important to know how to do it and to know like, do you need to? Should you do it?

When we talk about level three and we talk about state files, how do we know we're here? Well, we know we're here when we're still strictly inside the Claude code ecosystem. We haven't integrated outside tools or applications, and really, we're just at the place where we're just creating multiple markdown files to create our own homemade sort of like memory chunking system. But this still is really important. We're still mastering some true skills here. The idea of like actually structuring docs, having some sort of system in place that updates state at every session because this is can be a problem with RAG too. Like, how do you make sure everything is up to date? And chances are, you're also starting to lean into orchestration layers at this point. Things like GSD and superpowers that do things like this, this multi-markdown file architecture on their own. But there is a real trap here. What we create in this project is very much just for that project. It's kind of clunky to then take those markdown files and shift them over to another project.

So level four is where we bring in Obsidian. And this is a tool that has been getting a ton of hype, and for good reason. When you have people like Andrej Karpathy talking about these LLM knowledge bases they've created, which are built for all intents and purposes on an Obsidian foundation, it's getting almost 20 million views. We should probably listen and see how this is actually operating. Now, for context, I've done a full deep dive on this Obsidian Andrej Karpathy LLM knowledge base. I'll link that above. So, if you want to focus on that, how to build that, make sure you check that out above. And what I also want to mention to most people is that this Obsidian thing we're going to talk about right here in level four, this is honestly the level most people should strive for because this is enough for most people in most use cases. When we talk about levels five, six, and seven, we're going to talk about true RAG structures. And to be honest, it's overkill for most people. This is overkill for most people. Like, we love talking about RAG. Like, it's great. I understand that. But Obsidian is that 80% solution that in reality is like a 99% solution for most people because it's free. There's basically no overhead. And it does the job for the solo operator. And when I say does the job for the solo operator, I mean it solves the problem of having Claude code connected to a bunch of different documents, a bunch of different markdown files, and being able to get accurate, timely information from it, and having insight to those documents as the human being. Because when I click on these documents, it's very clear what is going on inside here. And it's very clear what documents are related to it. When I click these links, I'm brought to more documents. When I click these links, I'm brought to more documents. And so for me as the human being, having this insight is important because to be totally honest, the Obsidian-based insight to the documents, I would argue trumps a lot of the insight you get from the RAG systems. When we talk about thousands and thousands of documents being embedded in something like a graph RAG system, like this looks great visually, looks very stunning. Do you actually know what's going on inside here? Maybe you do. To be honest, you're kind of just relying on the answers you get that we'll show and the and the links and stuff, but it's a bit hard. It's like piecing through the embeddings for sure. All that to say is you should pay special attention to Obsidian and Claude code because when we talk about this journey from RAG, I always suggest to everybody, clients included, like, let's just start with Obsidian and see how far we can scale this and eventually, if we do hit a wall, you can always transition to more robust RAG systems. So, why not try the simple option? If it works, great. It's free. Cost me no money versus like, let's try to knock out this RAG system, which can be kind of difficult to put into production depending on what you're trying to do. Like, always start with the simple stuff. It's never too hard to transition to something more complicated.

So, what are we really talking about here in level four? What we're talking about taking sort of that structure we began to build in level three, you know, with an index file pointing at different markdown files and just scaling that up and then bringing in this outside tool Obsidian to make it easy for you, the human being, to actually see these connections. And the platonic idea of this version is pretty much what Andrej Karpathy laid out in building an LLM knowledge base on top of Obsidian and powered by Claude code. And what that looks like is a structure like this. So when you use Obsidian and you download, it's completely free, again, referenced that video I posted earlier. You set a certain file as the vault. Think of the vault as sort of like the RAG system, this quasi RAG system you've created. And inside of the vault, we then architect that. We structure that just with files. So we have the overarching file called the vault. And inside that vault, we create multiple subfolders. In Andrej Karpathy's case, he talks about three different subfolders. The reality is they could be any subfolders. It just sort of needs to match the theme. We're going to talk about. In one folder, we have the raw data. This is everything we are ingesting and eventually want to structure so that Claude code can reference it later. Think of, you know, you have Claude code do competitive analysis on 50 of your competitors and it pulls 50 sites for each, right? We're talking about a large amount of information. It's probably 2500 different things. All that will get dumped into some sort of raw folder. This is like the staging area for the data. We then have the wiki folder. The wiki folder is where the structured data goes. So we then have Claude code take this raw data and structure it into essentially different like Wikipedia type articles inside of the wiki folder. Each article gets its own folder. So the idea being when you then ask Claude code information about, you know, let's say we had it search for stuff about AI agents and I say, "Hey Claude code, talk to me about AI agents." It's the same way you would query a RAG system. Well, Claude code is going to go to the vault. From the vault, it's going to go to the wiki. The wiki has a master index markdown file. Think of sort of what we were doing with talked about doing with Claude.md before, right? You see how these sort of themes transition throughout the different levels. It takes a look at that master index. The master index tells it what exists in this Obsidian RAG system. Oh, AI agents exist. Cool. Guess what's going on down here? It also has an index file which talks about the individual articles that exist. What am I saying here? I am saying there is a clear hierarchy for Claude code to reference when it wants to find information about files: vault, wiki, index, article, etc. So, because it is so clear how to find information and also why it's so clear to first find information, then turn into wiki, we can create a system that has a lot of documents without RAG, hundreds, thousands, if you do this properly. Because if the system is clear, hey, I check the vault and I check the index, and that has a clear delineation of like where everything is, well, then it's not too hard for Claude code to figure out where to find stuff. And so you can get away with a non-RAG structure for thousands of documents, and it's been really hard to do that in the past. And that's because most people don't structure anything with any sort of structure. They just have a billion documents sitting in one folder. It's the equivalent of having 10 million files strewn across the factory floor and being like, "Well, Claude code, find it." Like, no, you actually just need a filing cabinet. Like Claude code's actually pretty smart. And you can see that architecture in action right here. So, right now, we're looking at a Claude.md file that is in an Obsidian vault. And what does it say? Breaks down the vault structure, the wiki system, you know, the overall structure of the subfolders and how to essentially work it. Right? So again, we're using Claude.md as a conventions type file. Over here on the left, you can see the wiki folder. Inside the wiki folder is a master index and it lists what is inside of there. In this case, there's just one article. It's on Claude managed agents. Inside that folder, we see Claude managed agents. It has its own wiki folder breaking down the articles inside until you get to the actual article itself. So very clear the steps it needs to take. And so when I tell Claude code, "Talk to me about the managed agents," we have a wiki on it. It's very easy for it to search for it via its built-in GPT tool. It links me the actual markdown file and then breaks down everything that's happening.

Now, the question at level four really becomes a level of scale. How many documents can we get away with where this sort of system continues to work? Is there a point at which Andrej Karpathy's system begins to fall apart where, hey, like, I get it, there's a very clear path that Claude code needs to follow, goes to the indexes, yada yada yada, does that sustain itself at 2,000 documents, 2500, 3,000? Is there a clear number? The answer is we don't really know and there isn't a clear number because all your documents are also different. And in terms of hitting a wall, it isn't just as simple as, well, Claude code's giving us the wrong answers, it has too many files in the Obsidian system. How much is it costing you in terms of tokens now that we've added so many files, and how quickly is it doing it? Because RAG can actually be infinitely faster and cheaper in certain situations. What we're looking at here is a comparison between textual LLMs, right, in the giant bars, and textual RAG in terms of the amount of tokens it took to get the correct answer and the amount of time it took to get that answer. What do we see here? We see that textual RAG versus textual LLMs, there's a massive difference to the tune of like 1,200 times. I'm saying RAG is 1,200 times cheaper and 1,200 times faster than textual LLM in these studies. Now, context, this was done in 2025. This was not done with Claude code. These models have changed significantly since then. These are just straight up LLMs. This isn't a coding artist, etc., etc., etc. However, we were talking a 1,200x difference. So, when we're evaluating, hey, is Obsidian what I should be doing versus is should I be doing RAG system? It isn't as simple as just, well, it's giving the right answer or not, because you could be, you could have a scenario where you get the right answer with Obsidian, yet if you went to RAG, it's a thousand times cheaper and faster, right? So it's this very fuzzy line between when is Obsidian good enough and these sort of like just markdown file architectures good enough, or when like we need to use RAG. There's not a great answer. I don't have a great answer for you. The answer is you have to experiment and you need to try both and see what works because this is frankly out of date, totally, like 2025 older models. The difference between RAG and textual LLM is not 1,200 times. But how much has that gap shrunk? Because that is an insane gap. That isn't like 10x. It's 1,200x. The so there's a lot you have to know and again, you, you, you won't know the answer ahead of time. You just won't. Watch every video you want. No one's going to tell you where that line in the sand is. You literally just need to experiment and see what works for you as you increase the amount of documents you're asking Claude code to answer questions about.

So on that note, let's move on to level five, which is where we finally begin to talk about real RAG systems and talk about some of the RAG fundamentals like embeddings, vector databases, and how data actually flows through a system when it becomes part of our RAG knowledge base. So let's begin by talking about naive RAG, which is the most basic type of RAG out there, but it provides the foundation for everything else we do. Now, you can kind of think of RAG systems being broken out into three parts. On the left-hand side, we have the embedding stage. We then have the vector database, and then we have the actual retrieval going on with the large language model. So one, two, and three. And to best illustrate this model, let's start with sort of the journey of a document that is going to be part of our knowledge base. Remember, in a large RAG system, we could be talking about thousands of documents, and each document could be thousands of pages. But in this example, we have a one-page document that we're talking about. Now, if we want to add this document to our database, the way it's going to work is it's not going to be ingested as a whole unit. Instead, we are going to take this document and we are going to chunk it up into pieces. So, this one-pager essentially becomes three different chunks. These three chunks are then sent to an embedding model. And the job of the embedding model is to take these three chunks and turn it into a vector in a vector database. Now, a vector database is just a different variation of your standard database. When we talk about a standard database, think of something like an Excel document, right? You have columns and you have rows. Well, in a vector database, it's not two-dimensional columns and rows. It's actually hundreds, if not thousands of dimensions. But for the purposes of today, just think of a three-dimensional graph like you see here. And the vectors are just points in that graph. And each point is represented by a series of numbers. So you can see here we have bananas. And bananas is represented by 0.52, 5.12, and then 9.31. You see that up here. Now that continues for hundreds of numbers. Now, where each vector gets placed in this giant multi-dimensional graph depends on its semantic meaning. What, what do the words actually mean? So you can see over here, this is like the fruit section. We have bananas, we have apples, we have pears. Over here, we have ships and we have boats. So going back to our document, let's imagine that this document is about World War II ships. So each of these chunks is going to get turned into a series of numbers, and those series of numbers will be represented as a dot in this graph. Where do you think it's going to go? Well, they'll probably go around this area, right? So that would be one, two, and three. So that's how documents get placed. Every document is going to get chunked. Each chunk goes through the embedding model, and the embedding model inserts them into the vector database. Repeat, repeat, repeat for every single document. And in the end, after we do that several thousand times, we get a vector database, which represents our knowledge graph, so to speak, our knowledge base. And that moves us on to step three, which is the retrieval part.

So, where do you play into this? Well, normally, let's, let's depict you. Well, we'll give you a different color. You can be you get to be pink. So, this is you. All right. You normally just talk to Claude code and you ask Claude code questions about World War II battleships. Well, in your standard non-RAG setup, what's going to happen? Well, the large language model, Opus 4.6, is going to take a look at its training data, and then it's going to give you an answer based on its training data, information about World War II battleships. But with a RAG system, it's going to do more. It's going to retrieve the appropriate vectors. It's going to use those vectors to augment the answer it generates for you. Hence, retrieval augmented generation. That's the power of RAG. It allows our large language models to pull in information that is not a part of its training data to augment its answer. In this example, World War II battleships. Yes, I understand the large language model already knows that, but replace this with any sort of proprietary company data that isn't just available for the web, and do it at scale. That's the sell for RAG. Now, in our example, when we ask Claude code for questions for information about World War II battleships and it's in a RAG setup, what it's going to do is it's going to take our question and it's going to turn our question into a series of numbers, similar to the vectors over here. It is then going to take a look at what the number is for our question and the numbers of the vectors and it's going to see which of these vectors most closely matches the question's vector. Right? How similar are the vectors to the question, pretty much? And then it's going to pull a certain amount of vectors, whether that's one, two, three, four, or five, or 10, or 20. And it's going to pull those vectors and their information into the large language model. So now the large language model has its training data answer plus say, 10 vectors worth of information. Right? That was the retrieval part, and then it augments and generates an answer with that additional information. And that is how RAG works. That is how naive RAG works.

Now, this is not particularly effective for a number of reasons. This very basic structure kind of falls apart at the beginning when we begin to think about, okay, how are we chunking up these documents? Is it random? Is it just off a pure number of tokens? Do we have a certain number of overlap? Are the documents themselves set up in a way where it even makes sense to chunk them? Because what if, you know, chunk number three is referencing something in chunk number one, and in our vector situation, when we pull the chunks, what if it doesn't get the right one? What if it doesn't get that other chunk that's required as context to even make sense of what number three says? You get what I'm saying? Like, very often, the entire document itself is needed to answer questions about said document. So this idea of getting these piecemeal answers doesn't really work in practice yet. This is how RAG was set up for a long, long time. Other issues that can come into play are things like, what if I have questions about the relationships between different vectors? Because right now, I kind of just pull vectors in a silo, but what if I wanted to know how boats related to bananas? Sounds random, but what if I did? You know, this standard sort of vector database naive RAG approach. Everything's kind of in a silo. It's hard to connect information, and a lot of it just depends on how well those original documents are even structured. Are they structured in a manner that makes sense for RAG?

Now, over the years, we've come up with some ways to alleviate these issues. Things like rerankers or ranking systems that take a look at all the vectors we grab and essentially then do another pass on them with a large language model to rank them in terms of their relevance. But by and large, this naive RAG system has kind of fallen out of vogue. Yet, it's still important to understand how this works at a foundational level so it can inform your decisions if you go for a more robust RAG approach. Because if you don't understand how chunking or embeddings even work, how can you make decisions about how you should structure your documents when we talk about something like graph RAG, or we talk about more complicating embedding systems like the brand new one from Google, which can actually ingest not just text, but videos. And if you don't understand this sort of foundation, it's hard for you to actually understand this trap. And the trap is that we've kind of just created a crappy search engine because with these naive RAG systems where all we do is grab chunks and we can't really understand the relationships between them, how is that different from basically just having an overcomplicated control F system? The answer is there's really not much of a difference. Which is why in these simple, when in these simplistic kind of outdated RAG structures that actually are still all over the place, if you see someone who's like, "Oh, here's my Pinecone RAG system," or "Here's my Superbase RAG system," they don't mention anything about graph RAG, or they don't mention anything about like, "Hey, here's how we have like the sophisticated reranker system," and they, it's going to suck to the tune of like, "Oh, the actual effectiveness of this is like 25% of the time you get something right." Like, you're almost better guessing. So if you don't know that going in, you can definitely be sort of hoodwinked, or confused, or in some cases, like, basically scammed into buying these RAG systems that do not make sense. And so level five isn't about implementing these sort of naive RAG systems. It's about understanding how they work so that you, when it comes time to implement something more sophisticated, you actually understand what's going on. Because that five-minute explanation of RAG is sadly not something most people understand when they say, "I need a RAG system." Well, do you? Because you also have to ask yourself, what kind of questions are you actually asking about your system? If you're just asking, you know, essentially treating your knowledge base as a giant rulebook and you just need specific things from that knowledge system brought up, well, then Obsidian is probably enough, or you could probably even get away with a naive RAG system. But if we need to know about relationships, if we need to know about how X interacts with Y, and they're two separate documents, they never even really mention each other, and it's not something I can just stick inside the context directly because I have thousands of said documents. Well, that is when you're going to need RAG, and that's when you're going to need something more sophisticated than basic vector RAG. That is when we need to start talking about graph RAG.

So when we talk about level six of Claude code and RAG, we're talking about graph RAG, and we're talking about this. And in my opinion, if you are going to use RAG, this is sort of the lowest level of infrastructure you need to create. This is using Light RAG, which is a completely open-source tool. I'll put a link above where I break down exactly how to use it and how to build it. But the idea of graph RAG is pretty obvious. It's the idea that everything is connected. This isn't a vector database with a bunch of vectors in a silo. This is a bunch of things connected to one another. Right? I click on this document. I can see over here on the right, and I'll move this over, you know, the description of the vector, the name, the type, the file, the chunk, and then more importantly, the different relationships. And this relationship-based approach results in more effective outcomes. Here is a chart from Light RAG's GitHub. This is about, I would say, six to eight months old. And also of note, Light RAG is the lightest weight graph RAG system out there that I know of. There's some very robust versions, including graph RAG itself from Microsoft. It's a graph, it's literally called a graph RAG. But when we compare naive RAG to Light RAG, across the board, we get jumps of often times more than 100%. Right? 31.6 versus 68.4, 424 versus 76, 24 versus 75, on and on and on. And that being said, according to Light RAG, it actually holds its own and beats out graph RAG itself. But hey, these are Light RAG's numbers, so take them with a grain of salt.

Now, when we look at this knowledge graph system, right away your mind probably goes to Obsidian because this looks very similar. However, what we're looking at here in Obsidian is way more rudimentary than what's going on inside of Light RAG or any graph RAG system because this series of connections we see here, this is all manual and somewhat arbitrary. It's only connected because we set related documents or Claude code set related documents when it generated this particular document. For example, just added a couple brackets, boom, that document's connected. So, in theory, I could connect a bunch of random documents that in reality have nothing to do with one another. Now, because Claude code isn't stupid, it's not going to do that. But that's a lot different than what went on here. Like, this went through an actual embedding system. It looked at the actual content. It set a relationship. It sent an entity. There's a lot more work going on here inside of Light RAG in terms of defining the relationships than Obsidian. Now, does that difference actually equate to some wild gap in terms of the performance at a low level? No. At a huge scale, maybe. Again, we're in sort of that gray area. Kind of depends on your scale and what we're actually talking about. And nobody can answer that question except you and some personal experience. But understand these two things are not the same. We are not the same, brother. Two totally different systems. One is pretty sophisticated. One's pretty rudimentary. Understand that.

And so to wrap up level six in graph RAG, we're really here when we've decided, hey, stuff like Obsidian isn't working. We can't use something like naive RAG because it just doesn't work. And we need something that can extract entities and relationships and really leverage the sort of hybrid vector plus graph query system design. But there are some traps. There are some serious roadblocks. Even here at level six, when we talk about Light RAG, this is just text. What if I have scannable PDFs? What if I have videos? What if I have images? We don't live in a world where all your documents are just going to be Google Docs. And so what do we do in those instances? So multimodal retrieval is a huge thing. And on top of that, what about bringing some more agentic qualities to these systems? Give it a little more AI power, some sort of boost in that department. Well, if we're talking about things that are multimodal, then we can finally move to sort of like the bleeding edge of RAG in today's day and age, as of April 2026. And that's what level seven's all about.

Now, when we talk about level seven in agentic RAG, the big thing we kind of want to index on here is things that have to do with multimodal ingestion. Now, we've done videos on these things, things like RAG Anything, which allow us to import images and non-text documents, again, think scannable PDFs, into structures like the Light RAG knowledge graph you saw here. We also have new releases like Gemini Embedding 2, which just came out in March, which allows us to actually embed videos into our vector database, videos itself. And this is frankly where the space is going. It's not enough to just do text documents. How much information, how much knowledge is trapped on the internet, especially on places like YouTube, where it's just purely video, and we want more than just a transcript as well. A transcript doesn't do enough. So, this sort of multimodal problem is real. And again, this is stuff that just came out weeks ago. And level seven is also where we need to start paying attention to our architecture and pipelines when it comes to the data going in and out of our.

rag system. It's not enough to just get data in here. Like this is great, you know, okay, we have all these connections and stuff. How does the data getting there? How is the data getting there in the context of a team? How is data getting out of there? Like what if some of the information here has changed in a particular document? What if somebody edits it? How does it get updated? What if we had duplicates? Who can actually put these things in there? When it comes to production level stuff, these are all questions you need to begin to ask yourself.

And so when we look at an agentic rag system like this one from NAND, you can see the vast majority of the infrastructure, everything outlined here is all about data ingestion and data syncing. There's only a very small part that has anything due to rag, which is right there. Because we need systems that clean up the data, that are able to look at, okay, we just ingested this document. In fact, this was version two of version one. Can we now go back and clean that data? Here's something like a data ingestion pipeline where documents don't get directly put into the system or in light rag. We instead put it inside of like a Google drive and from there it gets ingested into the graph rag system and logged. These were the sort of things that will actually make or break your rag system when you're using it for real.

And when we talk about a gentic rag, you can see here, and I know this is rather blurry, but if we have an AI agent running this whole program, so you set up, imagine some sort of chatbot for your team. Does it always need to hit this database? The answer is probably not. Chances are in a team setting, in a business setting, you're going to have information that's in a database like this like text or something, but you probably also have another set of databases like just standard Postgress databases with a bunch of information you want to query with SQL as well. So when we talk about in a gentic rag system, we need something that has all of that. The ability to intelligently decide, oh, am I going to be hitting the graph rag database represented here or am I just going to be doing some sort of SQL queries in Postgress? These things can get complicated, right? And all of this is use case dependent, which is why it's kind of hard to sometimes make these videos and try to hit every single edge case. The point here at level seven is not that there's necessarily some super rag system you've never heard of. It's that you're actually the devil's in the details here. And that's really mostly the data ingestion piece and keeping it up to date, but also like how do you actually access this thing? Easy to do in a demo right here. Oh, we just go to the light rag thing and I go to retrieval and I ask it questions. Different scenario when we're talking about it with a team and everyone's approaching it from different angles and you probably don't want everyone to have access to actually uploading it to light rag itself on a web app.

That being said, for the solo operator who is trying to create some sort of sophisticated rag system that is able to do multimodal stuff, I would suggest the rag anything plus light rag combination. I've done a video on that and I'll if I haven't linked it already, I'll link it above. I suggest that for a few reasons. One, it's open source and it's lightweight. So, it's not like you're spending a bunch of money or time to spin something like this up to make sure it actually makes sense for your use case. Again, the the thing we want is we don't want to get stuck in systems where there's no way out and we spent a bunch of money to get there, which is why I do love Obsidian. And I always recommend things like light rag and rag anything cuz hey, if you try this out and it doesn't work for you and it doesn't make sense, okay, whatever. You wasted a handful of hours, you know, it's not like you are spending a bunch of money on Microsoft's graph rag, which is in no in no way is cheap.

And so when do you know you're in level seven? Really multimodal stuff like you need to index images, tables, and videos and you're integrating some sort of agent system where it can intelligently decide like which path it goes down to answer information because at level seven you're probably integrating all this stuff. You probably have a claude MD file with some permanent information. You probably have it in a codebase with some markdown files that sort of makes sense for easy retrieval. Perhaps you're also including Obsidian. It's in some sort of vault. Plus, you probably have some section of documents that are in a graph rag database and you have a top of the funnel AI system that can decide they ask this question, I go down this route. That's a mature sort of memory architecture that I would suggest. But what's the trap here? The trap honestly is trying to force yourself into this level and this sort of sophistication when it's just not needed. To be honest, after all this, most of you are fine with obsidian. This is more than enough. You don't need graph rag. You really don't need rag in general. And if it's not obvious that you need level seven, and certainly if you haven't already tried the obsidian route, you don't need to be here. It's probably a waste of your time.

But the whole point of this video was to the best of my ability was to expose you to what I see is the different levels of rag and memory and claude code and what this problem is, what some of the tensions are, what the tradeoffs are, and where you should probably be for your use case. And again, the biggest thing is just experiment. You don't have to know the answer before you get into this. Just try them out. And I would try in ascending order. If you can get away with just markdown files in a cloud system and it's basically just claw.md on steroids, sweet, go ahead and then try Obsidian. If Obsidian's not enough, try LightRag and so on and so forth. So, that is where I'm going to leave you guys for today. If you want to learn more, especially about the production side of Rag, like how to spin this up for a team or package it for a client, we have a whole module on that inside of Chase AI plus. So, check that out. Other than that, let me know what you thought. I know this was a long one and I will see you.