核心要点
- 问题/背景
- 这篇论文把 repo context 注入从长上下文/RAG 或每仓库微调，转成 hypernetwork-generated LoRA adapters。目标是让代码模型获得仓库级 API、import 和 project conventions，同时不增加推理时 token 成本。
- 方法/机制
- Code2LoRA-Static 把稳定仓库快照转成 adapter；Code2LoRA-Evo 用 GRU hidden state 随代码 diff 更新 adapter，面向正在演化的代码库。
- 结果/证据
- 论文还构建 RepoPeftBench，覆盖 604 个 Python 仓库，包含静态和 commit-derived evolution 两条任务轨道，用来评估 repo-specific PEFT。
- 收录价值
- 收录价值在于它给 coding agents 和代码模型提供了一个可复用的参数化仓库记忆接口：仓库知识不一定只存在检索上下文里，也可以以低秩 adapter 的形式随软件演化更新。
原始摘要与中文对照
中文对照翻译
以长输入的形式，通过RAG（检索增强生成）或依赖分析检索相关文件，并在每次查询时为检索到的上下文付费。这成本高昂，因为仓库级别的上下文可能非常庞大，会给LLM的上下文窗口和RAG的检索能力带来压力。另一种方法是针对一个仓库或一组相关仓库微调模型或LoRA适配器（Hu et al., 2022），将知识推入参数中。这些方法也需要昂贵的训练，更糟糕的是，它们对不断演进的代码库很脆弱，每次提交都可能使适配器失效并需要重新训练。最近关于超网络生成的LoRA适配器（Ha et al., 2017; Charakorn et al., 2025, 2026）的工作很有前景：对条件输入进行一次前向传播即可为冻结的LLM生成任务或文档特定的权重。然而，这些方法是为简短的自然语言任务描述或单个文档构建的，而不是仓库通常携带的长上下文，并且它们假设一个静态的条件输入，没有跟踪代码库演进的机制。我们提出了Code2LoRA，一个超网络框架，它生成仓库特定的LoRA适配器，有效地注入仓库知识，且推理时令牌开销为零。我们围绕两个正交轴——知识如何进入参数以及何时更新——进行设计，并将其实例化为两种使用场景：Code2LoRA-Static将单个仓库快照转换为适配器，适用于理解稳定的代码库；Code2LoRA-Evo维护一个由GRU隐藏状态支持的适配器，该状态根据代码差异进行更新，因此递归增强（而非替换）了快照先验，适用于活跃开发中的演进代码库。我们在RepoPeftBench上评估了Code2LoRA，这是一个包含604个Python仓库的基准（512个在分布内，以及在抓取截止后创建的92个仓库的时间性保留集）。代码语言模型需要仓库级别的上下文来解析导入、API和项目约定。现有方法通过长输入（通过RAG或依赖分析检索）或通过每个仓库的微调和LoRA注入这些知识——这在仓库规模上成本高昂，并且对不断演进的代码库来说很脆弱。我们引入了Code2LoRA，一个超网络框架，它生成仓库特定的LoRA适配器，有效地注入仓库知识，且推理时令牌开销为零。Code2LoRA支持两种使用场景：Code2LoRA-Static将单个仓库快照转换为适配器，适用于理解稳定的代码库；而Code2LoRA-Evo维护一个由GRU隐藏状态支持的适配器，该状态根据代码差异进行更新，适用于活跃开发中的演进代码库。为了评估Code2LoRA与参数高效微调基线的表现，我们构建了RepoPeftBench，这是一个包含604个Python仓库的基准，具有两个赛道：一个静态赛道，包含4万个训练任务和1.2万个测试断言完成任务；以及一个演进赛道，包含21.5万个提交派生训练任务和8.7万个提交派生测试任务。在静态赛道上，Code2LoRA-Static实现了63.8%的跨仓库和66.2%的仓库内精确匹配，与每个仓库的LoRA上限相匹配；在演进赛道上，Code2LoRA-Evo实现了60.3%的跨仓库精确匹配（比单个共享LoRA高出5.2个百分点）。1
原始摘要
edge as long inputs, in the form of retrieved relevant files through RAG (retrieval-augmented generation) or dependency analysis, and pay for the retrieved context at every query. This is costly because repository-level context can be massive, stressing the LLM’s context window and RAG’s retrieval capability. Another approach is to fine-tune the model or LoRA adapters (Hu et al., 2022) for one repository or a group of related repositories, pushing knowledge into parameters. These methods also require costly training, and even worse, are brittle to evolving codebases, where every commit can invalidate the adapter and require retraining. Recent work on hypernetwork-generated LoRA adapters (Ha et al., 2017; Charakorn et al., 2025, 2026) is promising: a single forward pass over a conditioning input produces task- or documentspecific weights for a frozen LLM. These methods, however, are built for short natural-language task descriptions or single documents, not the long context a repository typically carries, and they assume a static conditioning input with no mechanism for tracking a codebase as it evolves. We propose Code2LoRA, a hypernetwork framework that generates repository-specific LoRA adapters, effectively injecting repository knowledge with zero inference-time token overhead. We design around two orthogonal axes—how knowledge enters the parameters and when it is updated—and instantiate them as two usage scenarios: Code2LoRA-Static converts a single repository snapshot into an adapter, suitable for comprehension of stable codebases; Code2LoRA-Evo maintains an adapter backed by a GRU hidden state updated per code diff, so the recurrence augments (rather than replaces) the snapshot prior, suitable for active development of evolving codebases. We evaluate Code2LoRA on RepoPeftBench, a benchmark of 604 Python repositories (512 indistribution and a 92-repository temporal holdout created after the scrape cutoff). RepoPeftBench di- Code language models need repository-level context to resolve imports, APIs, and project conventions. Existing methods inject this knowledge as long inputs (retrieved through RAG or dependency analysis) or through perrepository fine-tuning and LoRA—costly at repository scale and brittle to evolving codebases. We introduce Code2LoRA, a hypernetwork framework that generates repositoryspecific LoRA adapters, effectively injecting repository knowledge with zero inference-time token overhead. Code2LoRA supports two usage scenarios: Code2LoRA-Static converts a single repository snapshot into an adapter, suitable for comprehension of stable codebases; while Code2LoRA-Evo maintains an adapter backed by a GRU hidden state updated per code diff, suitable for active development of evolving codebases. To evaluate Code2LoRA against parameter-efficient finetuning baselines, we build RepoPeftBench, a benchmark of 604 Python repositories with two tracks: a static track with 40K training and 12K test assertion-completion tasks, and an evolution track with 215K commit-derived training and 87K commit-derived test tasks. On the static track, Code2LoRA-Static achieves 63.8% cross-repo and 66.2% in-repo exact match, matching the per-repository LoRA upper bound; on the evolution track, Code2LoRAEvo achieves 60.3% cross-repo exact match (+5.2 pp over a single shared LoRA).1