---
type: raw-transcript
title: "The EASIEST Possible Strategy for Accurate RAG (Step by Step Guide)"
youtube_id: z_LGan-t2Mo
url: https://www.youtube.com/watch?v=z_LGan-t2Mo
slug: the-easiest-possible-strategy-for-accurate-rag-step-by-step-guide
published: 2025-05-07
duration: "0:26:23"
fetched_at: 2026-07-21
immutable: true
---

## Transcript

**[0:00:00]** I have a very practical guide for you today covering a crucial strategy for making retrieval augmented generation more accurate. And it's all based around the idea of contextual retrieval introduced to us by the anthropic team. And it is so important. I cannot stress enough how important it is to understand

**[0:00:17]** these different strategies for making rag more accurate because if you want to build AI agents that can really leverage external knowledge like your documents effectively, you can't just implement basic RAG. Like in N8N, I have this example here showing you what a very basic RAG AI agent looks like. And rag

**[0:00:35]** is my go-to way to give external knowledge into my agents. Like in this case, I'm watching for files that are created or updated in Google Drive. That is my document source. And whenever that event happens, I'm extracting the text from that document and inserting it into my vector database. Like in this case

**[0:00:51]** I'm using Neon Postgress. It could be Superbase like I cover on my channel a lot or Quadrant. It's just some vector database where we're storing all of the information from our documents in a way that can be searched efficiently by our AI agents. And so now my agent at the

**[0:01:06]** top here has a tool to perform that lookup. And so for example, I can ask it what is our marketing strategy? And it's going to search through all this knowledge that I have transferred from my Google Drive into the vector representations here in our knowledge base. And sure enough, we get an answer

**[0:01:23]** based around this fake company that I have generated by Claude. This is what all of our documents are based around. And all of this information probably is coming from the marketing strategy meeting that we have right here. And so for example, if I scroll down, we can see that we have a community building

**[0:01:40]** strategy. And if I go and look at the answer here, and yep, we have a community building strategy as a part of the answer and some names that are mentioned here that we saw in the document. So it's using this document to aid in answering our question. That's

**[0:01:51]** the power of rag. But the problem is without some additional strategies like contextual retrieval that I'll cover in a little bit. This whole process is rather inaccurate. A lot of times it's not going to retrieve the necessary information from your knowledge base so it can actually answer the question.

**[0:02:08]** That's the biggest problem that we see. And so we need strategies to make sure that the large language model as it's accessing this knowledge base really understands the information that it's retrieving, how it relates to the rest of the knowledge base that it has. And that is something that contextual

**[0:02:25]** retrieval gives us. So in this article Anthropic shows us what contextual retrieval is, how to implement it, which we are going to use to build a better version of our rag agent in N8N. And then they also show some evaluations so that we can see with data backing it up

**[0:02:41]** that contextual retrieval does indeed make rag significantly more accurate. And I want to start with that even just to show you some of the results that we can expect with regular rag versus contextual retrieval. And so there are a few different strategies and some being combined together with all the different

**[0:02:58]** fancy colors that we see here. So on the far left hand side with this blue bar this 9.9% this means that with just regular rag like we're embedding the data no other additional strategies like contextual retrieval we have failed retrievalss 9.9% of the time as in about 10% of the time it doesn't actually

**[0:03:19]** retrieve the proper chunks from our knowledge base to aid the agent in answering our question properly. And as we start to add more strategies into our rag process, we can see the failure rate decline significantly. When we have all of these strategies combined together and I'm going to showcase the most

**[0:03:37]** important one in this video, we see the failure rate go from 10% all the way down to less than 3%. So 97% of the time, this rag lookup with these strategies is going to retrieve the right information from our knowledge base for our agent to be able to answer

**[0:03:52]** the user's question. That is a pretty accurate agent. And so contextual embedding, this is the one that I want to focus on in this video, show you how to implement in N8N and then later in Python as well. And this is really the backbone for what we see with these

