Розробка AI-системи управління трафіком та оптимізація світлофорів

Розробка AI-системи управління трафіком та оптимізація світлофорів

Світлофори з фіксованим циклом — причина 30% затримок у міському трафіку. Щодня мільйони водіїв втрачають години в заторах, а міста зазнають економічних втрат. Ми розробляємо адаптивні системи на основі багатоагентного RL (MARL), які знижують середній час очікування на 15-30%. Наприклад, у Ханчжоу впровадження такої системи скоротило затори на 22%, а в Саудівській Аравії — на 18%. Наш підхід використовує MARL: кожне перехрестя — агент з локальним спостереженням, який оптимізує фази в реальному часі. Отримайте консультацію щодо вашого проєкту — оцінимо за 2 дні.

Чому RL і MARL — найкращий підхід для управління світлофорами?

Фіксовані цикли працюють добре при передбачуваному потоці, але в реальності трафік непередбачуваний. Адаптивні системи (SCOOT, SCATS) вимагають ручного калібрування і погано справляються з аномаліями. RL-агент оптимізує фази безпосередньо під поточний трафік без ручного налаштування і адаптується до ДТП, дощів, заходів. Навчання відбувається в симуляторі, потім переноситься на реальні контролери. За нашими тестами, MARL на 20-30% ефективніший за SCOOT за середнім часом у дорозі.

Задача: N перехресть, у кожного K фаз (напрямків). Агент вибирає поточну фазу і тривалість → мінімізація сумарного часу очікування.

Середовище симуляції та навчання

CityFlow — середовище симуляції

import cityflow

# конфігурація міста з JSON (дороги, перехрестя, трафік)
eng = cityflow.Engine('config.json', thread_num=4)

# стан перехрестя
lane_vehicles = eng.get_lane_vehicle_count()  # машин у кожній смузі
lane_waiting = eng.get_lane_waiting_vehicle_count()
current_phase = eng.get_current_phase(intersection_id)

# дія: змінити фазу
eng.set_tl_phase(intersection_id, new_phase)
eng.next_step()

Для детальної мікросимуляції використовуємо також SUMO — він точніше моделює поведінку окремих автомобілів.

Gym-сумісне середовище

class TrafficEnv(gym.Env):
    def __init__(self, n_intersections, config_path):
        self.n = n_intersections
        self.eng = cityflow.Engine(config_path)

        # observation per intersection: vehicle counts + waiting + phase
        obs_dim = 12 + 12 + 8  # 12 під'їзних смуг, 8 фаз
        self.observation_space = spaces.Box(
            low=0, high=100, shape=(n_intersections, obs_dim))

        # action: вибір фази для кожного перехрестя
        self.action_space = spaces.MultiDiscrete([8] * n_intersections)

    def step(self, actions):
        for i, action in enumerate(actions):
            self.eng.set_tl_phase(f'intersection_{i}', int(action))

        # кілька кроків симуляції на одне рішення агента
        for _ in range(self.control_interval):  # 10–30 сек
            self.eng.next_step()

        obs = self._get_obs()
        reward = -self.eng.get_average_travel_time()  # мінімізуємо ATT
        return obs, reward, False, False, {}

Побудова MARL-системи

Алгоритми кооперації

Independent DQN (InDQN) — простий baseline: кожне перехрестя навчається незалежно, інші агенти — частина середовища. CoLight використовує attention для врахування сусідніх перехресть:

class CoLightAttention(nn.Module):
    def forward(self, own_obs, neighbor_obs):
        # own_obs: [batch, obs_dim]
        # neighbor_obs: [batch, n_neighbors, obs_dim]
        query = self.q_proj(own_obs).unsqueeze(1)
        keys = self.k_proj(neighbor_obs)
        values = self.v_proj(neighbor_obs)

        attention = F.softmax(
            torch.bmm(query, keys.transpose(1,2)) / math.sqrt(self.d_k), dim=-1
        )
        context = torch.bmm(attention, values).squeeze(1)
        return self.output_proj(torch.cat([own_obs, context], dim=-1))

MPLight поєднує pressure-based feature engineering (queue pressure) з MARL, показуючи найкращі результати на CityFlow benchmarks.

Вибір винагороди

Pressure-based reward дає найкращі результати в багатоагентному середовищі.

Інтеграція з реальними контролерами

Більшість міст використовують SCATS (Австралія) або SCOOT (Великобританія). Наше RL-рішення формує сигнали у форматі цих систем через NTCIP протокол (національний стандарт ITS). Для сумісності реалізовано адаптер SNMP. При відмові RL (мережевий збій) — автоматичний перехід на actuated control з детекторами транспорту. NTCIP 1202 v03 — ключовий стандарт для взаємодії.

Які дані потрібні?

Джерела даних: відеодетектори (черги в реальному часі), індуктивні петлі (точний підрахунок), GPS-флот (travel time feedback), Connected Vehicles (V2X/C-V2X) для проактивної оптимізації. MLOps-пайплайн автоматично оновлює модель за новими даними. Для навчання достатньо 1-3 місяців записів з детекторів. Якщо доступні дані V2X, точність підвищується на 10-15%.

Які KPI відстежуються?

Зв'яжіться для персоналізованої оцінки ваших KPI.

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

1. Аналітика: збір даних про трафік, калібрування симулятора. Складаємо digital twin району. Налаштовуємо предиктивну модель.
2. Проектування: вибір топології агентів (Independent / CoLight / MPLight), дизайн винагороди.
3. Реалізація: навчання в CityFlow (1000+ епізодів), тестування на реальних сценаріях.
4. Тест: A/B тестування на виділеному перехресті, верифікація KPI.
5. Деплой: інтеграція з NTCIP-контролерами, fallback-режими, моніторинг через MLOps.

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

• Модель MARL з підтримкою CoLight/MPLight
• Симулятор CityFlow з конфігом під ваш район
• Reward engineering під ваші KPI
• Адаптер для NTCIP (SCATS/SCOOT)
• Документація, навчання операторів, підтримка 3 місяці

Скільки часу займає впровадження?

Одне перехрестя в симуляції — 4 тижні. Район (20-50 перехресть) з координованими агентами — 12 тижнів. Повне впровадження з міською інфраструктурою — 20-24 тижні.

Готові оцінити ваш проєкт за 2 дні. Зв'яжіться для консультації — наші інженери мають досвід реалізації в містах з населенням 5+ млн осіб і гарантують зниження заторів.

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