A New Role for Relevance: Guiding Corpus Interaction in Agentic Search
Tencent and IIE-CAS researchers introduce RARG, a Relevance-Aware RipGrep Search Agent that turns document relevance scores into an execution priority for grep-style corpus search — ordering which files get scanned first, seeding the agent with relevant entry-point paragraphs, and reranking raw match output so the most informative excerpts survive truncation. On BrowseComp-Plus the system hits 84% accuracy with GPT-5.4-mini using 23.9 average tool calls versus 99.1 for vanilla Direct Corpus Interaction, and scales to 1M documents retaining 79% accuracy where RISE drops to 69%.
Transcript
Pippa Okay so ripgrep. I did not expect to be this interested in a paper about ripgrep.
Tyler I mean, it's not really about ripgrep. Ripgrep is just the tool they happened to use. The actual idea is about WHERE the agent looks first, and that turns out to matter a lot more than I expected going in.
Pippa Right, so walk me through the baseline problem, because I think it's easy to miss why this is even a gap.
Tyler So you've got two camps in agentic search. Classic retrieval agents rank the corpus by relevance and hand the model a top-k set of documents or snippets. That works fine until the evidence is split across documents, or the decisive fact is buried in a span that got cut by snippet truncation. Direct Corpus Interaction — DCI — tries to fix that by letting the agent grep raw files directly. But the catch is that grep scans the corpus as if every location is equally promising.
Pippa And the convergence cost compounds as the corpus gets bigger. The paper has a number on that — vanilla DCI averages 99.1 tool calls on their hundred-thousand document setup, versus 23.9 for their full system. That's not a marginal difference.
Tyler Yeah, 99.1 is genuinely bad. It's not that DCI is dumb, it's that it's relevance-agnostic at execution time. Relevance was being used to build the workspace, but then inside the workspace, the agent just grepped in arbitrary order. Which is the actual insight of the paper — use relevance as an execution prior, not just a filter.
Pippa Right.
Tyler So RARG takes an embedding retriever, scores the documents against an agent-generated query, and passes that ranked order to ripgrep as the traversal sequence. Most relevant documents get scanned FIRST, and if the output gets truncated, you've already seen the good stuff. Then RARG+ seeds the agent with query-relevant paragraphs before the first grep — so instead of writing a blind first pattern, the agent has a real foothold.
Pippa That last one is the part I find most interesting from a product angle. The problem in a lot of retrieval pipelines isn't that the answer isn't in the corpus — it's that it gets BURIED by the output window. Reranking the match pool is a clever way to solve that without touching the underlying model at all.
Tyler And it's cheap. The reranking step is over already-fetched matches, not an extra retrieval pass. The whole architecture is additive — you're composing existing tools, an embedder, ripgrep, a reranker — rather than training something new.
Pippa How does it hold up when they actually stress-test the scale?
Tyler The 1M document result is honestly the number I'd point to. RARG++ retains 79% accuracy at 1M documents. RISE, which is the strongest prior method, drops to 69%. So the gap widens under scale pressure, which is exactly what you'd want if you're thinking about deploying this on a real enterprise corpus. The BRIGHT results are also worth mentioning — reasoning-intensive retrieval, nDCG@10 as the metric. RARG+ scores 53.36, beating DCI, RISE, and the NeMo retrieval agent.
Pippa Yeah, that's the tell. A lot of these systems look great at benchmark scale and then quietly fall apart when someone points them at an actual data warehouse.
Tyler My honest caveat is that the whole thing is gated on retriever quality. If your retriever is weak on a specific domain — legal, biomedical, whatever — you're front-loading the wrong documents and the convergence benefit partially evaporates.
Pippa That's fair. Although I'd argue even a mediocre retriever probably beats random traversal order, which is what you had before. I just wouldn't want someone to assume it's robust to a bad retriever without testing it on their actual data.
Tyler Yeah. And framing it out a bit — the traversal order IS a routing policy. This is a pretty clean example of the infrastructure-as-product move — the model doesn't get smarter, the harness around it gets better at exposing the right work at the right time.
Pippa Which is a sentence we have said, in various forms, since roughly episode seven-ninety.
Tyler At some point we should just tattoo 'the harness gets simpler as the model gets stronger' somewhere and call it a thesis.
Pippa Okay, but this one actually inverts that a little — the harness gets SMARTER, not simpler. It's adding orchestration that wasn't there.
Tyler That's a good catch. The simplification pattern holds at the prompt layer; at the execution layer, you're adding structure. Both moves improve outcomes. They're just operating at different levels.
Pippa Right, and that's probably the more honest version of the thesis anyway. Code is on GitHub — the repo is called RARG, under LeqsNaN slash RARG — so if you're building something in this space it's actually inspectable, not just a paper claim.
Tyler Yeah, and it's ripgrep under the hood, which is a tool people already have. The integration surface is pretty small. I'd expect someone tries to drop this into a LangGraph-style execution graph within the month — seventy percent.
Pippa I'll take that bet. Alright, Tyler — same time next week, assuming the ground doesn't move again.
Tyler Don't say that.