ИИ чинит код лучше, если сначала задаёт вопросы

Прежде чем чинить код, неплохо бы его понять

У ИИ-агентов для программирования есть старая и очень человеческая проблема: они часто начинают чинить слишком рано. Видят описание ошибки, хватаются за знакомые слова, бегут по репозиторию и быстро вносят правку — но не туда и не о том. В итоге тесты падают, шаги множатся, токены сгорают, а агент ходит кругами.

Авторы работы Know Before Fix предлагают простую, но сильную идею: перед тем как писать патч, агент должен сначала задать правильные вопросы о кодовой базе и получить на них ответы, опираясь на реальные файлы репозитория. Не “как бы я это починил”, а “чего мне не хватает, чтобы вообще понять, что происходит”.

Из этого выросла система ACQUIRE — двухэтапный конвейер для решения задач из SWE-bench Verified. Идея оказалась не просто красивой. На практике она поднимает качество исправлений и делает это без безумного роста цены и времени.

В чём здесь главная мысль

Большие модели уже умеют неплохо рассуждать о коде. Но когда дело доходит до реальных репозиториев, проблема часто не в логике как таковой, а в нехватке фактов. Описание задачи редко содержит всё важное: где реально живёт нужная логика, какие есть скрытые зависимости между модулями, какие ограничения диктует внутренний API, какие допущения заложены в коде.

Многие существующие методы пытаются это лечить через предварительный обход репозитория. Но обычно они всё равно “заточены под исправление”: найти подозрительные файлы, собрать сводку, подсветить релевантные места. Это полезно, но не отвечает на ключевой вопрос: что именно агент не понимает?

ACQUIRE разворачивает процесс в сторону, более похожую на работу сильного разработчика. Сначала — понимание. Потом — правка.

Схема ACQUIRE: сначала агент формулирует вопросы и получает ответы по репозиторию, потом отдельный агент строит патч.

Система делит работу на два этапа:

Это важное разделение. Оно не даёт агенту смешивать догадки о причине ошибки с ранним редактированием кода.

Как устроен ACQUIRE

Внутри у ACQUIRE три роли.

Вопросы строятся не хаотично. Авторы выделили четыре типа пробелов в знаниях, которые чаще всего мешают починке:

Это, по сути, шаблон для любопытства. Агент не просто ищет “подозрительный файл”, а задаёт вопросы в духе: как здесь вообще устроен этот механизм? где реализована нужная часть? какой контракт нельзя нарушать?

Есть ещё один важный момент. Для каждого вопроса создаётся отдельный экземпляр отвечающего агента, и они работают параллельно. Это снижает задержку и не даёт одному поисковому следу заразить другой. Один агент ищет одно, другой — другое.

По умолчанию система задаёт два вопроса на задачу. Как выяснилось позже, это почти оптимальная точка.

Почему это вообще должно работать

Авторы сначала устроили почти “магический” эксперимент. Они взяли 116 задач, которые базовый агент не смог решить, и подбросили ему идеальную пару вопрос–ответ: вопрос был составлен с учётом эталонного патча, а ответ строился по файлам из правильного исправления.

Результат: 26 из 116 ранее проваленных задач удалось спасти.

Это не финальная система, а скорее доказательство идеи. Но оно хорошо показывает суть: если дать агенту правильное знание до начала исправления, часто оказывается, что думать он умеет — ему просто не хватало опоры в самом репозитории.

Дальше авторы убрали эту “магию” и автоматизировали процесс: вопросы начал генерировать сам агент, а ответы — добываться реальным поиском по коду.

Что получилось на SWE-bench Verified

Главный эксперимент шёл на SWE-bench Verified — это 500 реальных задач из GitHub, где исправление проверяется тестами.

По сравнению с базовым Mini-SWE-Agent, ACQUIRE даёт:

И это лучший на данный момент результат среди сравниваемых методов предварительного анализа.

Качество и средняя стоимость при разном числе пар вопрос–ответ: лучший баланс достигается на двух вопросах.

Особенно интересно здесь не только качество, но и цена улучшения. Некоторые конкуренты тоже помогают, но делают это дорого: больше обходов, больше шагов, больше времени. ACQUIRE добавляет умеренные накладные расходы. Например, с DeepSeek-V3.2 средняя стоимость растёт с 0,055 до 0,073 доллара на задачу, а время — с 815 до 1042 секунд. Рост заметный, но не драматичный.

На фоне методов, которые в 2–14 раз дороже, это выглядит очень разумным компромиссом.

