Обучение XGBoost, LightGBM, CatBoost на табличных данных

Клиент сменил требования на позднем этапе: вместо бинарной классификации потребовалась мультиклассовая. Пришлось пересобирать пайплайн с нуля. Выручили градиентные бустинги — XGBoost, LightGBM и CatBoost. В проекте по скорингу клиентов банка мы столкнулись с дисбалансом классов и 500+ признаками. Бустинги позволили достичь AUC 0.92 без глубокого обучения. Эти алгоритмы — рабочие лошадки ML для табличных структурированных данных. Они доминируют в Kaggle и production там, где нейронные сети пасуют: мало данных, много категориальных фичей, нужна интерпретируемость. Они эффективны на табличных данных с тысячами признаков, не требуют нормализации и устойчивы к пропускам.

Типичный сценарий: данные — таблица с пропусками, категориальными колонками с высокой кардинальностью и несбалансированным таргетом. Градиентный бустинг с правильной настройкой выигрывает у линейных моделей и случайного леса на 3-5% по AUC. Мы тестировали гипотезы на исторических данных — приросты стабильны.

Какие проблемы решаем

Неоптимальные гиперпараметры снижают AUC на 3-5%. Мы используем Optuna с ранней остановкой: 100 итераций за 10-30 минут на 1M строк.

Категориальные признаки с высокой кардинальностью. One-Hot Encoding плодит разреженность. CatBoost решает это native, для LightGBM применяем bayesian target encoding.

Интерпретируемость для бизнеса. SHAP-анализ раскладывает предсказание на вклады признаков — обязательное требование для кредитного скоринга или медицины. Как отмечает оригинальная статья: XGBoost: A Scalable Tree Boosting System (Chen & Guestrin, 2016).

Дисбаланс классов — ещё одна типичная проблема. Бустинги с взвешенными выборками и early stopping помогают сохранить качество на редких событиях.

Почему именно эти алгоритмы?

LightGBM выигрывает по скорости: он обучается в 2-3 раза быстрее XGBoost на датасетах от 100K строк. XGBoost стабильнее на разреженных данных и даёт более сглаженные предсказания. CatBoost не требует кодирования категорий — просто укажите список cat_features. В ансамбле они перекрывают слабости друг друга: stacking даёт прирост AUC 0.5-2% относительно лучшей одиночной модели. Экономия на вычислительных ресурсах до 40% при использовании LightGBM.

Как мы это делаем

Стек: Python 3.11, LightGBM 4.0, XGBoost 2.0, CatBoost 1.2, Optuna 3.5. Для больших данных используем Dask или Spark, на которых бустинги работают через distributed API. Типичный кейс: прогноз оттока с 1 млн строк и 200+ признаками. После подбора num_leaves=127, learning_rate=0.03, subsample=0.8 AUC вырос с 0.82 до 0.87. Окупаемость пилотного проекта достигается за счёт роста точности прогнозов.

Как избежать переобучения?

Ранняя остановка и регуляризация — ключевые приёмы. Параметры reg_alpha, reg_lambda, min_child_samples контролируют сложность модели. Мы используем кросс-валидацию с 5 фолдами и мониторингом метрики на валидации.

Сравнение производительности

Процесс работы

1. Аналитика. Изучаем распределения, выбросы, корреляции.
2. Feature engineering. Генерируем признак на основе бизнес-логики (скользящие средние, кросс-таблицы).
3. Поиск гиперпараметров. Optuna с 100-200 итерациями, кросс-валидация StratifiedKFold.
4. Обучение и валидация. Оцениваем AUC, precision-recall, калибровку.
5. Интерпретация. SHAP summary plot и dependence plots для топ-10 фичей.
6. Деплой. Экспорт в ONNX или PMML, REST API на FastAPI, мониторинг дрейфа.

Реализация

LightGBM: полный pipeline

import lightgbm as lgb
from sklearn.model_selection import StratifiedKFold
from sklearn.metrics import roc_auc_score
import optuna

