Знакомство с инструментами машинного обучения (часть 2 из 3)

Текущие инструменты машинного обучения и их внедрение

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

В этой серии сообщений в блоге я постараюсь ответить на следующие вопросы:

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

Эта запись в блоге посвящена второму вопросу.

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

Суть земли

Говорить о переполненном инструментальном ландшафте машинного обучения ни в коем случае не будет преувеличением. По состоянию на конец 2021 года в MAD Landscape (то есть «Машинное обучение, ИИ и данные») перечислено более 2000 (это число включает несколько дубликатов) коммерческих проектов и компаний с открытым исходным кодом (Turck, 2021). И это лишь один из нескольких подобных обзоров: (TWIML, 2021), (LF AI & Data Foundation, 2022), (Hewage, 2022), (Ruf, 2021).

Прежде чем идти дальше, имеет смысл уточнить некоторые термины по этой теме. Часто встречаются сквозные платформы машинного обучения, называемые, среди прочего, платформами MLOps (thoughtworks, 2021), платформами обработки данных и машинного обучения (DSML) (Turck, 2020). Однако после обсуждения в предыдущем сообщении в блоге имеет смысл использовать термин «платформа ML» для охвата всех таких предложений, поскольку, возможно, MLOps, как правило, является конечной целью зрелости ML. Я также склоняюсь к тому, чтобы отказаться от термина «от начала до конца», поскольку платформы машинного обучения обычно стремятся обслуживать все этапы рабочего процесса машинного обучения. Отдельно от платформ термин «инструментарий» используется для обозначения программного обеспечения, которое выполняет определенный шаг в рабочем процессе машинного обучения. Я могу время от времени использовать инструментарий, чтобы ссылаться на них вместе, что должно быть ясно из контекста, или иным образом использовать «решения», чтобы ссылаться на них вместе.

Хотя несколько обзоров различаются по своей методологии и широте охвата, есть ряд точек соприкосновения. Во-первых, наблюдается недостаточная зрелость самой инструментальной экосистемы, что связано с отсутствием какой-либо одной платформы, поддерживающей полностью автоматизированный рабочий процесс ML, или, по крайней мере, платформы, доступной для широкого круга заинтересованных сторон (Ruf, 2021). Связанный момент можно сделать для специализированных инструментов, которые в зависимости от их подхода могут поддерживать более одной задачи ML (TWIML, 2021). Во-вторых, платформа машинного обучения считается «хорошей» в той мере, в какой она, среди прочего, охватывает все аспекты рабочего процесса машинного обучения, допускает автоматизацию и поддерживает несколько языков, фреймворков и библиотек (Hewage, 2022). В-третьих, в существующих решениях наблюдается большое расхождение в уровне реализации разных задач машинного обучения (Felipe & Maya, 2021). Было бы разумно предположить, что многие из этих проблем являются прямым следствием отсутствия согласия относительно того, как практически реализовать рабочий процесс ML на практике, как обсуждалось в последнем сообщении в блоге.

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

Это платформа или специализированный/частичный инструмент?
Является ли это специфичным для машинного обучения или применимо к разработке программного обеспечения (SWE) в целом?
К каким этапам жизненного цикла ML он относится?

Этот более поздний критерий является особенно субъективным, поскольку он является спорным относительно того, к каким конкретным задачам относится данный инструмент, например. наблюдаемость данных касается практически всего (TWIML, 2021). Две такие схемы представлены (thinkworks, 2021) и (Miranda, 2021a). Я предпочитаю последнее, так как оно предоставляет средства для понимания инструментов машинного обучения в более широкой среде SWE, а также обеспечивает основу простой структуры для понимания текущего состояния зрелости инструментов, даже если они не связывают инструменты напрямую с рабочим процессом машинного обучения. состояния. Эта структура окажется полезной, когда мы рассмотрим, как оценивать выбор инструментов ниже.

Внедрение инструментов машинного обучения

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

