SaraCoder: Repo-Level Code Completion

Updated 8 July 2026

SaraCoder is a retrieval-augmented generation framework that refines retrieved code context and resolves cross-file ambiguity to improve repository-level code completion.
It integrates a three-stage process including database construction, Hierarchical Feature Optimization (HFO), and External-Aware Identifier Disambiguation (EAID) to counter semantic misguidance and redundancy.
Empirical evaluations demonstrate improved code generation accuracy with gains in exact match and identifier F1 metrics compared to existing baseline methods.

SaraCoder is a retrieval-augmented generation framework for repository-level code completion that systematically refines retrieved context and resolves cross-file ambiguity before generation. It is designed for settings in which an unfinished code context $C_{\text{context}}$ in file $F$ depends on types, functions, and classes declared in other files and modules, and it targets three persistent failure modes of standard similarity-based retrieval: semantic misguidance, redundancy and homogeneity, and external cross-file symbol ambiguity (Chen et al., 13 Aug 2025). In adjacent literature, the string “Saracoder” also appears as a source of terminological confusion with Self-Affirmed Refactoring (SAR) and with StarCoder/StarCoder2, but those are distinct topics and neither of those works introduces a tool named “Saracoder” (AlOmar, 2023, Dikici et al., 1 Apr 2026).

1. Repository-level completion as the problem setting

SaraCoder is formulated around repository-level code completion rather than in-file completion. Given an unfinished code context $C_{\text{context}}$ in file $F$ , the task is to predict the next statement $\tilde{y}$ . The defining complication is that the relevant evidence may reside outside the current file, so the system must recover semantically relevant snippets from elsewhere in the repository and resolve imported or aliased identifiers correctly (Chen et al., 13 Aug 2025).

The framework is motivated by three failure modes. Semantic misguidance arises when text-similarity retrievers return snippets that share identifiers or comments with the query but differ in semantics or intent. Redundancy and homogeneity arise when near-duplicate results consume prompt budget without expanding coverage. External symbol ambiguity arises when imports, includes, packages, aliases, overloads, or shadowing leave cross-file references unresolved or mis-resolved, which can propagate into signature mismatches, type errors, and hallucinated members. SaraCoder’s central design choice is therefore to combine semantic cues, structural cues, and dependency-aware identifier resolution in a single retrieval-and-generation pipeline (Chen et al., 13 Aug 2025).

2. End-to-end architecture

The architecture comprises three stages: database construction, code retrieval with Hierarchical Feature Optimization (HFO), and code generation with the External-Aware Identifier Disambiguator (EAID). In the database construction stage, SaraCoder builds a structured codebase with a multi-level Code Context Graph (CCG) integrating control flow, data dependencies, and control dependencies. Program slicing is used to produce induced graph slices per snippet, and the system stores a key-value mapping from graph slices to source code text and metadata such as file and line ranges (Chen et al., 13 Aug 2025).

At retrieval time, the system first performs simple text-similarity retrieval to obtain an initial pool of candidates. HFO then refines this pool hierarchically. The output of HFO is a refined set of top- $k$ candidates $C_{\text{final}}$ . EAID then resolves cross-file identifiers and constructs enhanced external symbol content $P_E$ . The final prompt is assembled as

$P_{\text{final}} = C_{\text{final}} \oplus P_E \oplus C_{\text{context}}.$

This prompt is then passed to the code LLM for completion (Chen et al., 13 Aug 2025).

A plausible implication is that SaraCoder treats retrieval not as a single ranking problem but as a staged filtering problem in which each stage removes a distinct error mode before prompt assembly.

3. Hierarchical Feature Optimization

HFO is the core retrieval mechanism. It consists of Semantic refinement (SAD), duplicate pruning (RAP), structural similarity scoring (TPM), and diversity-aware reranking (DAR) (Chen et al., 13 Aug 2025).

Module	Operation	Function
SAD	Semantic refinement	Keeps semantically aligned candidates
RAP	Duplicate pruning	Removes exact text duplicates
TPM	Structural similarity	Scores CCG alignment with D-SED
DAR	Diversity-aware reranking	Balances relevance and novelty

SAD uses GraphCodeBERT to encode the query $Q$ and each candidate $F$ 0 into 768-dimensional semantic vectors, with tokenized inputs padded or truncated to length $F$ 1 and then $F$ 2-normalized. Semantic similarity is computed as

$F$ 3

To avoid overly strict filtering in sparse repositories, the threshold is set dynamically as the 75th percentile of the similarity scores:

$F$ 4

