Любой разработчик, который просил языковую модель задокументировать код на русском, сталкивался с одним из трёх сценариев: модель переключается на английский, выдаёт дословный перевод технических терминов («развёртывание» вместо «деплой») или нарушает структуру докстринга так, что IDE перестаёт его распознавать. Причина системная — существующие датасеты для обучения кодинг-моделей либо не содержат русского языка вовсе, либо ориентированы на поиск кода, а не на генерацию документации.
Исследователи из MWS ИИ подошли к проблеме с академической стороны. Они собрали датасет StRuCom, включающий 153 тысячи пар «код — комментарий» на русском языке для пяти языков программирования: Python, Java, Go, C# и JavaScript. Работа представлена на конференции ACL 2025. Принципиальное отличие от существующих наборов данных — отсутствие машинного перевода: все примеры либо взяты из реальных русскоязычных репозиториев на GitHub, либо синтетически сгенерированы с сохранением авторского стиля.
| Язык программирования | Стандарт документации | Эффективность улучшения (MIQU-70B) |
|---|---|---|
| Go | GoDoc | 84% |
| Python | GoogleDoc | затруднено (требования к типам) |
| JavaScript | JSDoc | затруднено (требования к типам) |
| Java | Javadoc | — |
| C# | XML | — |
Сбор данных оказался нетривиальной задачей. GitHub API не позволяет фильтровать репозитории по языку коммитов, поэтому авторам пришлось скачивать репозитории с русскоязычными описаниями и открытыми лицензиями, а затем прогонять их через парсеры и языковые детекторы. Для определения языка использовали комбинацию FastText и Lingua — последняя показала лучшую точность при работе с очищенным текстом без меток кода. Из потока данных вычищали код библиотек (где документация почти всегда на английском), автогенерацию и дубликаты.
Данные взяты из реальных репозиториев GitHub, машинный перевод не использовался.
Отдельным этапом стала валидация структуры. Команда разработала инструмент, проверяющий соответствие пяти стандартам документации: GoogleDoc для Python, Javadoc для Java, GoDoc для Go, XML для C# и JSDoc для JavaScript. Комментарии делились на три группы: полные (есть описание всех аргументов и возвращаемого значения), частичные и некорректные. В итоговый датасет вошли только первые две категории.
Реальных данных не хватало — особенно для Python и JavaScript, где разработчики нередко пропускают полные докстринги. Для расширения датасета использовали модель MIQU-70B — мощную open-source модель с хорошим пониманием русского языка. Применяли два сценария: дописывание недостающих полей в существующих комментариях без изменения авторского текста и генерация докстрингов с нуля для кода без документации. Go оказался наиболее простым для автоматического улучшения — эффективность составила 84%, что объясняется минималистичностью стандарта GoDoc. Python и JavaScript давались сложнее из-за требований к явному указанию типов.
Для оценки полезности датасета исследователи провели дообучение моделей семейства Qwen2.5-Coder четырёх размеров: 0.5B, 1.5B, 3B и 7B параметров. Качество измеряли по двум метрикам: BERTScore (семантическая близость текста) и chrF++ (символьное совпадение, критичное для точного синтаксиса). Дообучение дало статистически значимый прирост для всех размеров моделей. Наибольший эффект получили малые модели — 0.5B и 1.5B: после тонкой настройки они начали генерировать докстринги, по качеству приближающиеся к результатам значительно более крупных моделей. Дополнительно использовали метод LLM-as-a-judge: в 80% случаев автоматическая оценка совпала с мнением живых экспертов. Часть датасета опубликована на Hugging Face.
