Месяц научного open source продолжается, и это — разговор с Николаем Никитиным, к.т.н и руководителем одной из лабораторий Университета ИТМО. @niclnno — энтузиаст открытой разработки. Он проводит тематические исследования и семинары, а также развивает сообщество «Научный опенсорс» вместе с коллегами из ИТМО и не только.

Расскажите, пожалуйста, о своем академическом и профессиональном опыте. Как вы пришли к руководству одной из фронтирных лабораторий Университета ИТМО? Как я понимаю, вы участвуете в работе сразу нескольких коллективов

Обучение в бакалавриате и магистратуре я проходил на кафедре ВТ в Университете ИТМО. Там давалось сильное фундаментальное образование в области Computer Science, хотя, оборачиваясь назад, можно сказать — постфактум не хватило погружения в математику и машинное обучение. Но удалось немного пощупать и опенсорс: в качестве выпускной работы я участвовал в разработке системы групповой работы C3 на языке Scala. Мы хотели помочь ученым в версионировании данных, упростить поиск материалов с помощью автоматизированного аннотирования научных документов (используя методы NLP), реализовать семантический поиск по ним. Но задача оказалась слишком амбициозной: система не вышла из статуса прототипа и использовалась внутри команды.

Еще в ходе учебы я начал работу на позиции разработчика ПО: мы создавали корпоративные порталы для различных заказчиков на языке C#. Однако, после окончания магистратуры хотелось поискать что-то более интересное. В 2016 году увидел вакансию в НИИ наукоемких компьютерных технологий ИТМО и решил попробовать, хотя до этого планов «уходить в науку» не имел вовсе. Меня взяли в небольшую группу Анны Калюжной, которая занималась задачами гидрометеорологического моделирования.

Дальше поступил в аспирантуру, постепенно расширял свои научные интересы на всё новые направления (методы оптимизации, машинное обучение, гибридное моделирование), участвовал в международных конференциях, постепенно вышел на уровень публикаций в топовых журналах. Основным языком разработки для меня стал Python. В 2020 защитил кандидатскую по теме автоматизации настройки моделей природных систем. После этого решил сделать следующий шаг и начать не просто публиковать статьи, но и создавать опенсорс-инструменты на основе научных идей. 

Сейчас в команде лаборатории почти 50 человек, из которых под моим руководством около 20. Свою лабораторию мы международно обозначаем Natural Systems Simulation Lab. Внутри неё — тоже несколько специализированных лабораторий с различными источниками финансирования.

Так, лаборатория композитного ИИ под руководством Александра Хватова занимается объединением нейросетевых и физико-информированных методов в одной модели. Лаборатория автоматического машинного обучения, которой руковожу я, занимается разработкой новых методов автоматизации создания пайплайнов МО. Конечно, все эти «перегородки» очень условны — мы все теснейшим образом взаимодействуем и внутри NSS Lab, и с другими командами исследовательского центра «Сильный ИИ в промышленности» ИТМО.

Этим летом, например, вместе с Анной и Александром мы заняли первое место в конкурсе РАН для молодых ученых в номинации по ИИ.

Также я активно руковожу научной деятельностью студентов и аспирантов (похвастаюсь — недавно получил за это Yandex ML Prize в номинации «Молодой научный руководитель»), участвую в программных комитетах нескольких конференций и воркшопов. И, конечно, возглавляю сообщество ITMO OpenSource.

Должно быть, открытые разработки в Университете ИТМО уже существовали к моменту запуска сообществ ITMO OpenSource и «Научный опенсорс». Так ли это? Могли бы вы рассказать о первых таких проектах? В какой момент вы с коллегами решили структурировать коммуникацию по части open source-начинаний?

Первым таким проектом, созданным под моим руководством, стал фреймворк автоматического машинного обучения FEDOT. Его идея в возможности обеспечения максимальной гибкости процесса создания моделей. Фреймворк стал «широко известен в узких кругах» — им пользуются отдельные исследователи и научные команды по всему миру (например, недавно установили контакты с активно использующей FEDOT командой гидрологов из Бразилии), его упоминают в ключевых обзорах по этой теме.

На дворе 2025, и мы по-прежнему продолжаем развивать фреймворк и производные проекты (FEDOT.Industrial, FEDOT.LLM). Делали мы и инструменты для смежных задач: GEFEST — для задач генеративного дизайна, GOLEM — для графовой оптимизации. При этом мы запускаем и проекты в новых для нас областях, например, фреймворк ProtoLLM для создания приложений на основе больших языковых моделей.

