CuraLoc находит баг в коде на 59,3% точнее конкурентов и тратит в 10 раз меньше токенов

Когда в код попадает жалоба на баг, первая проблема — не исправить ошибку, а понять, где именно в репозитории она прячется. Отчёт о баге описывает симптом («при вводе X система выдаёт неверный Y»), но не называет файл и функцию, которые нужно менять. Авторы новой работы предложили способ автоматически находить эти места точнее и дешевле, чем это делали существующие инструменты.

Почему старые подходы были дорогими

Большинство систем локализации багов работают по принципу агента: модель смотрит на код, решает, куда «пойти» дальше — в вызывающую функцию, в родительский класс, в соседний метод — и так постепенно сужает круг подозреваемых. Это гибко, но каждый шаг — отдельный запрос к модели, а значит, десятки обращений и огромный расход токенов на одну задачу.

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

Как работает CuraLoc

Система действует в три этапа, с каждым разом углубляясь в код:

• Выбор файлов. Модель смотрит на структуру репозитория и по трём разным «углам зрения» — кто владеет логикой, кто её выполняет, кто её проверяет — предлагает список файлов-кандидатов, не более 15.
• Выбор символов и действий. Из отобранных файлов модель получает не сам код, а компактные описания функций и классов: сигнатуру, роль в структуре, краткое резюме поведения (из документации или от вспомогательной модели меньшего размера). На основе этого модель одним решением выбирает, с каких функций начать осмотр, какую связь проверить у каждой (вызовы, наследование, переопределения) и формулирует гипотезы о том, где может быть правка.
• Получение кода и ранжирование. Только теперь система автоматически (без участия модели) подгружает реальный исходный код нужных фрагментов, и финальным запросом модель ранжирует до десяти кандидатов на правку, используя и код, и ранние гипотезы.

Ключевая экономия — в том, что модель принимает решение «что осматривать» один раз, компактно, а не пошагово после каждого нового куска кода.

Что показали тесты

Метод проверяли на двух наборах реальных багов из открытых проектов — SWE-bench Lite (274 задачи) и SWE-bench Verified (454 задачи), сравнивая с тремя существующими методами: LocAgent, RepoSearcher и Agentless, с моделью GPT-5.2.

• На SWE-bench Verified точность попадания в точное место правки (метрика Func@1) выросла с 53,8% у LocAgent до 59,3% у CuraLoc — при этом токенов потратили на 90,3% меньше.
• CuraLoc также обошла RepoSearcher (56,2%) и Agentless (39,6%) по той же метрике.
• На SWE-bench Lite CuraLoc добилась 83,8% точности в топ-5 предсказаний, что на 15% относительно лучше, чем у Agentless.
• Метод проверили и на новой модели GPT-6 Astra — результаты остались устойчиво высокими, то есть подход не привязан к одной конкретной модели.

Отдельно авторы проверили, что именно дает прирост точности. Оказалось, что просто находить правильные файлы — не главное: даже когда система правильно выбирала файлы, но символы внутри них ранжировались по формальному порядку (а не по смыслу бага), точность падала с 67,2% до 42,3%. Значит, основной выигрыш CuraLoc — именно в осмысленном выборе того, какие связи кода проверять, а не в более широком охвате файлов.

Что это значит на практике

Для команд, которые занимаются автоматическим ремонтом кода или строят ИИ-агентов для разработки, CuraLoc демонстрирует рабочую альтернативу дорогим пошаговым агентам: можно заменить десятки итеративных запросов одним продуманным планом осмотра и получить точность не хуже, а то и выше — при кратно меньшем расходе токенов. Это особенно важно для компаний, которые хотят встроить автопоиск багов в CI/CD-пайплайны, где цена и скорость каждого запроса критичны.