Ситуационная задача - “Бизнес просит срочно!”

Представьте, что вы работаете в продуктовой ML-команде. Продакт прилетает к вам с горящими глазами и говорит:

Нам срочно нужно предсказать, кто из клиентов уйдёт, прямо к пятнице, чтобы отправить им пуши. Время – два дня. Ты же сможешь?

Главная боль собеседований

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

Шаг 1. Бизнес-цель
Вопросы: что решаем, кто пользователь, как выглядит успех для бизнеса.
Что получаем на выходе: список бизнес-метрик и целевых эффектов.

Шаг 2. Данные
Вопросы: какой таргет, есть ли дисбаланс, утечки, сдвиги во времени, хватит ли объёма и качества.
Что получаем на выходе: риски и план подготовки данных.

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

Шаг 4. Метрика и порог
Вопросы: стоимость ошибок I и II рода, что важнее здесь Precision или Recall, нужна ли рабочая точка, PR-AUC или ROC-AUC, есть ли смысл в cost-sensitive подходе.
Что получаем на выходе: основная метрика плюс рабочий порог и вторичные метрики.

Шаг 5. Валидация и онлайн-проверка
Вопросы: корректная разбивка и контроль сдвигов, guardrails, дизайн A/B и окно измерения эффекта.
Что получаем на выходе: план оффлайн-валидации, A/B и мониторинга в проде.

Сохраняйте пост в закладки и возвращайтесь к этому фрейму перед собесом.

Как не потеряться на Kaggle: пошаговый гайд для новичков

Если вы только начинаете изучать машинное обучение, Kaggle может показаться чем-то вроде закрытого клуба. Но на самом деле, это лучшая площадка, чтобы перейти от теории к практике и понять, как всё работает.

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

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

Изучите раздел Datasets. Найдите темы, которые вам интересны: спорт, экономика, медицина и т.д. (проверить, стоит ли добавить больше информации)

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

Выберите первое соревнование. Лучше начать с чего-нибудь попроще. Самый популярный вариант для новичков, это “Titanic: Machine Learning from Disaster”.

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

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

Добавьте результат в портфолио. Это очень поможет потом на собеседованиях.

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

Ну и помните, что каждый ноутбук делает вас сильнее в аналитике, коде и понимании ML в целом.

Возвращаемся с нашей регулярной рубрикой Code Detective

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

Вот фрагмент кода:

import pandas as pd

data = pd.DataFrame({'value': [10, 15, 20, 25, 30]})
filtered = data[data['value'] > 20]

for i in range(len(filtered)):
    print(f"Элемент {i}: {filtered['value'][i]}")

Тут всё хорошо. Или нет? Есть какая-то ошибка? Если есть, напишите в комментариях:
1. Какую ошибку нашли;
2. Варианты её исправления.

Ответ мы опубликуем через пару дней, а посты этой рубрики можно посмотреть по хэштегу: #CodeDetective_MLinside

Как и обещали, вот ответ на пост. Да, в коде есть ошибка.

Объяснение:
После фильтрации у элементов датафрейма остаются те же индексы, в этом примере это 3 и 4, а в цикле i принимает значения 0 и 1

Исправление:

for idx, row in filtered.iterrows():
    print(f"Элемент {idx}: {row['value']}")
Или
for i in range(len(filtered)):
    print(f"Элемент {i}: {filtered['value'].values[i]}")

#CodeDetective_MLinside

Как нейросети изменили работу ML и DS

Думаем, если бы можно было выбрать «тему года» в 2025 году, ей бы точно стала тема ИИ. Нейросети уже прочно закрепились в работе, да и в повседневной жизни. Поэтому, мы подумали, что было бы здорово рассказать о том, где LLM уже дают прирост скорости и качества в работе ML инженеров.

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

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

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

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

Ну и не забывайте, что всё равно есть области, в которых магии от LLM ждать не стоит.

Учимся на практике: решаем реальные ML-задачки

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

Третья задача: Сегментация клиентов магазина

Что нужно сделать:
Разделить клиентов на группы по их поведению без заранее заданных меток

Как можно сделать:
▪️ Использовать признаки: общий чек, частота покупок, возраст, доход
▪️ Нормализовать данные
▪️ Применить K-Means или DBSCAN
▪️ Визуализировать кластеры через PCA

