Исследование опенсорс-инструментов в области ML/Data от ИТМО: выводы и инсайты23.10.2024 10:31

Новые инструменты в области ML/Data меняют правила в опенсорсе ― позволяют создавать решения быстрее и дешевле и это трансформирует существующие практики. Мы в центре «Сильный ИИ в промышленности» ИТМО задались вопросом: куда мы уже пришли и как эта отрасль изменится в ближайшие годы. А чтобы на него ответить, провели масштабное аналитическое исследование open source ― посмотрели как разработки крупных компаний, так и университетов, поговорили с экспертами рынка и проанализировали выложенный на GitHub код. На Хабре уже выходила новость с перечнем основных игроков и некоторыми результатами.

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

На что мы смотрели

Мир open source многогранен и мы не пытались охватить его целиком. Смотрели в основном на инструменты на стыке работы с данными и машинного обучения ― то есть не на софт для конечных пользователей, а на инструменты для разработки и научных исследований.

Почему так? Авторы исследования ― сотрудники центра «Сильный ИИ в промышленности» ИТМО. У нас большой опыт создания ПО с открытым кодом в сферах ИИ/ML/DS и его применения в реальных проектах. 

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

Мы выделили несколько категорий: (1) ML и AutoML; (2) математическое обеспечение; (3) Инфраструктура; (4) Визуализация и BI; (5) Хранение данных; (6) MLOps и LLMOps. Общепринятой таксономии внутри ML/Data нет, поэтому мы ориентировались на мнения экспертов и укрупненные теги репозиториев на GitHub. Чтобы было понятнее, для каждой категории дали пояснение и несколько примеров. В них мы подобрали представителей разных «уровней» опенсорса ― от разработок гигантских корпораций до академических решений и успешных пет-проектов.

В этом исследовании мы трактуем «используемость» несколько уже (и не ожидаем, что эксперт зачитает нам весь requirements.txt). Речь о ключевых в стеке решениях, работа с которыми не сводится просто к их скачиванию. Использование многих опенсорсных проектов связано с плотным изучением документации, созданием issue, общением с авторами, участием в них в роли контрибьюторов. Именно такие сценарии использования нам наиболее интересны.

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

Эксперты, которые участвовали в исследовании и давали комментарии:

Параллельно проанализировали открытые репозитории GitHub. Хотя в отрасли появляется интерес к другим платформам, сейчас это самая популярная площадка ― основная, куда выкладываются разработки. Сканируя репозитории, мы оценивали «количественные» показатели ― количество контрибьюторов, длительность существования репозитория, количество файлов с кодом и кода как такового, наличие документации и тестов (этот момент, кстати, инициировал интересную дискуссию в нашем чате о том, стоит ли вообще выделять тесты в отдельную директорию), количество форков и issues и т.п. Мы понимаем, что это не дает детальной картины, но позволяет составить общее представление. 

Пример фрагмента данных, собранных по одному из репозиториев (общая информация, критерии степени используемости проекта, критерии степени развития проекта)

В итоговый рейтинг наиболее активных в ML/Data-опенсорсе компаний мы включили 10 участников. Первое место занял Яндекс ― за большое количество активно развивающихся open source проектов, охватывающих все тематические категории, лучшие показатели используемости этих проектов в России по сравнению с другими российскими компаниями, высокий уровень качества реализации репозиториев и участие в развитии сообщества через организацию мероприятий. Также в первую пятерку вошли Сбер, Т-Банк, Avito и МТС. Хотя любое ранжирование тут, разумеется, условно ― в различных нишах есть свои сильные игроки (например, нельзя недооценивать вклад PostgressPro в экосистему Postgress).

Вот компании, которые вошли в топ. Но список не претендует на полноту — в качестве контрибьюторов опенсорс-проектов в России выступает огромное число компаний и частных лиц

Что происходит в open source

Хорошие новости

Исследование показало, что open source в России действительно активно развивается. Количество участников движения открытого исходного кода растет: появляются новые сообщества ― как технологические (например, у платформы GitVerse или Yandex for Developers), так и академические ― тут можно вспомнить про опенсорс-сообщество ИТМО, которое разрослось до более чем 1000 участников, или сообщества МФТИ и ВШЭ. Другой пример ― Институт системного программирования РАН, который активно участвует в развитии PyTorch в части исправления ошибок, выявленных с помощью разработанных в институте статических и динамических анализаторов.

Целый ряд крупных компаний делают ставку на открытый код, и уже есть достойные решения ― от давно развивающихся и всемирно известных (например, CatBoost) до сравнительно новых, но активно завоевывающих позиции ― таких, как LightAutoML или etna.

