Kuba [0:23]:
My name is Kuba, I'm a deployed engineer at turbopuffer. For those who don't
know what turbopuffer is, we are a full-text search and vector search database
built from first principles on top of object storage. If you would love to learn
more, just come find me after the talk if you have any questions. So let's get
started. This talk is about how RAG is dead and how hybrid retrieval is becoming
the default for serious agentic search.
If you guys have been on Twitter or other social media platforms, or I guess X, they call it now, you might have seen a lot of tweets about how RAG is dead. There are lots of tweets, especially at the end of 2025 and in early 2026, about how RAG is dead and agentic file search is all we need. There's a lot of content about this now. Interestingly, if we look at something like Google search volume over the last couple of years, you can see that in 2023, as AI starts, we have this increase that caps out a little bit in 2024 and settles down for about a year. Then about midway through 2025, we hit this new inflection point where search volume just goes through the roof. So take that, Twitter.
Let's clarify first what RAG and agentic search are. These are the two terms a lot of people are throwing around these days. RAG, what a lot of people think RAG is, is just simple vector search. They think this is just embedding a corpus of content, passing an embedding vector, and getting it back, passing it through your LLM. At turbopuffer, we think this actually means, if we break down RAG into retrieval-augmented generation, retrieval is not just vector search. It's a lot of different things. It could be vector search, full-text search using stuff like BM25, grepping, globbing, using regex, and other basic filters. The augmented generation is obviously just passing it into your LLM of choice.
Now, agentic search is a term people are using a lot these days. Generally, when people talk about agentic search, they usually refer to a file system graph. If you guys are familiar with something like Cloud Code, a lot of people call this agentic search. Essentially, it involves graphing through your file system, which is why these terms are so correlated. What we believe it is, and the definition we want to give it, is really about giving agents a set of tools to progressively and iteratively find and reason over context. With Cloud Code, if you are familiar with it, it can read your file, start traversing your file system, read a file, decide that it hasn't found what it needed to complete the task, and then find something again. It keeps doing this until it reaches a happy state where it can continue on with the task.
Now, let's take a step back and talk about one of the companies that use turbopuffer, which we believe is doing an excellent job with agentic search. This company is called Cursor. You might have heard of them. Fun fact, they're actually one of turbopuffer's very first customers. They have this excellent blog post that came out at the beginning of 2026 about how they index codebases. For those unaware, when you open up a new codebase or a new branch in Cursor, what happens is that Cursor will start embedding your code. They chunk out your parse and embed your codebase, making it available for semantic search. This blog post goes into excellent technical detail about how they do this. Essentially, the cool thing they found is that most people working on a team, let's say there's a hundred engineers, when they open codebases, they're usually working on the same codebase 99% of the time. It's really expensive to have to re-chunk, re-embed, and re-upload these codebases every single time.
So they essentially use Merkle trees, which are crypto hash trees, to calculate similarities between codebases that people open on the same team. If they're similar enough, they will copy over the data and only update every chunk and re-embed the files that have changed, using turbopuffer to ensure this is done securely. It's just an excellent blog post; they do some really cool stuff. You may think this is a lot of work. Why do they do this? Well, the reason they do this is also covered in a different blog post about how they use semantic search. Again, they use turbopuffer for this. They find that on average, across models, there's about a 12.5% or 13.5% increase in answer accuracy across their internal Cursor context benchmark. This is not a public benchmark, but trust the numbers they give us. You can see on the right side their composer model, which is before Composer 2, had almost a 24% increase in answer accuracy. So giving semantic search to these tools and models can drive real performance gains.
On the bottom right, this is from an online A/B test they did, which is also covered in their blog posts, about how there's almost a 2.6% retention in large codebases and a 2.2% decrease in dissatisfied user requests. You might be thinking, "Oh, well, these numbers aren't that big; 2.6% and 2.2% are not that large." But they also cover that semantic search isn't used in every single query. In their online A/B test, if you give this tool to 100 random queries, not every query will actually benefit from the existence of a semantic search tool, which is why these numbers look kind of small.
Now let's talk a little bit about Cloud Code. Cloud Code doesn't use vector search, as covered by the suite from Boris Cherney. For those unfamiliar with Boris, he's essentially the founding father of Cloud Code. He says that in early iterations of Cloud Code, they actually did use RAG in a local vector DB, but they found that it just didn't really work out for them. This is something important to understand. It's something we've taken on a lot internally here at turbopuffer: this idea that embeddings and semantic search are kind of cache compute. You may be thinking, "Cache compute? You're throwing out a lot of terms at me right now; I don't know exactly what that means." I think it's best to walk through an example of a Cloud Code-looking trace and a Cursor-looking trace of how these agents will understand your codebase.
On the left is a per-session discovery of Cloud Code. For example, if we were to ask the agent to understand how metadata filtering works, it would have to grep, read, assess, and repeat, trying to find the files it needs to gain this understanding on a per-session basis. This means you can have 10 agents on 10 different days across 10 developers, and they can be asking the same question multiple times every day. Each time, the agent can repeat the same exact steps to gain the same understanding of this codebase, which can cost quite a few tokens. 6,000 doesn't seem like a lot here, but just remember this is one sub-step of an agent.
On the right is a more Cursor-looking trace, where there's this upfront cost of indexing, but then we're able to allow for this lightweight tool to help the agent retrieve this information at runtime. Obviously, there's this upfront cost of parsing the codebase, embedding it, and making it available, but this is a one-time cost. At runtime, the agent can just query something like, "How is metadata filtered?" and get some simple results. This saves a lot of tokens, time, and money, helping the agents become a lot faster. A lot of people on the team who were big Cloud Code users here at turbopuffer have actually started switching to Cursor just because of how fast it's becoming, especially with their Composer 2 models and the semantic understanding. It's just becoming really, really good.
So, from RAG to agentic retrieval. What we're finding now is that a lot of people are no longer doing the simple RAG, you know, the Twitter quote-unquote RAG of just bringing it back to search once and throwing it into the context windows. What we're finding is that this work, back in 2023 and early 2024, kind of the beginnings of AI, is that a lot of the more sophisticated customers are doing agentic search, which is giving real performance gains and unlocking new products. They're doing a ton of calls, reasoning through several steps, searching semantically or through full text as needed, and only fetching what's needed for that specific use case.
The important thing to know is that retrieval is no longer just this simple one-time call to a vector DB. It's becoming super iterative, and these agents are really understanding what they're searching for to understand more. It's kind of an interesting loop. You know, Google's Jeff Dean went on a show or podcast, and he had this really good quote that we like to use. He was talking about how Gemini's models were having these really big context windows. I forget the exact question the host asked him, but he said, "You don't need a trillion at once; you need the right million." This is something we think a lot about here at turbopuffer. We have customers that embed trillions of tokens inside turbopuffer, and as we see, the really important part is just getting down to the right 100,000, right 10,000, or right million in order to pass into these context windows.
That's about it for my talk. If you have any questions about any specifics, I'd love to either have them asked now or you can find me after the talk. I appreciate you guys coming out.