**[0:04:08]** metrics here, all these other combinations of strategies. Contextual embedding is really the most important strategy. And so that's why I want to focus on this one with you right now. And that is what this article by Anthropic focuses on a lot. So scrolling down in this article, they start by

**[0:04:22]** introducing us to basic rag, which is what we already saw in N8N. So we have our corpus of documents, like that was Google Drive in our case. When we fetch new documents from our source, we're going to chunk them, create bite-sized pieces of information for all these documents. So we aren't overwhelming the

**[0:04:39]** LLM when we pull information from our knowledge base. And then we use an embedding model like we used openAI to create those vector representations of the knowledge to store in our vector database like Neon Postgress, Superbase Quadrant, all those vector databases. You can just use any of them. And then

**[0:04:56]** when we have the user query come in we're going to embed that as well. Use that to match against our knowledge base to find the most relevant chunks to aid the agent in answering our question. So that is basic rag like we already saw. And then when we add in contextual

**[0:05:12]** retrieval, we're just building on top of this process to provide some more context to help the LLM understand what these chunks represent, how they fit with our larger knowledge base as well. So kind of helping it zoom out a little bit, which is something that rag typically fails at because it's such a

**[0:05:29]** directed lookup. Sometimes you want to zoom out one layer just to have that extra context. And that is what we provide here. And so they introduce contextual retrieval. I'm just going to go right down to this diagram here to show what that looks like. So, we're still going to chunk our documents like

**[0:05:45]** we did with basic rag, but then for every piece of our document, every chunk, we're going to run a prompt where we're going to give it the entire document. And I'll show you what this prompt looks like. We give it the entire document. And then we give it the

**[0:06:00]** current chunk that we are processing. And we just give a very simple prompt asking it to give some more context around this chunk like where does it fit within the document? Maybe a brief description of what this chunk is all about. All that information just helps the LLM understand like when it

**[0:06:16]** retrieves this chunk from our knowledge base. What is it supposed to do with that? Like how is that chunk going to aid in answering the user's question? This helps rag more than you would think. Like it's crazy how even just like one or two sentences that we add at

**[0:06:29]** the start of each chunk, it improves our results significantly. So now after we run through this process, everything looks the same except that extra context is just prepended to the content of the chunk itself. And then we'll just embed those normally. And since I have my knowledge base built out already, I can

**[0:06:46]** show you right now what this looks like in practice. So I'll go back over to my database right here. I've just picked one random chunk from my knowledge base. since we can take a look at the text to see what this chunk looks like. And I'll show you next how to do this in N8N. But

**[0:07:00]** we have this triple dash separator that separates the extra context that we're prepending through contextual embedding from the contents of the chunk itself. And this isn't the most useful prepended text because it is just the start of the document. We're just telling it like this is the beginning of the document

**[0:07:16]** with the title, version, approval status, blah blah blah. And then we have the content itself. But especially as we get towards the middle of the document this extra context can be crucial because like I said, it allows us to zoom out and see how this chunk fits in

**[0:07:31]** with the rest of the document. We could even give information about what comes before or after this chunk in the document so that if the agent decides to research like perform rag again, maybe can alter the query to find some more information in other parts of the document. And that's just one example of

**[0:07:47]** how this extra context can be very very useful to the LLM and then it can just pull the regular content to actually aid in answering its question as well. So very very useful. So now with that I want to dive into how we build this out with N8N as an example for us here.

**[0:08:03]** Later in the video I'll show you how I built this with Python as well. But yeah NN is just a great way to visualize what this looks like. And you can see that compared to basic rag there's not that much more here. we just have an extra LLM call. That's most of the logic, but

**[0:08:17]** it's still going to, like we saw with those evaluations in the article improve our results pretty significantly. So, let me zoom in on this pipeline here. I want to show you how I built this, specifically focusing on the components that are related to contextual embedding. So, we start with

**[0:08:32]** our Google Drive triggers here where we're just watching every minute for any new files or updated files in this folder in Google Drive. So, I have this data pinned. This is a file that I added recently. Going to the right, it is the neural data privacy framework. This is

