Какие библиотеки и фреймворки должен знать ML/DS в 2026 году?

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Если Вы только входите в ML/DS, очень легко попасть в ловушку: пытаться выучить «все библиотеки мира» — на практике это почти никогда не нужно. Гораздо важнее понимать, какие инструменты закрывают базовый рабочий цикл: подготовку данных, обучение моделей, эксперименты и доведение решения до продукта.

Вот список того, что в 2026 году реально стоит знать ML/DS-специалисту, чтобы уверенно решать задачи и подходить под основные требования в вакансиях 👇

💻 NumPy + SciPy

Это две библиотеки для численных вычислений и базовой статистики.

NumPy часто используется при обработке Big Data — он особенно полезен, когда данных реально много, и базовые питоновские конструкции типа циклов или встроенных списков не справляются либо работают непомерно долго.

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

💻 Pandas, а лучше Polars!

Pandas — устоявшийся стандарт для работы с табличными данными, и до сих пор он используется в подавляющем большинстве компаний. Однако в 2026 году важно смотреть шире: к сожалению, Pandas ограничен тем, что не способен без дополнительных приёмов обрабатывать данные паралелльно + не поддерживает режим «ленивой» обработки для экономии памяти.

Поэтому в задачах, где размер таблиц исчисляется более чем десятками миллионов строк, наилучшим выбором будет библиотека Polars! Её синтаксис очень похож на Pandas, но работает она гораздо быстрее и эффективнее.

Так что на 2026 ориентир такой: уверенно знать Pandas и постепенно смотреть в сторону Polars как более производительной альтернативы.

💻 Scikit-learn

Это всё ещё главный и незаменимый must-have для классического ML. Здесь огромное количество возможностей и готовых функций для построения baseline-моделей, train/test split, кросс-валидации и оформления пайплайнов, стандартизирующих препроцессинг.
Если вы хорошо знаете scikit-learn, то уже умеете собирать половину типовых ML-решений.

💻 PyTorch

А это необходимый выбор, если работаете с нейросетями, NLP, CV или современными deep learning-задачами.

PyTorch важен не только сам по себе, но и потому, что вокруг него строится огромная экосистема: обучение, fine-tuning, кастомные модели, исследовательские эксперименты. А вот не менее известный TensorFlow для работы с нейросетями последнее время уходит на второй план.

💻 XGBoost / LightGBM / CatBoost

Это не просто «ещё один sklearn» — это очень мощный класс моделей для табличных данных. Даже в вакансиях очень часто можно видеть отдельные пункты в требованиях про знание этих библиотек.

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

Так что если работаете с табличными данными — эти «три кита» современных бустингов всегда должны быть в арсенале.

💻 Hugging Face Transformers

Если имеете дело с LLM, NLP, CV и в принципе дообучением готовых нейросетей, без этой экосистемы в 2026-м тяжело.

HF нужна, чтобы использовать предобученные модели, быстро их дообучать на своих данных, удобно работать с готовыми токенизаторами, датасетами и не писать всё с нуля
Сегодня это одна из самых простых «дверей» в прикладной DL — в особенности, NLP и LLM.

Итог такой: в 2026 году сильный ML/DS-специалист — это не тот, кто знает сотню библиотек, а тот, кто уверенно закрывает полный цикл: данные → baseline → эксперименты → и продакшен (про него ещё поговорим!).

Сохраняйте как ориентир, чтобы не учить лишнего! И ставьте 🔥, если хотите такой же пост про инструменты production для DS.

Привет! На связи Наталия Воронова, руководитель направления анализа данных в сфере машинного обучения в IT-компании BIV 👋🏻

Хочу разобрать кейс из практики про построение системы на базе LAM + LLM + ML. Это хороший пример того, почему «просто подключить LLM» почти никогда не работает в реальных задачах.

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

На старте была гипотеза: «давайте возьмём LLM и дадим ему всё это решать».

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

И главное — LLM не оптимизирует целевую функцию бизнеса. LLM отвечает на вопрос: «Что выглядит разумно?» А система должна отвечать: «Что максимизирует результат при ограничениях?». Это разные задачи.

Что сделали? Перешли от «одной модели» к агентной архитектуре.

