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

Проектуємо та впроваджуємо системи штучного інтелекту: від прототипу до production-ready рішення. Наша команда поєднує експертизу в машинному навчанні, дата-інжинірингу та MLOps, щоб AI працював не в лабораторії, а в реальному бізнесі.
Показано 1 з 1Усі 1564 послуг
Розробка RL-агента для торгівлі на основі SAC
Складний
~2-4 тижні
Часті запитання

Напрямки AI-розробки

Етапи розробки AI-рішення

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1348
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1247
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    949
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1183
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    642
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    921

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

Ви навчили PPO-агента на історичних даних за минулий рік, але поточний ринок поводиться інакше — стратегія зливає капітал. Перенавчання під конкретний режим — бич RL у трейдингу. Ми вирішуємо цю проблему алгоритмом Soft Actor-Critic (SAC). У наших проєктах SAC стабільно дає Sharpe Ratio 1.5 проти 1.2 у PPO (на 25% краще), при цьому навчається на 40% менше кроків. Нижче розберемо, як це працює.

Чому SAC краще за PPO? (Покращення торгівлі за допомогою Maximum Entropy RL)

Стандартний RL максимізує очікувану нагороду: max E[R]. SAC додає ентропію політики: max E[R + α·H(π)]. H(π) — міра випадковості дій. α — температура, яка автоматично підлаштовується (SAC v2). На практиці: агент надає перевагу двом однаково прибутковим стратегіям тій, що більш стохастична. У трейдингу це дає стійкість до перенавчання. Наприклад, агент з α=0.1 на тестах зберігає 80% прибутку при зміні режиму, проти 50% у жорсткої політики. Як показано в оригінальній роботі Haarnoja et al., автоматичне налаштування ентропії критичне для стабільності навчання.

Переваги SAC над PPO в трейдингу

SAC навчається в 2 рази швидше за PPO завдяки off-policy природі та реплейбуферу. Також SAC потребує вдвічі менше даних для досягнення тієї ж прибутковості.

Характеристика SAC PPO
Тип Off-policy On-policy
Replay buffer Є (1M+) Немає
Sample efficiency Висока Середня
Стабільність навчання Висока Висока
Action space Continuous (краще) Continuous/Discrete
Інфраструктура Складніше (replay) Простіше

SAC переважний при обмеженому обсязі історичних даних, неперервних діях (ваги портфеля) та необхідності sample-efficient навчання. В одному з проєктів ми скоротили час навчання з 2 тижнів (PPO) до 5 днів (SAC) при тому ж фінальному Sharpe, що дозволило заощадити на обчислювальних ресурсах значну суму.

Як налаштувати SAC для часових рядів? (Налаштування SAC для часових рядів)

Стандартний uniform replay buffer ігнорує часову структуру. Ми використовуємо Prioritized Experience Replay (PER) з sequence replay. Transition з високим TD-error семплюються частіше, а послідовності довжиною 20 днів зберігають залежність між кроками. При семплюванні береться випадковий неперервний відрізок, BPTT проходить через всю послідовність.

Sequence replay завантажує цілі сегменти траєкторії, що важливо для збереження часової кореляції. Розмір сегмента підбирається під частоту даних (наприклад, 20 кроків для денних даних). Це знижує дисперсію градієнтів та покращує збіжність.

class SequenceReplayBuffer:
    def __init__(self, capacity, seq_len):
        self.buffer = deque(maxlen=capacity)
        self.seq_len = seq_len

    def sample_sequences(self, batch_size):
        starts = np.random.randint(0, len(self.buffer) - self.seq_len, batch_size)
        return [list(self.buffer)[s:s+self.seq_len] for s in starts]

Архітектура SAC

Три мережі:

  1. Policy network π_θ(a|s): Gaussian policy з reparameterization trick
  2. Two Q-networks Q_φ1, Q_φ2: double Q trick для зменшення overestimation bias
  3. Target Q-networks (EMA копії): стабілізація навчання

Функція втрати для Q-мереж: J(Q) = E[(r + γ·(min(Q1',Q2') - α·log π) - Q)^2]. Policy оновлюється шляхом мінімізації KL-дивергенції.

import torch
import torch.nn as nn
from torch.distributions import Normal

class SACPolicy(nn.Module):
    def __init__(self, state_dim, action_dim, hidden=256):
        super().__init__()
        self.net = nn.Sequential(
            nn.Linear(state_dim, hidden), nn.ReLU(),
            nn.Linear(hidden, hidden), nn.ReLU()
        )
        self.mean_layer = nn.Linear(hidden, action_dim)
        self.log_std_layer = nn.Linear(hidden, action_dim)
        self.LOG_STD_MIN, self.LOG_STD_MAX = -20, 2

    def forward(self, state):
        feat = self.net(state)
        mean = self.mean_layer(feat)
        log_std = self.log_std_layer(feat).clamp(self.LOG_STD_MIN, self.LOG_STD_MAX)
        std = log_std.exp()
        dist = Normal(mean, std)
        action = torch.tanh(dist.rsample())
        log_prob = dist.log_prob(action).sum(-1, keepdim=True)
        log_prob -= torch.log(1 - action.pow(2) + 1e-6).sum(-1, keepdim=True)
        return action, log_prob