**[0:08:46]** the same file that I showed you, one of the chunks from within our Neon dashboard. And so the other thing with this is that we can send in more than one file at once. If we upload many files at the same time to Google Drive we need to make sure that we can handle

**[0:08:58]** all of them in a loop. So I have this loop node here. The rest of this flow is going to run for each individual file just one at a time. We set all the important metadata here that we need for our file like the ID, the type, the

**[0:09:11]** title, and the URL. And then to make sure that we have a blank slate when we're inserting this file, I'm going to delete all of the existing records for this file. Just so based on this file ID that we have in the metadata, I'm going to remove any of those records where

**[0:09:26]** that matches with the file ID that I just pulled from Google Drive. We want a blank slate. So now that when we insert in subsequent nodes here, we can guarantee that we don't have anything else left over from a previous version of the file if this whole thing was

**[0:09:39]** triggered from a file updated trigger. And then we're just going to download the file from Google Drive so that we can then extract the text from it. And this doesn't handle different file types like PDFs, but I do cover that in other videos on my channel. So check this

**[0:09:52]** video out here if you're interested in that. Right now I'm keeping it basic just to extract from text documents um like Google Docs for example like this file that we were looking at earlier. And so once we have the text extracted now we want to implement our chunking

**[0:10:06]** strategy. We have to split the documents into chunks before we can add any of that extra context. And so typically in N8N you will just use the text splitter node. When you implement rag it does all the chunking for you. But because we have to add custom information into each

**[0:10:22]** chunk, we need to just implement a little bit of uh simple custom JavaScript code here to do the chunking ourselves. And so it's a very basic chunking strategy. I didn't want to spend a lot of time making a robust one here when I want to focus on contextual

**[0:10:36]** embedding, but we're just splitting the document every 400 characters with no overlap. And you could adjust these parameters yourself, build out your own chunking strategy if you want to try to like respect paragraphs and sentences and things like that. That's outside of the scope of this guide here, though.

**[0:10:51]** So, we create all those chunks, and I'll even show you what that looks like. So I'm going to click on test step here. So, it'll go through this entire flow based on that pinned data that I have for the neural data privacy framework document. We extracted the text after

**[0:11:03]** downloading it from Google Drive. And now we have our chunks. And so, in this case, this document has six chunks. And so, there was about about 2,400 characters or whatever. So that's how based on this number right here, we got six chunks in total for this document. And then what we want to do after an N8N

**[0:11:21]** is we just want to take this and turn it into a list of chunks. And so at first it just starts as a single item. So it's a single item that it itself is an array, but we want to turn them into individual items within the n workflow

**[0:11:34]** which is what we're doing here. So, just a little bit of data massaging in the workflow because we want to work with each chunk one at a time because now we send it into this LLM that I'm literally just copy and pasting the prompt that we saw from this article from Anthropic.

**[0:11:51]** And so, I give it the full document and I'm saying here is the current chunk that I'm processing. Please give a short succinct context to situate this chunk. So, literally word for word the prompt that we had from Enthropic. I just wanted to show you that like I'm just

**[0:12:04]** taking their process and putting it into NAN for you so you can see exactly how this all works. So this is our big document that we have. Then this is the current chunk. And the biggest concern that we have here and I want to focus on this really quickly because we want to

**[0:12:19]** talk about cost as well. These prompts can get pretty big especially if your document is very large. But this is where we can take advantage of the idea of prompt caching. And they talk about this in the anthropic article. We can use prompt caching to reduce the cost of

**[0:12:36]** contextual retrieval. So with OpenAI for example, this is actually enabled by default. With other providers like Gemini and Enthropic, there's just a toggle that you can flip within your API request to enable it. Essentially what that means is when you are repeating the same tokens in a prompt over and over

**[0:12:53]** and over again, those tokens actually come at a reduced cost to you. So, we have to spend less money when we're sending this document in for every single chunk. So, we pay more for the first prompt, but then every prompt after because this piece of data in our