Мы разделили логику на компоненты:

1️⃣ ML-блок (предиктивный слой) считает вероятности и оценки: P(response), P(churn), Expected value и риск. Это числовая основа.

2️⃣ LLM-блок (интерпретация и логика) отвечает за объяснение, работу с текстом, генерацию гипотез и гибкую логику, которую сложно зашить в код.

3️⃣ LAM / агентный слой (оркестрация) — ключевая часть системы. Он управляет последовательностью действий, вызывает нужные модели, учитывает ограничения и принимает итоговое решение. По сути, это decision engine.

Как выглядит поток?
➖ Агент получает задачу;
➖ Запрашивает ML-оценки;
➖ Передаёт контекст в LLM;
➖ Применяет бизнес-ограничения;
➖ Выбирает действие.

Почему это работает? ML даёт точные оценки, LLM даёт гибкость, агент даёт контроль. По отдельности этого недостаточно.

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

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Сегодня вечером веду вебинар о том, чем Data Science отличается от Machine и Deep Learning — через сравнение на реальной задаче.

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

Что вы узнаете из вебинара?
➡️ Разберётесь, что стоит за аббревиатурами AI, ML, DL и DS и как эти роли соотносятся на практике;
➡️ Узнаете, в каких задачах хватает классического ML, а где без нейросетей не обойтись;
➡️ Увидите, как обучают модель и как оценивают её качество — на конкретном примере с кодом;
➡️ Получите представление о стеке инструментов DS, ML и DL-инженера: что нужно знать и откуда начинать.

📆 18 мая, 19:00 МСК, онлайн
❗️ Ссылку на трансляцию пришлём за час до начала!

Почему опытные ML-инженеры не начинают сразу с нейросетей?

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Один из самых полезных лайфхаков в ML, который сильно помогает в реальных проектах:

📌 Никогда не начинайте решение задачи сразу со сложной модели.

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

Как обычно выглядит работа над новым проектом:

1️⃣ Сперва постройте максимально простую модель — например, регрессию или дерево решений. Главное — без сложных пайплайнов и многочасового тюнинга гиперпараметров.

Почему это важно? Дело в том, что baseline быстро покажет, есть ли вообще полезный сигнал в данных и насколько задача решаема. Если простейшая модель выдаёт плохой результат — это повод поискать другой датасет или обогатить имеющийся дополнительными признаками.

2️⃣ Анализируйте не только итоговую метрику, но и ошибки модели на отдельных примерах непосредственно — очень часто это помогает разгадать загадку, что происходит на самом деле. Вот несколько типичных примеров:

➖ модель ошибается только на редких объектах ⇒ вероятен дисбаланс классов;
➖ качество резко падает на новых данных ⇒ распределения в обучающих и свежих продовых данных отличаются.

А если построить график зависимости loss/метрики по итерациям обучения, можно быстрее заметить проблемы в процессе обучения:
➖ если loss «застыл» ⇒ модель почти не учится, можно попробовать поменять что-нибудь в алгоритме оптимизации;
➖ если видите сильные скачки ⇒ learning rate может быть слишком большим;
➖ ну и если loss на валидации начал расти ⇒ типичный сигнал переобучения.

3️⃣ Не тратьте время на подбор гиперпараметров без нормальной валидации. Очень частая ошибка новичков — часами подбирать их, когда проблема вообще в другом.

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

4️⃣ И только когда все простейшие пути решения задачи тщательно проработаны, можно приступать к более сложным моделям.

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

Так что не бросайтесь сразу в SOTA и долгие эксперименты — часто бизнесу вполне хватает простой модели, если она даёт нормальное качество, быстро работает и не требует недель экспериментов ради +0.001 к метрике. В насущных задачах важна не только скорость работы модели, но и скорость её разработки тоже 😁

Ставьте ❤️, если хотите больше постов с лайфхаками!

Привет! Снова на связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Сегодня вечером снова приду на эфир — разберём, как выглядит подготовка датасетов в реальных проектах и пошагово пройдём по базовой «рутине» дата-сайентиста:

1️⃣ Дубликаты, пропуски, выбросы — что с ними делать на практике;
2️⃣ Подготовка признаков для модели — кодирование и масштабирование;
3️⃣ Частые ошибки — утечки данных, мультиколлинеарность, нестабильность и другие вещи, которые тихо ломают качество модели.

📆 20 мая, 18:00 МСК, онлайн
❗️ Ссылку на трансляцию пришлём за час до начала!

Мария Жарова на связи ❤️

Спешу сообщить, что запись стрима про ML-модели уже на канале! Смотрите там, где удобно:
➡️ YouTube
➡️ VK Видео

⭐️ Кстати, уже в пятницу завершается набор на обучение на курсы «ML-инженер» и «Дата-сайентист», где я выступаю ментором. Присоединяйтесь к курсу и учитесь строить эффективные ML-модели от создания до продакшена!

Полезные инструменты и библиотеки для MLOps

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

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

Чтобы понять важность MLOps-инструментов, давайте разберём типичный ML-пайплайн по шагам.

1️⃣ Сначала вы обучаете модель и начинаете экспериментировать: пробуете разные признаки, гиперпараметры, алгоритмы. Довольно быстро становится неудобно хранить результаты «вручную» — в блокнотах, Excel или названиях файлов вроде final_model_v2_last_really_last 😁

И как раз для этого существуют трекеры экспериментов: MLflow, Weights & Biases, ClearML! Они автоматически сохраняют параметры запуска, метрики, версии датасетов, модели, графики обучения и артефакты. Благодаря им потом можно нормально сравнивать эксперименты и наглядно видеть, почему одна версия модели сработала лучше другой.

2️⃣ Теперь представим, что ваша модель оказалась успешной, и её нужно выкатить в production — к примеру, рекомендательную систему. Что это значит? Как минимум то, что пользователи теперь должны регулярно получать актуальные рекомендации от вашей модели — а для этого её нужно регулярно перезапускать.

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

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

К счастью, для этого существуют оркестраторы: Airflow, Prefect, Luigi. Они позволяют описывать ML-процессы как последовательность задач и автоматически запускать их по расписанию. Плюс они умеют отслеживать статус задач, самостоятельно перезапускать упавшие этапы, хранить логи и строить зависимости между шагами пайплайна. По сути это инструмент для автоматизации и управления сложными процессами.

3️⃣ Также при выкатке в прод почти все сталкиваются с проблемой: «локально всё работает, а на сервере внезапно нет».

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

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

Благодаря этому можно один раз собрать окружение и потом запускать его где угодно:
локально, на сервере, в облаке или у другого разработчика в команде. Концепция Docker уже давно стала стандартом для ML, да и в принципе в разработке.

4️⃣ А уже после выкатки модели обычно хочется понимать, не упал ли сервис, не начала ли модель отвечать слишком медленно, не закончилась ли память, не выросла ли нагрузка на сервер.

Для ответа на эти вопросы обычно используют связку Prometheus + Grafana. Prometheus — это система сбора метрик, она регулярно ходит в сервисы и собирает техническую информацию: нагрузку CPU, использование памяти, время ответа, количество запросов, ошибки и другие показатели. А Grafana — это инструмент для визуализации этих данных. В ней можно подключать разные источники данных и через UI собирать дашборды с графиками, таблицами и мониторингом сервисов.

5️⃣ А когда ML-систем становится много — появляются Kubernetes, feature store, CI/CD и другие инфраструктурные инструменты. Но это уже следующий уровень зрелости проекта.

Так что каждый инструмент MLOps решает вполне конкретную практическую проблему, с которой рано или поздно сталкивается любая ML-команда.

Сохраняйте, чтобы не потерять ❤️

Лучший совет для начинающих — начните 😄 Но с чего начать, когда вокруг столько информации?

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Хоть Data Science и относительно молодое направление, по нему уже успело накопиться ооочень много ресурсов и литературы. Собрала для вас 3 книги, которые хорошо подойдут на старте — без перегруза и с понятной логикой роста.

📕 Луис Серра «Грокаем машинное обучение»

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

➖ Что такое модель и почему она «учится»;
➖ Что значит ошибка и качество;
➖ Зачем делить данные на train/test;
➖ И почему модели иногда «переучиваются».

Издание довольно новое (2024 года), и закрывает весь стек классического ML.

