Створення торгового агента з використанням DQN

Проектуємо та впроваджуємо системи штучного інтелекту: від прототипу до production-ready рішення. Наша команда поєднує експертизу в машинному навчанні, дата-інжинірингу та MLOps, щоб AI працював не в лабораторії, а в реальному бізнесі.

Напрямки 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

Створення торгового агента з використанням DQN

Торговий агент на DQN (Deep Q-Network)

Дискретна торгівля — класична задача для RL. Але DQN у сирому вигляді дає збої: overestimation bias, нестабільність, шум фінансових даних. Ми проектуємо та розробляємо RL-агентів на базі DQN/DDQN під конкретний інструмент з урахуванням усіх нюансів. Наш досвід — 5+ років у RL для фінансів, понад 20 впроваджених проектів. Гарантуємо стабільність навчання та валідацію на out-of-sample даних.

Deep Q-Network — перший deep RL алгоритм, що продемонстрував superhuman performance в іграх Atari. Для трейдингу: дискретний простір дій (buy/sell/hold), experience replay, target network. Підходить для single-asset торгівлі з чіткими входами/виходами.

Як DQN справляється з шумом фінансових даних?

Фінансові ряди зашумлені та нестаціонарні. DQN не вимагає моделі ринку, але страждає від high variance. Рішення: Double DQN (знижує overestimation bias на 50% порівняно з DQN), Dueling DQN (розділяє value і advantage), повільний epsilon decay (decay_factor=0.9995, epsilon_min=0.01). Ми використовуємо ці техніки, щоб агент не переучувався на шумі.

Що таке Rainbow DQN і навіщо він у трейдингу?

Rainbow DQN — комбінація шести покращень: Double, Dueling, Prioritized Experience Replay (PER), Multi-step returns (n=3), Distributional RL (C51/QR-DQN), Noisy Networks. Для трейдингу найцінніші: distributional дає risk-aware policy (бачить не тільки середню дохідність, але й волатильність), multi-step прискорює кредитне присвоєння, PER фокусується на рідкісних, але значущих рухах (наприклад, gap-відкриття).

DQN для трейдингу

Оригінальний DQN працює з дискретними діями. Це робить його природним для сигнальних стратегій:

Action space:

  • 0: Hold (нічого не робити)
  • 1: Buy (відкрити довгу позицію)
  • 2: Sell / Close (закрити позицію / відкрити шорт)

Для single-asset це розумно. Для multi-asset потрібен DQN з factored action space або перехід на SAC/PPO.

Q-функція оцінює очікувану сумарну дисконтовану винагороду зі стану s при дії a.

Алгоритм Тип дій Переучування Стабільність Коли використовувати
DQN/DDQN Дискретні (3-10) Ризик high variance Середня (потрібне налаштування) Single-asset, чіткі сигнали
SAC/PPO Неперервні Нижче Висока Multi-asset, continuous position sizing

Архітектура

import torch
import torch.nn as nn

class DQNTrading(nn.Module):
    def __init__(self, state_dim, n_actions=3, hidden=256):
        super().__init__()
        # Dueling DQN архітектура
        self.feature = nn.Sequential(
            nn.Linear(state_dim, hidden), nn.ReLU(),
            nn.Linear(hidden, hidden), nn.ReLU()
        )
        # Value stream: V(s)
        self.value = nn.Sequential(
            nn.Linear(hidden, 128), nn.ReLU(),
            nn.Linear(128, 1)
        )
        # Advantage stream: A(s, a)
        self.advantage = nn.Sequential(
            nn.Linear(hidden, 128), nn.ReLU(),
            nn.Linear(128, n_actions)
        )

    def forward(self, x):
        feat = self.feature(x)
        V = self.value(feat)
        A = self.advantage(feat)
        # Q = V + (A - mean(A))
        return V + (A - A.mean(dim=1, keepdim=True))

Dueling DQN розділяє V(s) і A(s,a). У трейдингу: часто стан ринку визначає загальну цінність (V), а вибір дії — відносну перевагу (A). Зазвичай швидше сходиться.

Experience Replay і Target Network

Два ключові механізми:

Experience replay buffer:

from collections import deque
import random

class ReplayBuffer:
    def __init__(self, capacity=100_000):
        self.buffer = deque(maxlen=capacity)

    def push(self, state, action, reward, next_state, done):
        self.buffer.append((state, action, reward, next_state, done))

    def sample(self, batch_size):
        batch = random.sample(self.buffer, batch_size)
        states, actions, rewards, next_states, dones = zip(*batch)
        return (torch.FloatTensor(np.array(states)),
                torch.LongTensor(actions),
                torch.FloatTensor(rewards),
                torch.FloatTensor(np.array(next_states)),
                torch.FloatTensor(dones))

Target network (заморожена копія Q-мережі):

# оновлення кожні C кроків
if step % target_update_freq == 0:
    target_net.load_state_dict(online_net.state_dict())

Без target network: Q-targets рухаються одночасно з Q-predictions → нестабільність → divergence.

Навчання з Double DQN

def train_step(batch, online_net, target_net, optimizer, gamma=0.99):
    states, actions, rewards, next_states, dones = batch

    # поточні Q-значення
    q_values = online_net(states).gather(1, actions.unsqueeze(1))

    # Double DQN: online обирає дію, target оцінює
    with torch.no_grad():
        next_actions = online_net(next_states).argmax(1)
        next_q = target_net(next_states).gather(1, next_actions.unsqueeze(1))
        target_q = rewards.unsqueeze(1) + gamma * next_q * (1 - dones.unsqueeze(1))

    loss = nn.SmoothL1Loss()(q_values, target_q)  # Huber loss (стійкий до викидів)
    optimizer.zero_grad()
    loss.backward()
    nn.utils.clip_grad_norm_(online_net.parameters(), 10)  # градієнтний кліпінг
    optimizer.step()
    return loss.item()

Double DQN усуває overestimation bias оригінального DQN. У фінансових середовищах з високим шумом це критично — без Double DQN Q-значення систематично завищені.

Epsilon-greedy для фінансових середовищ

# Експоненційний decay epsilon
epsilon = max(epsilon_min, epsilon_start * (epsilon_decay ** step))

if np.random.random() < epsilon:
    action = env.action_space.sample()  # випадкове дослідження
else:
    with torch.no_grad():
        q_vals = online_net(state_tensor)
        action = q_vals.argmax().item()

Фінансова специфіка epsilon:

  • epsilon_start = 1.0 (повне дослідження на початку)
  • epsilon_min = 0.01 (1% випадкових дій завжди)
  • Повільний decay (decay=0.9995) — ринок складніший за Atari

Коли DQN, коли SAC/PPO

DQN доречний для: single-asset, чіткі сигнали buy/sell, невеликий action space (3–10 дій), binary decision making. SAC/PPO переважніші для: multi-asset portfolio, continuous position sizing, коли розмір позиції важливий.

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

  • Архітектура агента (Dueling DQN, Double DQN, Rainbow).
  • Скрипти навчання та бектестингу на PyTorch.
  • Конфігурація гіперпараметрів під ваш інструмент (learning rate, batch size, replay buffer size, target update frequency).
  • Модель карда (model card) з метриками (Sharpe, Max Drawdown, Win Rate, P99 latency).
  • Документація з відтворення.
  • Інтеграція з live trading (опціонально, +3-4 тижні).
  • Підтримка 2 місяці після деплою.

Терміни та вартість

Базовий DQN агент — від 2 до 3 тижнів, вартість стартує від 2500$. Rainbow з PER, Distributional, multi-step — від 6 до 8 тижнів, від 6000$. Live trading інтеграція з риск-менеджментом — додатково від 3 до 4 тижнів, від 3000$. Вартість розраховується індивідуально після аналізу даних.

Чому варто замовити розробку у нас?

Ми впровадили RL-агентів для 20+ проектів у фінансах. Використовуємо production-ready стек: PyTorch, Ray, Weights & Biases, MLflow. Гарантуємо відтворюваність експериментів (seed, конфіги в YAML) та валідацію на out-of-sample даних. Напишіть нам — обговоримо ваш кейс та підготуємо комерційну пропозицію.

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