Разработка AI-системы автономного вождения Perception Planning Control

Почему автономное вождение ломается на редких сценариях

Длинный хвост редких сценариев — не экзотика, а повседневность: потерянный впереди груз, объезд по обочине, разметка под снегом, велосипедист, выныривающий из-за припаркованного фургона. Автономное вождение опирается на статистику обучающих данных, а такие ситуации в неё почти не попадают — и конвейер восприятия и планирования теряет устойчивость ровно на них.

Дальше начинаются отказы восприятия. Слияние данных сенсоров сшивает кадры камеры, облако точек и показания дальномеров в одну картину, и стоит разъехаться временным меткам или уйти калибровке — объект двоится. Мокрый асфальт, блик от низкого солнца, отражение в витрине дают помеху, которой на дороге физически нет.

Предсказание траекторий добавляет второй слой ошибки. Модель оценивает намерения соседей по потоку, и на редком сценарии разброс гипотез расходится так широко, что планировщик либо замирает в нерешительности, либо выбирает манёвр, который через секунду перестаёт быть безопасным.

Цена на дороге разная, и обе крайности плохи. Ложное срабатывание — резкое торможение на пустом участке, в которое сзади приезжает тот, кто не ждал. Пропущенный объект — контакт. Надёжность здесь определяет не среднее качество модели, а поведение на хвосте распределения.

Поэтому мы начинаем с реестра сценариев и метрик по каждому слою — от воспроизводимых проверок редких сцен до консервативной логики планирования; разбираем, как это закрывается на конкретном маршруте заказчика.

Измеримый эффект от модульной архитектуры восприятия

Монолитный контур показывает только итог: система поехала лучше или хуже, а какая часть это дала — неизвестно. Модульная архитектура снимает этот вопрос: у восприятия, планирования и управления свои метрики качества, поэтому правка видна в конкретном числе, а не в общем впечатлении от заезда.

Восприятие измеряем отдельно — полнота обнаружения, устойчивость сопровождения на перекрытиях, доля ложных срабатываний в сумерках и на мокрой дороге. Планирование — по доле манёвров с подстраховкой и по отклонению от целевой траектории. Регресс ловится по конкретному блоку и не размазывается по всему контуру.

Класс отказов становится управляемым. Раньше сбой планирования выглядел как ошибка восприятия, и разбор шёл по всей системе. Теперь у отказа есть адрес, а значит и понятный перечень проверок, которые его закрывают.

Отсюда же устойчивость модели: обновление одного блока не требует переобучения остальных и полной перепроверки контура. Потеряв уверенность на незнакомой сцене, модуль уходит в консервативный режим, а не тянет за собой всё поведение машины.

Время разбора инцидента сокращается за счёт сквозного журнала: запись помечена версиями модулей, причину находят по фрагменту, а не воспроизведением заезда целиком. На практике это часы работы вместо дней, и правка касается одного блока, а не всего контура.

Подходы к построению: модульный, сквозной, гибридный

Выбор схемы определяется маршрутом эксплуатации и составом сенсоров, а не предпочтениями команды. Модульный конвейер разделяет восприятие, планирование и управление на независимые блоки: отказ локализуется в конкретном узле, блок можно заменить, не пересобирая систему целиком. Сквозная обучаемая модель учится сразу на видео и телеметрии — увереннее в сложных сценах, но требует большого объёма разметки и слабо объясняет решения.

Гибридная схема соединяет обучаемое восприятие с формальным планированием: поведение остаётся проверяемым, качество распознавания растёт. Дообучение готового стека под свой парк сенсоров даёт результат быстрее прочих, но остаётся в границах исходной архитектуры.

Разбор начинаем с трёх вопросов: какие сенсоры уже стоят, насколько предсказуем маршрут и кто будет разбирать инциденты после запуска. Ответы на них и определяют, какой вариант выдерживает ваши условия эксплуатации.

Этапы разработки: от аудита сценариев до приёмки

Разработка системы автономного вождения — не один длинный спринт, а последовательность этапов, на каждом из которых есть проверяемый результат. Процесс строим так, чтобы состояние модулей восприятия, планирования и управления было видно по метрикам на размеченных наборах сценариев, а не по презентациям.