📖 Ссылка на PDF

📗 Джейк ВандерПлас «Python для сложных задач»

Это отличное практическое дополнение к теории. Несмотря на устрашающее название, в книге понятно и на примерах объясняются все базовые инструменты и библиотеки дата-сайентиста: NumPy, Pandas, визуализация и базовый ML через sklearn.

Хоть DS и считается исследовательско-математическим направлением, все идеи и алгоритмы реализуются через Python, поэтому его знание необходимо.

📖 Ссылка на PDF

📘 В. Савельев «Статистика и котики»

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

Можно наконец-то осознать:

➖ Почему маленькие выборки могут легко вводить в заблуждение;
➖ Почему любые «примерные оценки» всегда с погрешностью и почему это нормально;
➖ И как перестать воспринимать цифры как что-то точное, а начать видеть в них неопределённость.

И всё это через простые, жизненные примеры.

📖 Ссылка на PDF

В итоге получается очень комфортная траектория:
➡️ «Грокаем» — чтобы понять основы ML;
➡️ Python ВандерПласа — чтобы начать делать руками;
➡️ «Статистика и котики» — чтобы научиться мыслить аналитически.

На такую базу можно уже «наращивать» более сложный материал.

Сохраняйте, чтобы не потерять ❤️

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Записала отдельное видео про сравнение библиотек Pandas и Polars: где и в каких случаях их использовать, их возможности и технические ограничения. Надеюсь, будет полезно!

Смотрите там, где удобно:
📹 YouTube
📹 VK Видео

Всем привет! Я Валерия Елпатьевская, инженер данных в Альфа Банке и ментор Симулейтив 👋🏻

Мой путь начался не в IT: филология, преподавание, потом Data Science. Но быстро поняла, что без инженерной базы далеко не уедешь. Пошла разбираться в очередях, оркестрации и архитектуре… и как-то незаметно стала Data Engineer.

С 8 по 16 июля я буду ментором бесплатного ML-интенсива — буду помогать вам сделать первые шаги в data science и не дам застрять на задачах. Что ещё будет на интенсиве:

➖ Практика на Kaggle — решаете реальные задачи и сразу кладёте их в портфолио;
➖ Финальный эфир — разберём, как оформить готовый проект в GitHub так, чтобы его не стыдно было показать работодателю;
➖ Сертификат и призы самым активным участникам недели!

Продвинутый Python и математика не нужны — стартуем с азов, а разбираться в непонятных местах будет с кем. Буду ждать вас на интенсиве!

➡️ Зарегистрироваться на интенсив

Один из самых недооценённых лайфхаков в ML — это правильные негативные примеры

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Когда люди начинают изучать ML, обычно всё выглядит довольно просто: есть объект и есть правильный ответ. В процессе обучения мы показываем модели много таких примеров, чтобы она сама научилась предсказывать.

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

➖ В рекомендациях нужно выбрать лучшие товары среди тысяч других и расположить их в правильном порядке;
➖ Аналогично в поиске — найти самые подходящие документы;
➖ В матчинг-задачах — отличать похожие объекты от непохожих;
➖ В CV и NLP — понимать, какие изображения или тексты действительно близки по смыслу, а какие нет.

И тут всегда возникает проблема: потенциально «неправильных» вариантов обычно слишком много.

Представьте рекомендательную систему: пользователь купил кроссовки — это позитивный пример. Но товаров в магазине могут быть миллионы.

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

Простейший вариант — взять негативы случайно, но в этом есть свои риски: например, пользователь купил кроссовки, а в негативы попал холодильник. Формально всё правильно — холодильник действительно не купили, но проблема в том, что такой «негатив» слишком простой.

Другими словами, модель быстро выучится, что «кроссовки ≠ холодильник» — и почти ничего полезного из этого не получит. Потому что реальные ошибки обычно происходят не между совершенно разными объектами, а между похожими: то есть не между кроссовками и холодильником, а между двумя похожими моделями кроссовок.

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

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

Поэтому две команды могут использовать одну и ту же модель, но получать совершенно разное качество 🙂

Сохраняйте, чтобы не потерять ❤️

Один из самых популярных вопросов, который часто задают: «Из какой профессии проще всего перейти в ML или Data Science?»

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

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

