Когда логистическая регрессия лучше XGBoost

В мире ML есть странный культ сложных моделей.

Если задача табличная —
многие сразу запускают:

👉 XGBoost
👉 LightGBM
👉 CatBoost

А потом удивляются,
что простая логистическая регрессия работает не хуже.

Иногда — даже лучше.

Почему все недооценивают Logistic Regression

Потому что она:

👉 старая
👉 простая
👉 «не хайповая»

Но у неё есть огромный плюс:

Она очень хорошо обобщает.

Когда Logistic Regression выигрывает

1. Мало данных

Если у тебя:

👉 маленький датасет
👉 мало наблюдений
👉 мало signal

Бустинг легко переобучается.

Логистическая регрессия:

👉 проще
👉 стабильнее
👉 менее чувствительна к шуму

2. Линейная зависимость

Если данные разделяются почти линейно:

Сложная модель просто не нужна.

XGBoost будет:

👉 строить сложные деревья
👉 искать несуществующие паттерны

3. Высокая размерность

Особенно:

👉 NLP
👉 sparse features
👉 TF-IDF

Logistic Regression здесь очень сильна.

Почему:

👉 хорошо работает с разреженными данными
👉 быстро обучается
👉 эффективно регуляризуется

4. Нужна интерпретируемость

Логистическая регрессия:

👉 прозрачна
👉 объяснима
👉 понятна бизнесу

Можно сказать:

👉 какой признак влияет
👉 насколько влияет
👉 в какую сторону влияет

Для финтеха, медицины и скоринга это критично.

5. Ограничения по скорости

Logistic Regression:

👉 быстро обучается
👉 быстро работает
👉 мало потребляет памяти

Иногда latency важнее +2% качества.

Где XGBoost всё-таки сильнее

Когда:

👉 сложные нелинейные зависимости
👉 interaction effects
👉 много данных
👉 хороший feature engineering

Тогда бустинг почти всегда победит.

Самая частая ошибка

Люди сравнивают:

👉 плохо настроенную Logistic Regression
👉 и хорошо настроенный XGBoost

А потом говорят:

«Линейные модели умерли».

Нет.

Часто baseline даже не пытались нормально сделать.

Главный инсайт

Сложная модель не делает тебя хорошим ML-инженером.

Умение понять, когда хватит простой модели — делает.

В одном предложении

Если задача простая, данных мало или нужна интерпретируемость —
Logistic Regression может быть лучше XGBoost.

Почему знание математики не гарантирует работу

Неприятная правда для начинающих в Data Science:

Хорошая математика ≠ готовность к реальной работе.

Можно понимать:

👉 линейную алгебру
👉 статистику
👉 градиентный спуск
👉 вероятности

И всё равно провалиться на практике.

Почему так происходит

Потому что работа Data Scientist — это не только формулы.

Это ещё:

👉 грязные данные
👉 непонятные требования
👉 слабые baseline’ы
👉 странные бизнес-ограничения
👉 коммуникация с людьми

В реальности задача редко выглядит как в учебнике.

Математика помогает, но не заменяет практику

Математика даёт понимание:

👉 почему модель работает
👉 где она может сломаться
👉 как читать метрики
👉 как не верить магии

Но она не научит:

👉 чистить данные
👉 строить pipeline
👉 писать production-код
👉 делать нормальный train/test split
👉 объяснять результат бизнесу

Главная ошибка новичков

Они думают:

«Сначала выучу всю математику, потом начну проекты».

Проблема в том,
что «вся математика» не заканчивается никогда.

Работу дают не за знание формул,
а за способность решать задачи.

Что реально смотрят на собеседованиях

Обычно хотят понять:

👉 можешь ли ты работать с данными
👉 понимаешь ли метрики
👉 умеешь ли делать baseline
👉 видишь ли leakage
👉 можешь ли объяснить решение
👉 есть ли у тебя проекты

Математика важна.
Но сама по себе она не продаёт тебя как специалиста.

Что делать вместо бесконечной теории

Лучший путь:

👉 учить математику по мере необходимости
👉 параллельно делать проекты
👉 разбирать ошибки моделей
👉 писать код руками
👉 учиться объяснять выводы простыми словами

Теория должна усиливать практику,
а не заменять её.

Главный инсайт

Математика — это фундамент.
Но дом строится не фундаментом одним.

В одном предложении

Чтобы получить работу в DS/ML, мало знать формулы —
нужно уметь превращать данные в работающие решения.

Кошмар вайбкодера

xCode Journal

Data Fest в гостях у ВТБ

24 мая ВТБ открывает двери Loft Hall на Автозаводской — будет день докладов, нетворкинга и не душных разговоров про Data Science и карьеру в индустрии.

В программе:
• Data Fusion — кейсы от DS-команды ВТБ
• Mathematics & ML
• ML в рекламе и маркетинге
• Open Career — честно про карьеру в DS

Программу и спикеров можно посмотреть тут, регистрацию лучше не откладывать — места на площадке ограничены.

📍 24 мая, Loft Hall (зал Ratusha)
⏰ С 11:00 до вечера
📌 Вход бесплатный, при регистрации указывайте ФИО и опыт в DS/ML

Feature Engineering важнее выбора модели

Самый непопулярный факт в ML:
модель — это не главное.

Можно часами выбирать между:
XGBoost
LightGBM
CatBoost
…и получить +1% к качеству.

А можно поменять фичи — и получить +20%.

Разберёмся, почему так 👇

Модель учится только на том, что ты ей дал

Garbage in → garbage out

Если признаки:
- шумные
- нерелевантные
- плохо отражают задачу

👉 никакая модель не спасёт

Даже самая большая.

Пример из жизни

Задача: предсказать отток клиентов

Фичи:
- возраст
- город
- тариф

Модель: ок, но слабый результат

Добавили:
- время с последнего действия
- частоту использования
- изменение активности

👉 резкий рост качества

Почему?
Потому что фичи начали отражать реальное поведение

Feature Engineering = внедрение знаний о задаче

Модель не знает:
- бизнес
- контекст
- причинно-следственные связи

Зато ты знаешь.
И когда ты создаёшь фичи —
ты “вшиваешь” это знание в данные.

Модель vs Фичи

Что меняем → эффект

Модель → +1–5%
Гиперпараметры → +1–3%
Feature Engineering → +10–50%

Где FE особенно решает

- Табличные данные
- Маленькие датасеты
- Бизнес-задачи

👉 там, где нет миллионов примеров, фичи — это всё

Когда модель важнее
- CV (изображения)
- NLP (тексты)
- Speech

👉 там фичи учатся автоматически

Почему все игнорируют FE

Потому что:
- это сложно
- это долго
- нет “магической кнопки”
- требует понимания данных

Гораздо проще:
“давай попробуем ещё одну модель”

Главный инсайт

ML — это не соревнование моделей.
Это соревнование представлений данных.

В одном предложении

Лучший способ улучшить модель —
👉 перестать тюнить модель и начать тюнить данные

⁣Почему нормализация данных иногда ухудшает модель

Новички в ML часто слышат:

«Всегда нормализуй данные».

И начинают масштабировать всё подряд.

А потом качество модели… падает.

Почему так происходит?

Потому что нормализация нужна не всегда.

Что вообще делает нормализация

Она приводит признаки к одному масштабу.

Например:

👉 возраст → 18–60
👉 зарплата → 1000–100000

После scaling:

👉 значения становятся сопоставимыми
👉 обучение становится стабильнее

Когда нормализация действительно нужна

Особенно важна для моделей,
чувствительных к масштабу:

👉 Logistic Regression
👉 Linear Regression
👉 SVM
👉 KNN
👉 Neural Networks

Без scaling такие модели могут работать хуже
или обучаться нестабильно.

А теперь главное

Деревьям scaling обычно не нужен.

Это:

👉 Random Forest
👉 XGBoost
👉 LightGBM
👉 CatBoost

Почему?

Потому что деревья делают split’ы:

feature < threshold

Им неважно:

👉 0.5 это или 5000
👉 масштаб почти не играет роли

Как нормализация может ухудшить модель

1. Добавляет шум

Иногда scaling:

👉 размывает распределения
👉 усиливает выбросы
👉 ухудшает separability

Особенно на плохих данных.

2. Ломает интерпретируемость

Было:

👉 доход = 5000

Стало:

👉 доход = -0.73

Бизнесу это уже сложнее объяснять.

3. Неправильный scaling = leakage

Классическая ошибка:

👉 scaling на всём датасете
👉 потом split

Test уже «утёк» в train.

4. CatBoost может стать хуже

CatBoost хорошо работает с:

👉 категориальными фичами
👉 исходными распределениями

Иногда лишний preprocessing только мешает.

Самый важный инсайт

Scaling — это не «улучшение данных».

Это инструмент под конкретную модель.

Что делать на практике

Простое правило:

👉 линейные модели / distance-based → scaling нужен
👉 деревья → обычно не нужен

В одном предложении

Нормализация полезна не всегда —
для некоторых моделей она бесполезна,
а иногда даже вредна.

Как крепкий фундамент в ML работает в любой сфере

Выпускница ШАДа Дарима Мылзенова применяла одно и то же ML-мышление в медицине (анализ КТ-снимков), нефтянке (изучение недр), стартапе по синтезу речи, а теперь — в финтехе. В интервью 8бит она рассказала про изнанку инженерии.

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

⁣Почему open-source модели меняют рынок AI

Ещё пару лет назад казалось,
что AI будет полностью контролироваться
несколькими большими компаниями.

У кого больше GPU и денег —
тот и главный.

Потом появились:

👉 Llama
👉 Mistral
👉 DeepSeek
👉 Qwen
👉 Phi

И стало понятно,
что рынок пойдёт совсем по другому сценарию.

Дело не только в качестве

Самое интересное,
что open-source модели меняют индустрию
не только из-за качества.

Хотя с качеством у них уже всё довольно неплохо.

Проблема в другом:

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

Сегодня API работает.
Завтра:

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

И ты ничего не контролируешь.

Почему open-source меняет правила игры

С open-source всё иначе.

Хочешь:

👉 запускай локально
👉 дообучай
👉 квантизируй
👉 меняй inference stack
👉 оптимизируй latency
👉 держи данные внутри компании

Для бизнеса это огромная разница.

Особенно там, где:

👉 приватные данные
👉 compliance
👉 большие объёмы запросов
👉 дорогой inference

Есть ещё один важный эффект

Open-source очень быстро двигает индустрию вперёд.

Потому что тысячи инженеров:

👉 тестируют модели
👉 находят слабые места
👉 пилят оптимизации
👉 делают inference-движки
👉 выпускают fine-tuning инструменты

Прогресс идёт не сверху вниз,
а сразу со всех сторон.

Что особенно интересно сейчас

Иногда маленькая open-source модель
на хорошем inference pipeline
ощущается полезнее огромной закрытой LLM.

Особенно в проде.

Потому что в реальности важны не только benchmark’и.

Важны:

👉 цена
👉 контроль
👉 latency
👉 стабильность
👉 возможность встроить модель в систему

Главная мысль

Кажется, рынок AI постепенно уходит от идеи:

«Одна гигантская модель для всего».

К модели:

«Много специализированных моделей
под конкретные задачи».

Устал инициализировать претрейны весами Qwen? Приходи к нам — мы честно учим с нуля! 😉

Ищем Senior/Senior+ AI Engineer и продактов в RnD-команду: как отдельных специалистов, так и целые команды, — которые готовы разрабатывать прорывные AI-решения.

Познакомиться ближе с нашими направлениями и оставить отклик можно на сайте.

А если хотите следить за тем, как команда RnD ML Сбера исследует и разрабатывает AI-технологии, — подписывайтесь на Telegram-канал команды. Там делятся исследованиями, экспериментами и инсайтами из мира AI, а также свежими вакансиями 🚀