SWE-QA: Can Language Models Answer Repository-level Code Questions?

以下是论文《SWE-QA：语言模型能否回答仓库级别的代码问题？》的详细技术总结：

1. 问题陈述

当前的大语言模型（LLMs）在代码理解方面已展现出潜力，但现有的基准测试（如 CoSQA、CodeQA）主要集中于孤立的代码片段、函数或 API。这些设置未能捕捉现实世界软件工程中的复杂性，开发者必须：

• 导航跨越多个文件的大型、互联代码库。
• 理解软件架构和设计原理。
• 追踪长程依赖关系并执行多跳推理。
• 综合架构知识以回答复杂的“为什么”和“如何”类问题。

目前缺乏高质量、经人工验证的基准测试，用于评估 LLMs 在仓库级别问答（QA）中的表现，这类任务需要深度的多文件上下文和结构理解。

2. 方法论：SWE-QA 基准构建

作者提出了SWE-QA，这是一个仓库级别的代码 QA 基准，通过包含 15 个多样化 Python 仓库（12 个来自 SWE-Bench，3 个来自 SWE-Bench-Live）的四阶段流程（图 2）构建而成。

A. 种子收集与分类体系构建

• 数据源： 从 12 个热门仓库爬取了 77,100 个 GitHub 问题（Issues）。
• 过滤： 筛选出 41,955 个内容充实（>1,000 字符）的问题，并利用 LLM 提取出 127,415 个显式的代码相关问题。
• 分类体系： 两位拥有 3 年以上经验的人类专家手动分析了 1,000 个采样问题，创建了一个两级分类体系：
  • 一级（疑问词）： What（什么）、Why（为什么）、Where（哪里）、How（如何）。
  • 二级（意图）： 12 个细粒度类别（例如：依赖追踪、设计原理、功能定位、算法实现）。
• 分布： “如何”类问题（35.2%）和“哪里”类问题（28.4%）最为频繁，反映了对过程性和位置性知识的需求。

B. 问题实例化

• 上下文提取： 使用 tree-sitter 将仓库结构解析为类型化图（节点：类、方法、文件；边：调用、导入）。
• 生成： 选择焦点元素（例如特定类），将其结构上下文与源自分类体系的种子模板相结合。
• 过程： LLM 生成针对特定仓库定制的候选问题，确保它们需要多跳推理，且无法通过简单检索回答。

C. 答案收集与验证

• RAG 流程： 使用检索增强生成（RAG）方法生成答案，检索相关的代码片段、文档和元数据。
• 人在回路（Human-in-the-Loop）：
  • 专家修订： 两位高级开发人员使用 Cursor 等工具审查每个答案的事实准确性、完整性和清晰度。分歧由第三位专家解决。
  • 质量过滤： 如果问答对存在歧义、事实错误或缺乏足够的代码依据，则予以丢弃。
• 最终数据集： 720 个高质量 QA 对（每个仓库 48 个），涵盖 13,300 个文件和超过 340 万行代码。

3. 主要贡献

1. SWE-QA 基准： 一个包含 720 个人工验证 QA 对的仓库级别 QA 基准，跨越 15 个 Python 仓库。它独特地结合了多跳推理、跨文件依赖和架构理解。
2. 灵活的生成流程： 一个模块化框架，允许利用种子模板和静态代码分析，为任何新的开源仓库半自动创建 QA 数据集。
3. 全面评估： 对各种上下文增强策略（直接提示、RAG、智能体框架）下的 LLMs 进行了严格评估。

4. 实验结果

作者使用不同策略评估了六个先进的 LLMs（包括 GPT-5.1、Gemini 2.5 Pro、GLM-4.6 和 Qwen3-Coder）：

• 上下文增强的影响：
  • 直接提示： 表现不佳（例如，Kimi K2 得分约为 51/100），突显了仓库上下文的必要性。
  • RAG（滑动窗口/函数分块）： 显著提升了性能（例如，+10–14 分）。
  • 智能体框架（OpenHands, SWE-agent）： 通过启用迭代推理和工具使用取得了最佳结果。OpenHands 配合 GPT-5.1 取得了 70.79/100 的最高分。
• 模型性能：
  • GPT-5.1 和 GLM-4.6（配合 OpenHands）领先。
  • 较小模型（如 Qwen3-30B）在智能体框架中表现挣扎，表现与 RAG 相当或更差，表明其在长期记忆和工具规划方面存在局限性。
  • 商业工具（Cursor、通义灵码）表现具有竞争力（69–70 分），验证了端到端工具增强解决方案的有效性。
• 分类体系分析：
  • 模型在 “为什么” 类问题（设计原理）和关于 API 支持的 “如何” 类问题上表现优异，这些信息通常明确存在于文档字符串中。
  • 模型在 “什么”（架构探索）和 “哪里”（功能定位）类问题上表现挣扎，这些问题需要跨文件重构分散的逻辑。
• 跨仓库泛化：
  • 性能因仓库复杂度而异。"Flask" 最容易（75.42），而 "Pylint"（62.01）和 "Conan"（64.51）最具挑战性。
  • 来自 SWE-Bench-Live 的仓库（数据泄露较少）比来自 SWE-Bench 的仓库更难。

5. 意义与未来方向

• 现实评估： SWE-QA 超越了片段级测试，评估现实世界软件工程任务所需的“整个仓库”理解能力。
• 智能体框架： 结果表明，虽然 RAG 有帮助，但基于智能体的框架目前是在导航复杂的多文件代码库方面最有效的方法，尽管其 Token 成本更高。
• 局限性： 该基准目前仅限于 Python 且基于静态快照。未来工作旨在扩展到其他语言以及动态演进的仓库。
• 开放挑战： 论文强调，LLMs 在深度依赖追踪和精确的位置推理方面仍存在困难，表明需要更好的代码图集成和推理能力。

论文结论指出，虽然 LLMs 在仓库级别 QA 方面展现出潜力，特别是在配合智能体增强时，但在处理复杂的多跳依赖关系和架构推理方面仍面临重大挑战。