В случае со зрелыми компаниями это во многом связано с отсутствием (зрелых) альтернатив — в конце концов, они лидируют в этой области. Это особенно верно, когда речь идет конкретно об инструментах MLOps: хранилища функций, обслуживание моделей и т. д. В обзоре конкретных компонентов платформы MLOps среди преимущественно крупных американских B2C только компонент оркестровки рабочего процесса платформы ML часто использует решения с открытым исходным кодом, обычно Kubeflow. Трубопроводы или воздушный поток (Чан, 2021). Это может быть связано с тем, что это наиболее общий рассматриваемый компонент (dotscience, 2019). Среди таких компаний цели разработки собственных платформ машинного обучения двоякие (Symeonidis, 2022): во-первых, цель состоит в том, чтобы сократить время, необходимое для создания и доставки моделей, а во-вторых, чтобы поддерживать стабильность и воспроизводимость прогнозов; или, другими словами, для рассмотрения этапов доставки и развертывания MLOps соответственно. Может ли эта картина измениться по мере развития инструментальной экосистемы в целом? Наверное, не так уж и много. Это по трем основным причинам. Во-первых, любой существующий инструментарий возник как непосредственный ответ на конкретный стратегический ответ данной компании, для которого может быть нежелательно делать его более широко доступным, или его было бы трудно воспроизвести извне, если учесть два приведенных выше пожелания. Во-вторых, и в связи с этим может оказаться невозможным создать полнофункциональную альтернативу извне. В-третьих, успех на этом уровне определяется не одной технологией, а ее сквозной интеграцией, что создает дополнительный барьер для сторонних инструментов. Как говорит Мэтт Терк: «Успех больших данных [или ML/AI] заключается не во внедрении одной технологии… вместо этого требуется собрать воедино конвейерную линию технологий, людей и процессов». (Терк, 2016).

В случае незрелых компаний склонность к внутренним решениям во многом обусловлена именно этой незрелостью: у них может не быть ни технических навыков, ни бюджета для приобретения сторонних инструментов (dotscience, 2019). Соответственно, им может быть трудно обосновать потребность в таких инструментах именно потому, что нет эталона для сравнения, особенно если учесть, что эти инструменты в значительной степени используются для оптимизации известного процесса. Как мы увидим ниже, существует непреодолимый компромисс между созданием рабочего процесса машинного обучения по частям или выбором платформы, которая охватывает рабочий процесс от начала до конца; любой подход обязательно приводит к техническому долгу (Ruf, 2021). В любом случае может быть сложно найти предложения, соответствующие требованиям компании, из-за отсутствия консенсуса в отношении реализации рабочего процесса машинного обучения (см. предыдущий пост) и отсутствия полнофункциональной платформы машинного обучения (TWIML, 2021). И наоборот, может быть слишком сложно сопоставить сторонние варианты с существующими реализациями конвейера ML (подробно обсуждается ниже). Связанная с этим проблема: для многих из этих компаний доступные инструменты могут не соответствовать их потребностям по ряду причин, в частности из-за различных проблем с соблюдением требований. Например, текущий набор решений для маркировки данных, в которых обычно используются аутсорсинговые или контрактные работники, вряд ли подходят во многих случаях, таких как регулируемые области, такие как финансовые услуги (Vanian, 2021). Для многих предприятий, как правило, более желательно обеспечить полный контроль и право собственности на данные, а также избегать передачи данных нескольким сторонам. Такие компании, как Snorkel AI, стремятся напрямую решить эти проблемы.

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

Решения, решения, решения

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

Самый быстрый путь к полному внедрению MLOps — сосредоточиться на полном сквозном жизненном цикле машинного обучения или, используя терминологию, использованную в (Stiebellehner, 2022a), сначала сосредоточиться на глубине функциональности, а только затем на широте возможностей. функции. Это имеет дополнительное преимущество, заключающееся в сокращении времени и затрат, связанных с проверкой идеи, так что содержательную обратную связь можно получить раньше, чем позже.

