Вернуться к списку задач

ruCodeReviewer

Таксономии
Instruction Following
Code Perception
Style Guides
Review
Simulation
Explanation
Programming Patters
Метрика
chrF
BLEU
judge@1
judge@5
judge@10
Языки
Python
Go
Java
Scala

Описание задачи

Задача заключается в автоматической генерации комментариев для ревью кода на русском языке на основе изменений в коде.

Датасет содержит 689 примеров изменений кода на Java, Python, Scala и Go с соответствующими комментариями, проверенными на воспроизводимость и релевантность.

Тестируемые навыки моделей: Instruction Following, Code Perception, Review, Simulation, Explanation, Programming Patters, Style Guides

Авторы: Артем Завгороднев, Александр Медведев, Георгий Мкртчян, Иван Харкевич, Ильсеяр Алимова, Николай Бушков, Станислав Моисеев.

Мотивация

Этот бенчмарк устраняет критический пробел в оценке многоязычных LLM с поддержкой кода.

Целевые модели: Многоязычные LLM, способные обрабатывать русский язык.

Ограничения: Не подходит для моделей, не поддерживающих русский язык или не связанных с анализом кода.

Пользователи: Разработчики и исследователи, работающие над автоматизацией code review в русскоязычных командах. Результаты помогают оценить, насколько модель способна заменить человека в генерации полезных, контекстно-зависимых комментариев.

Оцениваемые способности:

- Понимание синтаксических и семантических изменений в коде.

- Генерация комментариев, специфичных для выявленных проблем (например, ошибки, оптимизация, стиль).

- Умение работать с различными языками программирования (Java, Python, Scala и Go).

Эти способности критичны для интеграции LLM в реальные процессы разработки, где требуется точность и соответствие стандартам.

Дизайн датасета:

- Комментарии привязаны к конкретным изменениям в коде, чтобы исключить зависимость от внешнего контекста.

- Двухэтапная фильтрация (LLM + двойная человеческая проверка) гарантирует, что комментарии самодостаточны и воспроизводимы.

Валидность обеспечивается строгим отбором: комментарий должен быть понятен только на основе приложенных изменений в коде.

Метрики:

BLEU/ChrF: Оценивают текстовое соответствие с эталоном.

judge@k: Метрика измеряет, в каком проценте случаев хотя бы один из первых k сгенерированных комментариев признается корректным при оценке LLM-as-a-Judge.

Модель генерирует до 10 вариантов комментариев для конкректного изменения в коде.

Каждый вариант проверяется LLM-судьей на соответствие смыслу эталонного комментария (reference-based).

Если среди первых k вариантов есть хотя бы один "прошедший" проверку — образец считается успешным.

Зачем это нужно?

Мы не требуем точного воспроизведения комментария ревьювера. Вместо этого оценивается способность модели генерировать в целом качественные комментарии, среди которых может быть и тот, который предложил бы человек. Это особенно важно для задач code review, где существует множество валидных способов указать на проблему.

Описание датасета

Поля датасета

Каждый вопрос в датасете содержит следующие поля:

  • instruction [str] — Промпт-инструкция для модели, содержащая шаблон для вставки элементов вопроса;
  • inputs — Вводные данные, формирующие задание для модели. Могут включать одну или несколько модальностей - видео, аудио, изображение, текст;
    • diff_block [str] — Фрагмент кода в формате унифицированного diff, отображающий изменения (добавленные/удалённые строки через +/-) в пределах определённого контекста (например, функции или класса);
  • outputs [str] — Эталонный комментарий ревьювера;
  • meta — Метаданные, относящиеся к тестовому примеру, но не используемые в вопросе (скрытые от тестируемой модели);
    • id [int] — Номер-идентификатор вопроса в датасете;
    • diff_block_with_arrow [str] — diff_block со стрелками, указывающими на строки, на которые написан комментарий;
    • full_diff [str] — diff всего файла;
    • language [str] — Язык программирования;
    • original_end_line [int] — Номер строки, на которой оканчивается комментарий в файле до изменений;
    • original_start_line [int] — Номер строки, с которой начинается комментарий в файле до изменений (-1, если комментарий написан на одну строку);
    • start_line [int] — Номер строки, на которой начинается комментарий (-1, если комментарий написан на одну строку);
    • end_line [int] — Номер строки, на которой оканчивается комментарий.

Промпты

Для задачи были подготовлены 10 промптов, которые были равномерно распределены по вопросам по принципу "один вопрос – один промпт". Шаблоны в фигурных скобках в промпте заполняются из полей внутри поля inputs в каждом вопросе.

Пример промпта:

Ты - проверяющий код (ревьювер). Твоя задача — анализировать изменения в коде и предлагать улучшения. Укажи на проблемные места и предложи способы их исправления или улучшения.

Используй максимум 10 комментариев. Форматируй ответ следующим образом:

Комментарий 1: <твой комментарий>

Комментарий 2: <твой комментарий>

Комментарий 3: <твой комментарий>

Комментарий 4: <твой комментарий>

Комментарий 5: <твой комментарий>

Комментарий 6: <твой комментарий>

Комментарий 7: <твой комментарий>

Комментарий 8: <твой комментарий>

Комментарий 9: <твой комментарий>

Комментарий 10: <твой комментарий>

Изменения кода:

{diff_block}

Создание датасета

Исследование охватило репозитории, созданные в BackEnd академии за 2024 год. Основные этапы:

1. Сбор данных: Через GitHub API извлечены комментарии к pull request’ам, коммитам и строкам кода.

2. Сегментация кода: Языково-специфичные парсеры (AST для Java/Scala, go/parser для Go, ast для Python) выделили логические блоки кода (классы, функции).

3. Фильтрация датасет:

- Удалены комментарии к файлам, не относящимся к целевым языкам программирования (50 примеров).

- Классификация через GPT-4o на воспроизводимые/невоспроизводимые: проверка возможности восстановления контекста комментария исходя только из изменений в коде.

- Ручная проверка 1300 примеров, которые которые предыдущая модель поменила как "воспроизводимые": утверждено 689 примеров.

Метрики

В качестве LLM-as-a-Judge используется Qwen2.5-Coder-32B-Instruct.

Для агрегированной оценки ответов моделей используются следующие метрики:

BLEU: BLEU (Bilingual Evaluation Understudy) — метрика для автоматической оценки качества машинного перевода, основанная на сравнении n-грамм кандидата с эталонными переводами, учитывающая точность и штраф за краткость.

chrF: chrF (Character n-gram F-score) — это метрика для оценки качества машинного перевода, основанная на F-мере, которая учитывает совпадения символьных n-грамм между кандидатом и эталонными переводами, объединяя точность и полноту.

judge@1: Доля примеров, в которых первый комментарий, сгенерированный моделью, LLM-as-a-Judge признал корректным.

judge@5: Доля примеров, где хотя бы один из первых 5 комментариев, сгенерированный моделью, LLM-as-a-Judge признал корректным.

judge@10: Доля примеров, где хотя бы один из первых 10 комментариев, сгенерированный моделью, LLM-as-a-Judge признал корректным.

Языки
Python
Go
Java
Scala