Навчання з підкріпленням: 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‑місячна підтримка після деплою
Процес роботи
- Аудит завдання — фіксуємо цілі, ресурси, обмеження.
- Reward engineering — формалізація бажаної поведінки, перевірка на reward hacking.
- Вибір середовища та алгоритму — baseline, перші прогони.
- Систематичний hyperparameter sweep — використовуємо Optuna.
- Навчання в симуляторі з domain randomization.
- Тестування на реальному обладнанні (за потреби).
- Деплой, моніторинг, підтримка.
Терміни: proof of concept — 2–4 тижні; production‑система з sim‑to‑real — 3–8 місяців; RLHF для LLM — 4–10 тижнів. Вартість розраховується індивідуально — оцінимо ваш проєкт за 2 дні. Замовте консультацію, щоб уникнути типових пасток RL.
Наша команда — понад п’ять років досвіду в RL, 30+ успішних проєктів у роботиці, оптимізації ланцюгів постачання та LLM alignment. Гарантуємо прозору архітектуру та повну технічну документацію. Зв'яжіться з нами для отримання детальної оцінки вашого проєкту.