Однако, реализуя все эти проекты, мы довольно быстро столкнулись с проблемой их популяризации в сообществе. На тот момент (конец 2022) было очень мало площадок, где можно было рассказать именно о научных, а не индустриальных открытых проектах в области ИИ. Поэтому мы и решили стартовать свой цикл митапов, из ядра участников которых и выросло наше сообщество. Для того, чтобы удобнее было коммуницировать создали чат для общения. Когда чат разросся за тысячу человек, и стало понятно, что следить за ним стороннему читателю сложно, — создали ещё и канал, куда периодически закидываем релевантные новости из мира опенсорса и анонсы своих активностей.

Свободно делимся в канале и результатами других команд и сообществ: конкурировать с ними и «тянуть одеяло на себя» для нас никакого смысла нет.

Разумеется, я занимаюсь развитием сообщества. Активными его участниками являются многие сотрудники ИТМО (например, Андрей Гетманов — энтузиаст открытого кода, который представляет сообщество на многих мероприятиях, и Юрий Каминский — аспирант и руководитель студенческого клуба любителей опенсорса).

В основном открытые разработки Университета ИТМО представлены в репозиториях лаборатории моделирования природных систем (NSS Lab) и сообщества AIM.club. Возможно, кто-то еще из ваших коллег отдает свои наработки в open source? Интересуются ли представители других лабораторий и центров вашим опытом?

Действительно, в ИТМО немало команд, которые тоже опенсорсят свои результаты. Например, Центр ИИ в Химии , с которым мы активно сотрудничаем и публикуем совместные статьи (недавно одну из них приняли на NeurIPS — топовую конференцию в мире ИИ). Наш недавний опенсорсный проект — инструмент для генерации ко-кристаллов GEMCODE. Другой пример — учебно-научные лаборатории LISA и CT, у которых тоже есть многочисленные репозитории, развиваемые студентами. Есть открытые проекты и у студентов магистерской программы ИТМО AI Talent Hub.

Опытом стараемся обмениваться, приглашаем на митапы, помогаем советами, но, безусловно, проблема взаимной информированности стоит остро, многие команды друг о друге даже и не знают. Как часть решения проблемы — сделали у себя подборку научных опенсорс-репозиториев от различных лабораторий и центров в ИТМО и не только. Также активно пересекаемся представителями заинтересованных в открытом коде команд на «чужих» мероприятиях. За прошлый год, например, я рассказал про результаты нашего сообщества на Highload++, Yandex Open Source Jazz, DataFest.

В большинстве открытых разработок Университета ИТМО используется лицензия BSD 3-Clause. Хотя в новых проектах можно встретить и лицензию MIT. Как вы считаете, почему коллеги отдают предпочтение именно этим лицензиям? Какие еще лицензии вы считаете востребованными в вашей области?

Для нас опенсорсные проекты — это не только возможность обеспечить воспроизводимость и переиспользуемость наших научных результатов, но и отправная точка для совместных проектов с индустрией. Поэтому одно из основных требований к лицензиям — это отсутствие некомфортных для коммерческого использования «вирусных» пунктов. При этом сохранение упоминания авторов для нас критично. Поэтому GNU GPL мы обычно не применяем, а BSD-3 и MIT вполне подходят.

Могли бы вы поделиться опытом проведения Scientific Open Source Meetup? Какие темы первых встреч и выступлений вы могли бы выделить? Есть ли у вас планы по развитию формата — например, с точки зрения проведения онлайн-встреч или, допустим, организации мини-хакатонов по данному направлению?

На первом митапе мы начали с достаточно «высокоуровневых» тем: «Как и зачем делать открытый научный код», «Зачем математику репозитории и коммиты», «Немного о код ревью». На следующих мероприятиях добавили формат с рассказом о конкретных проектах, отдельных аспектах развития открытого кода. На каждый митап стараемся привлечь спикеров не только из ИТМО, но и извне. Например, на последнем митапе часть докладов была от представителей компании OpenScaler: они рассказали об экосистеме открытого кода в Китае в целом и о проекте OpenScaler OS в частности.

На каждом митапе примерно 50% — из числа постоянных участников сообщества. Остальные — представители как институтов и университетов, так и технологических компаний. Наш основной формат митапов очный (в Санкт-Петербурге), так как это дает лучшие возможности для нетворкинга. По этой же причине в качестве площадки мы обычно выбираем какой-то уютный бар. Также для слушателей доступна трансляция.

В то же время мы экспериментируем с онлайн-форматом и проводим часть мероприятий в нем, чтобы охватить и спикеров из других городов. Смешивать же онлайн и оффлайн сложно — по моему опыту участия в гибридных конференциях, формат с удаленными докладчиками на очных мероприятиях редко «заходит» публике.

