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

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

Вы напрямую управляете артефактами модели.

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

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

Исправьте это, установив конвейер CI / CD для управления артефактами модели. MLFlow или Sagemaker Pipelines дает хороший вариант.

У вас проблемы с воспроизведением преобразований данных для вывода.

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

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

Вы используете локальные записные книжки.

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

Представление репозитория git может содержать эту проблему. Но ответственность за контроль версий своего кода по-прежнему несут специалисты по данным. Использование Amazon SageMaker Studio или Jupyterhub и обращение к команде могут помочь в решении этой проблемы.

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

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

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

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

У вас нет механизмов обнаружения дрейфа в реальном времени.

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

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

Управление версиями вашей модели, отслеживание экспериментов, переподготовка и мониторинг выполняются вручную.

Если модели не версируются и предыдущие эксперименты не сохраняются, у вас не будет возможности отслеживания, когда что-то пойдет не так. Мониторинг модели также отслеживает проблемы с задержкой, ошибки вывода и аномалии. Автоматическое переобучение моделей может улучшить обнаружение смещений ваших моделей. Хотя преимущества наличия этих функций очевидны, их отсутствие (или наличие очень ручной версии) указывает на незрелость практики машинного обучения.

Спасибо за чтение

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

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

Если вы зашли так далеко, у меня есть для вас один совет - практики New Data Science могут использовать один из пакетов облачного машинного обучения на всех этапах (Sagemaker от Amazon, AzureML, CloudML, Datarobot), чтобы в значительной степени избежать всего, что я только что описал. Однако большинству поставщиков облачных услуг еще далеко до полного понимания конвейеров машинного обучения. Вместе с ними вам придется совершенствовать свою практику и беспокоиться о привязке к поставщику.

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

использованная литература

Поищите здесь несколько лучших практик MLOps:



На Amazon: