Налаштування FinRL Framework для навчання торгового агента

Торговий агент на основі DRL дає збій, якщо середовище не відображає реальні комісії та ліквідність. Ми стикалися з проєктами, де модель показувала 200% дохідності в симуляції, але на живому ринку втрачала капітал через ігнорування спредів та slippage. FinRL вирішує це через налаштовуване середовище StockTradingEnv, де можна задати комісії купівлі/продажу, початковий капітал та ліміти на транзакцію. Нерідко розробники копіюють конфігурацію зі статті без урахування свого брокера: наприклад, використовують стандартні 0.1% комісії, а реальні — 0.3% з урахуванням спреду. Після коригування середовища дохідність впала з 30% до 8%, зате модель стала стабільно заробляти на реалі. Ми налаштовуємо середовище під конкретні ринкові умови: ліквідність, спреди, обмеження на обсяг позиції. Наш досвід — понад 5 років впровадження DRL у фінансах, десятки успішних проєктів. Гарантуємо робочий baseline за 2–3 дні. Отримайте консультацію — оцінимо ваш кейс під ключ. Зв'яжіться з нами для розрахунку вартості та термінів.

Типові проблеми при налаштуванні FinRL

Ігнорування комісій та прослизання. Якщо не задати buy_cost_pct та sell_cost_pct, агент буде здійснювати угоди з нульовими витратами, що в реальності неможливо. У проєкті з одним хедж-фондом ми додали прослизання 0.05% на угоду — дохідність знизилася на 12%, але модель стала стійкою до ринкових умов.

Перенавчання на історичних даних. Агент може запам'ятати шум замість сигналу. Щоб цього уникнути, використовуємо out-of-sample бектест з розділенням даних 70/30 та регуляризацію через ентропійний бонус у PPO. Типова економія на штрафах за ризик: +15% Sharpe ratio.

Некоректна нормалізація ознак. Ціни акцій не масштабовані, що ускладнює навчання. FinRL автоматично застосовує Z-score нормалізацію до технічних індикаторів, але якщо дані містять викиди (наприклад, flash crash), агент може обрати невірну стратегію. Ми додаємо winsorization на 0.5% перцентиля.

Встановлення та перший запуск

pip install finrl
pip install stockstats wrds alpaca-trade-api  # джерела даних

Швидкий старт:

import finrl
from finrl.train import train
from finrl.test import test
from finrl.config_tickers import DOW_30_TICKER
from finrl.config import INDICATORS

# навчання на акціях Dow Jones 30
train(
    start_date='2010-01-01',
    end_date='2021-10-31',
    ticker_list=DOW_30_TICKER,
    data_source='yahoofinance',
    technical_indicator_list=INDICATORS,
    drl_lib='stable_baselines3',
    env='stock_trading',
    model_name='ppo',
    if_store_account_value=True,
    cwd='./trained_models/ppo_dow30'
)

test(
    start_date='2021-11-01',
    end_date='2023-12-31',
    ticker_list=DOW_30_TICKER,
    data_source='yahoofinance',
    technical_indicator_list=INDICATORS,
    drl_lib='stable_baselines3',
    env='stock_trading',
    model_name='ppo',
    cwd='./trained_models/ppo_dow30'
)

Як налаштувати функцію винагороди?

Функція винагороди визначає поведінку агента. У FinRL вона задається через reward_scaling у env_kwargs. За замовчуванням нагорода дорівнює зміні вартості портфеля. Ми часто додаємо штраф за надмірний ризик, наприклад, дисперсію денних дохідностей. Це змушує агента шукати більш стабільні стратегії, підвищуючи Sharpe ratio на 15–20%.

from finrl.meta.env_stock_trading.env_stocktrading import StockTradingEnv

env_kwargs = {
    "hmax": 100,                    # max акцій за транзакцію
    "initial_amount": 1_000_000,    # початковий капітал
    "buy_cost_pct": [0.001] * n,    # комісія купівлі
    "sell_cost_pct": [0.001] * n,   # комісія продажу
    "state_space": state_space,
    "stock_dim": n_tickers,
    "tech_indicator_list": INDICATORS,
    "action_space": n_tickers,
    "reward_scaling": 1e-4          # масштаб reward
}

env = StockTradingEnv(df=train_df, **env_kwargs)

Чому PPO ефективний для трейдингу?

PPO (Proximal Policy Optimization) — один із найпопулярніших алгоритмів для фінансових DRL. Він стабільніший за A2C, швидший за DDPG і вимагає менше налаштування гіперпараметрів. У наших бенчмарках PPO перевершує A2C за Sharpe ratio на 15–20% і збігається в 2 рази швидше за DDPG на однаковому обсязі даних. Згідно з дослідженням, PPO забезпечує надійну збіжність у задачах з неперервним простором дій.

