💻 computer science

ProjAgent: Procedural Similarity Retrieval for Repository-Level Code Generation

ProjAgent 是一个仓库级代码生成系统，它通过基于过程相似性的函数检索进行智能体工作流，并利用静态分析反馈来优化输出，从而在 REPOCOD 基准测试中实现了 41.14% 的 Pass@1。

原作者： QiHong Chen, Aaron Imani, Iftekhar Ahmed

发布于 2026-07-10

📖 1 分钟阅读☕ 轻松阅读

原作者： QiHong Chen, Aaron Imani, Iftekhar Ahmed

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正在尝试为一部长达 10,000 页的巨型推理小说编写一个新章节。你知道需要达到的情节要点，但你不知道角色的名字、小镇的具体规则，也不知道侦探通常如何破案。如果你只是凭直觉猜测，你可能会创造出一个并不存在的角色，或者违反了小镇的法律，从而毁掉整个故事。这正是人工智能在尝试为大型软件项目编写代码时所面临的情况。

长期以来，AI 助手一直试图通过寻找“相似物”来寻求帮助。如果你要求编写一个计算温度的函数，AI 会搜索其他使用了“temperature”（温度）这个词或在表面上看起来相似的代码。论文指出，这就像仅仅因为另一份食谱提到了“糖”，就去寻找制作蛋糕的食谱一样。它忽略了真正的魔力：如何进行烹饪。

作者 Qihong Chen、Aaron Imani 和 Iftekhar Ahmed 开发了一个名为 ProjAgent 的新系统。他们发现，最有帮助的代码并不总是那些看起来相同的代码；而是那些思考方式相同的代码。

“思考” vs. “表达”

论文指出，代码有两个层面：它使用的词汇（如变量名和注释）以及它解决问题的实际步骤（逻辑）。

想象两位厨师。厨师 A 正在做披萨，而厨师 B 正在做沙拉。

旧方法（词法/语义搜索）： 如果你请求制作披萨的帮助，旧的 AI 会忽略厨师 B，因为他在做沙拉。它只会寻找其他披萨厨师。
新方法（ProjAgent）： ProjAgent 意识到这两位厨师都必须做同样的事情：切配料、检查是否新鲜、并将它们放入碗中。尽管一位在做沙拉，另一位在做披萨，但他们的程序化步骤是完全一致的。ProjAgent 找到了厨师 B 并说：“嘿，看看厨师 B 是如何检查生菜是否新鲜的！你可以使用同样的逻辑来检查你的番茄是否新鲜！”

论文明确排除了“表面相似性（观察单词）足以解决问题”的观点。他们认为，仅仅依赖单词或简单的含义往往会错过关键的“如何做”步骤，因为不同的项目会对相同的动作使用不同的名称。

ProjAgent 如何运作：侦探智能体

ProjAgent 扮演着一个拥有特殊工具的超级聪明侦探的角色。它是如何破解谜题的：

拆解： 它将你要编写的新代码拆解成微小的逻辑步骤，例如“检查数字是否为负数”或“转换单位”。
“思考”搜索： ProjAgent 不仅仅阅读单词，它使用一种特殊的技巧来观察 AI 模型的“隐藏思想”。它剥离掉华丽的词汇，只观察纯粹的逻辑。它寻找在项目中执行相同“思维舞蹈”的其他代码，即使这些代码位于完全不同的部分。
智能体的搜寻： 如果第一次搜索没有找到足够的资料，一个数字“智能体”（一个小型的 AI 机器人）就会在项目文件中进行一场搜寻游戏。它阅读文件、搜索函数，并询问：“这里是否有任何东西的思考方式与此一致？”
双重检查： 为了确保没有被误导，该系统使用了一个“静态分析”工具。你可以把它理解为逻辑层面的“拼写检查器”。它检查代码是否能实际运行而不崩溃。如果 AI 犯了错误，系统会说：“哎呀，那行不通，”并要求 AI 重试。这个循环最多会进行 10 次，直到代码变得稳健为止。

结果：它奏效了吗？

作者在名为 REPOCOD 的基准测试上对 ProjAgent 进行了测试，该测试包含来自 11 个不同软件项目的 980 个真实世界编程问题。

得分： ProjAgent 获得了 41.14% 的 Pass@1 分数。这意味着在第一次尝试时，它大约每 100 个问题中就能写出约 41 个可运行的代码。
对比： 这击败了之前的最佳方法。旧的“密集搜索”方法仅获得 28.83%，而“稀疏搜索”（寻找关键词）仅获得 26.58%。即使是顶尖系统 SpecAgent 也仅达到了 34.52%。
证明： 论文表明，最大的提升来自于寻找那些“程序化相似”的步骤。当他们移除程序化搜索时，分数降至 25.76%。当他们移除语义搜索（单词匹配部分）时，分数降至 32.29%。这证明了你需要“如何做”和“做什么”两者兼备才能成功。

本论文并未声称的事项

了解这篇论文没有说什么是很重要的。

它并没有声称已经解决了所有的编程问题。41.14% 的得分意味着它仍然有一半以上的时间会失败。
它并没有说这适用于每种编程语言。测试仅针对 Python 项目进行。
它并没有声称“智能体”是完美的。作者承认，有时智能体会耗尽时间或内存，从而无法找到最佳代码，这表明仍需要更好的探索工具。

核心结论

论文表明，要为大型项目编写优秀的代码，AI 需要停止仅仅寻找匹配的单词，转而开始寻找思维模式。通过寻找以相同方式解决问题的代码（即使单词完全不同），ProjAgent 帮助 AI 编写出更好、更可靠的软件。这是一个进步，但通往完美代码生成的旅程仍在继续。

技术摘要：ProjAgent：面向仓库级代码生成的程序化相似性检索