Пробуем мы и новые содержательные форматы: так, недавно мы провели «Разборку кода» с публичным анализом позитивных и негативных аспектов некоторых репозиториев, созданных в ИТМО. Пробовали и проводить митапы с фокусом на конкретную научную тематику — например, Байесовские методы. Хакатоны, посвященные созданию опенсорных решений, пока не проводили, но на организуемых в ИТМО ML-хакатонах на качество кода всегда смотрим, если участвуем в экспертизе. Но, конечно, чем уже тема мероприятия, тем сложнее найти спикеров, и достаточную аудиторию слушателей. Поэтому большинство наших мероприятий имеют широко очерченную тематику.

Не так давно вы опубликовали большое исследование по теме открытых ML/Data разработок и активности организаций в этой области. Что примечательно, вы отметили студенческие сообщества, а также гранты и корпоративные инициативы по поддержке open source-начинаний в России. На ваш взгляд, есть ли потенциал для расширения подобных форматов поддержки? Что еще было бы полезно запустить?

Для научных проектов даже небольшие по размеру, но массовые гранты могут быть очень полезны. Главное тут — не цепляться за формальные показатели, а давать энтузиастам дополнительную мотивацию запускать интересные разработки. Перспективным форматом могла бы быть поддержка не только создания новых, но и развития существующих проектов — здесь речь как о развитии кода и документации, так и о взаимной интеграции опенсорсных проектов и решении с их помощью практических задач.

Такие гранты могут стать хорошим инструментом реализации совместных проектов между бигтехом и научными центрами (у нас есть такой опыт со лабораторией ИИ Сбера). Сейчас наиболее привлекательными для опенсорс-команд являются гранты линейки КОД-ИИ от Фонда Содействия Инновациям (например, в нашей лаборатории целых три получателя таких грантов), но их одних объективно недостаточно.

Востребованным инструментом вовлечения студентов в опенсорс-разработку могли бы стать целевые стипендии (сейчас подобная практика есть у компании Selectel). Ещё можно вспомнить и разного рода негосударственные профессиональные премии, которые тоже могут быть хорошей поддержкой для энтузиастов. Позитивные примеры уже есть (Научная премия Сбера, Yandex ML Prize, премия «Лидеры ИИ», премии для молодых ученых от Академии Наук, награды от GitVerse и др.), но есть куда расширяться. Должны быть, конечно, и массовые премии, и «элитные». Главное — чтобы за всем этим стояла содержательная часть и не было излишней бюрократии.

Какие направления исследований и темы в области научного open source вы считаете наиболее актуальными? Возможно, у вас есть планы в этом отношении?

Как исследователю в области ИИ, мне в первую очередь интересны перспективы автоматизации анализа и генерации кода для открытых научных проектов. Несмотря на всю мощь современных языковых моделей, пока эти задачи не решаются «в лоб». Наибольшие перспективы, на мой взгляд, тут находятся в области мультиагентных систем на основе LLM, которые позволяют в какой-то мере имитировать процесс разработки ПО людьми-экспертами. Интересны, конечно, и исследования «социальных сетей», возникающих вокруг научного опенсорса, динамики популяризации проектов на платформах вроде GitHub. Также сейчас особенно актуальны тематические бенчмарки, так как важно не только создавать новые методы и модели, но и правильно тестировать их. Задачи кодогенерации для научного ПО — не исключение.

В научной работе все более значимым становится вопрос воспроизводимости исследований. Могли бы вы рассказать, как ученые подходят к его решению в мировой и российской науке? Есть ли характерные сложности в зависимости от направления исследований? Что можно сказать о российской специфике?

В целом, важность воспроизводимости понимают все (хотя, конечно, мой опыт более специфичен для AI/ML). Почти все статьи на топовые конференции так или иначе имеют ссылки на код и данные (если этому не препятствует политика компаний, в которых работают авторы). Но практика показывает, что часто воспроизвести результат статьи, даже имея код, — большой труд. Нюансов множество: от настройки окружения до понятной только самому автору структуры кода. Поэтому проблема обычно даже не в том, чтобы один в один воспроизвести тот же результат, что показан на графике в статье (хотя это тоже очень важный момент), а в том, чтобы в целом иметь возможность переиспользовать результат для каких-то своих задач.

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

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

В одном из материалов по теме вы говорили, что научным open source-разработкам свойственны проблемы с документацией. Чтобы поспособствовать их решению, вы с коллегами подготовили базовые рекомендации. Планируете ли вы продолжать работу в этом направлении? Чем было бы полезно дополнить свод лучших практик?

