CuraLoc ищет баги в репозиториях одним планом и тратит на 90% меньше токенов

Исследователи из команды Sangeeta Warrier предложили CuraLoc, метод локализации ошибок на уровне всего репозитория. Он заменяет длинную цепочку вызовов модели одним планом осмотра кода. На SWE-bench Verified с GPT-5.2 система показала Func@1 59,3% против 53,8% у LocAgent и израсходовала на 90,3% меньше записанных токенов. Препринт появился на arXiv 22 октября 2026 года, а вторая версия вышла 26 октября.

Почему баг-репорт плохо подсказывает, где чинить

Баг-репорт описывает симптом: что сломалось и при каких условиях. Где именно нужно менять код, в нём почти никогда не написано. Поэтому у агентов для исправления ошибок есть отдельный этап локализации, на котором среди тысяч файлов и функций надо найти те, что стоит править.

Большинство существующих методов решают эту задачу итеративно. Модель смотрит на структуру репозитория, выбирает файл, читает его, решает, куда идти дальше, и так по кругу. Каждый шаг означает новый вызов LLM и новую порцию токенов в контексте. Счёт растёт быстро, а качество зависит от того, не свернёт ли агент на ложный след на третьем или пятом шаге.

Авторы CuraLoc проверяют другую гипотезу: решения о том, что осматривать, можно спланировать заранее, до загрузки исходного кода.

Один план вместо цепочки шагов

Пайплайн CuraLoc устроен в несколько этапов. Сначала система отбирает файлы-кандидаты и описывает их символы (функции, классы, методы) компактными поведенческими и структурными описаниями. Сами исходники на этом этапе в модель не попадают.

Дальше следует единственное планирующее решение. В одном вызове модель делает три вещи:

• выбирает стартовые символы;
• определяет, какие связи от каждого из них стоит проверить (вызовы, зависимости и другие структурные отношения в коде);
• формулирует гипотезы о том, какие правки наиболее вероятны.

После этого в работу вступает детерминированный поиск. Он без участия модели собирает запрошенный исходный код. Затем модель выполняет финальное ранжирование, опираясь на уже сформулированные гипотезы. Её рассуждения уходят на выбор и сравнение кода, а не на управление каждым шагом выгрузки.

Что показали бенчмарки

Авторы тестировали метод на SWE-bench Lite и SWE-bench Verified. Основная метрика на Verified — Func@1, то есть доля случаев, когда верная функция оказывается на первом месте. Для Lite приведён Func@5, когда она попадает в пятёрку лучших.

Сравнение на SWE-bench Verified с GPT-5.2 по Func@1:

• CuraLoc: 59,3%;
• RepoSearcher: 56,2%;
• LocAgent: 53,8%;
• Agentless: 39,6%.

По расходу токенов CuraLoc тратит на 90,3% меньше записанных токенов, чем LocAgent. Это не мелкая оптимизация: вместо десятков обращений к модели вся навигация сворачивается в минимальное их число.

На SWE-bench Lite CuraLoc набрал 83,8% Func@5. Относительно Agentless это улучшение более чем на 15%.

Кроме того, авторы показали, что метод не привязан к одной модели. Сильную точность локализации CuraLoc демонстрирует и с GPT-5.2, и с GPT-6 Astra.

Что из этого можно взять в работу

Главный вывод для разработчиков агентов в том, что автономная навигация модели по кодовой базе не всегда оправдывает свою цену. Если часть решений вынести в детерминированный слой, а модели оставить задачи, где она сильна (гипотезы о правках и сравнение кандидатов), то в локализации ошибок можно выиграть одновременно в точности и в стоимости.

Для команд, которые строят собственных кодинг-агентов, это повод пересмотреть бюджет токенов на этапе поиска. Локализация часто стоит до генерации патча и определяет, будет ли патч вообще разумным. Дешёвый и устойчивый первый этап удешевляет и весь цикл исправления.

Есть и ограничения, о которых говорят сами постановка и метрики. Все результаты получены на SWE-bench Lite и Verified, а это Python-репозитории с известными задачами. Как схема поведёт себя на закрытых монорепозиториях и в других языках, предстоит проверять отдельно. Но для задачи «найти функцию по баг-репорту» CuraLoc даёт сильный аргумент в пользу планирования вместо блуждания.

Работа опубликована в разделе Machine Learning с перекрёстной категорией Software Engineering (cs.SE), DOI 10.48550/arXiv.2610.31809.