Ребята, всем привет! Нужный экспертный совет на тему: как должна

быть устроена идеальная ML команда?

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

Вопросы:
1. Сходу заметил странность, что ML инженеры выполняют дополнительно роль Data инженеров - выкладывают задания на толоку, передают их разметчикам, аккумулируют результаты и т.д. - на это у них уходит под 80% времени, а на эксперименты с моделью 20%. Это адекватно или правильней всё же выделить работу по подготовке данных в отдельную роль?
2. В многих статьях фигурирует роль ML Researcher'а. Как я понял, это чувак, который проводит эксперименты с данными и моделями для того, чтобы проверить гипотезу до передачи их ML-инженерам. На сколько роль обязательна? Возможно ли совмещение ML Инженеров с этой ролью? Условно, в рамках спринта брать задачу на такой-то эксперимент - проверили, пошли дальше по основной задаче дела делать.
3. Как описал ранее, ML инженеры специализируются на работе со звуком и видео. При это в бэклоге есть задачи связанные с простым предсказанием на основе деревьев решений. Ребята не против поэкспериментировать, но боевого опыта у них нет. Как мне кажется, работа с нейросетями сложнее и "спустится" до уровня деревьев решений особых проблем быть не должно. На сколько я близок к истине? Может быть лучше подрядчиков найти под такую задачу или отдельного человека взять под такие истории?

2 фронта для внедрения на прод, чего блять? А бэком у вас кто занимается? Девопсы что ли?

Data Engineer история гораздо больше чем выкладывают резы, выкладывать задания на толоку и другое

Компания не маленькая, а ML команда только одна. Пока задач, связанных с бэком не было. Если нужен будет - возьмём или в другой команде одолжим. Сейчас в работе конкретно 2 задачи - размытие/замена фона + шумоподавление. Вот это и внедряют. Продукт - сервис ВКС, фронта очень много

а как вы модели крутите друг?

текущую инфраструктуру используем. Та же замена фона уже была, но плохого качества (делали студенты много лет назад)

1. Для сбора, разметки данных и других несложных задач есть профессия Data Associate 2. ML Researcher это Applied Scientist. Эту роль сложно совместить с ML инженером. Роль обязательная если у вас много данных и есть простор для творчества. 3. ML инженеры должны делать задачи на деревья решений

С чего бы DLE должен делать работу классических MLщиков?

Ну так что? Объясни пж свою позицию по 3 пункту

1. Иногда 1 дата-инженер может обслужить команду из 5-10 ML-инженеров (особенно, когда источников данных не так много, а инфраструктуру не нужно ваять с нуля). Поскольку 0.5 дата-инженера вам не хватает (у вас, по твоим подсчётам, сейчас аж 1.5 дата-инженеров), точно нужно нанять одного человека под это дело. Но вот, кажется, ты всё-таки просто приписываешь все трюки с данными дата-инженеру, а выкладывать задания на толоку и кому-то там их передавать вообще не выглядит сложной работой и можно взять джуна/миддла дата-сайнтиста, который будет отвечать за такие процессы + покроет часть хотелок из п.3 (так у него как раз наберётся и часть, где он с моделями работает, и часть, где он в данных копается, а дата-инженер сделает так, чтобы облегчить все эти передачи данных туда-сюда, выстроит пайплайны). А так, иногда на работу с данными и должно уходить 80%, а на модельки всего 20%, это бывает нормой 2. Ну, если есть возможность тратить бюджет на отсутствие результата (= на потенциальный результат) и простор для исследований, то нанимайте. Если уж рассматривать идеальную команду в вакууме, там такой чел (а лучше несколько) точно будет 3. Непонятно, как они будут это делать, если 1. на данный момент они даже своё, судя по контексту, еле осиливают 2. они не умеют это делать. Кто будет проверять, что они выбрали правильный подход? Зачем уменьшать эффективность челов в долгосрочной перспективе, если задачи на табличные данные будут регулярными (из контекста они уже в беклоге, не кажется, что это какой-то редкий случай)? Если задач мало (но они всё ещё регулярные), их может покрыть и чел из п.1 в перспективе. Если задач много, нужен отдельный чел, который будет менторить чела из п.1 4. Почему не нанять техлида, который полностью покроет п.3 и заодно закроет ваши дыры в бэке/инфре + наймёт действительно нужных людей (возможно, в кол-ве 1шт.) для данных? Требования: практический опыт в DL + классическом ML + выведении моделей в прод, базовое понимание БД. Профит

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