首先，我们要感谢主办方组织了这样一场有意义的比赛。
我们参加这场比赛是为了学习 AI 代理如何编码，我们学到了很多。正如后面详细讨论的那样，我们认为获得第三名只是运气好，但很荣幸能获得这个位置。

流程

我们解决方案的大部分基于 starter-notebook-select-patch-verify by @huikang。我们的独特之处在于，在开始解决问题之前，我们使用问题的难度评估来选择应该解决哪些问题和跳过哪些问题。

为了减少将 LLM 加载到 GPU 内存所需的时间（只加载一次），我们在所有运行中使用了相同的模型 (deepseek-r1-distill-llama-70b-awq)。对于难度评估，我们将 LoRA 适配器应用于相同的基础模型。

整体流程如下：

1. 难度评估

• 使用 LoRA 微调模型进行问题难度评估
• 我们使用了 SWE-bench_Verified 数据集，并训练了一个 简单/中等/困难 的多分类任务。
• 计算每个问题是简单的概率，如果小于 0.5 则跳过回答该问题

2. 搜索查询生成与搜索

• 根据问题内容和仓库目录结构生成查询，以找到解决问题所需的部分。
• 设置 LLM 温度参数为 0.6 并运行 6 个并行任务
• 取匹配查询的行及其前后各 12 行，用作补丁生成的输入。

3. 补丁生成

• 对于六个搜索结果中的每一个，使用问题和搜索结果作为输入生成六个补丁。

4. 验证

通过以下过程检查补丁是否正确。如果六个都不正确，则跳过该问题的回答。如果有一个通过了所有检查，则选择其中一个作为答案：

• LLM 判断：使用 LLM 判断补丁是否正确（是/否）
• 格式验证：确定 unidiff.PatchSet 是否可以解析为补丁并包含一个或多个更改。
• 试运行测试：运行 patch 命令 dry 检查是否可以无错误应用。

难度评估的训练

我们使用 LoRA (Low-Rank Adaptation) 微调进行难度评估。

数据集和划分

• 数据集：SWE-bench verified（共 500 个问题）
• 划分：400 个问题用于训练，100 个问题用于验证

类别定义

• 简单：可以在 15 分钟内修复
• 中等：15 分钟到 1 小时
• 困难：超过 1 小时

模型架构

• 基础模型：deepseek-r1-distill-llama-70b-awq
• 方法：rank 为 32 的 LoRA 适配
• 任务：3 类分类（简单/中等/困难）

结论

在这次比赛中，错误答案的惩罚很大，所以避免错误答案有很大的优势。虽然我们通过评估难度级别避免了无法解决的问题，但最好使用其他方法提前避免无法解决的问题，避免提交不合适的补丁等，以提高分数。

最重要的是，像许多参与者一样，@huikang 的 starter notebook 对我们的解决方案至关重要，并作为许多其他发现的基础。我们表示最深切的感谢。