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

Один из способов преодолеть этот кризис ― открывать код исследований. Так какой-нибудь программной библиотеке, разработанной для решения научной задачи, можно дать вторую жизнь за пределами создавшей ее лаборатории. Поэтому мы в ИТМО сделали ставку на открытый исходный код. В этой статье расскажем, почему, на наш взгляд, ученым стоит выбирать опенсорс, что именно мы делаем и каких результатов достигли.

Привет, Хабр! Меня зовут Николай Никитин. Я руковожу фронтирной лабораторией в Университете ИТМО и одновременно выступаю энтузиастом и лидером сообщества ITMO OpenSource, созданного в нашем университете.

Как научная команда NSS Lab мы занимаемся ML и искусственным интеллектом ― разрабатываем открытую экосистему методов и алгоритмов машинного обучения для научных исследований. Эти инструменты помогают автоматизировать применение методов искусственного интеллекта для решения задач из разных областей науки и техники, и, что самое главное, открыты для всех — ими пользуются не только исследователи из ИТМО, но и научные команды в России и по всему миру. 

Особенность нашего направления в том, что в отличие от той же физики, где эксперименты «материальны», тут основной результат ― это программный код. Казалось бы, это открывает широчайшие возможности воспроизводимости: код (и сопутствующие ему модели, данные) достаточно просто выложить и любой желающий сможет его скачать, запустить у себя и проверить результаты. Но не все так просто…

Что такое воспроизводимость и почему с ней проблемы

Темпы развития computer science и искусственного интеллекта очень сильно выросли. Множество впечатляющих результатов достигается каждый день ― создаются алгоритмы, обучаются модели. Однако с их воспроизводимостью не всё гладко. Традиционно, воспроизводимость подразумевает возможность повторить научный результат, описанный в публикации. Но можно трактовать это понятие в широком смысле ― как возможность использовать данный результат на практике и в отрыве от исходного автора (иначе это можно назвать «коммодитизацией» научного результата). 

Как правило, научная работа в сфере ИИ представлена в виде статьи или препринта с кодом. Данные для обучения и валидации выкладываются далеко не всегда. Эта позиция понятна. Например, если речь идет о больших моделях, то эти данные могут стоить больших денег ― таким мало кто стремится делиться.

Даже если есть данные для обучения и код, и мы таким образом можем воспроизвести результаты авторов статьи ― текст статьи далеко не всегда отвечает на вопрос, как именно перенести решение на другие задачи. Код не всегда легко модифицировать ― ученые не лучшие разработчики ПО, у них своя специфика. Нельзя ожидать от небольшой научной группы, сфокусированной на своем исследовании, легко читаемого и покрытого тестами кода с прекрасной документацией, как у команд из бигтеха. То, что очевидно опытным разработчикам, может быть им просто незнакомо. Так что репозиторий, выложенный вместе со статьей, не всегда хорош с технической точки зрения, так как цель авторов ― не в создании продукта, а в проверке гипотезы. 

А еще в этой сфере много legacy. Многие научные проекты стартовали десятилетия назад и до сих пор разрабатываются на популярных тогда языках ― том же Fortran. Причем, это может быть топовое решение в своем узком сегменте, например, для моделирования динамики океана процессов (речь о модели NEMO Ocean). И скорее всего, команда никогда не заменит Fortran ― не хватит ни времени, ни финансирования (в конце концов, ученым обычно дают деньги на науку, а не на написание кода).

В итоге интересных результатов много, а что с ними делать ― не всегда понятно. 

Как можно повысить воспроизводимость

Естественно, я не первый, кто пишет об этой проблеме. О воспроизводимости в широком смысле активно шла речь еще в середине прошлого века, причем не только в области искусственного интеллекта. И как раз в опыте смежных сегментов науки и техники можно найти проверенные временем работающие решения проблемы.

Очевидно, что активно используются те идеи, у которых есть качественная реализация, где решения соответствуют актуальному технологическому стеку, где присутствует документация, позволяющая разобраться в происходящем человеку со стороны. Отчасти такое есть и в области ИИ ― например, агрегаторы воспроизводимых публикаций. Для размещения на таком ресурсе статья должна обязательно иметь ссылку на опенсорсную реализацию. В некоторых специализированных журнальных треках (например, трек “Open Source Software” в престижном Journal of Machine Learning Research) статью даже не будут рассматривать к публикации, если контрибьюторов и пользователей у проекта мало или последний коммит сделан год назад.

В целом нужно смотреть шире на то, чего мы достигли в сфере опенсорса в областях, не связанных с наукой ― в том же системном программировании, разработке различных открытых приложений и т.п. Там есть те же проблемы, что и в наших научных исследованиях: позиционирование проекта, поиск контрибьюторов, которые помогут развивать код дальше. И решаются они через создание открытого сообщества вокруг инструмента.

К сожалению, лучшие практики из мира open source пока еще плохо внедрены в open source научный ― во многом потому, что решаемые в нем задачи более сложные. Зачастую, чтобы разобраться в задаче и понять, как работает решение, нужно сначала углубиться в математику, лежащую в основе решения.

