TreeIRL: Safe Urban Driving with Tree Search and Inverse Reinforcement Learning

Сегодня разберём статью, в которой авторы предлагают использовать поиск монте-карло по дереву (Monte-Carlo Tree Search, MCTS) для задачи планирования. Как и в обычном MCTS, сначала генерируется множество траекторий, а затем на каждом шаге поддерживается баланс между перспективными направлениями и теми, которые ещё не исследованы.

Перспективность направления определяется функцией награды, учитывающей несколько факторов:

🔴 штраф за рывки (для комфорта),
🔴 штраф за столкновения с машинами и людьми,
🔴 адекватное расстояние до агента спереди,
🔴 следование на скорости около максимальной разрешённой,
🔴 остановки в местах, где это необходимо,
🔴 опционально — предобученная PPO-политика и её функция ценности V.

Исследователи генерируют всего 400 траекторий и выбирают из них 100 наиболее перспективных кандидатов по награде. Отобранные траектории удовлетворяют формальным требованиям, однако не все из них применимы в реальности.

Для решения этой проблемы авторы обучают отдельную модель на inverse reinforcement learning. Её задача — дать скалярное значение z, которое позволит из представленных траекторий выбрать наиболее «человекоподобную». При обучении используется таргет exp(z_i)/sum_z(exp(z)) — подходящая траектория определяется по подобию в L2-норме. В итоге из 100 траекторий-кандидатов остаётся только одна, лучшая по IRL-оценке. Она удовлетворяет формальным критериям и похожа на то, как водил бы человек.

Этот метод отличается от обычного подхода, где сначала нейросеть генерирует несколько траекторий, а потом их проверяют на формальную безопасность. Это свежий взгляд, но, к сожалению, остаётся неочевидным, насколько хорошо он масштабируется: подход тестировался как адаптивный круиз-контроль, и модель предсказывала только продольные рывки. С этим ограничением мы имеем всего 5 возможных действий против, например, 169 в другом популярном методе, MotionLM. Количество возможных деревьев в таком случае астрономически меньше — 390 тысяч против 600 квадриллионов.

Что касается результатов работы модели, то в категории адаптивного круиз-контроля на бенчмарке nuPlan TreeIRL показала себя весьма хорошо. Модель также применялась на дорогах общего пользования и смогла проехать 400 км без вмешательств.

Разбор подготовил ❣️ Кирилл Федянин
404 driver not found

DINO-MOT: 3D Multi-Object Tracking With Visual Foundation Model for Pedestrian Re-Identification Using Visual Memory Mechanism

В этом исследовании ищут решение задачи 3D Multi-Object Tracking (3D-MOT) в контексте автономного вождения. Акцент делают на том, как повысить точность отслеживания пешеходов.

Фреймворк DINO-MOT, по мнению авторов, расширяет классический подход Tracking-by-Detection за счёт интеграции DINOv2. Ключевая идея — использование визуальной информации с камер для повторной идентификации (Re-Identification) пешеходов. Это позволяет снизить количество ID switches до 12,3%.

3D-детекции пешеходов проецируются на 2D-изображения, из которых извлекают области интереса (кропы). Эти изображения обрабатывают энкодером DINOv2: получают признаковые эмбеддинги и сравнивают их с визуальной памятью (Lookup Table) с помощью косинусной схожести для коррекции треков.

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

На момент публикации DINO-MOT лидирует на бенчмарк-наборе nuScenes: устанавливает новое SoTA-значение по метрике AMOTA — 76,3%.

По результатам абляционных исследований, интеграция DINOv2:

🔴 Позволяет стабильно снижать ID switches для пешеходов, если использовать различные детекторы.
🔴 Не оказывает негативного влияния на общую точность трекинга.

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

Разбор подготовила ❣️ Ольга Ротова
404 driver not found

MADrive: Memory-Augmented Driving Scene Modeling

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

🔴 3D Gaussian Splatting (3DGS), чтобы реконструировать объекты и сцены, а потом генерировать новые кадры (novel-view synthesis).
🔴 Внешний банк объектов. Он помогает создавать реалистичные кадры с тех ракурсов, для которых не хватало исходных данных.

Как это работает
Мы декомпозируем сцену на статический фон (дорога, здания, деревья) и динамику (автомобили). Фон восстанавливаем c помощью 3DGS по данным с камер, уже известным положениям камер в проезде и лидарным 3D-точкам (как начальное приближение для положения сплатов).

