Авторы: Стефан Пачинда и Джон Спунер из H2O.ai
Введение в 4 основных принципа развертывания модели (1-я часть серии блогов)
Итак, вы создали модель машинного обучения (ML), которая обеспечивает высокий уровень точности и не допускает переборов. Какую ценность это имеет сейчас? Ну, на данный момент ничего, ноль, нечестно приседаю. Нет экономической ценности в модели машинного обучения, которая никогда не выходит в свет и не используется в производстве для принятия бизнес-решений.
Так как же специалисты по данным могут преодолеть «последнюю милю» до той неуловимой конечной зоны, которая называется производством? Как быстро извлечь максимальную пользу из созданной модели? Для многих организаций это самый трудный орешек, и есть много правильных путей к развертыванию. Какие вопросы мы должны задать, чтобы определить путь, по которому нам следует идти? Они построены на фундаменте, основанном на 4 столбах. Эти:
- Источники данных и их формат
- Как измерить успех
- Доведение модели до производства
- Внешние ограничения и ограничения
Во время следующего ряда дополнительных блогов, которые мы опубликуем как часть этой серии, мы исследуем эти 4 столпа более подробно. Этот первый блог предоставит обзор и введение в эти важные тематические области.
1. Источники данных и их формат
Некоторые из ключевых вопросов и указателей, которые необходимо задать:
- Будут ли те же данные с той же структурой доступны в производственной среде после расчета прогнозов?
- Доступны ли источник данных и место назначения прогнозирования с компьютеров, на которых они будут обработаны средой машинного обучения? Одним из наиболее распространенных препятствий в корпоративной среде является отсутствие доступа к сети, низкая пропускная способность и длительная обратная передача (не следует повторно передавать большие наборы данных через океан) ваших данных и между задействованными системами. . Решение этих проблем может занять долгие недели и значительные усилия, поэтому планируйте, тестируйте и привлекайте ИТ-специалистов заранее.
- Совместима ли система хранения с разъемами, доступными в платформе ML, и поддерживается ли формат данных. Может показаться тривиальным изменение представления и расположения ваших наборов данных при экспериментировании с небольшими выборками данных, но все меняется, когда вы начинаете увеличивать объем ваших данных.
- Подходит ли платформа машинного обучения к размеру набора данных? Избегайте соблазна использовать мощные фреймворки для простых задач, но также имейте в виду, что многие заявляют, что они готовы к работе с большими данными, а на самом деле лишь немногие. Независимо от мощности решения для машинного обучения, вам необходимо убедиться, что вы не включаете в процесс оценки, возможно, большой объем данных, которые не являются необходимыми. Размер набора данных измерения важен. Как физический размер (ГБ), так и количество строк и столбцов создают вычислительную проблему для задачи машинного обучения. Понижение частоты дискретизации столбцов и строк может потребоваться для уменьшения требуемого времени выполнения, надлежащий исследовательский анализ данных и предварительное моделирование также могут позволить вам уменьшить набор данных. Также можно рассмотреть возможность дробления или мини-пакетирования, особенно когда речь идет о перемещении моделей в среду производственной оценки.
2. Как измерить успех
Независимо от того, что вы делаете, в конце концов, вы должны уметь отличать успех от неудачи. Красоту можно найти во всем, однако давайте рассмотрим еще несколько объективных показателей.
Перевести на Бизнес
Можете ли вы выразить ожидания нетехнического потребителя ваших моделей машинного обучения, которые будут построены формализованным способом с использованием стандартных показателей машинного обучения?
Тестирование моделей и другие показатели
Основываясь на обсуждениях с представителями бизнеса, характере набора данных и других входных данных, жизненно важно, чтобы мы включили правильную стратегию проверки наших моделей, выбрали правильных счетчиков и разбили набор данных. Также необходимо учитывать стабильность, чувствительность, справедливость и интерпретируемость модели. Также вероятно, что после запуска модели в производство необходимо будет выполнить ряд других ключевых показателей эффективности: например:
- Для онлайн-бизнеса или торговли с малой задержкой нам нужны хорошие прогнозы, рассчитываемые в течение определенного периода времени, иначе они устареют.
- Устройства Интернета вещей / периферийных устройств требуют, чтобы модели были небольшого размера, а создание прогнозов было недорогим с вычислительной точки зрения из-за ограниченного объема памяти и, возможно, времени автономной работы.
Распад модели
Всем нужна самая свежая модель в производстве, однако вам нужно балансировать между свежими и возникающими при этом хлопотами. Как быстро распадаются ваши модели? Насколько сильно снижение точности повлияет на ваше экономическое обоснование? Насколько дорого обходится переобучение модели и запуск новой в производство? Какие накладные расходы у него есть? Можете ли вы заменить старую модель на новую, не прерывая всей операции, а если нет, какова стоимость такого периода обслуживания? Как часто вы можете собирать данные из ваших систем для переобучения моделей? Насколько велик разрыв в исторических данных между «сейчас» и последней собранной точкой данных? Эти затраты, связанные с внедрением новой модели в производство, должны быть оценены заинтересованными сторонами.
Постановка моделей
К сожалению, нам нужно спроектировать и выбрать правильную модель, прежде чем мы увидим, что она засветится или потерпит неудачу при развертывании. Поэтому мы стараемся как можно лучше измерить качество модели на этапе тестирования. Для этого нам необходимо установить и поддерживать базовые критерии, которые будут определять, удалось ли нам построить модель, которая, вероятно, будет достаточно хорошей, чтобы принести пользу при замене текущей модели в производстве. Если у нас нет модели в производстве, нам просто нужно полагаться на результаты лабораторных исследований.
Когда разрабатывается новая версия программного компонента, часто бывает, что релиз-кандидат продвигается через ряд промежуточных областей. Такой прогресс обычно включает в себя необходимость прохождения автоматизированных модульных тестов, интеграционных тестов, некоторых форм ручного тестирования, тестирования производительности и, в конечном итоге, приемочного пользовательского тестирования. Нет причин не относиться к моделям машинного обучения иначе. Следуя понятию экономии на масштабе, можно легко извлечь выгоду из существующего процесса, добавив модели машинного обучения в качестве еще одного компонента существующего процесса разработки программного обеспечения.
Рассматривали ли вы возможность A / B-тестирования для дальнейшего снижения риска внедрения новой модели?
Мониторинг модели
Чтобы наша модель продолжала работать достаточно хорошо в производстве, нам необходимо контролировать те же качества, что и в лаборатории. Модель понимает закономерности только на основе данных, на которых она была обучена. Как изменяются шаблоны данных и значения данных, как это влияет на качество результатов, выводимых из модели?
Существенно ли меняются данные по сравнению с нашим набором данных для обучения? Что делать, если другие KPI выходят за пределы ожидаемого диапазона значений? Мы можем сохранить резервную копию старой модели, чтобы вернуться к ней и / или подготовить более простую систему резервного копирования (например, вашу старую модель, основанную на правилах до машинного обучения). Всегда рекомендуется использовать стандартные предупреждения разработчиков, которые, скорее всего, будут реализованы для приложения с использованием модели машинного обучения.
Помимо метрик, мы также можем захотеть сгенерировать метаданные, документирующие, какие входные данные были просмотрены, какие значения были неизвестны моделям (невидимые категориальные значения, недопустимые входные данные или даже ошибки времени выполнения). Нам нужно решить, нужно ли обрабатывать эту информацию в реальном времени, чтобы инициировать некоторые немедленные действия, или автономной пакетной записи достаточно для последующего посмертного анализа. Есть ли у вас проверенная мойка для лесозаготовок или журналы? Используйте их при добавлении новых мест назначения для ваших записей.
Использование ресурсов
Мы говорили о показателях приложений, но принципы разумного управления активами требуют от нас также контролировать использование таких ресурсов, как вычислительные ресурсы, память и хранилище. Потребление ресурсов очень вариативно и очень зависит от сценария использования. В серьезных бизнес-случаях разумно избегать чрезмерного выбора оборудования. С другой стороны, если в моделях наблюдается увеличение потребления, это должно побудить операционную группу увеличить пул ресурсов. Это предотвратит внезапное падение производительности из-за нехватки ресурсов.
3. Доведение модели до производства
Многопользовательская среда
Многие предприятия обслуживают сразу нескольких арендаторов. Важно различать случаи, когда разные арендаторы могут извлечь выгоду из использования общей модели машинного обучения, обученной на объединенном наборе данных, и случаи, когда такой подход может привести к неоптимальным результатам (в основном к неточности). Юридические последствия такого компромисса часто обусловливают возможность такой оптимизации.
Высокая доступность
Как и для любого другого программного компонента, для развертывания логики скоринга может потребоваться определенное количество «девяток» доступности (возможно, по контракту). Рассматривали ли вы понятия расширенной балансировки нагрузки с автоматическим масштабированием, выполнения «ровно один раз» или горячего старта развернутых моделей?
Контроль версий
Как и в случае с другими активами, есть веская причина хранить старые модели в архиве и версиях. Власти могут потребовать от вас задокументировать основную логику ведения бизнеса в любой момент в прошлом, внутренний аудит может потребоваться руководителями или недостаток в текущей модели может привести к откату к последней известной правильной версии модели. Нет смысла хранить простую модель. Также необходимо хранить метаданные, описывающие параметры и структуру модели вместе с производственными показателями, обсуждавшимися ранее. Для экспериментов с новыми идеями бесценно использование таких методов, как A / B-тестирование и управление версиями моделей с их ключевыми показателями эффективности.
Интеграция логики скоринга
Невозможно предвидеть все разновидности интеграции логики скоринга. Недооценка правильного планирования интеграции привела к ситуации, когда создание отличных моделей машинного обучения заняло значительно больше времени, чем фактическая разработка модели.
H2O.ai давно об этом думает. Мы понимаем, что обученная модель должна быть максимально гибкой, предоставляя пользователю ее платформы большое количество способов развертывания. Одна жизненно важная характеристика, общая для всех вариантов развертывания, - это автономность логики скоринга, не требующая какой-либо серверной инфраструктуры H2O.ai.
В следующих публикациях мы расширим эти шаблоны развертывания, поэтому вот их список в произвольном порядке:
- Bash-подобный файл - ›автономная оценка файла, вызываемая на уровне процесса операционной системы, управляемая средствами системного администратора UNIX (-подобными), такими как Cron
- Пакетная оценка данных в базе данных (СУБД, Hadoop, NoSQL,…)
- Микрослужба, охватывающая несколько различных реализаций автономной (RESTful) службы с JSON / двоичным содержимым как локально, так и в облаке.
- Автоматическое развертывание в одном из масштабируемых облачных сервисов, например AWS Lambda.
- Тесная интеграция на уровне кода с моделями машинного обучения за счет встраивания логики скоринга с использованием библиотек времени выполнения, отделенных от фактической модели, которая обслуживается как зависимость времени выполнения в форме файла данных
- (Почти) оценка в реальном времени с системами потоковой обработки, такими как Kafka или Flink
- Развертывание Spark Pipelines с использованием моделей H2O.ai в качестве собственных конвейеров Spark, работающих со структурами данных Spark
4. Внешние ограничения и ограничения
Проще говоря, то, что было возможно в научно-исследовательской лаборатории, может стать очень серьезной проблемой в целевой среде.
Привилегированный доступ
Очень неприятным открытием может быть необходимость в привилегированном доступе для выполнения логики скоринга или настройки зависимостей времени выполнения скоринга. Это может быть неразрешимой проблемой или может занять очень много времени.
Герметичная среда
Для доступа к конфиденциальным данным может потребоваться герметично закрытая среда без доступа к Интернету или другим источникам зависимостей. Лениво разрешенные зависимости или просто процессы развертывания модели, требующие разрешения онлайн-зависимостей, могут быть недоступны, и во время устранения этой проблемы могут возникнуть пропущенные сроки.
Юридические ограничения
Нейронные сети и другие методы могут быть недоступны по нормативным причинам. Убедитесь, что даже юридические отделы участвуют в начальных обсуждениях по снижению таких рисков.
В итоге
Мы надеемся, что вам понравилась первая часть наших мыслей о максимальном воздействии машинного обучения, и вы цените все отзывы, которые у вас есть.
Что дальше?
В следующей части (часть 2) этой серии блогов мы подробно рассмотрим соображения, которые необходимо учитывать организациям в отношении источников и формата данных, которые используются для развертывания их моделей.
