В 16-м выпуске отчета о бизнес-аналитике в партнерстве с Bright Talk мы более подробно рассмотрим решения для машинного обучения, в частности, машинное обучение, ориентированное на данные, и конвейеры машинного обучения, в беседе с Радждипом Бисвасом, директором Advanced Аналитика и машинное обучение в Microsoft и Ник Спирин, соучредитель и генеральный директор Metapixel AI

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

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

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

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

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

Одна вещь, которую люди должны понять, - это концепция дрейфа модели производительности модели и дрейфа данных. Как это вписывается в MLOps и с точки зрения управления моделями и дрейфом?

Необходимо изучить два разных разговора. Один про MLOPs

На данный момент мы находимся на этапе, когда организациям следует задуматься о внедрении этих практик. Нам нужно внедрить эти бесконтактные системы, реализуя цикл DevOps, когда вы работаете в своей среде разработки, которая автоматически переходит в QA, а затем после определенных автоматических тестов и некоторых ворот качества каждая из них должна перейти в производство.

Есть проблемы с подготовкой данных, потому что у нас есть несколько источников данных, несколько форматов, а затем очистка и преобразование.

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

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

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

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

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

Чтобы решить эту проблему, на помощь приходит объяснимый ИИ как подполе, которое выступает за большую интерпретируемость в разработке модели ИИ.

Каковы проблемы в этом сценарии?

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

Многие люди знакомы с перекрестной проверкой и статистической оценкой моделей. У вас есть образец ваших данных, вы берете подмножество своих данных и в качестве задержки обучаете 80% своих данных, а затем оцениваете их на оставшихся 20%, которые модель не видела раньше во время обучение. Если в этих 20 % есть внутреннее смещение, модель будет иметь проблемы и не будет точно отражать выборку».

Ник Спирин

Как организация, которая думает о создании приложений машинного обучения, должна подумать о разработке конвейера для конкретного варианта использования в отрасли и какие соображения следует учитывать при разработке этого конвейера?

Во-первых, нам нужно понять, что влияние ИИ не застраховано от принципа Парето. Таким образом, от 80% до 90% ценности приходится на 20% потенциальных вариантов использования. Первое, что должна сделать любая отрасль, — это найти те ценные малозависимые варианты использования, которые являются хорошими кандидатами для приложений машинного обучения. Большим преимуществом является то, что даже если мы говорим об отраслевых проблемах, стартовая фаза достаточно обобщена.

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

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

Бизнес-лидеры также должны учитывать сторону создания или покупки, потому что даже если они определили вариант использования, им нужна либо собственная наука о данных, либо им нужно обратиться за коммерческим предложением для его создания. Они должны думать о качестве стоимости, качестве данных, и им нужно смотреть на данные, как они будут их анимировать, насколько они могут полагаться на устаревшую систему данных. Так терпение становится добродетелью.

Каковы ваши последние мысли при рассмотрении вопроса о конвейерах машинного обучения и машинном обучении, ориентированном на данные, и каковы ваши рекомендации?

Во-первых, важно подумать об этой проблеме на уровне платформы и начать думать о строительных блоках, которые вы могли бы начать повторно использовать в своей организации, чтобы со временем обеспечить более широкое внедрение ИИ. Только в 2015 году в Гугл было всего несколько масштабных приложений машинного обучения; сейчас вроде более 1000 разных приложений.

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

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

Этот разрыв приводит к тому, что проекты терпят неудачу с еще большей скоростью. От 70% до 89, 90% всех программ цифровой трансформации терпят неудачу, производственные модели машинного обучения затем терпят неудачу и не могут быть развернуты.

Люди думают об изолированных приложениях ML, а не систематически на уровне организации, чтобы сбалансировать спрос и предложение. Вот почему от 60% до 70% всех цифровых преобразований терпят неудачу. Крайне важно не рассматривать эти варианты использования изолированно, так как вы хотите найти варианты использования, которые дополняют друг друга.

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

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

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

Подробнее о конвейерах машинного обучения

"Кликните сюда"