SWE-bench: Могут ли языковые модели решать реальные проблемы на GitHub?

Статья CodeAct привела убедительные аргументы в пользу использования Python как оптимального формата действий для LLM-агентов. Но выбор правильного формата — это лишь половина дела: нужно также продемонстрировать, что агенты способны справляться со сложностью реальных задач, а не только с подготовленными бенчмарками. SWE-bench (arXiv:2310.06770), опубликованный Карлосом Хименесом, Джоном Янгом, Александром Веттигом, Шунью Яо, Кесином Пеем, Офиром Прессом и Картиком Нарасимханом из Принстона и представленный на ICLR 2024, — это работа, которая заставила отрасль напрямую столкнуться с этим разрывом.

О статье

«SWE-bench: Can Language Models Resolve Real-World GitHub Issues?» создает бенчмарк из 2 294 экземпляров задач, взятых из реальных объединенных пулл-реквестов в 12 популярных репозиториях Python: astropy, django, flask, matplotlib, pylint, pytest, requests, scikit-learn, seaborn, sphinx, sympy и xarray. Каждый экземпляр предоставляет модели снимок кодовой базы и описание проблемы на GitHub; модель должна создать патч, который заставит назначенный набор ранее не пройденных тестов выполниться успешно, не ломая при этом существующие тесты. Бенчмарк был построен путем анализа ~90 000 пулл-реквестов, отбора тех, которые одновременно решали связанную проблему и добавляли новые тесты, с последующей проверкой переходов прохождения/провала на основе выполнения. Такая строгая конструкция позволяет избежать типичной проблемы бенчмарков — неоднозначной или легко манипулируемой эталонной истины.

Ключевые идеи

• Claude 2, модель с лучшими показателями на момент публикации, решает только 1,96% проблем при использовании разреженного поиска BM25 — в реалистичном сценарии развертывания, где модель должна самостоятельно находить релевантные файлы.
• При «поиске с оракулом» (oracle retrieval) — когда модели предоставляются именно те файлы, которые ей нужны, — показатель Claude 2 улучшается до 4,80%, что подтверждает: узкое место отчасти заключается в поиске, но в основном — в редактировании: даже при идеальном контексте показатели успеха остаются ниже 5%.
• GPT-4 решает 0,00% проблем с поиском BM25 (оценивалось на подмножестве в 25% по бюджетным соображениям) и 1,74% с оракулом. Падение от оракула к BM25 для Claude 2 является критическим, а для GPT-4 — полным.
• Создаваемые патчи систематически слишком коротки: успешные патчи Claude 2 в среднем составляют 19,6 строк против 74,5 строк в эталонных человеческих патчах. Модели находят простые локальные исправления; люди пишут комплексные решения, затрагивающие несколько файлов.
• Избыток контекста активно вредит. BM25 при 50 тысячах токенов извлекает больше файлов оракула, чем при 13 тысячах, однако показатели решения часто снижаются. Эффект «потери в середине» (lost in the middle) — игнорирование моделями релевантных данных, зарытых в длинных контекстах, — здесь является реальным и задокументированным типом отказа.
• SWE-Llama 13b, дообученная на контекстах, полученных от оракула, достигает 4,00% с оракулом, но только 0,70% с BM25. Обучение на идеальном контексте создает хрупких агентов, которые терпят неудачу при реалистичном поиске.

Что подтвердилось, а что нет

Конструкция бенчмарка отличается строгостью. Оценка на основе выполнения — когда тесты действительно запускаются и либо проходят, либо нет — является правильной истиной для задач редактирования кода. Она объективна, автоматизируема и устойчива к манипуляциям. Решение требовать переходов от провала к успешному прохождению (а не просто успешного наложения патча) особенно важно: это предотвращает тривиально «правильные» патчи, такие как пустые операции (no-ops) или удаления.

Результаты подтвердились на удивление хорошо. SWE-bench был опубликован в октябре 2023 года и быстро стал оценкой де-факто для кодинг-агентов. Начальный базовый уровень в 1,96% действительно информативен, а не подтасован. SWE-agent, опубликованный в 2024 году смежной группой, поднял планку до 12,47% за счет изменения дизайна интерфейса взаимодействия агента с компьютером — улучшение в 6 раз, которое само по себе подтверждает, как много было упущено в первоначальном базовом варианте.

Две вещи, с которыми статья справляется не так хорошо: во-первых, бенчмарк ориентирован только на Python. Это практическая необходимость, но она создает риск переобучения под конвенции Python. Во-вторых, статья предлагает только базовые модели генерации с дополненным поиском и явно откладывает агентные подходы на будущее. Это было уместно в 2023 году, но означает, что сама статья не дает сигналов о том, какие архитектуры агентов помогают.

Настройка «оракул» также является более слабым верхним пределом, чем кажется. Предоставление контекста идеального файла не решает проблему локализации кода внутри этих файлов и не помогает в рассуждениях о взаимодействии модулей в нескольких файлах. Результат Claude 2 в 4,8% с оракулом означает, что даже при наличии нужных файлов в контексте модель ошибается в 95% случаев. Проблема заключается не в первую очередь в поиске.

Почему это важно для ИИ в финансах

Beancount — это Python-проект, размещенный на GitHub. Агент записи для Beancount — это, по сути, агент, которому необходимо выполнять задачи в стиле SWE-bench: на основе файла гроссбуха (ledger) и инструкции («добавь эту транзакцию», «исправь это расхождение баланса») создать правку, которая пройдет bean-check, не нарушая существующих утверждений (assertions).

Отказ поиска напрямую аналогичен проблеме локализации в гроссбухе. Когда пользователь говорит «исправь завышение расходов на офисные принадлежности в третьем квартале», агент должен сначала найти соответствующие записи в файле, который может содержать тысячи строк — та же задача локализации файлов, где BM25 терпит неудачу в 40–50% случаев SWE-bench. Деградация «потери в середине» в равной степени относится к длинным .beancount файлам, где более ранние записи с такой же вероятностью могут быть проигнорированы.

Асимметрия длины патча является практическим предупреждением. Модели вносят правки слишком узко. В бухгалтерском учете это выражается в исправлении одной записи при пропуске корреспондирующей (offsetting) записи или в обновлении статьи расходов при сохранении устаревшего текущего баланса. Рабочему агенту Beancount необходим слой валидации — bean-check, проверки баланса или явный этап сверки, который заставит агента увидеть полные последствия своей правки, а не только ее локальную правдоподобность.

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

Что почитать дальше

• SWE-agent (arXiv:2405.15793, NeurIPS 2024) — прямое продолжение; переход от 1,96% к 12,47% за счет пересмотра интерфейса «агент-компьютер». Принципы проектирования для навигации по файлам и поиска кода напрямую применимы к инструментарию агентов Beancount.
• Agentless: Demystifying LLM-based Software Engineering Agents (arXiv:2407.01489) — отбрасывает сложность агентов и показывает, что простой конвейер локализации и исправления без сложной надстройки может быть конкурентоспособным; полезный противовес подходам с тяжелыми интерфейсами.
• MemGPT: Towards LLMs as Operating Systems (arXiv:2310.08560) — решает проблему длинного контекста «в лоб» с помощью многоуровневого управления памятью; напрямую актуально для агентов, которые должны анализировать многолетние гроссбухи Beancount.