Промышленные записки
5 вещей, которые я узнал как создатель платформы машинного обучения с открытым исходным кодом
Если вы начинающий создатель или разработчик фреймворков машинного обучения с открытым исходным кодом, эти советы могут оказаться полезными.
Создать успешный проект с открытым исходным кодом сложно, особенно в области науки о данных / машинного обучения / глубокого обучения. Большое количество проектов с открытым исходным кодом никогда не используется, и от них быстро отказываются. Как создатель Flow Forecast, системы глубокого обучения для прогнозирования временных рядов с открытым исходным кодом, мне приходилось сталкиваться как с успехами, так и с ошибками. Вот подборка советов, которые у меня есть для начинающих создателей / разработчиков фреймворков машинного обучения с открытым исходным кодом.
- Документация, документация и документация
Наличие хорошей документации, руководств и руководств по началу работы, вероятно, является одним из наиболее важных аспектов для любой среды с открытым исходным кодом. В то время как в рабочих условиях знания о кодовой базе обычно делятся на собраниях, на уроках и на сессиях парного программирования, в проектах с открытым исходным кодом основным методом обучения является документация, учебные пособия и примеры. Более того, специалисты по обработке данных часто очень заняты, и если ваша документация / руководство по началу работы неясны, они часто переходят на более простой в использовании фреймворк. Часто это верно вне зависимости от обещанных характеристик моделей.
Чтобы помочь людям легко начать использовать ваш фреймворк, я рекомендую иметь простой учебник по началу работы, не вызывающий острых ощущений. Помимо руководства по началу работы вам также понадобится место для более подробной документации по методам и классам. Это полезно как для участников, так и для опытных пользователей. Я обнаружил, что ReadTheDocs хорошо подходит для этой цели. Для проектов в области науки о данных (особенно для проектов с тяжелым машинным обучением) вам также может понадобиться сайт, содержащий концептуальную информацию и информацию о производительности модели. В частности, для FF мы решили использовать Confluence от Atlassian. Это идеальное место для более концептуальной информации и результатов моделирования, не загромождая документацию по коду.
Конечно, на написание и поддержку документации уходит много времени. Так что вам следует уделить этому достаточно времени. Уловка (если ее можно так назвать), которую я обнаружил, заключается в том, что легче всего писать документацию, когда вы пишете код. Чем больше времени проходит, тем более туманными становятся ваши воспоминания о том, что делает код. В конце концов, вы и другие ваши сопровождающие даже не вспомните, что в кодовой базе существует определенная функция. Так что немедленно пишите свои документы!
Еще одна полезная вещь - прежде чем вносить какие-либо изменения в дизайн, нужно создать проектный документ. Тогда проектный документ становится живой памятью об изменениях и причинах их внесения в проект. Еще одна уловка - использовать в VSCode такие расширения, как Python DocString Generator. Они автоматически сгенерируют строки документации в правильном формате для отображения на вашем сайте онлайн-документации.
2. «Если вы построите это, они НЕ придут»
К сожалению, создание хорошей среды науки о данных с открытым исходным кодом не приведет к автоматическому использованию ею людьми. Более того, во многих случаях наиболее популярным становится не самый лучший фреймворк, а тот, в котором больше всего внимания уделяется маркетингу, брендингу и оптимизации ключевых слов. Хотя многие разработчики машинного обучения предпочли бы сосредоточиться только на технической стороне вещей, маркетинг и продвижение - неизбежное зло.
Это то, с чем мы боролись на ранних этапах разработки Flow Forecast. Несмотря на то, что это первый фреймворк временных рядов для поддержки трансформаторов, мы мало продвигали его. Быстро появились и другие фреймворки, которые завоевали большую популярность в социальных сетях. Еще одна проблема, с которой мы столкнулись, заключалась в названии нашего фреймворка. Хотя FF отдает дань уважения корням хранилищ, он иногда сбивает людей с толку и заставляет думать, что мы всего лишь основа для прогнозирования речного стока, а не универсальная система прогнозирования временных рядов. Поэтому я бы порекомендовал с самого начала выбрать достаточно общее название.
Чтобы хорошо продвигать свой репозиторий, я рекомендую регулярно писать статьи на Medium и публиковать обучающие видеоролики. Это может помочь привлечь трафик на ваш фреймворк и заработать звезды. Вы также можете (нечасто) объявлять о крупных выпусках в соответствующих субреддитах Reddit. Выступления на местных встречах - отличный способ рассказать о своей структуре сообществу DS. Большинство встреч всегда ищут новых спикеров и очень поддерживают проекты с открытым исходным кодом. Наконец, также могут помочь обучающие записные книжки с использованием вашего фреймворка по популярным наборам данных Kaggle и соревнованиям.
Хотя звезды на самом деле не должны так много значить (я думаю, что наблюдатели и форки - лучший индикатор), они играют центральную роль в алгоритме рекомендаций GitHub и в том, как другие воспринимают ваше репо. Поэтому важно попытаться со временем накапливать звезды в репозитории. Если вы сможете получить достаточно звезд за короткий период времени, ваш репозиторий также начнет расти, что приведет к еще большему количеству звезд. Не забудьте добавить соответствующие теги в свой репозиторий на GitHub, так как это повысит рейтинг вашего репозитория (на основе звездочек на этом теге).
Проведение периодических мероприятий также может привлечь больше людей к участию в вашем репозитории. В 2020 году мы провели спринт FF в рамках крупных мероприятий PyData Global. В этом году на FF мы планируем провести Хактоберфест-спринт (нажмите для подробностей). Во время этих мероприятий важно быстро отвечать на PR и быть готовым ответить на вопросы, которые могут возникнуть у делегатов. Такие поощрения, как футболки, также могут мотивировать участников предлагать более актуальные элементы.
3. Тестирование
Тестирование является сложной задачей, особенно в области машинного обучения, поскольку большинство моделей машинного обучения явно недетерминированы. Лучше всего начать с простого и использовать стандартные типы модульных тестов (например, проверить, возвращается ли правильная форма, тестировать, цикл обучения проходит от конца до конца). Обязательно включите как модульные, так и интеграционные тесты. Тесты следует запускать с помощью таких инструментов, как CircleCI или Travis-CI. Вы можете использовать CodeCov или другие инструменты для автоматического отслеживания покрытия кода. Когда у вас будет базовое покрытие кода и вы убедитесь, что эти тесты пройдены, вы можете приступить к более сложным тестам.
Для тестирования таких вещей, как валидность теста и циклы оценки, вам может потребоваться создать фиктивную детерминированную модель. Затем вы можете запустить эти функции с фиктивной моделью и небольшим набором данных и убедиться, что расчеты действительно точны. Для моделей вы можете написать относительно недорогие «тесты» сходимости, чтобы убедиться, что модель сходится через несколько эпох. С помощью этих тестов вы можете быть уверены, что ваш код работает правильно.
Возможно, одна из самых сложных и трудоемких форм тестирования - это убедиться, что модель, которую вы переносите на свой фреймворк, соответствует исходным результатам, упомянутым в документе. Это часто требует проведения эксперимента с точными гиперпараметрами и предварительной обработки из бумаги. Эти тесты не могут выполняться как обычная часть CI, так как они займут слишком много времени. Вместо этого их следует запускать только время от времени, чтобы гарантировать, что производительность модели не изменится при серьезных изменениях фреймворка.
4. Очень важно хорошее управление зависимостями и обратная совместимость.
Зависимости - это постоянная проблема, с которой приходится иметь дело при поддержке проекта с открытым исходным кодом. Моя рекомендация номер один - установить версию зависимостей в вашем файле requirements.txt. В противном случае всякий раз, когда зависимость обновляется, это может привести к поломке вашего кода, и вы получите строку сообщений от пользователей, которые задаются вопросом, почему их код внезапно не работает. Dependabot хорош в открытии PR для автоматического увеличения зависимостей, которые затем можно легко увидеть, пройдут ли они CI. Смотрите мою другую статью для получения дополнительной информации.
Еще одна вещь, за которой следует следить, - это управление версиями вашего фреймворка на PyPi и ваши циклы выпуска. Существует простой в использовании рабочий процесс GH, который автоматизирует отправку на PyPi после выпуска. Обычно я стараюсь выпускать релизы в начале каждого месяца (или если я отстаю раз в два месяца).
5. Выберите систему для определения приоритетности проблем / новых функций
Это ведет к следующему этапу создания системы для определения приоритетов проблем. У многих разработчиков ПО с открытым исходным кодом невероятно мало времени. Однако количество ошибок и запрошенных функций часто продолжает расти в геометрической прогрессии. Поэтому важно отслеживать прогресс и решать открытые вопросы. В FF мы экспериментировали с различными инструментами управления проектами (например, JIRA), но в итоге обнаружили, что простые задачи GH и доски проектов работают лучше всего.
Еще одна трудность, с которой сталкиваются разработчики ПО с открытым исходным кодом, - это делегирование работы. Часто разработчики добровольно предлагают реализовать функцию из лучших побуждений, но увязли в другой работе и не могут решить указанную проблему. Вы должны стараться регулярно связываться с разработчиками, особенно по важным вопросам. При необходимости вам следует как можно вежливо передать проблему кому-нибудь еще, чтобы она была решена, если это критично.
Надеюсь, вы нашли это руководство полезным! Не стесняйтесь оставлять любые вопросы или комментарии. Пожалуйста, ознакомьтесь также с другими моими статьями!