def train_lgbm_with_cv(X: pd.DataFrame, y: pd.Series,
                        n_splits: int = 5) -> lgb.LGBMClassifier:
    def objective(trial):
        params = {
            'n_estimators': trial.suggest_int('n_estimators', 100, 1000),
            'num_leaves': trial.suggest_int('num_leaves', 20, 300),
            'max_depth': trial.suggest_int('max_depth', 3, 12),
            'learning_rate': trial.suggest_float('learning_rate', 0.005, 0.1, log=True),
            'subsample': trial.suggest_float('subsample', 0.6, 1.0),
            'colsample_bytree': trial.suggest_float('colsample_bytree', 0.6, 1.0),
            'reg_alpha': trial.suggest_float('reg_alpha', 1e-8, 10.0, log=True),
            'reg_lambda': trial.suggest_float('reg_lambda', 1e-8, 10.0, log=True),
            'min_child_samples': trial.suggest_int('min_child_samples', 5, 100),
        }
        cv = StratifiedKFold(n_splits=5, shuffle=True, random_state=42)
        scores = []
        for train_idx, val_idx in cv.split(X, y):
            model = lgb.LGBMClassifier(**params, random_state=42, verbose=-1)
            model.fit(
                X.iloc[train_idx], y.iloc[train_idx],
                eval_set=[(X.iloc[val_idx], y.iloc[val_idx])],
                callbacks=[lgb.early_stopping(50, verbose=False)]
            )
            pred = model.predict_proba(X.iloc[val_idx])[:, 1]
            scores.append(roc_auc_score(y.iloc[val_idx], pred))
        return np.mean(scores)

    study = optuna.create_study(direction='maximize')
    study.optimize(objective, n_trials=100, n_jobs=4)
    best_model = lgb.LGBMClassifier(**study.best_params, random_state=42)
    best_model.fit(X, y)
    return best_model

def explain_model(model, X: pd.DataFrame):
    import shap
    explainer = shap.TreeExplainer(model)
    shap_values = explainer.shap_values(X)
    shap.summary_plot(shap_values, X, plot_type="bar")
    top_feature = X.columns[np.abs(shap_values).mean(0).argmax()]
    shap.dependence_plot(top_feature, shap_values, X)

CatBoost с категориальными признаками

from catboost import CatBoostClassifier, Pool

def train_catboost(X_train: pd.DataFrame, y_train: pd.Series,
                    X_val: pd.DataFrame, y_val: pd.Series,
                    cat_features: list[str]) -> CatBoostClassifier:
    train_pool = Pool(X_train, y_train, cat_features=cat_features)
    val_pool = Pool(X_val, y_val, cat_features=cat_features)
    model = CatBoostClassifier(
        iterations=1000,
        learning_rate=0.03,
        depth=6,
        l2_leaf_reg=3.0,
        bootstrap_type='Bayesian',
        bagging_temperature=1.0,
        eval_metric='AUC',
        use_best_model=True,
        early_stopping_rounds=100,
        random_seed=42,
        verbose=100
    )
    model.fit(train_pool, eval_set=val_pool)
    return model

Как настроить стекинг для максимальной точности?

from sklearn.ensemble import StackingClassifier
from sklearn.linear_model import LogisticRegression

stacking = StackingClassifier(
    estimators=[
        ('lgbm', lgb.LGBMClassifier(**lgbm_best_params)),
        ('xgb', XGBClassifier(**xgb_best_params)),
        ('catboost', CatBoostClassifier(**cat_best_params, verbose=0)),
    ],
    final_estimator=LogisticRegression(C=0.1),
    cv=5,
    stack_method='predict_proba'
)
stacking.fit(X_train, y_train)

Какие ошибки допускают при обучении бустингов?

• Игнорирование категориальных признаков: используйте CatBoost или правильный encoding.
• Недостаточная валидация: StratifiedKFold для несбалансированных выборок.
• Переобучение: ранняя остановка и регуляризация (reg_alpha, reg_lambda).

Что входит в работу (deliverables)

• Оптимизированная модель с документированными гиперпараметрами.
• SHAP-отчёт с топ-10 признаками и их влиянием.
• REST API или ONNX-экспорт.
• Деплой на production + мониторинг (дрейф данных, падение метрик).
• Обучение команды заказчика.

