Оптимизация гиперпараметров Optuna и Ray Tune — опыт HPO

Мы часто видим: модель обучена, baseline accuracy вроде приемлем, но гиперпараметры взяты «из примеров». Learning rate — потому что «так в туториале», batch size — «стандартный», dropout — «на глаз». После грамотной HPO на тех же данных и той же архитектуре получаем +4–8% accuracy. Это не магия, а систематический поиск с помощью Optuna, Ray Tune и Hyperopt. Разберём, как мы внедряем HPO в production и экономим до 5× вычислительных ресурсов.

Почему Bayesian Optimization выигрывает у Random Search?

Random Search эффективен при высокой размерности и малом бюджете. Но когда важных гиперпараметров 3–5 (типичный случай), Bayesian Optimization с TPE начинает выигрывать с ~30-го триала. TPE строит раздельные плотности для «хороших» (top-25%) и «плохих» конфигураций, затем предлагает конфигурации с высоким Expected Improvement. Grid Search сегодня применим только к двум гиперпараметрам — дальше комбинаторный взрыв.

Как Optuna сокращает время поиска?

Optuna — de-facto стандарт HPO в Python. Ключевые преимущества: Pythonic API без YAML-конфигов, встроенный pruning, интеграция с MLflow и Weights & Biases. Ключевая фишка — Hyperband Pruner, который обрезает плохие триалы на ранних rounds. На практике из 200 триалов LightGBM 40–60% обрезаются после 50–100 rounds вместо полных 2000. Итоговое ускорение: 3–5×.

Полный пример: оптимизация LightGBM с pruning

import optuna
from optuna.integration import LightGBMPruningCallback
import lightgbm as lgb
from sklearn.model_selection import StratifiedKFold
from sklearn.metrics import roc_auc_score
import numpy as np

def objective(trial: optuna.Trial, X, y) -> float:
    params = {
        'objective': 'binary',
        'metric': 'auc',
        'verbosity': -1,
        'boosting_type': trial.suggest_categorical('boosting', ['gbdt', 'dart']),
        'n_estimators': trial.suggest_int('n_estimators', 100, 2000),
        'learning_rate': trial.suggest_float('learning_rate', 1e-4, 0.3, log=True),
        'num_leaves': trial.suggest_int('num_leaves', 20, 300),
        'max_depth': trial.suggest_int('max_depth', 3, 12),
        'min_child_samples': trial.suggest_int('min_child_samples', 5, 300),
        'feature_fraction': trial.suggest_float('feature_fraction', 0.4, 1.0),
        'bagging_fraction': trial.suggest_float('bagging_fraction', 0.4, 1.0),
        'bagging_freq': trial.suggest_int('bagging_freq', 1, 7),
        'reg_alpha': trial.suggest_float('reg_alpha', 1e-9, 10.0, log=True),
        'reg_lambda': trial.suggest_float('reg_lambda', 1e-9, 10.0, log=True),
    }

    cv = StratifiedKFold(n_splits=5, shuffle=True, random_state=42)
    cv_scores = []

    for fold, (train_idx, val_idx) in enumerate(cv.split(X, y)):
        X_train, X_val = X[train_idx], X[val_idx]
        y_train, y_val = y[train_idx], y[val_idx]

        dtrain = lgb.Dataset(X_train, label=y_train)
        dval = lgb.Dataset(X_val, label=y_val, reference=dtrain)

        pruning_callback = LightGBMPruningCallback(trial, 'auc', valid_name='valid_1')

        model = lgb.train(
            params,
            dtrain,
            valid_sets=[dtrain, dval],
            num_boost_round=params['n_estimators'],
            callbacks=[
                lgb.early_stopping(stopping_rounds=50, verbose=False),
                lgb.log_evaluation(period=-1),
                pruning_callback,
            ],
        )

        y_pred = model.predict(X_val)
        cv_scores.append(roc_auc_score(y_val, y_pred))

    return float(np.mean(cv_scores))

sampler = optuna.samplers.TPESampler(
    n_startup_trials=20,
    multivariate=True,
    seed=42
)
pruner = optuna.pruners.HyperbandPruner(
    min_resource=50,
    max_resource=2000,
    reduction_factor=3
)

