2020 год был… эээ… вы знаете, это было нехорошо. Однако были и серебряные накладки. Для тех из нас, кто практиковал машинное обучение (ML), Сообщество MLOps было очень нужным форумом. Даже до пандемии это сообщество было бы очень приветствуемым событием, но, возможно, не было бы таким же без реальности, которую COVID навязывает всем. Сообщество MLOps было порождением 2020 года. Если вы его пропустили или хотите подвести итоги, эта статья направлена ​​именно на это.

Хотя эта статья является своего рода сообщением TL; DR, я действительно хочу отметить, что я многое упускаю. В этом сообществе произошло столько всего, что я не могу рассказать обо всем. Имея это в виду, если вам нравится то, что вы читаете, и вы хотите узнать больше, загляните в сообщество на Slack и YouTube.

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

MLOps - это культура и практика

Одним из аспектов дискуссий внутри сообщества, которые продолжали возникать снова и снова, был подход или, возможно, я бы сказал определение MLOps. Лучше всего это описать как инженерную культуру и практику, направленную на объединение разработки систем машинного обучения (Dev) и эксплуатации систем машинного обучения (Ops). Эта фраза взята из основополагающего блога MLOps: конвейеры непрерывной доставки и автоматизации в машинном обучении (см. Обзор Дэвида Апонте здесь).

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

Это очень хорошо нашло отражение в подкасте Шубхи Джайна из SurveyMonkey, где он обсуждал формирование и штурм команды машинного обучения. Подход, основанный на консенсусе, который они использовали на раннем этапе, звучал для меня как классический Scrum, и это подход, который я считаю бесценным при создании новой команды с новой миссией. Я не был удивлен, узнав, что команда выбрала подход, основанный на принципах строительство вместо покупки, учитывая ограничения их технического стека и дату начала (казалось, пару лет назад) в дополнение к относительной незрелости инструментов MLOps. Не было сюрпризом и то, что состав команды был немного сложным для инженеров, а передача знаний между ролями в области науки о данных и инженеров была плавной. Во многих отношениях это обеспечивает хороший каркас, на котором мы строим наши представления о формировании и атаке MLOps.

То, как вы решите формировать и штурмовать команду, оказывает большое влияние на решения о создании или покупке. Мне нравится, как выразился Нил Латия - большинство из них предпочтут строить, а не покупать, поскольку инвестиции идут в команду, т.е. вам нужны квалифицированные и талантливые специалисты по данным и инженеры (я перефразирую это и буду продолжать делать это на протяжении всего периода). Почта). Команду нельзя купить, но можно ее построить. Независимо от инструментов, их приобретенные навыки и, осмелюсь сказать, эмоциональные вложения необходимы для долгосрочного успеха.

Точка зрения Шубхи также коснулась проблем, связанных с построением с нуля - сосредоточение внимания на создании над покупкой на протяжении всего жизненного цикла машинного обучения - и дала слушателям ощущение масштаба - их команда состоит из примерно 15 членов команды, которые справляются с 30-40. времени и созревания технического стека MLOps с момента создания этой команды, мне интересно, изберут ли они другой подход при формировании своей команды сегодня. Будет ли больше места для покупки или, по крайней мере, меньше строительства?

Простота и сложность нашей идентичности

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

Похоже, что еще одним способом преодоления разрыва стало создание большего количества ролей и «гирляндной цепи». Я считаю это потенциально проблематичным, поскольку наша отрасль борется с идентичностью этих ролей. Например, в чем разница между аналитиком данных и специалистом по анализу данных? Специалист в области данных полного цикла? Инженер ML? Инженер по данным? Облачный инженер? И, пожалуй, самое главное, когда, почему и как важно различие?

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

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

Два инструмента, которые могут привести к результату на 90%

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

На YouTube и Slack было много разговоров о Kubeflow. Мое внимание действительно привлек Дэвид Арончик, который был соучредителем Kubeflow и ведущим менеджером по продукту Google Kubernetes Engine. Обсуждение вращалось вокруг того, как был задуман Kubeflow, и на выяснении того, как уменьшить входной барьер для разработки больших моделей. Я нашел этот доклад проницательным. Это дало мне лучшее представление о выборе дизайна в Kubeflow и напомнило мне Шаблоны проектирования с машинным обучением, которые могут быть полезной сопутствующей книгой, которая поможет контекстуализировать этот выбор дизайна.

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

О магазинах функций говорили не так много, как о Kubeflow. Однако они предлагают то, чего не может предложить Kubeflow. Другими словами, если вы можете предоставить возможность магазина функций плюс то, что предлагает Kubeflow, это 90% идеальной платформы MLOps. Период. Хорошо, это звучит слишком просто, но с архитектурной точки зрения я считаю, что это правильно.

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

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

Tecton и другие предлагают покупать, а не строить. Однако, как уже упоминалось многими другими, вы можете создать его самостоятельно. Например, Нил писал о том, как это было сделано в Monzo, а Томас Морейра обсуждает подход Mercado Libre. Я тоже реализовал свой собственный магазин функций, используя хранилище данных OLAP (например, BigQuery) и инструмент оркестровки (например, dbt). Это соответствовало моим требованиям, но, честно говоря, не отвечало требованиям к онлайн-свежести, о которых я упоминал выше - потребуется инструмент обработки несвязанных данных (например, Apache Beam).

Этическое мышление

Во вступлении я написал: «[c] необходимо уделить внимание людям и процессам…» Это не только в отношении формирования и штурма команд машинного обучения. Это также может относиться к процессу проектирования выбора вариантов использования машинного обучения, а также к лучшему пониманию людей, на которых эти варианты использования окажут положительное и отрицательное влияние.

Предупреждающие слова Чарльза Рэдклиффа хорошо подчеркивают это. Он приводит довольно известный пример, Cambridge Analytica, которому не хватало технических талантов, а скорее моральной основы. Хотя их специалисты по обработке данных и инженеры были технически опытными, они не смогли ответить на самый важный вопрос - должны ли мы это делать? Чарльз говорит, исходя из опыта работы в области финансов во время глобального финансового кризиса 2007–2008 годов. (GFC). После этого события он увидел, как репутация банкиров, а также финансовые рынки, на которых они работают, рушатся из-за отсутствия этического сознания.

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

Политика может расширять возможности. Однако, если мы сосредоточимся только на этом, действительно ли мы делаем все возможное? И означает ли это, что мы должны больше сосредоточиться на технических решениях?

Чарльз пишет о том, как компании объединяют два связанных, но отдельных аспекта управления технологиями, игнорируя при этом подлинное этическое мышление. Технологи чувствуют себя наиболее комфортно со стандартами и процессами. Они склонны искать инженерные решения проблем. Вот почему большая часть разговоров об этике сводится к обсуждению «прозрачности, объяснимости и смягчения предвзятости. Это критические проблемы, но, кстати, также и проблемы, связанные с технологическими решениями. Вторая путаница - это противоречие между этикой и нормативно-правовыми вопросами. Общий регламент по защите данных (GDPR) и Закон о конфиденциальности потребителей Калифорнии (CCPA) сделали многое для повышения осведомленности о том, что, возможно, аналитике данных нужно какое-то господство - , но также убаюкали многих комментаторов по этому вопросу, заставив их почувствовать, что степень дискуссии по этике и ответственность за ее управление лежит на регулирующих органах, а не на более широком сообществе ».

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