Налаштування торгового RL-агента в OpenAI Gym / Gymnasium

При навчанні торгового RL-агента на реальних котируваннях часто виникають підводні камені: комісії, прослизання, обмеження на шорти. Стандартні середовища на кшталт gym-anytrading їх ігнорують, і агент показує відмінні результати на симуляції, але провалюється на live-ринку. Ми накопичили досвід у 20+ проектах з налаштування торгових агентів і знаємо, як цього уникнути. Розберемо, як налаштувати кастомне середовище Gymnasium (форк OpenAI Gym), яке враховує всі витрати, та навчити першого агента за 1–2 дні. Середня економія на комісіях при такому підході становить 15–25% від торгового обсягу, а підвищення дохідності — до 30% за рахунок урахування прослизання. Економія може бути значною при обсягах торгівлі від $100,000. Зв'яжіться з нами, щоб обговорити ваш проект.

Як налаштувати торгове середовище Gymnasium?

Установка

pip install gymnasium stable-baselines3
pip install gym-anytrading         # прості торгові середовища
pip install gymnasium-trading-env  # більш продвинуті

Швидкий старт з gym-anytrading

import gymnasium as gym
import gym_anytrading
from stable_baselines3 import A2C
import pandas as pd

# завантаження даних
df = pd.read_csv('AAPL.csv', index_col='Date', parse_dates=True)

# створення середовища
env = gym.make('stocks-v0',
               df=df,
               frame_bound=(50, len(df)),
               window_size=10)

# навчання
model = A2C('MlpPolicy', env, verbose=1)
model.learn(total_timesteps=100_000)

# тест
obs, info = env.reset()
done = False
while not done:
    action, _ = model.predict(obs)
    obs, reward, terminated, truncated, info = env.step(action)
    done = terminated or truncated

print(f"Profit: {info['total_profit']:.2%}")

Перед навчанням важливо попередньо обробити дані: нормалізувати ціни, видалити викиди та привести до єдиної частоти. Для цього використовуємо pandas та scikit-learn. Неправильна попередня обробка — часта причина перенавчання.

Як вибрати архітектуру винагороди?

Функція винагороди (reward shaping) визначає поведінку агента. Стандартний підхід — використовувати логарифмічну дохідність портфеля або різницю між поточною дохідністю та бенчмарком. Ми частіше застосовуємо композитну винагороду: сума логарифмічної дохідності та штрафу за просадку. Коефіцієнт штрафу підбираємо так, щоб Sharpe ratio на валідації був максимальним.

Чому кастомне середовище краще за готові?

Готові обгортки (gym-anytrading) не враховують комісії, відсоток за шорт та часткове виконання заявок. Для реальної торгівлі цього недостатньо. В одному з проектів клієнт використовував gym-anytrading для ф'ючерсів: на історії агент давав 20% річних, але на live рахунку пішов у мінус через ковзні спреди. Ми переписали середовище на gymnasium-trading-env з комісією 0.0015 та прослизанням 0.001. Після донавчання агент вийшов на 12% річних з Sharpe 1.8. Ось чому враховувати витрати варто з самого початку.

Порівняємо готові обгортки в таблиці:

gymnasium-trading-env краще підходить для продакшену: він у 3 рази детальніше моделює витрати.

Приклад продвинутого середовища

from gymnasium_trading_env.environments import TradingEnv

env = TradingEnv(
    df=df,
    positions=[-1, 0, 1],           # short / flat / long
    trading_fees=0.0015,             # 0.15% комісія
    borrow_interest_rate=0.0003,     # 0.03% в день для шортів
    portfolio_initial_value=10_000,
    windows=20,                       # lookback window
    verbose=1
)

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

Одна дохідність — поганий критерій. RL-модель може перенавчитися на історичних даних і провалитися на нових. Мінімальний чек-лист включає три метрики:

Також обов'язково тестувати на out-of-sample даних (які не брали участі в навчанні) та порівнювати з бенчмарком buy-and-hold.

Як уникнути перенавчання?

Перенавчання — бич торгових RL-агентів. Щоб його мінімізувати, використовуємо регуляризацію (entropy coefficient в PPO), додаємо шум до нагород на етапі навчання та ділимо датасет на три частини: train, validation, test. Тест не чіпаємо до фінальної оцінки. Застосовуємо early stopping по loss на validation. Як зазначено в документації Stable-Baselines3, регуляризація допомагає уникнути перенавчання. Наш досвід показує, що без цих кроків 70% моделей виявляються непридатними для live-торгівлі. Додатково використовуємо Walk-Forward cross-validation на часових рядах, щоб переконатися, що агент працює на різних режимах ринку. Гарантуємо, що кожен агент проходить таку перевірку.

Як зареєструвати кастомне середовище?

Якщо стандарт не підходить — реєструємо своє:

from gymnasium.envs.registration import register

register(
    id='MyTradingEnv-v1',
    entry_point='my_module:MyTradingEnv',
    max_episode_steps=252
)

env = gym.make('MyTradingEnv-v1', df=train_df)

Що входить у налаштування під ключ

1. Збір та попередня обробка даних (історія котирувань будь-якого тікера та таймфрейму).
2. Проектування винагородної функції — залежить від мети: максимізація прибутку, мінімізація просадки або ризик-скоригована дохідність.
3. Реалізація кастомного середовища на базі Gymnasium з урахуванням комісій, шортів, прослизання.
4. Навчання агента з підбором гіперпараметрів (A2C, PPO, DQN).
5. Тестування на out-of-sample періоді та розрахунок метрик (Sharpe, drawdown, Calmar).
6. Документація та код для самостійного запуску.

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

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

• Готові обгортки + перший агент: 1–2 дні.
• Кастомне середовище + бектест: 3–7 днів.
• Повний цикл під ключ: від 7 до 14 днів залежно від складності.

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