Пример гео-привязки github-звезд от пользователей CatBoost по открытым данным

«Культура использования опенсорсных инструментов у нас хорошо развита. Сложно сказать, что именно изменилось за последние пять лет, так как я сам слежу за этой областью не более трех лет. Однако в рамках моего домена появилось множество библиотек с различной спецификой, и самому старому фреймворку уже около пяти лет. Похоже, что такой тренд наблюдается и в других областях: за последние пять лет для каждой задачи был создан набор качественных открытых инструментов», ― Александр Чиков, тимлид, Т-Банк.

В открытом доступе публикуются не только код, но и модели (например, семейство моделей Kandinsky, модель YaLM), данные (например, Golos и Dusha от SberDevices, исследовательские данные Яндекса), бенчмарки (отличный пример ― LLM-бенчмарк MERA, созданный консорциумом индустриальных компаний в сотрудничестве с академическими партнерами). При этом продвигают open source не только крупные компании и университеты, но и множество энтузиастов, реализующих собственные проекты.

«Я предпочитаю делить опенсорс на несколько уровней. На первом уровне находятся крупные проекты-гиганты, такие как ClickHouse, YDB, YTsaurus, Tarantool. На следующем уровне — более простые проекты с относительно небольшими командами разработчиков, но которые уже известны в определенных кругах, например, Testplane. И, наконец, существует так называемый «пушистый хвост опенсорса» — это мелкие опенсорсные проекты, которые, несмотря на свою скромность, имеют свою ценность и значимость. Они могут быть популярны и широко известны в узких сообществах, как, например, проект Типограф», ― Сергей Бережной, директор по взаимодействию с разработчиками, Яндекс.

Опенсорс как таковой развивается не только благодаря тому, что появляются новые проекты (как от крупных игроков, так и от энтузиастов), но и благодаря поддержке сообществ. Она может выражаться в виде организации профильных мероприятий (здесь можно вспомнить, например, Open Source Jam от Яндекса, GigaConf от Сбера, митапы по ML Т-Банка и митапы «Научный опенсорс» от ИТМО).

«Радует, что компании активно занимаются организацией профильных мероприятий, связанных с инструментами разработки. В последние годы наблюдается рост популярности подкастов и вебинаров, которые позволяют разработчикам и энтузиастам углубиться в тему и обменяться опытом. Таким образом, растет интерес к инструментам, которые не только создаются в компаниях, но также и независимыми разработчиками», ― Александр Белоцерковский, технологический евангелист GitVerse/СберТеха.

«Базовый» открытый стек для отрасли DataScience и ML уже сформировался. Сюда входят CatBoost, Hadoop, PyTorch и другие решения. В ML почти весь популярный инструментарий опенсорсный.

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

«Малый размер рынка усложняет внедрение результатов исследований и разработок, и при сопоставимом качестве это приводит к ухудшению ситуации. На энтузиазме много не сделаешь, и это блокирует развитие. Есть шанс для российских команд выйти на международный рынок, например, в Латинскую Америку, Африку или Индию. Ориентировать только на рынок внутри страны малоперспективно», ― Максим Савченко, управляющий директор, руководитель Центра инструментов машинного обучения Лаборатории AI, Сбер.

Плохие новости

В целом наш рынок open source «разорван» ― у нас есть решения от крупного бизнеса и индивидуальных разработчиков, но провален сегмент решений среднего размера.

«Главная проблема опенсорса в России ― это отсутствие инфраструктуры для «проектов среднего размера». Компании радостно вкладываются во что-то большое и международное вроде Postgres. Маленькие проекты, которые делаются одним человеком хорошо растут силами отдельных разработчиков и студентов. А вот средние проекты, которые требуют команды в 3–4 человека, делать особенно негде. В Европе и Америке с этим справляются фонды вроде Apache и Eclipse, но в России ничего похожего нет. Роль таких фондов могли бы играть вузы, но даже в ведущих вузах финансирование опенсорса крайне низкое», ― Александр Нозик, директор центра научного программирования, МФТИ.

Многие популярные решения действительно развиваются при активной поддержке крупного бизнеса. Но с участием компаний не все так просто. 

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

• Есть сложности с лицензиями. Бизнес не все открытые решения может использовать у себя, а значит не все из них будет развивать.

• На отдельно взятом российском рынке опенсорсу не хватает системности и масштаба. А крупные компании в большей степени смотрят на зрелость продуктов, чем на факт открытия кода.

• Открытые проекты хромают с точки зрения документации, поддержки и совместимости с другими решениями.

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

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

«Приведу пример: однажды у нас возник вопрос о возможности перехода на Playwright ― это опенсорс-инструмент для визуального тестирования интерфейсов. Мы провели обсуждения с командой Playwright, однако, к сожалению, наши взгляды на сотрудничество не совпали. Им не требовалось то, что было необходимо нам. Например, нам нужно тестировать в более широком диапазоне браузеров, чем это предусмотрено в самой системе Playwright, а также учитывать большой объем и поток изменений, с которыми мы работаем», ― Сергей Бережной, директор по взаимодействию с разработчиками, Яндекс.

Развивать open source независимо тоже не так просто.

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

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

«В России, к сожалению, очень мало опенсорсеров и разработчиков системного программного обеспечения, а также специалистов в области машинного обучения», ― Максим Савченко, управляющий директор, руководитель Центра инструментов машинного обучения Лаборатории AI, Сбер.

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

Как в сообществе, так и в крупных компаниях разработка часто продвигается конкретными энтузиастами, и их мало. 

«Существующие инициативы завязаны на конкретных людях. Поддержка исходит от верхнего и среднего звена, а также от отдельных техноэнтузиастов. Команды небольшие, и проблема заключается в отсутствии системы — все держится на горстке энтузиастов», ― Максим Савченко, управляющий директор, руководитель Центра инструментов машинного обучения Лаборатории AI, Сбер.

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

«Не хватает четких подходов к выстраиванию устойчивой экономики опенсорса. В основном гранты предоставляются на создание проектов, но не на их поддержку. Возникает вопрос: как измерять пользу и за что следует платить разработчикам?», ― Сергей Бережной, директор по взаимодействию с разработчиками, Яндекс.

Как можно было бы решить эти проблемы?

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

• Более тесное сотрудничество бигтех-компаний между собой и с академией ― чтобы обмениваться опытом и наработками;

• Совместная разработка опенсорс-решений вместо создания всё новых «корпоративных» проектов ― чтобы сработал эффект масштаба;

• Вместо маркетинговых мероприятий формата «всё обо всём» ― больше специализированных технических и научных активностей;

• Инвестиции в студентов, обеспечение их раннего вливания в опенсорс-движение ― для обеспечения массовости;

• Негосударственная грантовая поддержка перспективных открытых проектов (в том числе в формате пожертвований).

«На мой взгляд, есть еще много возможностей для развития форматов взаимодействия в этой области. Одно из наиболее перспективных направлений — devroom-ы, посвященные крупным open source проектам. Такие мероприятия обеспечивают глубокое погружение в технологии и позволяют участникам не только ознакомиться с проектами, но и задать вопросы непосредственно разработчикам. Например, уже не один хакатон прошел на базе платформы для работы с исходным кодом GitVerse, где участники выполняли задания. Подобные активности способствуют эффективной совместной работе над обучающими проектами. Также важно обратить внимание на формат питчей молодых проектов, в том числе и open sourse, на крупных конференциях. Подобные инициативы требуют тщательной проработки, но их потенциал для развития огромен», ― Александр Белоцерковский, технологический евангелист GitVerse/СберТеха.

Что дальше

Сейчас активно обсуждаются идеи замены части команды разработки на ИИ-агентов. Это должно подталкивать интерес к открытым инструментам LLMOps и AutoML. И эти инструменты действительно развиваются.

«Перспективы применения искусственного интеллекта в разработке и опенсорсе представляют собой сложную картину. Возможно, мы столкнемся с «хоккейной клюшкой» сингулярности, когда изменения произойдут стремительно и неожиданно. Есть вероятность, что мы доживем до технологической сингулярности в течение ближайших 10–20 лет. У нас уже есть база в виде больших языковых моделей (LLM), но их необходимо контролировать и задавать им четкие задачи. Возможно, исчезнет часть рутинной работы программистов, а разработчики опенсорса займут более высокие позиции, такие как CTO или руководители разработки», ― Сергей Бережной, директор по взаимодействию с разработчиками, Яндекс.

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

«Что касается актуальных инструментов, здесь важное место занимает AI-ассистент разработчика. Мы первыми среди российских git-платформ внедрили такой инструмент в платформу GitVerse. На данный момент AI-ассистент автоматизирует процессы, дополняет и оптимизирует код, исправляет ошибки, а также проводит аналитику и оценку трудозатрат», ― Александр Белоцерковский, технологический евангелист GitVerse/СберТеха.

А что можно было бы улучшить в самом исследовании?