Данные можно взять на Kaggle: https://www.kaggle.com/datasets/vjchoudhary7/customer-segmentation-tutorial-in-python

Готовы попробовать? Делитесь своими результатами в комментариях.

Все посты этой рубрики можно посмотреть по тэгу: #петпроект_MLinside

Первая задача джуна

Начинать что-то новое всегда страшно. Кто-то откладывает реальную работу, потому что боится работать с продуктом, пока не разберется в нем «очень глубоко внутри», а кто-то считает, что для успешного начала нужно подтянуть теорию, еще порешать задачки. Но всё сводится к прокрастинации работы.

Поэтому, мы подобрали пять типовых задач для ML инженера позиции джуниор, чтобы вы понимали – как они выглядят в жизни и к какому результату вы должны прийти.

▪️Кейс 1. Сбор и чистка данных
Это рутина, которая делает все остальное возможным. Вам дают тему и источники, вы тянете сырые тексты или таблицы, убираете мусор, дубли и странные кодировки, приводите поля к одному виду и балансируете классы. Цель простая: получить набор, на котором не стыдно учить модель. Финал выглядит как аккуратный датасет плюс скрипт и README, чтобы любой смог повторить.

▪️Кейс 2. Baseline на бенчмарке
Команде нужна точка отсчета. Вы берете референсный конфиг, фиксируете версии и seed, гоняете модель на известном наборе и сверяете метрики с публичной вилкой. Смысл в том, чтобы понять, что у нас все собрано правильно. Ожидаемый итог: метрики в пределах нормы, логи и конфиг приложены, есть с чем сравнивать будущие улучшения.

▪️Кейс 3. Мини-пайплайн препроцессинга
Это превращение разрозненных шагов в один воспроизводимый прогон. Делаете короткий EDA, выносите очистку и трансформации в функции, сохраняете артефакты и проверяете на отложенной выборке. Цель - убрать ручные клики и магические константы. Результат - ноутбук или скрипт, который запускается сверху вниз и дает одинаковый выход.

▪️Кейс 4. Офлайн-оценка качества
Тут вы переводите качество в цифры, понятные команде. Выбираете уместные метрики, считаете их на разных сегментах, строите графики, фиксируете пороги. Контекст простой: по этим числам будут принимать решения. Финал - один скрипт оценки, таблица метрик с датой и короткий вывод, где видно, что стало лучше, а что просело.

▪️Кейс 5. Отчет по эксперименту и хенд-офф
Это упаковка работы так, чтобы коллега продолжил без вас. Коротко описываете задачу и гипотезу, откуда взялись данные и как готовились, какой конфиг модели, какие метрики получились и что делать дальше. Цель - экономия времени команды и сохранение знаний. Итог - аккуратный Markdown или ноутбук со ссылками и однозначным next step.

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

Продолжаем нашу регулярную рубрику Code Detective

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

Вот фрагмент кода:

import pandas as pd

df = pd.DataFrame({
    'group': ['X', 'X', 'Y', 'Y'],
    'value': [10, 20, 30, 40]
})

df['mean_diff'] = df.groupby('group').transform('mean') - df['value']

Тут всё хорошо. Или нет? Есть какая-то ошибка? Если есть, напишите в комментариях:
1. Какую ошибку нашли;
2. Варианты её исправления.

Ответ мы опубликуем завтра, а посты этой рубрики можно посмотреть по хэштегу: #CodeDetective_MLinside

Как и обещали, вот ответ на пост. Да, в коде есть ошибка.

Объяснение:
df.groupby('group').transform('mean') возвращает датайфрейм, но df['value'] – Series, в итоге получится что столбец df['value'] вычитается из каждого столбца полученного датафрейма, получим ошибку что df['mean_diff'] присваивается датафрейм

Исправление:

import pandas as pd

df = pd.DataFrame({
    'group': ['X', 'X', 'Y', 'Y'],
    'value': [10, 20, 30, 40]
})

df['mean_diff'] = df.groupby('group')['value'].transform('mean') - df['value']
print(df)

#CodeDetective_MLinside