问题陈述

仓库级代码生成要求大语言模型（LLM）在处理复杂的跨文件依赖、项目特定规范以及分布式工具时，实现目标函数。现有的检索增强生成（RAG）方法主要依赖于词法（如 BM25）或语义（如稠密嵌入）相似性。

作者指出这些方法的一个关键局限性：它们往往无法检索到实现了相似程序逻辑但命名、数据类型或应用领域显著不同的仓库函数。例如，一个在宇宙学模块中验证输入形状的函数，可能在程序逻辑上与物理模块中验证温度输入的函数完全相同，但表层相似性度量（词法或语义）却无法将两者联系起来。这种“程序化差距”会导致 LLM 幻觉出 API 或生成的代码违反项目规范，因为必要的逻辑模式在检索到的上下文中缺失。

方法论：ProjAgent

论文提出了 ProjAgent，这是一个仓库级代码生成系统，它引入了程序化相似性作为显式的检索信号，并将其集成在智能体工作流和静态分析反馈循环中。

1. 表示程序化相似性

为了捕捉超越表面文本的实现行为，ProjAgent 利用从 LLM 隐藏状态中导出的推理子空间投影。

子空间分解： 基于 Hu 等人 [14] 的研究，系统将 LLM 的隐藏状态空间分解为语义子空间（语言表达）和推理子空间（内部逻辑）。这是通过对解嵌入层（unembedding layer）进行奇异值分解（SVD）实现的。
投影： 代码步骤的隐藏状态被投影到推理子空间，以隔离程序化逻辑。
去偏置： 为了解决各向异性现象（即向量无论内容如何都聚集在共同方向），作者引入了基于主成分分析（PCA）的去偏置步骤。这消除了占主导地位的共享方向并进行了中心化处理，显著提高了余弦相似度在程序化匹配中的判别能力。

2. 智能体检索工作流

ProjAgent 采用多阶段检索过程来为目标函数构建丰富的上下文：

离线预处理： 对仓库进行预处理，将上下文函数分解为逻辑步骤（例如，输入验证、状态转换）。每个步骤都经过原始代码验证，并投影到推理子空间中。
程序化检索（智能体化）：
- 种子寻找： 将目标函数分解为若干步骤。通过投影相似性识别出一组初始的程序化相似上下文步骤。
- 智能体探索： LLM 智能体利用工具（如 read_func、search_func）在仓库中导航，以发现可能包含程序化相似步骤的新函数，从而迭代地扩展种子集。
- 种子扩展与验证： 系统通过投影相似性阈值将搜索扩展到未处理的函数。验证步骤（基于 LLM）会过滤掉假阳性，特别是针对通用操作，以确保高质量的程序化匹配。
语义检索： 为了补充程序化逻辑，系统使用词法（BM25）和语义（稠密嵌入）得分的混合方式检索语义相关的符号（API、类、常量）。这确保了 LLM 能够获取实现检索逻辑所需的特定仓库实体。
代码生成与反馈： LLM 使用结合了程序化和语义的上下文生成代码。随后，一个保守的静态分析反馈循环会对代码进行迭代优化。它执行基于 AST 的语法检查和语义一致性检查（方法调用、字段访问、变量解析），并将错误反馈给 LLM 进行修复。

核心贡献

将程序化相似性作为检索维度： 论文引入了程序化相似性作为一个独特且有效的检索信号，解决了函数共享逻辑模式但缺乏词法或语义重叠的问题。
推理子空间投影： 作者利用 LLM 隐藏状态投影来表示程序化逻辑，从而实现跨不同命名规范和领域的相关函数检索。
ProjAgent 系统： 一个完整的系统，集成了用于程序化上下文发现的智能体工作流、混合检索（程序化 + 语义）以及用于迭代代码修复的静态分析反馈循环。
全面评估： 在 REPOCOD 基准测试上进行了严格评估，包括消融实验和检索组件贡献的分析。

结果

在 REPOCOD 基准测试（涵盖 11 个仓库的 980 个问题）上使用 Qwen2.5-Coder-14B-Instruct 模型进行评估：

性能： ProjAgent 达到了 41.14% 的 Pass@1，优于现有基准模型：
- SpecAgent (SOTA): 34.52%
- 稠密检索 (Dense Retrieval): 28.83%
- 稀疏检索 (Sparse Retrieval): 26.58%
- 同文件检索 (Same-File Retrieval): 14.98%
消融实验：
- 移除程序化检索导致性能大幅下降（41.14% $\to$ 25.76%），凸显了其在提供实现指导方面的关键作用。
- 移除语义检索也显著降低了性能（41.14% $\to$ 32.29%），证实了对仓库特定符号的需求。
- 移除反馈循环导致性能轻微下降（41.14% $\to$ 40.29%），这归因于静态分析的保守性质。
检索有效性： 投影相似性方法被发现能非常有效地过滤掉不相似的上下文（在“剩余”组中具有高精确度），但需要两阶段设计（投影 + 验证）来处理“提升”组中的假阳性。

重要性与主张

论文声称，程序化相似性是一个有效且此前尚未被探索的检索维度，适用于仓库级代码生成。作者认为，成功的代码生成不仅取决于检索语义相关的代码，还取决于检索具有相同底层计算过程的上下文。

通过将程序化相似性与传统的词法和语义信号相结合，ProjAgent 证明了即使在领域或词汇显著不同的情况下，也能引导 LLM 实现复杂的逻辑。这项工作表明，软件工程正朝着行为感知检索方法的方向转变，超越了表层的文本匹配，转而捕捉代码的功能意图。作者对外部有效性保持谨慎，指出结果针对 Python 仓库及特定的骨干模型，且搜索覆盖范围仍是进一步改进的瓶颈。