来源笔记
Evaluating Repository-level Software Documentation via Question Answering and Feature-Driven Development
Software DocumentationRepository Level BenchmarkQuestion AnsweringCode IntelligenceSoftware Engineering
摘要
SWD-Bench 是一个用于评估仓库级软件文档的基准，通过测试 LLM 能否根据文档回答开发问题来完成评估。它把评价重点从含糊的裁判打分，转到仓库理解和实现细节上的任务表现。
问题
- 现有文档基准通常只给小段代码打分，因此看不到文档是否解释了跨多个文件和模块的功能。
- 常见评估方法，尤其是使用 Likert 量表的 LLM-as-a-judge，标准模糊，而且往往缺少足够的仓库知识来判断对错。
- 这一点很重要，因为仓库文档要用于真实工作：判断某个功能是否存在、找到对应代码，并理解到足以扩展或修复的程度。
方法
- 论文构建了 SWD-Bench，这是一个仓库级 QA 基准，包含 4,170 条条目，数据来自 12 个 SWE-Bench 仓库中的 pull request。
- 每条样本被转成三个和开发流程相关的 QA 任务：Functionality Detection（这个功能是否存在？）、Functionality Localization（哪些文件实现了它？）和 Functionality Completion（补全缺失的技术细节）。
- 数据流程从 177.4k 个 GitHub pull request 开始，经过多步筛选，保留已合并、已审查、与功能相关且是持续性变更的 PR，最后留下 4,170 个高质量 PR。
- 对每个 PR，基准收集仓库上下文，例如依赖分析、关联 issue、外部页面和提交历史，然后用 LLM 按 WHAT/WHY/HOW 三个维度写出功能描述。
- 评估时，把模型答案和从 PR 元数据与代码变更中提取出的客观参考答案比较，而不是直接让 LLM 给文档质量打分。
结果
- SWD-Bench 包含 4,170 个基准条目。功能描述平均长度为 771.45 个字符；正向检测样本占 50.65%。
- 定位任务平均每条需要找到 2.01 个文件，范围是 1 到 62 个文件。
- 补全任务平均每条需要补充 7.48 个细节，范围是 3 到 23 个细节。
- 在 100 条抽样条目上的人工验证中，标注者间一致性达到 90% 以上的 Kappa，支持数据集质量。
- 论文声称，当前仓库级文档生成方法仍有明显局限，而仓库上下文更丰富的方法表现更好，但这段摘要没有给出完整的任务指标表。
- 在下游使用中，最佳方法生成的文档让 SWE-Agent 的 issue 解决率提高了 20.00%，说明它对解决问题有实际价值。