Розробка системи оптимізації гіперпараметрів торгової AI-моделі

Розробка системи оптимізації гіперпараметрів торгової AI-моделі — ключовий етап, коли стандартний grid search підводить. Клієнт прийшов з готовою LSTM-моделлю для торгівлі ф'ючерсами. На історії вона показувала Sharpe 1.5, але на live-даних провалилася до 0.3. Діагноз: стандартний grid search з 5-fold крос-валідацією дав data leakage — параметри підігналися під шум, а не під сигнал. Ми застосували walk-forward validation з Bayesian optimization на Optuna, що дозволило зберегти стабільність моделі та уникнути підгонки. Підсумковий out-of-sample Sharpe склав 1.1 — модель перестала втрачати гроші на нових даних. Цей кейс — ілюстрація того, чому фінансова оптимізація гіперпараметрів потребує особливих підходів.

Проблеми, які вирішуємо

• Data leakage через порушення часової причинності при стандартній крос-валідації. Кожна точка даних — частина часового ряду, і використовувати майбутнє для прогнозу минулого не можна.
• Overfitting — параметри, підібрані на повній історії, оптимальні лише для неї. На свіжих даних вони дають збиток, тому що модель запам'ятала шум, а не патерн.
• Зміна ринкового режиму — бичачий тренд змінюється флетом або високою волатильністю. Параметри, які чудово працювали в тренді, в боковику генерують хибні сигнали.
• Висока розмірність простору параметрів — grid search потребує перебору мільйонів комбінацій, що займає дні. Навіть random search не гарантує знаходження оптимуму за прийнятний час.

Чому стандартний AutoML не працює для трейдингу?

Стандартні AutoML-бібліотеки (H2O, TPOT) використовують k-fold CV, яка для часових рядів — зло. Вони не враховують режим ринку та оптимізують метрики класифікації, а не фінансові показники. Результат — красива крива equity на історії та злив на реальному рахунку.

Що таке walk-forward validation і навіщо він потрібен?

Walk-forward validation — єдиний чесний метод для часових рядів. Він запобігає data leakage. Ми навчаємо модель на in-sample вікні, тестуємо на out-of-sample, зсуваємо вікно вперед і повторюємо. Агрегована OOS метрика — реальна оцінка якості.

import numpy as np
import pandas as pd
from typing import Callable

def walk_forward_optimization(
    price_data: pd.DataFrame,
    strategy_func: Callable,
    param_space: dict,
    in_sample_months: int = 12,
    out_sample_months: int = 3
) -> dict:
    """
    WFO: навчаємо на IS періоді, тестуємо на OOS — і так ковзаємо вперед.
    Метрика = агрегований OOS Sharpe ratio по всіх періодах.
    """
    results = []
    total_months = len(price_data) // 21  # ~21 торговий день у місяці

    for start_month in range(0, total_months - in_sample_months, out_sample_months):
        is_end = start_month + in_sample_months
        oos_end = is_end + out_sample_months

        if oos_end > total_months:
            break

        is_data = price_data.iloc[start_month * 21: is_end * 21]
        oos_data = price_data.iloc[is_end * 21: oos_end * 21]

        # Оптимізація на IS періоді
        best_params = optimize_on_period(strategy_func, is_data, param_space)

        # Тест на OOS
        oos_returns = strategy_func(oos_data, **best_params)
        oos_sharpe = calculate_sharpe(oos_returns, annualization=252)

        results.append({
            'period_start': is_end,
            'best_params': best_params,
            'oos_sharpe': oos_sharpe,
            'oos_returns': oos_returns
        })

    return {
        'wfo_results': results,
        'avg_oos_sharpe': np.mean([r['oos_sharpe'] for r in results]),
        'sharpe_stability': np.std([r['oos_sharpe'] for r in results]),
        'profitable_periods': sum(1 for r in results if r['oos_sharpe'] > 0) / len(results)
    }

Як ми використовуємо Bayesian Optimization?

Bayesian Optimization будує ймовірнісну модель цільової функції — у нашому випадку складеної метрики, що включає Sharpe, максимальну просадку та транзакційні витрати. Замість перебору всіх комбінацій (як у grid search) алгоритм вибирає наступну точку, де очікується покращення. Це дозволяє знайти оптимум за 200 trials замість 10000. У трейдингу це критично: кожна ітерація — backtest на історії, який займає хвилини. За нашими оцінками, Bayesian Optimization з walk-forward знаходить стабільні параметри в 10 разів швидше grid search і знижує ризик overfitting на 50%. Для реалізації ми використовуємо Optuna — фреймворк з TPE-семплером та Hyperband pruning.

import optuna

