Опыт соревнования VLNVerse: от базовой навигации до переноса двухсистемной модели

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

Этот разбор описывает базовое обучение, перенос InternVLA, совместное обучение и отправку решений, которые мы делали на соревновании VLNVerse 2026. По онлайн-квитанциям успешность по подробным инструкциям выросла с 32.0% у базовой модели до 48.7% у InternVLA в режиме zero-shot; у грубых инструкций тот же перенос снизил результат с 27.3% у исправленной базовой модели до 22.7%. Поэтому два типа инструкций нужно проверять отдельно, а больший объём обучения не даёт улучшения автоматически.

Онлайн-результаты относятся к конкретным номерам отправок, локальные результаты — к фактически завершённым оценкам. По сохранившейся таблице соавтора от 17.07.2026 результаты составляли: грубые инструкции 46.0%, подробные 59.3%, итоговое место — 7-е; это не окончательное место по итогам соревнования. В архивных материалах мы не нашли окончательной квитанции таблицы.

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

Публичная модель и архив: Datawhale / VLNVerse, адаптер для грубых инструкций. Это экспериментальные веса от 22 июня из таблицы 5, включая зафиксированную деградацию после расширенной оценки. Веса опубликованы в 41 фрагменте; сопутствующий скрипт восстанавливает файлы, побайтно совпадающие с оригиналами. Этот адаптер не соответствует результату zero-shot 48.7% в онлайне.

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

1. Задача, робот и способ оценки

Основной путь участия использует гуманоидного робота H1, Isaac Sim 4.5 и InternUtopia. Сцены — жилые интерьеры из ассетов Kujiale с разными комнатами, мебелью, дверными проёмами и коридорами. Площадь жилья, досягаемые зоны и длина маршрутов различаются, поэтому нельзя описать все тестовые задачи одной «площадью дома».

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

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

Таблица 1. Метрики, использованные в основной работе.

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

На позднем этапе соревнование перешло на общий зачёт (Overall): по 150 инструкций каждого типа, итоговый балл — среднее арифметическое успешности на пороге 3 м по двум типам. Если одна сторона отсутствует, она считается нулём; старые отправки отдельных треков в новый рейтинг автоматически не переносились. Корневой каталог итогового архива должен содержать:

submission_overall.zip
├── coarse_challenge.json.gz
└── fine_challenge.json.gz

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

2. Сначала сделать данные и окружение проверяемыми

Самой ранней трудностью была загрузка больших файлов. Официальная сцена занимает около 312 ГБ, предварительно собранные данные — около 179 ГБ, плюс ассеты роботов, предобученные энкодеры и кеш. Если одновременно хранятся установщики, исходные ассеты, результаты обработки и модели, фактическое место на диске заметно больше того, что показано на странице загрузки.

Рекомендуется отделить исходный код от больших файлов и сделать так, чтобы конфигурации ссылались на единый корень данных:

workspace/
├── source/          # исходный код с фиксированной версией
├── configs/         # конфигурации обучения и оценки
└── reports/         # небольшие сводки результатов
data-root/
├── envs/            # рабочие окружения
├── datasets/        # сцены и траектории
├── models/          # исходные веса и результаты обучения
├── cache/           # кеш, который можно пересоздать
└── evaluations/     # построчные результаты и видео

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

Мы сначала считали ассеты «готовыми» по наличию каталогов и проверке части файлов, а затем обучение обнаружило отсутствие отдельного файла rgb.npy. Глубже проверка показала, что в локальных обучающих ассетах не хватает целых каталогов траекторий: в списках грубых и подробных инструкций не хватало 932 и 931 каталога соответственно, и прежние проверки их не охватывали.

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

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

3. Разный размер выборки: сначала проверяем ассеты, потом правила выборки

При совместном обучении в нашей локальной документации стояли 122 472 образца для грубых инструкций и 40 955 для подробных, а соавтор считал 150 009 и 50 366. На первый взгляд это похоже на разные версии загрузчика, но на деле действовали одновременно два фактора: целостность данных и стратегия выборки.