Для порівняння моделей використовуйте вбудовані функції FinRL:

models = ['a2c', 'ddpg', 'ppo', 'td3', 'sac']
results = {}

for model_name in models:
    train(model_name=model_name, cwd=f'./models/{model_name}', ...)
    account_value = test(model_name=model_name, cwd=f'./models/{model_name}', ...)
    results[model_name] = account_value

# візуалізація
from finrl.plot import backtest_plot
backtest_plot(results, baseline_start='2022-01-01', baseline_end='2023-12-31',
             baseline_ticker='^GSPC')  # vs S&P500

Як уникнути overfitting при навчанні агента?

Overfitting — часта проблема DRL у фінансах. Щоб її уникнути, використовуйте наступні прийоми:

• Розділіть дані на train/validation/test (наприклад, 60/20/20). Валідаційна вибірка потрібна для ранньої зупинки.
• Застосуйте регуляризацію: у PPO це параметр ent_coef (ентропійний бонус). Значення 0.01–0.05 покращує узагальнення.
• Додайте noise у середовище: випадкові затримки виконання ордерів або стохастичну комісію. Це імітує ринковий шум.
• Обмежте кількість кроків епізоду — не більше 252 (торговий рік). Короткий епізод змушує агента фокусуватися на короткострокових сигналах.
• Перевіряйте модель на out-of-sample періодах з кризами (наприклад, 2020). Якщо дохідність падає більш ніж на 30%, агент переобучений.

Які метрики використовувати для оцінки агента?

Не варто покладатися лише на накопичену дохідність. Використовуйте комплекс метрик:

• Sharpe ratio — дохідність з поправкою на ризик. Хороший агент показує Sharpe > 1.0.
• Maximum drawdown — максимальна просадка. Допустимо не більше 20% від піку.
• Win rate — відсоток прибуткових угод. Вище 50% вже добре, але залежить від стратегії.
• Calmar ratio — відношення річної дохідності до максимальної просадки. Ідеально > 2.
• Sortino ratio — аналог Sharpe, враховує лише негативну волатильність. Більш суворий.

У FinRL ці метрики можна отримати через backtest_plot() або розрахувати вручну з account_value. Ми надаємо у звіті всі ключові показники.

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

• Аналіз доступних ринкових даних та вибір джерел.
• Конфігурація середовища StockTradingEnv під вашого брокера/ринок.
• Навчання 5 DRL-алгоритмів з автоматичним підбором гіперпараметрів.
• Бектестинг на історичних даних зі звітом за метриками (Sharpe, Sortino, Max Drawdown).
• Передача навченої моделі та документації по запуску.
• Консультація щодо інтеграції у ваш торговий термінал.

Процес роботи

1. Аналітика — розбір вимог, джерел даних, обмежень.
2. Проєктування — визначення state/action space, функції reward.
3. Реалізація — налаштування FinRL, навчання baseline моделей.
4. Тестування — бектест на out-of-sample даних, перевірка на стійкість.
5. Деплой — видача моделі, навчання персоналу.

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

Вартість розраховується індивідуально — пишіть, оцінимо проєкт. Наші сертифіковані за TensorFlow інженери мають досвід роботи з JAX та PyTorch. Отримайте консультацію — обговоримо деталі. Замовте налаштування FinRL — отримайте робочий прототип за 2–3 дні.

Навчання з підкріпленням: PPO, SAC, DQN та промислове застосування

Ми щодня бачимо проєкти, які гинуть не через слабкий алгоритм, а через неправильну винагороду. Інженер пише reward = +1 за правильну дію, запускає навчання, а через 10 млн кроків агент знаходить спосіб отримати максимум, не вирішивши завдання. Це reward hacking — системний біль промислового RL. Наш досвід показує: правильний reward займає 70% успіху.

Чому RL складніше, ніж supervised learning?

У supervised learning є датасет з правильними відповідями. У RL правильної відповіді немає — є скалярний сигнал «краще/гірше», який надходить із затримкою в сотні кроків. Агент сам досліджує простір і знаходить стратегію.

Наслідки: нестабільність навчання, висока чутливість до гіперпараметрів, повільна збіжність. PPO (Proximal Policy Optimization) на Atari сходиться за 10 млн кроків — це години. На роботизованих завданнях з реальною фізикою — дні або тижні в симуляторі.

Чому reward engineering вирішальний для RL?

Без якісної reward-функції навчання перетворюється на лотерею. Reward hacking — класична пастка: агент знаходить неочевидний спосіб максимізувати винагороду, ігноруючи справжню ціль. Один із проєктів — сортування компонентів на PCB — demand: ми витратили 2 тижні на формалізацію reward: штраф за зіткнення, бонус за швидкість, penalty за неправильне розташування. Без цього агент навчився скидати деталі з конвеєра, отримуючи +1 за кожну скинуту, а не за відсортовану.

