Markdown source

Transcript: Benchmarking semantic code retrieval on Claude Code — Kuba Rogut, Turbopuffer

Source Video

Local Cache

Transcript

[music] >> Hi everyone. Welcome to benchmarking semantic search or semantic code retrieval on cloud code. My name is Kuba. I'm here from Turbo Puffer. For those unfamiliar with Turbo Puffer, we are a serverless full text and vector search database built from first principles on top of object storage. We serve some of the fastest growing AI companies in the world and if you'd like to know more about the talk or any question about Turbo Puffer or anything, just find feel free to find me after. So let's get started. So for those of you who are unaware, cloud code by default or I mean yeah, by default doesn't use semantic code search.

There's actually a tweet from Boris. Those unfamiliar with Boris, he's actually like the founding father of cloud code and he talks about how cloud the early versions of cloud code did actually use semantic search with a local vector DB, but they just kind of found agentic search which is actually you know, grepping through your file system kind of worked better and you know, seems to work simpler for for cloud code.

However, one of Turbo Puffer's customers actually fun fact, one of our very first customer is Cursor does use semantic code search and does index code bases into Turbo Puffer and you may think like this seems like a lot of work and it kind of is, but the reason they do this is because they see real performance gains because of this. They have this amazing blog post about their semantic search. They also have one about indexing code bases which I highly recommend as well.

But you can see on the right the kind of performance gains they see with their composer model is like 24% increase in relative improvement in answer accuracy and I think it's like 12 and a half or 13% across all models and you know, I this benchmark came up before composer two, but you can probably imagine there's some sort of similar performance gains with that that new model as well. And in the bottom right you can see this is from to the same blog post.

They talk about how in they perform an online AB test where they found that adding semantic either allowing or disallowing semantic code search led to like a 2.6% increase in code retention in large code bases and then 2.2% decrease in dissatisfied user requests. And you may also think like these numbers seem kind of small like what 2.6% 2.2%? Well, keep in mind that you know, out of 100 queries not all queries will ever really need semantic search or like benefit from it.

So these they even state in the blog post that these numbers look small because not every you know, you can imagine a very simple tool call or very simple query would not really use semantic search. So what we think about here at Turbo Puffer and why we kind of really think vector search and why Cursor probably sees this like real performance gain is we think about how embeddings are cache compute and you can also you know, what is what do you mean cache compute? This sounds like a bunch of baloney you're throwing at me.

You know, if we were like walk through like a cloud code trace and like a Cursor type trace of kind of the same thing, you can imagine that on the left side this kind of like a you know, grepping through the file system or what they call agentic search. How it just has like grep through this is for finding metadata filtering and understanding it in your code base.

That's essentially grep through, read the files, grep through more if it doesn't find the right things and again, this is repeated on every session across you know, every agent running in for the same code base so that even if you're asking the same question or trying to do the same thing multiple times, you always have to do this compute again and you can see like I mean in this case 6,000 tokens isn't a lot in one time, but across every session and every agent this really starts to add up.

And if we you know, on the right of this is more of a like like Cursor style or Cursor level trace where you have this upfront cost where you have to chunk embed and index the code base, but then you would essentially have this cache of the semantic meaning so that when a when a agent wants to understand you know, where or how does metadata filtering work, it can simply query you know, how is metadata filtered and get a lot get the chunks it needs and kind of the understanding it needs a lot faster and with token savings and again, this doesn't it's not a lot of savings in one time, but we all you know, we're not really running one agent anymore.

Like I'm running like three at one time. So there's definitely some long-term savings. So what we did is we built a simple CLI tool for cloud code. We call it Turbo Grep. It's essentially you can imagine it's just a simple way of using a tree splitter library to essentially parse through your code base, chunk it, embed it using the Voyage code model and then upload it to Turbo Puffer. This is just a simple file system walk through. There is an open source library for the V1 version and then soon the V2 version will be open sourced.

Here's a little video of example a tool call trace for a cloud code where you'll see it will call the T Puffer tool. Now it's called T Puffer search password reset token generator. This is in the Django repo. This is one of the repos I was testing it on and you can see that it gets the contents and then is able to kind of give the full explanation to the user. And you know, it's very easy to say like oh this works better, but the important thing is obviously benchmark it. Let's see for real what what how much better does it work?

