Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Исправления роботизированных навыков удалось переносить на новые длинные композиции без доработки кода под целевую задачу. Система Recursia на физическом роботе повысила среднюю долю успешных выполнений на 40 процентных пунктов, хотя препринт ещё не рецензирован и эти числа получили сами авторы. Работа предлагает хранить накопленный опыт в общем исполняемом коде, а не в отдельных сценариях или описаниях навыков.
Почему исправлять отдельный навык недостаточно
Навык может правильно взять предмет и всё равно сорвать следующую операцию. Например, робот завершит отпускание, но не отведёт захват; следующий навык начнёт движение из состояния, для которого его не проектировали.
Авторы выделяют четыре источника таких сбоев. В наборе инструментов может не хватать нужной операции. Инструмент может завершиться без требуемого физического результата. Один навык может оставить состояние, несовместимое со следующим. Наконец, проверка может принять незавершённую задачу за выполненную или нарушить уже достигнутый результат.
Recursia хранит эти механизмы в общем исполняемом стеке — наборе инструментов, навыков, переходов между ними и проверок результата. Навык получает явные предусловия, исполняемую программу, проверяемые условия завершения и пределы расхода ресурсов. Он возвращает не только признак окончания, но и наблюдаемые свидетельства результата с причиной остановки.
Переход между навыками вынесен в отдельный слой. Он проверяет готовность следующей операции и сохранность уже достигнутых отношений между предметами. Если предусловие не выполнено, исполнитель может заново осмотреть сцену, запустить ограниченное восстановление или остановиться.
Описание конкретной задачи остаётся декларативным: в нём перечислены объекты, места назначения, требуемые отношения и зависимости целей. Код инструментов и навыков в такой адаптер не помещают. Поэтому исправление общей операции может перейти в другую композицию без вставки частного обходного пути.
Как изменение попадает в следующую версию стека
Recursia анализирует трассу исходной задачи и ищет первое подтверждённое нарушение требования. Это позволяет отличить отсутствующую возможность от ошибки в существующем компоненте: в первом случае система добавляет инструмент, во втором исправляет инструмент, контракт навыка, переход или проверку.
За одну итерацию кандидат меняет только один выбранный участок стека. Сначала фильтр общности отклоняет ветвления по идентификатору задачи, номеру запуска, конкретному объекту или сцене. Затем проверка механизма выясняет, исправляет ли патч заявленный сбой. Изменения восприятия можно повторно проверить на записанных наблюдениях, а изменения движения требуют нового физического или имитационного запуска.
Прошедший эти этапы кандидат сравнивают с родительской версией на одинаковых начальных состояниях и при заранее заданном бюджете ресурсов. В стек попадает только изменение, которое улучшает выбранные задачи и не теряет слишком много ранее успешных случаев. Отклонённый кандидат не заменяет родителя, а принятый сохраняют вместе с версией кода, исходным сбоем и результатами проверок.
После разработки стек замораживают. Целевые задачи могут только вызывать его компоненты через свои адаптеры, но не ремонтировать код по результатам запусков. Базовая языковая модель внутри контролируемого сравнения также остаётся прежней: работа измеряет пользу от изменения исполняемых интерфейсов, а не от дополнительного обучения модели.
В симуляции стек улучшали на LIBERO-90, затем проверяли на десяти задачах LIBERO-Pro Long: по 50 начальных состояний дали 500 эпизодов для каждого вида возмущений. Физический опыт провели на Franka FR3 с Franka Hand и трёх целевых композициях; траектории целевой проверки не использовали для ремонта. Все опыты оставались в рамках одной конструкции робота, а при диагностике в симуляции применяли точное состояние среды, которое не передавали развёрнутому исполнителю.
Общий стек стоит включить в архитектурный план
На LIBERO-Pro Long Recursia достигла 28,4% успеха при изменении начальных позиций и 53,4% при изменении формулировки задачи. Это выше результата ASPIRE на 5,8 и 15,1 процентного пункта соответственно. На физическом стенде средний результат превысил вариант, который обновлял только текстовое описание навыков, на 40 процентных пунктов.
Промежуточные версии улучшались не монотонно: исправление локального механизма не всегда завершало всю задачу, а рост общего результата мог скрывать потерю ранее успешных состояний. Поэтому практический результат работы заключается не только в устройстве стека, но и в запрете принимать патч по одному агрегированному показателю.
Для команды, которая строит программируемого робота из повторно используемых навыков, меняется объект разработки. Версионировать и тестировать нужно не только планы задач, но и общие инструменты, условия входа и выхода, переходы и проверки физического результата. Адаптеры конкретных задач при этом остаются данными, а не местом для исправлений.
Такой подход можно заложить в систему поставки кода: сравнивать кандидата с текущей версией на одинаковых состояниях, ставить предел допустимым регрессиям и замораживать прошедший проверки стек перед эксплуатацией. Для переноса самого цикла улучшения на реальное оборудование понадобится надёжная диагностика через откалиброванные журналы состояния, внешние датчики или разметку, поскольку точное состояние симулятора там недоступно.
Источники
Иллюстрация: рисунок из статьи «Learning to Compose: Recursive Self-Improvement of Shared Executable Stacks for Zero-Shot Long-Horizon Robot Manipulation», Yangzhi Chen, Feiran Liu, Zishuo Wang и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