Сроки ориентировочно

От 5 рабочих дней на прототип до 3 недель на production-пайплайн. Свяжитесь с нами для консультации по вашему проекту. Закажите пилотный проект, чтобы оценить прирост метрик. Стоимость рассчитывается индивидуально. Получите консультацию по вашему проекту — наши инженеры помогут выбрать оптимальный подход.

Data Engineering для ML: пайплайны, разметка и качество данных

«У нас много данных» — фраза, которая на деле часто означает «у нас много сырых логов в S3, которые никто не трогал два года». Перед тем как обучить модель, нужно понять, что вообще есть: какова структура, есть ли дубли, как часто меняется схема, насколько репрезентативна выборка.

Data Engineering для ML — не просто ETL. Это построение воспроизводимой инфраструктуры данных, которая делает обучение моделей надёжным, а переобучение — предсказуемым. По опыту нашей команды (8 лет в дата-инжиниринге, более 30 проектов в ML) каждая вторая проблема в продакшене связана не с архитектурой модели, а с качеством данных.

ETЛ-пайплайны для ML: чем отличаются от BI

ETL для аналитики и ETL для ML — разные задачи. В аналитике важна агрегация, в ML — индивидуальные записи с историей. В аналитике train/val/test split не нужен, в ML — критичен. В аналитике skew данных мешает интерпретации, в ML — напрямую влияет на качество модели.

Инструменты. Apache Spark (Wikipedia) для больших объёмов (10GB+): PySpark с DataFrames, оптимизации через partitioning и caching. dbt для трансформаций поверх DWH (Snowflake, BigQuery, Redshift) — декларативно, версионируется, тестируется. Pandas + Polars для объёмов до нескольких GB — Polars в 5-10x быстрее Pandas на типичных трансформациях.

Temporal splits. Для ML важно, что split по времени, а не случайный. Если данные временные (транзакции, события пользователей), случайный split даёт data leakage: модель видит «будущие» данные при обучении. Правило: train на периоде T1-T2, validation на T2-T3 (с gap для предотвращения leakage), test на T3-T4. Неправильный split может стоить 10–15% качества модели на валидации.

Инкрементальные пайплайны. Модель переобучается еженедельно на новых данных. Нужен пайплайн, который инкрементально добавляет новые записи к обучающей выборке, не перегружая всё с нуля. Delta Lake или Apache Iceberg — форматы с ACID-транзакциями, Change Data Capture, time travel.

Как избежать training-serving skew с помощью Feature Store

Feature Store решает проблему рассинхронизации между обучением и инференсом. Самая коварная ошибка в ML-инфраструктуре — training-serving skew: признак считается по-разному в обучении и в продакшене. Модель учится на «правильных» данных, а инференс получает другие.

Feast (open source) — офлайн store на Parquet/Delta в S3 для обучения, онлайн store на Redis для low-latency инференса (<10ms). Feature definitions как Python-код:

from feast import FeatureView, Field
from feast.types import Float32, Int64

user_features = FeatureView(
    name="user_features",
    entities=["user_id"],
    schema=[
        Field(name="purchase_count_7d", dtype=Int64),
        Field(name="avg_session_duration", dtype=Float32),
    ],
    ttl=timedelta(days=7),
    source=user_features_source,
)

Один definition, используется везде. Нет расхождений.

Потоковые признаки. Когда признак должен обновляться в реальном времени (количество транзакций за последние 10 минут), нужна потоковая обработка. Apache Kafka + Apache Flink или Kafka Streams для вычисления признаков в реальном времени → запись в онлайн store. Сложнее, дороже, нужно только когда staleness признаков критична для качества.

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

Разметка — самая трудоёмкая и недооцениваемая часть ML-проекта. Плохо размеченные данные не исправит никакая архитектура.

Label Studio — open source, поддерживает разметку изображений (bounding box, polygon, segmentation), текста (NER, классификация), аудио, видео. Поднимается за 10 минут через Docker. Для небольших команд — первый выбор.

