Навчання 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-пайплайн. Зв'яжіться з нами для консультації по вашому проєкту. Замовте пілотний проєкт, щоб оцінити приріст метрик. Вартість розраховується індивідуально. Отримайте консультацію по вашому проєкту — наші інженери допоможуть обрати оптимальний підхід.

Чому дата-інжиніринг визначає успіх ML-моделі

Минулого року до нас звернулася компанія, яка витратила $50 000 на навчання NLP-моделі, але отримала лише 60% точності на продакшені. Причина — data leakage через випадковий split часових даних. Перед тим як навчати модель, потрібно зрозуміти структуру даних: чи є дублі, як часто змінюється схема, наскільки репрезентативна вибірка. Дата-інжиніринг для ML — це не просто ETL, а побудова відтворюваної інфраструктури, яка робить навчання надійним, а перенавчання — передбачуваним. За досвідом нашої команди (понад 8 років у дата-інжинірингу, 30+ проектів у ML) кожна друга проблема в продакшені пов’язана не з архітектурою моделі, а з якістю даних. Замовте аудит ваших даних — оцінимо поточний пайплайн безкоштовно.

Як ETL-пайплайни для ML відрізняються від BI

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

Інструменти. Apache Spark для великих обсягів (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% якості моделі на валідації. Temporal split best practices (scikit-learn docs)

Інкрементальні пайплайни. Модель перенавчається щотижня на нових даних. Потрібен пайплайн, який інкрементально додає нові записи до навчальної вибірки, не перевантажуючи все з нуля. 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 — економія склала $15 000 на 100 000 розмічених прикладів.

Синтетичні дані. Коли реальних даних мало або отримати їх дорого. Для 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.

Типові помилки при побудові пайплайнів

• Пропуск перевірки свіжості даних. Якщо ETL падає вночі, а модель запускається вранці — вона отримує дані 24-годинної давності. Рішення: алерт при затримці > 30 хвилин.
• Відсутність версіонування даних. Не можна відтворити експеримент, бо дані змінилися. DVC або Delta Lake time travel виправляють це.
• Забувають про schema evolution. Нове поле з’являється, а пайплайн падає. Автоматичне виявлення змін схеми через Great Expectations.

Active learning дозволяє скоротити бюджет на розмітку до 50–70%. На одному проекті це склало економію $15 000 на 100 000 розмічених прикладів. Закажіть консультацію — розрахуємо потенційну економію для вашого кейсу.

Що входить у проект з дата-інжинірингу для ML

Ми надаємо повний цикл:

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

Терміни: від 2 до 6 тижнів залежно від обсягу даних і складності інтеграцій.

Як ми будуємо пайплайн: покроково

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

Чому варто довірити це нам

Ми займаємося дата-інжинірингом та ML з понад 8-річним досвідом. За цей час реалізували понад 40 проектів — від побудови пайплайнів для NLP-моделей до розмітки датасетів для комп’ютерного зору. Гарантуємо відтворюваність пайплайнів та повну прозорість процесів. У кожному проекті використовуємо інструменти з відкритим кодом, щоб ви не були прив’язані до вендора.

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