当前位置：首页 > news >正文

SWE-QA：语言模型能否回答仓库级代码问题？

news 2025/10/18 13:26:03

彭伟涵，上海交通大学，中国；史玉玲，上海交通大学，中国；王宇杭，上海交通大学，中国；张欣韵，上海交通大学，中国；沈备军，上海交通大学，中国；顾晓东*，上海交通大学，中国

理解和推理整个软件仓库是智能软件工程工具的核心能力。现有基准（如CoSQA和CodeQA）虽推动了该领域发展，但主要聚焦于小型、独立的代码片段。这类设置无法体现真实世界软件仓库的复杂性——在真实场景中，有效的理解与推理往往需要跨多个文件检索、掌握软件架构，并基于长程代码依赖生成答案。本文提出仓库级代码问答（QA）基准SWE-QA，旨在为真实代码环境下的自动问答系统研究提供支持。SWE-QA包含576个高质量问答对，覆盖意图理解、跨文件推理、多跳依赖分析等多个类别。为构建SWE-QA，研究团队首先从11个热门仓库中爬取77100条GitHub议题，通过分析议题中开发者的自然提问，建立仓库级问题的两级分类体系，并为每个类别设计种子问题。随后，针对每个类别手动筛选、验证问题并收集对应答案。作为原型应用，研究进一步开发SWE-QA-Agent——一个基于智能体框架的系统，可让大语言模型（LLM）智能体通过推理与行动自动生成答案。研究在SWE-QA上评估了6个先进LLM在不同上下文增强策略下的表现，结果表明LLM（尤其是SWE-QA-Agent框架）在仓库级问答任务中具有潜力，同时也揭示了当前存在的挑战，并指出未来研究方向。

ACM参考文献格式

彭伟涵、史玉玲、王宇杭、张欣韵、沈备军、顾晓东，2025，《SWE-QA：语言模型能否回答仓库级代码问题？》，1（1）（2025年9月），21页。https://doi.org/XXXXXXX.XXXXXXX

1 引言

理解和推理整个软件仓库是智能软件工程工具的核心能力。实际开发中，开发者很少仅对孤立函数或小型代码片段进行推理，而是需要面对庞大、互联的代码库，跨多个文件追踪依赖关系，并整合架构知识以解决复杂问题。

尽管大语言模型（LLM）在代码理解领域取得进展[6,11,34,43]，但现有评估[10,13,16,17,25]多针对孤立代码片段、函数或API。这些基准无法体现真实仓库的复杂性，如架构设计、跨文件依赖、生命周期流程和设计原理等——而理解这些内容需要对代码结构、语义和意图进行深度多跳推理[23,41]。近期仓库级研究（如CoReQA[3]）虽开始关注仓库级理解，但聚焦于议题解决而非代码模块理解，未能全面覆盖真实开发场景中必需的多种推理模式和多跳依赖关系。

为解决这一局限，本文提出仓库级代码问答基准，用于评估LLM回答真实仓库问题的能力。SWE-QA包含576个高质量问答对，覆盖意图理解、跨文件推理、多跳依赖分析等类别。为捕捉实际开发中的各类推理需求，研究从SWE-bench[12]使用的11个热门仓库中爬取77100条GitHub议题，通过分析议题中的自然提问，建立仓库级问题的两级分类体系，并为每个类别设计种子问题。基于分类体系和种子模板，研究利用LLM从12个仓库中生成候选问题，经手动筛选和优化后，每个仓库得到48个高质量问答对。随后，基于检索到的上下文，使用性能强大的LLM生成初始答案，再经人工审核与优化，确保答案的正确性、完整性和清晰度。最终形成基于代码上下文的高质量参考答案，构建出兼具可靠性与扩展性、涵盖多种推理需求的基准。作为原型应用，研究还开发SWE-QA-Agent——一个基于智能体框架的系统，可让LLM智能体通过推理与行动自动生成答案。该智能体借助多种工具辅助推理与信息检索，尤其适用于跨文件和多跳问题。

研究使用多种上下文增强方法，在SWE-QA上评估了6个先进LLM，包括Devstral-Small-1.1[20]、Qwen2.5-Coder-32B-Instruct[24]、Qwen2.5-72B-Instruct[30]、DeepSeek-V3[5]、GPT-4o[21]和Claude 3.7 Sonnet[2]。研究设计基于评分标准的评估系统[18,33]，由性能强大的LLM（如GPT-5[22]）从正确性、完整性、相关性、清晰度和推理质量五个维度对模型输出评分。为减少评估偏差，研究对候选答案匿名处理、随机排序，并结合人工抽查与校准提示。

结果表明LLM在仓库级代码问答中具有潜力：无上下文直接提示的性能较差，而标准检索增强生成（RAG）方法可显著提升效果。其中，基于Claude 3.7 Sonnet的SWE-QA-Agent框架表现最佳，综合得分达47.82。人工评估也证实这一结果，SWE-QA-Agent在所有维度均获最高分。通过分析不同问题类别和仓库的表现发现：模型在概念类“What”和“Why”问题上表现优异，但在需要多跳推理的流程类“How”和位置类“Where”问题上存在困难；不同仓库的性能差异明显，如“pytest”仓库的问题难度较高。

总体而言，实验结果既表明LLM（尤其是SWE-QA-Agent框架）在仓库级问答任务中的潜力，也揭示了当前存在的挑战，并指出未来研究方向。

综上，本文的贡献如下：

构建仓库级代码问答基准SWE-QA，包含来自12个不同开源Python仓库的576个高质量问答对，用于评估对仓库的综合理解能力；
提出SWE-QA-Agent——一种基于ReAct风格的智能体，专为回答仓库级问题设计。该智能体借助多种工具辅助推理与信息检索，尤其适用于跨文件和多跳问题；
不仅构建基准，还提供灵活的流程，用户可利用种子问题为任意新仓库高效生成问答数据集；
基准、代码和实验结果已公开，可用于复现研究，网址为https://github.com/peng-weihan/SWE-QA-Bench。

2 SWE-QA：仓库代码问答新基准