Почему так? Потому что ACQUIRE не пытается вычитать весь репозиторий. Он собирает узкие, осмысленные знания, которые действительно помогают принять решение.

Не просто точнее, но и короче

Одна из самых сильных частей статьи — разбор того, как именно меняется поведение агента.

Когда в систему добавляют блок вопрос–ответ, агент делает меньше бесполезных кругов. На всём наборе задач число раундов снижается в среднем на 7,1%. А на тех 44 случаях, где был переход из “не решил” в “решил”, сокращение уже 17,1%.

Состав шагов траектории на задачах, где ACQUIRE перевёл решение из провала в успех: меньше времени уходит на поиск и правку вслепую.

Авторы разбили траекторию работы на четыре стадии: воспроизведение, поиск нужного места, исправление, проверка. И увидели очень показательный сдвиг:

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

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

Насколько этим ответам можно верить

У такого подхода есть очевидный риск: а вдруг агент сам себе напридумывает неверные “факты”, а потом другой агент на них опрётся?

Авторы это отдельно проверили вручную. Они просмотрели 232 пары вопрос–ответ. Итог очень сильный: 99,1% ответов признаны поддержанными репозиторием. Из них:

Это важный результат. Он показывает, что разбиение задачи на маленькие, конкретные вопросы действительно уменьшает склонность модели фантазировать. Ответить на узкий вопрос по коду проще, чем сразу “понять и починить всё”.

Но есть нюанс. Даже фактически верный ответ может сместить фокус не туда. Авторы нашли 22 случая, где базовый агент решал задачу, а ACQUIRE — уже нет. При ручном разборе выяснилось, что только 5 таких регрессий были связаны с реально сбивающим знанием. Остальные происходили потому, что решающий агент неправильно использовал в целом полезную подсказку: слишком широко обобщал, чинил только часть проблемы или добавлял лишние изменения.

Вывод простой: узкое место здесь уже не столько в качестве собранных знаний, сколько в том, как агент умеет с ними спорить и перепроверять их.

Почему два вопроса лучше, чем один или три

Авторы отдельно проверили, сколько вообще нужно пар вопрос–ответ.

Результат оказался очень жизненным:

То есть больше контекста — не всегда лучше. После двух вопросов начинает работать знакомая проблема длинного контекста: часть информации дублируется, внимание рассеивается, и агенту сложнее выделить главное.

Это одна из самых практичных находок статьи. Не надо заваливать модель всеми возможными справками. Лучше дать две хорошие подсказки, чем пять средних.

Самый показательный пример

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

Разбор примера со Sphinx: ACQUIRE находит корневую причину через вопрос о механизме разбора, а не по совпадению ключевых слов.

ACQUIRE пошёл иначе. Спрашивающий сформулировал вопрос не про “где ломается рендеринг”, а про механизм разбора типа параметра. Это сместило поиск в сторону причин, а не симптомов. Отвечающий агент в итоге нашёл файл `docfields.py`, где `split` неверно обрабатывал пробелы внутри скобок типа.

Дальше решающий агент сразу открыл правильный файл, внёс точечную правку и закрыл задачу за 52 шага вместо 117.

Очень показательно: проблема была не в том, что агент не умеет написать нужный код. Он просто изначально смотрел не туда.

Что это значит для ИИ-агентов для программирования

Эта работа важна не только как ещё один плюсик на SWE-bench. Она бьёт в одно из самых слабых мест нынешних ИИ-агентов: они плохо отличают нехватку знаний от ошибки в рассуждении.

Если агент не понимает репозиторий, он обычно не говорит “мне не хватает фактов”. Он начинает импровизировать. ACQUIRE вводит полезную дисциплину: сначала сформулируй пробелы в знаниях, потом закрой их, и только затем редактируй код.

Для отрасли это важный сдвиг:

И это особенно ценно на реальных кодовых базах, где ошибки часто сидят не в одном файле и не лежат на поверхности.

Выводы

ACQUIRE показывает простую вещь: для хорошего исправления кода мало уметь генерировать патч. Нужно ещё уметь понять, чего ты не знаешь о репозитории, и быстро добыть именно это знание.

Подход с вопросами и ответами дал стабильный прирост на двух разных моделях, сократил число лишних шагов и оказался заметно дешевле тяжёлых схем с глубоким предварительным обходом. Самое важное — он меняет сам стиль работы агента: меньше суеты, больше понимания.

Главный урок отсюда звучит почти по-человечески. Хороший ИИ-агент для программирования должен не только чинить. Он должен сначала задавать правильные вопросы.