Список проблем и решений
Решения здесь делятся на три класса:
- проверенное исправление: есть явный повторный тест или официальная квитанция;
- инженерное смягчение: снижает риск, но не доказано, что повышает онлайн-балл;
- непроверенная гипотеза: наблюдается корреляция, но причинно-следственная связь экспериментами не установлена.
1. Файлы данных полные, но смысл данных ещё нужно проверить
Проблема
550 обработанных файлов по количеству верны, модель обучается, но всё ещё возможны сдвиг времени action/qpos, неверный порядок трёх камер, смешение профилей экспертов или несогласованность паттернов действий в траекториях rescue.
Проверенное исправление
Введён строгий аудит: проверяются набор файлов, 16-D, метаданные левой и правой руки, конечность значений, одинаковая длина трёх камер и покадровое выравнивание next-state. У канонического набора processed550 next_state_max_error=0, SHA manifest зафиксирован.
Что ещё нужно улучшить
Каждую разметку layout — конфигурацию сбора, модель объекта, позу, yaw, профиль эксперта, источник stock/retry/rescue — нужно закрепить в отдельном manifest. Не следует маскировать пробелы в покрытии суставов одним общим числом эпизодов.
2. Высокая доля rescue может искажать распределение
Проблема
В exact550 rescue = 257, то есть доля высока. Траектории rescue решили задачу покрытия и записи на диск, но могут иметь другие фазы вмешательства, скорости, позы концевого эффектора и временные профили действий.
Инженерное решение
Оставили канонический набор canonical550 без изменений, чтобы не менять данные, вес gripper и выборку одновременно за несколько дней до дедлайна. Отдельно собрали clean50 для диагностики, чтобы проверить, может ли самое чистое подмножество быстро замкнуть цикл.
Границы вывода
Разница между clean50 и exact550 подтверждает, что распределение данных стоит изучать, но не доказывает, что rescue — единственная причина низкого онлайн-результата. Дальше нужна абляция stock/rescue с одной переменной, той же архитектурой, тем же seed и той же топологией оценки, а проверка — на новой панели seed.
3. Недостаточно шагов обучения — низкий loss этого не скрывает
Проблема
Официальный ACT рассчитан на 6000 эпох, но основная линия завершила только до e1250, а затем пробовали направления e1500/e1750/e2000. Короткое дообучение у самого дедлайна не заменяет полного обучения с нуля и не гарантирует эквивалентность состояния оптимизатора, порядка данных и статистик нормализации.
Проверенные факты
Участок до e1250 нормально завершился как 1000/1000 этапа и не был OOM. Причина остановки — заданный вручную предел этапа и ограничения аппаратуры и дедлайна.
Правильный подход
Заранее зафиксировать вычислительный бюджет 6000 эпох; каждые 250 эпох сохранять неизменяемый checkpoint; каждый полный checkpoint оценивать фиксированным fresh3 на пустом, чистом одиночном процессе оценки; выбирать кандидатов по успешности с фиксированными seed, а не только по loss обучения и валидации.
4. Обычный runner и runner с трассировкой дают разные баллы
Проблема
Для clean50 e6500 обычный fresh3 дал 0/3, 1/3, а диагностическая версия с трассировкой — 1/3, 5/9. Один и тот же вес даёт заметно разные результаты.
Вывод о причине
Версия с трассировкой монкипатчит run_act_eval.py, чтобы записывать границы действий и конечные состояния. Топологию запуска, порядок сброса, инициализацию и расход генератора случайных чисел нельзя автоматически считать такими же, как в официальном runner.
Решение
Обычный runner считаем официальными воротами; трассировку используем только для поиска стадии сбоя. Оба результата сохраняем рядом, не выбираем лучший, не усредняем и не отправляем высокий результат трассировки на онлайн.
Что сделать дальше
Для финальных ворот использовать persistent-процесс, совпадающий с организаторами: фиксированный порядок публичных seed, модель загружается один раз, путь сброса каждого эпизода совпадает с официальным. Если нужно изолировать зависание, можно запускать отдельные процессы для отбора, но их результаты нельзя напрямую считать финальным результатом.
5. Публичные seed локально и приватные seed онлайн сильно расходятся
Проблема
Контрольный кандидат дал локально fresh3 2/3, а онлайн T4 — 25.3/100. Публичные 3 успешных прогона не отражают среднее число уровней на приватных 100 seed.
Решение
Вводим уровни оценки: fresh3 — только для отсева явно плохих моделей и проверки интерфейса; fresh10/fresh20 — для стабильности кандидата; затем полная фиксированная публичная панель; кандидат также обязан пройти проверку пакета кода, checkpoint, статистик и предварительной проверки официального окружения.
Чего не делать
Нельзя выдавать за онлайн-успех один успешный прогон clean50 с трассировкой, воспроизведение обучающих траекторий, видео экспертных траекторий или «отсутствие ошибок». Нельзя после просмотра проваленных seed добавлять их в обучение и затем сообщать об улучшении обобщения на тех же seed.
6. Правильный аккаунт и подтверждение очереди отправки
Проблема
Однажды T4 был отправлен с другим аккаунтом, который был разблокирован только до более низкого трека, и сервер вернул 403. Затем вторая версия была загружена до дедлайна, но квитанция пришла уже после него.
Проверенное исправление
Перед отправкой проверяем только фрагмент токена для сверки, отправляем с аккаунтом, у которого разблокирован T4, и получаем однозначную квитанцию #719 T4 с submit_exit=0. Когда вторая версия получила ответ «приём закрыт», повторные отправки прекратили.
Что сделать дальше
Скрипт отправки должен сначала проверять статус разблокировки аккаунта. После загрузки обязательно сохранять официальный ответ сервера, идентификатор очереди, SHA на стороне сервера и отметку времени. Если квитанции до дедлайна нет, нельзя по факту «процесс ещё работает» считать, что отправка попала в очередь.
7. Граница пакета отправки и именование checkpoint
Проблема
Онлайн-оценка T2/T3/T4 поддерживает только официальные зависимости ACT и минимальный код участника. Если упаковать весь корень проекта, символические ссылки, wandb, исходные данные или дополнительные зависимости, пакет может быть отклонён при распаковке, не импортироваться или дать несоответствие конфигурации и весов.
Решение
Корень кода ограничиваем минимальным неизменяемым снимком external/robotwin_local; пакет checkpoint — только policy_last.ckpt и dataset_stats.pkl; отклоняем символические и жёсткие ссылки, выход за пределы каталога и лишние файлы; перед отправкой проверяем импорт ACT на смоделированной упаковке.
Что сделать дальше
Для каждого кандидата отправки фиксируем: SHA дерева кода, SHA конфигурации развёртывания, SHA весов, SHA статистик, список файлов пакета и ответ сервера. Не допускаем, чтобы семантика policy_best.ckpt, policy_last.ckpt или config расходилась между обучением, оценкой и загрузкой.
8. Официальное выравнивание действий и локальные изменения
Проблема
Загрузчик ACT в симуляционном пути использует семантику next-state. Если локально заменить action[max(0, start_ts - 1):] на action[start_ts:], это выглядит как потеря одного кадра, но на самом деле меняет цель каждого обучающего примера.
Решение
Основная линия зафиксирована с action shift=0, и исходные данные проверяются аудитом action[t] == qpos[t+1]. Любой эксперимент с выравниванием использует отдельное имя запуска, отдельные статистики и отдельный checkpoint, не меняя одновременно размер модели, вес gripper или выборку данных.
9. Отключение 4090 из-за недостатка средств и перенос на PRO 6000
Проблема
Удалённая 4090 отключилась из-за недостатка средств на счёте; обучение и оценка были прерваны. Попытки пополнить счёт, перезапуск, синхронизация окружения съели оставшееся до дедлайна время. Облачная PRO 6000 имела задачи других пользователей, ограничения по диску и вопросы принадлежности GPU.
Инженерное смягчение
- Включили докачку и после переноса проверяли число файлов, размер, SHA и импорт;
- для совместимого окружения Python 3.10 / PyTorch / SAPIEN / MPlib / cuRobo использовали проверяемый образ, а не пересборку в последний момент перед дедлайном;
- большие данные, checkpoint и журналы хранили отдельно, чтобы окружение не заполнило корневой диск;
- не занимали ресурсы других пользователей и не запускали несколько оценщиков SAPIEN на одном GPU одновременно.
Вывод
Это проблема доступности инфраструктуры, а не доказательство того, что качество модели определяется конкретной картой. В дальнейшем нужны постоянный диск, предупреждения о балансе, автозапуск с восстановлением и ежедневные восстанавливаемые checkpoint.
10. Приоритеты исправления после низкого результата
Если участвовать повторно, приоритет такой:
- сначала зафиксировать официальное окружение и постоянный оценщик;
- заново проверить покрытие суставов по layout/object/pose/yaw;
- полностью обучить на чистом официальном коде до заранее заданного горизонта;
- провести парную абляцию с одной переменной для rescue / retry / stock;
- кластеризовать сбои по времени захвата, подъёма, переноса и отпускания;
- подтвердить улучшение на независимой новой панели seed;
- и только потом упаковывать и отправлять.
Не рекомендуется путь, при котором эпохи механически доводят с 1250 до 2000, решения принимаются только по loss, выбирается единичный высокий результат трассировки или одновременно меняется пять переменных данных и модели.