Оценка качества разметки. Inter-annotator agreement — насколько согласны разметчики между собой. Cohen's Kappa > 0.8 — хорошо, 0.6-0.8 — приемлемо, < 0.6 — задача неоднозначна или инструкция плохая. Пересечение разметок (10-20% примеров размечают два независимых аннотатора) — обязательная практика.

Active learning. Не размечать случайные примеры, а выбирать те, на которых модель наиболее неуверена (low confidence, high uncertainty). Позволяет добиться того же качества при 50-70% объёма разметки. Modals, Prodigy, Label Studio поддерживают active learning workflows. На одном из проектов для NLP мы сократили бюджет на разметку в 2,5 раза за счёт active learning.

Синтетические данные. Когда реальных данных мало или получить их дорого. Для CV: рендеринг в Blender/Unity с реалистичными текстурами (domain randomization). Для NLP: parafrase через LLM, backtranslation. Риск: модель обучается на distribution синтетических данных, а не реальных — нужна осторожность и проверка на реальном holdout.

Качество данных: валидация и мониторинг

Great Expectations — de facto стандарт для data validation в ML-пайплайнах. Expectations — это декларативные утверждения о данных: «колонка age содержит значения от 0 до 120», «колонка user_id не содержит null», «распределение amount не отклоняется более чем на 20% от baseline». Запускается в пайплайне, при провале — блокирует прохождение.

Pandera — Pythonic alternative для pandas/polars DataFrames. Schema-based validation с type hints:

import pandera as pa

schema = pa.DataFrameSchema({
    "user_id": pa.Column(int, nullable=False),
    "score": pa.Column(float, pa.Check.between(0, 1)),
    "label": pa.Column(str, pa.Check.isin(["positive", "negative", "neutral"])),
})

Data freshness. Модель ожидает данные за последние N дней. ETL упал, данные не обновились — модель использует устаревшие признаки. Мониторинг свежести данных: timestamp последней записи в каждой таблице, алерт при задержке > порога.

Дедупликация. Дубликаты в обучающей выборке завышают метрики (одни и те же примеры в train и val) и искажают веса модели. MinHash LSH для приближённой дедупликации больших датасетов. Для точной — хэш по нормализованному контенту.

Инструменты валидации: сравнение

Хранилища и форматы

Для большинства ML-проектов на старте: Parquet в S3 + DVC для версионирования. Delta Lake или Iceberg — когда появляется потребность в инкрементальных обновлениях или time travel.

Что входит в проект по дата-инжинирингу для ML

Мы предоставляем полный цикл:

• Аудит существующих данных и пайплайнов (1 неделя).
• Проектирование архитектуры: выбор инструментов, форматов, способов разметки.
• Реализация ETL/ELT пайплайна с валидацией и мониторингом.
• Документация кода и процессов (model card, data card).
• Обучение вашей команды работе с пайплайном.
• SLA на сопровождение и поддержку.

Как мы строим пайплайн: пошагово

1. Аудит существующих данных. Профилирование: ydata-profiling (бывший pandas-profiling) генерирует HTML-репорт со статистиками, дистрибуциями, корреляциями, missing values за минуты.
2. Проектирование пайплайна. Определяем источники данных, частоту обновления, требования к latency признаков, объёмы.
3. Реализация и тестирование. Unit-тесты на трансформации, integration-тесты на пайплайн, data validation через Great Expectations.
4. Деплой и мониторинг. Алерты на freshness, quality checks, аномалии в объёмах данных.

Почему стоит доверить это нам

Мы занимаемся дата-инжинирингом и ML с 2016 года. За это время реализовали более 40 проектов — от построения пайплайнов для NLP-моделей до разметки датасетов для компьютерного зрения. Гарантируем воспроизводимость пайплайнов и полную прозрачность процессов. В каждом проекте используем инструменты с открытым исходным кодом, чтобы вы не были привязаны к вендору.

Свяжитесь с нами для бесплатного аудита ваших данных — оценим текущий пайплайн и предложим roadmap. Закажите построение ML-пайплайна под ключ.