Бенчмарк · agentic
Multi-SWE-bench
Multi-SWE-bench проверяет, способен ли ИИ-агент по написанию кода решать реальные задачи (issues) с GitHub во множестве репозиториев и языков программирования, а не только на Python. Главная метрика — resolution rate: доля тестовых экземпляров, чьё исправление проходит скрытый набор тестов.
Подробнее
- Пример
- Типичная задача: по реальному баг-репорту или запросу функции из open-source проекта на языке вроде Java, Go, Rust, TypeScript, JavaScript, C или C++, вместе с репозиторием, выгруженным на коммите до исправления, агент должен сгенерировать патч, решающий описанную проблему.
- Метрика
- Каждый экземпляр оценивается по принципу pass/fail через выполнение. Патч агента применяется к репозиторию, и запускаются тесты проекта; экземпляр считается решённым, только если указанные тесты FAIL_TO_PASS теперь проходят, а все тесты PASS_TO_PASS по-прежнему проходят. Итоговый показатель — resolution rate (решённые экземпляры ÷ общее число), обычно при pass@1; его можно разбивать по языкам и по размеченной экспертами сложности (easy/medium/hard).
- Приёмка
- Приём результата полностью основан на выполнении внутри отдельного Docker-образа для каждого экземпляра, воспроизводящего точный инструментарий языка и зависимости. Сгенерированный патч должен чисто применяться, после чего запускаются тесты fail-to-pass и pass-to-pass; не используется ни оценка с помощью LLM, ни текстовое сравнение с эталонным патчем разработчика.
- Почему важно
- SWE-bench оказался влиятельным, но охватывает только Python, тогда как реальная разработка ПО ведётся на множестве языков. Multi-SWE-bench проверяет, обобщают ли кодовые агенты навыки между языками на подлинных задачах, с экспертной разметкой сложности, давая более трудный, реалистичный и менее «насыщенный» сигнал практических инженерных способностей.
Разбор примера
Задача
Иллюстративный экземпляр в формате Multi-SWE-bench — язык: Go, небольшая библиотека обобщённых коллекций. problem_statement: «Stack.Pop() на пустом стеке возвращает нулевое значение и nil-ошибку, молча скрывая ошибки у вызывающего кода; вместо этого он должен возвращать признак ErrEmpty». Вам даётся репозиторий на базовом коммите с багом и падающий тест. FAIL_TO_PASS: TestPopEmptyReturnsError. PASS_TO_PASS: TestPushThenPop, TestLen. Отправьте патч, который заставит падающий тест проходить, не ломая проходящие тесты.
Решение
--- a/stack.go
+++ b/stack.go
@@ func (s *Stack[T]) Pop() (T, error) {
+ if len(s.items) == 0 {
+ var zero T
+ return zero, ErrEmpty
+ }
n := len(s.items)
v := s.items[n-1]
s.items = s.items[:n-1]
return v, nil
}Разбор
Исправление добавляет в Pop проверку на пустоту, которая возвращает признак ErrEmpty (вместе с нулевым значением типа) ровно так, как ожидает TestPopEmptyReturnsError, оставляя обычный путь извлечения без изменений, чтобы TestPushThenPop и TestLen продолжали проходить. Оценка чисто исполнительная: харнесс применяет патч в Docker-образе экземпляра и помечает экземпляр решённым, только если тест FAIL_TO_PASS начинает проходить и ни один тест PASS_TO_PASS не регрессирует.
По этому бенчмарку пока нет проверенных результатов.