The unreasonable effectiveness of BM25 for agentic search — Jo Kristian Bergum, Hornet.dev
Read the talk
Why BM25 works so well for agentic search
Jo Kristian Bergum explains how a model’s knowledge, query reformulation and file-system tools give an old lexical scoring function a new role—and why retrieval must be judged by the task it helps complete.
From a talk by Jo Kristian Bergum
At a glance
Ideas worth remembering
Agentic search depends on the model, the harness and the retrieval engine. High accuracy with evidence supplied directly does not guarantee that the same model can find that evidence through search.
A BM25 baseline needs a stated configuration. Bergum attributes substantial BrowseComp+ accuracy differences to parameters that were poorly suited to long documents.
Literal matches serve two purposes: finding specific names and identifiers, and giving the agent understandable feedback for its next query.
A file-system workspace lets the agent inspect titles and snippets before reading full documents, then use familiar tools such as grep and ripgrep to examine retrieved material.
Evaluate the complete search trajectory by task success, and assess serving efficiency separately. One ranked list or a throughput claim cannot establish both.
Search inside an agent loop
BM25’s comeback begins with a change in who uses search. Jo Kristian Bergum, CEO of Hornet.dev, has worked on search and retrieval for more than twenty years. His argument is that a roughly thirty-year-old lexical scoring function becomes more useful when its user can draw on extensive general knowledge, write specific queries and keep searching after an incomplete result.
Bergum defines agentic search as search inside an agent loop. An agent working on code or deep research encounters an information need, searches for the missing material and uses what it finds to continue the task. Search therefore sits within a larger process whose success depends on what the agent eventually accomplishes.
He separates the system into three parts. The model must formulate queries and use tools. The harness must expose search in a form the model can operate, whether through tool calls or code. The retrieval engine must execute those searches efficiently, potentially across billions of documents. These parts solve different problems: a capable model still needs a usable interface, and a usable interface still needs an engine that can find information at the required scale.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The scoring function stays the same; the queries change
BM25 stands for Best Match 25. Bergum explains the name as the result of a series of experiments in which the twenty-fifth worked best. Its role is to score a document against a query through interactions between their terms. The score serves as a proxy for relevance: documents with higher scores become candidates for the results returned to the user.
The scoring rule and the machinery that runs it are separate. A straightforward approach would score every document and then select the top K. Making that selection fast has motivated decades of retrieval algorithms. Two engines can therefore use BM25 while taking very different amounts of time or computing resources to return results. This distinction matters later in Bergum’s argument: retrieval quality depends on how scoring behaves, while serving cost also depends on how efficiently the engine finds the highest-scoring documents.
The new advantage comes from the model’s knowledge. It already knows entities, companies and dates, and can use that knowledge to choose search terms. BM25 has long served as the baseline against which more elaborate neural retrieval methods compete. Bergum argues that its value changes when the user can issue many queries rather than type one query and scan ten blue links. A weak first result can become input to another search instead of the end of the interaction.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The bottleneck is getting the evidence into context
Bergum develops the argument through BrowseComp+, a deep research benchmark with 830 long, riddle-like questions. Its corpus contains roughly one hundred thousand web documents. The model receives a simple Search tool that accepts a query string and returns snippets. Each question has a reference answer, so the benchmark can check whether the complete model-and-search loop produces the expected answer.
Why retrieve at all? Bergum compares the context window to a floppy disk: a bounded space into which the system must place useful information. He recalls a capacity of about 1.4 megabytes and estimates that models can use around 350,000 tokens before quality starts to degrade. The token figure is his opinion, rather than a universal limit. The analogy’s practical point is that even a large context window requires selection; the system must decide which evidence deserves space.
BrowseComp+ offers a useful comparison. When the documents needed to answer a question are placed directly into context, answer accuracy is high, including for older models. When the model must find those documents through search, accuracy falls. Bergum takes this as evidence that reasoning is not the main bottleneck in that experiment. The model can answer once it has the evidence; acquiring the evidence introduces failures involving query formulation, the harness and retrieval quality. The comparison does not identify one of those components as the sole cause.
A question consequently becomes a search trajectory. The model issues a query, reads the response, reformulates and repeats until it finds the answer or fills the context window. Bergum expects evidence selection to remain important even as models become more capable. Better reasoning alone does not decide which documents enter a bounded context, and each unsuccessful search can consume space without resolving the information need.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Long queries expose the importance of the BM25 configuration
Hornet investigated these search trajectories and compared model-written queries with human queries in the AOL search logs. Bergum describes the human queries as short, a pattern he also recognizes in more recent logs. The model can write much longer queries and use search syntax, including site operators and phrases. This changes the workload: an engine serving agents must contend with the queries agents actually generate, rather than assume the short queries familiar from human search.
That leads to an important qualification: which BM25 configuration is being tested? Bergum notes that BM25 has two hyperparameters and criticizes the baseline in the original BrowseComp+ research. In his account, later research found that its parameters were poorly suited to the benchmark’s long documents. Embedding-based methods looked much stronger against that baseline, but changing the BM25 parameters had a substantial effect on end-to-end accuracy. He does not provide parameter settings or numerical accuracy changes here, so the lesson is to examine the baseline configuration before drawing a broad conclusion about the retrieval method.
Exact matching gives the model a concrete way to use its knowledge. Names, entities, ZIP codes and SKUs can become highly specific query terms. Bergum argues that these details are harder for embedding-based retrieval to preserve as useful distinctions. His case for BM25 centers on workloads where the literal identifier matters: the model can supply that identifier, and lexical retrieval can look for it directly. This supports a role for exact matching without establishing that it wins on every kind of query.
Cost and inspectability strengthen the case. Embedding retrieval requires text encoding and inference infrastructure; Bergum points out that some embedding models have about eight billion parameters. BM25 avoids that embedding-inference step and benefits from readily available tooling. Its literal matches also help the agent understand why a result appeared. The model can inspect the returned text, recognize which terms matched and use those observations to reformulate its next query. Explainability thus contributes to the search loop itself.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Retrieve globally, then inspect a file-system workspace
Bergum then introduces a research direction called Scaling Direct Corpus Interaction via Dynamic Workspace Expansion. The pattern starts with a corpus potentially containing billions of documents, far too much to place in context. A retriever selects relevant documents and places them in a workspace. He describes this as a search results page for agents: an intermediate collection the model can examine before deciding what to read in detail.
Organizing that workspace as a file system enables progressive disclosure. The model first sees a document’s title and a short snippet. If those suggest useful evidence, it can read more of the document. The system therefore need not insert every retrieved document in full into context. It gives the agent a way to choose which material deserves closer inspection.
The file-system interface also makes familiar tools available. The model can use grep, ripgrep, sed and awk while inspecting documents and managing context. The retrieval engine searches the large corpus; these tools operate on the material brought into the workspace. This combines retrieval infrastructure with a sandbox or virtual file system and a Bash interface. BM25 and grep fit together particularly well in Bergum’s account because both let the model work with literal text matches.
Bergum calls this a pragmatic adaptation to what models are already good at. Model developers invest heavily in coding, Bash and tool use, so a retrieval workflow built around those capabilities may benefit from that training direction. This is a bet about how to design the interface, rather than a guarantee that each future model will improve it. He leaves open whether more capable systems might eventually work directly through a browser; his recommendation is grounded in the tools models can use effectively now.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Measure task success and the cost of serving search
The same change in user calls for a change in evaluation. Traditional information retrieval often compares one query and one ranked list using a metric such as nDCG. Bergum argues that this is insufficient for an agent that can reformulate queries, expand its search and recover through later results. His proposed endpoint is task completion: for question answering, does the agent get the answer right? A single ranked list captures only one step in the process that produces that answer.
Serving efficiency remains a separate concern. Hornet is betting on BM25 as a retrieval primitive and on making its execution efficient. Bergum presents a comparison against anonymized engines using the same type of hardware and one hundred million web documents on a single node. He claims that Hornet delivers more throughput for the same spending, which could reduce costs for companies building search infrastructure.
The comparison supports only a limited performance conclusion here. Bergum initially identifies the vertical axis as queries per second, then corrects it to latency. The numerical values, horizontal-axis definition and engine identities are not established in his explanation. His claimed efficiency advantage should therefore remain distinct from a quantified speedup or a reproducible cost comparison. It also answers a different question from BrowseComp+ accuracy: faster retrieval does not by itself show that an agent finds the right evidence.
Bergum closes by returning to the user and the tools. An agent can write and read quickly, reformulate queries and draw on general knowledge, making simple primitives such as BM25 and grep more useful. Parameters, implementation and performance still matter. His preferred combination is corpus-scale lexical retrieval followed by literal-text inspection in a workspace, with the complete loop judged by whether it accomplishes the task. The old scoring function gains value because the model can do more with its results.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Read the complete timestamped transcript
- 0:12
So great being here. Uh, I'm Jo Kristian Bergum. I'm the CEO of, uh, Hornet.dev, and I'm here today to talk about the unreasonable effectiveness of BM25 for agentic search. So how many of you heard about BM25 before? Is it new, or is it... Oh, quite a few, so that's great. Uh, I'm also watching the World Cup. Norway is playing their, uh, against Ivory Coast second half. Norway is leading, so that's good. So yeah. And at Hornet, we are building
- 0:42
retrieval infrastructure for agents, and, uh, I've been working on search and retrieval problems for a long time. As you can tell, I'm gray-haired. Uh, been working in this space for more than twenty years. Um, and in the talk today, I'll talk about why this kind of thirty-year-old lexical scoring function is, uh, making a strong comeback. First, I will talk a little bit about what I mean by agentic search or agentic retrieval and kind of
- 1:12
define that for, for you, all of you. Um, my definition is that agentic search is essentially search inside a agent loop. So you have an agent that is trying to accomplish a task, write a coding or, uh, do some deep research or whatever task. And inside that, you have some kind of information need for the agent, right, in order to get that task done successfully. And you essentially need three things, uh, to kind of build a good agentic
- 1:42
search system, and that is you need a capable model, a model that is able to use tools and is able to formulate queries. You also need a harness around the model in how you kind of expose the retrieval and the search functions to the model. There's different ways to do that. It could be through tool calling, or it could be through code mode. Um, Edo here, uh, demonstrated what I call code mode for exposing retrieval
- 2:12
infrastructure. So that's the harness part. And then you also need, uh, a retrieval engine to be able to do searches efficiently, potentially over billion-scaled, uh, document sets.
- 2:27
And to define BM25. So BM25 actually stands for Best Match 25. So there were some researchers doing plenty of different experiments, and experiment number twenty-five turned out to be the best one. So that's, that's the background of the name. It's essentially a scoring function. So you can imagine you have a query, and you have a document, and you calculate some kind of score by interaction between the query terms and the document terms, and you come up with a score, and you hope that this score kind of is
- 2:57
a good proxy for the relevancy of the document with regards to the query. Right. So one way to calculate BM25 would be to take all the documents and score each of them, you know, and then figure out what are the top K documents. And then there's, like, thirty or forty years of interest in how you accelerate that type of retrieval. Top K, lots of different algorithms. We also invest a lot in that. I'll show something in this direction, but BM25 is the scoring function, and there is a
- 3:27
way to kind of accelerate top-K retrieval. Uh, BM25 hasn't changed. It's the same scoring function. But the change here is really that we got a more powerful user. Uh, Edo talked about general knowledge. The LLMs today have a lot of general knowledge. They know about entities. They know about companies. They know about dates. They know a lot, right? And by using that kind of implicit knowledge that is built into the parametric model,
- 3:58
uh, they essentially become very good at search. Um, and that's the really change, uh, here now that we're-- is kind of making BM25 more relevant. And BM25 used to be a kind of a baseline function. Any information retrieval research would include a BM25 baseline, and then you would put something fancy, advanced, neural, fancy stuff, and then you would compare it with BM25. I also think it's interesting in how we evaluate search
- 4:27
before, because you will simply look at ten blue links, and you, like how scan it, and you compute some metrics. A lot of that is now going away because the agent is not really... It's kind of powerful in the way that it can type out a lot more queries than a human can do, so it's less relevant to think about, uh, evaluating these systems just by a single-shot query.
- 4:53
And this is one of my kind of favorite benchmarks out there. I like to talk about benchmarks. So BrowseComp+ is a deep research benchmark, uh, published in a paper last year. And it has almost or exactly eight hundred and twen- thirty questions. These are riddle-like. Think about it like a pub quiz. Do you have pub quizzes in the US? Yeah. Okay, great. So like kind of a riddle type of questions, quite long.
- 5:24
And the agent, the harness of this kind of-- or the protocol of this benchmark is that you have a model, and it gets a very simple tool called Search, and it accepts a query string, and you return some snippets back to the model. And the corpus is about hundred and five thousand or a hundred thousand documents, so that's kind of tiny, and these are web documents. And the end-to-end accuracy, um, all of these questions have a golden reference answer, and you can
- 5:54
kind of check if the model and the entire loop produces that exact answer.
- 6:01
Um, but why kind of, why do we need retrieval? I like to compare context windows with floppy disks because I'm old. In the '80s, right, we installed these kind of games on our computers using floppy disks. So one kind of... You guys are so young, so you don't probably have this kind of nostalgia, but one floppy disk could fit about one point four megabytes of data. And the current models, before they start degrading in quality, that's I-
- 6:31
in my opinion, around three hundred and fifty thousand tokens. So that's one floppy disk of data, right? Um, so you need retrieval in order to, um, to fetch the information that you actually need to put into the context window. And BrowseComp+ really demonstrate how, uh, retrieval quality affects the end-to-end accuracy of the task, right? The end-to-end accuracy here is essentially, is the model equipped with this
- 7:01
search tool able to answer the question, right, the riddle-like question? And if you artificially just stuff the evidence documents that is needed to answer this question into the context window of the model, the accuracy is really high, right? So reasoning is not the bottleneck. The model, given the evid-evidence up front, answers the question with a very high accuracy rate, even GPT-4.
- 7:33
Um, but if you expose the model with the harness, with a retrieval tool, uh, that accuracy falls because it now depends on the harness, it depends on the model's ability to formulate queries, and the retrieval quality of the retriever. Um, so for me, this is also quite important because even if we get perfect models, like models that are kind of AGI, you don't have to append, "Make no mistakes," you still will be limited to a context window that
- 8:03
is approximately a floppy disk, right? So you have to decide what goes into that context window, and I think retrieval is still very relevant as the previous slide showed.
- 8:14
And in this BrowseComp+ data set, one of these riddle-like questions become a search trajectory because the model execute the query, gets some response back, reads it, reformulates the query, and continues until it has kind of filled up the context window or found the answer, whatever comes first.
- 8:37
And we spent some time to investigate these trajectories, uh, to see how GPT-5 is formulating queries, and we found a lot of interesting aspects with that. Uh, we described it in a recent blog post as well. You can find it on Hornet.dev. And we like to compare it with, uh, AOL query logs. So AOL, AOL was like a service back in the day, had some
- 9:07
search interface, and they accidentally published, um, a very large sample of what people were searching for on the web, and they were quite short. And I have seen more recent query logs as well, and the user-human pattern are still searching with just a few terms. GPT-5, on the other hand, it's a much more powerful user. It has the general knowledge, and it can like, bam, write out very long queries. It can use
- 9:37
a lot of syntax operators that are kind of useful from... It has learned from web search or site operator phrases, et cetera. And this is a new type of workload.
- 9:52
And on BM25. BM25 has essentially two hyperparameters that controls various aspects of the scoring function. And I talked about having a baseline, and BM25 was usually a baseline, and BrowseComp+ as well has a baseline with BM25, but it turns out that that baseline is terrible. So when you look at fancier techniques, embedding models, what have you, um, it stands out
- 10:22
as a much better retrieval paradigm than BM25 if you look at the or-original paper. But more recent research shows that the parameters that were used in the BrowseComp+ research paper was not really adequate to handle these kind of long documents. So I like this, "Which BM25 do you mean?" Uh, because it has a quite dramatic impact on that specific benchmarks on the overall accuracy.
- 10:50
And why is BM25 now more powerful with the new user? So I mentioned the general knowledge of the user and that he can type faster and more, be more specific as a more powerful user. And exact matching is still relevant, right? Because the model knows names, entities, uh, zip codes, uh, SKUs, what have you, that is not so easy to represent with an embedding model which kind of encodes all the tokens into a fixed vocabulary.
- 11:21
Uh, it's also relatively cheap, especially if you take into consideration the cost of doing embedding inference, right? Some of these embedding models have like eight billion parameters, and you encode text, and you have to stand up infrastructure for this and what have you. So it's quite simple, and also the tooling, uh, in the overall ecosystem is quite good. Um, so it's, it's readily available. And it's also very easy for the model to inspect the results and understand why a certain query
- 11:51
formulation returned the result it did, right? Because you're matching literal terms and phrases and things like that, which can hi- help it kind of reformulate the query. So these are the three key things. And now into more hot topics on, like, what is all you need. Um, and this is a very recent research that came out from Waterloo, from Jimmy Lin's group up there. They are doing a great job at the information retrieval research and
- 12:21
also on agentic search. They have a recent paper that I love. Uh, it's called Scaling Direct Corpus Interaction via Dynamic Workspace Expansion. So I'll spend some time on expanding this. So imagine you want to stand up web search infrastructure for agents. A lot of companies are doing that at the moment. We are also working with some of these companies to help them build infrastructure for powering that kind of use case. And there you have potentially billions of documents,
- 12:52
right? So that doesn't fit into the context window, so you obviously need retrieval, and BM25 is a good baseline. So you can retrieve information over that, and the results of this is, um, you can imagine this as a search engine result per page, SERP, for agents because you can place these documents that are retrieved from the retriever into a workspace. And if you
- 13:22
organize this workspace as a file system, you can, uh, play into the same things that you have around skills. You can have progressive disclosure because you can have the document, like the title of the document and a small snippet of the document, and expose that to the model, and the model can then also decide, "Oh, I need to read more of the document." And when it's doing that, it can use all the primitive tools that it's really good at using. You all use coding agents, so you all seen grep, and ripgrep, and sed,
- 13:52
and awk, and whatever it's doing to kind of manage context. So here you get the benefits of both worlds, and also you get to combine sandbox infrastructure, retrieval infrastructure, so, and VFS, and just Bash, and whatever. So it's also quite exciting, right? Because it combines all of these new type of paradigms that is happening at the moment. So I'm really excited about this type of direction. And it's also kind of a hack, right? To optimize for what the models are good at at the moment, right? Because all the frontier LLM companies are
- 14:22
optimizing their model for co- for coding, for Bash, for tool use. So if you put your kind of end-to-end task on the trajectory of that, you kind of, whatever, there's a new model, you know there's gonna be better at this as well, right? Right. So might be that when we get AGI, they can just use the browser. We'll see. But currently, this is a very powerful way to, to build, uh, retrieval infrastructure and a whole agentic search experience.
- 14:53
And when it comes to evaluation, right? I talked about this earlier as well. In traditional information retrieval, we were used to having just one query, one ranked list, compute nDCG, and compare it. That is no longer very relevant when the new user is a agent, because that agent can reformulate queries and do more queries and do expansion and all, all kinds of different stuff, right? So a lot of the classical information retrieval evaluation is now kind of dead.
- 15:23
Instead, look at, like, see if the model can perform the task it's, it's set to. And for example, for question answering, does it get the answer right?
- 15:35
And we at Hornet, we are betting on BM25 as one of the primitives, and we have set out on a vision to kind of have the best, most efficient way to evaluate, uh, BM25, because I think it's such a strong, fundamental primitive. And this illustration compares some anonymized engines comparing with Hornet on the same type of, um, same type of hardware with, um, web documents, hundred
- 16:05
million web documents on a single node. And as you can see, Hornet has a much more efficient implementation than the other engines and can do more throughput for the same type of bucks, which for a lot of companies that are building infrastructure at the moment for web search, et cetera, means a lot in savings. What is the Y-axis? The Y-axis is QPS. Sorry.
- 16:33
What's the X-axis? The Y-axis is... Oh, sorry. The Y-axis is latency. I'm sorry.
- 16:40
So four claims to take away from this talk. There's a new user. It's more powerful. It's able to type faster. It's able to read faster. It's able to reformulate queries, and it has a lot of general knowledge, which makes simple tools like grep and BM25 more powerful.
- 17:03
That's number one. Number two, which BM25 do you mean? Uh, there are differences in implementation, in performance, in parameters, so think about that. And also, why is it effective for agentic search? It's simply because it's explainable for the model, so the model can see and also use it in combination with grep, right? Because you have literal matches, and grep is almost about literal matches as well. And the combination of these two is a very
- 17:33
strong agentic search or agentic retrieval paradigm.
- 17:39
There's a lot of references. I think I will publish a talk, uh, or the talk will be published and also the, the slides. And if you hated it, you can, uh, tweet at me.
- 17:55
Um, there is not, I was told that there's not a room for, for questions, but happy to chat about retrieval. You will find me around the conference. Uh, probably best way to reach me is through my X account, and that's it.