AI Engineer World's Fair 2026
Where RL Will Take Search — Maximilian-David Rumpf, SID.ai
Read the talk
Where Reinforcement Learning Can Take Search
Maximilian-David Rumpf explains why a search model should be able to inspect results, change its approach and try again—and how a trained specialist can make that process cheaper while keeping the main agent’s context cleaner.
From a talk by Maximilian-David Rumpf
At a glance
Ideas worth remembering
A reranker can recognize inadequate candidates without being able to obtain better ones. An iterative search model can use retrieved material to choose another query or metadata filter.
Search supports reinforcement learning through checkable document outcomes and repeated training attempts. Latency rewards can encourage efficient behavior alongside successful retrieval.
Rumpf reports around five seconds per search instead of around two minutes, at roughly one hundredth of frontier-model search cost on the task. The specialist still has higher latency than a vector-and-reranker pipeline.
A search sub-agent keeps exploratory material out of the main agent’s context and moves retrieval work onto a cheaper model. Its document selection still determines whether the returned context is useful.
Internal organizational knowledge is a central opportunity for better retrieval. Unlimited improvement and future voice or e-commerce applications remain forecasts; the method’s ultimate ceiling is unknown.
Better retrieval comes with an expensive search phase
Finding the right documents can consume much of an agent’s effort before it starts the work the user requested. Maximilian-David Rumpf, founder and CEO of SID.ai, opens with the comparison driving his research: agents are about twice as likely to find the right documents as classical search, but cost roughly 100–1,000 times more per search and take minutes rather than milliseconds. Better context comes with a substantial bill.
Rumpf estimates that searching uses 30–50 percent of an agent’s tokens, usually at the beginning of a task. The agent needs to gather context before it can act on it. His proposed division of work follows that dependency: the main agent delegates searching to a sub-agent trained specifically for retrieval, then uses the returned material to perform the task. Reinforcement learning is the proposed way to make that specialist faster and cheaper.
The target spans legal, finance, knowledge bases, science and email, using a mixture of academic and internal benchmarks. Rumpf presents vector-only retrieval and reranking as lower-performing baselines, while frontier models improve retrieval by spending minutes on each question. The goal is to retain high recall—the ability to find the relevant documents—while reducing the time and cost of the search phase. These comparisons concern the workloads he presents; they do not establish the same improvement for every corpus or question.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A reranker can recognize failure without being able to fix it
The classical pipeline Rumpf describes follows a fixed route: a question enters, an optional LLM rewrites it, a search backend retrieves candidates, and an optional reranker orders them before the system returns results. These are chained, locally optimized models. Improving a component can make its particular operation better, but the sequence still determines which operations happen and how much computation each question receives.
The reranker exposes the problem most clearly. It may recognize that the retrieved documents do not adequately answer the question. Yet it can only reorder the candidates it already has; it cannot obtain better ones by launching another search. The system has detected insufficient evidence without giving that detection an action that could repair the failure. It returns the results anyway.
Unexpected questions then produce a long tail of failures. Developers add special cases and tweaks for questions the original design did not anticipate, but no finite collection of exceptions covers every future request. Rumpf’s objection is to making retrieval decisions once, during system design, and applying them uniformly even when the results reveal that a different approach is needed.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Let the model decide what to search next
Rumpf motivates learned search strategies through two earlier changes in machine learning:
- Computer vision: his progression moves from handwritten edge detection to narrow object detectors—the generation of models that could put a box around a dog—and then to more general vision-language models.
- Chess: his analogy moves from human-authored rules, through systems combining approaches, toward learned strategies in AlphaZero and MuZero.
He expects search to follow a similar progression: established algorithms such as BM25 and PageRank, then specialized vector models and rerankers, then a model trained to make retrieval decisions throughout the search.
Results become input to the next decision
The proposed mechanism is a loop between one model and a database. The model searches, reads what came back, and decides what to do next. It can search again, set metadata filters during the process or constrain the search before eventually returning a ranked list of documents. The results of an unsuccessful query can therefore change the next retrieval action. That is the capability missing from the fixed pipeline.
The loop also lets effort vary with difficulty. A difficult question can receive more computation and more iterations than an easy one. Rumpf wants the model to discover useful strategies rather than follow a prescribed sequence. His description of removing baked-in decisions applies to the model’s search behavior: the system still supplies actions such as searching and filtering, and training still defines rewards. The learned policy decides how to use those opportunities and when to return results.
Chooses searches and metadata filters; decides whether to continue.
The model reads retrieved material before choosing another query or filter. When it decides the search is sufficient, it returns ranked results.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Search offers a checkable reward and a repeatable environment
Reinforcement learning needs feedback that distinguishes successful attempts from unsuccessful ones, plus enough opportunities to attempt the task. Rumpf identifies two useful properties of search:
- Verifiable outcomes: for a training question, the system can check whether the model found the correct document. The retrieval outcome supplies a concrete reward target.
- Repeatable attempts: the model can try the task many times in a search environment. Rumpf describes thousands of attempts per second during a training run.
This makes it possible to train search behavior through repeated outcomes rather than write a rule for every retrieval situation.
Specialization supplies another route to efficiency. Rumpf argues that strong search does not require all the capabilities of a general-purpose language model. He compares CPUs, GPUs and ASICs: a general device may be able to do the work, while a specialized one performs it much more effectively. The analogy motivates narrowing the model’s job. It does not specify which language-model components can be removed or what architecture produces the savings.
Reward successful retrieval and efficient searching
In an earlier training task, Rumpf reports that search quality increases predictably with compute, alongside vector-only and reranker-only baselines. Training can also include latency rewards, so the model has a reason to find documents efficiently as well as correctly. The desired behavior is discovered through training rather than imposed as a fixed sequence of queries.
Rumpf says the team has not yet seen a ceiling to this approach, but he explicitly leaves open whether one exists. Continued improvement in the observed training regime supports further scaling experiments; it does not establish unlimited improvement across all domains.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A faster specialist also keeps the main context cleaner
Rumpf returns to the initial comparison with SID-1, including a configuration with parallel execution. He reports approximately 20 times faster searching: around five seconds on average instead of around two minutes, at roughly one hundredth of the cost of a frontier model on the task. Both the times and the speedup are rounded comparisons. Benchmark composition, retrieval quality and execution configuration matter when deciding whether those gains will transfer to another workload.
The specialist still takes longer than a vector-and-reranker pipeline. Rumpf expects that gap to narrow, but classical retrieval latency remains a future target. The decision therefore involves three measures together: retrieval quality, latency and cost. A large improvement over frontier-model searching does not erase the simpler pipeline’s speed advantage.
Keep exploration in the search agent’s context
The production example adds a second reason to delegate. When the main agent searches directly, it encounters both useful documents and bad results. All of that exploratory material enters the context it carries into the rest of the task. A search sub-agent can do the reading, thinking and iteration separately, then return selected results. The main agent gets the useful output without carrying the full search history.
Rumpf expects cleaner context to make the main agent more likely to be correct. That benefit depends on the search specialist finding and selecting the right documents; a separate context window cannot guarantee that its output is good. The mechanism reduces exposure to unsuccessful exploration, while retrieval quality determines whether the material that replaces it actually helps.
Delegation also moves the search work associated with that initial 30–50 percent token share onto the cheaper model. This is a saving within the task: making the search phase about 100 times cheaper does not make the complete task 100 times cheaper, because the main agent still performs the work after retrieval. The economic benefit grows with the amount of search the task would otherwise require.
Reads useful and unsuccessful results while exploring.
Direct searching exposes the main agent to exploratory results. Delegated searching keeps that exploration in the specialist and returns selected documents.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The destination is knowledge inside organizations
Rumpf closes by forecasting arbitrarily good search across domains as reinforcement learning scales. He also expects faster and cheaper models to make iterative search practical in voice and e-commerce. These are proposed destinations beyond the reported results. His earlier acknowledgment that the method’s ceiling is unknown remains an important qualification on the prediction of unlimited improvement.
The larger opportunity, in his view, is knowledge work over information that public web search cannot supply. He argues that the web contains only a small part of the data available and uses J.P. Morgan as his example: the knowledge needed to run the organization sits deep inside its databases. His claim concerns the operational knowledge held within an organization, rather than information a public search engine can readily retrieve.
That ending gives the search specialist a concrete purpose. The main agent needs the right context before it can do useful work, and much of the relevant context may be inside an organization. A model that can inspect results, refine its search and return selected documents could make more of that knowledge usable without forcing the main agent to spend its own expensive context on every attempt.
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
SID’s overview of the retrieval model discussed in the recording, with benchmark recall, latency and cost comparisons.
The search research lab Rumpf introduces, with links to its research and model waitlist.
Further reading
A companion explanation by Max Rumpf and Sam Dauncey covering training rewards, learned tool choices, parallel searches and the backend demands of large-scale rollouts.
Read the complete timestamped transcript
- 0:12
Okay. Today I'm gonna talk about where reinforcement learning will take search. And some, some background on me. Uh, I'm the founder and CEO of SID.ai. We're a stealth-ish AI lab for search. We're backed by some pretty amazing people, uh, and we're hiring.
- 0:35
Okay. Agents are a new paradigm for search. You can now get vastly higher quality results, um, twice as likely to find the right documents. But it's incredibly expensive, um, about a hundred to a thousand times more expensive than what you'd get out of a classical search query. And it is extremely slow. You're looking at minutes and not milliseconds like TurboPuffer.
- 1:05
And what this means is that agents spend thirty to fifty percent of their tokens on searching, and this is usually at the beginning of some task. It finds the right context to then do whatever you ask it to do. And the idea here is quite simple. First, instead of having the main agent do the searching, you pass the searching to a sub-agent, and you train a model to be a great sub-agent. And the question here that we'll answer today
- 1:36
is how much cheaper and faster can we make this with reinforcement learning? And this is really our target. So this is a benchmark across legal, finance, knowledge bases, science, email, a bunch of different tasks, some academic benchmarks, some internal benchmarks. And this is where you currently are. You see reranker and vector-only performance at the bottom, and you can see frontier models essentially kind of like go through here
- 2:06
at the cost of spending many, many, you know, minutes per question. And can we get a model to kind of like be extremely accurate, um, have extremely high recall, but also be incredibly fast and cheap. And let's quickly look at classical search. Uh, this is the pipeline that many of you guys will be familiar with. A question comes in. You might have an LLM that rewrites the question. You then execute that on a search backend. You might have a reranker, um, and
- 2:36
you get your results at the end of the day. Um, it is essentially a pipeline of chained, locally optimized models. And all of the decisions are baked in at design time. And you expend a fixed amount of compute per question. And this one is really important. The reranker might know that the results are insufficient at answering the question, but the reranker can't take action. It can only essentially return the results even when they're bad. And what this means is that in practice,
- 3:06
a pipeline like this accrues a long tail of failure where unexpected questions come that, you know, the designer didn't have something for. And in practice, this usually means people add lots of edge cases, um, to essentially fix these. But of course, you can't design infinite edge cases, and you can't add infinite tweaks. And so the strategy here is one that we've seen before. Machine design outperforms human design.
- 3:36
Um, and we saw this in computer vision where you had your, you know, primitive edge detection algorithms. You then had the box around a dog generation of models, um, that were very good at this like very narrow task and locally optimized for it. And then you had VLMs that were extremely good at all parts of the search pipeline. You saw this again with chess, with IBM Deep Blue being largely a collection of human-written rules, um, Stockfish bridging the two, and then AlphaZero and MuZero essentially
- 4:05
completely just putting it all inside of the model. And we're gonna see something similar happen to search, where we have our existing algorithms like BM25 and PageRank. Um, then we had an evolution from that with small models that did some tasks very well, like vectors and rerankers. And now essentially this new paradigm of pure RL where we actually don't bake any design decisions into the model. And what this looks like in practice is, um,
- 4:36
something like this. Um, so you have one model. Uh, it goes back and forth with the database. It can search, it can read results, it can iterate, uh, it can search again until it is happy. It can set metadata filters on the fly. It can constrain its search. It can try as much as it wants. Uh, and in the end, it produces a ranked list of results. Uh, and what you get is a model that makes all of the decisions and can adapt to any question on the fly
- 5:06
and, for example, use much more compute if a user asks a very difficult question. And what helps us here is that search is verifiable, um, and reinforcement learning needs rewards that are verifiable and grindable. Verifiable here means for a given question, did you find the correct document? And we can design this and tell this quite easily. Um, and is there an environment where the model can attempt this question loads and loads of times? And in practice for us this means, uh,
- 5:35
thousands of times per second during a training run. Uh, and the second part is kind of like, can we turn the models that are currently very general and very general purpose into something that is much more specialized? And it turns out we don't actually need most of the parts of a language model to be extremely performant at search. Uh, and similarly with like CPUs and GPUs and ASICs, um, a CPU in theory can do anything that a GPU can do. But you would never want to use a CPU to do LLM
- 6:05
inference, for example, um, because the much more specialized version is much more effective. And this really makes search an ideal target for RL. Um- And this is what happens when you train a model on this task. And so again, here we added the vector and reranker-only baselines. This is of an earlier task. And what we see is that search quality increases very predictably with compute. And we can mix in other rewards like latency, um, and different kind of like retrieval strategies to make it even more performant.
- 6:35
Importantly, we don't really tell the model what to do. Much like in AlphaZero in chess, we want it to discover its own strategies and its own tricks to essentially search well. Uh, and we don't know whether this method has no ceiling, but we're definitely not yet seeing a ceiling to this approach. And these are the results. Uh, so this is the same chart as before, and this is SID-1 and then SID-1, um, with some parallel execution on the left-hand side. And so what this ends
- 7:05
up meaning is you get-- you're about twenty times faster, so instead of taking around two minutes, you take around five seconds on average. And it's about a hundred times cheaper than using a frontier model for this task. Uh, there's some more detail here, but like yeah, the cost and kind of like speed are just completely incomparable. Uh, you can-- Yeah, um, it's not quite at the latency of a vector and reranker pipeline, but in practice, we think we can get there quite quickly.
- 7:36
And how does this look like in production? So this is a usual kind of like agent execution trace. The agent does some searching here. It finds some good stuff. It finds some bad stuff. Um, but all of the bad stuff that it finds is essentially polluting its own context window. And what we can instead do is use, um, a sub-agent here that does all of the searching and thinking and iterating for the main agent, and the main agent only ever sees great results. And this means that the main agent sees more good stuff, which means it's more likely to be correct. And it
- 8:06
is also, um, extremely cost-effective, uh, where those thirty to fifty percent tokens that were earlier used by the main agent to do searching can now be passed off to this just, you know, hundred X cheaper search sub-agent.
- 8:23
Uh, and
- 8:28
where will this take us? Scaling RL will give us arbitrarily good search in any domain.
- 8:35
And RL models will become even faster, which will allow them to be used in things like voice and e-commerce. They'll become even cheaper than we are currently. Um, so the charts that you saw there, but like I think we can move even further. Uh, and better search will unlock more knowledge work tasks. Uh, the web is actually quite small, uh, in comparison to the entirety of data that is there-- uh, that is out there. Uh, and the most valuable information is
- 9:05
not on the internet. For example, how to run J.P. Morgan is nowhere on the web, but it is deep inside of the databases at, at J.P. Morgan. That's it for me. Thank you.