A/B‑тесты в ML – это не только сравнение AUC, но и влияние моделей на выручку, удержание и поведение пользователей. На YouTube, в ВК и на канале в Дзен у нас вышло видео с Александром Дубейковским (ML-Engineer Авито, ex-Yandex, эксперт MLinside), где он рассказал про то, как проводить A/B тесты и как выбирать бизнес‑метрики и воронку метрик, чтобы не обмануться оффлайном.

Если еще не смотрели, то вот ссылки на разные площадки:
YouTube
Вконтакте
Дзен

Учимся на практике: решаем реальные ML-задачки

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

Четвертая задача: Предсказание отказа оборудования

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

Как можно сделать:
▪️ Поработать с временными окнами: считать среднее, дисперсию, тренд;
▪️ Обозначить целевую переменную: 1 — поломка в ближайшие N часов, 0 — всё ок;
▪️ Обучить: бустинг, Random Forest, LSTM.

Данные можно взять на Kaggle: https://www.kaggle.com/datasets/stephanmatzka/predictive-maintenance-dataset-ai4i-2020

Готовы попробовать? Делитесь своими результатами в комментариях.

Все посты этой рубрики можно посмотреть по тэгу: #петпроект_MLinside

Типичные ошибки во время испытательного срока

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

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

▪️Ошибка 1. Перерабатывать
На короткой дистанции это создаёт иллюзию сверхэффективности, но формирует завышенные ожидания. Ваш максимальный темп кажется нормой и вы начинаете жить на энергии «в долг». А теперь представьте, что кто-то из коллег пришёл с дополнительной, но очень важной и срочной задачкой. Но и без этого, через пару недель ваша продуктивность упадет, а у команды возникнет вопрос – что случилось?

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

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

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

▪️Ошибка 3. Излишняя самостоятельность
На старте вы не знаете карту системы, зависимости между командами и реальные бизнесовые цели. Выбор задачи на глаз легко приводит к тому, что вы тратите время не там, где это сейчас критично.

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

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

Сможете найти ошибку в коде?

Да, это наша регулярная рубрика Code Detective. Тут мы публикуем фрагмент кода, а вы смотрите, что с ним не так. Но помните, что ошибки может и не быть. Так что если хотите прокачать навык чтения и анализа чужого кода, а это крайне полезный навык в работе ML-инженера, рубрика вам пригодится.

Вот фрагмент кода:

import pandas as pd

df = pd.DataFrame({
    'A': [1, 2, 3],
    'B': [4, 5, 6]
})

# Хотим изменить B там, где A > 1
df.loc[df['A'] > 1]['B'] = 99
print(df)

Тут всё хорошо. Или нет? Есть какая-то ошибка? Если есть, напишите в комментариях:
1. Какую ошибку нашли;
2. Варианты её исправления.

Ответ мы опубликуем завтра, а посты этой рубрики можно посмотреть по хэштегу: #CodeDetective_MLinside

Как и обещали, вот ответ на пост. Да, в коде есть ошибка.

Объяснение:
df.loc[...]['B'] = 99 loc создает временную копию и присваивание не повлияет на исходный DataFrame

Исправление:

df.loc[df['A'] > 1, 'B'] = 99

#CodeDetective_MLinside

Завтра мы будем записывать третью часть подкаста: Виктор Кантор x Валерий Бабушкин

Если не смотрели первые две части, вас ждет замечательный вечер. Посмотреть выпуски можно на YouTube, в ВК или Дзен.

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

В комментариях вы можете написать свои вопросы Валерию Бабушкину, мы отберем самые интересные и передадим Виктору. Если хотите что-то узнать про ML System Design, работу в бигтехе или о чем-то еще - ждем вас в комментариях.

Что такое скрининг резюме и как его пройти

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

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

Цель этого этапа - понять, стоит ли инвестировать время в интервью с вами.

Теперь поговорим о том, как работает ATS. Эта система любит прямые совпадения. Заголовок должен звучать так же, как в вакансии или максимально близко.

Ключевые навыки должны встретиться в вашем резюме несколько раз: в шапке, в опыте, в блоке навыков.

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

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

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

И, конечно же, если у вас есть кейсы и несколько пет-проектов в портфолио, шансы пройти на собеседование кратно вырастают.

А если вам нужна помощь по составлению резюме, напишите в комментариях слово «Гайд», отправим вам ссылку на материал, который поможет правильно описать свой опыт и проекты.