Encoding results for high-frequency code are cached (Chen et al., 13 Aug 2025).

RAP removes exact duplicates by computing $F$ 5 for each candidate in $F$ 6 and retaining only candidates whose digest has not yet been observed. The paper characterizes this step as $F$ 7 in the number of candidates, with single digest computation approximately $F$ 8 ms and collision probability approximately $F$ 9 (Chen et al., 13 Aug 2025).

TPM introduces structural similarity through a graph-based distance. For the query and a candidate, SaraCoder builds CCGs $C_{\text{context}}$ 0 and $C_{\text{context}}$ 1, where nodes represent code statements or entities and edges represent control flow, data dependencies, and control dependencies. The system defines a designated core node $C_{\text{context}}$ 2 in the query’s graph slice using the heuristic “the node with the largest ID.” Edit operations are then weighted by topological importance: if $C_{\text{context}}$ 3 is the shortest-path hop distance from $C_{\text{context}}$ 4 to the nearest affected node, the weight is $C_{\text{context}}$ 5 with $C_{\text{context}}$ 6. The resulting decaying subgraph edit distance is

$C_{\text{context}}$ 7

and structural similarity is

$C_{\text{context}}$ 8

Exact graph edit distance is NP-hard, so SaraCoder uses heuristic alignment based on node-level affinity, bipartite matching, and BFS distances from $C_{\text{context}}$ 9 (Chen et al., 13 Aug 2025).

DAR applies maximal marginal relevance:

$F$ 0

with

$F$ 1

and

$F$ 2

The reported practical range is $F$ 3– $F$ 4, with $F$ 5. In this design, diversity is not a post hoc convenience but a direct countermeasure against prompt homogenization (Chen et al., 13 Aug 2025).

4. External-Aware Identifier Disambiguator

EAID resolves cross-file symbol ambiguity through dependency analysis and structured symbol tables. For each file, the system extracts method entities and class entities, recording identifier, aliases, line range, signature, scope, and, for classes, a member map. These are organized into a symbol table $F$ 6. Import or include statements are then parsed into a directed dependency graph $F$ 7 over modules or files. For Python, dotted names and relative imports are resolved; for Java, package and import declarations, including static imports, are used (Chen et al., 13 Aug 2025).

Name resolution is expressed as a function $F$ 8 that maps an identifier in context $F$ 9 to a unique definition in $\tilde{y}$ 0, taking into account local scope, aliases, module qualification, overloads, and shadowing. The rules are ordered: local scope wins; aliases are rewritten to canonical names; module-qualified names are split by dots and mapped to file paths; Java overloads are selected by best signature match to call-site arity and types; shadowing prefers the closest lexical scope; and unresolved external libraries are recorded in $\tilde{y}$ 1 for prompt augmentation (Chen et al., 13 Aug 2025).

The prompt construction stage preserves this dependency information. External symbols are ordered by import sequence, method entities may contribute function bodies, and class entities may contribute variable tables and method definitions. The resulting prompt joins refined retrieval evidence with external symbol content and the unfinished local context. The paper’s examples show why this is necessary: in Python, alias resolution distinguishes User as U from another User class in a different module, and in Java, overload resolution prevents selection of the wrong addListener signature (Chen et al., 13 Aug 2025).

5. Empirical evaluation and reported performance

SaraCoder is evaluated on CrossCodeEval and RepoEval-Updated, using Codegen2-7b, Codegen25-7b, CodeLlama-7b-Instruct, and deepseek-coder-6.7b-instruct. The reported baselines are No RAG, Shifted RAG, Vanilla RAG, RepoCoder, and GraphCoder. Evaluation uses Code Exact Match (EM), Edit Similarity (ES), Identifier Exact Match (ID_EM), and Identifier F1 (ID_F1) (Chen et al., 13 Aug 2025).

Benchmark	Scale	Focus
CrossCodeEval	471 repositories and 1368 files for Python; 239 repositories and 745 files for Java; 2665 Python task cases and 2139 Java task cases	Cross-file completion
RepoEval-Updated	10 repositories and 3258 files for Python; 8 repositories and 8260 files for Java; 2000 Python task cases and 1600 Java task cases	In-file completion

On CrossCodeEval, SaraCoder outperforms RepoCoder on average by $\tilde{y}$ 2 EM, $\tilde{y}$ 3 ES, $\tilde{y}$ 4 ID_EM, and $\tilde{y}$ 5 F1 across languages and models. For Java, it often has higher EM and ID_EM with marginal ES and F1 dips, which the paper associates with static typing verbosity affecting ES and F1 more than functional correctness. Accuracy saturates around $\tilde{y}$ 6– $\tilde{y}$ 7, and increasing to $\tilde{y}$ 8 yields no further gains for both GraphCoder and SaraCoder. Under $\tilde{y}$ 9, SaraCoder still improves most Python metrics, while Java ID_F1 trails slightly at low $k$ 0 but surpasses baseline at saturation (Chen et al., 13 Aug 2025).

The paper also reports synergy with other cross-file methods. For Python, RepoCoder + SaraCoder yields improvements of $k$ 1 to $k$ 2 across EM, ES, ID_EM, and F1, and DraCo + SaraCoder yields $k$ 3 to $k$ 4 across metrics. On RepoEval-Updated, SaraCoder surpasses GraphCoder by roughly $k$ 5 EM, $k$ 6 ES, $k$ 7 ID_EM, and $k$ 8 F1 on average, with smaller gains than on CrossCodeEval due to higher snippet redundancy in RepoEval-Updated (Chen et al., 13 Aug 2025).

Ablation results indicate that removing EAID degrades cross-file performance, while removing HFO causes larger drops. Removing CCG further reduces structural understanding and affects TPM effectiveness. These results locate most of the gain in the combination of semantic filtering, deduplication, structural scoring, diversity reranking, and identifier disambiguation rather than in retrieval alone (Chen et al., 13 Aug 2025).

The term “Saracoder” is not stable across neighboring literatures. In one unrelated line of work, SAR denotes Self-Affirmed Refactoring, defined as developers’ documentation of their refactoring activities across the software lifecycle. That work introduces a SAR taxonomy and a model centered on Intent, Instruction, and Impact, designed to integrate commit messages with refactoring detectors such as RefactoringMiner and RefDiff. It explicitly states that it does not introduce or name any tool or model called “Saracoder” (AlOmar, 2023).

A second unrelated usage appears in work on membership inference attacks against code LLMs. There, “Saracoder” is described as appearing to refer to StarCoder or StarCoder2, while the actual contribution is SERSEM, a white-box attack framework that suppresses uninformative syntactical boilerplate and amplifies human-centric coding anomalies. SERSEM is evaluated on StarCoder2-3B and StarCoder2-7B and reports overall AUC-ROC values of $k$ 9 and $C_{\text{final}}$ 0, respectively, outperforming Loss, Min-K% Prob, and PAC baselines (Dikici et al., 1 Apr 2026).

These distinctions matter because SaraCoder, SAR, and SERSEM occupy different technical strata. SaraCoder is a repository-level completion framework; SAR is a refactoring-documentation taxonomy and classification model; SERSEM is a white-box membership inference method for code LLM auditing. The shared string therefore denotes naming overlap rather than methodological continuity.

7. Limitations, implementation guidance, and significance

The paper identifies several limitations. Graph edit distance approximations add overhead, so scaling to very large slices or repositories may require aggressive pruning or caching. EAID is Python-first for import resolution, with Java handled via packages and imports, while broader multilingual support and build-system integration such as Maven, Gradle, or CMake are left for future work. Highly duplicated codebases reduce diversity benefits, and dynamic imports, reflection, metaprogramming, and code generation can defeat static dependency analysis (Chen et al., 13 Aug 2025).

For implementation, the paper recommends building the structured codebase with language-specific parsers, adopting GraphCodeBERT embeddings and the adaptive threshold $C_{\text{final}}$ 1 quantile for SAD, enabling MD5 deduplication in RAP, setting $C_{\text{final}}$ 2 for TPM, using $C_{\text{final}}$ 3 in DAR with $C_{\text{final}}$ 4, and selecting $C_{\text{final}}$ 5– $C_{\text{final}}$ 6 because performance saturates in that range. It also states that SaraCoder is compatible with CodeGen2/2.5, CodeLlama, and deepseek-coder, and that it can work orthogonally with cross-file systems such as RepoCoder and DraCo by refining their retrieved contexts before prompt assembly (Chen et al., 13 Aug 2025).

Within the research landscape, SaraCoder’s significance lies in making retrieval quality itself a multi-dimensional optimization problem. Rather than assuming that lexical similarity is a sufficient proxy for usefulness, it explicitly filters for semantic alignment, removes duplicates, scores structural compatibility through CCG-based distance, reranks for diversity, and only then performs generation with external symbol resolution. This suggests a conception of repository-level completion in which semantic relevance, structural correspondence, and identifier correctness are coequal prerequisites for effective prompting rather than separable engineering refinements.