Для эффективной работы с автомобилями мы предварительно собрали датасет MAD-Cars. В него вошли около 70 тысяч 360-градусных видеозаписей автомобилей разных моделей и цветов.

Чтобы реконструировать автомобили при обработке проезда:

1. Выделяем каждый автомобиль на сцене в 3D-бокс.
2. Получаем 2D-кроп по проекции бокса на кадр.
3. Считаем эмбеддинг SigLIP2 для кропа и уточняем цвет машины с помощью Qwen2.5-VL.
4. Находим похожую машину в MAD-Cars по эмбеддингу и цвету (косинусное сходство).
5. Для найденного автомобиля строим новую 3D-модель c помощью 2D Gaussian Splats. Попутно явно разделяем цвет автомобиля и влияние освещения, при котором записывали 360-градусное видео для MAD-Cars.
6. Переосвещаем восстановленную 3D-модель автомобиля с учётом освещения на реконструируемой сцене. Вставляем модель в сцену на место реальной машины.

Зачем это нужно
MADrive позволяет достоверно генерировать синтетические сенсорные данные для новых дорожных сценариев. MAD-Cars полезен для многих задач 3D Computer Vision — от реконструкции до генерации сцен.

Познакомиться с MADrive и MAD-Cars можно на странице проекта, а узнать больше об их создании — на Хабре.

Разбор подготовил ❣️ Кирилл Струминский
404 driver not found

Learning Personalized Driving Styles via Reinforcement Learning from Human Feedback

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

RLHF (reinforcement learning from human feedback) — тот самый алгоритм, который используют для алайнмента моделей под потребности людей в текстовых LLM, в том числе в оригинальном ChatGPT: людей просили людей ранжировать ответы, и по их оценкам нейросеть обучалась говорить приятное и полезное.

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

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

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

Самое интересное происходит во время дообучения. Если для претрейна используют данные о водителях с очень разными стилями вождения, то для файнтюна предлагают фильтровать сцены, оставляя только подходящие. Далее тренируют отдельную модель награды, которая должна присваивать траекториям одинакового стиля более высокий скор, если их сгенерировал человек, а не претрейн-модель. Эти награды помогают дообучить основную модель с GRPO на крошечном датасете: 5 тысяч сцен против полумиллиона в претрейне. То есть, авторы буквально активируют определённый стиль, в котором модель уже умеета водить.

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

Разбор подготовил ❣️ Кирилл Федянин
404 driver not found

Old but gold: SimCLR и DINO [1/2]

Сегодня начнём разбирать популярные подходы к построению foundation model. Первым двум работам уже много лет, но их основные идеи до сих пор актуальны.

A Simple Framework for Contrastive Learning of Visual Representations (или просто SimCLR)

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

Есть несколько изображений. Каждое из них аугментируют двумя способами, после чего подают на вход модели-эмбеддеру все аугментированные изображения. А дальше — обычный contrastive learning. Эмбеды, соответствующие аугментациям одного и того же изображения, приближают друг к другу, одновременно отдаляя от эмбедов прочих аугментированных изображений. Заранее размечать данные при таком подходе не нужно.

Авторы рассуждают, какие именно рецепты аугментаций лучше подойдут для задачи self-distillation. Общий компонент рецептов — разбиение аугментаций на сильные и слабые: одно аугментированное изображение из пары всегда будет испорчено сильнее, чем другое

DINO: Emerging Properties in Self-Supervised Vision Transformers

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

Изображение, которое подаётся на вход учителю и ученику, аугментируют по-разному:

🔴 Для модели-учителя готовят глобальные аугментации (для простоты можно считать, что они строятся по всей картинке целиком, без crop-and-resize).
🔴 Для ученика — локальные (кусочек изображения).

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

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

В следующей серии поговорим о semi-supervised подходах к построению foundation model.

Разбор подготовил ❣️ Сергей Ким
404 driver not found

Old but gold: Data Engine на примерах OWL и SAM [2/2]

Продолжаем разбирать популярные подходы к построению foundation model. В первой части обсудили SimCLR и DINO, сегодня в программе — Data Engine на примерах OWL и SAM.

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

Хороший пример human-in-the-loop pipeline: RLHF (reinforcement learning from human feedback) завёлся для текстового домена, но не работает для компьютерного зрения. Так для задач обработки изображений появился родственный пайплайн — model-in-the-loop.

Работы Scaling Open-Vocabulary Object Detection (OWLv2) и Segment Anything (SAM) вышли в одно и то же время. Обе они посвящены схожему концепту Data Engine:

1. Модель v1 обучают на датасете, собранном мануально.
2. Модель v1 участвует в псевдоразметке примеров. Разметку по необходимости корректирует человек — получается псевдодатасет.
3. На полученном псевдодатасете обучают модель v2.
4. Модель v2 порождает следующую волну разметки. Алгоритм можно повторять до тех пор, пока не получится модель с нужным качеством.

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

Качественную задачу можно свести к количественной, если хорошо настроить конвейерную автоматику движка данных на каждом из этапов:

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

Пересмотреть подход к отбору данных пытаются во многих современных работах. Например, в DINOv2, Llama2 и Llama3 много внимания уделяют дедупликации данных и улучшению разнообразия датасетов. А также ищут способы повысить эффективность обучения на выросшем корпусе данных.

Разбор подготовил ❣️ Сергей Ким
404 driver not found

Distilling Multi-modal Large Language Models for Autonomous Driving

Сегодня разберём статью о попытке дистиллировать VLM (а именно LLaVA-1.5-7b) в планнер — в теории это улучшает понимание сцен и подчищает длинные хвосты.

Ход мысли интересный:

🔴 VLM по умолчанию знает о мире больше, чем стандартная планнерная модель.
🔴 Чем больше размер, тем лучше обработка нишевых ситуаций.
🔴 Дистилляция позволяет эффективно упаковать оба предыдущих преимущества в меньшую модель для деплоя.

Для реализации авторы предлагают использовать предобученную для вождения end-to-end модель с промежуточными векторными представлениями. VLM, в свою очередь, умеет отвечать на вопросы, и у неё тоже есть выходные эмбеды — обе модели доучивают параллельно, накладывая ограничение: их векторные пространства должны быть похожи по KL.

Но если обучать VLM только предсказывать движение, она схлопнется и утратит свои обширные знания о мире. Чтобы избежать этого, обучение обогащают несколькими типами задач. Во-первых, реконструкцией маскированных токенов-агентов как в BERT. Во-вторых, ответами на текстовые вопросы. Например, учат отвечать, какая на улице погода или что будет делать агент перед нашим ТС. Чем лучше понимание сцены, тем выразительнее выход модели — векторное пространство.

Чтобы это всё работало, авторы адаптируют:

🔴 Входы. Учат Q-Former слои проекций для каждого типа данных (bev, карта, промпт). В итоге получается набор токенов, которые последовательно отдают в VLM.
🔴 Выходы. Готовят отдельные головы, чтобы предсказывать положения эго и агентов, решать синтетические задания и отвечать на текстовый промпт текстом.

Основную часть LLaVa авторы тренируют с помощью LORA: не трогают все веса, а только доучивают небольшие поправки к ним.

Этот подход напоминает известный способ быстрой разработки мультимодальных моделей, когда векторные представления претренированной LLM и картиночного энкодера файнтюнят на задачах в духе visual QA.

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

🔴 Количество коллизий уменьшилось вдвое по сравнению с исходной end-2-end моделью.
🔴 Дистилляция прошла успешно, модель фактически не проседает на тесте без VLM.

Разбор подготовил ❣️ Кирилл Федянин
404 driver not found

GaussianLSS — Toward Real-world BEV Perception: Depth Uncertainty Estimation via Gaussian Splatting

Авторы сегодняшней статьи предлагают альтернативу LSS. Для этого от задачи классификации распределения глубины они переходят к регрессии параметров распределения (среднего и дисперсии). В результате точно так же предсказывается распределение, но лоссы считаются иначе.

В GaussianLSS вместо BEVPool или BEVPoolv2 используется классическая растеризация через diff-gaussian-rasterization (как в компьютерных играх: проецируем полигоны/гауссианы на камеру/BEV). Именно так авторы получают BEV-фичи для прикладных задач, при этом увеличивая FPS за счёт diff-gaussian-rasterization. По FPS они побеждают всех конкурентов на бенчмарках, не сильно теряя в качестве.

Распределение вероятности по бинам предсказывается аналогично стандартному LSS. Но затем авторы считают среднее, поскольку знают, на каком расстоянии находится каждый бин, и дисперсию. Получаются точки в системе координат камеры (каждый пиксель — u,v и глубина для него — d). Они перегоняются в мировые координаты через внешние и внутренние матрицы калибровок.

Откуда вообще берётся распределение глубины? Как мы помним, в классическом LSS есть волшебный DepthNet, который предсказывает распределение глубины каждого пикселя и новые фичи. Авторы ещё немного модифицируют его так, чтобы получать ещё и opacity. Кажется, это сделано, потому что того требуют библиотеки для растеризации гауссиан. Но этот параметр можно как-нибудь использовать. Например, вы не хотите видеть бесполезное для ваших задач небо на BEV-фичах — благодаря opacity от него можно избавиться.

Итого, авторы получают в 3D-пространстве точки, у каждой из которых есть координата, матрица ковариаций (на самом деле немного вырожденная, потому что гауссиана растянута вдоль «луча», проходящего через пиксель камеры), а кроме того — opacity и фичи. Дальше можно просто взять и отрендерить гауссианы. У оригинальной diff-gaussian-rasterization не очень хорошая лицензия, но есть и «народная» реализация этой библиотеки.

После растеризации получаются стандартные BEV-фичи, которые можно использовать привычным способом.

Разбор подготовил ❣️ Денис Глазов
404 driver not found

Openpilot 0.11 — первый робо-агент, обученный только на симуляциях

Команда Comma.ai опубликовала интересный пост, где утверждает, что впервые в истории индустрии выпустила на дороги робо-агент, полностью обученный в вымышленной нейросетями симуляции.

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

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

Вот что предлагают создатели Openpilot 0.11:

Шаг 1. Собрать 40 тысяч часов интересных видео, записанных флотом автономного транспорта и разбить их на сцены по 10 секунд с частотой 5 Гц.

Шаг 2. Обучить на этом датасете двухголовую модель мира:

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

Потом к контексту добавляется сгенерированный кадр, и процесс повторяется.

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

Шаг 3. Обучить в полученном симуляторе небольшую модель-водителя, которая должна сходиться в финальное состояние по одному лишь видео, не видя последний кадр. Щедро насыпать шум на всех стадиях для устойчивости.

Openpilot 0.11 обучали on-policy — модель много едет по сгенерированной ей самой траектории, что выгодно отличает подход от обычного imitation learning.

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

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

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

Разбор подготовил ❣️ Кирилл Федянин
404 driver not found

π0: A Vision-Language-Action Flow Model for General Robot Control

Сегодня разберём статью о важной для self-driving теме из смежной области — как делать large-scale pre-training, если обучающих данных исчезающе мало.

У ребят, которые создают автономных роботов, обучающих датасетов ещё меньше, чем у нас. Авторы из команды Physical Intelligence предлагают решение: прикручивают flow-matching-декодер для экшнов к VLM, натренированной на internet-scale-датасете.

Архитектурно эта система устроена следующим образом:

1. Изображения с камер и текст задания попадают в префикс, проходят через VLM (PaliGemma 3B на базе Gemma 2) — получается KV-кэш.

2. В получившуюся последовательность после префикса добавляют эмбеддинг текущего состояния — вектора Q из 18 float-значений.

3. Траекторию на H=50 шагов, предсказывают с помощью flow-matching-декодера на 300M параметров, используя KV-кэш из 1 и 2.

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

При этом у аттеншна блочно-каузальная маска:

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

Так как префикс лежит в KV-кэше, важно, чтобы у декодера траектории были те же количество слоёв и размерность слоя. Но можно уменьшить размерность в MLP: именно так удаётся получить 300M параметров в декодере траектории при 3B в VLM.

Сначала модель претрейнят на составном датасете:

🔴 9,1% разнообразных опенсорс-данных — Oxe Magic Soup (2 Гц + 10 Гц),
🔴 остальные 90% (903M таймстепов на 68 заданий для single-/dual-arm роботов) — π0-dataset,
🔴 чтобы избежать дисбаланса, каждую task-robot-пару взвешивают с весом n⁰˒⁴³.

Потом обучают все части модели: image-backbone, VLM, Action-Expert. А во время пост-трейнинга каждый Action-Expert файнтюнится на своём task-specific-датасете.

В инференсе 10 шагов интегрирования (денойзинга). Он работает 73 мс на RTX 4090 (86 мс с задержкой сети). Для 20-герцовых роботов инференс делают каждые 0,8 секунды (после 16 шагов), для 50 Гц роботов — каждые 0,5 секунды (после 25 шагов). Для траекторий пробовали добавлять temporal ensembling, но результаты получились хуже чем open-loop.

Авторы утверждают, что на момент публикации были в топе всех популярных бенчмарков.

Разбор подготовил ❣️ Сергей Репьевский
404 driver not found