Успешные опенсорсные научные проекты есть, но в основном они держатся на энтузиастах, которые хотят обеспечить переиспользуемость своего труда. Часто научные решения имеют формат пет-проекта, предназначенного для демонстрации навыков и строчки в резюме. Но на мой взгляд, научный опенсорс должен быть масштабнее. И это не только моё мнение ― множество R&D-подразделений бигтех-компаний выкатывают в опенсорс свои решения как в России, так и за рубежом, обеспечивая им тем самым не только внутренний, но и потенциальный внешний рост.

Несмотря на наличие перечисленных трудностей, у процессов разработки научного опенсорса есть и преимущества:

• Здесь нет интереса заказчика скрыть детали, нет строгих требований к архитектуре и совместимости с корпоративным стеком, да и сама идея в основе работы, как правило, довольно атомарна ― например, придумали и выложили новый алгоритм обучения глубоких моделей. Если код доступен и совместим с существующими библиотеками, его будут использовать, особенно если удалось сравнить новое решение со старым, используя бенчмарки.

• Выложенный код обеспечивает более прочную позицию автора статьи в дискуссии с коллегами. Как рецензент, я часто напоминаю авторам, что нужно выкладывать код. Во многом это win-win для ученых ― помимо помощи сообществу, опенсорс обеспечивает создание «бренда» исследования.

• Мир научного опенсорса более лояльный. Когда код выкладывает крупная корпорация, сообщество настроено искать в нем «косяки» и максимально публично их обсуждать. В научной среде так не принято, здесь больше доброжелательности.

Как мы внедряем лучшие практики разработки в научный опенсорс в ИТМО

В отличие от многих других научных центров, в центре «Сильный ИИ в промышленности» ИТМО ставку на открытый код сделали сразу. Начинали мы несколько лет назад с достаточно типовой для области машинного обучения ситуации. Открытый код есть, но им никто не пользуется: внешних участников минимум, популяризации нет ― максимум ссылка в статье. И в новых проектах мы стали придерживаться курса на продвижение наших опенсорсных идей.

Мы выработали best practices оформления и выкладывания наукоемких опенсорсных библиотек.

Опыт развития сообщества в ИТМО показал, что у научных команд проблемы довольно типовые. Коммерческие разработчики, как правило, все это знают, но научные команды просто не сталкивались с такими вопросами, поэтому для них мы создаем отдельные туториалы и рекомендации: «Как написать readme», «Как реализовать автотесты» и т.п. Поэтому полезны руководства, которые помогает сторонним пользователям понять, как использовать наш опыт для своих задач. 

Например, общие рекомендации по структуре проекта (на примере Python-проектов) довольно прямолинейны:

• Использовать  PyPi для релиза основного ядра кода.

• Чтобы не захламлять основной репозиторий, можно создать отдельный репозиторий для туториалов по каждой версии (например, в формате Jupyter Notebook).

• К каждой статье стоит создавать отдельный репозиторий со всеми данными, необходимыми для воспроизведения эксперимента ссылкой на конкретную «замороженную» версию фреймворка.

Разработанные руководства мы собрали в отдельный репозиторий. 

Много сил вкладываем в популяризацию. 

Целевая аудитория научных проектов не так велика, как хотелось бы. Для узкого по тематике научного проекта может быть необходимо найти конкретную команду на другом конце мира, которая воспользуется наработками. 

Мы предпринимаем такие шаги:

• Пишем про созданные библиотеки на Хабр. В России это основная площадка, куда можно публиковать лонгриды про научный опенсорс. Здесь можно получить охваты в тысячи и даже десятки тысяч просмотров (если повезет, конечно). 

• Переводим эти статьи для публикации в Towards Data Science, где охваты уже стабильно около десятков тысяч и выше. Это тематический портал, посвященный вопросам машинного обучения, так что аудитория более заинтересованная.

• Выкладываем на YouTube и других площадках туториалы, выступления и прочие видеозаписи по теме опенсорса. Просмотров у рядового видео немного, но и они постепенно конвертируются в заинтересованных пользователей, а заодно помогают проще войти в тему.

• Ведем Telegram-чаты и каналы по теме открытого ПО, где можно задавать свои вопросы, получить помощь в решении проблем или обменяться опытом по созданию открытых проектов. 

• Вовлекаем студентов в формате опенсорс-клуба. 

• Выступаем на профильных мероприятиях. В России сейчас есть опенсорс трибуны на крупных конференциях, и выступление там ― отличный способ презентации проекта.

• Делаем аналитические исследования в области опенсорса. 

Каких результатов мы достигли

Первый митап «Научный опенсорс» мы провели в конце 2022-го, а сами проекты делаем с 2019 года (тогда стартовал Национальный центр когнитивных разработок ИТМО). Чего получилось достичь?

Популяризировали разработки ИТМО. 