def optimize_trading_model(train_data: pd.DataFrame,
                             val_data: pd.DataFrame) -> dict:
    def objective(trial):
        params = {
            'n_estimators': trial.suggest_int('n_estimators', 100, 500),
            'max_depth': trial.suggest_int('max_depth', 3, 8),
            'learning_rate': trial.suggest_float('learning_rate', 1e-3, 0.1, log=True),
            'min_samples_leaf': trial.suggest_int('min_samples_leaf', 50, 500),
            'feature_fraction': trial.suggest_float('feature_fraction', 0.5, 1.0),
            # Специфічні для фінансів параметри
            'lookback_window': trial.suggest_int('lookback_window', 5, 60),
            'prediction_horizon': trial.suggest_categorical('prediction_horizon', [1, 5, 10, 20]),
            'threshold_long': trial.suggest_float('threshold_long', 0.001, 0.01),
            'threshold_short': trial.suggest_float('threshold_short', -0.01, -0.001)
        }

        # Навчаємо та тестуємо
        model = train_model(train_data, params)
        signals = generate_signals(val_data, model, params)
        returns = backtest_signals(val_data, signals)

        # Складена метрика: Sharpe зі штрафом за drawdown
        sharpe = calculate_sharpe(returns)
        max_dd = calculate_max_drawdown(returns)
        # Штраф за надмірну торгівлю (транзакційні витрати)
        trade_count = signals.abs().sum()
        cost_penalty = trade_count * 0.0001  # 1 bp за угоду
        # Optuna максимізує: sharpe - drawdown_penalty - cost_penalty
        return sharpe - abs(max_dd) * 0.5 - cost_penalty

    study = optuna.create_study(
        direction='maximize',
        sampler=optuna.samplers.TPESampler(seed=42),
        pruner=optuna.pruners.HyperbandPruner()
    )
    study.optimize(objective, n_trials=200, timeout=3600)

    return {
        'best_params': study.best_params,
        'best_value': study.best_value,
        'n_trials': len(study.trials)
    }

Як враховувати зміну режиму ринку?

Ринок нестабільний: тренд змінюється флетом, волатильність зростає та падає. Один набір гіперпараметрів не може бути оптимальним для всіх станів. Ми використовуємо HMM для детекції режимів (зазвичай 3: тренд, флет, висока волатильність). Для кожного режиму попередньо запускаємо окрему walk-forward оптимізацію. У live-торгівлі модель визначає поточний режим за останніми 20 барами і застосовує відповідні параметри.

from hmmlearn import hmm

class RegimeAwareOptimizer:
    """
    Різні режими ринку (тренд/флет/волатильність) потребують різних гіперпараметрів.
    HMM визначає режим → вибираємо попередньо оптимізований набір параметрів.
    """
    def __init__(self, n_regimes=3):
        self.regime_model = hmm.GaussianHMM(n_components=n_regimes, covariance_type='full')
        self.regime_params = {}  # {режим: best_params}

    def fit_regimes(self, returns: np.ndarray):
        features = np.column_stack([
            returns,
            np.abs(returns),                         # волатильність
            pd.Series(returns).rolling(20).std().values  # rolling vol
        ])
        self.regime_model.fit(features[~np.isnan(features).any(axis=1)])

    def optimize_per_regime(self, price_data, strategy_func, param_space):
        """Для кожного режиму — окрема WFO оптимізація"""
        regimes = self.get_current_regime(price_data)

        for regime_id in range(self.regime_model.n_components):
            regime_data = price_data[regimes == regime_id]
            if len(regime_data) > 500:
                self.regime_params[regime_id] = optimize_trading_model(
                    regime_data[:len(regime_data)//2],
                    regime_data[len(regime_data)//2:]
                )['best_params']

    def get_current_regime(self, recent_data: pd.DataFrame) -> int:
        features = extract_regime_features(recent_data.tail(20))
        return self.regime_model.predict(features)[-1]

Порівняння методів оптимізації

Результати оптимізації (приклад)

Економія на транзакційних витратах може сягати 40%, що в грошовому вираженні становить сотні тисяч рублів на місяць при активній торгівлі.

Етапи роботи

1. Аналіз даних і стратегії — вивчаємо історію, визначаємо метрики.
2. Вибір методу валідації — налаштовуємо walk-forward вікна.
3. Побудова простору гіперпараметрів — задаємо діапазони та розподіли.
4. Оптимізація за допомогою Optuna + WFO — запускаємо 200+ trials.
5. Аналіз стабільності та адаптація під режими — детекція режимів, переоптимізація.
6. Передача результатів і документація — звіт, код, інтеграція.

Терміни орієнтовно

• Walk-forward validation + Optuna базова оптимізація + backtest — 3–4 тижні.
• Regime-aware optimization, адаптивна переоптимізація, multi-objective Pareto front — 6–8 тижнів.

Що входить в роботу

• Повний звіт з візуалізаціями (графіки Sharpe, drawdown, стабільності).
• Оптимізований код моделі з конфігами.
• Інтеграція у ваш торговий пайплайн.
• Навчання команди (1 день).
• Підтримка 1 місяць після здачі.

Все виконується під ключ — ви отримуєте готове рішення та консультації щодо його експлуатації. Наші сертифіковані спеціалісти з досвідом більше 5 років у галузі машинного навчання та трейдингу виконають оптимізацію під ключ. Запрошуємо вас отримати консультацію щодо вашого проекту. Зв'яжіться з нами, щоб обговорити деталі та отримати попередню оцінку.

AutoML: AutoGluon, FLAML, Vertex AI AutoML і коли це працює

Коли бізнес хоче швидко отримати модель, ми пропонуємо впровадження AutoML платформ. Це не кнопка «зроби мені AI», а автоматизація перебору гіперпараметрів і вибору алгоритму. Різниця критична: без якісних даних і правильної постановки задачі навіть найкраща платформа видасть сміття. Але для конкретних задач AutoML економить тижні ручних ітерацій.

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

Як AutoML може прискорити створення моделей?

Хороші кандидати для 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'].

Порівняння preset-конфігурацій AutoGluon

Як 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

Вартість навчання обчислюється погодинно за використання нод. Для 100k рядків і 50 ознак зазвичай 2–4 години навчання. Для високонавантажених задач 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 тижні залежно від складності. Типова економія бюджету клієнта — до 40% порівняно з ручною розробкою. Оцініть потенційну економію для вашого проєкту — зв'яжіться з нами.

Процес роботи та терміни

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.