第五名解决方案

首先，感谢 Kaggle 和 Andy 举办这场有趣的比赛。祝贺所有参与者。

我的解决方案基于 huikang 的 notebook。我非常感谢他对这次比赛的贡献。

我的 notebook 在此处。

我对公开 notebook 做了 2 处主要更改：

• 新的解析模块 get_selection_query_x（基于正则表达式），取代了旧的 get_selection_query（基于 LLM），用于解析错误 traceback 并准确识别需要编辑的文件和代码片段。
• 使用 git 冲突标记 (GCM) 格式生成修复 patch，并通过 git diff . 创建 diff patch，而不是直接生成 diff patch —— 与 第一名 的方法相同。

跳过非错误 traceback 问题

在我的测试中，只有在问题中包含错误 traceback 时，才能识别出正确的修改位置。因此，我决定跳过所有没有错误 traceback 的句子以加快测试速度。此外，根据我在公开排行榜 (Public LB) 上的探索，包含错误 traceback 的句子数量在 6 < n < 11 之间。Eduardo 在公开 LB 上解决了 9 个句子的事实某种程度上加强了这一假设。

如果问题包含 traceback，则进入下一步 get_selection_query_x：

上下文检索

公开 notebook 中的 get_selection_query 最初生成基于 LLM 的关键词搜索，当 LLM 建议的短语在仓库中不存在或过于简单时会出现问题，导致产生过多嘈杂的代码片段。

我构建了 get_selection_query_x（基于正则表达式）来提取并将错误 traceback 映射到仓库中的文件和错误位置。该模块包含 2 个主要组件：

• 识别 traceback 中出现错误的文件路径，并将其映射到新仓库中的相应位置
• 提取每个出现错误的文件和行位置的整个子 traceback

该模块兼容 Python 3.10、3.11 和 3.12 的错误报告风格，确保正确且最小化地搜索需要修复的位置。如果无法识别文件或错误 -> 使用旧的 get_selection_query (基于 LLM)。

示例：

problem = """
TypeError: unsupported format string passed to NoneType.__format__
Regression in #2459

### Steps to reproduce
a.py:
```py
class A:
    def __init__(self):
        self._magnitude = None

    def name(self) -> str | None:
        if self._magnitude:
            return f"M {self._magnitude:.1f}"
```
```
pylint a.py
```
### Current behavior
```
  File "/Users/jwalls/release/lib/python3.12/site-packages/astroid/nodes/node_classes.py", line 4778, in _infer_from_values
    yield from nodes[0]._infer(context, **kwargs)
  File "/Users/jwalls/release/lib/python3.12/site-packages/astroid/nodes/node_classes.py", line 4695, in _infer
    formatted = format(value.value, format_spec.value)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: unsupported format string passed to NoneType.__format__
```
"""

print(get_selection_query_x(problem))
# {'/kaggle/working/q1/repo/astroid/nodes/node_classes.py': ['    yield from nodes[0]._infer(context, **kwargs)', '    formatted = format(value.value, format_spec.value)']}

生成修复 patch

我的方法使用 git 冲突标记 (GCM) 格式生成修复 patch，而不是直接生成 diff patch，这使得大多数 patch 都是有效的。我为每个问题生成 8 个查询，使用 DeepSeek-R1-Distill-Qwen-14B 模型。

GCM 提示词 (Prompt)：

We are currently solving the following issue within our repository. Here is the issue text:
--- BEGIN ISSUE ---
{problem_statement}
--- END ISSUE ---

Below are some code segments, from the repository. One or more of these files may contain bugs.

--- BEGIN FILE ---
```
{file_content_string}
```
--- END FILE ---

Please first localize the bug based on the issue statement, and then generate *SEARCH/REPLACE* edits to fix the issue.

Every *SEARCH/REPLACE* edit must use this format:
1. The file path
2. The start of search block: <<<<<<< SEARCH
3. A contiguous chunk of lines to search for in the existing source code
4. The dividing line: =======
5. The lines to replace into the source code
6. The end of the replace block: >>>>>>> REPLACE

Here is an example:

```python
### mathweb/flask/app.py
<<<<<<< SEARCH SEARCH
from flask import Flask
=======
import math
from flask import Flask
>>>>>>> REPLACE
```

Please note that the *SEARCH/REPLACE* edit REQUIRES PROPER INDENTATION. If you would like to add the line '        print(x)', you must fully write that out, with all those spaces before the code!
Wrap each *SEARCH/REPLACE* edit in a code block as shown in the example above. If you have multiple *SEARCH/REPLACE* edits, use a separate code block for each one.

创建 diff patch： 提取搜索/替换内容，然后直接对仓库进行编辑（我创建了一个假仓库），然后使用 git diff 命令生成有效的 diff patch。

创建假仓库 -> 应用所有编辑命令 -> 提交 -> 运行 !git diff .

评估

我只是选择了第一个有效的 patch 进行提交。我的第二个包含所有步骤的提交随机损坏了，迫使我创建了一个更简单的提交。

总结

该方法基于强大的搜索模块和使用 git 冲突标记格式创建解决方案。无需运行测试，无需评估，不需要运行环境设置。

无效的方法

• 通过计算添加和删除的行数来检查和修复 diff patch 的数量 -> 没有改进
• 更大的模型：DeepSeek-R1-Distill-Qwen-32B 在我的测试中没有改进，我还没有测试许多其他模型，因为我参加比赛比较晚。

致谢

• @huikang 为比赛做出的巨大贡献。
• 许多论坛讨论。