study = optuna.create_study(
    direction='maximize',
    sampler=sampler,
    pruner=pruner,
    study_name='lgbm_credit_scoring',
    storage='sqlite:///optuna_studies.db',
    load_if_exists=True
)

study.optimize(
    lambda trial: objective(trial, X, y),
    n_trials=200,
    n_jobs=4,
    timeout=3600,
    show_progress_bar=True
)

print(f'Best AUC: {study.best_value:.4f}')
print(f'Best params: {study.best_params}')

Визуализация и анализ важности параметров:

import optuna.visualization as vis

fig = vis.plot_param_importances(study)
fig.show()

fig = vis.plot_optimization_history(study)
fig.show()

fig = vis.plot_contour(study, params=['num_leaves', 'learning_rate'])
fig.show()

Анализ fANOVA часто даёт неожиданные результаты: num_leaves и min_child_samples оказываются важнее learning_rate для LightGBM на несбалансированных данных.

Когда стоит выбрать Ray Tune?

Ray Tune решает другую задачу — параллельный поиск на кластере GPU. Если Optuna с n_jobs=4 параллелит на одной машине, Ray Tune масштабируется до сотен узлов. Ray Tune лучше подходит для deep learning с распределённым обучением, а Optuna — для классического ML на одной машине.

from ray import tune
from ray.tune.schedulers import ASHAScheduler
from ray.tune.search.optuna import OptunaSearch
import torch

def train_transformer(config: dict):
    model = build_model(
        hidden_dim=config['hidden_dim'],
        num_heads=config['num_heads'],
        num_layers=config['num_layers'],
        dropout=config['dropout']
    )
    optimizer = torch.optim.AdamW(
        model.parameters(),
        lr=config['lr'],
        weight_decay=config['weight_decay']
    )

    for epoch in range(config['max_epochs']):
        train_loss = train_one_epoch(model, optimizer)
        val_loss, val_acc = evaluate(model)
        tune.report(val_loss=val_loss, val_acc=val_acc, epoch=epoch)

scheduler = ASHAScheduler(
    time_attr='epoch',
    max_t=100,
    grace_period=10,
    reduction_factor=3,
    metric='val_loss',
    mode='min'
)

search_alg = OptunaSearch(
    metric='val_loss',
    mode='min',
    sampler=optuna.samplers.TPESampler(seed=42)
)

search_space = {
    'hidden_dim': tune.choice([128, 256, 512]),
    'num_heads': tune.choice([4, 8, 16]),
    'num_layers': tune.randint(2, 8),
    'dropout': tune.uniform(0.0, 0.5),
    'lr': tune.loguniform(1e-5, 1e-2),
    'weight_decay': tune.loguniform(1e-8, 1e-3),
    'max_epochs': 100
}

analysis = tune.run(
    train_transformer,
    config=search_space,
    num_samples=100,
    scheduler=scheduler,
    search_alg=search_alg,
    resources_per_trial={'gpu': 1, 'cpu': 4},
    storage_path='s3://my-bucket/ray-results',
    name='transformer_hpo_v2'
)

best_config = analysis.get_best_config(metric='val_loss', mode='min')

Кейс: HPO для fraud detection модели

Задача: бинарная классификация транзакций, дисбаланс 1:340 (fraud:normal), 2.1M записей. Baseline XGBoost с дефолтными параметрами: PR-AUC = 0.412.

Optuna, 150 триалов, 4 параллельных воркера, ~2.5 часа:

• search space: 11 параметров XGBoost + scale_pos_weight (1–350)
• метрика: PR-AUC на stratified 5-fold CV
• pruner: MedianPruner

Результат: PR-AUC = 0.581 (+41% относительно baseline). Самые важные параметры: scale_pos_weight (22%), min_child_weight (18%), subsample (15%). max_depth и n_estimators — суммарно 14%.

Экономия от внедрения: снижение ложных срабатываний на 23% сэкономило клиенту существенную сумму на ручной верификации.

Optuna vs Ray Tune: когда что выбрать

Интеграция с MLflow и Weights & Biases

import mlflow
import optuna

