- PVSM.RU - https://www.pvsm.ru -
Развертывание машинного обучения (machine learning, ML) в продакшн – задача нелегкая, а по факту, на порядок тяжелее развертывания обычного программного обеспечения. Как итог, большинство ML проектов так никогда и не увидят света — и продакшена — так как большинство организаций сдаются и бросают попытки использовать ML [1] для продвижения своих продуктов и обслуживания клиентов.
Насколько мы можем видеть, фундаментальное препятствие на пути большинства команд к созданию и развертыванию ML в продакшн в ожидаемых масштабах заключается в том, что нам все еще не удалось привнести практики DevOps [2] в машинное обучение. Процесс создания и развертывания моделей ML частично раскрыт уже вышедшими MLOps решениями, однако им недостает поддержки со стороны одной из самых трудных сторон ML: со стороны данных.
В этой статье мы обсуждаем, почему индустрия нуждается в DevOps решениях для данных ML, и как уникальные трудности ML data препятствуют усилиям по практическому применению ML и развертыванию его в продакшн. Статья описывает вакуум в текущей инфрастуктурной экосистеме ML и предлагает заполнить его Tecton, централизованной дата платформой для машинного обучения. По ссылке [3] (англ) на статью от моего со-основателя Майка можно ознакомиться с дополнительными деталями по запуску Tecton.
Tecton был создан группой инженеров, которые создавали внутренние ML платформы в таких компаниях, как Uber, Google, Facebook, Twitter, Airbnb, AdRoll, и Quora. Значимые инвестиции этих компаний в ML позволяли разрабатывать процессы и инструменты по обширному применению ML для своих организаций и продуктов. Уроки, представленные в этой статье, равно как и сама платформа Tecton, во многом основаны на опыте нашей команды по развертыванию ML в продакшн за последние несколько лет.
Процесс разработки и развертывания программного обеспечения двадцать лет назад и процесс разработки ML приложений наших дней имеют очень много общего: системы обратной связи оказывались невероятно долгими, и к тому моменту, когда вы добирались до выпуска продукта, ваши изначальные требования и дизайн уже успели устареть. А затем, в конце нулевых, возник набор лучших практик по разработке программного обеспечения в виде DevOps [2], предоставив методы для управления жизненным циклом разработки и позволив добиться непрерывных, стремительных улучшений.
Подход DevOps позволяет инженерам работать в четко определенной общей кодовой базе. Как только поэтапное изменение готово к развертыванию, инженер проверяет его через систему контроля версий. Процесс непрерывной интеграции и доставки (CD/CI) берет самые последние изменения, проводит модульное тестирование, создает документацию, проводит интеграционное тестирование, и в итоге в управляемой манере выпускает изменения в продакшн либо готовит релиз к распространению.
Рис. 1: типичный DevOps процесс
Ключевые удобства DevOps:
В наши дни многими командами разработки взят за основу именно такой интегрированный подход.
В явном противоречии с разработкой ПО, в анализе данных нет четко определенных, полностью автоматизированных процессов для быстрого продакшна. Процесс создания ML приложения и развертывания его в продукт состоит из нескольких шагов:
Рис. 2: специалистам анализа данных приходится координировать свою работу между несколькими командами в разных областях
В итоге, команды ML сталкиваются с теми же проблемами, с которыми программисты сталкивались двадцать лет назад:
Рис. 3: И скорость, и частота повторения процессов оказывают значительное давление на кривую ожидаемого улучшения продукта
Такие MLOps [5] платформы как Sagemaker и Kubeflow движутся в верном направлении по пути помощи компаниям в упрощении производства ML, благодаря чему мы можем наблюдать, как MLOps привносит принципы и инструментарий DevOps в ML. Для начала работы им требуются довольно порядочные авансовые инвестиции, но после корректной интеграции они в состоянии расширить возможности специалистов data science в области обучения, управления и выпуска ML моделей.
К несчастью, бо́льшая часть инструментария MLOps склонна фокусироваться на рабочем процессе вокруг самой модели (обучение, внедрение, управление), что создает ряд трудностей для действующих ML. ML приложения определяются кодом, моделями, и данными [6]. Их успех зависит от способности создавать высококачественные данные ML и поставлять их в продакшн достаточно быстро и стабильно… иначе это очередной «garbage in, garbage out». Следующая диаграмма, специально подобранная и адаптированная из работы Google [7] на тему технического долга в ML, иллюстрирует «датацентричные» и «моделецентричные» элементы в ML системах. В наши дни платформы MLOps помогают с множеством «моделецентричных» элементов, но лишь с несколькими «датацентричными» либо не затрагивают их вовсе:
Рис. 4: Моделе- и атацентричные элементы систем ML. В наши дни моделецентричные элементы в значительной степени покрыты MLOps системами
Следующий раздел демонстрирует некоторые из самых тяжелых испытаний, с которыми нам пришлось столкнуться в ходе упрощения производства ML. Они не являются всеобъемлющими примерами, но рассчитаны показать проблемы, с которыми мы сталкиваемся в ходе управления жизненным циклом ML data (функции и метки):
Небольшое напоминание, прежде чем мы погрузимся дальше: функция ML это данные, которые служат входящим сигналом для принятия решения моделью. Например, сервис доставки еды хочет в своем приложении показывать ожидаемое время доставки. Для этого необходимо предугадать длительность готовки конкретного блюда, в конкретном ресторане, в конкретное время. Одним из удобных сигналов для создания такого прогноза — прокси для того насколько ресторан загружен — будет «конечный счет» входящих заказов за последние 30 минут. Функция рассчитывается исходя из потока исходных данных порядка заказов:
Рис. 5: Исходные данные меняются функцией трансформацией в значения функций
Для создания любой функции или модели специалисту data science в первую очередь необходимо обнаружить корректный источник данных и получить к нему доступ. На этом пути есть несколько препятствий:
Исходные данные могут поступать из множества источников, каждый со своими, влияющими на извлекаемые из них типы функций, важными свойствами. Эти свойства включают в себя поддержку источником данных типов трансформации, актуальности данных, и объема доступного архива данных:
Рис. 6: Различные источники данных по-разному подходят к различным типам трансформации данных и предоставляют доступ к различным объемам данных в зависимости от актуальности
Важно учитывать эти свойства, так как типы источников данных определяют типы функций, которые специалист data science может получить из исходных данных:
Забегая вперед, обращаем внимание: комбинирование данных из разных источников с взаимодополняющими характеристиками позволяет создавать действительно хорошие функции. Подобный подход требует реализации и управления более совершенными трансформациями функций.
Формирование обучающих или тестовых наборов данных требует объединения данных соответствующих функций. При этом необходимо отслеживать множество деталей, способных оказывать критические воздействия на модель. Двумя наиболее коварными из них являются:
После того как модель выпущена в работу в реальном времени, для создания корректных и актуальных прогнозов ей требуется постоянно поставлять новые данные функций — зачастую масштабно и с минимальным временем ожидания.
Каким образом нам следует передавать модели эти данные? Напрямую из источника? Получение и передача данных из хранилища может занять минуты, дни, часы, или даже дни, что слишком долго для вывода данных в реальном времени и потому в большинстве случаев невозможно.
В таких случаях, вычисление функций и потребление функций необходимо расцепить. Для предварительного вычисления (пред-вычисления) функций и отгрузки их в оптимизированное для выдачи хранилище данных продакшна необходимо воспользоваться процессами ETL. Эти процессы создают дополнительные сложности и требуют новых трат на обслуживание:
Поиск оптимального компромисса между актуальностью и рентабельностью: Расцепка вычисления и потребления функций присваивает актуальности первоочередное внимание. Зачастую, за счет повышения стоимости, процессы функций могут прогоняться чаще и как следствие выдавать более актуальные данные. Корректный компромисс колеблется в зависимости от функций и вариантов использования. Например, функция агрегации тридцатиминутного окна конечного счета по доставке будет иметь смысл, если ее будут обновлять чаще, чем похожую функцию с двухнедельным окном конечного счета.
Интегрирование процессов функций: Ускорение производства функций требует получения данных из нескольких различных источников, и как следствие разрешения связанных с этим проблем, более сложных, чем как при работе лишь с одним источником данных, которые мы обсуждали до этого. Координация таких процессов и интеграция их результатов в единый вектор функций требует серьезного подхода со стороны инжиниринга данных.
Недопущение искажений при обучении (training/serving-skew [9]): Расхождения между результатами процессов обучения и работы могут привести к искажениям при обучении. Искажения при обучении довольно сложно обнаружить, а их наличие может привести в негодность прогнозы модели. Модель может повести себя хаотично при выводе заключений на основе данных, сгенерированных отлично от тех на которых она обучалась. Сам по себе вопрос искажений и работы с ними заслуживает отдельной серии статей. Тем не менее, стоит выделить два типичных риска:
Рис. 7 В целях недопущения искажений при обучении следует пользоваться единым методом реализации функций для и обучающих, и рабочих процессов
Рис. 8: График показывает конечный счет заказов: на (1) изображены значения функции, выданные для прогноза и обновляемые каждые 10 минут; на (2) изображены обучающие данные, которые некорректно отображают истинные значения намного четче по сравнению с функциями, выданными на продакшн
Что-нибудь да будет ломаться, не смотря на все попытки корректно обходить указанные выше проблемы. Когда ML система ломается, почти всегда это случается из-за «нарушения целостности данных». Данный термин может указывать на множество различных причин, каждая из которых требует отслеживания. Примеры нарушения целостности данных:
Подобные испытания создают почти непреодолимую полосу препятствий даже для самых продвинутых команд в области data science и ML engineering. Для их решения требуется нечто лучшее, чем неизменный статус-кво большинства компаний, когда индивидуальные решения на заказ остаются единственным ответом на подмножество этих проблем.
В Tecron мы создаем дата платформу для машинного обучения чтобы предоставить помощь с самыми обычными и самыми тяжелыми проблемами в области data science.
На высоком уровне, платформа Tecron имеет в себе:
Рис. 9: Будучи центральной дата платформой для ML, Tecton выдает функции в среды разработки и продакшна
Платформа позволяет командам ML привнести практики DevOps в ML data:
Конечно, ML data без ML модели не дадут вам практической реализации ML. Поэтому Tecton предоставляет гибкие API и интегрируется с уже существующими ML платформами. Мы начали с Databricks, SageMaker и Kuberflow, и продолжаем интегрироваться с взаимодополняющими компонентами экосистемы.
Автор: ITSumma
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/big-data/352714
Ссылки в тексте:
[1] сдаются и бросают попытки использовать ML: https://venturebeat.com/2019/07/19/why-do-87-of-data-science-projects-never-make-it-into-production/
[2] DevOps: https://en.wikipedia.org/wiki/DevOps
[3] ссылке: https://tecton.ai/blog/data-platform-ml/
[4] 80%: https://www.infoworld.com/article/3228245/the-80-20-data-science-dilemma.html
[5] MLOps: https://en.wikipedia.org/wiki/MLOps
[6] данными: https://martinfowler.com/articles/cd4ml.html
[7] работы Google: https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf
[8] Lyft`s Amundsen: https://github.com/lyft/amundsen
[9] training/serving-skew: https://developers.google.com/machine-learning/guides/rules-of-ml#training-serving_skew
[10] Источник: https://habr.com/ru/post/500272/?utm_source=habrahabr&utm_medium=rss&utm_campaign=500272
Нажмите здесь для печати.