GrepRAG: Lexical Retrieval for Code Completion

• GrepRAG is a retrieval-augmented generation framework that uses on-the-fly, ripgrep-style lexical search to extract cross-file code context.
• It employs LLM-generated commands combined with BM25 re-ranking and structure-aware deduplication to optimize snippet retrieval without costly indexing.
• GrepRAG outperforms index-based methods with significant gains in exact match accuracy and sub-second latency, making it ideal for interactive code completion.

Searching arXiv for GrepRAG and closely related repository-level code completion RAG work to support the article with current citations. GrepRAG is a retrieval-augmented generation framework for repository-level code completion that uses index-free lexical retrieval, implemented through ripgrep-style search, rather than semantic indexing or graph construction. It was introduced as an empirical study of “grep-like retrieval” for code completion and as an optimization of that retrieval regime through a lightweight post-processing pipeline. In its baseline form, an LLM generates ripgrep commands from the local code context before the cursor, executes those commands over the repository, ranks the resulting snippets, and conditions completion on the retrieved cross-file context. The full framework retains the same lexical retrieval stage but adds identifier-weighted re-ranking via BM25 and structure-aware deduplication and fusion, with reported gains over prior repository-level completion baselines on CrossCodeEval and RepoEval-Updated while maintaining low latency (Wang et al., 30 Jan 2026).

1. Definition and problem setting

GrepRAG addresses repository-level code completion, a setting in which the completion target depends on code distributed across multiple files rather than solely on the current function or file. The motivating claim is that modern LLM-based code completion degrades when the “true” context is spread across hundreds or thousands of files, because essential cross-file dependencies such as class definitions, utility functions, and global constants cannot all fit into a finite context window. The framework is designed for cases where relying only on intra-file context leads to wrong or incomplete suggestions (Wang et al., 30 Jan 2026).

The central design decision in GrepRAG is to treat lexical retrieval as a first-class retrieval primitive. Instead of constructing semantic indexes or graph representations of the repository, GrepRAG uses on-the-fly grep-like matching over raw source text. This is motivated by the observation that human developers often use lightweight search utilities such as grep or ripgrep to locate definitions by name, and by the claim that existing semantic-index RAG and graph-based retrieval methods incur substantial computational overhead for offline index or graph construction and frequent re-indexing as code evolves (Wang et al., 30 Jan 2026).

Within this formulation, the repository is searched at inference time using LLM-generated ripgrep commands derived from the local context. The retrieved snippets are then filtered and assembled into a prompt for the completion model. A plausible implication is that GrepRAG belongs to a broader family of retrieval systems that prioritize interactive responsiveness and low systems complexity over richer but more expensive retrieval structures.

2. Naive GrepRAG and lexical retrieval mechanics

The baseline variant, Naive GrepRAG, provides the core retrieval loop. Its workflow has five explicit steps. First, the LLM examines the local context before the cursor, denoted as $\mathcal{C}_{\text{local}}$. Second, it generates up to $m$ ripgrep commands $\{q_1,\dots,q_m\}$. Third, each command is executed deterministically over the entire repository to produce a set of raw code snippets $\{C_i\}$. Fourth, each snippet is scored by lexical overlap with $\mathcal{C}_{\text{local}}$ using Jaccard similarity. Fifth, the top-$K$ snippets are concatenated after the local context and supplied to the LLM for completion (Wang et al., 30 Jan 2026).

The command-generation stage is intentionally simple. The model is prompted to output up to $m=10$ rg commands that string-match class names, method names, variable names, or wildcard patterns likely to retrieve relevant cross-file context. The reported examples include:

$\{C_i\}$7

This operationalizes retrieval as LLM-guided lexical search rather than vector search or static-analysis traversal (Wang et al., 30 Jan 2026).

The Naive GrepRAG scoring function is likewise minimal. For each candidate snippet $C_i$, the score is computed as the Jaccard overlap of token sets:

$$\text{score}[C_i] = \frac{|\text{Tokens}(C_i) \cap \text{Tokens}(C_{\text{local}})|} {|\text{Tokens}(C_i) \cup \text{Tokens}(C_{\text{local}})|}.$$

This baseline is important because the reported empirical results indicate that even this simple lexical retrieval regime already achieves performance comparable to sophisticated graph-based baselines, suggesting that repository-level code completion often benefits from lexically precise fragments that are spatially closer to the completion site (Wang et al., 30 Jan 2026).

3. Failure modes of pure grep retrieval

The GrepRAG study identifies three failure modes for Naive GrepRAG through error analysis. These failure modes motivate the two post-processing components of the full system (Wang et al., 30 Jan 2026).

Keyword ambiguity (“Noisy Matches”): Common identifiers such as init and config appear widely across repositories. Because ripgrep returns many snippets containing these tokens, and because Jaccard re-ranking treats all tokens equally, noisy fragments with many common tokens can outrank snippets that are semantically more relevant but lexically less frequent (Wang et al., 30 Jan 2026).