⭐️ Например, аналитика — наверное, один из самых естественных входов в Data Science. DA хорошо умеют работать с данными, знают Python и SQL, понимают метрики, визуализацию и логику продуктовых задач. Обычно здесь остаётся посмотреть только темы, связанные непосредственно с машинным обучением: какие бывают модели, их валидацию, концепции подготовки данных для ML и базовый production-подход.

⭐️ А вот разработчикам легче даётся инженерная часть: код, архитектура, оптимизация, работа с инфраструктурой. При переходе в ML они обычно прокачивают математику и принципы работы с данными и экспериментами.

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

⭐️ А ещё в ML очень много людей из совсем других сфер: экономики, физики, биологии, маркетинга, финансов — и это тоже нормально. Во многих задачах доменная экспертиза оказывается не менее важной, чем знание очередной библиотеки. Последнее время можно наблюдать интересную тенденцию: нередко в описаниях вакансий встречаются требования про знание доменной сферы.

Но есть вещь, которая почти одинаково важна для всех, независимо от точки входа:
без практики перейти в ML очень сложно.

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

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

Так что если вам кажется, что у вас «не тот» бэкграунд для ML — скорее всего, это не так. Намного важнее другое: насколько системно вы готовы закрывать пробелы и превращать теорию в практику ❤️

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

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Разберём типичный кейс, через который проходит почти каждая команда, которая берётся за рекомендации с нуля.

Стартовая точка: а что вообще рекомендовать?

Обычно всё начинается так: есть каталог (товары, видео, статьи, треки — назовём их обобщённо айтемы) и есть пользователи, которые с ним как-то взаимодействуют. Бизнес говорит: «сделайте, чтобы люди больше кликали/покупали/смотрели». И тут появляется первая ловушка — кажется, что задача про алгоритмы, а на самом деле она про данные.

Первые вопросы, на которые приходится отвечать:
➡️ Какие взаимодействия считать «положительными» — клик? Просмотр дольше 30 секунд? Покупка?
➡️ Как быть с неявным фидбэком, когда пользователь просто проскроллил, и непонятно, понравилось ему или нет, а может просто кот прошёлся по клавиатуре;
➡️ Что делать с новыми юзерами и новыми айтемами, про которых мы ничего не знаем? (знаменитая проблема cold start).

✅ Первая итерация: baseline, который очень простой, но нужный

Классика жанра — начать с чего-то максимально простого: топ популярного, топ популярного в сегменте пользователя или content-based (похожие айтемы по описанию/тегам).

Звучит скучно, но именно на этом этапе выясняется куча важного: где в логах дырки и пропуски, какие товары давно неактуальны и их вообще не стоит рекомендовать, и — сюрприз — что простой топ популярного уже даёт вполне приличные клики, и обогнать его сложными моделями не так-то просто.

✅ Вторая итерация: коллаборативная фильтрация и двухстадийная схема

Дальше обычно строится честная двухстадийная архитектура:

➖ Candidate generation — быстро отобрать сотни кандидатов из миллионов (ALS, item2item, эмбеддинги);
➖ Ranking — аккуратно переранжировать топ градиентным бустингом или нейронкой с добавлением фичей.

Именно здесь появляется ощущение «настоящей» рексистемы. И именно здесь всплывает вторая типичная ловушка — оффлайн-метрики не всегда хорошо коррелируют с онлайном. Знакомая история: NDCG на исторических данных подрос, а в A/B-тесте — тишина. Причин может быть много:

🔶 Выбрана не совсем та оффлайн-метрика под бизнес-задачу;
🔶 Сказывается смещение в обучающих данных, особенно если они собраны предыдущей версией рексистемы — привет, feedback loop;
🔶 Иногда дело в том, что рост качества модели просто не транслируется в поведение пользователя напрямую.

Поэтому в зрелых командах оффлайн-эксперименты воспринимают скорее как фильтр гипотез, а финальное слово всегда за A/B.

✅ Третья итерация: а что мы вообще оптимизируем?

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

➖ Многокритериальная оптимизация (клик + удержание + разнообразие);
➖ Бизнес-правила поверх модели (не показывать одно и то же, поддерживать новинки);
➖ Контроль за разнообразием выдачи, чтобы пользователь не оказался запертым в «пузыре» из одного и того же типа контента.