Несмотря на то, что различно рода туториалов сделано уже очень много (и встречаются очень интересные и качественные), я действительно считаю наш труд по подготовке руководств именно для ниши «научного опенсорса» весьма полезным. Зачастую у проблем, возникающих среди научных команд, своя специфика, и те моменты, которые очевидны для профессиональных разработчиков ПО, могут быть им внове. Поэтому мы планируем и дальше делиться своим опытом в этом направлении. И тут речь не только о документации — обсуждаем и нюансы с CI/CD, и с общие моменты по структурированию репозитория понятным для пользователя образом. Конечно, делать это только своими силами не особо реалистично, и мы приглашаем всех поучаствовать в развитии проекта. Первый фидбек от сообщества положительный — у репозитория уже более 100 «звезд».

Не так давно вы отметили, что начали разработку открытого Open Source Advisor’а (OSA). Решение должно помочь с оформлением переиспользуемых репозиториев с результатами исследований. Могли бы вы чуть подробнее рассказать о концепции и предполагаемых возможностях инструмента? На каком этапе находится разработка?

Основная идея инструмента — помочь научным командам быстрее и проще выкатывать свои наработки в виде переиспользуемых открытых репозиториев. Фактически, речь идет о идее, близкой к широко известному CoPilot — но не на уровне кода, а на уровне репозитория целиком. Конечно, подобные подходы уже пытается реализовать множество команд по всему миру, но наша фишка именно в фокусе на научный код.

Технически, решение будет основано на уже упомянутых специализированных LLM-агентах, объединенных в мультиагентную систему. На входе — архив с кодом или ссылка на репозиторий. Агенты будут генерировать документацию, переструктурировать файлы с кодом, создавать «обвязку» в виде CI/CD скриптов, анализировать имеющиеся недостатки в реализации и сообщать о них пользователю. Для того, чтобы результаты были максимально конкретные, реализуем RAG по имеющейся документации.

Запустить инструмент можно будет, как используя публичные LLM, так и запуская небольшие локальные модели на своих ресурсах (хотя, конечно, чем лучше модель, тем выше качество). Основной язык для нас Python (из-за его активно использования в ML/DS), но мы хотим реализовать поддержку и других популярных ЯП. Первый прототип планируем выкатить в феврале. Дальше будем тестировать, проверять на проектах из различных областей и дорабатывать. Полноценный релиз можно ожидать осенью.

Как вы могли бы объяснить управленцам российских научных центров и университетов ключевые преимущества работы в формате open source? Зачем им открывать что-то из разработок и технологий? Как встроить этот подход в привычную работу? С чего стоит начинать эксперименты и как их оценивать?

Тут есть несколько возможных мотиваций. Первая — «придание веса» технологическому бренду научного центра за счет создания инструментов, которыми реально пользуются в сообществе. Это в перспективе позволит привлечь и коммерческие проекты по созданию производных решений для нужд заказчиков.

Вторая — обеспечение развития своих проектов за счет вовлечения сообщества. Большинство инструментов, используемых в AI/ML, уже невозможно создать небольшой группе разработчиков (например, у pytorch более 3,5 тысяч контрибьюторов и миллионы пользователей). Поэтому вовлечение внешних разработчиков и пользователей-тестировщиков во многих случаях является критичным для реализации чего-то реально востребованного.

Еще один важный плюс открытого кода в науке — возможность подкреплять им заявки на гранты и проекты. В том же РНФ пусть и нет показателей вида «открытая библиотека, 1 шт», но обещание оформить результаты в таком виде экспертами воспринимается как признак серьезности намерений. Позитивный отклик опенсорсная реализация обычно находит и у рецензентов научных статей.

На мой взгляд, в научной среде эффективнее всего начинать выходить в опенсорс не «указом сверху», а силами энтузиастов. Пусть это будет даже небольшой проект, но интересный его авторам, которые готовы вкладывать время и силы в его развитие и продвижение. При наращивании [масштабов], конечно, без поддержки организации не обойтись.

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

Могли бы вы порекомендовать пару книг или исследований для погружения в специфику научного опенсорса и проблематику воспроизводимости исследований?

Есть небольшая обзорная книга «Open Source. Разработка программ с открытым исходным кодом» — может быть хорошим стартом для тех, кто пока не знаком с этой областью. Если говорить о разработке больших проектов, то практика показывает, что выводы из классического «Мифического человеко-месяца» Брукса все так же актуальны.

Много интересных статей выходит по «социальным» аспектам открытой разработки. Как пример, могу привести работы Хадсона Борхеса  — «Understanding repository starring practices in a social coding platform», «How do developers promote open source projects».

Что же до исследований по воспроизводимости — их много: «Could machine learning fuel a reproducibility crisis in science?», «Improving reproducibility in machine learning research», «Leakage and the reproducibility crisis in machine-learning-based science». Область AI/ML развивается очень динамично, а значит, и у проблем обеспечения воспроизводимости (и технических, и концептуальных) возникает все больше новых аспектов.