Реальная задача требует ориентирования в репозитории
SWE-bench появился как проверка на реальных задачах GitHub: требуется разобраться в проекте, найти место ошибки и подготовить исправление, которое проходит тесты. Это отличается от замкнутой алгоритмической задачи, где нужная функция уже дана. Ведущий напоминает, что модели начала этой истории решали лишь небольшую долю задач. Авторы бенчмарка стали искать способ улучшить работу модели с компьютером. Инженеру помогают редактор, поиск, навигация и подсветка. У текстового агента другое рабочее место: он получает текстовые ответы инструментов, расходует токены на их чтение и не может пользоваться графическим интерфейсом так, как человек. Отсюда идея ACI — интерфейса между агентом и компьютером. Его задача состоит в том, чтобы сделать полезное действие простым, а результат действия понятным для следующего шага. Удобство здесь проверяется через способность довести изменение до работающего патча. Оценивается вся цепочка работы с проектом: от исходного описания проблемы до отправки результата.
SWE-agent действует в цикле «мысль — действие — наблюдение». Модель формулирует следующий шаг, отправляет команду и читает ответ среды. В обсуждаемой системе формат ограничен одной мыслью и одним действием; неправильный ответ вызывает сообщение об ошибке. Исполнение происходит в подготовленном окружении, где доступны обычный shell и специальные команды. Даже отсутствие вывода обозначается явно, чтобы агент понимал, что произошло. После отправки патча решение проверяют тестами. Основная оценка — доля задач, решённых за одну попытку, с ограниченным денежным бюджетом. Полный SWE-bench содержит 2294 задачи, а эксперименты с отдельными компонентами используют Lite из 300 задач. Ведущий сравнивает подход с поиском BM25 и немедленной генерацией патча, а также с агентом, которому доступен только shell. Результаты GPT-4 Turbo и Claude 3 Opus различаются: полезность конкретного интерфейса зависит от модели. Сравнивать конфигурации нужно при одинаковых условиях, сохраняя различие между полным набором, Lite и вариантами с демонстрацией решения.
Действие должно возвращать ориентиры для следующего шага
Первый практический вопрос — где менять код. Цепочки стандартных команд требуют точных параметров, иногда арифметики для выбора строк, а их вывод легко заполняет контекст ненужными подробностями. В SWE-agent поиск разделён по масштабу: найти файл, найти совпадения в директории, найти нужное внутри файла. Так агент постепенно сужает область работы. Когда файл открыт, интерфейс показывает его имя, номера строк, выбранный фрагмент и сведения об оставшейся части. Можно перемещаться к конкретной строке и просматривать соседние участки. Это сохраняет положение в файле без самостоятельного пересчёта. Команда edit заменяет заданный диапазон строк и сразу возвращает обновлённое окно. Агенту не приходится отдельно читать файл, чтобы узнать, применилась ли правка. Ведущий подчёркивает, что одна такая команда заменяет несколько мелких операций. При этом размер окна — параметр эксперимента: избыток текста мешает так же, как недостаток нужного контекста. Номера строк полезны именно как устойчивые ориентиры для дальнейшего действия.
Следующий слой — проверка синтаксиса после изменения. Если линтер находит проблему, правка отклоняется. Ответ содержит ошибку, предложенный вариант кода и исходный фрагмент. Каждая часть помогает восстановиться: описание даёт диагноз, неудачная правка показывает, что повторять бессмысленно, а исходный код избавляет от нового поиска. В абляциях на SWE-bench Lite конфигурация без команды edit решала 10,3 % задач, с edit без линтера — 15 %, с редактированием и линтером — 18 %. Эти числа принадлежат конкретному эксперименту. Проверка также ограничивает порядок работы: промежуточное состояние, нужное для большого изменения, может быть отвергнуто раньше завершения правки. Ведущий обсуждает этот компромисс на примере последовательного изменения определения и мест использования. Защитный механизм меняет доступные агенту траектории. Поэтому полезность ограничения нельзя выводить только из его названия; нужно смотреть, какие ошибки оно предотвращает и какую нужную работу затрудняет.
Измерения важнее привязанности к конструкции агента
Контекст растёт после каждого шага и хранит старые версии файлов. Авторы оставляли последние пять наблюдений полностью, а более ранние заменяли указанием на пропущенный вывод, сохраняя мысли и команды. Это сокращало объём и количество устаревших сведений. Окно в сто строк и такая глубина истории оказались полезны в их конфигурации; ведущий предостерегает от переноса этих чисел как универсального рецепта. Далее разбираются успешные последовательности: создать скрипт, внести код для воспроизведения проблемы, выполнить его; найти директорию, затем файл и нужное место. Успешные решения часто приходили быстро, затруднения занимали больше ходов. Однако длина траектории может отражать трудность задачи, поэтому корреляция не даёт готового правила остановки. Несколько независимых запусков увеличивали число решённых задач, но это отдельные попытки, а не простое продолжение застрявшего разговора. Ошибочная реализация, слишком частное исправление и незавершённая работа показывают предел, который одним удобством инструментов не снять.
Важная часть истории — способ разработки самого интерфейса. Авторы запускали задачи, читали траектории, формулировали гипотезу, меняли конфигурацию и повторяли измерение. Так можно проверить размер окна, обработку истории или отдельный инструмент. Финальные принципы понятны: простые и компактные действия, короткая полезная обратная связь, ограничения, которые помогают исправляться. Но их реализация меняется. В эпилоге ведущий связывает SWE-agent с SWE-smith, где создают проверяемые задачи для обучения, и mini-SWE-agent, где модель снова работает через bash и историю сообщений. Более сильные модели изменили ценность прежнего специального интерфейса. Менялся и сам экзамен: обсуждаются SWE-bench Verified и последующий аудит. Поэтому инженерный вывод состоит в регулярной перепроверке всей связки. Нужно измерять вклад каждого компонента на важных для команды задачах и быть готовым убрать вчерашнее улучшение, если новая модель делает его избыточным. Исторические проценты помогают понять ход эксперимента, но не обещают результата текущей системе.
Что стоит унести с собой
- 01Интерфейс агента включает действия и ответы среды. Поиск, номера строк и обновлённый фрагмент после правки уменьшают число промежуточных операций при работе с чужим проектом.
- 02Отклонение ошибочной правки полезно вместе с объяснением ошибки и показом обоих вариантов кода. Ограничение одновременно влияет на допустимый порядок изменений.
- 03Абляции показывают вклад конкретного компонента при заданных условиях. Нельзя смешивать результаты полного SWE-bench и Lite, одной попытки и нескольких независимых запусков.
- 04По мере улучшения моделей специальный интерфейс может стать избыточным. Переносить стоит метод измерения действий, обратной связи и ограничений, регулярно пересматривая выбранные инструменты.
Источники
- Расшифровка аудиозаписи
- Слайды выпуска
- Запись выпуска