本节介绍仓库级代码问答新基准SWE-QA。如图1所示，基准构建流程包含四个主要阶段：种子问题收集、问题实例化、答案收集和数据验证。各阶段细节如下。

2.1 种子收集与分类体系构建

为确保SWE-QA反映实际软件工程的复杂性，研究首先通过实证研究，分析开发者在处理大型代码库时提出的问题类型，从GitHub议题中系统收集并分析大量问题，建立仓库级问题的综合分类体系，作为基准构建的基础。

数据收集流程始于从SWE-bench[12]使用的11个热门仓库（排除禁用议题功能的Django）中爬取77100条GitHub议题。为聚焦有实质内容的讨论，研究筛选出内容长度至少1000字符的议题，得到41955条有效数据。由于议题通常包含大量描述文本，研究利用LLM解析每条议题，提取与代码理解相关的明确问题，最终得到127415个不同问题，平均每条议题含3.04个问题。提示词细节可参考补充材料[1]。各仓库的议题分布如图2所示。

研究通过迭代开放式编码，手动分析1000个随机抽取的问题，识别重复出现的模式和开发者意图，最终建立仓库级问答的两级分类体系，如表1所示。第一级根据核心疑问词分类：What（事实查询）、Why（因果解释）、Where（位置确认）和How（流程解释）；第二级进一步将问题细分为12个具体意图类别，如依赖追踪、设计原理说明、算法分析等，涵盖常见软件工程场景。

分类体系确定后，研究使用性能强大的LLM（GPT-5），通过简洁的标注提示和一致性检查，将剩余126415个问题归入一级/二级类别。结果分布如图3所示：“How”类问题占比最高（35.2%），主要关注系统设计、算法等实现细节；“Where”类问题次之（28.4%），表明开发者常需定位功能、数据流或特定标识符；“Why”类问题（探究设计原理和目的）占23.1%；“What”类问题（查询定义或架构概述）占13.3%。这一分布表明，开发者的大量查询集中于流程和位置相关知识，凸显了问答系统深入理解代码结构与实现的重要性。

2.2 问题实例化与扩展

基于上述分类体系，研究为每个意图类别设计抽象种子模板。例如“What are the subclasses that inherit from the class?”（类的子类有哪些？）和“How does implement in case of ?”（在情况下，如何实现？）。这些模板捕捉了重复出现的问题核心，如表1所示，可作为生成特定仓库上下文相关问题实例的蓝图，确保基准涵盖各类推理挑战。

本阶段目标是为目标仓库生成上下文相关的问题实例。研究使用语言无关的解析工具tree-sitter[31]解析每个仓库的结构，生成核心元素及其关系的类型化图（图4）。图中节点包括仓库（Repository）、文件（File）、代码片段（Code Snippet）、类（Class）、方法（Method）、属性（Attribute）、函数（Function）、参数（Parameter）和变量（Variable）；边表示包含关系（如类包含方法/属性、文件包含代码片段）。此外，每个函数会记录其调用的函数和调用它的函数，每个文件会记录其导入的内容，从而呈现跨文件依赖关系。该结构同时捕捉类型级和调用级依赖，为多跳推理奠定基础。

问题实例化过程如下：围绕核心元素（如类或方法）选择紧凑子图，结合第一阶段的种子模板生成问题。子图提供签名、定义、类归属、文件路径、导入信息及调用关系，确保上下文充分且不冗余。图5展示具体实例：左栏概述核心函数及其关联信息；右上栏列出所选分类类别的5个种子问题；LLM根据提示为指定函数合成最合适的非复合问题（右中栏）。参考答案（右下栏）则列举基于仓库的约束条件（如版本限制、后端差异），将在后续答案收集阶段生成。实际操作中，研究将图4中的结构元素和完整种子集输入LLM生成候选问题，提示词细节可参考补充材料[1]。

2.3 答案收集

问题实例化完成后，研究为每个问题生成初始参考答案。如图1第三阶段所示，该过程采用检索增强生成（RAG）流程，确保答案紧密基于仓库上下文，具体包含两个关键步骤：

步骤1：上下文检索。针对每个问题，首先构建目标仓库代码元素（包括函数、类及其相互依赖）的综合索引，结合语义相似性匹配和结构依赖分析，检索相关代码片段、文档和架构元数据，为答案生成提供丰富且相关的上下文。

步骤2：初始答案生成。基于检索到的上下文，研究结合人类专家（使用Cursor等工具）和性能强大的LLM生成初步答案。生成过程遵循提示词要求，强调事实准确性、完整性，并严格依据提供的上下文。提示词明确要求模型引用代码位置，避免引入检索材料之外的信息，减少幻觉现象。生成的问答对将作为后续数据验证阶段的输入。

2.4 数据验证

为确保基准的高质量和可靠性，所有初步问答对需经过严格的数据验证流程，如图1第四阶段所示。该多阶段流程由熟悉目标仓库的资深开发者执行，包括答案修订和质量筛选：

步骤1：专家答案修订。专业团队手动审核每个生成的答案，借助Cursor等基于LLM的工具，细致验证每个表述的事实准确性，评估解释的完整性，并优化语言以提升清晰度和精准度。这种“人类参与”的方式能够修正自动化系统可能遗漏的细微错误，确保答案既正确又易于理解。

步骤2：质量筛选。修订后的问答对需经过最终筛选，不符合质量标准的将被剔除。筛选标准包括（但不限于）：问题模糊或表述不当、修订后答案仍存在事实错误或不完整、答案无法充分依据仓库代码和文档支撑。此外，研究确保每个仓库的一级类别（What、Why、Where、How）问题数量均衡，最终每个仓库保留48个问答对。严格的筛选流程确保最终SWE-QA基准仅包含清晰、正确且有价值的问答对。

2.5 SWE-QA统计信息

表2全面展示SWE-QA的统计数据。该基准包含从12个不同热门Python仓库中精心筛选的576个问题，仓库选择基于SWE-bench[12]基准，确保其相关性和复杂性。这些仓库共包含11335个文件、19544个类、128835个函数，代码行数超300万行，为代码理解模型提供了具有挑战性的真实场景。为确保问题类型分布均衡，研究选择数量相等的What、Why、Where和How类问题，每个仓库贡献48个样本。

