Ответ
У меня есть несколько вопросов о работе и команде:
- О продукте и метриках: Над каким продуктом или бизнес-задачей работает команда? Какие ключевые метрики (business и ML) используются для оценки успеха проекта?
- О процессе: Как выглядит типичный workflow в команде — от получения задачи до вывода модели в production? Как организовано тестирование и мониторинг моделей?
- О стеке и инфраструктуре: С какими инструментами для feature store, экспериментов (MLflow, DVC), и вычислительными ресурсами (GPU/TPU) обычно работают?
- О команде: Как построено взаимодействие между Data Scientists, ML Engineers, аналитиками и product-менеджерами? Как часто происходит ротация по задачам?
Ответ 18+ 🔞
А, ну это прям классика, ебать мои старые костыли! Сидишь на собеседовании и пытаешься понять, не в говне ли ты тут вляпаешься. Давай по порядку, чувак, разложу как есть.
1. Продукт и метрики. Ну, ёпта, зависит от конторы, как водится. Может быть какой-нибудь рекомендашка для видосов, чтобы пользователь сидел и срал кирпичи от контента, а может — скоринг для кредитов, где от твоей модели зависит, дадут ли челу бабки или пошлют нахуй. Бизнес-метрики — это святое, их product-менеджеры с анальной тщательностью выписывают: там ARPU, конверсия, retention, LTV — вся эта ебалова гитара. А наши, ML-метрики — это уже наше, внутреннее развлечение: accuracy, precision-recall, AUC-ROC, MAP@K, если рекомендации. Главное — не уйти в себя, в эти свои красивые графики, а чтобы бизнес-циферка в итоге шевелилась. Иначе все твои модели — хуй с горы, а не помощь бизнесу.
2. Процесс. О, тут может быть ёперный театр, если процесс не отлажен. В идеале всё как у людей: прилетела задача -> обсудили с продактом и аналитиками -> наковыряли фичей из feature store или нагенерили -> зафигачили эксперименты в MLflow -> лучшую модель завернули в API, накормили тестами (юнит, интеграционные, A/B) и выкатили в продакшн. Мониторинг — это отдельная песня: смотрим не только на технические метрики (латентность, ошибки), но и на качество предсказаний (data drift, concept drift). А то бывает, модель вчера работала, а сегодня накрылась медным тазом, потому что пользователи вдруг стали делать что-то невообразимое.
3. Стек и инфраструктура. Тут разброс, блядь, овердохуища. Feature store — часто свой велосипед на Spark или Feast. Для экспериментов — MLflow святая святых, иногда DVC для данных. Вычислилки — если не бедный стартап, то обычно кластер с GPU (Nvidia, само собой), на котором юзаем Kubernetes, чтобы моделки в контейнерах бегали. В особо жирных конторах могут быть и TPU, но это уже для избранных, кто нейросетями тяжёлыми балуется. Главное, чтобы инфраструктура не была такой пиздопроебибной, когда полдня потратишь не на модель, а на то, чтобы скрипт запустить.
4. Команда. Всё упирается в коммуникацию, чувак. Идеал — когда data scientists, ML-инженеры и аналитики сидят в одной кухне (или хотя бы в одном Slack). Продакты ставят задачи, аналитики помогают с гипотезами и дата-инсайтами, мы — пилим модели, а ML-инженеры — это те герои, которые всю эту красоту превращают в работающий сервис. Ротация по задачам — обычно есть, чтобы не закиснуть. Раз в квартал-полгода можно переключиться: с рекомендашек на фрод-детекшн, например. Это полезно, а то подозрение ебать чувствую, когда человек пять лет одну и ту же линейную регрессию дотачивает.
Вот, короче, примерный расклад. Но имей в виду: в каждой конторе свой адок, свои тараканы и свои хитрые жопы в менеджменте. Всегда смотри, как люди между собой общаются — это самый честный показатель.
Видео-ответы
▶
▶
▶
▶
▶
▶
▶
▶
▶
▶
▶
▶
▶
▶
▶
▶
▶
▶
▶
▶
▶