Cursor has their own internal context bench and there's this paper this public paper called context bench where essentially the benchmark is not really testing whether or not the coding agent solved or didn't solve a problem. It tests when it in the process of solving the problem, did it find certain files? Did it find certain lines and it find certain symbols? Because they you know, they kind of have this this thesis that like it you know, it's also important how you get there not just like the end goal. The process really matters for understanding like are agents actually looking for the right files?

So essentially it's a human labeled data set of like in order to complete this task they the agent should have looked at this file, these few lines and these few symbols in order to like actually complete the task well. And I tested with three conditions. Essentially raw cloud code out of the box. Then I tested it with cloud code with a max of 50 line reads at a time and then the same thing with a windowed reads with the T Puffer search tool. You may ask me like why this like 50 line read thing limit? It's because it it became really noisy really fast if it's just reading like long files.

It's really hard to like understand and get a difference because it all if it just reads a whole like a thousand line file, it doesn't really make a lot of difference in the numbers. So we'll start with the first result of it. This is precision. Precision is essentially the the measure of of how many files did it read like in its total process? How many of them were actually golden files? So if there was if if cloud read 10 files and eight of them were needed, it hits 80% precision.

You can see the baseline it hit like 65% precision, 33% on line precision and 43% on symbol and it kind of goes up as we add windowed grep and then windowed grep plus semantic search got it to like 87% file precision for example. And this is also due to the fact like cloud code by default like it's a really exploratory. It loves to read as much as it can and like try to read everything for example and it kind of shows up in the 65% precision.

And you know, it's hard to like translate these numbers, but a more like English or like human version of it is that you know, cloud code one in every three file reads is actually just a completely wasted file and with windowed grep it was one in five reads was a irrelevant file and then with semantic search there's only one in eight files was a you know, quote unquote wasted or irrelevant file and it kind of like scales up as you kind of add these tools. And you know, obviously this this is already like pretty good. Then we have recall. Recall is essentially how many of the needed files did it find?

So for example, if there was 10 files in the task that it should have found, if cloud found five of them five files in its total trajectory and only three of them were actually these golden files, it would hit 30% recall. By default again, cloud code actually does win the file recall and again, part of this is because it just loves to explore every single file it can. Then we have line recall where it drops a lot more. This is kind of because it loved to read a lot of files, but also read to really read a lot of files that didn't have a lot of golden context lines.

So you can kind of see that even though it did explore a lot, it also kind of explored the wrong things a lot and then with grep and grep plus semantic or windowed grep and windowed grep plus semantic search kind of have the same recall. You can kind of see on the right like kind of the what happened with the behavior between these three conditions. And you may be thinking like well, you know, semantic search didn't really like add improvements here. Like what what went wrong? Like actually some decreases. And we can like dig in a little further into the recall numbers for certain tasks.

This is across 50 tasks by default, but if we break it down into where semantic search won you know, quote unquote won and where just like windowed grep won, we see some stark differences between like certain tasks performed a lot better with semantic search allowed and then certain tasks performed a lot better with with no semantic search and this kind of proves you know, certain tasks requires different types of tools. For example, when semantic search won, it was really good at finding a lot of behavior adjacent files that didn't have the same kind of keywords.

For example, it was like I think one example off top of my head was we're trying to like it was a multi like first handle lots of different ORMs that have to like handle across different libraries and it didn't by default the keyword search didn't by default find all of them, but behaviors semantic search was able to kind of like understand these are all related files.

And then grep won when it was really good at just the task was a lot of it like tracing through imports and if it like was able to find the keywords in like the first or second tool call, it was able to like just keyword search through that and find the relevant files. So again, it's like two different types of how to find files, but they kind of lead to like really different results. So in summary like what does this mean? Well, we like we saw semantic search like did boost precision quite a bit and we like kind of understand like grep and semantic search kind of find different code different ways.

And an interesting thing to note as well was um these numbers weren't as great as Cursor's because part of like part of Claude code is it's built for just grepping. Like that's that's what Anthropic kind of focuses on. Like it's not built to under like to really understand like when to call semantic search or how to call it. Uh we kind of like add as an extra tool and it's like, "Hey, like here's this cool tool.