表3对比SWE-QA与现有代码问答基准，结果显示片段级与仓库级基准存在本质差异。CoSQA[10]、CodeQA[17]、CS1QA[13]等传统基准仅关注孤立代码片段或教学场景，无法满足真实仓库级代码模块理解需求；即使支持多跳推理的CodeQueries[25]，也仅局限于孤立Python函数，不涉及跨文件依赖。ProCQA[16]、InfiBench[15]等近期大规模基准虽从Stack Overflow收集数据，但聚焦通用编程任务，未针对仓库结构设计。

CoReQA[3]虽属于仓库级基准，从GitHub议题和评论中收集数据，但聚焦于议题解决而非代码模块理解。关键在于，现有基准均未要求模型将代码模块视为仓库内相互关联的架构组件进行理解。SWE-QA则填补这一空白，专门针对真实代码模块理解设计，要求模型掌握模块间的交互与依赖关系、模块在代码库中的架构作用，以及模块间的语义约定。SWE-QA的真实构建场景使其具备以下独特特征：

仓库级粒度：与以往针对孤立代码元素（如函数、类）的基准不同，SWE-QA以仓库为单位，贴合实际软件理解任务——在此场景下，有效的推理需结合跨文件上下文、架构理解和依赖追踪。该基准要求模型处理、解读并回答基于复杂互联代码库的问题。
流程级扩展性：SWE-QA不仅是一个基准，还是生成新仓库级问答实例的模块化流程。通过结合静态代码分析、LLM提示和人工筛选，可半自动持续生成新基准，确保其长期扩展性和对新兴代码库的适应性。

3 SWE-QA-Agent

为验证所提基准的有效性，研究提出仓库级问答方法SWE-QA-Agent。该方法基于智能体框架[39]，设计为专门用于仓库级代码问答的自主智能体。智能体的设计直接源于分类体系分析中发现的挑战：它配备语义搜索、结构导航和直接文件检查工具，能够有效回答各类问题，尤其在具有挑战性的“Where”和“How”类别上表现突出。具体而言，SWE-QA-Agent通过“推理-执行”循环工作：智能体迭代分析问题、从目标仓库检索相关代码或文档、生成答案，同时保留中间推理步骤以提升准确性和完整性。这种设计使SWE-QA-Agent能够处理复杂的多文件仓库，并生成精准、贴合上下文的答案。

如图6所示，SWE-QA-Agent采用基于ReAct的迭代工作流程：首先通过语义内容搜索检索初始相关代码片段，随后循环进行仓库结构分析、带模式匹配的目标文件读取和上下文逐步优化，直至收集到足够信息以生成全面、有依据的答案，流程终止。

3.1 行动空间

SWE-QA-Agent的认知过程由离散行动空间驱动，包含四个基本且全面的核心功能。这些行动为智能体提供仓库分析和答案生成所需的工具，具体如下：

ReadFile（读取文件）：允许智能体查看仓库中特定文件的内容，是实现底层代码理解的主要方式。智能体可通过该功能检查源代码、配置文件、文档等文本资源，并能执行cat、grep等标准命令行工具，实现精准的内容检索和模式匹配。
GetRepoStructure（获取仓库结构）：通过获取仓库文件和目录结构的层级表示，帮助智能体建立高层结构认知。尽管单文件分析至关重要，但全面掌握仓库整体结构对于理解模块依赖、定位相关入口点，以及基于常规项目布局（如src、docs、tests目录）形成假设不可或缺。该功能通过执行tree命令实现，为智能体提供可在整个推理过程中参考的全局上下文地图。
SearchContent（内容搜索）：解决智能体在处理大型代码库时面临的上下文窗口有限问题。该功能采用检索增强生成（RAG）流程，使用商用级代码嵌入模型（voyage-code-3），使智能体的搜索能力超越简单关键词匹配，达到抽象概念层面。
Finish（完成）：标记问答任务结束，表明智能体已从收集的信息中合成确定答案，或已达到预设的最大迭代次数。

3.2 迭代推理与检索流程

智能体的工作流程基于ReAct框架，将推理、行动和观察整合为迭代循环。该流程的形式化描述如算法1所示，以用户查询和仓库上下文为输入，使智能体能够动态积累知识并逐步收敛至解决方案。

流程始于通过广泛的SearchContent行动检索最相关的代码片段，建立初始上下文。随后，智能体进入探索与优化循环：在每一步，智能体分析当前上下文形成思路，然后策略性地选择行动——要么获取高层结构概览（GetRepoStructure），要么检查具体实现细节（ReadFile）。每个行动的输出作为观察结果，不断丰富智能体的理解。迭代循环持续进行，直至智能体判定已收集足够证据生成全面答案，此时调用Finish行动合成并返回最终结果。该流程的核心原则是“目标导向”，可减少上下文过载，避免无目的探索，确保效率。

4 实验设置

为展示SWE-QA的实用性，研究基于该基准评估语言模型在仓库级代码问答任务中的表现，旨在通过对现有语言模型的全面深入比较，发现新见解。具体而言，研究试图回答以下研究问题：

RQ1（语言模型性能）：语言模型在仓库级代码问答任务中的表现如何？
RQ2（人工评估）：各评估方法在人工评估中的表现如何？
RQ3（分类体系分析）：分类体系中不同问题类型的难度和知识需求有何差异？
RQ4（跨仓库泛化）：代码问答性能在不同仓库间的泛化能力如何？

4.1 模型选择

研究评估了6个广泛认可的LLM，包括Devstral-Small-1.1[20]、Qwen2.5-Coder-32B-Instruct[24]、Qwen2.5-72B-Instruct[30]、DeepSeek-V3[5]、GPT-4o[21]和Claude 3.7 Sonnet[2]。这些模型涵盖专有模型（GPT-4o、Claude 3.7 Sonnet）和开源模型（DeepSeek-V3、Qwen系列、Devstral），包括通用模型（GPT-4o、DeepSeek V3）和代码专用模型（Qwen2.5-Coder、Devstral）。此外，研究还将两个商用编程工具（通义灵码[1]和Cursor[2]）作为系统级基线纳入评估：通义灵码使用专有模型；Cursor默认采用“自动”模式，可根据用户查询自动选择最佳模型，并内置检索和协调功能。评估这些商用工具旨在反映当前最先进闭源解决方案的性能。每个模型在以下四种设置下进行评估：