Как уже говорилось, в настоящее время не существует общепризнанной полной сквозной платформы машинного обучения. Это оставляет выбор между текущим набором платформ машинного обучения и/или объединением рабочего процесса машинного обучения из различных автономных специализированных инструментов. Со стратегической точки зрения может быть нежелательно идти ва-банк с одним поставщиком платформы, поскольку он может не соответствовать вашим потребностям в долгосрочной перспективе и может привести к привязке к поставщику, а это означает, что любое последующее изменение представляет собой большую альтернативную цену. И наоборот, разработка процессов вокруг автономных инструментов может означать создание большего объема внутренней работы, чем хотелось бы, особенно если главной целью является скорость доставки. В любом случае, следуя приведенной выше схеме, чем более зрелым является данный инструмент или платформа и в определенной степени чем более фрагментарным является инструмент, тем безопаснее выбор (Miranda, 2021b).

В частности, для предприятий, где машинное обучение не является основной функцией, общий совет состоит в том, чтобы покупать, а не создавать, и добавлять настраиваемые интеграторы между этими компонентами, будь то платформы или специализированные инструменты (Miranda, 2021b). Выбор инструмента должен основываться на непосредственных целях доставки с упором на интеграцию и дублирование этих компонентов; цель состоит в том, чтобы выбрать наименьший удовлетворяющий набор вариантов. Поскольку основное внимание уделяется глубине, а не широте, такие факторы, как масштабируемость или автоматизация, не должны быть главными проблемами. Вопросы, которые следует задать, включают в себя, какие языки поддерживает каждый инструмент для облегчения взаимодействия, и не приведет ли какой-либо набор инструментов к избыточности из-за их перекрывающихся функций; На такие вопросы можно ответить только с опытом, поэтому крайне необходимо повторять и учиться на своем процессе (Ruf, 2021). Наглядным примером внедрения инструментов является Kubeflow, который, хотя и обеспечивает поддержку сквозной платформы ML, видел только отдельные элементы, такие как Kubeflow Pipelines, которые получили широкое распространение.

Что на Горизонте?

Один из центральных споров вокруг текущего набора инструментов заключается в том, стоит ли нам ожидать какой-либо консолидации, и если да, то когда. Большинство наблюдателей ожидают какой-то рационализации, однако параметры далеко не ясны (Turck, 2021). Своего рода консолидация, «функциональная консолидация», уже наблюдалась для устоявшихся и успешных решений, таких как Databricks и Snowflake, где наблюдается тенденция к полнофункциональному сквозному предложению (Turck, 2021). Это вполне может быть частью более общей тенденции многих успешных сторонних решений, которые, как правило, были компонентом гораздо более крупной экосистемы, например. Снежинка и AWS. Помимо этого, мы можем ожидать появления дополнительных предложений услуг от крупных облачных платформ либо за счет внутренних инноваций, либо за счет слияний и поглощений.

До сих пор любая более широкая рационализация инструментов и процессов, как правило, сводилась на нет возрастающей сложностью требований к данным и инструментам, а также темпами таких изменений. Это очевидно в отношении инструментов MLOps и DataOps, которые в настоящее время обычно обрабатываются с помощью внутренних инструментов (Turck, 2020). Дальнейшее торможение прогресса связано с широко наблюдаемой нехваткой талантов, которая, как ожидается, сохранится в долгосрочной перспективе (O’Shaughnessy, 2022), хотя в определенной степени это можно смягчить с помощью дополнительных инструментов.

Инструменты проверки качества данных и наблюдаемости в настоящее время пользуются наибольшим успехом на рынке именно благодаря тому, где рынок находится с точки зрения общей зрелости МО (Stiebellehner, 2022b). Однако мы, похоже, вступаем в новую фазу инструментов машинного обучения и машинного обучения/ИИ в целом. Учитывая заметный рост числа стартапов, посвященных MLOps, можно ожидать, что в ближайшем будущем операционализация станет преобладать (Shankar, 2021). Тем не менее, с общим охлаждением найма ИИ (Huyen, 2020) и общим сокращением венчурного финансирования (Turck, 2022), кажется, что консолидация может быть не за горами. Что касается технологических разработок, я оставлю обсуждение для третьего сообщения в этой серии блогов, однако я ожидаю, что ИИ, ориентированный на данные, MLOps и AutoML станут ключевыми тенденциями в инструментах ML в ближайшем будущем.

Заворачивать

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