Context fragmentation and redundancy: Multiple grep queries often match overlapping or adjacent lines in the same file. In the naive pipeline, each hit is treated independently, so duplicate or near-duplicate lines consume context budget without adding information. The study also notes that chronological order can become scrambled, for example with usage appearing before definition, which can disrupt logical flow in the assembled prompt (Wang et al., 30 Jan 2026).

Implicit dependencies: Some cross-file relations, including inheritance and interface implementation, have no explicit common identifier in the local context. Pure grep therefore cannot retrieve such dependencies at all, producing a recall failure. This limitation is conceptually distinct from noisy matching: it reflects lexical absence rather than ranking error (Wang et al., 30 Jan 2026).

These observations place GrepRAG within a specific retrieval design space. Its strengths are lexical precision, zero offline indexing cost, and low latency; its weaknesses arise when relevant dependencies are only weakly lexicalized in the local context.

4. Post-processing architecture of GrepRAG

The full GrepRAG pipeline preserves the exact same ripgrep retrieval stage as Naive GrepRAG but adds two cascaded post-processing steps: identifier-weighted re-ranking via BM25, and structure-aware de-duplication and fusion (Wang et al., 30 Jan 2026).

Identifier-weighted re-ranking

In the first stage, each retrieved snippet $C_i$ is treated as a document and the local context $m$0 is treated as the query. GrepRAG computes the standard BM25 score

$m$1

where

$m$2

Here, $m$3 is the raw frequency of token $m$4 in snippet $m$5, $m$6 is the snippet length in tokens, and $m$7 is the average snippet length over all candidates. The stated effect is that rare, task-specific identifiers such as Deck and draw are up-weighted, while high-frequency generic tokens are down-weighted (Wang et al., 30 Jan 2026).

Structure-aware de-duplication and fusion

In the second stage, each snippet is tagged with its source file and matched line interval. The BM25-ranked snippets are sorted by decreasing score, and the algorithm iterates through that ranked list, merging any new snippet whose interval overlaps or is adjacent to an existing fused block. If intervals $m$8 and $m$9 are merged, the new interval is $\{q_1,\dots,q_m\}$0, after which the full contiguous code block is re-extracted from the file. This continues until at least $\{q_1,\dots,q_m\}$1 fused blocks are obtained or the top $\{q_1,\dots,q_m\}$2 of the BM25 list is exhausted; in practice, the reported setting is $\{q_1,\dots,q_m\}$3 (Wang et al., 30 Jan 2026).

The resulting overall pipeline is:

$\{C_i\}$8

The ablation results indicate that these two additions are not equally important: deduplication yields the larger single gain, and BM25 provides an additional boost once redundancy has been removed (Wang et al., 30 Jan 2026). This suggests that prompt budget efficiency and structural coherence are central to GrepRAG’s effectiveness, not merely better lexical ranking.

5. Experimental setting and empirical results

The evaluation covers two benchmarks: CrossCodeEval and RepoEval-Updated. CrossCodeEval includes Python and Java repositories, with 2,665 Python test examples and 2,139 Java examples, all requiring cross-file context. RepoEval-Updated includes 10 large Python repositories and 10 large Java repositories, with up to 577 K LOC for Python and up to 754 K LOC for Java, and 4,000 examples per language (Wang et al., 30 Jan 2026).

The evaluation metrics are defined for both code match and identifier match. The reported metrics are Exact Match (EM), Edit Similarity (ES), Recall, and F1, along with retrieval latency measured as CPU time per query. All methods limit total prompt length to 4,096 tokens and retrieve Top-10 snippets. The reported backbones are DeepSeek-V3.2-EXP and Qwen3-Coder-Plus with temperature $\{q_1,\dots,q_m\}$4. For GrepRAG itself, the reported hyperparameters are $\{q_1,\dots,q_m\}$5 ripgrep queries, BM25 parameters $\{q_1,\dots,q_m\}$6 and $\{q_1,\dots,q_m\}$7, and fusion cutoff $\{q_1,\dots,q_m\}$8 (Wang et al., 30 Jan 2026).

The baselines listed are NoRAG, VanillaRAG, GraphCoder, RepoFuse, and RLCoder (Wang et al., 30 Jan 2026).

Benchmark/result category	Reported result
CrossCodeEval, Naive vs prior best	Naive GrepRAG outperforms the best prior baseline (RLCoder) by 2–4 points EM
CrossCodeEval, full system	Full GrepRAG reaches 42.3% EM (Python) and 43.1% EM (Java)
CrossCodeEval, relative gain	Relative Code EM gains over strongest baselines: +7.0%–15.6%
CrossCodeEval, identifier quality	Identifier F1 improves by +2.8–4.3 points
RepoEval-Updated latency	GrepRAG 0.2–0.6 s vs. GraphCoder 7–50 s
RepoEval-Updated, Python line-level	Naive 41.5 EM $\{q_1,\dots,q_m\}$9 GrepRAG 44.9 EM
RepoEval-Updated, Python API-level	Naive 35.8 $\{C_i\}$0 GrepRAG 40.7 EM (+13.8% relative)
RepoEval-Updated, Java API-level	Naive 40.3 $\{C_i\}$1 GrepRAG 45.7 EM (+13.4% relative)

