SWE-bench: учусь запускаться локально на swe задачах

TL;DR: SWE-bench (Software Engineering) бенчмарк для оценки AI-агентов на реальных GitHub issues
Тестирую qwen2.5-32b-coder-instruct на 2x RTX 4090 (48GB), получил 5.3% zero-shot
Планирую адаптировать open-source лидеров под локальные модели через vLLM + SO

Что такое SWE-bench его кстати придумала команда из Princeton University и Stanford University
Работа была принята на ICLR 2024

SWE-bench это benchmark для оценки больших языковых моделей на реальных software issues, собранных из GitHub
Получив кодовую базу и issue, языковая модель должна сгенерировать патч, который решает описанную проблему

В отличие от бенчмарков, фокусирующихся на скорости, SWE-bench оценивает инженерные
навыки: понимание существующего кода, генерацию нового кода, отладку, исправление багов и рефакторинг

Варианты: Full (2,294 задач), Lite (300 задач), Verified (500 задач)

Мои эксперименты: 2x RTX 4090 (48GB) + я взял сервер на 32CPU (под eval)

Развернул qwen2.5-32b-coder-instruct через vLLM

Запуск включает в себя 3 этапа:

1) Подготовка: Создание датасета с Style-3 промптами (19K символов контекста: issue + полный код + примеры патчей)
2) Inference: Модель получает промпт и генерирует diff-патч для решения GitHub issue
3) Evaluation: Патч применяется к репозиторию в Docker контейнере, запускаются тесты (FAIL_TO_PASS + PASS_TO_PASS)

Ключевые поля датасета:

instance_id - уникальный ID (astropy__astropy-12907)
text - полный промпт для модели (19K символов)
problem_statement - описание GitHub issue (1.2K символов)
patch - правильное решение (500 символов)
FAIL_TO_PASS - тесты, которые должны заработать
PASS_TO_PASS - тесты, которые должны остаться рабочими

Структура промпта (19K символов):

Введение (100 символов) - инструкция для модели
<issue> (1.2K символов) - описание проблемы + примеры
<code> (16K символов) - полный контекст кода + документация
<patch> (1.2K символов) - пример формата решения

Результаты zero-shot на SWE-bench Lite:
Решено: 16/300 (5.3%)
Применимых патчей: 119/300 (39.7%)
Производительность: 79-383 tokens/s prompt, 46-64 tokens/s generation

Проблема на первый взгляд: стандартный few-shot не выдерживает формат diff - модель генерирует
правильную логику, но ломается на синтаксисе unified diff format
Именно поэтому лидеры используют structured output

Еще уперся в рейт лимиты Docker Hub api при сборке но исправление проблемы показало +1 процент точности

Так же c командой прокопали open-source лидеров
На сегодня вот такой вот лидерборд на lite

1. ExpeRepair-v1.0 + Claude 4 Sonnet — 60.33%
4 агента: Search, Reproducer, Write Patch, Reviewer
Structured Output архитектура (промптинг+shema repair)

2. Refact.ai Agent — 60.00%
Claude 3.7 Sonnet + o4-mini для deep_analysis()
Дела вывод что planning-модуль критичен без него агент работает реактивно (увидел → патчит),
с ним: анализ → стратегия → план → исполнение
Разница между 5% и 60% именно в этом

3. SWE-agent + Claude 4 Sonnet 56.67%

Новая версия с Claude 4 Sonnet
ReAct архитектура с улучшенным scaffolding

4. ExpeRepair-v1.0 — 48.33%
Базовая версия без Claude 4 Sonnet
Все тот же structured output подход(промптинг)

Чем круче подобран набор tool + архитектура > размер модели

Хочу попробовать в течении месяца по вечерам собрать такого франкенштейна
vLLM + Structured Output (замена function calling)
Локальный planning-модуль (курсор мне в помощь) (аналог deep_analysis)
Multi-agent архитектура еще не выбрал что буду брать (есть советы?)
Эффективное использование 120k context (скорее всего буду батчи упаковывать для паралельного запуска tool

P.S. Кто еще тестирует open-source агентов на SWE-bench? Делитесь результатами!