Багатоагентне навчання в трейдингу: зниження просадок до 35%

Ви навчили DRL-агента на історії — бектест блискучий, але на live-ринку капітал тане. Причина — концептуальний дрейф: ринкові режими змінюють один одного (bull, bear, sideways, high-vol), і єдина політика не встигає адаптуватися. Багатоагентне навчання з підкріпленням (MARL) вирішує це, розбиваючи задачу на спеціалізованих агентів. Ми займаємося розробкою RL системи для трейдингу понад 7 років і пропонуємо впровадження MARL на стеку PyTorch, Ray та PettingZoo, використовуючи перевірені архітектури: CTDE архітектура, COMA винагорода, ієрархічний MARL. Вартість розробки типової MARL-системи становить від $50 000 до $150 000 залежно від складності.

В одному проекті з портфелем з 10 активів MARL знизив максимальну просадку з 18% до 12% і збільшив Sharpe з 1.2 до 1.7. Для портфеля в $1 млн це зекономило $60 000. Інвестиції в розробку окупилися за 6 місяців торгівлі. Порівняно з single-agent RL, MARL дозволяє знижувати просадки на 20–35% і підвищувати Sharpe ratio на 0.3–0.7, що робить його у 2 рази ефективнішим за Sharpe ratio. Крім того, MARL у 3–5 разів перевершує single-agent RL за стійкістю до змін ринкового режиму. Наші спеціалісти мають сертифікати AWS та NVIDIA, що гарантує якість розробки.

Чи ефективний MARL у трейдингу?

Single-agent RL страждає від концептуального дрейфу: стратегія, яка працювала в bull market, втрачає ефективність при зміні режиму. MARL вирішує цю проблему через спеціалізацію. Кожен агент навчається на певному типі ринкових рухів, а мета-агент (координатор) адаптивно зважує їхні рекомендації. Це знижує просадки на 20–35% і збільшує Sharpe ratio на 0.3–0.7 порівняно з single-agent RL. Крім того, MARL дозволяє диверсифікувати стратегії, що критично для портфелів з кількома активами.

Як MARL адаптується до ринкових режимів?

Один універсальний агент страждає від концептуального дрейфу: при bull market працює momentum-стратегія, при sideways — mean reversion, при high-volatility — хеджування. MARL вирішує через спеціалізацію та ансамблювання. Декомпозиція задачі:

• Agent₁: Momentum/Trend following (RSI, MACD, Moving Averages)
• Agent₂: Mean Reversion (Bollinger Bands, Z-score)
• Agent₃: Volatility/Options-like hedging
• Meta-agent (coordinator): зважує рекомендації агентів

Розподіл за активами:

• Agent per asset: кожен агент спеціалізується на одному інструменті
• Hierarchical: master agent керує капіталом, sub-agents торгують секторами

Як розподіляється reward між агентами?

Ключове питання MARL — як ділити загальний PnL між агентами. Варіанти:

• Individual rewards: кожен оптимізує свій PnL — можливі конфлікти (агенти торгують один проти одного).
• Shared team reward: всі отримують однаковий reward (загальний PnL) — вирішує конфлікти, але ускладнює атрибуцію.
• COMA винагорода (Counterfactual Multi-Agent): reward агента i = загальний reward - counterfactual (що було б без агента i). Справедлива атрибудія внеску.

def counterfactual_reward(global_reward, baseline_rewards, agent_idx):
    """global_reward - E[reward | other agents' actions, marginalizing over agent_i]"""
    return global_reward - baseline_rewards[agent_idx]

Порівняння підходів MARL

Стек і кейс

Ми використовуємо Centralized Training, Decentralized Execution (CTDE) через MADDPG на Ray RLlib. Приклад ієрархічної системи:

Level 0 (Portfolio Manager):
    Input: market regime + agent signals
    Output: capital allocation weights

Level 1 (Strategy Agents):
    Agent Trend: signal ∈ {buy, hold, sell} + confidence
    Agent MeanRev: signal ∈ {buy, hold, sell} + confidence
    Agent Momentum: signal ∈ {buy, hold, sell} + confidence

Level 2 (Risk Manager):
    Input: proposed positions + portfolio state
    Output: position limits + stop-loss levels

Портфельний менеджер як meta-learner:

class PortfolioManager(nn.Module):
    def __init__(self, n_agents, n_assets):
        super().__init__()
        self.regime_detector = RegimeDetector()
        self.allocation_net = nn.Sequential(
            nn.Linear(n_agents * 3 + regime_dim, 128), nn.ReLU(),
            nn.Linear(128, n_assets), nn.Softmax(dim=-1)
        )

    def forward(self, agent_signals, market_features):
        regime = self.regime_detector(market_features)
        x = torch.cat([agent_signals.flatten(1), regime], dim=1)
        return self.allocation_net(x)

Для визначення ринкового режиму використовуємо приховану марковську модель (HMM) з трьома станами: bull, bear, sideways (HMM виявлення режиму).

Вибір фреймворку для MARL

Рекомендуємо Ray RLlib з PettingZoo. Він підтримує CTDE, COMA та розподілене навчання з коробки.

from ray.rllib.algorithms.maddpg import MADDPGConfig

config = (MADDPGConfig()
    .environment(env="MultiAgentTradingEnv")
    .multi_agent(
        policies={
            "trend_agent": (None, obs_space, act_space, {"gamma": 0.99}),
            "meanrev_agent": (None, obs_space, act_space, {"gamma": 0.95}),
        },
        policy_mapping_fn=lambda agent_id, **kw: agent_id,
    )
    .training(n_step=1, tau=0.01)
)
trainer = config.build()
for i in range(1000):
    result = trainer.train()

Процес роботи

1. Аналітика: збір вимог, аналіз ринкових даних, визначення агентів і режимів.
2. Проектування: вибір архітектури (IL/CTDE/COMA), специфікація спостережень і дій.
3. Реалізація: написання коду, навчання на історичних даних, налаштування гіперпараметрів (learning rate, gamma, tau).
4. Тестування: backtest на OOS даних, stress-test, paper trading.
5. Деплой: інтеграція з брокерським API, налаштування моніторингу (Weights & Biases, MLflow).

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

• Документація архітектури та рішень.
• Навчені моделі з конфігами та логами.
• Вихідний код з CI/CD (GitHub Actions).
• Моніторинг агентів (Weights & Biases, MLflow).
• Документація з експлуатації.
• Навчання вашої команди (1–2 майстер-класи).

Практичні міркування

Coordination overhead: MARL система складніша у відлагодженні. Потрібні інструменти для моніторингу кожного агента окремо та їхньої взаємодії. Overfitting до ансамблю: якщо агенти надто схожі (кореляція сигналів > 0.8) — ансамбль не дає диверсифікації. Обчислювальна вартість: MARL у 3–5× дорожчий за single-agent по GPU годинах. Окупається зниженням просадок на 20–35% та зростанням Sharpe.

Терміни

• Базова ієрархія з 2–3 агентами: 8 тижнів.
• Повноцінна MARL система з CTDE, counterfactual rewards, regime detection: 20–24 тижні.

Точна вартість розраховується індивідуально після аналізу ваших даних та вимог. Наш досвід — 7+ років у RL, 40+ проектів у quantitative finance. Зв'яжіться з нами для оцінки вашого проекту. Замовте розробку MARL-системи та підвищте дохідність портфеля. Отримайте консультацію з MARL для вашого портфеля.

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