Direct（直接提示）：模型仅接收任务指令，不获取仓库的详细检索上下文。该基线用于评估模型在预训练阶段可能获取的目标仓库内部知识，是衡量检索增强生成技术带来性能提升的基础基准。
Function Chunking RAG（函数分块检索增强生成）[35]：基于语义边界划分代码，将仓库解析为函数级块，避免函数被拆分，便于对仓库结构进行精准推理。
Sliding Window RAG（滑动窗口检索增强生成）[41]：采用滑动窗口将长文件分割为重叠片段，提取代码片段。该策略能有效捕捉局部和跨文件上下文，在仓库级代码理解任务中表现出较强性能。
SWE-QA-Agent：研究提出的基于ReAct范式的自主智能体框架，通过迭代推理检索相关代码和文档，生成贴合上下文的答案，同时保留中间推理轨迹。

除非另有说明，SWE-QA-Agent的每个问题最大推理-行动迭代次数设为5。所有LLM的解码温度均设为0，以避免随机性影响。所有实验在配备Intel Xeon Gold 6254 CPU和NVIDIA A100-80G GPU的系统上进行。

4.2 评估指标

研究采用基于LLM的评估（LLM-as-Judge）方法评估仓库级代码问答性能。LLM-as-Judge的可靠性已得到广泛验证，不仅在自然语言生成任务[18,28]中表现出色，在软件工程相关任务[8,33]中也展现出强大能力，因此适合作为本研究的稳健评估指标。

针对生成的答案和参考标准答案，研究使用LLM（实验中为GPT-5[22]）从五个维度评估答案质量：

正确性：衡量答案的事实准确性；
完整性：衡量答案对问题的覆盖程度；
相关性：衡量答案与问题的关联度；
清晰度：衡量答案的结构合理性和易懂性；
推理质量：衡量答案推理过程的连贯性。

每个维度采用预定义的5分制评分（1-5分，5分为最高质量）。为提高可靠性，LLM对每个实例的每个维度评估5次，通过多数投票确定各维度的最终得分，再汇总得到实例的综合得分。评估过程中，候选系统需匿名处理，每次评估的答案顺序随机打乱；评估模型固定且与所有候选模型不同，不会评估自身生成的输出。该方法能全面、稳健地评估语义准确性和推理质量。提示词细节可参考补充材料[1]。

然而，仅依赖LLM评估自身输出会存在固有偏差。为缓解这一问题，研究采取以下措施：确保评估模型与候选模型分离（评估模型不参与候选）、对系统匿名处理、随机打乱答案顺序，并通过人工研究（见5.2节）补充自动化评估。

5 评估结果

5.1 RQ1：语言模型性能

表4展示所有模型在SWE-QA所有问答对上的综合评估结果，清晰呈现不同方法和LLM在仓库级问答任务中的表现差异。

不同方法对比

研究首先分析不同上下文增强方法的影响：无仓库上下文的直接查询基线在所有模型中得分最低（如DeepSeek V3得34.38分），凸显了基于上下文的重要性；滑动窗口检索增强生成和函数分块检索增强生成通过提供相关代码片段，显著提升模型性能（如DeepSeek V3分别提升至39.72分和39.90分）；在性能强大的基础模型上，研究提出的智能体方法SWE-QA-Agent结合检索与迭代推理，实现了最大幅度的性能提升（如DeepSeek V3提升至42.70分，较基线高8.32分；Claude 3.7 Sonnet提升9.64分）。对于轻量级模型（如Qwen系列、Devstral），其智能体方法性能与标准检索增强生成基本持平，表明智能体规划和工具使用会带来额外开销，而这种开销仅在基础模型能可靠执行规划时才能产生回报。在子指标方面，SWE-QA-Agent在有效时能显著提升“完整性”和“推理质量”（如GPT-4o的“推理质量”指标，智能体方法较检索增强生成高1.78分，而检索增强生成仅高1.1分），体现了“规划-行动-观察”循环在处理复杂查询中的价值。

结论1：仓库上下文对仓库级问答至关重要。标准检索增强生成方法能显著提升性能，而基于智能体的方法（SWE-QA-Agent）在性能强大的基础模型上表现最佳，尤其在“完整性”和“推理质量”等指标上优势明显，证明其处理复杂查询的卓越能力。

不同语言模型对比

基础LLM的选择也起着关键作用：在所有模型中，Claude 3.7 Sonnet表现最佳，结合SWE-QA-Agent框架后综合得分达47.82；商用工具Cursor紧随其后，得47.40分。值得注意的是，尽管GPT-4o声誉较高，但结合智能体框架后仅得39.54分，不仅低于Claude，也落后于DeepSeek V3（42.70分）。这表明不同模型在软件工程任务中的天赋存在差异，Claude 3.7 Sonnet等较新模型可能更适合代码相关推理。开源模型虽整体表现不及顶级专有模型，但潜力巨大：DeepSeek V3结合智能体框架后，绝对性能提升幅度排名第二（+8.32），最终得分42.70，具有较强竞争力。这凸显了智能体框架的重要价值——能显著提升基础模型的能力。

结论2：专有模型（尤其是Claude 3.7 Sonnet）目前在仓库级问答任务中领先。但开源模型（如DeepSeek V3）潜力强劲，结合先进的智能体框架后可达到具有竞争力的性能。

与商用编程工具对比

研究最后将所提方法与两个商用闭源编程工具（通义灵码和Cursor）进行对比。如表4所示，这些工具表现出色：Cursor综合得分47.40，在所有评估方法中排名第二，仅略低于基于Claude 3.7 Sonnet的智能体方法（47.82）；通义灵码也取得44.80的高分。这些工具是高度集成的系统，可能采用先进的专有LLM和复杂的上下文检索机制，与研究提出的智能体框架类似。它们的优异表现既提供了有价值的基准，也验证了构建集成化、工具增强型系统解决复杂仓库级问答问题的有效性。

