AI Engineer Europe 2026
Benchmarking semantic code retrieval on Claude Code
Read the talk
Benchmarking semantic code retrieval on Claude Code
Adding semantic search makes Claude Code’s context discovery more selective, but recall depends on the task—and on whether the agent knows which retrieval tool to use.
From a talk by Kuba Rogut
Before you start: Familiarity with command-line code search and coding agents is helpful; embeddings, precision, and recall are explained as they appear.
Why index code when an agent can grep?
Should a coding agent discover a repository by repeatedly searching and reading files, or should it start with a searchable index of the code’s meaning? That is the practical difference behind this experiment. Kuba Rogut, a deployed engineer at turbopuffer—a serverless full-text and vector search database built on object storage—starts with Claude Code’s choice. At the time of the recording, it relied on agentic filesystem search by default. Rogut cites Boris Cherny’s account that early versions used a local vector database, but iterative search proved simpler and worked better for Claude Code.
Cursor made a different investment: it indexed codebases into turbopuffer to support semantic retrieval. In Cursor’s semantic-search evaluation, Rogut highlights roughly 24% relative answer-accuracy improvement for Composer, with about 12.5% averaged across models. These results predate Composer 2; they do not establish its performance. He also recommends Cursor’s account of indexing large codebases.
Cursor’s separate online A/B test measured user outcomes rather than benchmark answer accuracy. Its report gives 2.6% higher code retention with semantic search for codebases containing at least 1,000 files. It also reports 2.2% more dissatisfied follow-ups when semantic search was disabled. The direction of that second comparison matters: it is not exactly the same percentage as a reduction measured from the disabled condition. Aggregate effects also include requests that have little use for semantic search, so a modest overall change can conceal larger gains on the requests that need it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Embeddings amortize repeated discovery
Consider the question: how does metadata filtering work in this codebase? An agent using filesystem search starts with candidate terms, reads matching files, and searches again when those files do not answer the question. A shell search can begin broadly and then request nearby context:
bash
rg -n -i 'metadata|filter' .
rg -n -i -C 12 'metadata.*filter|filter.*metadata' .
The agent still has to interpret the matches and decide where to look next. Rogut’s illustrative trace spends about 6,000 tokens on this discovery process. That is one example, not a benchmark-wide average. The same work can recur in another session or in another agent working on the same repository.
The indexed route moves some of that work earlier:
- Split the codebase into chunks.
- Embed those chunks and store them in a searchable index.
- At runtime, use the metadata-filtering question to retrieve relevant chunks.
Embeddings are cached compute in this sense: they preserve a reusable representation of meaning that can shorten later discovery. They do not cache a complete answer. The agent still needs to read and reason about the returned code. Nor does indexing eliminate upkeep; changed code requires the index to be maintained. The complete slide compares repeated grep-and-read discovery with the upfront indexing work and subsequent retrieval.
The economic argument becomes stronger across repeated sessions and concurrent agents. A small saving on one question may be unremarkable, but paying to rediscover the same area of a repository repeatedly can accumulate. Whether indexing pays off depends on how often the representation is reused relative to the cost of building and maintaining it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give Claude Code a semantic retrieval tool
TurboGrep implements a small version of that pipeline. It walks the filesystem, uses tree-sitter to parse and chunk code, generates embeddings with a Voyage code model, and uploads them to turbopuffer. Claude Code then gets a search tool backed by that index. At recording time, Rogut described V1 as open source and V2 as awaiting release; the public repository should not be assumed to reproduce the exact demonstrated integration.
The demonstration uses the Django repository. Claude Code invokes the TPuff search tool with a query for a password reset token generator, receives the relevant content, and uses it to explain the implementation to the user. The useful handoff is from a description of the desired behavior to code the agent can inspect. A successful trace shows that the integration works in that example, but does not yet establish whether it improves retrieval across tasks.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Measure the context found along the way
To move beyond a convincing demonstration, the evaluation asks what context the agent discovers while attempting a task. Rogut distinguishes Cursor’s internal context benchmark from the public ContextBench work. The latter uses human annotations identifying files, lines, and symbols that an agent should inspect to complete a task well. This evaluates the retrieval trajectory, rather than simply whether the final code solves the issue. Retrieval precision and recall are not answer accuracy or task completion.
The experiment compares three conditions:
| Condition | Available retrieval behavior |
|---|---|
| Stock Claude Code | Default search and file reads |
| Windowed reads | Reads limited to 50 lines at a time |
| Windowed reads + semantic search | Same read limit, plus TPuff Search |
The read limit matters because reading an entire thousand-line file can sweep in annotated context without showing whether the agent located it precisely. Large reads made the measurements noisy and obscured differences between retrieval strategies. The windowed condition provides a more informative baseline for assessing the added semantic tool.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Precision improves with more selective retrieval
Precision asks how much of the retrieved context belongs to the annotated target set:
If the agent reads ten files and eight are required, file precision is 80%. The same idea applies to lines and symbols. Rogut reports these approximate results:
| Condition | File precision | Line precision | Symbol precision |
|---|---|---|---|
| Stock Claude Code | 65% | 33% | 43% |
| Windowed reads + semantic search | 87% | — | — |
The intermediate windowed condition also improves precision. Consequently, the entire increase from stock Claude Code to the combined condition cannot be attributed to semantic search alone; restricting reads contributes too. These are Rogut’s reported experimental results, not a general guarantee for other models or repositories.
Rogut describes default Claude Code as highly exploratory: it tries to read broadly before settling on the relevant implementation. His rounded interpretation is that files outside the labeled target set account for about one in three baseline reads, one in five windowed reads, and one in eight reads with semantic search added. That makes the selectivity improvement tangible. Calling those reads wasted is shorthand for being outside the benchmark’s annotations, not proof that every exploratory read was useless.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Recall reveals what selective search can miss
Recall changes the denominator: how much of the required context did the agent find?
Suppose a task requires ten files. The agent reads five files, but only three belong to the required set. Its file recall is 30%. Reading fewer irrelevant files can improve precision without improving this coverage measure.
Stock Claude Code has the highest file recall in the reported comparison. Broad exploration helps it encounter more target files. Its line recall is weaker, however: reaching the right file does not necessarily mean inspecting the right parts of it. Windowed reads and windowed reads plus semantic search have roughly similar aggregate recall, with some decreases when semantic search is added. The aggregate covers 50 tasks in Rogut’s experiment, not the full public benchmark. Higher precision therefore coexists with a mixed coverage result.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Behavioral similarity and import tracing find different code
Splitting the tasks by which condition performs better reveals differences that the aggregate hides:
- Semantic search: Useful when relevant files implement related behavior but use different keywords. Rogut recalls an example involving related handling across several ORMs or libraries: lexical search missed some implementations, while semantic search found their behavioral relationship.
- Windowed grep: Useful when an early search finds a good identifier and the remaining work follows explicit connections such as imports. Once the agent has the right names, keyword search can trace the relevant files directly.
These are different ways to navigate a repository. One follows similarity of behavior; the other follows names and explicit code relationships. The task breakdown supports choosing tools according to that structure, rather than declaring one search method universally better.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A useful tool still needs a tool-selection policy
The experiment improves precision, but the agent also has to decide when and how to use the new tool. Rogut’s interpretation is that Claude Code is oriented toward grep: attaching a semantic-search tool does not automatically give it a reliable policy for choosing that tool, phrasing a query, or deciding when to return to lexical search. He contrasts this with Composer’s integrated retrieval behavior.
That is a plausible explanation for why an added tool might fall short of an integrated system, rather than a causal result isolated by this experiment. Cursor’s answer-accuracy evaluation and Rogut’s context-retrieval evaluation also measure different outcomes, so their gains cannot be compared directly. His closing design principle is to provide lightweight, complementary ways of finding context. Even very large context windows still benefit from selecting the relevant information before asking a model to reason over it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What semantic search means here
The audience first asks for an exact definition of semantic search. In this implementation it means vector similarity search: embed the code, embed the query text, and search the stored vectors in turbopuffer to retrieve code chunks. The embedding model is voyage-code-3. This is a concrete, relatively simple retrieval setup, not a claim that every system described as semantic search uses the same architecture.
Rogut names Cursor, Anthropic, and Notion as turbopuffer customers. A company’s use of the database does not identify the retrieval architecture of each of its products; in particular, that customer relationship does not establish semantic code search inside Claude Code.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Comments help a chunk explain itself
What happens on poorly written code? Rogut does not give a controlled benchmark answer. Instead, he describes a pattern from reviewing trajectories, including using Claude to help examine them: examples with useful function comments and inline documentation tended to retrieve better. Those comments supply context about behavior that both the embedding model and the coding agent can use.
The difficult part is not merely producing a vector. It is making the chunk’s meaning available to the representation. A function’s syntax may show what operations it performs without clearly expressing why it exists or which user-facing behavior it supports. Good documentation can help connect those levels. This remains a qualitative observation from the trajectories, not a measured rule that comments always improve retrieval.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Bridge the gap between a question and raw code
A follow-up question points to a representation mismatch: a natural-language query and raw code may express the same behavior in very different forms. The audience proposes a parent–child arrangement in which a query-like description points to a child containing the actual code. Rogut clarifies that this experiment did not apply that preprocessing; it embedded the raw code chunks.
Authentication flow is the audience’s example of a human-level concept that may not appear directly in implementation text. A description at that level could provide a useful retrieval target, while the linked code remains the evidence the agent needs to inspect. Rogut mentions Cursor’s own embedding model as another way to address the translation between code and human queries, but says he cannot explain its internal implementation.
Another audience member suggests that Cursor generates comments and embeds them with code. That explanation is unverified in the discussion. Rogut agrees that comment enrichment could work; he does not establish that it is Cursor’s actual method. The concrete distinction is between the raw-code experiment presented here and possible enrichment methods that would need their own evaluation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Where shared vector retrieval earns its place
The final question raises long-term memory and reducing database size. Rogut answers in terms of workload placement, without specifying when to encode memories or how to compact them. If all relevant information can be downloaded to a local filesystem, grep is convenient and requires little setup. That simplicity is valuable, even though the agent’s repeated searching and reading still consumes compute.
Shared workloads change the calculation. A Notion-like knowledge base contains relationships across information that may be awkward to gather and search as local files. A shared vector index can make those semantic relationships available to multiple agents. Multimodal data extends the case further: grep does not directly recover the semantic content of raw video, audio, or images. Matching a filename is different from finding what the media contains.
The choice therefore depends on the data, the workload, and the amount of repeated discovery. Local lexical search remains useful when the relevant material and identifiers are readily available. As agents share larger or more varied information spaces, storing reusable semantic representations can offload work they would otherwise repeat. That is where the cached-compute argument reaches beyond code search.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Cursor's offline answer-accuracy evaluation and online tests of semantic search, plus its approach to training a custom embedding model.
How Cursor synchronizes code changes, caches chunk embeddings and securely reuses indexes across teammates.
Public code-search CLI with installation instructions and a semantic-query example using Voyage and turbopuffer.
A benchmark using human-annotated code contexts to evaluate retrieval precision, recall and efficiency during issue resolution.
Further reading
Technical background on voyage-code-3, including code-retrieval training, embedding dimensions and quantization.
Read the complete timestamped transcript
- 0:00
[upbeat music] Hi, everyone.
- 0:16
Uh, welcome to Benchmarking Semantic Sear- or Semantic Code Retrieval on Claude Code. Uh, my name is Kuba. I- I'm here from TurboPuffer. For those unfamiliar with TurboPuffer, we are a serverless full text and vector search database built from first principles on top of object storage.
- 0:29
Uh, 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 TurboPuffer or anything, just find-- feel free to find me after.
- 0:38
Uh, so let's get started. So for those of you who are unaware, uh, Claude Code by default, or I mean, yeah, by default doesn't use semantic code search. Uh, there's actually a tweet from Boris.
- 0:47
Uh, those unfamiliar with Boris, he's essentially like the founding father of Claude Code, and he talks about how Claude-- the early versions of Claude Code did actually use semantic search with a local vector DB, but they just kinda found agentic search, essentially, you know, grepping through your file system kinda worked better and, you know, seems to work
- 1:02
simpler for, for Claude Code. However, uh, one of TurboPuffer's customers, actually, fun fact, one of our very first customers, Cursor, uh, does use semantic code search and does in-index codebases into TurboPuffer.
- 1:14
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 r-real performance gains because of this.
- 1:23
Uh, they have this amazing blog post, uh, about their semantic search. They also have one about indexing codebases, which I highly recommend as well. Uh, but you can see on the right, the kind of performance gains they see with a Composer model is like twenty-four percent, uh, increase in an- or relative improvement in answer accuracy.
- 1:38
And I think it's like twelve and a half or thirteen percent across, uh, all models. And, you know, I, I-- This benchmark came up, uh, before Composer 2, but you can probably imagine there's some sort of similar performance gains with that, that new model as well.
- 1:49
And in the bottom right, you can see, uh, this is from-- So this same blog post, uh, they talk about how in-- they performed an online A/B test where they found that adding semantic-- either allowing or disallowing semantic, uh, code search led to, like, a two point six percent increase in code retention in large codebases and an
- 2:05
n-two point two percent decrease in dissatisfied user requests. And you may also think, like, these numbers seem kinda small, like what, two point six percent, two point two percent?
- 2:14
Um, well, keep in mind that, you know, out of a hundred queries, not all queries will ever really need semantic search or, like, benefit from it. Uh, so these-- They even state in the blog post that these numbers look small because not every-- You know, you could imagine a very simple tool call or very simple query would
- 2:29
not really use semantic search. Um, so what we think about here at TurboPuffer and why we kind of really, uh, think vector search and why Cursor probably sees this, like, real performance gain is we think about how embeddings are cache compute.
- 2:44
And you could also, you know, what does even-- what do you mean cache compute? This sounds like a bunch of baloney you're throwing at me. Um, you know, if we would, like, walk through, like, a Claude Code trace and, like, a Cursor s-type trace of kind of the same thing, you can imagine that, uh, on the left
- 2:56
side, there's kind of like a, you know, grepping through the file system or what they call agentic search, um, how it just has, like, grep through. Uh, this is for finding metadata filtering and understanding it in your codebase.
- 3:05
It 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, um, running in, you know, uh, for the same codebase so that even if you're asking the same question or trying to do the same thing multiple times, you always
- 3:21
have to do this compute again. And you can see, like, in this case, six thousand tokens isn't a lot in one time, but across every session and every agent, this really starts to add up.
- 3:29
And if we-- You know, on the right, if this is more of a, like, Cursor style or Cursor level trace, where you have this upfront cost, where we have to, like, chunk, embed, and index the codebase.
- 3:37
But then you essentially have this cache of the semantic meaning so that when a f-when an agent wants to understand, you know, where or how does metadata filtering work, uh, it can simply query, you know, how is metadata filtered and get a lot, uh, get the chunks it needs and kinda the understanding it needs a lot faster
- 3:54
and, uh, with token savings. And again, this doesn't-- It's not a lot of savings in one time, uh, but we all, you know, we're not really running one agent anymore.
- 4:03
Like, I'm running, like, three at one time. So, um, there's definitely some l-long-term savings. So, uh, what we did, what we did is we built a simple CLI tool for Claude Code.
- 4:12
Is-- We call it TurboGrep. Um, it's essentially, you can imagine, it's just a simple way of, um, using a tree splitter library to essentially parse through your codebase, uh, chunk it, embedding using the Voyage code model, and then upload it to TurboPuffer.
- 4:26
Um, this is just a simple, um, file system walkthrough. Uh, there is an open source library for the V1 version, and then soon the V2 version will be, uh, open sourced.
- 4:37
Um, here there's a little video of example a, a tool call trace for a Claude Code where you'll see, uh, it will call the TPuff tool. Now, it's called TPuff Search Password Reset Token Generator.
- 4:49
This is in the, uh, Django repo. This is one of the, the repos I was testing it on. And you can see that, uh, it gets the content and then is able to kind of give the full, um, explanation to the user.
- 5:02
And, you know, it's very easy to say, like, "Oh, this works better," but the important thing is obviously benchmark. Let's see for real, what, what-- how much better does it work?
- 5:10
Uh, Cursor has their own internal, uh, context bench, and there's this paper, this public paper called Context Bench, um, where essentially the benchmark is not really testing whether or not the coding agent solved or didn't solve a problem.
- 5:22
It tests when it-- In the process of solving the problem, did it find certain files? Did it s-find certain lines and did it find certain symbols? Because they, you know, they kind of have this, uh, this thesis that, like, it, you know, it's also important how you get there, not just, um, like, the end goal.
- 5:39
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, the, the agent should have looked at this file, these few lines, and these few symbols in order to, like, actually complete the task well.
- 5:54
Uh, and I tested it with three conditions. Uh, essentially raw Claude Code out of the box. Uh, then I tested it with Claude Code with a fa- uh, the max of fifty line reads at a time.
- 6:03
And then, uh, the same thing with the windowed reads, uh, with the TPuff Search tool. Uh, you may ask me, like, why this, like, fifty line read, uh, thing.
- 6:10
... or limit. It's because it's, it became really noisy really fast. If it's just reading, like, long files, it's really hard to, like, understand, uh, and get a difference because it all ...
- 6:19
If it just reads a whole f- like, a thousand line file, it doesn't really make a lot of difference in the numbers.
- 6:24
So we'll start with the first result of it. Uh, this is precision. Precision is essentially the, [coughs] the measure of, of how many files did it read, like, in its total process, how many of them were actually golden files.
- 6:37
So if there was ... If the, if Claude read 10 files and eight of them were needed, it hits 80% precision. Uh, 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.
- 6:52
And then windowed grep plus semantic search got it to, like, 87% file precision, for example. Uh, and this is also due to the fact, like, Claude Code by default, like, is really exploratory.
- 7:00
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. Um, and, like, it's hard to, like, translate these numbers, but a more, like, English or, like, human version of it is that, you know, Claude Code, one in every three file reads
- 7:15
is actually just a completely wasted file. Um, and with windowed grep, it was one in five reads was a irrelevant file. And then with semantic search, it was only one in eight files was a, you know, quote, unquote, "wasted or irrelevant file."
- 7:27
And it kind of, like, scales up as you kind of add these tools.
- 7:30
And, you know, obviously this, this is already, like, pretty good. Uh, 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 Claude found five of them, five files in its total trajectory, and only three of
- 7:46
them were actually these golden files, it would hit 30% recall. Um, by default, again, uh, Claude Code actually does win the file recall. And again, part of this is because it just loves to explore every single file it can.
- 7:58
Um, then we have line recall, where it drops a lot more. This is kind of a ... Because it loved to read a lot of files, but also read to le- read a lot of files that didn't have a lot of, uh, golden context lines.
- 8:10
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 semantics, or windowed grep and windowed grep plus semantic search, kind of about the same recall.
- 8:20
Uh, you can kind of see on the right, like, kind of the, what happened with the behavior between these three conditions. Uh, and you may be thinking like, "Well, you know, semantic search didn't really, like, add improvements here.
- 8:29
Like, what, 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 was across, uh, 50 tasks by default.
- 8:38
Uh, 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, uh, allowed, and then certain tasks performed a lot better with, with no semantic search.
- 8:54
And this kind of proves, um, you know, certain tasks require s- different types of tools. For example, when semantic search won, uh, it was really good at finding a lot of behavior adjacent files that didn't have the same kind of keywords.
- 9:06
For example, it was like ... I think one example off the top of my head was with trying to, like ... It was, like, multi... Like, first handle lots of different ORMs that have to, like, handle across, uh, different libraries, and it didn't by default, the keyword search didn't by default find all of them, but behaviors, uh,
- 9:19
semantic search was able to kind of, like, understand these are all related files. Uh, and then grep won when it was really good at just ... The task was a lot about, like, tracing through imports, and if it, like, was able to find the keywords in, like, the first or second, uh, tool call, it was able to,
- 9:34
like, just keyword search through that and find the relevant files. So again, it's like two different types of, uh, how to find files, but they kind of lead to, like, really different results.
- 9:43
So in summary, like, what does this mean? Well, we, we saw semantic search, like, did boost precision quite a bit. Uh, and we, like, kind of understand, like, grep and semantic search kind of find different code different ways.
- 9:55
Um, 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.
- 10:05
Like, that's, that's what Anthropic kind of focuses it on. Like, it's not built to under- like, to really understand, like, when to call semantic search or how to call it.
- 10:14
Uh, we kind of, like, add it 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, like, for example, Cursor's Composer model, they understand this is a
- 10:27
built-in tool that, um, it knows when and how to use it, and that's why they saw this, like, 23 and a half perfor- uh, percent, uh, performance gain. Uh, so, like, in summary, uh, you know, we think long-term winners will find con- kind of provide these lightweight tools to find the right context in various different ways, and
- 10:43
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
- 10:58
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. [audience applauding]
- 11:07
I have my own idea of what semantic search is, but could you define what you, what your definition is of semantic search?
- 11:13
Sure. Uh, so this was just, uh, just doing vector search. It was just performing vector searching, uh, embedding it using Voyage's code model, and then just embedding the th- the, the query, um, query sentence or, uh, query tokens, and just sending them back to Tur- to TurboPuffer.
- 11:28
Yeah.
- 11:29
Uh, sorry. But which, uh, embedding model are you using?
- 11:32
Uh, Voyage Code 3.
- 11:34
Okay. And which vector DB?
- 11:36
TurboPuffer.
- 11:37
Ah, okay. [laughs]
- 11:38
Yeah.
- 11:38
Sorry. [laughs]
- 11:39
Oh, no worries. Yeah, yeah. Yeah, for those, for those who are unfamiliar with TurboPuffer-
- 11:43
That's all right
- 11:43
... 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 TurboPuffer.
- 11:53
Um, so you may know us just not by name, I guess.
- 11:58
So...
- 11:58
I just wanted to ask, you may not have a benchmark for this, but how does it perform on shit code?
- 12:04
Oh, that's, that's tough. I mean, it's hard to say.
- 12:08
Is grepping better or is semantic better for code that- That sort it out
- 12:12
Uh, so I think it works best when there's a lot of d- like, comments-
- 12:17
Mm-hmm
- 12:17
... on code, uh, because it kind of provides that semantic meaning
- 12:20
So working alongside, like, documentation that's kind of inline?
- 12:22
Yeah, if it's like inline documentation, that was like a big, um, boost. I believe, uh, one of the repos I remember, like, looking through some trajectories and, like, asking Claude, be like, "Why did it perform so well here versus not?"
- 12:32
And it was when it, it kind of explains to me like, um, when I was looking through as well, like, those with, like, really good comments, for example, just, like, comments about the function, it's able to, like, really understand a lot more 'cause you, you kind of give this context to the model and the embedding model so
- 12:45
then it can, like, actually search better. Um, 'cause that's, that's part of it. Like, the, the embedding i- and, uh, is not the hard part. It's, like, figuring out what meaning really is of that chunk.
- 12:56
Yeah.
- 12:58
Okay.
- 12:58
Yeah, you may have, you have, you've mentioned some of it now, but of course semantic search is just similarity search, so if your query doesn't really match the format of what you're querying against, then you get some kind of innate distance.
- 13:12
Do you do any kind of pre-processing of what your, uh, of the target data before you... Like, do you do any parent-child where the parent is query-ish and the child is the real code?
- 13:23
Or how do you-
- 13:24
In, in this case, it was just simple, just-
- 13:26
Yeah
- 13:26
... just the code.
- 13:26
Just the raw code?
- 13:27
Yeah, just the raw code, just as a thing. But, um, uh, 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-
- 13:40
Yeah, like the authentication flow. Like, that could be a good query to do a similarity search against, but the code itself is more, like, raw code, so.
- 13:47
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-
- 13:54
Yeah
- 13:55
... like, 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 that.
- 14:01
Yeah.
- 14:01
Yeah.
- 14:01
I think they actually do what you said, like they create fake comments on top your, of your code, and they embed the code with the comments.
- 14:09
Yeah.
- 14:09
So that's how they can have, like, the higher recall when, uh-
- 14:14
Oh, okay. Yeah
- 14:15
... they search all the code.
- 14:15
So they add, they kind of inject comments?
- 14:17
Yeah. Yeah.
- 14:18
Yeah, something like that I think definitely could work, yeah.
- 14:21
Interesting.
- 14:21
In the back?
- 14:22
Yeah. I was gonna ask, like, how do you see, uh, I guess, the vector database, uh, kind of working with the Rennis and, and how, like, when do you encode, like, long term memory to reduce the size of the, uh, database?
- 14:38
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.
- 14:48
Um, I think vector DBs are built for essentially, like, multiplayer and, like, this, like, super [cough] maybe in a sense, like, hard to understand or, uh, complicated relationships between lots of data.
- 14:58
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 vectorized, uh, for the agents.
- 15:09
Um, and even stuff, like we have customers doing stuff like with multimodal data. Like, you can't really grep through a video file. You can't grep through an audio file.
- 15:15
You can't grep through an, an image file. Like, maybe you can glob on the, on the filename, um, but to, like, get a true understanding the kind of multimodal datas as well is, that's something that we find a lot of customers are doing.
- 15:26
Um, so and it just kind of depends on the workload and, um, I, I, yeah, if you're, if you're hitting qu- 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 compute- cache this semantic meaning.
- 15:42
Um, any other questions? Perfect. Thank you all. [audience applauding] [upbeat music]