Введение в машинное обучение для производства / MLOps

Введение в машинное обучение для производства / MLOps - этапы MLOps

Обсуждение этапов создания модели машинного обучения, а именно определение объема, данных, моделирования и развертывания.

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

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

1. Оценка

Определение объема помогает определить возможные решения проблемы, говоря очень просто. Рассмотрим пример, в котором вы работаете над проектом распознавания рукописного ввода для своей компании. Теперь некоторые начальные шаги при приближении к этой проблеме могут быть связаны с тестовыми документами / реализациями этой проблемы с открытым исходным кодом. Часто это хорошая отправная точка для большинства проектов, поскольку перед вами почти всегда есть кто-то, кто, возможно, попытался бы решить ту же самую постановку проблемы. После этого вы можете передать свои данные в эту модель с открытым исходным кодом и точно настроить ее или взять некоторые фрагменты из модели с открытым исходным кодом и создать свою собственную модель. По сути, просмотр этих уже существующих решений дает вам общее представление о достижимом уровне точности. Вот что влечет за собой определение объема работ. Некоторые ключевые моменты, охваченные аналитическим обзором:

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

Вот что по сути представляет собой определение объема работ. Это поможет вам или вашей команде лучше понять проблему и способы ее решения.

2. Данные

Общеизвестно, что данные в значительной степени правят миром искусственного интеллекта. Наши модели, по крайней мере, в случае обучения с учителем, хороши ровно настолько, насколько хороши наши данные. Важно, особенно при работе в команде, быть на одной странице в отношении имеющихся у вас данных. Рассмотрим ту же задачу распознавания рукописного ввода, которую мы определили ранее. Предположим, вы и ваша команда решили на время отказаться от изображений, на которые плохо нажимали. Итак, что такое изображение с плохим кликом? Для вашего товарища по команде все может быть иначе, а для вас - иначе. В таких случаях важно установить набор правил, определяющих, что такое плохо нажимаемое изображение. Может быть, если вам сложно прочитать более 5 слов на странице, вы решите отказаться от этого. Что-то в этом роде. Это чрезвычайно важный шаг даже в исследовании, поскольку неоднозначность данных и меток приведет только к еще большей путанице для модели.

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

Некоторые ключевые моменты, которые следует помнить при работе с данными:

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

3. Моделирование

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

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

Установление базового уровня: то, что часто упускается из виду (совершил эту ошибку лично, пожалуйста, не делайте эту ошибку * внутренне кричит *), установление базового уровня невероятно важно, поскольку помогает дать вам представление о том, как продолжить. В основном это включает в себя предыдущие исследования в соответствующих областях или просмотр продуктов других компаний, которые делают то же самое, и определение того, насколько хороши их модели. Это наряду с информацией о требуемых / доступных вычислительных ресурсах может помочь вам воспроизвести некоторые современные результаты (SOTA). Что хорошо для сообщества DL, так это то, что большая часть всех статей SOTA имеет открытый исходный код. Это позволяет легко не только устанавливать базовые линии, но и строить аналогичные или, в некоторых случаях, даже лучшие модели. Для неструктурированных данных вы можете использовать производительность человеческого уровня в качестве критерия для оценки вашей модели. Рассмотрим задачу распознавания рукописного ввода, данную ранее - если модель с открытым исходным кодом способна читать слова с частотой ошибок ~ 20%, то это ваш базовый уровень для задачи. Если вы чувствуете, что у вас есть средства для копирования документов SOTA, вы также можете использовать их результаты для определения ваших исходных показателей. Все это субъективно.
Подход, ориентированный на данные. То, что быстро набирает популярность в сообществе, ориентированные на данные подходы предполагают сосредоточение внимания на данных, а не только на модели. Прилагаются усилия, чтобы обеспечить высокое и постоянное качество данных. На мой взгляд, подходы, ориентированные на данные, хотя и не являются чем-то распространенным в исследованиях, являются единственным окончательным способом улучшить результаты вашей модели. Обеспечение того, чтобы ваши данные охватывали важные тестовые случаи, были согласованно определены и распределялись равномерно, насколько это возможно, - все это часть подхода, ориентированного на данные. Лично в проектах, над которыми я работал, я всегда замечал небольшое улучшение точности невидимых данных всякий раз, когда я пытался использовать подход, ориентированный на данные. Это может быть что-то небольшое, например, исправление условий освещенности на изображениях перед их загрузкой в модель и т. Д.
Отслеживание экспериментов / контроль версий: хорошо известный шаг в DevOps, контроль версий помогает нам отслеживать изменения и позволяет нам вернуться к предыдущим рабочим версиям в тех случаях, когда наши приложения могут выдавать ошибки. В MLOps важно отслеживать ваш код используемого алгоритма, гиперпараметров, изменений в наборе данных (если есть) и типа полученных результатов для определенного набора гиперпараметров и т. д.

4. Развертывание

Теперь, когда у нас есть готовая модель, что дальше? Развертывание конечно! Это включает в себя выпуск вашей модели в реальных условиях или ее интеграцию в приложение / периферийное устройство, для которого она была разработана. Теперь даже в развертывании есть определенные типы развертывания. Эти-

Теневое развертывание. В этом типе развертывания модель развертывается, но окончательное решение принимает человек, независимо от того, что прогнозирует модель. Обычно это делается для того, чтобы оценить, насколько хорошо модель работает и где она терпит неудачу.
Канарское развертывание. В этом типе развертывания модели предоставляется только небольшая часть данных, на основе которых ей разрешено принимать решения. Например, модель может быть выставлена только на 10 из каждых 1000 изображений. В зависимости от того, как работает модель, трафик постепенно увеличивается или модель откатывается и вносятся корректировки.
Сине-зеленое развертывание. При этом типе развертывания трафик постепенно переносится со старой или синей версии на новую или зеленую версию. Это помогает предотвратить любые простои, а в случае каких-либо ошибок / ошибок приложение можно легко откатить до предыдущей стабильной версии или синей версии.

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

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

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

Ссылки

Введение в машинное обучение для производства / MLOps - этапы MLOps