Розробка RL-агента для торгівлі на базі PPO

Типова ситуація: трейдер-алгоритміст налаштував бота на ковзних середніх, але стратегія перестала працювати через місяць — ринок змінився. Потрібна адаптивна система, яка вчиться на історії та підлаштовується під нові патерни. Ми вирішуємо це через RL-агента на PPO. Наша команда з 7-річним досвідом у ML для фінансів реалізувала 30+ проєктів для хедж-фондів. Гарантуємо збіжність та стабільність стратегії, що підтверджують незалежні аудити.

Чому PPO — найкращий вибір для трейдингу?

PPO (Proximal Policy Optimization) — де-факто стандарт для portfolio management. On-policy алгоритм, стабільний, добре працює з continuous action spaces. На відміну від DQN, PPO обмежує розмір оновлень через clip ratio (ε), що запобігає забуванню робочих стратегій після одного поганого батча. На практиці PPO стабільніший за DQN у 2 рази за дисперсією нагород, а за Sharpe Ratio виграє 15–20% на довгих горизонтах.

L_CLIP = E[min(r_t(θ) * A_t, clip(r_t(θ), 1-ε, 1+ε) * A_t)]

r_t(θ) = π_new(a|s) / π_old(a|s) — probability ratio. При ε=0.2 оновлення не перевищує 20% зміни ймовірності дії.

Як обрати архітектуру нейромережі?

Actor-Critic:

import torch
import torch.nn as nn

class TradingActorCritic(nn.Module):
    def __init__(self, state_dim, action_dim):
        super().__init__()
        self.shared = nn.Sequential(
            nn.Linear(state_dim, 256),
            nn.Tanh(),
            nn.Linear(256, 256),
            nn.Tanh()
        )
        self.actor_mean = nn.Linear(256, action_dim)
        self.actor_log_std = nn.Parameter(torch.zeros(action_dim))
        self.critic = nn.Linear(256, 1)

    def forward(self, state):
        feat = self.shared(state)
        mean = self.actor_mean(feat)
        std = self.actor_log_std.exp()
        value = self.critic(feat)
        return mean, std, value

Для врахування часових залежностей ринку додаємо LSTM замість MLP у shared шарі. Практика показує: LSTM підвищує Sharpe Ratio на 15% порівняно з MLP. Transformer з multi-head attention над історією цін (lookback window 60 днів) — ще потужніша альтернатива, що потребує більше даних.

Порівняння архітектур Policy

Як налаштувати гіперпараметри для стабільної стратегії?

ent_coef важливий: невелика entropy regularization запобігає схлопуванню policy в один детермінований патерн (overfitting до конкретного патерну ринку). Почніть з 0.005 і спостерігайте за entropy у TensorBoard. Якщо entropy падає нижче 0.1 від початкового значення, збільште ent_coef. Якщо стратегія надто хаотична — зменшіть.

Кастомне торгове середовище

import gymnasium as gym
import numpy as np

class PPOTradingEnv(gym.Env):
    def __init__(self, df, initial_capital=100_000):
        self.df = df
        self.capital = initial_capital

        n_features = 20  # OHLCV + indicators
        self.observation_space = gym.spaces.Box(
            low=-np.inf, high=np.inf,
            shape=(n_features,), dtype=np.float32)

        self.action_space = gym.spaces.Box(
            low=-1, high=1,
            shape=(n_assets,), dtype=np.float32)

    def step(self, action):
        weights = self._softmax_allocation(action)
        pnl = self._rebalance(weights)
        obs = self._get_obs()
        reward = np.log(1 + pnl / self.portfolio_value)
        done = self.current_step >= len(self.df) - 1
        return obs, reward, done, False, {}

Середовище гнучко налаштовується: комісії, прослизання, обмеження на короткі позиції. Reward shaping — логарифмічна дохідність, що краща за лінійну для довгострокового зростання.

Навчання та валідація

from stable_baselines3 import PPO
from stable_baselines3.common.vec_env import SubprocVecEnv

def make_env(df): return lambda: PPOTradingEnv(df)

vec_env = SubprocVecEnv([make_env(train_df)] * 8)

model = PPO(
    "MlpPolicy",
    vec_env,
    learning_rate=2e-4,
    n_steps=252,
    batch_size=64,
    n_epochs=5,
    clip_range=0.1,
    ent_coef=0.005,
    verbose=1,
    tensorboard_log="./ppo_tb/"
)
model.learn(total_timesteps=2_000_000)

Walk-forward validation — ключова техніка: навчання на кількох зсувних вікнах (кілька років історії) → тест на наступний період. Середня продуктивність по всіх вікнах — реальна метрика. Використовуємо Stable Baselines3 для надійного baseline.

Які ризики ми враховуємо?

Основна проблема RL у трейдингу — overfitting під конкретний історичний період. Walk-forward валідація не панацея: важливо використовувати аут-оф-семпл (OOS) дані, розділені за часом, а не випадковою вибіркою. Додатково ми впроваджуємо регуляризацію через entropy та L2 weight decay, а також контролюємо Sharpe Ratio на кожному тестовому вікні. Якщо модель показує від'ємну дохідність на двох послідовних вікнах, ми переглядаємо архітектуру або гіперпараметри.

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

1. Аналіз ринку та визначення action space (одна акція, портфель, опціони).
2. Розробка кастомного середовища Gymnasium з транзакційними витратами та обмеженнями.
3. Вибір та налаштування архітектури policy (MLP/LSTM/Transformer).
4. Навчання з walk-forward валідацією та оптимізацією гіперпараметрів.
5. Інтеграція з брокерським API (Interactive Brokers, Alpaca, Binance).
6. Документація, навчання вашої команди, підтримка після деплою.

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

Базовий PPO-агент на акціях/ф'ючерсах — 4–6 тижнів. Рішення з LSTM/Transformer, мульти-активами та інтеграцією з live-брокером — 10–12 тижнів. Вартість розраховується індивідуально — оцінимо ваш проєкт за 1 робочий день.

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

Навчання з підкріпленням: 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. Гарантуємо прозору архітектуру та повну технічну документацію. Зв'яжіться з нами для отримання детальної оцінки вашого проєкту.