Всем привет! Пару месяцев назад Альянс в сфере искусственного интеллекта, в который MWS AI тоже входит, запустил MERA CODE — бенчмарк для оценки качества умений написания кода для больших языковых моделей. MERA CODE оценивает способности моделей в реальных сценариях, с которыми встречаются разработчики программного кода: написание unit-тестов, комментариев, функций по запросу и многое другое — подробности тут. Однако все задачи в MERA CODE, как впрочем и в SWE-bench и других бенчмарках подобного назначения, следуют классической парадигме, когда у нас есть фиксированный обучающий набор данных и, что более важно, фиксированный проверочный набор.

К сожалению, фиксированные наборы данных могут устаревать, из-за чего бенчмарки на их основе с течением времени теряют свою эффективность. Как это происходит? Многие из наборов данных для бенчмарков собраны из открытых источников. В нашем случае это прежде всего GitHub. Но большие языковые модели для кодинга, которые мы и пытаемся оценивать нашим набором, также учатся на GitHub — со времен еще первой модели LLaMa. А раз они учатся на данных с GitHub, то рано или поздно (и в наше время скорее рано) эти большие языковые модели также во время обучения увидят данные из проверочного множества. Это явление называется контаминацией данных, то есть мы не можем больше быть уверены в том, что оценка моделей является объективной. 

Мы думали об этой проблеме, и пришли к выводу, что ее влияние можно минимизировать, если мы будем периодически обновлять проверочное множество. Так родилась идея для нашего нового бенчмарка — SWE-MERA.

Коротко об SWE-MERA

SWE-MERA — это бенчмарк для оценки моделей для кодинга на реальных задачах по типу SWE-bench. Как и SWE-bench, он основан на issues и pull requests с GitHub, но является динамичным — в него регулярно в автоматическом режиме добавляются новые актуальные примеры задач из активных репозиториев. Пользователи могут выбирать задачи из разных временных периодов, что упрощает выявление моделей, затронутых контаминацией данных.

Как мы обеспечиваем обновление проверочного множества?

Начну с того, что данные в бенчмарке обновляются на ежемесячной основе — каждый месяц добавляется приблизительно 250 новых задач. Так мы можем быть более менее уверены в том, что LLM проверяются на задачах, которых они не видели просто в силу того, что модели пусть и выходят очень часто, но все-таки конкретная модель учится на конкретном наборе данных, у которого есть финальная дата – дата создания самого нового документа, и эта дата всегда отстает от текущей на несколько месяцев просто в силу того, что сам по себе процесс обучения и тестирования требует времени.

Давайте немного статистики. Отобрать популярные активные репозитории — это уже само по себе непросто, таковых репозиториев больше 100000. Потом нужно выбрать из них issues, их порядка 300000. Дальше мы применяем несколько уровней фильтрации и в итоге получаем всего лишь 700 задач для LLM.

Кажется, что 700 задач немного, но это уже очень приличное количество, и что самое важное — это новые задачи. В процессе сборки мы собрали более 2700 задач, но для замера бенчмарка нет смысла использовать такое большое количество.

Каждый месяц мы можем собирать еще приблизительно 250 новых задач. Так что мы можем быть более менее уверены в том, что LLM проверяются на задачах, которых они не видели просто в силу того, что LLM пусть и выходят очень часто, но все-таки конкретная модель учится на конкретном наборе данных, у которого есть финальная дата — дата создания самого нового документа, и эта дата всегда отстает от текущей на несколько месяцев просто в силу того, что сам по себе процесс обучения и тестирования требует времени.

Как устроен бенчмарк? 

Для того, чтобы про это рассказать, нужно пройти по нескольким шагам.

Шаг 1. Мы собираем список активных репозиториев на GitHub. 

Это должны быть достаточно  популярные репозитории с форками, свежими закрытыми issues с прилинкованным и смердженным pull request, а еще тестами

Шаг 2. Мы скачиваем отобранные репозитории и issues, и запускаем в них pytest. Если репозиторий у нас не получается протестировать автоматически, то мы его исключаем.

Шаг 3. Мы находим связанные с issue коммиты и делаем две версии репозитория — до закрытия issue и после. Находим разницу между состояниями репозитория до и после, отбираем новые тесты, появившиеся в процессе закрытия issue. 

В итоге у нас получается набор из содержимого репозитория "до", текста issue и набора юнит-тестов, которые должны начать проходить в репозитории "после". Все это подается на свод LLM, которая должна сгенерировать (вообще говоря любым, но мы рассматриваем только агентным способом) изменения в один или несколько файлов в репозитории, чтобы указанный issue был успешно разрешен. Успешность мы проверяем по тому самому набору юнит-тестов, который отобрали на третьем шаге. Если все требуемые тесты пройдены, то мы считаем, что LLM справилась c задачей.

Методология сбора задач очень похожа на один из самых популярных бенчмарков — SWE Bench. Ключевое отличие нашего бенчмарка в том, что мы автоматически собираем новые задачи из свежих issue GitHub.

Мы выложили в открытый доступ repotest, репозиторий для запуска и сбора задач.

from repotest.core.docker.python import PythonDockerRepo 

repo = PythonDockerRepo(
    repo="sympy/sympy",
    base_commit="b6091e94af5ce0464472b5639503e3117efe8dee",
    image_name="python:3.11"
)

repo.clean()  # Reset the repo folder to the base commit state
repo.build_env(“pip install .\npip install -r requirements-dev.txt\npip install pytest-json-report”, timeout=60*5)  # Set up the environment
repo.apply_patch(patch)  # Apply a patch to the repo
repo.run_test("pytest --json-report --json-report-file=report_pytest.json", timeout=60*5)

Теперь давайте обсудим имеющиеся результаты. Мы проверили несколько популярных открытых моделей, результаты доступны тут.

Выше приведены метрики open source моделей на агенте aider в формате метрика [5%-95% доверительный интервал].

В наших планах на ближайшие несколько месяцев — расширить количество языков до 5 (c++, java, javascript, typescript, go) и количество задач в несколько раз.

Если вы хотите протестировать какую-то свою модель, то у нас есть инструкция, как это сделать. 

Перед заключением хочется похвастаться, что нашу статью про этот бенчмарк приняли на конференцию EMNLP, которая пройдет в Китае в ноябре.

И теперь уже заключение, хочется сказать, что мы надеемся, что SWE-MERA будет полезным инструментом, который поможет избежать переобучения на конкретный бенчмарк со стороны языковых моделей.

Хотим поблагодарить Альянс в сфере искусственного интеллекта за предоставленную поддержку в разработке данного проекта и выразить благодарность коллегам, с которыми мы делали эту работу, прежде всего моему студенту Михаилу Иванову из ИТМО, который первым занялся этим проектом, Павлу Адаменко, Айдару Валееву,  Павлу Задорожному, Родиону Левичеву, Ивану Лопатину и Дмитрию Бабаеву из команды GigaCode, а также Алене Феногеновой, руководителю проекта MERA.