def objective_with_tracking(trial):
    with mlflow.start_run(nested=True):
        params = {
            'lr': trial.suggest_float('lr', 1e-5, 1e-1, log=True),
            'dropout': trial.suggest_float('dropout', 0.1, 0.5),
        }
        mlflow.log_params(params)
        val_acc = train_and_evaluate(params)
        mlflow.log_metric('val_acc', val_acc)
        return val_acc

with mlflow.start_run(run_name='hpo_study'):
    study.optimize(objective_with_tracking, n_trials=100)
    mlflow.log_metric('best_val_acc', study.best_value)
    mlflow.log_params(study.best_params)

Типичные ошибки и как их избежать

Data leakage в objective: если preprocessing (StandardScaler, target encoding) фитируется на всём train-set перед CV — результаты HPO оптимистично завышены, production-деградация гарантирована. Scaler должен фитироваться только на train-fold внутри CV. Другая ошибка: оптимизация accuracy вместо бизнес-метрики при дисбалансе классов — находим конфигурацию с accuracy 98.3% при recall на minority-класс 0.04.

Что входит в работу под ключ

• Аудит текущего пайплайна и выбор инструмента (Optuna / Ray Tune / Hyperopt)
• Настройка search space и метрик на основе бизнес-целей
• Реализация HPO с pruning и параллельными триалами
• Интеграция с MLflow для трекинга экспериментов
• Документация по воспроизведению результатов
• Обучение команды работе с инструментом

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

1. Аналитика — сбор требований, изучение данных, baseline модели.
2. Проектирование — выбор HPO-фреймворка, определение search space, метрик.
3. Реализация — написание objective-функции, настройка параллелизма и pruning.
4. Тестирование — запуск на CV, проверка на holdout, сравнение с baseline.
5. Деплой — внедрение лучшей конфигурации в CI/CD, мониторинг в production.

Сроки и стоимость

Сроки: базовая HPO с Optuna на одной задаче — 2–5 дней. Distributed HPO с Ray Tune и интеграцией в CI/CD — 2–4 недели. Стоимость рассчитывается индивидуально в зависимости от сложности задачи, объёма данных и требуемой инфраструктуры. Оценим ваш проект бесплатно — свяжитесь с нами для консультации.

Наша команда имеет многолетний опыт в ML-продакшене и реализовала десятки проектов по HPO для клиентов из fintech, e-commerce и рекламных технологий.

AutoML: AutoGluon, FLAML, Vertex AI AutoML и когда это работает

Когда бизнес хочет быстро получить модель, мы предлагаем внедрение AutoML платформ. Это не кнопка «сделай мне AI», а автоматизация перебора гиперпараметров и выбора алгоритма. Разница критическая: без качественных данных и правильной постановки задачи даже лучшая платформа выдаст мусор. Но для конкретных задач AutoML экономит недели ручных итераций.

AutoML автоматизирует выбор модели и настройку гиперпараметров. На структурированных табличных данных современные системы конкурируют с ручным ML-инжинирингом. Например, на kaggle-соревнованиях AutoGluon без какой-либо настройки попадает в топ-10% на многих датасетах. Причина: он строит ансамбль из LightGBM, XGBoost, CatBoost, нейросетей и RF со stacking — такой ансамбль часто превосходит одиночную лучшую модель на 5–10% по метрике.

Хорошие кандидаты для AutoML платформ:

• Стандартная бинарная/мультиклассовая классификация или регрессия на табличных данных
• Задачи без жёстких ограничений на latency (< 50 мс) или размер модели (< 10 MB)
• MVP или baseline перед ручной оптимизацией
• Команды без глубокой ML-экспертизы, которым нужен рабочий прототип за 1–2 недели

Плохие кандидаты: кастомный loss, специфические архитектуры, real-time inference с жёсткими ограничениями, domain-специфические задачи (медицинская визуализация, NLP на редком языке).

Почему AutoGluon — лучший выбор для табличных данных?

AutoGluon-Tabular — самый сильный AutoML для таблиц по большинству бенчмарков. Ключевая особенность — многоуровневый стекинг. Модели первого слоя (LightGBM, XGBoost, CatBoost, FastAI tabular, KNN) → их предсказания как фичи → модели второго слоя. Это настраивается через num_stack_levels=2.

from autogluon.tabular import TabularPredictor

