Jupyter Notebook — рак машинного обучения | Ор Хилтч | Skyline AI
В последние годы, после демократизации науки о данных, во главе с развитием сообщества открытого исходного кода машинного обучения с такими библиотеками, как SciKit-Learn, TensorFlow, PyTorch и Pandas, Jupyter Notebooks стали стандартом де-факто для исследования и разработки в области науки о данных. На самом деле, Jupyter Notebooks сами по себе сыграли важную роль в демократизации науки о данных, сделав ее более доступной за счет устранения входных барьеров, как мы скоро увидим.
Как и сам язык Python, наиболее распространенный язык Jupyter Kernel , который во многих аспектах является очень свободным языком, ноутбуки Jupyter являются идеальной средой для хакинга в науке о данных.
Объединяя все преимущества Jupyter Notebooks, главная ценность, которая возникает, заключается в том, что использование Notebooks — это простой способ создания истории данных.
По этой причине легко относиться к коду блокнота, используя подход «это только для исследования», поведение, поощряемое отсутствием инструментов и стандартов в области машинного обучения и Jupyter Notebooks (например, крайне редко можно увидеть специалиста по обработке данных). запуск ноутбука внутри док-контейнера только для того, чтобы убедиться, что используемые внешние библиотеки докеризованы и не поступают с их собственной машины).
Проблемы начинаются, когда эта история должна взаимодействовать с производственным приложением. Веселая и простая платформа, используемая специалистом по данным, должна быть интегрирована в конвейер данных производственного уровня. Именно здесь почти все преимущества Jupyter становятся недостатками, превращая жизнь инженера машинного обучения в сущий ад. Если в компании нет инженера по машинному обучению, почти каждая строка кода, написанного на Jupyter, может стать серьезным случаем технического долга, замедляя время выхода компании на рынок и доводя ее до сложностей с отладкой как в исследованиях, так и в процессе разработки.
этап производства.
К тому времени, как вы это заметите, возможно, вся ваша команда по обработке и анализу данных будет активно использовать записные книжки и что сотни таких вещей в настоящее время время от времени используются для создания некоторых данных, которые вы используете для принятия решений в процессе производства, игнорируя почти каждый важный урок, полученный в мире производственной инженерии и DevOps за последние 20 лет.
Успех Jupyter объясняется многими причинами, большинство из которых связано с устранением барьеров — или, скорее, с упрощением таких вещей, как документация, визуализация данных и кэширование, — особенно для людей, не имеющих серьезного опыта разработки программного обеспечения.
Давайте рассмотрим некоторые из них.
Блокноты позволяют исследователю данных просматривать результаты своего кода в режиме реального времени, иногда , без какой-либо зависимости от других частей их кода. В отличие от работы со стандартной IDE, такой как VSCode или PyCharm, в Jupyter каждая ячейка, исполняемая единица кода, может быть вызвана потенциально в любое время для вывода вывода прямо под кодом.
Это чрезвычайно полезно для исследовательского анализа данных 9Фаза 0004 в любом исследовательском процессе по науке о данных, когда специалисту по данным необходимо играть с данными, извлекать их, изменять их структуру, нарезать и нарезать кубиками, создавать агрегаты и в целом изучать корреляции и распределения вероятностей, чтобы развить интуицию. о характере данных, которые необходимо смоделировать.
Например, именно так можно легко представить результаты в режиме реального времени в Jupyter. Первая ячейка (называемая In [12]) выводит выходные данные JSON (output[12]), а вторая печатает тепловую карту на основе цветных кругов, чтобы помочь исследователю данных понять географическое распределение средних платежей Medicare в США:
Хотите разбить данные на бины и построить гистограмму (гистограмма представляет распределение данных путем формирования бинов по диапазону данных, а затем рисования столбцов, показывающих количество наблюдений, попадающих в каждый бин)? Одна строка кода дает вам вывод прямо под вашим кодом и некоторый текст, описывающий, что вы делаете:
Еще одно огромное преимущество (позже мы поймем, почему это может стать большой ловушкой) использования Jupyter заключается в том, что Jupyter автоматически, за кулисами.
, поддерживает состояние выполнения каждой отдельной ячейки.
Кэшировать сложно, особенно если ваши навыки разработки программного обеспечения не на высшем уровне. Если вы математик, пытающийся получить какие-то данные для моделирования вещей, последнее, что вам нужно, — это реализовать свои собственные схемы кэширования.
Jupyter волшебным образом решает эту проблему, кэшируя результаты каждой запущенной ячейки. Например, если у вас есть огромная записная книжка, содержащая сотни ячеек кода, и где-то в начале записной книжки (находится ранее в «потоке выполнения» записной книжки) у вас есть, скажем, некоторый код, который выполняет какую-то тяжелую операцию. — например, обучение модели машинного обучения или загрузка гигабайт данных с удаленного сервера, с Jupyter у вас есть ноль касается кэширования результатов этих операций.
Обычно, если вы пишете код Python, вы реализуете простую схему кэширования или используете какую-либо библиотеку (например, записывая результаты обученной модели в корзину хранения или сохраняя результаты запроса к БД в локальный файл).
В Jupyter, после того как вы запустили ячейку один раз, пока вы не решите очистить кэш, вы можете просто избежать повторного запуска ее , чтобы насладиться глобальным кэшированием ее последнего выполнения. То есть, если бы в ячейке была строка кода, которая делает что-то вроде этого:
df = client.query(merge(‘SELECT * FROM MyTable’)).to_dataframe()
Переменная `df` будет хранить назначенные ей данные до тех пор, пока кэш не будет явно очищен или ячейка не будет перезапущена. Потенциально, сотни ячеек ниже, вы можете вызвать df , чтобы получить значение, даже если в последний раз вы запускали ячейку, которая ее заполняет, несколько месяцев назад.
Мы убедились, что блокноты Jupyer отлично подходят для рассказывания историй из данных. Но, если мы не проводим чистое исследование, наше исследование является средством для достижения цели, а именно получения ценной информации из наших историй данных и моделей машинного обучения.
Конвейер машинного обучения производственного уровня должен состоять из поддающихся отладке, воспроизводимых, простых в развертывании и высокопроизводительных компонентов кода, которые можно организовать и запланировать. В версии по умолчанию есть все, чего нет в исследовательском коде Jupyter.
Даже если вы проигнорируете тот факт, что кэширование ячеек способствует загрязнению глобальной области кэшированными переменными (см. назначение df выше), поведение кэширования Jupyter по умолчанию заставляет разработчика помнить всю конечную машину блокнота в своих головы.
Какая ячейка с чем кэшируется? Из 400 ячеек могла ли работать ячейка № 273, даже если ячейка № 50 не работала? Что, если бы он запустился, но с другими данными, читая другие данные? Являются ли результаты ячейки № 200 неизменными? т.е. можем ли мы повторно запустить его и получить те же результаты, или повторный запуск завершится ошибкой/вернет другие результаты?
Нет простого способа ответить на любой из этих вопросов при разработке на Jupyter Notebook.
Вы должны полагаться на свою человеческую память, которая не предназначена для запоминания конечных автоматов наизусть, чтобы знать, какая ячейка может работать с другими ячейками или без них, какая ячейка может быть запущена повторно и т. д. Это просто не работает. .
По сути, то, что делает большинство специалистов по данным, когда они не уверены в конечном автомате, просто запускает полный повторный запуск всей записной книжки, что является пустой тратой времени и ресурсов.
Машины состояний не предназначены для того, чтобы люди запоминали их наизусть Но что еще хуже — что происходит, когда вы хотите перенести код исследования в производство ? Либо сами разработчики блокнотов, либо инженеры машинного обучения должны организовать исследовательский код в компоненты кода производственного уровня (помните — отлаживаемые, воспроизводимые и т. д.). Различные части исследовательского кода — части, которые извлекают данные, части, которые обучают модель, части, которые проверяют результаты и т.
д., должны быть 9.0003 организовал , и нам нужно запустить их в какой-то форме DAG (см. Apache Airflow).
Но когда у вас есть «история данных», состоящая из сотен ячеек, и единственное, на что вы можете в значительной степени положиться (и это тоже решает разработчик, написавший блокнот), это то, что конечный автомат продвигается по прямой линии «вперед», «в хронологическом порядке», когда вы прокручиваете блокнот вниз… у вас большие проблемы.
Удобный интерфейс командной строки ноутбука Jupyter поддерживает локальное выполнение. Почти уверен, что 99% специалистов по данным используют Jupyter локально, хотя некоторые облачные провайдеры предпринимают преждевременные попытки перенести ноутбуки в облако (Google Cloud DataLab и AWS SageMaker). Но эти решения преждевременны и имеют множество собственных проблем.
Существует множество проблем с локальным запуском блокнотов, которые усложняют работу инженера по машинному обучению, который будет запускать код блокнота в производство.
Прежде всего, зависимости. Блокнот может импортировать библиотеки, которые установлены только на компьютере специалиста по анализу данных.
Если по какой-то причине специалист по данным использует другую версию одной и той же библиотеки, например, NumPy для TensorFlow, фактические математические расчеты в производстве могут отличаться от результатов исследований. Это один из самых больших кошмаров каждой инженерной операции и одна из главных причин успеха контейнерных технологий, таких как Docker, которые обычно не используются при работе с ноутбуками, потому что они предназначены «только для исследований».
Кроме того, результаты записной книжки, полученные при локальном выполнении, невозможно воспроизвести. Ноутбук не проходит процесс сборки и не должен соответствовать стандартам CI, применяемым сервером сборки. Вполне может быть, что результаты будут другими при работе на машине другого члена команды только из-за некоторых различий в кэшировании между машинами.
Конечно, производительность локальной машины тоже не идеальна, но есть способы обойти это (например, можно подключиться к внешним кластерам, чтобы разгрузить там выполнение тяжелых вычислений).
Существует множество практик, связанных с исследованиями, которые используют отличные библиотеки от серьезных компаний, таких как Google, чтобы устранить трения за счет написания хорошего кода.
Отличным примером этого является магия ячеек Google Cloud Big Query . Магия ячеек в Jupyter — это библиотеки кода, которые могут расширять функциональность ячеек Jupyter Notebook, например, автоматически сохранять результаты в структуру данных.
Рассмотрим следующий пример из официальной документации Google Cloud, Визуализация данных BigQuery в блокноте Jupyter:
%%bigquery total_births
SELECT
source_year AS year,
COUNT(is_male) ASbirth_count
FROM `bigquery-public-data. Samples.natality`
ГРУППИРОВАТЬ ПО году
ORDER BY year DESC
LIMIT 15
Выглядит красиво, правда? Просто жестко закодируйте SQL-запрос в ячейке и разделите набор результатов на кадр данных pandas с именем total_births. Хотя понятно, почему с ним легко работать, на самом деле это очень плохая практика кодирования для всего, кроме чисто научных исследований.
Если ваш ноутбук использует эту магию ячеек повсюду, вы не сможете динамически создавать запросы, используя универсальные функции. Таким образом, если у вас есть два сложных запроса, которые должны быть идентичными, за исключением небольшой части, вы обнаружите, что эти запросы дублируются.
Без магии ячеек средний программист написал бы универсальную функцию для возврата запроса с небольшим изменением:
def get_births_by(period):
return """SELECT
source_period AS {период},
COUNT(is_male) ASbirth_count
FROM `bigquery-public-data.samples.natality`
ГРУППИРОВАТЬ ПО {период}
ПОРЯДОК BY {период} DESC
LIMIT 15""".replace('{период}', период)by_month = get_births_by('month')
by_year = get_births_by('год')
Чтобы иметь возможность наслаждаться этой магией клетки, большинство специалистов по данным создали бы повторяющиеся ячейки, одну для года :
%%bigquery total_births
SELECT
source_year AS year,
COUNT(is_male) AS Birthday_count
FROM `bigquery-public-data.samples.natality`
GROUP BY year
ORDER BY year DESC
LIMIT 15
samples.natality` 2 6 месяцев: 5 %%bigquery total_births
SELECT
source_month КАК месяц,
COUNT(is_male) ASbirth_count
FROM `bigquery-public-data.samples.natality`
GROUP BY month
ORDER BY month DESC
LIMIT 15 3 900 Тип кода очевидно, что это очень плохо, и, скорее всего, инженеру машинного обучения, интегрирующему такого рода исследовательский код в приложение производственного уровня, придется реорганизовать весь код блокнота, чтобы использовать общие функции, которые избегают дублирования кода, не используя какой-либо из этого кода.
Благодаря встроенному кэшированию Jupyter и тому факту, что результаты сохраняются после выполнения записной книжки, легко обмануть чувство стабильности.
Конечно, если я вижу результаты перед глазами под одной из ячеек, то повторный запуск той же ячейки без изменения кода должен дать те же результаты. Верно? Неправильный.
Если ячейка выдает результат на основе данных в БД, и эти данные изменились, и в коде нет ничего, чтобы убедиться, что код работает с конкретным снимком данных, который не изменяется, точно такая же ячейка может вернуть другой результат. И, после повторного запуска ячейки очень трудно узнать, каким был предыдущий результат, потому что Jupyter Notebook ничего не делает для сохранения истории результатов, а решения для управления исходным кодом, такие как git, обычно также не хранят кэши.
Как и многие примеры в этой статье, это не проблема Jupyter, но это хороший пример того, как воспроизводимость предыдущих результатов невозможна без надлежащего инструментария для их создания, и поскольку Jupyter не Если вы не предоставите этот инструментарий, специалист по обработке и анализу данных, не обладающий большими навыками разработки программного обеспечения, скорее всего, пострадает от этого.
Итак, можем ли мы как-то наслаждаться обоими мирами? Имея гибкость и кэширование в стиле Jupyter, с одной стороны, и современные методы кодирования, с другой?
Похоже, что да, или скоро будет так: две самые популярные на сегодняшний день IDE для всего, что связано с наукой о данных, PyCharm и VSCode, обе теперь изначально поддерживают Jupyter (хотя поддержка все еще далека от совершенства).
Используя встроенную поддержку PyCharm и VSCode для Jupyter, вы можете легко интегрировать решения для управления исходным кодом и использовать такие функции повышения производительности, как IntelliSense, обработка ошибок в реальном времени (в случае синтаксических ошибок или нарушения соглашений Pylint), интеграция с Git , управление несколькими файлами и многое другое, предлагая специалистам по данным правильный способ экспериментировать и эффективно работать с данными.
Уникальная сложная информация в аналоговых методах, вероятно, дает мозгу больше деталей для запуска памяти -- ScienceDaily
Исследование студентов и недавних выпускников японских университетов показало, что письмо на физической бумаге может привести к большей активности мозга при запоминании информации в час потом. Исследователи говорят, что уникальная, сложная, пространственная и тактильная информация, связанная с записью от руки на физической бумаге, вероятно, приводит к улучшению памяти.
«На самом деле, бумага более совершенна и полезна по сравнению с электронными документами, потому что бумага содержит больше уникальной информации для лучшего запоминания», — сказал профессор Куниёси Л. Сакаи, нейробиолог из Токийского университета и автор соответствующей статьи. исследования, недавно опубликованного в Границы поведенческой неврологии . Исследование было завершено с сотрудниками из Института управленческого консультирования NTT Data.
Вопреки распространенному мнению, что цифровые инструменты повышают эффективность, добровольцы, которые использовали бумагу, справились с заданием по ведению заметок примерно на 25% быстрее, чем те, кто использовал цифровые планшеты или смартфоны.
Хотя добровольцы писали от руки как ручкой и бумагой, так и стилусом и цифровым планшетом, исследователи говорят, что бумажные блокноты содержат более сложную пространственную информацию, чем цифровая бумага. Физическая бумага допускает ощутимое постоянство, неправильные штрихи и неровную форму, например, загнутые углы.
Напротив, цифровая бумага однородна, не имеет фиксированного положения при прокрутке и исчезает при закрытии приложения.
«Наше основное послание — использовать бумажные блокноты для информации, которую нам нужно выучить или запомнить, — сказал Сакаи.
В ходе исследования 48 добровольцев прочитали вымышленный разговор между персонажами, обсуждая свои планы на два месяца в ближайшем будущем, в том числе 14 разных занятий, сроки выполнения заданий и личные встречи. Исследователи провели предварительный анализ, чтобы убедиться, что добровольцы в возрасте от 18 до 29 лет, набранные из университетских городков или офисов NTT, были в равной степени разделены на три группы в зависимости от навыков памяти, личных предпочтений в отношении цифровых или аналоговых методов, пола, возраста и другие аспекты.
Затем волонтеры записали вымышленное расписание, используя бумажный ежедневник и ручку, приложение-календарь на цифровом планшете и стилус или приложение-календарь на большом смартфоне и клавиатуру с сенсорным экраном.
Ограничений по времени не было, и добровольцев попросили записывать вымышленные события так же, как они делали бы это в своих реальных расписаниях, не тратя дополнительное время на запоминание расписания.
По прошествии одного часа, включая перерыв и интерференционное задание, чтобы отвлечь их от размышлений о календаре, добровольцы ответили на ряд простых (когда нужно выполнить задание?) и сложных (какой срок выполнения заданий является более ранним?) вопросы с несколькими вариантами ответов, чтобы проверить их память о расписании. Пока они завершали тест, добровольцы находились внутри магнитно-резонансного томографа (МРТ), который измеряет кровоток вокруг мозга. Это метод, называемый функциональной МРТ (фМРТ), и увеличение кровотока, наблюдаемое в определенной области мозга, является признаком повышенной активности нейронов в этой области.
Участники, которые использовали бумажный ежедневник, заполнили календарь примерно за 11 минут. Пользователям планшетов потребовалось 14 минут, а пользователям смартфонов — около 16 минут.
Добровольцы, использовавшие аналоговые методы, набрали больше баллов, чем другие добровольцы, только по простым тестовым вопросам. Однако исследователи говорят, что данные об активации мозга выявили существенные различия.
Добровольцы, которые использовали бумагу, имели более высокую активность мозга в областях, связанных с языком, воображаемой визуализацией, и в гиппокампе — области, которая, как известно, важна для памяти и навигации. Исследователи говорят, что активация гиппокампа указывает на то, что аналоговые методы содержат более богатые пространственные детали, которые можно вспомнить и перемещаться мысленным взором.
"Цифровые инструменты имеют равномерную прокрутку вверх и вниз и стандартизированное расположение текста и размера изображения, как на веб-странице. Но если вы помните физический учебник, напечатанный на бумаге, вы можете закрыть глаза и визуализировать фотографию на треть вниз на левой странице, а также примечания, которые вы добавили в нижнем поле», — объяснил Сакаи.
Исследователи говорят, что персонализация цифровых документов путем выделения, подчеркивания, обведения кружком, рисования стрелок, рукописного ввода цветных заметок на полях, добавления виртуальных стикеров или других типов уникальных пометок может имитировать пространственное обогащение в аналоговом стиле, что может улучшить объем памяти.
Хотя у них нет данных о более молодых добровольцах, исследователи подозревают, что разница в активации мозга между аналоговыми и цифровыми методами, вероятно, будет сильнее у молодых людей.
«Мозг старшеклассников все еще развивается и намного более чувствителен, чем мозг взрослых», — сказал Сакаи.