Як обрати алгоритм під задачу?

Як налаштувати PPO та уникнути типових проблем?

PPO — робоча конячка RL. Основна ідея: обмежуємо оновлення політики через кліпування ratio clip_range=0.2. Це дає стабільність порівняно з vanilla policy gradient. Але без грамотного налаштування агент не сходиться.

Одна з частих пасток — entropy collapse: агент занадто швидко стає детермінованим, перестає досліджувати. Симптом — entropy coefficient падає до нуля. Лікування — ent_coef=0.01–0.05 і не знижувати нижче 0.001. Інша проблема — value function розходиться, коли vf_loss_coef високий, а explained_variance від'ємний. Рекомендуємо vf_coef=0.5 і gradient clipping max_grad_norm=0.5.

Неправильний n_steps також ламає навчання. n_steps=2048 — дефолт Stable‑Baselines3. Для завдань з довгим горизонтом (>500 кроків) потрібно збільшувати, для швидких (10–50 кроків) — зменшувати до 256–512.

Для швидкого старту використовуємо stable‑baselines3 + sb3‑contrib. Для research і кастомних алгоритмів — tianshou або CleanRL.

SAC для безперервного керування

SAC (Soft Actor‑Critic) додає в objective максимізацію ентропії — агент вчиться бути і ефективним, і різноманітним. Це дає відмінну sample efficiency та стійкість до шуму в reward. На задачах керування техпроцесами SAC зазвичай обходить PPO за збіжністю: потребує на 30–40% менше взаємодій для досягнення тієї ж якості. Ключовий параметр — target_entropy. Стандартне значення ‑dim(action_space) часто підходить, але для специфічних завдань краще налаштовувати вручну.

Як перенести навченого агента на реальний пристрій?

Навчати RL на реальному роботі — дорого та небезпечно. Стандартний підхід: навчання в симуляторі → трансфер на реальне залізо. Основна проблема — reality gap: симулятор не відтворює фізику, тертя, шум датчиків.

Головний інструмент — domain randomization. Під час навчання випадково варіюємо параметри середовища: маса об'єктів ±30%, коефіцієнт тертя ±50%, затримка дій 0–100 мс, шум спостережень σ=0.01–0.1. Агент навчається бути робастним до варіацій, і реальний світ стає лише ще однією варіацією.

Порівняння популярних симуляторів:

RLHF: навчання LLM з людського зворотного зв'язку

RLHF став стандартом після InstructGPT. Класична схема: supervised fine‑tuning → reward model → PPO.

Проблеми класичного PPO: нестабільність (KL‑дивергенція може вибухнути), повільна збіжність, складність налаштування. Тому популярні альтернативи:

• DPO — обходить reward model, вчиться на парах уподобань. Простіше, стабільніше, але менш гнучкий.
• GRPO — використовується в DeepSeek‑R1, хороший для reasoning tasks.
• ORPO — об'єднує SFT та alignment в одну стадію.

Бібліотека trl від Hugging Face — стандарт. Підтримує PPO, DPO, ORPO, GRPO з коробки, працює з PEFT/LoRA для memory‑efficient fine‑tuning.

Reward hacking залишається однією з головних причин провалів у RL, поряд з неправильно обраною архітектурою середовища. Це підтверджують дослідження з відкритих джерел (Reward hacking in reinforcement learning, Wikipedia).

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

• Архітектурне рішення та обґрунтування вибору алгоритму
• Розробка та документування reward‑функції
• Створення симулятора або налаштування існуючого
• Навчання, hyper‑parameter sweep (Optuna / Ray Tune)
• Трансфер на реальне залізо або інтеграція в продукт
• Документація, доступи до коду та симуляторів
• Навчання команди та 3‑місячна підтримка після деплою

Процес роботи

1. Аудит завдання — фіксуємо цілі, ресурси, обмеження.
2. Reward engineering — формалізація бажаної поведінки, перевірка на reward hacking.
3. Вибір середовища та алгоритму — baseline, перші прогони.
4. Систематичний hyperparameter sweep — використовуємо Optuna.
5. Навчання в симуляторі з domain randomization.
6. Тестування на реальному обладнанні (за потреби).
7. Деплой, моніторинг, підтримка.

Терміни: proof of concept — 2–4 тижні; production‑система з sim‑to‑real — 3–8 місяців; RLHF для LLM — 4–10 тижнів. Вартість розраховується індивідуально — оцінимо ваш проєкт за 2 дні. Замовте консультацію, щоб уникнути типових пасток RL.

Наша команда — понад п’ять років досвіду в RL, 30+ успішних проєктів у роботиці, оптимізації ланцюгів постачання та LLM alignment. Гарантуємо прозору архітектуру та повну технічну документацію. Зв'яжіться з нами для отримання детальної оцінки вашого проєкту.