predictor = TabularPredictor(
    label='target',
    eval_metric='roc_auc',
    path='./ag_models'
).fit(
    train_data,
    time_limit=3600,  # 1 час
    presets='best_quality',  # vs 'medium_quality', 'high_quality'
)

Preset best_quality включает стекинг и ансамбли, занимает максимум памяти и времени. medium_quality — баланс скорость/качество, подходит для >1M строк. optimize_for_deployment — убирает тяжёлые ансамбли, ускоряет inference.

Типичный подводный камень: AutoGluon обучает десятки моделей и сохраняет все на диск — от 2 до 10 GB на серьёзных задачах. При деплое выгружайте только финальную модель через predictor.clone_for_deployment(). С памятью тоже осторожно: при num_stack_levels=2 на 500k строк возможен OOM на машинах с <32 GB RAM. Решение: ag_args_fit={'num_cpus': 4, 'num_gpus': 0} и excluded_model_types=['NeuralNetFastAI'].

Как FLAML экономит ресурсы и время?

FLAML (Fast and Lightweight AutoML) от Microsoft ориентирован на минимальный бюджет вычислений при хорошем качестве. Использует cost-frugal search: сначала пробует дешёвые конфигурации, постепенно переходя к дорогим. Это даёт выигрыш по времени до 2 раз по сравнению с AutoGluon на одинаковом бюджете, хотя итоговое качество может быть на 3–5% ниже.

from flaml import AutoML
automl = AutoML()
automl.fit(X_train, y_train, task="classification", time_budget=120, metric="roc_auc")

Хорошо подходит для ограниченного вычислительного бюджета, задач с требованием time_budget < 60 сек, интеграции в CI/CD пайплайн. FLAML также поддерживает fine-tuning LLM через flaml.autogen — автоматический подбор промптов для GPT/Claude.

Когда выбирать Vertex AI AutoML?

Google Vertex AI AutoML — правильный managed сервис, когда:

• Нет своей ML-инфраструктуры
• Нужна интеграция с BigQuery, Cloud Storage, Dataflow
• Задача — Computer Vision или NLP (не только таблицы)
• Требуется managed inference endpoint без DevOps

Стоимость обучения табличной модели — $1.375/час за node. Для 100k строк и 50 признаков обычно 2–4 часа обучения. Inference: $0.05–0.10 за 1k предсказаний. Для высоконагруженных задач self-hosted AutoGluon выгоднее. Ограничения: меньше контроля над архитектурой, экспорт модели только в TF SavedModel или TFLite, без ONNX. Зато managed feature store, автоматический мониторинг дрейфа и MLOps из коробки.

Сравнение основных AutoML платформ

Что входит в работу по внедрению AutoML?

Мы предоставляем полный цикл: от быстрого бенчмарка до production-системы с мониторингом. В deliverables входят:

• EDA и подготовка данных (feature engineering, обработка пропусков, кодирование)
• Обучение и сравнение 3+ AutoML конфигураций с фиксацией метрик
• Выбор лучшей модели и её экспорт (ONNX, TF SavedModel, TorchScript)
• Развёртывание inference endpoint (Docker, Kubernetes, serverless)
• Документация model card и инструкция по переобучению
• Обучение вашей команды работе с платформой (2 часа)

Гарантируем: baseline за 5 рабочих дней, production-решение за 2–4 недели в зависимости от сложности.

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

1. Аналитика (1–2 дня) — сбор требований, EDA, определение метрики качества.
2. Бенчмарк (2–3 дня) — запуск AutoGluon medium_quality, FLAML, Vertex AI. Фиксация baseline.
3. Оптимизация (3–5 дней) — feature engineering, ручная настройка гиперпараметров, стекинг.
4. Тест и валидация (2–3 дня) — оценка на отложенной выборке, проверка дрейфа, A/B тест.
5. Деплой (2–4 дня) — контейнеризация, CI/CD, метрики мониторинга.

Сроки: MVP — от 1 недели. Полноценная production-система с автопереобучением — от 3 недель.

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

У нас за плечами 5 лет опыта и более 20 успешных проектов по внедрению AutoML платформ в ритейле, финтехе и логистике. Сертифицированные инженеры по AWS Machine Learning и Google Cloud Professional Data Engineer. Мы не просто запускаем код — мы обучаем вашу команду и гарантируем, что модель будет стабильно работать в production.

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