1. Аудит сценариев. Фиксируем условия эксплуатации, классы объектов и манёвры, которые система обязана отрабатывать, и то, что осознанно оставляем за периметром. Итог — матрица сценариев с приоритетами и перечень ограничений.
2. Подготовка данных. Собираем записи сенсоров, размечаем и балансируем набор по редким ситуациям, отдельно формируем проверочные выборки, не пересекающиеся с обучающими.
3. Настройка модулей. Восприятие, планирование и управление отлаживаем раздельно, у каждого свои метрики: полнота обнаружения, доля пропущенных объектов, плавность траектории. В общий контур собираем только после прохождения порога по каждому модулю.
4. Испытания. Сначала виртуальный пробег в симуляторе на тысячах сценариев, затем закрытая площадка и дороги общего пользования с водителем-испытателем. Каждый инцидент разбираем до причины, а не до симптома.
5. Калибровка и регресс. Любое изменение проходит полный регресс на закреплённом наборе: система не должна выигрывать на новом сценарии, теряя на старом.
6. Приёмка системы. Сдаём по согласованному протоколу: метрики безопасности, доля вмешательств водителя, время восстановления после отказа сенсора, отчёт о покрытии сценариев и документация.

Контрольная точка каждого этапа — воспроизводимый прогон, который можно повторить на вашей стороне. Спорные места закрываем до старта следующего этапа, а не после сдачи.

Поставка по автономному вождению: модели и регламенты

Результат проекта — не показ на полигоне, а комплект, с которым ваша команда продолжает работу без нас. Каждый артефакт версионируется в вашем репозитории, проверяется на приёмке и остаётся у вас вместе с правами на использование.

• Веса обученных моделей восприятия, планирования и управления в экспортируемом формате, с контрольными метриками качества на отложенной выборке.
• Конфигурации и скрипты воспроизведения обучения — от подготовки данных до выгрузки модели, чтобы повторный прогон давал сопоставимый результат.
• Схемы архитектуры: поток данных от сенсоров до управляющих воздействий, границы модулей, режимы деградации при потере сигнала.
• Регламенты испытаний: наборы сценариев, критерии прохождения, порядок прогонов на стенде и закрытой площадке, правила разбора расхождений.
• Документация: интерфейсы между модулями, форматы данных, требования к разметке, инструкции по развёртыванию контура на вашем оборудовании.
• Обучение инженеров заказчика — сессии на ваших данных и вашем стенде, чтобы команда сама правила наборы, дообучала модели и читала отчёты прогонов.
• Протоколы приёмки, известные ограничения и журнал решений по спорным сценариям как основа для следующих итераций.

Приёмка идёт по согласованным критериям: сценарий закрыт, когда воспроизводится на вашем стенде и подтверждён протоколом. Что не проходит — остаётся в работе, а не переносится в «известные ограничения».

Кейс: сокращение отказов при плотном движении

Клиент пришёл с работающим прототипом: автомобиль проходил городской маршрут, но на плотном движении автоматический режим приходилось прерывать слишком часто — порядка 12 вмешательств водителя на каждые 100 км. Больше половины случаев — слияния потоков, узкие полосы и перестроения соседей. Каждый такой заезд обнулялся и не давал накопить статистику для вывода системы в эксплуатацию.

Где терялась надёжность

Разбор записей показал, что причина не в отдельной модели, а на стыке звеньев. Восприятие обновляло сцену реже, чем планировщику требовалось, а треки объектов рвались при кратком перекрытии — автобус закрывал легковую, и она появлялась заново уже в опасной близости. Планировщик работал по единственному варианту траектории без оценки риска, поэтому вместо плавного объезда выбирал резкое торможение.

Что изменили и что получили

Мы переработали конвейер восприятия и планирования: связали треки по истории движения, добавили предсказание манёвров соседей и перевели планировщик на сравнение нескольких траекторий с оценкой риска по каждой. Сценарии прогоняли в симуляторе CARLA и на закрытой площадке, затем — на том же городском маршруте.

Вмешательства на 100 км упали с 12 до 3, ложные торможения — почти втрое, доля заездов без единого прерывания выросла с 18% до 64%. Тестовый парк стал проходить маршрут втрое быстрее, потому что перестал перезапускать заезды.

Чем отличается модульный конвейер от сквозной модели?

Разница в том, где проходят границы ответственности. В модульном конвейере восприятие, прогноз поведения других участников, планирование траектории и управление приводами — отдельные блоки с явными контрактами на вход и выход. Сквозная модель обучается от сенсоров к командам управления напрямую, и промежуточные представления в ней не описаны человеком, а возникают как побочный продукт обучения.