О нашем исследовании написали довольно много СМИ (например, РБК, Ведомости, РИА Новости) и технологических telegram-каналов (включая несколько каналов-миллионников), а также упоминали почти все компании, проекты которых попали в топ. Большинство отзывов были позитивными, многие комментаторы давали предложения, как улучшить исследование ― от уточнения формулировок до добавления новых продуктов.

О нас пишут

«Считаю, что подобные исследования крайне важны для развития сообщества. В мире уже много лет проводится анализ опенсорс-сферы, в России же только делаются первые шаги. Мы рады, что ИТМО внес свой вклад в познание ML-ниши опенсорс-проектов, а ранее активно участвовал и в нашем исследовании. Результаты, опубликованные ИТМО, могут привлечь новых разработчиков в ML-комьюнити и сподвигнуть проекты к кооперации», — Тимофей Кочкар, шеф-редактор исследования опенсорса для N + 1.

Значит ли это, что мы всё сделали идеально? Конечно, нет. Каких-то вопросов мы касаться не стали, на что-то не хватило времени, что-то просто упустили. Поэтому сейчас мы решили кратко описать моменты, как могли бы улучшить и развить эту работу:

1) Повысить прозрачность расчета количественных метрик

Чтобы расчеты было проще проверить, стоило сразу реализовать end-to-end пайплайн для сбора и обработки данных, генерации таблиц и картинок, валидации результатов. Это позволило бы избежать обидных накладок с рассинхронизацией значений, повысило воспроизводимость и помогло читателям предлагать свои проекты, которые, по их мнению, следовало бы учесть. Текущие материалы выложены в открытом репозитории (ссылка).

2) Охватить не только код, но и модели и данные

Изначально мы решили ограничить исследование только открытым ML/Data-инструментами на GitHub. Но всё-таки без анализа используемости данных и моделей (включая те, что выложены на huggingace) часть вопроса осталось раскрытой не до конца ― попробуем вернуться к этому в будущем.

3) Глубже проработать критерии «используемости»

Использованная методика, основанная на звездах, issue, PR-ах и скачиваниях, дает только очень грубую оценку. Конечно, на допустимые варианты формирования критериев сильно влияет доступность открытых данных с GitHub и производных сервисов (мы использовали сервисы pepy.tech для скачиваний с PyPI, GitHub Star History ― для звезд, OSS Insight ― для прочих данных). Но если более детально рассмотреть активность участников (публичную переписку, код-ревью, роли участников), то можно бы было бы точнее оценить востребованность ряда проектов. 

Заметим, какого-то общепринятого критерия пока не смог предложить никто, а анализу пригодности имеющихся посвящены даже научные работы (приведем те, с которыми мы познакомились в ходе подготовки исследования: «The Fault in Our Stars: An Analysis of GitHub Stars as an Importance Metric for Web Source Code», «What«s in a GitHub Star? Understanding Repository Starring Practices in a Social Coding Platform», «Understanding the Factors That Impact the Popularity of GitHub Repositories».

Поступали ли резко критические отзывы? Конечно, да, и они тоже полезны.

Так, один из комментаторов пишет:»Собрали два десятка ссылок на известные оперсорс проекты, написали парсер, который вытащил количество звезд и ишшю, построили по этим цифрам бессмысленную диаграмму». Но, одновременно, другой комментарий как раз про то, что даже проекты компаний, попавших в топ, совершенно не на слуху:»А этот банковский опенсорс, он сейчас с нами, в этой комнате? Ну напишите уже хоть во что они вкладывают». Значит части аудитории такой анализ однозначно полезен.

Аспекты исследования, связанные с деятельности ИТМО в рамках опенсорс-сообщества, мы обсуждали на недавнем Scientific Open Source Meetup №8, который проводился совместно с компаний OpenScaler и Центром научной коммуникации ИТМО. Также совсем Николай Никитин расскажет об исследовании в рамках Yandex Open Source Jam, которое пройдет в Петербурге уже сегодня — 23 октября.

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

Над материалом работали:

• Николай Никитин ― к.т.н, лидер сообщества ITMO.OpenSource;

• Андрей Гетманов ― опенсорс-энтузиаст, исследователь в области LLM и AutoML;

• Ирина Деева ― к.ф.м.н, руководитель проекта по развитию открытого кода на факультете цифровых трансформаций ИТМО;

• Юрий Каминский ― аспирант, исследователь в области LLM, руководитель студенческого опенсорсного клуба;

• Кирилл Федорин, Иван Рубин ― студенты ИТМО.

© Habrahabr.ru