🤔Что происходит, когда AI выходит за пределы прототипа?

20 мая в 15:00 приглашаем на Inside AI Meetup от Wildberries & Russ.

Там обсудят реальные кейсы: от высоконагруженной модерации с векторным поиском и AIOps-подходов к управлению ML-сервисами до практики построения RAG-систем, тонкостей реранкинга и реальных этапов запуска LLM-продуктов.

Среди спикеров эксперты Wildberries & Russ, MWS, Avito, Сбера, Альфа-Банка, red_mad_robot. Принять участие советуем senior ML/AI инженерам, MLE, DS, инженерам платформ и всем, кто строит или масштабирует AI-системы в продакшене.

Митап пройдет в Москве + будет трансляция. Подробности и регистрация — на сайте.

Как бороться с переобучением в нейросетях

Переобучение — это момент, когда модель:

👉 идеально знает train
👉 и плохо работает на новых данных

Она запоминает, а не обобщает.

Разберём, как с этим бороться на практике.

1. Больше данных

Самый надёжный способ.

Если данных мало:

👉 собирай новые
👉 делай data augmentation
👉 используй синтетические данные

Больше разнообразия = меньше шансов запомнить шум.

2. Regularization

Добавляем штраф за сложность модели.

Основные варианты:

👉 L2 (weight decay)
👉 L1

Меньше веса → проще модель → меньше overfitting.

3. Dropout

Во время обучения случайные нейроны «выключаются».

Что происходит:

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

Обычно используют:

👉 0.2 – 0.5

4. Early Stopping

Следим за валидацией:

👉 train loss падает
👉 val loss сначала падает, потом растёт

Останавливаем обучение в момент роста val loss.

Это один из самых эффективных методов.

5. Упростить модель

Иногда решение очевидное:

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

Большая модель легче переобучается.

6. Data Augmentation

Особенно важно для:

CV:

👉 повороты
👉 шум
👉 кропы

NLP:

👉 перефразирование
👉 замены

Модель видит больше вариантов одного и того же.

7. Batch Normalization

Помогает:

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

Не основное решение, но усиливает остальные.

8. Правильная валидация

Если плохой split — ты не заметишь проблему.

Используй:

👉 train / val / test
👉 k-fold при малых данных

Иначе будешь оптимизировать иллюзию.

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

Переобучение — это сигнал:

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

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

Чтобы уменьшить переобучение —
добавь данных или убери сложность модели.

Когда логистическая регрессия лучше 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 нужен
👉 деревья → обычно не нужен

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

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