结论3：Cursor等商用编程工具效果显著，性能接近表现最佳的“模型-方法”组合。这凸显了集成化、工具增强型系统在仓库级问答中的价值，为未来研究设立了高标准。

5.2 RQ2：人工评估

尽管LLM-as-Judge方法具有可扩展性，但存在固有偏差。为补充自动化指标并更可靠地评估答案质量，研究开展人工评估：招募3名具有四年以上开发经验的专业软件工程师（非本文作者），从12个仓库的12个分类类别中各随机抽取1个问题，共144个问题作为评估样本（占基准的四分之一）。

对于每个问题，评估者会看到参考标准答案，以及基于Claude 3.7 Sonnet模型的四种方法生成的答案：无上下文基础模型、函数分块检索增强生成、滑动窗口检索增强生成，以及研究提出的SWE-QA-Agent。为确保公平性，答案顺序随机排列，评估者不知道答案对应的生成方法。每位评估者需从正确性、完整性、相关性、清晰度和推理质量五个维度（与自动化评估一致），采用10分制对144个答案评分。该实验设计符合相关研究的公认实践[7,18]。

人工评估结果如表5所示，与LLM-as-Judge的自动化评估结果高度一致：研究提出的SWE-QA-Agent智能体方法显著优于其他所有方法，综合得分45.51，证实人类专家也认为智能体生成的答案质量更优。对比SWE-QA-Agent与基础模型发现，“完整性”（从4.82分提升至8.85分）和“推理质量”（从5.35分提升至8.74分）的提升幅度最大，表明智能体的迭代检索与推理流程在生成全面、逻辑严谨的答案方面效果显著。尽管两种检索增强生成方法均较基线有明显提升，但仍不及智能体方法，凸显了简单检索在处理复杂仓库级问题时的局限性。

结论4：人工评估证实了智能体方法的优越性。专家在所有维度上对SWE-QA-Agent生成的答案评分显著更高，尤其在“完整性”和“推理质量”维度，与LLM-as-Judge自动化评估结果一致。

5.3 RQ3：分类体系分析

为了解模型在不同类型仓库级问题上的表现差异，研究使用表现最佳的SWE-QA-Agent方法，对分类体系中12个问题意图类别的模型得分进行分析，结果如表6所示。

结果显示，模型在高层概念类问题和底层实现类问题上的表现存在明显差异：模型在“Why”类问题上表现最佳（平均43.10分），其中“设计原理”子类得分最高（44.40分）；在“What”类问题的“概念/定义”子类上也表现出色（44.22分）。这表明当所需信息以自然语言形式明确表达（如文档字符串、注释、架构说明）时，模型能高效处理。

模型在需要深入理解流程或位置的问题上表现较差：“Where”类问题（如追踪数据流、定位功能）平均得分最低（37.55分），其中“数据/控制流”子类仅36.88分；要求解释实现过程的“How”类问题（38.15分）也颇具挑战性。这些类别的问题通常需要整合分散在多个文件中的逻辑，以及文档之外的隐含控制路径，对模型的多跳代码追踪和依赖推理能力提出了更高要求。

结论5：模型在不同类型问题上的表现差异显著。在可通过文档回答的高层概念类问题（如“Why”和“What”）上表现优异，但在需要深入代码理解和依赖追踪的底层流程类（How）和位置类（Where）问题上存在困难。

5.4 RQ4：跨仓库泛化

为评估模型的泛化能力，研究使用SWE-QA-Agent方法，分析模型在SWE-QA中12个不同仓库上的表现，结果如表7所示。尽管整体表现较为稳定，但不同仓库的特性对性能有显著影响。

平均而言，大多数仓库的难度相近，得分集中在40分左右，例如“django”（41.90分）、“matplotlib”（41.08分）和“sphinx”（40.68分）。但也存在明显例外：“requests”仓库的问题平均难度最低（43.72分）；而“pytest”（36.76分）和“sqlfluff”（36.72分）的问题难度较高。这种差异与代码库大小、架构复杂度、插件/钩子系统、API接口清晰度，以及增加推理难度的非常规模式等因素相关。

此外，部分模型对仓库特定特性的敏感度更高。例如，“Qwen2.5-Coder-32B”模型在特定仓库上表现出明显的性能波动（“pytest”得12.78分，“sqlfluff”得17.06分），但在其他仓库（如“requests”得41.30分）上表现正常，表明该模型在面对特定代码风格时稳定性不足。相比之下，Claude 3.7 Sonnet等顶级模型在所有仓库上均保持高得分（46.32-49.16分），展现出对不同代码库风格和复杂度的强大适应能力。

结论6：模型在不同仓库间具有一定泛化能力，但性能并非完全一致。“pytest”和“sqlfluff”等仓库的问题难度显著更高；部分模型（尤其是代码专用模型）在特定仓库上表现不稳定，而顶级通用模型则展现出更强的跨仓库稳健性。

5.5 案例研究

为直观展示答案质量差异，研究以sqlfluff仓库中的一个复杂问题为例：“How does SQLFluff implement its plugin system for custom rules?”（SQLFluff如何实现自定义规则的插件系统？）。如图7所示，基线滑动窗口检索增强生成仅检索到关于get_rules()的代码片段，生成的答案较为笼统，未能涵盖核心机制；而SWE-QA-Agent智能体通过检索发现pluggy库的使用及更深层上下文（如PluginSpec和注册流程），使模型能够解释实际架构。

智能体通过基于假设的多步搜索实现这一目标：从get_rules()入手，推断出钩子规范（hookspec）接口，找到包含抽象方法的PluginSpec；随后定位插件管理器初始化和钩子规范注册过程；最后验证第三方规则的分布式入口点发现机制。这些相互印证的片段共同构成了最终答案——涵盖规范/钩子、加载/协调和外部注册，生成简洁、机制层面的解释，具有更高的完整性、精准度和可验证性。

