论文信息

题目：SYNFIX: Dependency-Aware Program Repair via RelationGraph Analysis
链接：ACL 25’

主要问题

储存库级别的代码问题分析任务面临一个主要问题：跨组件（文件、类和方法）要求需要对代码库由全面了解。传统方法难以应对该问题，因此本文的主要问题聚焦于有效建模处理大规模代码库之间连系本质的解决方案。
一些基于独立智能体的框架化设计可以使得LLM自主决策，并根据智能体彼此的反馈迭代更新信息。但是限制在于，工具调用的复杂性会引入易出错的抽象层，尤其是将操作映射于API时。缺乏稳健的规划机制意味着智能体经常做出次优决策，另外它们自我反思和过滤不相关或不正确反馈的有限能力也会增大限制。
主要工作在于：

关系图驱动的框架：对存储库中的依赖关系进行建模；
定位方法和同步过程：分层的定位方法，引入同步机制在链接组件间传播修复信息；
验证机制：补丁验证，确保修复正确性

SynFix

上图为总览，包含以下过程：关系图（①）、定位（②）、同步（③）和验证（④-⑧）。首先构造一个代码库的关系图，捕获其层次结构、变量、类和方法的调用关系，然后通过一个低成本LLM（比如免费使用的GPT3.5）识别排名前N个问题节点及上下文，然后识别问题节点的单跳邻居，提取相应内容，旨在作为LLM的额外输入，并评估是否要对单跳邻居进行更新。模型会动态静态地缩小编辑单位，修复阶段中，SynFix将问题语句和编辑位置呈给LLM，根据提示词生成补丁，然后应用于原始代码库，迭代这个过程，直到补丁应用成功。

关系节点图构建

有向图，节点为代码实体（例如文件夹名、文件名、变量名、类名、函数名），边表示他们的层次或依赖关系（文件夹和子文件夹、文件夹中文件）。如下图实例，该关系图可以视作多个子图按照边关系合并后的结果。

定位

定位过程被拆解为多个步骤：

第一步：可疑节点定位

利用混合检索机制求出前N个可疑节点。

基于嵌入的检索：将每个节点转为包含代码片段、注释和相关文件的文本表示，使用OpenAI的textembedding-3-small计算节点嵌入，利用余弦相似度与问题描述比较，以此确定高相似的前N个节点。
基于LLM的重排序：将包含问题描述和提取节点上下文结构化提示交给GPT3.5,重新排序。从此获取可以代码行。