共计 1658 个字符，预计需要花费 5 分钟才能阅读完成。
个人 Github Blog 地址：https://wj-mcat.github.io/agent-handbook/docs/paper-reading/2024/08/swe-bench
现实中的软件开发问题非常复杂，为了公正全面的评估现实中开发过程，作者根据 Github issue 创建了一组评估数据集，主要是 Python 相关语言。
给定一个 Issue 的描述，此时 LLM 需要基于当前的代码版来修改此问题，此时就涉及到对于代码的修改横跨不同的 package、file、class、method 等多个维度，同时还需要和真实执行环境进行交互，输入文本长度会很长（在输入中塞入不同 file 的所有的代码，此时消耗的 token 会很多）。
Benchmark Construction
Github 上面的项目很多，质量层次不齐，此时需要构建一个高质量的数据集需要进行严格的筛选，此时会有如下筛选标准：
Repo 筛选和数据筛选
筛选出 Github 排名 12 的 Python 项目，首先因为他们的 PR 数量多，代码质量高，具备完整的单测和 Contributor Guides（通常是先发 Issue，再发 PR 来 fix，此时就容易构建训练数据）。
PR 筛选
不是所有的 PR 都要纳入到评估数据集当中，也是需要经过一定筛选：
- 该 PR 是否被合入
- 是否有解决 Issue 中的问题
- 是否有修改单测中的文件（保证新增的功能是否有通过单测进行监控到）
单测检测
用合入后的 PR 单测来检测合入前后的代码版本，如果从 fail 变成 pass 即说明此 PR 解决了 Issue 中的问题。
任务定义
模型输入
输入是一个 Repo 中的 issue 描述和整个 CodeBase 的代码文件，于是模型就需要基于 Issue 在整个 Codebase 上面进行修改。
评估指标
当模型生成修改建议（diff）后可通过（patch）命令将 changes 应用到当前代码库当中，然后来执行单测，如果单测通过了，则说明此修改建议解决了 Issue 中的问题。
针对于某一个任务是通过单测来监控是否通过，针对于整个评估任务，是通过 ACC 来作为整体评估指标。
SWE-Llama：通过 finetune 的方式来优化模型解决问题的能力。
作者在实验中通过 finetune CodeLlama 7/13B 模型来提升在 SWE-Bench 上的模型能力，可是也存在一些问题：
- Issue 中的描述质量层次补齐，模型很难 Follow 其中的指令。
- 模型是无法重新生成整个 repo 的代码，理想情况下至需要生成 git diff 的部分内容即可。
训练数据
作者从 Python top 37 仓库当中筛选出 19000 个 Issue-PR 对用来训练，此时不需要模型生成单测相关的代码。
训练细节
为了让模型能够生成 patch 相关内容（关键修改代码），此时需要对训练数据进行构建：
- 通过 Prompt 将 Issue 描述和相关代码文件拼接起来作为模型的输入。
- 将 patch 作为训练中的可学习内容（golden patch），这样模型就只需要学习最关键的部分内容即可。
作者使用 Lora 进行 finetune，同时将训练数据中总长度超过 30000 的 token 给剔除掉了，最终控制到 10000 个数据集。
实验设置
Retrieval-Based 方法
在模型的输入中，issue 的描述是非常短的，作者训练数据集中平均长度为 195 个 token，而整个 CodeBase 的 token 是非常长的：438K 行 代码（还不是 token 哟）。
此时两者长度极度不均衡，会导致模型难以理解 issue 问题，也无法从代码中找到对应的修改位置：非常考验 LLM 的长文本理解能力，很显然，这种能力是经不起考验的，此时就需要想办法来解决。
最直观的想法肯定是：从 codebase 当中召回出对应的文件，然后塞入到模型当中。
此时 Dense-Retrieval 不太适合当前任务：query 和 document 都太长了，现有 dense-retrieval 的模型支持长度都比较短，所以没办法适用。所以作者们采用了 BM25（关键字召回）的 Sparse-Retrieval 的方法来召回出相关代码文件。