Таблица 2. Разные источники числа обучающих образцов.

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

В тогдашней ветке format == "vlnverse_action" перечисление образцов шло с sample_step=4; количество определялось не параметрами predict_step_num=32 или num_future_steps=4, и не применялись отсечение по остановке и фильтрация по эталонному пути и цели. Эти параметры окна будущих кадров относятся к другим путям модели, и нельзя по названию судить, что они управляют текущей веткой данных.

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

4. Базовая модель и реальная выгода от переноса без обучения

Сначала использовали CMA-CLIP [базовая модель кросс-модального внимания и текстово-визуальных представлений], затем подключили InternVLA-N1-DualVLN. Последняя использует двухсистемную схему: верхний уровень на основе зрения и языка обновляет навигационное решение, а модуль локальной траектории исполняет движение. При переносе нужно и подключить модель, и согласовать робота, камеру, чтение сцены и интерфейс действий.

Таблица 3. Ранние отправки на онлайн-оценку с номерами, в процентах.

Переход с 32.0% до 48.7% по подробным инструкциям дал +16.7 процентного пункта, а грубые инструкции при том же переносе не выиграли. Поэтому мы сохраняли отдельного кандидата для каждого типа инструкций, а не считали «модель крупнее — значит лучше во всех задачах».

Позднее готовили комбинированный пакет «грубые 46.0% соавтора + подробные 48.7% локально», среднее арифметическое примерно 47.35%. Это расчётная оценка: в имеющихся записях нет квитанции на такую комбинацию. У соавтора тогда уже была подробная оценка 59.3%, значит при обмене файлами надо обмениваться и номерами отправок, и версиями весов, иначе лучший результат может быть заменён старой версией.

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

В начале переноса модель постоянно выдавала поворот влево. Диагностика на 10 задачах показала, что все 10 изображений, которые получала модель верхнего уровня, были полностью чёрными. Причина: читатель сцены искал только <scan>.usda, а в локальных ассетах входной файл назывался start_result_navigation.usd. После исправления пути все 10 входов перестали быть чёрными, и действия стали разнообразными вместо повторяющегося поворота влево.

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

Камеру тоже нужно выравнивать с официальными ассетами. Когда стал доступен h1_internvla.usd, мы стали использовать torso_link/h1_1_25_down_30. Прежний torso_link/h1_pano_camera_0 нельзя считать эквивалентным входом: одинаковое разрешение не означает одинакового ракурса.

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

Для проверки мы использовали путь трассировки лучей высокого качества, а затем добавили в официальный оценочный путь render_profile='pathtracing_fast', что уменьшило постоянное вращение и исчерпание числа шагов. Поэтому план «все официальные оценки в быстром режиме» нельзя записывать как итоговую конфигурацию. Обучающие, проверочные изображения и демонстрационные видео нужно регистрировать отдельно, а сравнение моделей вести при одинаковой конфигурации рендеринга.

6. Десять успешных прогонов из десяти не означают полный балл

Одно дешёвое изменение — уменьшение интервала перепланирования движения вперёд с 8 до 4 — при сохранении исходных весов и максимального числа шагов повысило успешность на фиксированных 10 проверочных инструкциях InternNav с 60% до 100%. Выглядит очень убедительно. Но при расширении до 50 инструкций рост составил только с 48% до 50%, то есть одна дополнительная успешная задача.

Таблица 4. Влияние масштаба и цепочки оценки в одной и той же серии переноса.

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

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

На официальном окружении замечена и долгая задержка оценки. Разбиение на части с перезапуском снижает влияние одного длительного процесса, но при восстановлении нужно убирать дубликаты по идентификатору задачи и убедиться, что все задачи, которые должны быть проверены, выполнены. Один прогон из 50 инструкций мы завершили двумя восстановлениями через start_eval_chunked.sh; это не то же самое, что 12 экспериментальных инструкций, которые мы остановили сами.

7. Неудачи дообучения информативнее, чем кривые потерь

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

Таблица 5. Ветки обучения и локальные результаты проверки.

Последняя строка в основном отражает короткие траектории и ранние остановки. В записях сказано, что мы остановили прогон сами из-за низкого качества; нельзя писать, что «прогон дошёл до 50 задач и симуляция упала». Даже после прохождения проверки на 10 задачах результат может сильно упасть: причина может быть в недостаточном покрытии, а может и в том, что модель выучила неподходящую стратегию остановки.

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

8. Как работать вместе: многокарточное обучение и станция рендеринга

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

В совместной работе встретились две конкретные ошибки, которые стоит запомнить.

Первая — в функции set_model(): скрипт запуска передавал tune_lm_head=True, но функция связывала обучение выходной головы языка с веткой tune_mm_llm и не читала этот отдельный переключатель. После исправления нужно печатать имена обучаемых параметров и проверять, что фактическое состояние совпадает с конфигурацией. Написать «включено» в конфигурации — ещё не доказательство обучения.

Вторая — при экспорте из DeepSpeed ZeRO [технология шардирования состояний оптимизатора и параметров]. То, что пакет загружается через from_pretrained(), не означает, что все веса содержат правильные значения. В первом экспорте из 1 338 тензоров у 758 доля нулевых значений превышала 99%; исходные веса на том же кадре давали действия, а экспортированный пакет выдавал повторяющиеся бессмысленные символы. Сначала надо исправить агрегацию и сохранение весов, и только потом обсуждать качество обучения.

Исправленный адаптер содержит 615 обучаемых тензоров, примерно 680,9 млн параметров, основной файл — около 1.36 ГБ. Его нужно загружать после исходных весов DualVLN и перезаписывать им обучаемые параметры; каталог, содержащий только приращения, нельзя напрямую считать полной моделью.

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

9. Что остаётся после отправки и архивирования

Перед отправкой проверьте внутренние имена в архиве, число задач, уникальные идентификаторы, пустые траектории, нефинитные координаты и поля траекторий. В наших сохранённых результатах полем траектории служит reference_path; нельзя переименовывать его в другое только потому, что название похоже на «эталонную траекторию». Ориентируйтесь на официальный контракт сериализации.

Если у тестового разбиения соревнования нет локальной истины о цели, число not_reach_goal в локальном журнале нельзя трактовать как число онлайн-неудач. Проверки без истины показывают, что траектории корректны; реальный результат даёт только квитанция онлайн.

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

Сопутствующий скрипт проверки пакета использует только стандартную библиотеку; он проверяет структуру файлов и корректность траекторий и не считает успешность навигации. Запуск в любом терминале с установленным Python:

python code/inspect_submission.py /path/to/submission_overall.zip

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

10. Источники воспроизведения и лицензии

• Официальный репозиторий VLNVerse: базовая модель, симуляция и точки входа в оценку; опыт относится к экспериментам июня–июля 2026 года, при воспроизведении нужно зафиксировать версию кода.
• Официальная инструкция по подготовке данных: исходные ассеты и целевые каталоги.
• Официальные обучающие данные и официальные жилые сцены: источники исходных данных.
• Исходная модель InternVLA-N1-DualVLN и документация по обучению InternNav: двухсистемная модель и справка по обучению.
• Страница соревнования: онлайн-задачи и результаты.

Лицензия официального кода и лицензия сцен и данных различаются. По описанию репозитория соревнования код распространяется по лицензии MIT [разрешительная лицензия], а сцены и данные — по CC BY-NC-SA 4.0 [атрибуция, некоммерческое использование, распространение на тех же условиях]. Модели и ассеты роботов подчиняются условиям своих авторов; лицензия этого учебного материала не распространяется на них.

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