**[0:13:08]** prompt, like everything here is not changing, we're paying a lot less. For OpenAI, it's a 50% reduced cost. And then for Anthropic and I think Gemini as well, it's like a 90% reduced cost. And so, it is a lot cheaper. So, don't worry. Even though it seems like you're

**[0:13:23]** paying a lot more because you're sending in this entire document for every single chunk that you process, it actually is pretty affordable. And the other thing on top of this besides just taking advantage of prompt caching is that we can use a very small and cheap LLM to

**[0:13:40]** handle this part of our flow. Like I'll show you in this case that I am using GPT 4.1 Nano. So, I'm using the smallest model offered from OpenAI. It is dirt cheap and we don't need that much reasoning power here just to add that little bit of extra context for each of

**[0:13:57]** our chunks. And so we do have to run seven prompts where we are given the entire document all seven times. But because of prompt caching and a cheaper LLM, this whole thing is not that expensive. And so you can see now for our output that each of the data points

**[0:14:11]** that we have here is that extra context that we're going to prepend for each chunk. And so I'll show you that now. First, we just get the values that we need here, like the chunk and the text for each of our seven chunks. And so let me uh let that run here. It it's I

**[0:14:26]** should have pinned the data. Let me pin the data so I don't have to rerun that every single time. So, I'll pin the data for the output for this document. And then we can go into our Postgress node. And so, right now I have this hooked into Neon. You could hook this into

**[0:14:39]** Superbase as well. They both run Postgress under the hood. I'll talk more about that in a second. But what I want to do within my default data loader is instead of just loading all input data I'm going to go to the drop-own and load specific data. And then right here with

**[0:14:53]** a little bit of JavaScript, I'm creating that custom chunk where I'm starting with the text that was outputed from the LLM, that extra context. And then I have that triple dash separator that we saw in the Neon dashboard right here. And then I'm adding in the content of the

**[0:15:10]** chunk itself. And so we're doing this for every single chunk, adding in that extra context with our default data loader. And then we have all of our metadata here as well, like the file ID the title, and the URL, so that the LLM can also site its sources as it's doing

**[0:15:23]** these rag lookups. So that's everything for the default data loader. And we still have this character text splitter. But because we already chunk the documents ourself, this is never going to re-chunk because we just have a chunk size of 2,00 which is larger than the chunk size that we specified earlier.

**[0:15:40]** So, this is just not really going to ever run, which is good because we have to have this here in N8N. Like, there's not a way to make the text spplitter optional. Um, but it is using the chunking that we had right here for our custom implementation. And then I'm just

**[0:15:53]** using the text embedding three small OpenAI embedding model. That's what creates all those vector representations. Like going back to my tables here, when we have that embedding vector like I'm looking at right here this is created from that OpenAI model. So that is everything for this workflow. That is how we get all this data in a

**[0:16:12]** way where we have within each of these text fields, we have the context, the three dashes and then the content of the chunk itself. And so when the whenever the LLM retrieves one of these records it now has both pieces of information. And that definitely makes the whole

**[0:16:27]** process a lot more accurate. So the other thing that I want to hit on really quickly is my choice of database. So I typically cover superbase exclusively but here I've been using neon to access Postgress under the hood and since they do both use Postgress it's pretty interchangeable here you just have to

**[0:16:43]** change the underlying Postgress database that you are connected to but I wanted to show you here that there are other platforms available to you. So when Neon reached out to me to partner with me on this video I jumped at this opportunity because I wanted to show you that there

**[0:16:59]** are other platforms available and there are pros and cons to different ones. It's worth you doing the research to find the one that is right for you. And there definitely are some distinct advantages to using Neon over other platforms because it is serverless Postgress. And the biggest advantage to

**[0:17:14]** that is we have autoscaling. So the infrastructure for your database under the hood changes depending on the load to your database versus with other platforms you have to pay for a specific instance size and then you have to manage that scaling yourself which can definitely become a nightmare as you're

**[0:17:31]** scaling your application. And they have other really cool features like database branching so you can very easily manage and test different database schema changes and different environments like dev test and prod. Really really cool. And they even have an MCP server. And I've tested this out. It's very, very

