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

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

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

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

Ошибка 1: речь идет не о создании платформы; Речь идет об ускорении доставки с помощью платформы

ловушка

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

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

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

Решение

Проведите время со своими пользователями и поймите их потребности

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

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

Замените «Платформа» на «Включение пользователей»

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

Чтобы решить эту проблему, команде вашей платформы крайне важно разработать обдуманную стратегию поддержки пользователей. Таким образом, вы можете гарантировать, что пользователи получат надлежащую адаптацию к платформе, доступ к рабочим часам и поддержку, которая поможет им преодолеть любые препятствия. Уделяя особое внимание расширению возможностей пользователей, ваша команда разработчиков платформы может предоставить пользователям возможность использовать ее и эффективно выполнять свою работу. «Долой платформу, вперед с поддержкой разработчиков»

Уделите приоритетное внимание обитаемости при разработке платформы

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

Ешьте собачий корм

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

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

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

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

Кроме того, вашей организации, вероятно, не хватает инженерных талантов ML по сравнению с ИТ-компанией, что вынуждает специалистов по данным браться за инженерную работу ML без надлежащей подготовки. Поскольку специалистов по данным очень мало, а инженеров по машинному обучению еще меньше, эта нехватка мешает пользователям вашей платформы предоставлять информацию в промышленном масштабе для производства и вызывает у них стресс и разочарование. Это заставляет их просить вас о «простом инструменте MLOps с приятным пользовательским интерфейсом», чтобы решить то, что на самом деле является проблемой ЛЮДЕЙ. Это возвращает нас к ловушке 1 в этом посте.

Эта ситуация возникла не только по вашей вине, поскольку внедрение облачных технологий, DevOps и машинного обучения может привести к разрушительным последствиям, особенно для ИТ-команд, которые всю свою карьеру занимались настройкой COTS-продуктов в традиционных SDLC, каскадных средах. Однако важно признать, что такие изменения требуют усилий по управлению изменениями в масштабах всей компании. Чтобы ваша платформа машинного обучения работала успешно, важно внедрить культуру DevOps и операционную модель, объединяющую людей, процессы и технологии. Такой подход позволит вам последовательно и эффективно приносить пользу бизнесу.

Решение

Выберите шаблон операционной модели для своей платформы

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

  • Централизованность — все команды специалистов по обработке данных и платформе сосредоточены в одной организации.
  • Децентрализовано — группы специалистов по обработке и анализу данных распределены по каждому направлению бизнеса (LoB).
  • Федеративное — команда платформы централизована, а группы по обработке и анализу данных принадлежат бизнес-направлениям.

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

Определяет четыре типа команд на вашей платформе

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

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

Три других типа команд могут быть частью централизованной команды платформы:

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

Настройте явное взаимодействие между командами, чтобы ускорить доставку

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

«Team Topologies» предлагает три режима взаимодействия между командами:

  • Сотрудничество: две команды, работающие вместе в течение определенного периода времени для решения сложной проблемы, например, команда инженеров ML, работающая с командой проекта ML, для перемещения моделей из эксперимента в производство.
  • X-as-a-Service: одна команда предоставляет, а другая использует что-то «как услугу», например, группа обеспечения соответствия предоставляет Approval-as-a-Service проектным группам машинного обучения, чтобы они могли перенести развертывание в рабочую среду.
  • Фасилитация: одна команда нуждается в помощи, опыте или знаниях от другой команды, например, от команды платформы, которая проводит обучение пользователей платформы по адаптации или MLOps.

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

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

Ошибка 3: остерегайтесь слова на букву «Г»

Подводный камень

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

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

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

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

Решение

Сделать правильные вещи максимально простыми

Чтобы помочь пользователям ускорить доставку, предложите Дороги с твердым покрытием или Золотые пути, которые поддерживают шаблоны проектов машинного обучения с ограждениями, учебными пособиями и поддержкой. Их пошаговые руководства содержат все необходимые шаги для их выполнения. Если ваши пользователи следуют за ними, они получают доступ к производственной среде без изучения всех технических деталей. Команды, которые не следуют рекомендованному пути, должны вручную заполнить контрольный список готовности к работе.

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

Внедрите самообслуживание на своей платформе

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

Ошибка 4: Связывание невыполненных работ и флуд запросов замедляют разработку вашей платформы

ловушка

Ваша команда платформы машинного обучения изначально была создана для повышения автоматизации и повышения производительности пользователей. Все началось с простой миссии и предложения: предоставить Jupyter Notebooks в облаке, на SageMaker или Kubeflow.

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

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

Решение

Разработка самой тонкой жизнеспособной платформы (TVP)

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

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

Можно ли начать с простого: «Вот ваша учетная запись AWS с SageMaker, некоторыми ограничениями и надстройками? Вот вики-учебник о том, как использовать вашу среду машинного обучения»?

Разбейте монолитную платформу на более мелкие продукты и команды

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

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

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

Ловушка 5: каково направление вашей платформы?

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

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

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

Решение

Институционализируйте свою платформу машинного обучения с помощью комплексной стратегии

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

Здесь я предлагаю работать с четырьмя столпами и примерами инициатив для каждого:

  • Адаптация и активация: план адаптации, встроенные инженеры по машинному обучению для поддержки проектов, программы непрерывного обучения и облачной сертификации, часы работы платформы.
  • Стандарты и управляемые проекты: шаблоны «Золотой путь», многоразовые шаблоны решений машинного обучения, ускорение процессов утверждения развертывания.
  • Операционное совершенство: дизайн платформы и дорожная карта, управляемая пользователями, управление основной инфраструктурой, управление данными, сбор отзывов пользователей (опросы, круглые столы, тестирование).
  • Жизнеспособность сообщества: программа Champions, Lunch and Learns, общественные мероприятия, награды за проекты.

Определить преднамеренные показатели

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

Ускорение раскрывает четыре ключевых показателя для измерения производительности доставки программного обеспечения в культурах DevOps: время выполнения изменений, частота развертывания, частота отказов изменений и MTTR. Определите прозрачные входные цели и выходные цели для вашей платформы. Для оценки организационного здоровья, включая скорость метаболизма, архитектуру программного обеспечения и способность запускать продукты в производство.

Получите менеджера по продукту, дорожную карту и процесс определения приоритетов

Менеджер по продукту имеет решающее значение в команде платформы, поскольку он определяет видение платформы, дорожную карту, собирает требования и расставляет приоритеты функций на основе влияния на бизнес и потребностей пользователей. Важно, чтобы продакт-менеджер имел опыт работы в современных ИТ и следовал четкому и прозрачному процессу приоритизации входящих запросов. Это гарантирует, что команда работает над важными функциями и может эффективно общаться с заинтересованными сторонами о новых функциях и улучшениях. Должен быть создан план реализации на 3–5 лет с последовательным, пошаговым подходом, чтобы установить реалистичные ожидания в отношении преобразования, которое закрепится. Дорожная карта должна быть прозрачной, чтобы установить четкие ожидания пользователей платформы.

Получайте краткосрочные выгоды, институционализируя свою платформу

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

Заключение

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

Вот дополнительные материалы, которые могут оказаться полезными по теме: