Умеют ли трансформеры водить машину

Трансформеры уже умеют писать код, генерировать тексты и рисовать картины. Но могут ли они управлять автономным автомобилем в реальных городских условиях, среди людей и других машин?

Меня зовут Максим, я руковожу службой поведения и предсказания движения в Автономном транспорте Яндекса. Отвечаю за задачу Motion Planning — ту часть системы, которая решает, как именно должен двигаться автомобиль в следующие секунды. В этой статье я расскажу, как мы используем архитектуры на основе трансформеров в планировании движения и почему это сильно отличается от привычных задач генеративных моделей.

Мы пройдём путь от первых ML‑экспериментов до регулярных испытаний на реальных машинах. Разберём, чем Open Loop отличается от Closed Loop, почему качество предсказаний не определяет качество вождения и почему безопасность для нас важнее любой архитектуры.

Любая система автономного движения опирается на модуль, который в индустрии называют Motion Planner. Это алгоритм, который несколько раз в секунду решает, куда должен переместиться робот или автономный автомобиль: по какой траектории, с какой скоростью и с какими манёврами. Фактически это мозг, который превращает восприятие мира в конкретные действия — руление, торможение, ускорение.

Любая модель вождения проходит длинную цепочку проверки: определение ML‑метрик, симуляцию и только затем тесты под контролем водителей‑испытателей — это нужно для безопасности.

Чтобы Motion Planner мог работать, он получает на вход три типа данных:

• сенсорные данные с камер, лидаров, радаров;

• дополнительное структурированное описание сцены — в случае автономного автомобиля это HD‑карта с описанием дорожной разметки;

• цель движения — маршрут и точку назначения.

Далее примерно каждые 100 мс система пересобирает состояние мира и заново решает, где автомобиль окажется через доли секунды и какие управляющие команды нужно выдать.

В индустрии существует два основных подхода к построению таких систем.

Первый — классический. Motion Planner разделён на компоненты: perception и planning. Сначала мы превращаем сырые сенсорные данные в структурированное представление сцены, а затем отдельный планировщик строит безопасную траекторию. Так работают автомобили Waymo, Zoox, Aurora и наши тоже. Этот подход надёжнее, прозрачнее и позволяет отдельно тестировать восприятие и планирование на большом количестве сценариев.

Второй — end‑to‑end. Модель получает на вход сырые сенсоры и сразу выдаёт управляющие действия, без промежуточной стадии perception (тем не менее она может быть дополнительной стадией для интерпретируемости и валидации). Такой подход используют, например, в Tesla. Это интересная и перспективная исследовательская линия, но для продакшена она пока слишком хрупкая: качество таких моделей сложно измерить до наката в реальности, так как нужна реалистичная симуляция сенсорных данных, а достаточно надёжные и качественные симуляторы такого рода пока являются предметом исследований.

Далее в статье я буду говорить именно про первый подход (с разделением на perception и planning) — тот, который мы используем в реальных автономных автомобилях Яндекса.

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

Что подаётся на вход модели

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

Агенты. Так мы называем любые движущиеся объекты: автомобили, мотоциклы, пешеходов, велокурьеров — всех, чьё поведение нужно предсказывать. Perception даёт нам не только их текущее состояние, но и историю состояний — 100 мс назад, 200 мс назад и дальше на несколько секунд.

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

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

Карта. Кроме временных сигналов (агентов и эго), у нас есть статическая геометрия — HD‑карта. В отличие от остальных входов, карта — пространственная структура, не зависящая от времени. В ней заранее известны границы дорог, линии разметки, центры полос и топология движения, ограничения скорости, приоритеты и другие атрибуты.

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

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

Что на выходе

Маршрут для простоты можно считать частью карты, поэтому в этой части мы его опустим. Нас интересует, что именно должна выдавать модель.

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

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

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

Но где взять достаточно примеров таких сцен и как подготовить их для обучения модели?

Как мы собираем данные

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

В логах есть всё, что нам нужно:

• трек эго (то есть нашего автомобиля);

• треки всех агентов вокруг — кто появился, кто пропал, кто перестроился или свернул на другую улицу.

Дальше процесс выглядит следующим образом. Мы выбираем произвольный момент времени X и берём будущие 5 секунд треков из логов — это наш ground truth. Всё уже записано, поэтому в этих 5 секундах есть реальные траектории и эго, и остальных агентов. А предыдущие 5 секунд используем как input — то, что система «видела» к моменту времени X.

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

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

Теперь у нас есть описания входов, выходов, а также то, откуда мы берём данные для обучения. И здесь появляется следующий ключевой компонент — как именно измеряем качество предсказаний.

Метрики: Open Loop и Closed Loop

Чтобы корректно поставить задачу, нужны метрики. Базовый вариант — сравнивать предсказанную моделью траекторию с эталоном из логов. В логах у нас есть ground truth: реальные траектории эго и всех агентов.

В Open Loop мы просто «телепортируем» модель в сцену из датасета и сравниваем её предсказание с эталоном. Используются стандартные метрики Motion Prediction:

• Average Displacement Error — средняя ошибка по точкам траектории, измеряемая каждые 100 мс;

• Final Displacement Error — ошибка в последней точке;

• Miss Rate — попадает ли хотя бы одна из предсказанных траекторий в заданный коридор вокруг ground truth.

Open Loop оценивает только качество «угадывания будущего» при фиксированном входе — без среды, без исполнения, без обратной связи.

Но наша конечная задача — планирование движения (Motion Planning), а не предсказание. В реальности автономный автомобиль работает в замкнутом цикле: каждые ~100 мс он получает обновлённое состояние мира, пересчитывает траекторию и делает шаг. Его действия влияют на среду, среда влияет на вход модели — и так бесконечно.

Такой режим называют Closed Loop. Здесь сравнение с эталоном имеет меньше смысла: небольшое отклонение от ground truth необязательно ошибка — часто это тоже вполне правильное и безопасное решение. Поэтому метрики в таком сетапе другие, они описывают качество реального поведения модели:

• Collisions — были ли столкновения в симуляции;

• Rules compliance — соблюдение правил движения (например, не проехать на красный);

• Road compliance — удержание автомобиля в пределах дороги;

• Route compliance — не уезжаем ли мы с маршрута;

• Driving comfort — нет ли ненужных рывков, колебаний и других неприятных эффектов.

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

Таким образом, Open Loop — это про качество предсказания, а Closed Loop — про качество вождения. И в конечном счёте именно Closed Loop определяет, насколько безопасно модель ведёт себя в реальной среде.

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

Архитектура

У нас есть постановка задачи, данные и метрики. Теперь — к архитектуре. Формально перед нами задача sequence‑to‑sequence: на вход приходят временные последовательности стейтов, нужно предсказать будущие стейты. Для решения используем трансформеры.

• Энкодер временного контекста. Для каждого агента и эго у нас есть последовательность стейтов за последние несколько секунд. Мы пропускаем её через энкодер с attention по временной оси, чтобы модель учитывала динамику движения.

• Энкодер карты. Карта — статическая структура, которую также нужно преобразовать в эмбеддинги. Обычно её разбивают на фрагменты с фиксированным числом точек и кодируют каждый фрагмент отдельным энкодером. PointNet здесь лишь пример возможного подхода. Можно использовать как более простые, так и более сложные варианты.

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

На выходе этого блока получается три вида эмбеддингов: агентов, карты и эго.

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

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

Теперь, когда архитектура определена, переходим к результатам первых обучений.

Какую задачу решили

Мы обучили модель на датасете реальных проездов и замерили ML‑метрики. В Open Loop они снижаются ожидаемо: Average Displacement Error стабильно падает по мере обучения. Этот этап мы называем претрейном — по сути, это решение задачи Motion Prediction без взаимодействия со средой.

По графикам видно примерно следующее:

• на горизонте 30 стейтов (или трёх секунд) среднее отклонение от ground truth — порядка 15 см;

• на горизонте пяти секунд — около 40 см.

На первый взгляд звучит отлично: модель «телепортируется» в любую сцену из датасета и с точностью до десятков сантиметров предсказывает, что бы сделал водитель‑испытатель. Но подвох в том, что всё это — метрики Open Loop.

Когда мы запускаем ту же модель в Closed Loop, то есть в реальной среде симуляции, где она каждые 100 мс получает обновлённое состояние мира и перестраивает траекторию, выясняется, что она… не всегда может ехать даже по центру полосы. Хотя любой водитель делает это легко, особенно на пустой дороге.

И что ещё неприятнее, модель в целом начинает вести себя довольно глупо, несмотря на блестящие метрики Open Loop. На Motion Prediction она показывает отличные результаты, но в Motion Planning — проваливается.

Почему так происходит? Это наблюдение давно известно в робототехнике и self‑driving: похожие эффекты демонстрировали и другие команды. Даже была статья про аналогичную генеративную модель, там получали такую же картину.

Чтобы разобраться, посмотрим внимательнее на то, как именно ведут себя разные подходы в Open Loop и почему всё меняется, когда модель попадает в Closed Loop.

Почему хорошие модели в Open Loop ведут себя плохо в Closed Loop

В вышеупомянутой статье рассматривались два подхода:

• Простейшая IDM‑модель. Эго держится в центре полосы и тормозит перед препятствиями пропорционально расстоянию до такового. Никакого машинного обучения, только кинематика и пара эвристик.

• PDM‑Open. Генеративная модель, обученная на данных реальных водителей. В Open Loop она выдаёт отличные метрики и хорошо предсказывает человеческие траектории.

Если смотреть только на Open Loop Score (OLS), всё логично: водители по центру полосы не ездят идеально, тормозят по‑разному и генеративная модель предсказывает это поведение намного лучше, чем примитивный IDM.

Но ситуация меняется, когда мы смотрим на Closed Loop Score. Для CLS‑R (с реактивными ботами) и CLS‑NR (с нереактивными ботами) — метрик, которые измеряют качество вождения в симуляции — простая IDM‑модель внезапно аутперформит сложный трансформер. «Умная» модель, которая прекрасно воспроизводит человеческие траектории в Open Loop, в Closed Loop начинает вести себя глупо.

Это системная проблема: метрики Open Loop и Closed Loop могут быть обратно скоррелированы. Улучшаешь Open Loop — ухудшаешь Closed Loop. И наоборот.

Чтобы понять, почему так происходит, разберём ключевые проблемы.

Проблема № 1: Kinematic Hacking

Когда мы пытаемся понять, почему модель, отлично работающая в Open Loop, разваливается в Closed Loop, полезно взглянуть на один простой, но показательный эффект.

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

Первое, что приходит в голову, — ограничения скорости на карте. Логично: на пустой дороге водитель часто едет примерно с разрешённой скоростью. Значит, модель может «объяснить» свою скорость, глядя на карту.

Второй вариант — другие агенты. Если автомобиль движется медленнее ограничения, скорее всего, он подстраивается под поток или под автомобиль впереди. Тогда скорость будет скоррелирована со скоростью окружающих машин.

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

Возникает эффект, который мы называем Kinematic Hacking: модель выучивает тривиальную корреляцию «едем туда же и с той же скоростью», и это даёт прекрасные метрики Open Loop. Но в Closed Loop такая стратегия не выдерживает проверки: автомобиль почти не реагирует на окружение и в большинстве сценариев уходит с центра полосы.

Чтобы решить проблему, можно искусственно ограничить корреляцию.

Мы сделали два шага:

1. Убрали историю эго. Предыдущие стейты могут быть слишком скоррелированы с будущими, и без них в целом модель может обойтись.

2. Добавили дропаут текущего стейта эго. Таким образом, модель сможет по небольшой доле примеров выучить динамику движения, а в большей части обучающих примеров будет вынуждена искать корреляции с чем‑нибудь ещё.

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

Проблема № 2: разнообразие данных

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

А ML‑модель просто по своему построению предсказывает водительское поведение с небольшой ошибкой, например на 10–15 см. И если за 100 мс она сместится чуть‑чуть, то за секунду рискует отклониться гораздо сильнее, так как сделает ошибочное предсказание несколько раз подряд. И потом так окажется, что в обучающем датасете нет ни одного примера, который бы показывал ей, как вернуться обратно и отрекавериться от такой ошибки.

Как это исправляют коллеги (и как сделали мы): добавляют аккуратную синтетику. Например, слегка искажают ground truth так, будто бы автомобиль отклонился и вернулся в полосу. Это нужно делать очень аккуратно, чтобы не научить модель вилять, но правильно аугментированные таким образом данные заметно улучшают способность модели удерживать дорогу и держать корректную скорость.

Проблема № 3: фундаментальное ограничение Imitation Learning

Imitation Learning учит модель на демонстрациях хороших водителей. Но лосс у неё простой: либо кросс‑энтропия по токенам, либо какая‑то средняя ошибка между предсказанием и эталоном.

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

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

Промежуточный итог: что получилось после исправлений

Мы применили несколько подходов:

• убрали историю эго и добавили дропаут текущего стейта;

• добавили синтетику корректирующих траекторий.

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

И эти версии уже заметно улучшили поведение в симуляции, а главное, хорошо поехали в реальных тестах с водителем‑испытателем. Метрики реальных проездов я привести здесь не могу, приведу только улучшение по симуляции. Тем не менее даже по реальным проездам видно, что прогресс кратный.

Но все описанные методы — это небольшие решения внутри рамок Imitation Learning. Они уменьшают расхождение между Open Loop и Closed Loop, но полностью проблему не убирают. Чтобы двигаться дальше, нужен инструмент, который учитывает обратную связь со средой напрямую.

Reinforcement Learning: более простой вариант Open Loop

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

Дальше всё работает как классический RL‑цикл: модель генерирует действия, потом получает reward и обновляет параметры.

У нас этот процесс заводился и с простыми методами вроде Reinforce, и с PPO — сейчас мы тестируем и другие варианты. Даже такой базовый RL поверх имитационного обучения уже даёт заметное улучшение поведения в симуляции.

Но это только первый шаг. Дальше можем пойти глубже и обучать модель не в роллаутах Open Loop, а в настоящем Closed Loop, внутри симуляции.

RL в Closed Loop: использование среды

Главное преимущество здесь в том, что среда автономного транспорта достаточно стабильна. В отличие от пользователей интернета, которые могут вести себя по‑разному в зависимости от модных трендов или новостей в мире, водители в городе в целом ведут себя одинаково из года в год. Их поведение симулировать проще.

Благодаря этому мы можем построить такой цикл RL‑обучения:

1. Энкодим текущую сцену.

2. Модель выдаёт не всю траекторию сразу, а ближайшие несколько действий.

3. Автомобиль смещается в новый стейт, а симулятор двигает остальных агентов.

4. Снова энкодим получившуюся сцену.

5. Повторяем шаги и получаем длинный роллаут Closed Loop длиной в несколько секунд.

Такой подход даёт два ключевых преимущества:

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

• Можно учить долгосрочное поведение делая длинные роллауты — 10, 20, 30 секунд. В Open Loop это невозможно: слишком много неопределённости в таком далеком будущем. В Closed Loop — можно, потому что при генерации модель делала только короткие предсказания.

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

Преимущества RL + Closed Loop

Здесь я перечислю несколько практических наблюдений при применении RL со средой в нашей задаче.

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

Во‑вторых, длинный роллаут — огромный плюс. В Open Loop мы не можем предсказывать на 30 секунд вперёд. В Closed Loop — можем, и это даёт модели способность к долгосрочному планированию.

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

Результаты

Первый раз, когда я увидел, что делает модель после RL + Closed Loop, это выглядело впечатляюще: она заранее перестраивается, уходит от потенциальных проблем, реагирует на странное поведение агентов так, как делает опытный водитель.

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

RL в Closed Loop даёт качественный скачок, но не решает всех задач — лишь открывает дорогу к новым направлениям, которые требуют отдельного внимания.

Результаты

Развитие и открытые направления

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

Одно из направлений, которое мы активно развиваем, — синтетические данные для обучения с подкреплением.

Редкие и потенциально опасные ситуации почти не встречаются в реальных логах, поэтому поверх небольшого количества таких эпизодов мы генерируем их вариации: меняем локацию, количество агентов, конфигурацию движения. Для Imitation Learning такие данные бесполезны (нет ground truth), но в RL они могут работать — важна корректная симуляция и reward‑функция.

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

А ещё заранее приглашаю вас на Practical ML Conf. В этом году конференция о практическом ML пройдет 19 сентября. Регистрация уже открыта!

Источник: habr.com