**[0:17:47]** powerful. As you're building your applications with AI coding assistance you can with natural language manage your database to create new tables manage your records, do database migrations. Very, very powerful. So that's why I've been showing them throughout this video. It's a really good platform. And just like Superbase

**[0:18:04]** it's using Postgress under the hood. So it's going to be very, very familiar to you. Also, Neon literally powers Vzero and Replet and Highkey, one of the co-founders of Neon, has been contributing to Postgress for over 20 years. So, it is a platform with a strong foundation. I would highly

**[0:18:20]** recommend checking it out if you're interested in getting your database to a point where it is very very scalable. So, that is everything for our rag pipeline. Now, we can move on to our AI agent. But I did very intentionally spend most of the time in this guide

**[0:18:35]** talking about what we have here at the bottom because contextual retrieval really just happens in the rag pipeline. The AI agent itself is still a very basic implementation of rag. We just have a single tool to search the knowledge base. It's just now all the chunks that we get back are better

**[0:18:51]** because each one of them is prepended with that extra information to make them more useful to our AI agent. And so I've got a simple chat trigger here that gives us this chat in the bottom. I have the AI agent with a very simple system prompt just to get us started. And then

**[0:19:06]** I'm using OpenAI for the LLM just like I am for the embedding model, but you can obviously switch all these out pretty easily in N8N for whatever provider you want to use. I've got Postgress chat memory just like we're using Postgress to store our documents. And then within

**[0:19:20]** our tool for rag, I'm using the Postgress retrieve documents tool referencing that documents_pg table that we used in our pipeline. That's where we've been putting all of our documents as we've been chunking them and embedding them. And then I've got the description to tell my agent when and

**[0:19:35]** how to use this tool. And I'm limiting to the four most relevant chunks that it pulls from that lookup. And you could change this number to 10 or 20 something like that as well. And then the very last thing is I'm including metadata for things like the title and

**[0:19:49]** the URL that we added in our pipeline so that we have that extra information for our agent so it can do things like site its sources. And then the very last thing for the embedding model I'm just using the exact same one that we use in our pipeline. It's very important for

**[0:20:04]** both the agent and then also within the pipeline that you are using the same embedding model regardless of the provider that you are using for that. So with that, let's just give it a little bit of a test now. So I'm going to exit full screen. I'm going to go into my

**[0:20:17]** Google Drive. Let's just pick a random document because I have each one of these ingested into our knowledge base right here. So let's just open up the quarterly report from Q1. And then we'll pick some random thing just so we can verify the answer. We'll pick something here and then we'll ask it a question

**[0:20:34]** that it would need to grab some component here um to actually understand and answer that question. So let's say for example within the development process here the progress is uh 72% complete and so I could just ask it u in quarter 1 of 2024 how close were we to

**[0:20:51]** the to finishing the neural adaptation engine and so uh I don't know exactly which chunk that is within all the chunks we have in our knowledge base here but somewhere out of one of these dozens and dozens of or hundreds of chunks that we have we have that

**[0:21:06]** information stored and so I'm going to go back to the agent open up the chat and I'll say in Q1, how close were we to finishing the neural adaptation engine? All right. And so now we're going to use that tool. We're going to pull relevant chunks and we'll see in a second. Um

**[0:21:24]** actually, yeah, here it is. Progress is 72% completed against the 85% target. So it pulled that chunk. And then also we have what was prepended. So everything here is what we set up with contextual retrieval. This chunk details the current development status of the neural adaptation engine. Obviously, that is

**[0:21:42]** going to be pretty helpful to the agent to know because that literally relates directly to our question, which is sweet. So, yeah, we have the progress here. I'll go back into our chat and make sure. Yeah, here we go. The NAE was 72% complete against the 85% target. And

**[0:21:57]** obviously that was kind of throwing a lowball to the AI agent, but I just wanted to show you really quickly what this process looks like when the agent is using this tool and what it looks like to get those chunks back from Neon. Yeah, this is looking really, really