Разбираемость ошибок — главный водораздел. В конвейере сбой локализуется: по записи и промежуточным артефактам видно, что объект потерялся на этапе восприятия, а не был снят планировщиком, а один блок можно заменить или ужесточить правилами, не переобучая остальные. У сквозной модели такой привязки нет: причина неудачи ищется статистикой по большим выборкам, и ответ «сеть неNotice» — это не ответ.

Требования к данным тоже расходятся. Модулям достаточно своих наборов: детекция — разметка рамок, прогноз — треки, планирование можно доводить на симуляции и геометрии. Сквозной модели нужны длинные согласованные серии, где метки состояний и сигналы управления синхронны, иначе обучение уходит в артефакты. Редкие, но критичные сценарии приходится набирать отдельно — иначе модель их просто не увидит в общей массе.

Сопровождение вытекает из этого. Конвейер релизится по частям, версионирует интерфейсы между модулями и проверяет регрессию по метрикам стыков — обновление одного блока не ломает остальные. Сквозная модель при правке любого участка переобучается целиком, и проверять нужно весь маршрут заново. Поэтому на практике чаще собирают гибрид: сквозные блоки внутри модульной рамы, где за инженером остаётся контроль над стыками и возможность объяснить каждый отказ.

Частые технические вопросы по внедрению и испытаниям

До старта работ заказчик проверяет не архитектуру, а риски: как система поведёт себя в дождь и снег, кто отвечает за инцидент, можно ли дообучать её на своих данных и что делать с уже установленным парком сенсоров. Ниже — короткие ответы по каждому сомнению; на разборе задачи проходим их на вашей конфигурации и маршрутах.

Кто отвечает за инцидент?

Зоны ответственности фиксируем в договоре и регламенте эксплуатации — они не подразумеваются, а описаны. Мы отвечаем за компоненты, которые поставляем, и за доказательную базу: непрерывные журналы событий, записи сенсоров и возможность восстановить картину происшествия по шагам. Без такого следа разбор невозможен, поэтому запись ведётся с первого дня испытаний.

Можно ли дообучить систему на наших данных?

Дообучение на данных заказчика — штатная часть работы, а не отдельный проект. Собираем записи с ваших маршрутов, размечаем сложные случаи, дообучаем и проверяем на отложенной выборке плюс на закрытом наборе сценариев, чтобы не потерять уже достигнутое качество. Каждый цикл обновления проходит регрессионные проверки, иначе правка под одну дорогу ломает поведение на другой.

У нас частично установлен парк сенсоров — придётся менять всё?

Частично установленный парк — нормальный старт. Сначала описываем, что уже стоит и какие участки маршрута покрыты, затем достраиваем только пробелы: слепые зоны, отсутствующие ракурсы, нехватку перекрытия. Существующие сенсоры проверяем на калибровку и синхронизацию — часто их достаточно, а замена требуется только там, где покрытие физически не закрывается.

Обсудим задачу: какие данные нужны для оценки

Оценка задачи автономного вождения начинается не с выбора модели, а с инвентаризации того, что уже есть: без исходных данных любая цифра по срокам — догадка. Ниже — минимум, после которого мы возвращаемся с планом работ и декомпозицией по этапам.

• Сценарии эксплуатации — где движется платформа: закрытая территория, город, трасса; какие манёвры обязательны, а какие недопустимы.
• Записи сенсоров — сырые данные с камер, лидаров и радаров с метками времени, синхронизацией и калибровкой между датчиками.
• Разметка и её качество — есть ли аннотации объектов, полос и свободного пространства, кто их делал и по какой инструкции.
• Требования к поведению — правила приоритета, дистанции, реакции на пешеходов и нештатные ситуации, описанные текстом, а не «на словах».
• Платформа и ограничения — вычислительный модуль, доступная память, допустимое время реакции контура управления, интерфейсы к приводам и тормозам.
• Метрики приёмки — по чему принимаем результат: доля пройденных сценариев, число вмешательств оператора, перечень недопустимых отказов.
• Инфраструктура — где обучаем и воспроизводим эксперименты: кластер, хранилище, версионирование наборов данных и весов моделей.

Обсуждение требований идёт параллельно сбору: мы фиксируем, что входит в объём, а что выносим за скобки, и где граница ответственности между модулями восприятия, планирования и управления. Если часть данных отсутствует — это не остановка, а отдельный этап подготовки в плане, с понятной стоимостью по срокам и риску. Присылайте то, что есть: вернёмся с оценкой, порядком работ и перечнем того, что нужно добрать до старта.