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

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

Светофоры с фиксированным циклом — причина 30% задержек в городском трафике. Каждый день миллионы водителей теряют часы в пробках, а города несут экономические потери. Мы разрабатываем адаптивные системы на основе многоагентного RL (MARL), которые снижают среднее время ожидания на 15-30%. Например, в Ханчжоу внедрение такой системы сократило заторы на 22%, а в Саудовской Аравии — на 18%. Наш подход использует MARL: каждый перекрёсток — агент с локальным наблюдением, который оптимизирует фазы в реальном времени. Экономия для города с населением 500 тыс. человек может составить до 10 млн рублей в год за счёт снижения расхода топлива и времени в пути. Получите консультацию по вашему проекту — оценим за 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 млн шагов — это часы. На роботизированных задачах с реальной физикой — дни или недели в симуляторе.

Выбор алгоритма под задачу:

Как настроить 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 по сходимости: требуется меньше взаимодействий для того же качества. Ключевой параметр — 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, наряду с неправильно выбранной архитектурой среды.» — Wikipedia: Reward hacking

Что входит в работу

• Архитектурное решение и обоснование выбора алгоритма
• Разработка и документирование 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 дня. Свяжитесь с нами для консультации.

Наша команда — 5+ лет опыта в RL, 30+ успешных проектов в роботике, оптимизации цепочек поставок и LLM alignment. Гарантируем прозрачную архитектуру и полную техническую документацию. Закажите разработку системы RL — мы поможем обойти типовые ловушки и получить работающую систему в сжатые сроки.