В статье представлено многоязычное расширение SWE-Bench от команды Doubletapp — бенчмарка для оценки больших языковых моделей (LLM) на реальных задачах программной инженерии, на различных языках программирования и кодовых базах индустрии. О процессе сбора SWE-Bench мы уже рассказывали в отдельной статье, а здесь сосредоточимся на результатах тестирования. Мы оцениваем ряд ведущих открытых LLM, предоставляя подробный количественный и качественный анализ, а также рассматриваем, как качество бенчмарка влияет на достоверность и объективность оценки моделей.
Многие публичные датасеты были включены в обучающие данные современных моделей, что привело к загрязнению и искусственному завышению их производительности. Поэтому мы представляем новое, независимо составленное многоязычное приватное расширение SWE-Bench, построенное на основе разнообразных открытых репозиториев. Для валидации данных привлекались команды AI-тренеров, что обеспечивает сложность воспроизведения результатов. Этот подход дает прозрачную, независимую и объективную оценку LLM на более широком спектре языков программирования и реальных задач в домене Software Engineering.
SWE-Bench Multilingual: описание набора данных
Наш набор данных расширяет существующий датасет SWE-Bench-Verified несколькими ключевыми улучшениями
Полноценная поддержка нескольких языков
C++, C#, Go, JavaScript, Kotlin, PHP, Ruby, Rust и другие. Это обеспечивает всестороннюю оценку LLM по различным языковым парадигмам, синтаксическим особенностям и специфичным для языка регламентам.Строгая гарантия качества
Для балансировки масштабируемости с точностью мы используем гибридную систему валидации и разметки, которая сочетает автоматический статический анализ и ручную регламентированную проверку экспертами-аннотаторами. Эта двухуровневая валидация гарантирует, что формулировки задач и их решения соответствуют строгим стандартам согласованности при минимизации шума меток.Отбор задач уровня индустрии
Все задачи взяты из активно поддерживаемых общественно значимых открытых репозиториев (например, kubernetes, llvm-project), уровень сложности которых соответствует реальным вызовам инженерной разработки. Каждый экземпляр бенчмарка представляет собой обособленную задачу enterprise-разработчика — исправление ошибок, доработку API или оптимизацию производительности. Такой подход обеспечивает реалистичность условий для оценки моделей, максимально приближенных к реальной production-среде.
Общая статистика об исходных данных
Language | Task count | Avg.lines changed | Median lines changed |
ALL | 506 | 9.7 | 5.0 |
GO | 137 | 7.1 | 4.0 |
JS | 120 | 14.8 | 9.5 |
Rust | 103 | 11.1 | 7.0 |
PHP | 53 | 8.2 | 4.0 |
Ruby | 53 | 0.8 | 0.0 |
Kotlin | 34 | 14.9 | 13.5 |
CPP | 3 | 5.0 | 2.0 |
CSHARP | 3 | 8.7 | 4.0 |
Расширенный анализ (см. Приложение А) демонстрирует распределение объема изменений для решения задач и распределение репозиториев.
Конфигурация для оценки
Выбор модели
В исследовании были оценены несколько востребованных языковых моделей — как открытых, так и проприетарных, обладающих функционалом мышления (reasoning) и имеющих навыки в домене Coding, Computer Science:
• google/gemini-2.5-pro-preview
• anthropic/claude-3.7-sonnet
• meta-llama/llama-4-maverick
• deepseek/deepseek-r1
• deepseek/deepseek-chat (deepseek v3)
• qwen/qwen-2.5-72b-instruct
Все модели были интегрированы и оркестрованы с использованием фреймворка-агента MOpenHands. MOpenHands отвечал за полное управление и взаимодействие с моделью, включая форматирование промптов, вызов модели и постобработку ответов.
Генерация и оценка patch-файлов
Генерация patch-файлов
Для каждой задачи из набора тестов были сгенерированы решения (патчи) путём подачи запросов (промптов) к моделям через агента MOpenHands.
Агент обеспечивал унифицированную структуру запросов, согласованность параметров декодирования запросов и воспроизводимые условия генерации ответов для всех моделей.
Оценка patch-файлов
Решения (патчи), сгенерированные моделями, оценивались с использованием фреймворка multi-swe-bench. Этот фреймворк автоматизировал применение каждого патча к соответствующей кодовой базе, выполнял сборку проекта и запуск тестов, а также генерировал подробные логи для каждого раунда оценки.
Основная функция фреймворка multi-swe-bench в этой настройке заключалась в предоставлении стандартизированной и воспроизводимой среды для применения патчей и выполнения тестов для всех моделей. Фреймворк сам не вычислял агрегированные метрики, вместо этого он выводил статусы выполнения тестов и логи исполнения решения для каждой задачи.
После получения результатов тестирования мы провели анализ и рассчитали метрики, обеспечив консистентность и полную прозрачность в расчёте и отчётности ключевых показателей, таких как pass@k, precision и F1-оценка.
Метрики оценки
pass@k (k=1, 3)
Метрика pass@k измеряет долю задач, для которых хотя бы одно правильное решение присутствует среди k результатов модели. Для каждой задачи мы генерируем k независимых выводов модели с помощью агента MOpenHands и оцениваем их с использованием фреймворка multi-swe-bench, который применяет каждый патч к кодовой базе, запускает тесты и сообщает результаты тестирования.
• pass@1 оценивает процент успешных предсказаний, когда учитывается только первое (top-1) предсказание, что отражает детерминированную эффективность модели.
• pass@3 оценивает вероятность того, что хотя бы одно из трех первых предсказаний будет правильным. Эта метрика полезна для сценариев, где возможно несколько допустимых решений, и модель может предложить несколько корректных из топ-k ответов.
Precision и F1-оценка (F1 Score)
Мы вычисляем precision и F1 Score на уровне патчей и тестирования, оценивая, насколько точно модификации кода, сгенерированные моделью, соответствуют истинным патчам. Эти метрики выводятся из логов выполнения, генерируемых фреймворком multi-swe-bench, который предоставляет сырые результаты после применения сгенерированных патчей.
• Precision определяется как доля правильно сгенерированных изменений среди всех изменений, предложенных моделью.
• F1 Score рассчитывается как гармоническое среднее между precision и pass@1, обеспечивая сбалансированную оценку производительности модели.
Инфраструктура & гиперпараметры
Все выводы модели выполнялись с помощью агентного фреймворка MOpenHands, который был расширен для взаимодействия с платформой OpenRouter. Такая интеграция обеспечивает согласованные аппаратные ресурсы, стандартизированные среды выполнения и высокую производительность оценки для всех экспериментов. Ниже мы подробно описываем соответствующие аспекты инфраструктуры, зависимостей и автоматизации оценки для обеспечения полной воспроизводимости.
Облачная и аппаратная среда
API/Hosting провайдер
Для обращения к моделям использовался сервис OpenRouter (https://openrouter.ai), который предоставляет унифицированный доступ к широкому разнообразию open-source и проприетарных LLM-моделей, развернутых на инфраструктуре провайдеров.
Вычислительные ресурсы
Все обращения к моделям выполнялись с использованием инфраструктуры провайдера OpenRouter. Конкретные аппаратные конфигурации, такие как GPU (например, NVIDIA A100/RTX 4090), абстрагированы и управляются провайдером, что обеспечивает масштабируемость и согласованность экспериментов.
Batching и распараллеливание
Запросы выполнялись с помощью распараллеливания на уровне задач во фреймворке MOpenHands, который диспетчеризировал отдельные задачи выводов параллельно. Такая настройка позволила максимизировать пропускную способность и минимизировать задержку за счет использования стандартного ThreadPoolExecutor в Python для параллельного исполнения. Пакетный вывод был отключен, чтобы избежать артефактов, связанных с пакетной обработкой, и обеспечить независимую обработку каждого модельного запроса.
Программная среда
Контейнеризация: все скрипты и инструменты запускались в Docker-контейнерах, которые мы модифицировали в рамках фреймворка multi-swe-bench для обеспечения воспроизводимой и изолированной среды во всех экспериментах.
OS: Ubuntu 22.04 LTS (контейнеризованная)
Основной язык инструментов: Python 3.11.8
Ключевые фреймворки:
MOpenHands облегчает взаимодействие с моделями, формирование, управление задач и интеграцию с GitHub для беспрепятственного решения задач и создания патчей тестируемыми моделями.
multi-swe-bench используется для оценки решений моделей, включая применение решений (патчей), выполнение сборок/тестов и регистрацию результатов.
OpenRouter обеспечивает доступ к широкому выбору моделей, позволяя делать последовательные и стандартизированные выводы по результатам экспериментов.
Никакой тонкой настройки или обучения модели не проводилось — только вывод по опубликованным и предоставленным контрольным версиям моделей на OpenRouter.
Гиперпараметры запросов к моделям
Все модельные выводы выполнялись с использованием стандартных настроек конфигурации, предоставляемых MopenHands и OpenRouter. Эти настройки включают параметры декодирования по умолчанию и унифицированные шаблоны промптов для каждого типа задач.
Автоматизация
Оркестрация оценки
Все скрипты и инструменты выполнялись внутри Docker-контейнеров. Мы расширили функциональность фреймворка multi-swe-bench, чтобы гарантировать изолированность и воспроизводимость среды при проведении экспериментов.
Параллельная обработка задач
Параллельная обработка выполнялась в MOpenHands с помощью ThreadPoolExecutor из Python. Количество потоков динамически регулировалось с учётом доступных API-токенов и ограничений OpenRouter.
Random Seed
Во время работы модели явное значение random seed не задавалось, использовались стандартные настройки OpenRouter API и MOpenHands. Поскольку все вычисления выполнялись через внешние API, результаты могут незначительно варьироваться из-за стохастических параметров генерации (например, top-k, top-p, temperature > 0).
Логирование:
Мы записывали и версионировали все операции, включая:
Каждый API-вызов с параметрами модели
Полные данные запросов и ответов
Временные метки
Сгенерированные результаты
Это обеспечивает полную отслеживаемость всех процессов.
Примечание:
Все работы по промпт-инжинирингу, усечению контекста и форматированию входных данных основывались на оригинальных промптах из MopenHands, что обеспечило согласованность и позволило достичь воспроизводимости результатов для будущих исследований.
Результаты
Модель | Precision (%) | pass@1 (%) | pass@3 (%) | F1 (%) |
anthropic/claude-3.7-sonnet | 16.54 | 5.63 | 14.47 | 8.4 |
google/gemini-2.5-pro-preview | 14.08 | 4.78 | 11.27 | 7.13 |
deepseek/deepseek-r1 | 7.24 | 2.46 | 6.03 | 3.67 |
deepseek/deepseek-chat (deepseek v3) | 7.58 | 3.04 | 7.22 | 4.33 |
meta-llama/llama-4-maverick | 6.09 | 1.31 | 5.39 | 2.15 |
qwen/qwen-2.5-72b-instruct | 1.26 | 0.47 | 1.09 | 0.68 |
Сильные и слабые стороны полученных метрик
Сильные стороны:
Precision: указывает на точность предложенных решений. Модели с высоким precision (например, anthropic/claude-3.7-sonnet) показывают, что их решения часто корректны, даже если они не всегда находятся в топе.
Pass@1: отражает способность модели генерировать правильное решение в качестве первого предсказания. Высокие значения указывают на модель, которая может точно решать задачи с первого раза.
Pass@3: оценка того, насколько часто хотя бы одно из трёх предложенных решений правильное. Это полезно для задач с несколькими возможными решениями.
Слабые стороны:
Низкие значения Pass@1 и F1: большинство моделей не справляются с точной генерацией правильных решений с первого раза. Это делает их менее подходящими для задач с высокими требованиями к точности с первого шага.
Нестабильность результатов: отдельные модели (qwen/qwen-2.5-72b-instruct) продемонстрировали низкие показатели по всем метрикам.
Вероятные причины — меньший размер модели и облегчённая архитектура. Эти особенности, видимо, снижают их эффективность при решении сложных задач бенчмарка.
Общие выводы: Несмотря на хорошую precision, проблемы с pass@1 и F1 свидетельствуют о трудности в генерации точных решений с первого предсказания, что является ключевым для задач с высоким риском ошибок.
Модели демонстрируют трудности в генерации правильных решений с первой попытки, даже несмотря на возможность создания нескольких вариантов ответа. Это подтверждает высокую сложность данного типа бенчмарков для тестируемых моделей.
Что влияет на качество данных
Качество набора данных для оценки играет ключевую роль в достоверности и интерпретируемости результатов оценки моделей, особенно в контексте больших языковых моделей для генерации кода и автоматизированной разработки программного обеспечения. Мы обнаружили, что несколько конкретных аспектов качества данных оказывают существенное влияние как на общие оценки, так и на наблюдаемое ранжирование моделей.
Подробнее
Тщательный отбор: каждая задача в многоязычном SWE-Bench была отобрана и проверена вручную, чтобы убедиться, что она представляет собой реалистичный, однозначный и нетривиальный сценарий программной инженерии. В отличие от некоторых публичных бенчмарков, где преобладают автоматически сгенерированные или слабо контролируемые примеры, в нашем наборе данных приоритет отдается человеческому контролю на каждом этапе — от выбора задачи до проверки решения. Такой ручной контроль существенно снижает распространенность неправильно обозначенных, недостаточно определенных или нерелевантных задач, которые в противном случае могут искусственно завышать оценки моделей.
Распределение стека языков: производительность моделей на разных языках программирования часто существенно различается, особенно когда модели предварительно обучаются или настраиваются преимущественно на одном или нескольких основных языках (например, Python). Чтобы избежать предвзятости и обеспечить справедливую обобщающую оценку, наш многоязычный набор данных SWE-Bench был специально сбалансирован и включает широкий набор языков программирования с репрезентативным количеством задач и уровнем сложности. Это позволяет провести надежную дифференциацию моделей и выявить подлинные сильные и слабые стороны моделей в менее распространенных и известных языковых областях.
Валидация эталонных решений в датасете: эталонные решения проходили двухэтапную проверку:
Автоматическая проверка (сборка/тесты, применение патчей)
Экспертная оценка (проверка корректности и релевантности решения)
Такой подход минимизирует:
Ложные положительные срабатывания (например, решения, которые компилируются, но содержат семантические ошибки)
Ложные отклонения (например, корректные альтернативные решения, ошибочно помеченные как неверные из-за узких критериев конверсии в итоговый датасет)
Сравнение с публичными бенчмарками
В процессе разработки датасета мы систематически сопоставляли часть наших задач с их аналогами из известных публичных бенчмарков по коду. Этот анализ выявил типичные проблемы:
Частые ошибки в разметке
Несоответствие между предоставленными "эталонными" патчами и фактическим состоянием репозитория
Принятие синтаксически корректных, но семантически ошибочных решений
Синтетические артефакты
Наличие программно сгенерированных задач или решений
Не отражают реальные проблемы разработки ПО
Могут быть обойдены моделями, «выучившими» шаблонные решения на этапе разработки
Неоднозначные или неполные задачи
Задачи с недостаточным контекстом
Задачи, в которых допускается несколько решений
Сложные для объективной оценки
Влияние на оценку моделей
Наши исследования показывают, что качественные, экспертно проверенные и сбалансированные датасеты
дают более низкие, но реалистичные оценки моделей
позволяют точнее сравнивать модели по их реальным возможностям, а не из-за особенностей датасета
В частности, модели, показывавшие SOTA-результаты на зашумленных бенчмарках, демонстрировали заметное падение производительности и меняли свои позиции в рейтинге при тестировании на нашем мультиязычном бенчмарке и оригинальном SWE-Bench.
Промежуточный вывод
Для достоверной оценки кодогенерирующих LLM необходимы:
Разнообразные и сложные задачи
Тщательная подготовка и валидация датасетов
Постоянный контроль качества
Без этого
Результаты бенчмарков могут завышать реальную применимость моделей
Замедляется прогресс в AI-разработке ПО.
Обсуждение
Наши результаты подтверждают важность комплексных многозадачных бенчмарков, основанных на реальных промышленных задачах, для оценки истинных возможностей больших языковых моделей (LLM) в разработке ПО.
Ограниченная обобщаемость моделей: модели, обученные на узкоспециализированных данных (например, соревновательных задачах или одноязыковых корпусах), показывают хорошие результаты в ограниченных областях, но плохо справляются с разнообразными реальными сценариями, особенно в менее представленных языках программирования и сложных кодовых базах.
Значение качественных данных: сбалансированные и тщательно проверенные наборы данных обеспечивают более надежные и воспроизводимые результаты, а также позволяют точнее дифференцировать модели, которые на менее качественных бенчмарках выглядят схоже.
Нерешенные проблемы: даже лучшие модели сталкиваются с трудностями при работе с изменениями в нескольких файлах, понимании контекста проекта и генерации семантически корректных исправлений. Для их преодоления требуются как улучшение моделей, так и совершенствование бенчмарков.
Заключение
Мы представляем многоязычное расширение бенчмарка SWE-Bench, ориентированное на промышленные задачи. Оно устраняет пробелы в существующих наборах данных, обеспечивая более честную, разнообразную и реалистичную оценку LLM. Результаты показывают, что многие современные модели, несмотря на впечатляющие показатели в стандартных тестах, испытывают значительные трудности в реальных многозадачных сценариях.
Источники
Chen, D., Zheng, S., Mishra, S., Du, X., Gu, J., Li, X., ... & Fried, D. (2023). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? arXiv preprint arXiv:2310.06780.
Original SWE-Bench dataset and evaluation pipeline. Core pipeline scripts and methodology for evaluation and patch application were adapted from this resource.
https://github.com/princeton-nlp/SWE-benchZan, D., Huang, Z., Liu, W., Chen, H., Zhang, L., Xin, S., ... & Xiang, L. (2025). Multi-SWE-bench: A Multilingual Benchmark for Issue Resolving. arXiv preprint arXiv:2504.02605. https://arxiv.org/abs/2504.02605multi-swe-bench.github.io+8arxiv.org+8github.com+8
Zan, D., Huang, Z., Liu, W., Chen, H., Zhang, L., Xin, S., ... & Xiang, L. (2025). Multi-SWE-bench: A Multilingual Benchmark for Issue Resolving. Multi-SWE-bench Documentation. https://multi-swe-bench.github.io
Jimenez, C. E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O., ... & Narasimhan, K. R. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? Proceedings of the 12th International Conference on Learning Representations (ICLR 2024). https://openreview.net/forum?id=VTF8yNQM66arxiv.org+3github.com+3github.com+3
Zhang, L., He, S., Zhang, C., ... & Zhang, D. (2025). SWE-bench Goes Live! arXiv preprint arXiv:2505.23419. https://arxiv.org/abs/2505.23419arxiv.org
Hugging Face. (2024). Transformers Library Documentation. https://huggingface.co/docs/transformers
OpenRouter. (2024). OpenRouter API Documentation. https://openrouter.ai/docs
Wolf, T., Debut, L., Sanh, V., ... (2020). Transformers: State-of-the-Art Natural Language Processing. Proceedings of the 2020 EMNLP: System Demonstrations (pp. 38-45). https://aclanthology.org/2020.emnlp-demos.6/
Multi-SWE-bench Team. (2025). Multi-SWE-bench: A Multilingual Benchmark for Issue Resolving. GitHub Repository. https://github.com/multi-swe-bench/multi-swe-bench
Приложение
A. Процесс сбора и валидации данных
A.1. Исходные данные
Список включенных репозиториев
Распределение задач по языкам
Ключевые наблюдения
Доминирующие языки:
Ruby является доминирующим языком в наборе данных, он встречается в 8 из 20 репозиториев. Эти репозитории в основном сосредоточены на инфраструктуре и инструментах разработки, таких как CocoaPods/CocoaPods, github-changelog-generator/github-changelog-generator, и ruby-grape/grape.
Особенности набора репозиториев:
Репозитории преимущественно сосредоточены вокруг инфраструктурных проектов (например, go-kratos/kratos, prometheus/prometheus) и утилит для разработчиков (например, gohugoio/hugo, go-resty/resty). Также значительно представлены веб-/социальные платформы (например, mastodon/mastodon, facebook/docusaurus).
Репозитории Android и Kotlin в первую очередь ориентированы на мобильные приложения, а Rust сосредоточен на утилитах системного уровня и инструментах, ориентированных на производительность.
Лицензирование данных:
Большинство репозиториев распространяются под разрешительными лицензиями, такими как MIT, за исключением нескольких заметных случаев, например, copyleft лицензий для социальных/веб-платформ (таких как mastodon/mastodon), которые подчёркивают принципы открытого и свободного ПО.
A.2. Генерация задач
Подробнее
Pipeline для генерации реальных задач в разработке ПО
Сбор Issues и Pull Request’ов:
Автоматический сбор issues и PR из выбранных репозиториев через GitHub API или прямое сканирование.
Отбор PR, которые:
Связаны с конкретным issue,
Содержат текстовое описание и код с изменениями.
2. Извлечение patch’й и генерация diff
Для каждого подходящего PR извлекается минимальный diff (патч), относящийся к задаче.
Сохраняются все затронутые файлы до и после изменений, чтобы обеспечить полный контекст для применения и проверки патча.
Context and Metadata Attachment:
Для каждой задачи фиксируются связанные метаданные, включая:
Хеш коммита
Автора изменений
Дату внесения правок
Затронутые файлы
Описание связанного issue
A.3. Генерация эталонных данных
Подробнее
Автоматическое извлечение эталонных решений:
Для каждого принятого pull request'а с помощью GitHub API или git diff извлекается соответствующий diff коммита.
Сохраняются версии затронутых файлов до и после изменений, а также сам патч с минимальным набором правок для решения задачи.
Каждый патч связывается с метаданными исходного issue и PR для обеспечения отслеживаемости.
Проверка валидности полученных patch’ей:
Автоматическое применение каждого патча к исходной кодовой базе с помощью VCS-инструментов (git apply).
После применения выполняется сборка проекта и запуск доступных автотестов (через make, pytest, mvn test и т.д.).
В финальный набор данных включаются только патчи, которые успешно применяются, проходят сборку и все тесты.
A.4. Экспертная валидация
Протокол ручной проверки
Выборка и охват:
Каждая задача в наборе данных была проверена как минимум одним экспертом-аннотатором с опытом в разработке ПО (100% покрытие). 30% задач прошли перекрёстную проверку вторым независимым аннотатором для оценки согласованности (с учётом репозитория, языка программирования и типа задачи).
Распределение аннотаторов
Каждая задача проверялась по стандартизированному протоколу. Для перекрестной проверки два аннотатора независимо оценивали корректность и полноту решения.
Критерий принятия решения:
Патч считался валидным, если он:
Корректно решал описанную проблему/реализовывал функционал;
Не вносил регрессий или посторонних изменений;
Был минимальным и соответствовал контексту задачи.
Оценка качества описания задачи:
Аннотаторы оценивали ясность issue по шкале SWE-bench Verified и отбирались решения, получившие отметки:(0) “The issue is well-specified and it is clear what is required for a successful solution;”
(1) “There are some blanks to fill in about the issue, but there is a sensible interpretation of what is required for a successful solution.”
Оценка покрытия тестами:
Аналогично отбирались наборы, тестирующие решения:(0) “The tests perfectly cover all possible solutions;”
(1) “The tests cover the majority of correct solutions, however some unusual solutions may be missed.”
Разрешение разногласий:
При расхождениях решение принимал старший аннотатор. Неоднозначные задачи исключались из финального набора.
Инструкция к разметке и крайние случаи
Аннотаторам предоставляется подробный документ с рекомендациями, который охватывает следующие аспекты:
Как оценивать несколько допустимых решений
Все решения, соответствующие критериям приемки, должны отмечаться как правильные, даже если существует несколько вариаций.Обработка частичных исправлений
Частичные исправления исключаются из рассмотрения, если они не обозначены явно и не могут быть протестированы в соответствии с требованиями.Отношение к рефакторингу и изменениям, затрагивающим только стиль
Такие правки исключаются, если они не были явно запрошены в задаче.Протокол документирования причин исключения задачи или разногласий
Аннотаторы должны четко фиксировать причины, по которым задача была исключена из оценки, или причины возникновения разногласий при проверке.
A.5. Баланс языков
Подробнее
Пропорциональное распределение стека задач
После парсинга задач анализируется их распределение по языкам программирования.
Недостаточно представленные языки могут быть дополнены за счет целенаправленного поиска в дополнительных хранилищах или включения менее частых, но все же качественных задач.
Распределение сложности задач
Датасет стратифицирован по степени сложности, определяемой через
Количество измененных строк в patch;
Количество измененных файлов в patch;
Количество тестов, проверяющих оригинальное решение задачи.
Мы стремились подобрать задачи таким образом, чтобы в каждом языке были сбалансированно представлены легкие, средние и трудные категории.
Дополнительной постобработкой мы гарантировали, что ни один язык или тип задачи (например, тривиальные исправления) не будет доминировать в конечном наборе данных, что способствует справедливой оценке модели.
B. Подробное определение метрик
B.1. pass@k:
Математическое определение
Для каждой задачи pass@k вычисляется как вероятность того, что хотя бы один из k выборочных выходов модели приведет к успешному решению. Ожидаемое значение вычисляется как:
где n — общее количество сгенерированных образцов для каждой задачи, а c — количество правильных образцов.
Процедура попыток решения:
Для каждого задания один и тот же prompt подавалась модели 3 раза, что давало 3 независимых результата. Каждый результат оценивался отдельно.Критерий успеха:
Решения модели считаются успешными, если после применения сгенерированного patch все результаты тестов (как из исходных логов, так и из логов, сгенерированных моделью) полностью совпадают — это свидетельствует о функциональной эквивалентности.
B.2. Precision, F1
Определение точности:
Точность — это доля правильно сгенерированных изменений кода среди всех изменений, предложенных моделью.Определение F1 оценки:
Оценка F1 рассчитывается как среднее гармоническое значение точности и pass@1, обеспечивая сбалансированную оценку способности модели генерировать корректные решения.Обработка частичных совпадений:
Функционально корректные патчи, которые могут отличаться синтаксически, считаются корректными, если удовлетворяют тестовым случаям. Частичные совпадения или неидентичные, но функционально эквивалентные патчи считаются корректными
B.3. Протокол качественного анализа
После применения патчей и тестирования с использованием multi-swe-bench, полученные логи анализируются для оценки качества модели. В процессе анализа логи сравниваются по статусам задач, где проверяется, совпадают ли результаты тестов, полученные с эталонными патчами, с результатами, генерируемыми моделью. Это позволяет вручную оценить синтаксические ошибки, логические несоответствия или недоразумения в контексте задачи.
D. Golden solution changes Analysis
Обсуждение возможных Bias вследствие отобранных исходных данных
Хотя мы стремились максимизировать языковое и тематическое разнообразие при выборе репозиториев, некоторые предубеждения могли сохраниться.
Языковая предвзятость: итоговый набор данных отражает концентрацию задач на JS, GO и Rust из-за популярности и уровня активности доступных репозиториев на этих языках. В результате языки с меньшим количеством качественных open-source проектов (например, PHP по сравнению с Go или Ruby, C++, C#) оказались недостаточно представлены. Это может повлиять на оценку моделей, создавая преимущество для тех, которые лучше адаптированы к доминирующим языкам.
Тематическая и экосистемная предвзятость: в наборе данных значительную долю составляют веб-фреймворки, мобильные клиенты и инструменты для инфраструктуры. Напротив, научные вычисления, embedded-системы или низкоуровневое программирование представлены слабее. Это может благоприятствовать моделям или подходам, оптимизированным для разработки приложений и веб-решений. Также значительную часть списка репозиториев составляют утилитарные проекты.
Предвзятость поддержки и популярности: мы отдавали приоритет активно поддерживаемым и популярным репозиториям (на основе звёзд, форков и недавней активности коммитов). Хотя это повышает актуальность задач и качество данных, менее известные, но технически значимые проекты могли быть исключены. Кроме того, это может усилить шаблоны, характерные для популярных экосистем.
Предвзятость типа задач: некоторые репозитории, такие как системы управления контентом и инструменты для разработчиков, естественным образом содержат больше тривиальных или повторяющихся задач. Несмотря на фильтрацию, это может повлиять на распределение сложности и типов задач в рамках бенчмарка