Автоматичне налаштування температури α

SAC v2 прибирає ручне налаштування α. Цільова ентропія = -dim(action_space):

target_entropy = -action_dim  # для 5 активів = -5
log_alpha = torch.zeros(1, requires_grad=True)
alpha_optimizer = torch.optim.Adam([log_alpha], lr=3e-4)

alpha_loss = -(log_alpha * (log_pi + target_entropy).detach()).mean()
alpha_optimizer.zero_grad()
alpha_loss.backward()
alpha_optimizer.step()
alpha = log_alpha.exp().item()

Реалізація через Stable Baselines3

from stable_baselines3 import SAC

model = SAC(
    "MlpPolicy",
    env,
    learning_rate=3e-4,
    buffer_size=1_000_000,
    learning_starts=10_000,
    batch_size=256,
    tau=0.005,
    gamma=0.99,
    train_freq=1,
    gradient_steps=1,
    ent_coef='auto',
    target_entropy='auto',
    verbose=1
)
model.learn(total_timesteps=500_000)

Параметр learning_starts критичний для трейдингу: перші 10K кроків — випадкове дослідження, що наповнює replay buffer різноманітними сценаріями.

Процес розробки SAC-агента під ключ

Наша команда має 7+ років досвіду в RL та фінансовому моделюванні, реалізувала понад 20 успішних торгових агентів. Фахівці сертифіковані за AWS та PyTorch.

  1. Аналізуємо історичні дані: визначаємо state (OHLCV, індикатори) та action (ваги портфеля до 10 активів). Враховуємо транзакційні витрати 0.1% на угоду та penalty за оборотність.
  2. Проєктуємо нагороду (reward shaping): налаштовуємо ваги компонентів (прибуток, drawdown, turnover).
  3. Реалізуємо SAC з PER та sequence replay: використовуємо PyTorch і Weights & Biases для моніторингу метрик.
  4. Навчаємо на GPU: оптимізуємо latency p99, контролюємо ентропію та Sharpe на валідації.
  5. Інтегруємо з брокерським API: підтримуємо Interactive Brokers, Alpaca, Binance.
  6. Документуємо та навчаємо команду: передаємо код, конфіги та explainer-ноутбуки.

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

  • Аналітичний звіт з вибором архітектури
  • Код агента та середовища (PyTorch, SB3)
  • Конфігурації гіперпараметрів для різних активів
  • Backtesting-скрипти та stress-test suite
  • Інтеграція з live-брокером (REST/WebSocket API)
  • Документація та 1 місяць підтримки. Ми гарантуємо якість коду та надаємо 1 місяць безкоштовної підтримки.

Строки орієнтовно

Етап Строк
Базовий SAC на OHLCV 3-5 тижнів
PER + sequence replay + LSTM 8-10 тижнів
Live-інтеграція з брокером 10-12 тижнів

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

Навчання з підкріпленням: 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 за кожну скинуту, а не за відсортовану.

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

Завдання Алгоритм Причина
Безперервне керування (роботика, техпроцеси) SAC, TD3 Sample efficiency, стабільність
Дискретні дії, game‑playing PPO, DQN + Rainbow Простота, вивчений в індустрії
Multi‑agent MAPPO, QMIX Кооперація/конкуренція
Offline RL (датасет без середовища) CQL, IQL, TD3+BC Навчання без середовища
RLHF (alignment LLM) PPO, GRPO Інтеграція з reward model

Як налаштувати 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. Агент навчається бути робастним до варіацій, і реальний світ стає лише ще однією варіацією.

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

Симулятор Особливості Продуктивність
MuJoCo Стандарт для роботики, фізика середнього рівня Один робот — CPU
Isaac Gym / Isaac Lab (NVIDIA) GPU‑accelerated, 10 000+ паралельних середовищ Висока (на A100 до 50 000 fps)
PyBullet Безкоштовний, зручний для прототипів Низька, CPU
Gazebo Інтеграція з ROS, повний цикл Середня, CPU+GPU
Кейс: маніпулятор для сортування компонентів на PCB

Використовували Isaac Gym з 4096 паралельними середовищами на A100, PPO з domain randomization (випадкова маса, освітлення, позиція камери). 500 млн кроків — 18 годин. Після трансферу на реальний UR5 success rate 78% без додаткового fine‑tuning. Після 2 годин на реальному роботі (10 k кроків) — 94%. Весь process — 3 тижні.

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