GrepRAG

🗒️ Description

GrepRAG (arXiv:2601.23254, Jan 2026, Zhejiang University) is the counter-thesis to graph-and-vector retrieval for code: instead of building any index, the LLM generates its own ripgrep commands (~10 per query), runs them against the raw repo, and re-ranks the hits. It’s the academic form of the “agentic search beats RAG” argument that Claude Code and Cline ship in practice.

This is the load-bearing evidence for the grep side of the debate in Structural Retrieval for Code — and the reason the honest position is “match retrieval to task” rather than “structure always wins.”

🧩 How it works

• Naive GrepRAG — LLM emits ripgrep patterns, results ranked by Jaccard overlap.
• Full GrepRAG — adds identifier-weighted / BM25 re-ranking plus structure-aware dedup.
• Index-free — nothing is embedded or pre-graphed, so there is no stale index to drift out of sync with the code. This is the “code drifts out of sync” argument (the same reason Graphify notes the Claude Code team dropped its early vector DB).

📒 Results (self-reported — MEDIUM confidence)

On repo-level code completion (CrossCodeEval Python, DeepSeek-V3.2):

• 42.29% code EM vs RepoFuse 27.50% / GraphCoder 19.44% — i.e. it beat both a retrieval-fusion and a graph baseline.
• +7.04–15.58% aggregate relative EM over the best baseline across settings.
• ~1/35th retrieval latency at the extreme: 1.45s vs >50s on a 754K-LOC Java repo (average ratio ~13×, not 35×).

⚠️ Why I hold this at medium confidence, not fact:

• Non-peer-reviewed preprint, author-self-reported benchmarks, benchmark-selection risk.
• Framing is stretched: the headline 42.29-vs-27.50 cell is ~53.8% relative — far above the cited 7–15% aggregate range — and the 35× latency figure is the single largest-repo extreme. Cite as the paper’s own result, not established truth.

⚔️ Tension with the graph camp

GrepRAG (“grep matches/beats graph & vector” on completion) directly conflicts with RepoGraph (“graph +32.8%” on SWE-bench-Lite bug repair). Best current reading — it’s task-dependent:

• Local line/chunk completion → agentic grep wins (cheap, index-free, no staleness).
• Cross-subsystem edits, multi-file repair → structural graph / LSP wins.

That split is the practical takeaway for a Claude Code harness: grep for local work, structure for changes that cross module boundaries — see the task table in Structural Retrieval for Code.

📖 Further reading / watching

• Preprint: GrepRAG, arXiv:2601.23254
• Cline — why we don’t index your codebase — the first-party manifesto version
• Structural Retrieval for Code — the full taxonomy and when grep beats graph
• RepoGraph — the opposing “graph helps” result
• Progressive Disclosure · Context Engineering · Token Optimization for Claude Code

---

Template: knowledge_note_info