Оптимизация гиперпараметров: Optuna и Ray Tune
Типичная история: модель обучена, базовый accuracy вроде приемлемый. Но learning_rate=0.001 взят «из примеров в документации», batch_size=32 «потому что стандарт», dropout=0.3 «на глаз». После грамотной HPO на том же датасете и той же архитектуре получаем +4–8% accuracy — просто за счёт правильных гиперпараметров. Это не магия, это систематический поиск.
Почему Random Search проигрывает Bayesian Optimization
Random Search эффективен при высокой размерности пространства и малом бюджете триалов. Но как только важных гиперпараметров 3–5 (а это типичный случай), Bayesian Optimization с TPE (Tree-structured Parzen Estimator) начинает выигрывать с ~30-го триала. Суть TPE: строит раздельные плотности вероятности для «хороших» (top-25%) и «плохих» конфигураций, затем предлагает конфигурации с высоким EI (Expected Improvement).
Grid Search в 2025 году применим только к двум гиперпараметрам максимум — дальше комбинаторный взрыв делает его нецелесообразным.
Глубокий разбор: Optuna в production
Optuna — de-facto стандарт для HPO в Python-экосистеме. Ключевые преимущества перед конкурентами: Pythonic API без YAML-конфигов, встроенная поддержка pruning (обрезка плохих триалов на ранней стадии), интеграция с MLflow и Weights & Biases.
Полный пример: оптимизация 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: обрезает плохие триалы после каждого round
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))
# Создаём study с TPE sampler и Hyperband pruner
sampler = optuna.samplers.TPESampler(
n_startup_trials=20, # случайный поиск до построения surrogate
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', # persistence между сессиями
load_if_exists=True
)
study.optimize(
lambda trial: objective(trial, X, y),
n_trials=200,
n_jobs=4, # параллельные триалы
timeout=3600, # максимум 1 час
show_progress_bar=True
)
print(f'Best AUC: {study.best_value:.4f}')
print(f'Best params: {study.best_params}')
Pruning — ключевая экономия вычислений. Hyperband Pruner убивает плохие триалы на ранних rounds обучения. На практике: из 200 триалов LightGBM — 40–60% обрезаются после 50–100 rounds вместо полных 2000. Итоговое ускорение: 3–5× по сравнению с тем же числом полных триалов.
Визуализация и анализ важности параметров:
import optuna.visualization as vis
# Какие гиперпараметры реально влияют на результат
fig = vis.plot_param_importances(study)
fig.show()
# История оптимизации — смотрим, сошлась ли она
fig = vis.plot_optimization_history(study)
fig.show()
# Correlation matrix: num_leaves vs learning_rate
fig = vis.plot_contour(study, params=['num_leaves', 'learning_rate'])
fig.show()
Анализ важности параметров через fANOVA часто даёт неожиданные результаты: num_leaves и min_child_samples оказываются важнее learning_rate для LightGBM на несбалансированных данных. Это меняет стратегию — следующий поиск фокусируется на узком диапазоне важных параметров.
Ray Tune: distributed HPO на кластере
Ray Tune решает другую задачу — параллельный поиск на кластере GPU. Если Optuna с n_jobs=4 параллелит на одной машине, Ray Tune масштабируется до сотен узлов.
from ray import tune
from ray.tune.schedulers import ASHAScheduler
from ray.tune.search.optuna import OptunaSearch
import torch
def train_transformer(config: dict):
"""
Ray Tune ожидает функцию, которая репортит метрики через tune.report().
"""
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)
# Ray Tune получает метрику для Scheduler/Search
tune.report(
val_loss=val_loss,
val_acc=val_acc,
epoch=epoch
)
# ASHA (Asynchronous Successive Halving) — aggressive early stopping
scheduler = ASHAScheduler(
time_attr='epoch',
max_t=100, # максимум epochs
grace_period=10, # минимум epochs до обрезки
reduction_factor=3, # каждые 3× — половина триалов выбывает
metric='val_loss',
mode='min'
)
# OptunaSearch внутри Ray Tune — лучший из обоих миров
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', # S3 для distributed setup
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). Самые важные параметры по fANOVA: scale_pos_weight (22% важности), min_child_weight (18%), subsample (15%). max_depth и n_estimators — суммарно 14%.
| Этап | PR-AUC | Recall при Precision=0.8 |
|---|---|---|
| XGBoost default | 0.412 | 0.34 |
| Random Search (50 trials) | 0.521 | 0.47 |
| Optuna TPE (150 trials) | 0.581 | 0.56 |
| + Feature engineering | 0.634 | 0.62 |
Optuna vs Ray Tune: когда что выбрать
| Критерий | Optuna | Ray Tune |
|---|---|---|
| Одна машина, 1–8 GPU | + | избыточен |
| Кластер 10+ GPU/узлов | сложнее | + |
| Deep learning (PyTorch/JAX) | + | + |
| Классический ML (sklearn, lgbm) | + | работает |
| Интеграция с distributed training | через callbacks | native |
| Восстановление после сбоя | SQLite/PostgreSQL backend | + |
| Кривая обучения для новой команды | пологая | круче |
Интеграция с 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
# Все триалы — отдельные MLflow runs, удобно для сравнения
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.
Сроки: базовая HPO с Optuna на одной задаче — 2–5 дней включая настройку окружения и анализ результатов. Distributed HPO с Ray Tune на кластере, интеграция с CI/CD пайплайном — 2–4 недели.