Ещё раз кратко, что запомнить:
📌 Сначала данные и метрика, потом модель, а не наоборот;
📌 Простой baseline экономит месяцы — без него не с чем сравнивать;
📌 Offline-качество ≠ бизнес-эффект, финальный судья — A/B-тест;
📌 Рексистема — это не одна модель, а пайплайн из отбора, ранжирования и правил.

Рекомендации — та область, где инженерная аккуратность важнее модного алгоритма. И это, пожалуй, главный инсайт, который приходит с практикой ❤️

Сохраняйте, если было полезно!

Гайд: практическое применение алгоритмов ML

Знаете, как компьютеры могут учиться на данных и делать точные прогнозы? Благодаря алгоритмам машинного обучения — набору методов, которые позволяют компьютерам учиться на данных и делать прогнозы без явного программирования.

Подготовили для вас материал с обзором и примерами применения таких алгоритмов.

Что вы получите от нашего материала?

⭐️ 16 алгоритмов с реальными примерами кода, такими как прогнозирование стоимости недвижимости, классификация электронных писем как спам или не-спам и многое другое;

⭐️ Разберётесь в принципах работы алгоритмов и их практическом применении. Вы узнаете, как использовать их для автоматизации рутинных задач и улучшения процессов принятия решений;

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

✅ Получить материал

Встроенная магия Jupyter и библиотека importlib

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Знакомая ситуация: пишете код в .py-файле, импортируете его в ноутбук, находите баг, правите — и ничего не меняется, пока не перезапустишь ядро и не потеряешь все переменные из памяти 😩 Сегодня про то, как это лечится в две строчки.

Разберём сразу два подхода — встроенную магию Jupyter и библиотеку importlib. Оба решают одну задачу: подхватывать изменения в модулях без перезапуска ядра. Но работают они чуть по-разному, поэтому полезно знать оба.

Способ 1: магические команды %load_ext autoreload

Это самый удобный вариант для повседневной работы. В начале ноутбука пишем две строчки:

%load_ext autoreload
%autoreload 2

И всё — теперь при каждом выполнении ячейки Jupyter будет автоматически перечитывать все импортированные модули, если в них что-то поменялось.

Что означают режимы:
➖ %autoreload 0 — выключено;
➖ %autoreload 1 — перезагружаются только модули, импортированные через %aimport;
➖ %autoreload 2 — перезагружаются все импортированные модули (то, что нужно в 99% случаев).

Типичный сценарий использования:

%load_ext autoreload
%autoreload 2

from my_project.features import build_features
from my_project.models import train_model

X = build_features(df)         # запустили
# ... идём в features.py, правим build_features ...
X = build_features(df)         # уже работает новая версия, ядро живо

Все переменные (df, обученные модели, загруженные датасеты) остаются в памяти. Магия ✨

Способ 2: importlib.reload — когда нужен контроль

autoreload штука удобная, но иногда мешает: например, если модуль тяжёлый и вы не хотите перечитывать его каждый раз, или если работаете вне Jupyter. Для таких случаев есть встроенный модуль importlib:

import importlib
import my_project.features as features

# ... правим features.py ...

importlib.reload(features)
X = features.build_features(df)

Работает надёжно, но есть нюанс — если вы делали from my_project.features import build_features, то после reload старое имя build_features продолжит указывать на старую функцию. Нужно либо переимпортировать явно:

importlib.reload(features)
from my_project.features import build_features   # обновили ссылку

…либо изначально импортировать модуль целиком (import features + features.build_features(...)), а не отдельные функции.

Итог: что когда что использовать

📌 %autoreload 2 — дефолт для исследовательской работы в ноутбуках, ставим в первую ячейку и забываем;
📌 importlib.reload — когда autoreload конфликтует с чем-то (иногда бывает с C-расширениями, декораторами, dataclass-ами) или когда нужен точечный контроль;
📌 Комбинация — тоже вариант: autoreload 2 для большинства обычных модулей, а %aimport с режимом 1 для тяжёлых, которые дорого перечитывать.

Сохраняйте, чтобы не потерять ❤️