You probably should use it sometimes." But it's very hard for it to have a true understanding of when to use it, why to use it uh versus like for example Cursor's composer they understand this is a built-in tool that um it knows when and how to use it and that's why they saw it's like 23 and 1/2 per uh percent uh performance gain. Uh so like in summary, uh you know, we think long-term winners were like kind of provide these lightweight tools to find the right context in various different ways. I think it's something important to think about. Uh you can't just like grep through everything unfortunately in a file system.

Uh we think there's a lot of different ways to access lots of different types of information. Uh and the people that provide these like easy tools to provide to shrink down these billion context windows into the right million uh will win in the long term. Um that's the general talk. Thank you. If you have any questions, feel free to come up. >> [applause] >> I have my own idea of what semantic search is, but could you define what you what's your definition is of semantic search? >> Sure. Uh so this was just uh just doing vector search.

It was just performing vector search using embedding it using Voyage's code model and then just embedding the the the query um query sentences or query tokens and just sending them back to to Turbo puffer. Yeah. Uh sorry, the uh embedding model Uh Voyage code three. Okay. And which vector DB? Turbo puffer. Yeah. >> Sorry. Uh no worries. Yeah, yeah. Yeah, for those for those who are unfamiliar with Turbo puffer, we are the we are the vector database that powers companies like Cursor, Anthropic, Notion. So when you use something like Cursor uh you have by proxy used Turbo puffer. Um so you may know us just not by name, I guess.

I was just going to ask You may not have a benchmark for this, but how does it perform on code? Oh, that's that's tough. I mean it's hard to say >> better or is semantic better if the code's like a mess and you need to go and sort it out? Uh so I think it works best when there's a lot of like comments on code uh because it kind of finds that semantic meaning. >> like the documentation is kind of inline. Yeah, if it's like inline documentation, that was like a big um boost.

I believe one of the repos I remember like looking through some directories and like asking Claude be like, "Why did it perform so well here versus not?" And it was one of it kind of explains me like um when I was looking through as well like those with like really good comments, for example, just like comments above the function, it's able to like really understand a lot more cuz you you kind of give this context to the model and the embedding model. So then it can like actually search better. Um cuz that's that's part of it. Like the the embedding it and is not the hard part.

It's like figuring out what meaning really is of that chunk. Yeah. Yeah, you may have you you've mentioned some of it now, but of course semantic search is just similarity search. So if your query it doesn't really match the format of what you're querying against then you get some kind of innate distance. Do you do any kind of preprocessing on what your of the target data before you like do you do an parent-child where the parent is query-ish and the child is the real code or how do you >> In in this case it was just simple just just the code.

Yeah, just the raw code just as a thing, but I can't speak for like how these more complicated and sophisticated customers use this, but I can imagine it's definitely something of providing not just code level meaning, but you know, as you said at least a parent-child relationship of like authentication flow, like that could be a good query to do a similarity search against, but the code itself is more like raw. Yeah. Yeah. Like Cursor has their own embedding model, which I think kind of helps with this of like how do you translate code into more of like a human level query. And I mean they're kind of been experts on that.

I can't speak for how they do it, but I just know they do do it. I think they actually do what you said like they create fake comments on top of of your code and then embed the code with the comments. Yeah. So that's how they can have like their high recall when they So they add they kind of inject comments. Yes. Yeah, it's something that I think definitely could work. Yeah. In the back? Yeah.

I was going to ask like how do you see uh I guess the vector database kind of working with the partners and how like when do you code like long-term or need to reduce the size I mean I think it depends. Like obviously the easiest way like people love grepping because it's zero cost. Like if you're able to like download everything to your local file system and just like grep through it, like yeah, that works. Um I think vector DBs are built for actually like multiplayer and like this like super maybe in a sense like hard to understand or uh complicated relationships between lots of data.

For example, like a knowledge base like a Notion, like you can imagine kind of hard to like really grep through that really easily on your local machine. Like it's in a sense best to like have that vectorize uh for the agents. Um and even stuff like we have customers doing stuff like with multimodal data. You can't really grep through a video file. You can't grep through an audio file. You can't grep through an an image file. Like maybe you can glob on the on the file name, um but like get a true understanding of kind of multimodal data as well is that something that we find a lot of customers are doing.

Um so it just kind of depends on the workload and um I I yeah, if you if you're hitting like at some sort of even like miniature scale like a vector DB kind of like helps offload a lot of this this work into like you know, cache computer cache this semantic meaning. Any other questions? Okay. Thank you all. >> [applause]