Проекты, которые мы создаем в Институте ИИ ИТМО, используются именно как открытые библиотеки. Этот код запускают, применяют для своих задач и контрибьютят в него. В общей сложности у нас уже более 30 библиотек и фреймворков в разных областях, которые используются довольно активно ― у них более полутора тысяч звезд, сотни тысяч скачиваний из 40 стран. Для академического открытого кода это довольно много.

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

Благодаря популяризации FEDOT постоянно цитируется в обзорах на эту тему. Со всего мира нам приходят десятки кейсов его использования, в том числе от незнакомых нам людей.

При этом в ИТМО открытые проекты создает не только наша команда. 

Упростили вкатывание в проекты новых людей.

У научной разработки есть своя специфика. Зачастую, ядро команды ИИ ― два-три фуллтайм исследователя уровня аспирантов, которые совмещают написание кода со своей основной научной деятельностью. А большую часть работы над кодом проектов выполняют стажеры ― зачастую это студенты, которые пишут выпускную работу в таком формате. Этих стажеров надо вводить в курс дела.

Чтобы процесс двигался, нужно заботиться о координации действий стажеров. Нужны налаженные процессы по индивидуальному менторингу и полная прозрачность issues в GitHub. Для научных проектов это не очень характерно. Также мы проводим дополнительные очные и онлайн-встречи, создаем чаты в Telegram, где могут общаться все контрибьюторы.

Кстати, стажеры не только разрабатывают новые инструменты, но и активно используют их, например, при участии в хакатонах ― включают опенсорс в свои решения поставленных задач. Часто они занимают призовые места и это дает дополнительную популяризацию инструменту. 

Обеспечили долгосрочную поддержку многим проектам

В опенсорсе встречается плохая практика, когда внешних пользователей, которые создают issue или пул-реквесты, просто игнорируют ― им даже не отвечают. Это приводит к тому, что даже очень полезная библиотека перестает развиваться ― сами авторы теряют к ней интерес, а сторонние контрибьюторы к этому моменту так и не появляются. В лучшем случае у библиотеки будет форк, но в итоге проигрывают все. 

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

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

Для России это сообщество достаточно уникально и масштабно (хотя нельзя не упомянуть сильные open-source сообщества на факультете компьютерных наук ВШЭ и в центре научного программирования МФТИ. Сообщество позволяет научным командам получить менторинг и найти контрибьюторов для своих проектов.

Вот запись доклада «Как обеспечить воспроизводимость научных исследований в AI/ML с помощью Open Source» с конференции Highload++, где говорю об этом подробнее 

Но не все так просто

Конечно, есть и определенные нюансы.

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

В этой сфере нет прямой связи: «вложил усилия ― получил результат». Нужно постоянно вспоминать про общую картину.

Хотя «звезды» на GitHub часто критикуют, но так или иначе их используют для оценки популярности. Часто кажется, что усилия по написанию текстов не окупаются с точки зрения конверсии в «звезды» и другие метрики. Однако, на долгосрочном горизонте хорошо написанные посты приносят однозначную пользу.

Приходится в какой-то степени нарушать сложившийся порядок вещей. 

Для научных вопросов актуальна проблема контекста. Сначала необходимо разобраться в предметной области или математических основах. Поэтому приходится максимально уходить от сложившейся научной традиции говорить «сложным» языком. Писать научно-популярные и популяризирующие статьи, прикладывать ролики и GIF-ки. Бывает, что авторам приходится оставлять и личные контакты, чтобы консультировать потенциальных контрибьюторов.

Проекты двигаются не так быстро, как хотелось бы. 

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

Деньги на опенсорс дают неохотно. 

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

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

Они не верят, что будет длительная поддержка, что через год-другой эта команда все еще будет работать над проектом. И такие опасения зачастую оправданы.  Поэтому часть нашей работы заключается как раз в том, чтобы создавать устойчивую команду с некой преемственностью, на основе которой можно было бы строить длительные проекты. И мы в ИТМО стараемся создавать взаимосвязанную экосистему, чтобы одни проекты использовали другие. Получается, что разрабатываемые библиотеки нужны хотя бы соседним командам в том же университете. Так шансов на привлечение новых контрибьюторов больше.

Промежуточные итоги

Самым сложным было стартовать. Но мы сдвинули это колесо, хотя путь не был простым. Мы убедили руководство сделать ставку на открытый код, инвестировать в это деньги. Доказывали, что нашему Центру Сильный ИИ в промышленности (который в 2019-2020 годах только появился) нужна площадка для демонстрации компетенций, в том числе и для привлечения впоследствии коммерческих заказчиков.

Кажется, ставка на открытый код сыграла очень неплохо. Я обратил внимание, что нашему примеру следуют и другие научные школы, поскольку увидели на этом пути потенциал для роста. Например, коллеги из «Открытый код ФКН» рассказывают о нас в своих презентациях.

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

Дополнительные материалы

Про опенсорс в ИТМО

Наш канал и чат про научный опенсорс в Telegram: @scientific_opensource