Большинство дата-сайентистов использовали или до сих пор используют notebooks. В чем-то это здорово, но кажется, что дата-сайентисты должны действовать как разработчики. И поэтому с notebooks надо переходить на скрипты, разрабатываемые в IDE.
Команда VK Cloud перевела статью о том, какие преимущества вам даст более активное использование IDE.
Для чего мы используем notebooks и почему это неэффективно
Почему нам, дата-сайентистам, нравятся notebooks
Чаще всего notebooks используют в самом начале проекта по обработке данных: чтобы исследовать возможные варианты, найти доказательство концепции и проверить техническую
- скорость: чтобы запустить новый notebook, нужно несколько минут;
- удобство вычислительных операций: notebook можно запустить на виртуальной машине или в облачной среде;
- простота использования: для проведения тестов не нужны уверенные навыки разработки, а код можно выполнять строку за строкой;
- готовые презентации: графики и текст с разметкой, отображаемые в документе, можно показывать нетехническим командам.
Пример ячейки notebook
Что не так с notebooks
Хотя это интересные функции, мне, как и многим другим дата-сайентистам, использование notebooks мешает внедрять современные практики разработки программного обеспечения.
Большую часть времени (если не сказать всегда) приходится заново создавать код для всего, что попадает в продакшен. Это же двойная работа! Не лучше ли сразу создать хорошую базу, чтобы потом просто вносить изменения, не переделывая весь код заново?
Еще у notebooks есть несколько недостатков:
- нет отслеживаемости;
- нет воспроизводимости;
- нет инструментов для разработки кода: справки для строки документации, проверки Lineage, исправления багов, автозаполнения и многого другого;
- акцент экспериментальной проверки на машинном обучении, а не на тестировании всех технических аспектов решения;
- устранение багов может занимать много времени, особенно при настройке ядра и среды.
Не говоря уже о том, что notebook не подходит для разработки сложных систем и системного анализа.
Поговорим про недостатки notebooks чуть подробнее.
Ненадежная основа для исследований. Работа в notebooks плохо вписывается в научный подход. Даже если команда обращается к точному методу, а такое случается нередко, notebook не облегчает внедрение этого подхода.
Нет отслеживаемости. Во-первых, в notebooks нет поддержки отслеживания хода экспериментов. Они не поддерживают контроль версий. При слиянии возникает множество конфликтов, так что часто вам ничего не остается, кроме как работать в своем notebook в одиночку. В результате команда часто теряет из виду ход эксперимента. Я встречал альтернативную систему отслеживания версий вручную, когда команды используют имена файлов как источник информации. Это не оптимальное решение.
Нет воспроизводимости. Вполне возможно, что полученные результаты не имеют ничего общего с фактическим кодом в notebook. Инженер прошелся по коду, выполнил код из ячейки здесь, что-то подправил и уже не вспомнит, какая информация используется для интерпретации результатов исследования. Какой код я использовал, чтобы получить эти результаты? А какие данные? Но дело здесь не в неточной работе инженера — никто не мыслит линейно. Проблема во фреймворке эксперимента, из-за которого его невозможно воспроизвести.
Нехватка инструментов для разработки. В notebooks не поддерживаются многие инструменты, которые можно использовать в IDE: автозаполнение, навигация по коду и его форматирование, контроль версий, рефакторинг и т. п. Следовательно, работа занимает больше времени и выполняется не в соответствии с передовыми методами, которые позволяют:
- упростить работу и доступ для участников команды;
- реализовывать однозначное поведение программного обеспечения, когда каждая функция должна работать только определенным образом;
- обеспечить модульность кода.
Акцент экспериментальной проверки только на одном аспекте задачи. Поскольку приносит пользу именно продукт, необходимо апробировать продукт в целом, а не только модель. Что, если главная трудность — это не задача обучения, а работоспособность самой модели? Что, если она работает локально, но не работает в приложении? Тестируя только задачу обучения, мы оставляем за рамками проверки UX, деплоймент, безопасность и все технические аспекты программы. Кроме того, начав с простого комплексного теста, можно сократить цикл разработки, заранее протестировать пользу продукта, сэкономить время и повысить качество дизайна. Для этого лучше всего с самого начала разрабатывать решение как программное обеспечение.
Заниматься Data Science так, будто вы разработчик, непросто, но выход есть!
Новый подход: отнеситесь к исследованию как к составной части жизненного цикла разработки ПО
Сегодня появляется все больше готовых моделей и решений под ключ. В том числе поэтому современная наука о данных сильнее сосредотачивается на проработке сценариев использования, моделировании задач и работе с данными, а не на создании самой модели.
Занимайтесь наукой о данных как разработчик
Используйте скрипты и IDE. Таким образом вы сможете выполнять полноценные эксперименты, манипулируя разными модулями и по необходимости запуская с ними сложные циклы обучения. Например, для задач обучения с подкреплением или генерирования изображений необходимо спроектировать несколько частей (среду и один или несколько агентов) или несколько моделей (генератор и дискриминатор) и привести их в действие в цикле обучения, дизайн которого имеет критически важное значение для обучения. Способность моделировать и решать особенно сложные задачи окажется еще важнее для дата-сайентистов, поскольку им больше не нужно решать простые задачи машинного обучения. Действительно, многие решения доступны и неэкспертам в математике или статистике, например:
- решения без кода (dataiku);
- машинное обучение (auto-sklearn);
- предварительно обученные модели, модели и примеры из проектов с открытым исходным кодом (например, на платформах Vertex AI, от компании Hugginface и сообщества решений с открытым исходным кодом).
Управляйте версиями кода и экспериментами как разработчики. С сильной методологией контроля версий можно:
- разобраться, чем один эксперимент отличается от других;
- сделать эксперимент действительно воспроизводимым;
- улучшить отслеживаемость и сократить риск повторения одинаковых экспериментов.
Но контроль версий кода и экспериментов — две разные вещи. С одной стороны, можно использовать Git и современные методы (например, Karma convention) и таким образом фиксировать все, что было сделано, открыв доступ к данным для всей команды. С другой стороны, для отслеживания экспериментов Data Science можно использовать инструменты вроде MlFlow tracking, который позволяет получать метрики, конфигурацию и артефакты, связанные со всеми параметрами.
В идеале хорошо бы объединить обе стороны контроля версий, чтобы можно было сопоставить код с результатами эксперимента. Для этого можно использовать git python, который позволяет делать новый коммит при выполнении кода, то есть провести новый эксперимент.
Сохраните самые интересные преимущества notebooks
Выполняйте код строка за строкой и стройте графики. При проведении экспериментов, а еще потому, что основной для дата-сайентистов Python — это интерпретируемый язык, бывает очень удобно выполнять код построчно или поблочно. Это вполне осуществимо, если к IDE привязан терминал Python. С помощью Pycharm можно выполнять выбранные строки сочетанием клавиш.
В notebooks результаты построения графиков отображаются сразу под каждой ячейкой. В IDE это реализовано не так удобно, но все-таки возможно: в Pycharm можно настроить всплывающие окна с графиком, если использовать matplotlib. Но вы можете — и я даже советую вам — сохранять графики как HTML-страницы (или в другом формате) в отдельных папках, чтобы удобно было вернуться к ним при необходимости. Для любого типа графиков это легко сделать с помощью plotly. Еще можно использовать pandas-profiling, чтобы быстро провести первый исчерпывающий эксперимент с данными.
Скриншот отчета pandas-profiling в HTML
Кроме того, есть инструменты для комплексного отслеживания экспериментов, например tensorboard или MLflow. В этом случае вам не придется строить много графиков, чтобы отслеживать ход исследования.
stackoverflow.com/questions/53529632/how-to-display-the-accuracy-graph-on-tensorboard
Выполнение кода на мощном оборудовании. Возможности локального оборудования достаточно ограничены. В отличие от notebooks, которые можно запускать удаленно на очень мощном оборудовании (экземпляры notebooks предоставляют все крупные облачные провайдеры, Google Collab и т. п.), IDE часто используется в локальной среде.
Первый вариант — запускать вычислительные задачи на удаленных машинах вроде станции DXG с GPU по SSH или через управляемые сервисы, предоставляемые облачными провайдерами. Например, пакетные задачи Azure можно запускать из Python API.
Второй вариант — использовать IDE на виртуальной машине. Такую услугу предоставляет JetBrains GetWay, в котором можно запускать IDE на собственной виртуальной машине по SSH или в Space, другом сервисе JetBrains.
Учитывая все моменты, в подавляющем большинстве случаев имеет смысл спросить себя: действительно ли вам нужна такая вычислительная мощность? Часто это пальба из пушки по воробьям, ведь есть стратегии, позволяющие избежать использования огромных вычислительных ресурсов:
- исследование выборки;
- выбор в пользу непосредственных подходов: передача обучения, готовые модели, доступные на платформах или в режиме службы, бизнес-правила.
У этих стратегий есть другое преимущество: не выполнять масштабное обучение на мощном оборудовании, а сначала попробовать метод побыстрее.
Усилие, которое стоит сделать
Конечно, заниматься Data Science как разработчик не так просто для большинства специалистов, но затраченные усилия окупятся:
- приложить усилия для входа в эту нишу нужно всего один раз;
- команда сможет извлечь пользу из того, что делают другие.
Перестроиться можно быстро. По моему опыту, если даже дата-сайентист вообще не знаком с современными методами работы, ему хватит несколько недель, чтобы освоить:
- IDE,
- контроль версий,
- тестирование,
- сервисы.
В частности, я создал трехдневную программу вводного обучения для дата-сайентистов. За это время мы, в числе прочего, обсуждаем современные подходы к разработке. Меня очень порадовало, что ученики не только быстро вникли в концепции, но и сразу же попытались применить их в работе. Через некоторое время они уже могли создать Data-Science-проект непосредственно в IDE и применяли осовремененные подходы к разработке.
Заключение
Отказаться от notebooks не так-то просто: придется менять привычки, осваивать новые инструменты и подбирать рабочие процессы, оптимальные именно для ваших обстоятельств. Но со всем этим можно быстро справиться и уже в ближайшем будущем пожинать плоды — значительную экономию времени и снижение рисков при проведении исследований.
Кроме того, это позволяет дата-сайентистам стать ближе к разработчикам, дата-инженерам и другим специалистам из проектной команды. В результате вы сможете лучше соответствовать современным стандартам и методам разработки, упростить и ускорить работу, а еще обеспечить понимание и согласованность в команде.
Отказ от notebooks — первый шаг к высокой цели — интеграции экспериментов в полный рабочий процесс MLOps.
VK Cloud развивает собственную платформу для полного цикла ML-разработки ML Cloud Platform. Сейчас она на этапе бета-теста и доступна бесплатно. Мы будем рады, если вы ее протестируете и дадите обратную связь.