The main quantitative summary in the abstract states that GrepRAG “consistently outperforms state-of-the-art (SOTA) methods,” achieving “7.04-15.58 percent relative improvement in code exact match (EM) over the best baseline on CrossCodeEval” (Wang et al., 30 Jan 2026). The more detailed section-level results state the corresponding range as +7.0%–15.6%, which is consistent at the level of rounding (Wang et al., 30 Jan 2026).

Ablation on CrossCodeEval (Python/DeepSeek) further decomposes the contribution of the two post-processing stages. The reported EM values are 39.1% for BM25 without deduplication, 41.9% for deduplication without BM25, and 42.3% for the full system, relative to the Naive baseline. The interpretation given is explicit: deduplication yields the larger single gain, and BM25 fine-tuning yields an additional boost once redundancy is removed (Wang et al., 30 Jan 2026).

Hyperparameter analysis reports an inverted U-curve when varying the percentage $\{C_i\}$2 of BM25-ranked candidates fed into deduplication from 10% to 90%, peaking at $\{C_i\}$3. Too small an $\{C_i\}$4 under-samples diversity, while too large an $\{C_i\}$5 re-introduces noise (Wang et al., 30 Jan 2026).

6. Latency, scalability, and implementation characteristics

A defining property of GrepRAG is that it is index-free. The work contrasts this with semantic-index RAG and graph-based retrieval, which are said to require heavy offline index or graph construction taking minutes to hours and frequent re-indexing as repositories evolve. For large repositories of 100 K–700 K LOC, the reported retrieval latency of those methods often exceeds 5–50 seconds per query, which is characterized as unacceptable for an interactive IDE (Wang et al., 30 Jan 2026).

By contrast, the GrepRAG study reports end-to-end latency under 1 second in the abstracted motivation section and 0.2–0.6 seconds on RepoEval-Updated in the detailed quantitative results (Wang et al., 30 Jan 2026). The key systems claim in the takeaways is that GrepRAG is index-free, scales linearly with local context size rather than repository size, and can be integrated into interactive IDEs with sub-second retrieval (Wang et al., 30 Jan 2026).

The query-generation stage appears robust across model choices. Swapping the instruction-generator LLM between DeepSeek and Qwen produces near-identical downstream completion performance, with less than 1 point EM difference. The paper therefore concludes that query generation is a stable capability across modern models (Wang et al., 30 Jan 2026).

The framework also includes a distilled 0.6 B variant for grep keyword generation. Fine-tuning a 0.6 B Qwen2.5 model to emit only the grep keyword, with the remainder of the command filled by a template, reduces command-generation latency. The reported outcome is comparable or better Code EM on RepoEval than vanilla Qwen3-Coder-Plus, with RAG pipeline time of approximately 2 seconds, still substantially lower than the 7–50 second range reported for graph-based methods (Wang et al., 30 Jan 2026).

These results indicate that GrepRAG is not only a retrieval strategy but also a systems optimization for deployment conditions where indexing cost, maintenance burden, and query latency are decisive constraints.

7. Relation to redundancy-aware retrieval and broader significance

GrepRAG is centered on code retrieval, but its optimization logic resonates with a broader line of work on context selection under token budgets. In particular, “AdaGReS: Adaptive Greedy Context Selection via Redundancy-Aware Scoring for Token-Budgeted RAG” formulates context selection as a set-level objective combining query-chunk relevance with intra-set redundancy penalties, and performs greedy selection under a token-budget constraint using marginal gains derived from that objective (Peng et al., 31 Dec 2025). AdaGReS also introduces a closed-form, instance-adaptive calibration of the relevance–redundancy trade-off parameter and provides an $\{C_i\}$6-approximate submodularity analysis with a greedy near-optimality guarantee under practical embedding-similarity conditions (Peng et al., 31 Dec 2025).

This comparison is instructive because GrepRAG’s structure-aware deduplication addresses a closely related problem—redundant or overlapping retrieved context consuming prompt budget—though by line-interval fusion rather than by explicit set-function optimization. A plausible implication is that GrepRAG can be understood as a lexical, code-specific instantiation of a more general redundancy-control principle in RAG systems: retrieval quality depends not only on relevance of individual units, but also on the non-redundant utility of the retrieved set (Peng et al., 31 Dec 2025, Wang et al., 30 Jan 2026).

At the same time, GrepRAG does not claim to solve all repository-level dependency retrieval problems. Its documented failure mode on implicit dependencies remains significant, because some relations are not recoverable through shared identifiers alone (Wang et al., 30 Jan 2026). This constrains the scope of purely lexical retrieval and marks the boundary at which more expressive retrieval mechanisms may become necessary.

The principal significance of GrepRAG lies in the empirical argument it makes about that boundary. The reported results suggest that simple, on-the-fly lexical retrieval guided by an LLM already rivals or exceeds complex graph- or embedding-based RAG in many repository-level completion settings, and that two lightweight post-processing steps—BM25 re-ranking and structure-aware deduplication—are sufficient to correct the major failure modes of naive grep retrieval (Wang et al., 30 Jan 2026). In this sense, GrepRAG repositions lexical search from a baseline heuristic to a competitive retrieval architecture for interactive code completion.