Чтобы установить некоторый контекст, я хотел бы упомянуть «Т-образные» инженерные навыки.

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

Мое личное откровение здесь заключалось в том, что меня спросили, в чем заключается моя страсть после того, как я претендовал на титул «полный стек».

Ищем инженеров MLOps

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

Не было никакой возможности найти человека со ВСЕМИ требуемыми навыками и опытом для наших позиций MLOps.

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

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

Создание команды MLOps оказалось настоящей проверкой межфункциональной работы. Рассмотрим различные задействованные сквозные области:

  • Лучшие практики ML/AI: как вы реализуете свой процесс обучения с научной точки зрения? Вам нужна характеристика, проверка или выбор? Какие архитектуры имеют смысл? Является ли эволюция архитектуры модели более важной, чем переобучение на последних данных или наоборот?
  • Архитектура и реализация программного обеспечения: как вы реализуете эти передовые методы на прагматичной основе? Вам нужны микросервисы и/или процессы, управляемые событиями? Можно ли автоматизировать шаги в вашем конвейере? Должны ли мы реализовать уровень API перед вашей базой данных для доступа к приложениям? (Ответ ДА) Каковы компромиссы?
  • Самое главное, опыт предметной области. Вы работаете с контролируемой или неконтролируемой проблемой? Это может кардинально изменить ваш подход к обработке данных. В любом случае ваша команда должна быть хорошо знакома с задействованными данными и заботиться о них, как о собственных детях.

Пи-образный

После разговора с кем-то (все заслуга «пи» принадлежит ему), который также философствует в этом пространстве, мы быстро пришли к наблюдению, что люди приходят к MLOps в основном с двух возможных направлений. Либо они были учеными данных/исследователями искусственного интеллекта, либо имели опыт разработки программного обеспечения/DevOps. Нет, они, возможно, носили множество разных ярлыков на своем пути, но важнее их результирующий набор навыков.

Кто-то в начале своего пути MLOps, начав как «Т-образный» человек, теперь развивает другую «ногу» числа Пи.

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

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

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

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

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