Почему успешный результат — не всегда успешный поиск
До сих пор работу ИИ-агентов для кода оценивали по итоговому результату — исправили они ошибку или нет. Такой подход скрывает детали: возможно, агент вообще не заглянул в нужный фрагмент кода, или же нашёл файл, но сгенерировал неправильное исправление. Внешне и то и другое выглядит одинаково.
Международная группа учёных при участии Шанхайского университета Цзяо Тун решила восполнить этот пробел с помощью бенчмарка SWE-Explore. Он проверяет только первый этап процесса: агент получает описание ошибки и проект, после чего должен выдать ранжированный список участков кода, которые считает важными.
Как определяют действительно важные участки
Вручную определить, какие строки действительно нужны для исправления, почти невозможно. Поэтому авторы пошли другим путём: для каждой из 848 задач в датасете есть как минимум два успешных решения от мощных моделей — GPT-5.4, Gemini 3 Pro, Claude Sonnet 4.6 или Kimi K2.6.
Из этих удачных запусков исследователи извлекли информацию о том, какие файлы и строки модель действительно просматривала перед исправлением. Участки, к которым обращались несколько независимых путей решения, считаются сигналом полезного контекста. Они не обязательны строго, но с высокой вероятностью указывают на значимые места. Затем отдельный этап верификации дополняет ключевые фрагменты, а команда вручную проверяет каждую выявленную область.
Датасет охватывает 203 открытых проекта на десяти языках программирования. Доминирует Python (547 из 848 задач), за ним идут Go, JavaScript и Rust.
Ключевые слова почти не помогают
В эксперименте традиционный поиск по ключевым словам сравнивали с пятью универсальными агентами для кода (включая Claude Code, Codex, OpenHands) и четырьмя исследовательскими системами, специально созданными для поиска кода.
Старый добрый поиск по ключевым словам показал результат едва выше случайного. В отчёте авторы показывают почему. Описание ошибки «RuntimeWarning on Overflow» содержит термины, которые гораздо чаще встречаются в шаблонах и документации проекта, а не в исходном коде. ИИ-агенты заметно вырываются вперёд, потому что исследуют проект пошагово, а не просто сортируют все найденные совпадения.
Точность на уровне строк резко падает
На уровне файлов агенты справляются хорошо: они находят правильный файл, ставят его в начало выдачи и не раздувают список. Но как только тест переходит к отдельным строкам кода, система разваливается. Универсальные агенты покрывают лишь 14–19% действительно значимых строк.
Установка более сильной языковой модели не решает проблему. Команда протестировала одного и того же агента с шестью разными моделями от OpenAI, Anthropic, Google, Moonshot и Zhipu. Семейство GPT лидирует, но общая картина сохраняется: доля попаданий в файлы стабильно выше, чем реальное покрытие строк.
Разные архитектуры агентов показывают на удивление схожие результаты. Claude Code, Codex, OpenHands, Mini-SWE-Agent и AweAgent демонстрируют почти одинаковые оценки по всем метрикам.
Исключением стала исследовательская система CoSIL. Она сканирует код как сеть взаимосвязанных строительных блоков и достигает гораздо более высокого покрытия строк. Среди специализированных систем локализации AutoCodeRover работает точно, но консервативно, а OrcaLoca создаёт мало шума, но пропускает много нужных мест.
Ремонт не работает без достаточного контекста
В контролируемом абляционном эксперименте команда искусственно меняла объём контекста. Модель для исправления видела 0, 25, 50, 75 или 100% ключевых областей, иногда с добавлением нерелевантного кода. Для простых задач из датасета проявился чёткий пороговый эффект: пока видно меньше половины необходимых ключевых зон, исправления обычно проваливаются.
Вероятность успеха резко подскакивает, когда покрытие переходит от 50 к 75%. Улучшение не происходит постепенно — нужен определённый минимум подсказок. Для сложных задач эффект заметно слабее: если проблема изначально превышает способности модели, даже лучший контекст не сильно помогает.
Когда критически важные места уже доступны, второстепенный код почти не мешает. Агент, прочитавший слишком мало, справляется хуже, чем тот, что прочитал лишнего. Главный вывод для будущих улучшений ясен: меньше фильтровать — больше читать. Код и данные доступны на GitHub и Hugging Face.
Контекст и критика SWE-bench
Примерно два года назад исследовательская группа создала SWE-bench — бенчмарк, проверяющий способность ИИ-агентов работать с реальными отчётами об ошибках с GitHub. С тех пор появилось целое семейство вариантов — с разными языками, более чистыми данными и сложными профессиональными задачами. Однако в последнее время стандартный показатель успешности подвергается давлению с разных сторон. Исследование организации METR показало, что менеджеры проектов отвергли бы примерно половину решений, которые прошли автоматическую проверку, причём многие из-за базовых функциональных ошибок.