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

Переоцінка Q-функції — системна помилка DDPG, яка ламає навчання в трейдингових задачах. Алгоритм TD3 (Twin Delayed Deep Deterministic Policy Gradient, запропонований Scott Fujimoto в роботі Addressing Function Approximation Error in Actor-Critic Methods Addressing Function Approximation Error in Actor-Critic Methods) вирішує цю проблему трьома механізмами: twin critics, delayed policy updates і target smoothing. Ми застосовуємо TD3 для побудови торгових агентів із безперервним position sizing, забезпечуючи стабільне навчання та відтворювані результати на реальних ринках.

В одному з проєктів перехід з DDPG на TD3 підняв Sharpe ratio з 0.8 до 1.6 на 15-хвилинних свічках ф'ючерсів S&P 500. Ключовим фактором стало пригнічення overestimation bias, яке в DDPG призводило до переторговки та частого потрапляння в drawdown.

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

Overestimation bias. Стандартний DDPG завищує value-оцінки, і policy оптимізується під нереалістичні цілі. TD3 використовує двох критиків з target = min(Q₁, Q₂), що дає консервативну апроксимацію.

Нестабільне навчання. Швидке оновлення policy відносно criticів призводить до oscillation. TD3 оновлює actor кожні d кроків (d=2), дозволяючи Q-функціям стабілізуватися.

Гіперактивна торгівля. Без регуляризації агент здійснює надлишкові угоди. Додавання target policy smoothing з Gaussian noise (σ=0.2) і штраф за транзакційні витрати (0.1% на угоду) вирішують проблему.

Як TD3 вирішує проблему переоцінки?

Два незалежні критики Q₁ та Q₂ працюють як взаємна перевірка. Target value:

y = r + γ · min(Q₁_target(s', π(s')), Q₂_target(s', π(s')))

Така оцінка систематично нижча за true value, але не завищує. На практиці це знижує variance оновлень і покращує підсумкову дохідність.

Коли TD3 виграє у SAC?

TD3 — детермінована policy, SAC — стохастична. TD3 дає відтворювані сигнали, що критично для live-торгівлі. SAC кращий при високій невизначеності, але для трендових ринків TD3 показує більш стабільний Sharpe.

Архітектура для трейдингу

class TD3Actor(nn.Module):
    def __init__(self, state_dim, action_dim, max_action):
        super().__init__()
        self.net = nn.Sequential(
            nn.Linear(state_dim, 256), nn.ReLU(),
            nn.Linear(256, 256), nn.ReLU(),
            nn.Linear(256, action_dim), nn.Tanh()
        )
        self.max_action = max_action

    def forward(self, state):
        return self.net(state) * self.max_action

class TD3Critic(nn.Module):
    def __init__(self, state_dim, action_dim):
        super().__init__()
        # Q1
        self.q1 = nn.Sequential(
            nn.Linear(state_dim + action_dim, 256), nn.ReLU(),
            nn.Linear(256, 256), nn.ReLU(),
            nn.Linear(256, 1)
        )
        # Q2
        self.q2 = nn.Sequential(
            nn.Linear(state_dim + action_dim, 256), nn.ReLU(),
            nn.Linear(256, 256), nn.ReLU(),
            nn.Linear(256, 1)
        )

    def forward(self, state, action):
        sa = torch.cat([state, action], dim=1)
        return self.q1(sa), self.q2(sa)

    def q1_forward(self, state, action):
        sa = torch.cat([state, action], dim=1)
        return self.q1(sa)

Continuous position sizing і reward

Action space: [-1, 1] для кожного активу, з бюджетним обмеженням Σ|wᵢ| ≤ 1. Reward включає Sharpe-подібну метрику та штраф за зміни позицій:

def reward_fn(returns_series):
    if len(returns_series) < 20:
        return returns_series[-1]
    mean_r = np.mean(returns_series[-20:])
    std_r = np.std(returns_series[-20:]) + 1e-8
    sharpe = mean_r / std_r
    return sharpe * returns_series[-1]

position_change = np.abs(new_position - old_position)
transaction_cost = position_change * 0.001
reward -= transaction_cost

Важливо: додавання штрафу за транзакції (0.1% на угоду) суттєво знижує кількість угод і покращує чисту дохідність. В одному проєкті це скоротило частоту торгів на 40% при збереженні загального прибутку.

Які гіперпараметри задавати?

Для multi-asset сценаріїв action space нормується так, щоб сума абсолютних ваг не перевищувала 1. Це легко реалізувати через softmax-подібне перетворення або проекцію на симплекс.

Чому варто обрати TD3 для вашого трейдинг-проєкту?

TD3 забезпечує детермінованість дій при одному і тому ж state, що критично для бектестування та live-торгівлі. Ви отримуєте відтворювану стратегію, яку можна протестувати на історичних даних без стохастичних флуктуацій. Крім того, механізм target smoothing робить агента стійким до шуму ринкових даних.

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

• Повна реалізація TD3-агента (actor/critic мережі, буфер, навчання)
• Пайплайн збору даних та симуляційне середовище
• Підбір гіперпараметрів та крос-валідація
• Інтеграція з брокерським API (Interactive Brokers, Alpaca, ваш)
• Документація з відтворення та модифікації
• Навчання команди (1 сесія) та гарантійна підтримка 3 місяці

Процес розробки під ключ

1. Аналіз — історичні дані, метрики, бенчмарки
2. Проєктування — state/action/reward, симуляційне середовище
3. Навчання — підбір гіперпараметрів, decay exploration, моніторинг
4. Тестування — out-of-sample backtest, stress-test на кризових періодах
5. Деплой — інтеграція з брокерським API, налаштування моніторингу та алертів

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

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