6 有效性威胁

内部有效性

内部有效性的主要威胁是数据污染——语言模型在预训练阶段可能接触过基准数据，导致性能指标虚高，影响评估公平性。为解决这一问题，研究通过对比“无检索直接回答”和“基于检索增强生成”两种方法的性能，进行系统验证。分析发现两种方法存在显著性能差距，检索增强生成方法始终优于直接回答基线，表明数据污染的影响极小（若存在污染，两种方法的性能应相近）。此外，研究承诺通过定期更新新发布仓库的基准数据，维护基准的完整性，确保评估框架的长期有效性。

外部有效性

影响外部有效性的威胁主要包括三方面：

数据泛化性：评估基于12个热门Python仓库的问题，尽管涵盖多种类型和意图，但可能无法完全代表不同领域、不同复杂度的真实用户查询，可能影响研究结果的普适性。为缓解这一威胁，研究精心选择跨领域仓库，并确保问题分类体系覆盖多种查询类型和复杂度。
编程语言范围：基准仅聚焦Python仓库，可能限制结果对其他编程语言的适用性。但研究提出的方法具有语言无关性，不依赖Python特有特性，因此在其他编程语言中具有较强可迁移性，核心检索和推理机制在不同编程范式中应保持有效。
人工评估偏差：尽管由3名资深软件工程师进行人工评估，但评估过程仍可能存在主观偏差。为减少这一威胁，研究提供详细评估指南、分析评估者间一致性，并采用多数投票确定最终评分。

7 相关工作

7.1 代码问答

随着语言模型和预训练技术的发展，代码问答（QA）领域取得显著进展，出现了多种专门处理代码查询的方法。CodeMaster[40]是其中一种重要方法，通过任务自适应预训练自动回答代码问题，利用语法和语义分析将代码注释转换为问答对，有效处理代码相关查询。另一种创新方法是CIQA[13]，这是一种受编码启发的问答模型，通过学习从GitHub等代码仓库中表示和利用外部API，引入“问答文本到代码”算法，提升编程任务性能。此外，相关研究还包括基于检索的方法（如在社区数据集[16]中匹配自然语言查询与代码片段），以及针对特定领域（如建筑规范[37]）的微调Transformer模型。然而，这些方法主要聚焦于片段级理解，无法处理复杂的仓库级推理。与这些针对孤立代码元素的方法不同，本文工作通过引入仓库级上下文感知和多跳推理能力，解决了现有代码问答系统的根本局限，满足真实软件开发场景的需求。

7.2 代码问答基准

已有多个基准用于评估代码问答系统，但均未能实现真实仓库级代码模块理解。多数现有工作的范围更为有限：CodeQueries[25]、CodeQA[17]等片段级基准仅关注孤立代码片段或单个方法；CodeQA特意选择完整Python函数作为答案，以确保功能独立性；CoSQA[10]聚焦函数级代码搜索，每个查询对应单个Python函数，明确避免跨文件依赖；CS1QA[13]则围绕编程入门课程案例设计，不涉及生产级软件架构。

近期仓库级基准从GitHub议题讨论中收集数据，而非直接建模代码模块关系。CodeRepoQA[9]聚焦预测议题回复，不评估对实际代码模块、文件结构或模块间依赖的理解；CoReQA[3]从176个仓库的GitHub议题和评论中收集问答对，但聚焦于议题解决而非代码理解；Spyder-CodeQA[29]仅包含来自单个IDE仓库的325个问答对；InfiBench[15]和ProCQA[16]则关注通用编程任务或基于Stack Overflow的代码搜索，未针对仓库结构设计。

关键在于，现有基准均未要求模型将代码模块视为仓库内相互关联的架构组件进行理解，未涉及模块接口、跨模块数据流、架构模式或不同代码模块间语义关系等问题。为填补这一空白，本文提出仓库级代码问答基准SWE-QA，专门针对真实代码模块理解设计，要求模型掌握模块间的交互与依赖关系、模块在代码库中的架构作用，以及模块间的语义约定，实现了从“将代码视为孤立函数”到“理解结构化仓库”的根本性转变。

7.3 代码仓库理解

仓库级代码理解已成为现代软件工程工具的关键能力，现有方法主要聚焦于代码生成[26,27,42]、代码翻译[32,36]和议题解决[4,12]。传统方法采用检索增强技术从仓库中收集相关代码上下文[41]；更复杂的系统（如RepoUnderstander[19]）通过引导智能体进行系统导航和分析，实现对仓库的全面理解；RepoFusion[27]则通过训练代码模型整合仓库上下文，提升单行代码补全和仓库特定理解能力；基于图的方法[23]通过表示代码结构捕捉跨文件关系；基于智能体的系统[14,38]则利用工具使用和导航能力，发挥LLM的推理优势，提供仓库感知的编码辅助。

然而，现有仓库理解方法主要针对代码生成和补全任务，在全面问答能力评估方面存在不足。尽管这些方法在上下文检索和代码合成方面表现出色，但缺乏评估多跳推理、架构理解和跨文件依赖分析的系统框架——而这些正是复杂仓库级问题的核心特征。相比之下，本文提出的SWE-QA-Agent采用基于ReAct的智能体框架，专为仓库级问答设计，通过工具实现迭代推理、检索和结构化导航，能够在代码库中进行精准的多跳推理。

8 结论

本文提出仓库级代码问答基准SWE-QA，用于评估LLM回答真实仓库级代码问题的能力。研究从11个热门开源仓库的77100条GitHub议题中提取问题，建立包含核心问题类型和用户意图的两级分类体系，以此为基础设计种子问题。通过LLM实例化和扩展种子问题，最终从12个Python仓库中生成576个高质量问答对（每个仓库48个），涵盖多跳依赖、跨文件上下文等多种推理复杂度。为展示基准的实用性，研究提出基于ReAct风格的自主智能体SWE-QA-Agent，通过文件读取、结构检索、语义搜索等结构化行动，对仓库进行迭代推理，生成贴合上下文的答案。在SWE-QA上的实证评估表明，SWE-QA-Agent在正确性、完整性和推理质量方面优于基线方法，揭示了直接提示和分块检索在处理仓库级复杂问题时的局限性，同时证明了智能体框架在弥补这些局限方面的潜力。未来研究将把SWE-QA扩展到更多编程语言，并纳入动态仓库更新，为LLM-based软件工程工具的评估提供更稳健的支持。