**[0:22:11]** nice. So I will have a link in the description to this workflow. Just take it for yourself. Bring it into your own rag agents with contextual embedding and contextual retrieval. It's very, very powerful stuff. And I want to keep making this better for you as well. Like if we go back to the Anthropic article

**[0:22:27]** we started with contextual embedding which from anthropics tests does reduce failure rate for rag by up to 35%. Which is crazy. But they talked about other strategies as well. Things like BM25 for hybrid rag where we have keyword search along with semantic search. They talked about re-ranking and things that I

**[0:22:44]** didn't want to dive into in this video because I wanted to just get you started with something very tangible. But we can definitely make the process even more accurate for our rag agents. And that's what I want to keep building out with you, continuing to make this better. But

**[0:22:57]** right now, we have something that is a good foundation and it's very tangible as well. Like, it's cool how we can go and look at the contents of each chunk and we can see that prepended text and and just visualize like how that helps our agent with that extra information

**[0:23:10]** that it needs. And speaking of making things better, I also implemented contextual retrieval in Python. And so if you're interested in NATM, this is for you. If you're interested in coding your AI agents, then I have you covered as well because I added contextual retrieval into my crawl for AI rag MCP

**[0:23:27]** server. So, I covered this in the last video on my channel. So, check out this video if you haven't yet cuz this MCP server is a gamecher. Essentially providing your own custom knowledge base that you can build up and crawl yourself into your AI coding assistants and AI

**[0:23:42]** agents. And so I've been having a blast building this and I'll probably even incorporate it into Archon, my AI agent builder. More on that in the other video if you want to check that out. But yeah this is a really awesome server and I added in contextual retrieval as well.

**[0:23:56]** So we are using Neon with the NN implementation. But now for this MCP server, I'm using self-hosted superbase but they're both running Postgress under the hood like we know. And clicking in we can see that we have the same kind of setup here. The prepended text from contextual embeddings and then the

**[0:24:10]** regular chunk itself. And it's the same deal for any of these rows that we click into. But now this is all built in Python instead of N8N. And you can check out all the code. This is a completely open- source MCP server. So you can see that if you want. I'll just show you

**[0:24:25]** really quickly one of the functions here to generate the contextual embeddings. And so this takes the full document as a parameter as well as the chunk. And then we have the same prompt that we saw in NAN where we give it the document and we give it the chunk and we're telling it

**[0:24:39]** to give those couple of sentences for extra context to prepen to our chunk. So we call OpenAI to do that and then we just build up this string in the same way where we have that extra context the triple dash separator and then the chunk itself. And that's pretty much it in a

**[0:24:54]** nutshell. There's obviously a little bit more code involved here in this utils.py pi script to make this all happen and add that all into our knowledge base. But you can definitely just check that out if you want. You can go to the source folder and then utils.py and dive

**[0:25:08]** into that if you are curious. Um yeah you could even take this code and paste it into your AI coding assistant to use it as an example for adding in contextual betting to your rag AI agents. So yeah, this is yet another resource for you. And I also just wanted

**[0:25:22]** to show you this because I am continuing to make improvements to this rag MCP server, probably integrating in Archon. Like I said, I've got some big plans for this. And so I'm just going to keep working on this as I cover more RAG strategies and chunking strategies and

**[0:25:36]** things on my channel as well. So that is everything that I have for you for now for contextual retrieval. And also I did a workshop recently in the Dynamis AI mastery community where I took contextual retrieval and I combined it with query expansion and a gentic rag. So creating a more powerful system

**[0:25:53]** combining multiple strategies together. So if that sounds interesting to you, or if you just want to dive into a lot of these things in a lot more detail with me, definitely check out dynamis.ai. And I'll be continuing to put out more content on my channel covering rag strategies and strategies

**[0:26:08]** around chunking as well. That is a super important thing that I want to hit on. So stay tuned for that. If you appreciated this video and you're looking forward to more things ra agents, I would really appreciate a like and a subscribe. And with that, I will see you in the next
