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

Давайте углубимся в процесс MLOps — в частности, в некоторые основополагающие моменты, в которых большинство команд ошибаются . Как выглядит успешный процесс MLOps и как отдельные специалисты по машинному обучению могут помочь в построении этого процесса?

TL;DR

• Начните с продукта, а не модели
• Изучите данные в производстве , а не на вашем складе
• Начните с простого — с данных и моделей
• Сотрудничайте с инженерами

Начните с продукта машинного обучения

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

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

• PM / Business Stakeholder : Как выглядит успех?
• ML Person : Что (вероятно) возможно с ML?
• Инженер по продукту : что возможно и каковы ограничения?

Некоторые примеры плохо слаженных команд:

• Специалист по машинному обучению оптимизирует точность модели (а не бизнес-результаты!)
• Начаты проекты, которые невозможно решить с помощью машинного обучения.
• Модель не соответствует ограничениям производительности в производственной среде.
• Функции сложны или невозможны для вычисления в производственной среде.

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

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

Кто-то может спросить — разве все данные, доступные для обучения, не должны быть доступны в производственной системе?

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

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

• Домашний почтовый индекс пользователя : вероятно, это очень просто использовать в производстве. Запросить базу данных.
• Среднее местоположение пользователя за последние пять минут : вероятно, PITA! Данные о местоположении пользователя находятся в Kafka Stream? Насколько свежим он должен быть? Потоковые агрегации сложны! Вероятно проблемы с обучением/обслуживанием!

Начните с простого

Вероятно, самый распространенный совет по машинному обучению, но это хороший совет. Начните с простого решения.

Мое дополнение: большинство людей скажут вам начать с простой модели , но не менее важно начать с простых данных! Чтобы воспроизвести приведенный выше пример:

• Среднее местоположение пользователя за последние пять минут: трудно
• Последнее местонахождение пользователя: вероятно, намного проще!

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

Сотрудничайте с инженерами

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

Решение состоит в том, чтобы подружиться с инженерами и работать с ними на протяжении всей разработки модели машинного обучения. Создание любого проекта программного обеспечения не может быть выполнено изолированно, а машинное обучение изолировано еще хуже. Инженеры могут помочь с тем, «какие данные доступны», «о каких ограничениях я должен знать», «какие SLA выполнимы» и многое другое.

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

Вывод

Эти шаги не являются всеобъемлющим представлением процесса MLOps — есть много движущихся частей, которые ведут к успеху (обзоры кода, CI/CD, мониторинг и т. д.). Это отправная точка. Как упоминалось выше, большинство сбоев ML, которые я видел, связаны с проблемами выравнивания. Эти руководящие принципы процессов в первую очередь предназначены для того, чтобы помочь вам настроить вашу команду на успех.

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

Дэвид Херши — инвестор Unusual Ventures , где он инвестирует в машинное обучение и инфраструктуру данных. Дэвид начал свою карьеру в Ford Motor Company, где он основал команду по инфраструктуре машинного обучения. В последнее время он работал в Tecton и Defined AI , помогая командам MLOps внедрять эти технологии. Если вы создаете компанию, занимающуюся инфраструктурой данных или машинного обучения, свяжитесь с Дэвидом в LinkedIn .