数据可用性

本研究使用的所有代码和数据已公开，网址为：https://github.com/peng-weihan/SWE-QA-Bench。

参考文献

[1] 匿名作者，2025，《SWE-QA基准与SWE-QA-Agent复现包》，https://anonymous.4open.science/r/SWE-QA-D3EC。
[2] Anthropic，2025，《Claude 3.7 Sonnet模型》，https://www.anthropic.com/news/claude-3-7-sonnet/。
[3] Jialiang Chen、Kaifa Zhao、Jie Liu、Chao Peng、Jierui Liu、Hang Zhu、Pengfei Gao、Ping Yang、Shuiguang Deng，2025，《CoreQA：挖掘语言模型在代码仓库问答中的潜力》，arXiv预印本arXiv:2501.03447（2025）。
[4] Silin Chen、Shaoxin Lin、Xiaodong Gu、Yuling Shi、Heng Lian、Longfei Yun、Dong Chen、Weiguo Sun、Lin Cao、Qianxiang Wang，2025，《SWE-Exp：基于经验的软件议题解决》，arXiv预印本arXiv:2507.23361（2025）。
[5] DeepSeek-AI，2025，《DeepSeek-V3模型》，https://api.deepseek.com。
[6] Zhangyin Feng、Daya Guo、Duyu Tang、Nan Duan、Xiaocheng Feng、Ming Gong、Linjun Shou、Bing Qin、Ting Liu、Daxin Jiang等，2020，《CodeBERT：面向编程与自然语言的预训练模型》，《计算语言学期刊协会会刊：EMNLP 2020成果》，1536-1547页。
[7] Mingyang Geng、Shangwen Wang、Dezun Dong、Haotian Wang、Ge Li、Zhi Jin、Xiaoguang Mao、Xiangke Liao，2024，《大语言模型是少样本摘要生成器：基于上下文学习的多意图注释生成》，《第46届IEEE/ACM国际软件工程大会论文集》，1-13页。
[8] Junda He、Jieke Shi、Terry Yue Zhuo、Christoph Treude、Jiamou Sun、Zhenchang Xing、Xiaoning Du、David Lo，2025，《从代码到法庭：LLM作为新型软件评估者》，arXiv预印本arXiv:2503.02246（2025）。
[9] Ruida Hu、Chao Peng、Jingyi Ren、Bo Jiang、Xiangxin Meng、Qinyun Wu、Pengfei Gao、Xinchen Wang、Cuiyun Gao，2024，《CodeRepoQA：软件工程问答大规模基准》，arXiv预印本arXiv:2412.14764（2024）。
[10] Junjie Huang、Duyu Tang、Linjun Shou、Ming Gong、Ke Xu、Daxin Jiang、Ming Zhou、Nan Duan，2021，《CoSQA：20000+条代码搜索与问答网络查询》，《第59届计算语言学期刊协会年会暨第11届国际自然语言处理联合会议论文集（第一卷：长论文）》，虚拟会议，2021年8月1-6日，计算语言学期刊协会，5690-5700页。
[11] Siming Huang、Tianhao Cheng、Jason Klein Liu、Jiaran Hao、Liuyihan Song、Yang Xu、J Yang、Jiaheng Liu、Chenchen Zhang、Linzheng Chai等，2024，《Opencoder：顶级代码大语言模型开放指南》，arXiv预印本arXiv:2411.04905（2024）。
[12] Carlos E Jimenez、John Yang、Alexander Wettig、Shunyu Yao、Kexin Pei、Ofir Press、Karthik R Narasimhan，2024，《SWE-bench：语言模型能否解决真实GitHub议题？》，《国际学习表征会议论文集》。
[13] Changyoon Lee、Yeon Seonwoo、Alice Oh，2022，《CS1QA：面向编程入门课程代码问答辅助的数据集》，CoRR abs/2210.14494（2022）。
[14] Han Li、Yuling Shi、Shaoxin Lin、Xiaodong Gu、Heng Lian、Xin Wang、Yantao Jia、Tao Huang、Qianxiang Wang，2025，《SWE-Debate：面向软件议题解决的竞争性多智能体辩论》，arXiv预印本arXiv:2507.23348（2025）。
[15] Linyi Li、Shijie Geng、Zhenwen Li、Yibo He、Hao Yu、Ziyue Hua、Guanghan Ning、Siwei Wang、Tao Xie、Hongxia Yang，2024，《Infibench：评估代码大语言模型的问答能力》，《神经信息处理系统进展》37（2024），128668-128698页。
[16] Zehan Li、Jianfei Zhang、Chuantao Yin、Yuanxin Ouyang、Wenge Rong，2024，《ProCQA：面向代码搜索的社区级编程问答大规模数据集》，《2024计算语言学与语言资源评估国际联合会议论文集》，13057-13067页。
[17] Chenxiao Liu、Xiaojun Wan，2021，《CodeQA：面向源代码理解的问答数据集》，《计算语言学期刊协会会刊：EMNLP 2021成果》，虚拟会议/多米尼加共和国蓬塔卡纳，2021年11月16-20日，计算语言学期刊协会，2618-2632页。
[18] Yang Liu、Dan Iter、Yichong Xu、Shuohang Wang、Ruochen Xu、Chenguang Zhu，2023，《G-Eval：基于GPT-4的自然语言生成评估，更贴合人类判断》，《2023自然语言处理经验方法会议论文集》，2511-2522页。
[19] Yingwei Ma、Qingping Yang、Rongyu Cao、Binhua Li、Fei Huang、Yongbin Li，2024，《如何理解整个软件仓库》，arXiv预印本arXiv:2406.01422（2024）。
[20] Mistral AI，2025，《Devstral模型》，https://mistral.ai/news/devstral。
[21] OpenAI，2024，《GPT-4o模型》，https://openai.com/index/hello-gpt-4o/。
[22] OpenAI，2025，《GPT-5模型》，https://openai.com/index/introducing-gpt-5/。
[23] Siru Ouyang、Wenhao Yu、Kaixin Ma、Zilin Xiao、Zhihan Zhang、Mengzhao Jia、Jiawei Han、Hongming Zhang、Dong Yu，2024，《RepoGraph：基于仓库级代码图的人工智能软件工程增强》，《第13届国际学习表征会议论文集》。
[24] Qwen团队，2024，《Qwen2.5-Coder模型》，https://qwenlm.github.io/blog/qwen2.5-coder/。
[25] Surya Prakash Sahu、Madhurima Mandal、Shikhar Bharadwaj、Aditya Kanade、Petros Maniatis、Shirish K. Shevade，2024，《CodeQueries：面向代码的语义查询数据集》，《第17届软件工程创新会议论文集》，印度班加罗尔，2024年2月22-24日，ACM，7:1-7:11页。
[26] Yuling Shi、Songsong Wang、Chengcheng Wan、Xiaodong Gu，2024，《从代码到正确性：通过分层调试填补代码生成的最后一公里》，arXiv预印本arXiv:2410.01215（2024）。
[27] Disha Shrivastava、Denis Kocetkov、Harm De Vries、Dzmitry Bahdanau、Torsten Scholak，2023，《RepoFusion：训练代码模型理解仓库》，arXiv预印本arXiv:2306.10998（2023）。
[28] Hwanjun Song、Hang Su、Igor Shalyminov、Jason Cai、Saab Mansour，2024，《FineSurE：基于LLM的细粒度摘要评估》，《第62届计算语言学期刊协会年会论文集（第一卷：长论文）》，906-922页。
[29] Jan Strich、Florian Schneider、Irina Nikishina、Chris Biemann，2024，《提升大语言模型的仓库级代码问答能力》，《第62届计算语言学期刊协会年会论文集（第四卷：学生研究研讨会）》，209-244页。
[30] Qwen团队，2024，《Qwen2技术报告》，arXiv预印本arXiv:2407.10671（2024）。
[31] Tree-sitter，2025，《Tree-sitter》，https://tree-sitter.github.io/tree-sitter/。
[32] Chaofan Wang、Tingrui Yu、Jie Wang、Dong Chen、Wenrui Zhang、Yuling Shi、Xiaodong Gu、Beijun Shen，2025，《EVOC2RUST：面向项目级C到Rust翻译的骨架引导框架》，arXiv预印本arXiv:2508.04295（2025）。
[33] Ruiqi Wang、Jiyu Guo、Cuiyun Gao、Guodong Fan、Chun Yong Chong、Xin Xia，2025，《LLM能否替代人类评估者？LLM作为软件工程评估者的实证研究》，《ACM软件工程期刊》2，ISSTA（2025），1955-1977页。
[34] Yue Wang、Weishi Wang、Shafiq Joty、Steven CH Hoi，2021，《CodeT5：面向代码理解与生成的标识符感知统一预训练编解码器模型》，《2021自然语言处理经验方法会议论文集》，8696-8708页。
[35] Yanlin Wang、Yanli Wang、Daya Guo、Jiachi Chen、Ruikai Zhang、Yuchi Ma、Zibin Zheng，2024，《RLCoder：面向仓库级代码补全的强化学习》，《2025 IEEE/ACM第47届国际软件工程大会论文集》，IEEE计算机学会，165-177页。
[36] Yanli Wang、Yanlin Wang、Suiquan Wang、Daya Guo、Jiachi Chen、John Grundy、Xilin Liu、Yuchi Ma、Mingzhi Mao、Hongyu Zhang等，2024，《Repotransbench：面向仓库级代码翻译的真实场景基准》，arXiv预印本arXiv:2412.17744（2024）。
[37] Xiaorui Xue、Jiansong Zhang、Yunfeng Chen，2024，《基于微调与蒸馏预训练Transformer模型的建筑规范问答框架》，《自动化建造》168（2024），105730页。
[38] John Yang、Carlos E Jimenez、Alexander Wettig、Kilian Lieret、Shunyu Yao、Karthik Narasimhan、Ofir Press，2024，《Swe-agent：智能体-计算机接口实现自动化软件工程》，《神经信息处理系统进展》37（2024），50528-50652页。
[39] Shunyu Yao、Jeffrey Zhao、Dian Yu、Nan Du、Izhak Shafran、Karthik R. Narasimhan、Yuan Cao，2023，《ReAct：语言模型中的推理与行动协同》，《第11届国际学习表征会议论文集》，卢旺达基加利，2023年5月1-5日，OpenReview.net。
[40] Tingrui Yu、Xiaodong Gu、Beijun Shen，2022，《基于任务自适应序列到序列预训练的代码问答》，《2022第29届亚太软件工程会议论文集》，IEEE，229-238页。
[41] Fengji Zhang、Bei Chen、Yue Zhang、Jacky Keung、Jin Liu、Daoguang Zan、Yi Mao、Jian-Guang Lou、Weizhu Chen，2023，《RepoCoder：通过迭代检索与生成实现仓库级代码补全》，《2023自然语言处理经验方法会议论文集》，新加坡，2023年12月6-10日，Houda Bouamor、Juan Pino、Kalika Bali（编），计算语言学期刊协会，2471-2484页。
[42] Kechi Zhang、Jia Li、Ge Li、Xianjie Shi、Zhi Jin，2024，《CodeAgent：基于工具集成智能体系统的真实仓库级编码挑战代码生成增强》，《第62届计算语言学期刊协会年会论文集（第一卷：长论文）》，13643-13658页。
[43] Qihao Zhu、Daya Guo、Zhihong Shao、Dejian Yang、Peiyi Wang、Runxin Xu、Y Wu、Yukun Li、Huazuo Gao、Shirong Ma等，2024，《Deepseek-coder-v2：突破代码智能领域闭源模型壁垒》，arXiv预印本arXiv:2406.11931（2024）。