Применение LLM для синтеза и стилизации поведений агентов
TLDR: Рассмотрим, как можно использовать LLM-ки для управления роботами и какие от этого можно получить преимущества.
1. Введение
В нашем предыдущем обзоре мы рассмотрели, как Reinforcement Learning (RL) помогает управлять сложными роботехническими конструкциями, такими как четвероногие роботы. Важную роль в здесь играет дизайн функции награды (reward) — именно награда определяет, какую задачу будет решать агент.
Функция награды в определенном смысле формализует задачу, которую будет решать RL-алгоритм, и, соответственно, целевое поведение агента, которого мы хотим добиться.
Дизайн функции награды сам по себе может стать отдельной сложной задачей. Эта задача становится ещё сложнее, если мы хотим добиться поведения, которое, с одной стороны, интуитивно понятно человеку, но с другой стороны едва ли возможно явно отобразить с помощью математических выражений в функции награды. RL чаще всего позволяет одновременно решить одну задачу — другими словами, научить робота одному навыку.
Возникает вопрос: можем ли мы безболезненно комбинировать эти навыки, а также синтезировать новые без обучения?
Конечно, для вышеперечисленных проблем у нас есть методы imitation learning, посвященные обучению политики, имитирующей демонстрации эксперта (им может выступать как какая-то другая политика, так и человек — в этом случае подразумевается наличие датасета демонстраций от человека). Из описаний видно, что главный недостаток этих методов — необходимость достаточного количества экспертных демонстраций, и собрать эти демонстрации, особенно если речь идет о реальных роботах, может быть довольно сложно.
На тему комбинации навыков (skill combination) работы существуют (например, первая и вторая), также, возможно, сюда подходит и Hierarchical Reinforcement Learning (тык на survey), но это все пока что, насколько мне известно, не особо исследованные в контексте роботехники направления.
Поэтому, вдохновившись показателями уровня знаний, заложенных в LLM, и их результатами в reasoning-задачах, исследователи задались вопросом:
Достаточно ли у LLM reasoning-способностей и знаний о нашем мире, чтобы синтезировать поведения роботов из только лишь текстовых описаний и, возможно, нескольких примеров (также только в форме текста), и если ответ "да", то как мы можем "соединить" LLM с роботом?
2. Reward Design with Language Models (Kwon et al., 2023)
Link
Начнем немного издалека, кратко рассмотрев данную работу из начала 2023 года. Авторы исследуют задачу формализации "неформальных" поведений агента в небольших текстовых играх на тему экономики и бизнес-переговоров с помощью LLM. Сами авторы называют подобных агентов objective-aligned agents. Пример поведений: быть более настойчивым в переговорах, или наоборот, более пассивным.
Идея заключается в том, чтобы использовать LLM, а именно, GPT-3, в качестве, как они сами её называют, прокси-функцией награды. Конкретно, предлагается следующая схема:
- Для текущей версии политики запускаем эпизод, и собираем данные с этого эпизода (episode outcomes) — как некий "лог" игры
- Конструируем
затравкупромпт для LLM. Этот промпт состоит из следующих блоков: - Описание задачи
- Примеры требуемого поведения
- Собранные данные с эпизода
- Вопрос к LLM о соответствии поведения из эпизода решению описанной задачи и приведенному в пример поведению. На вопрос можно ответить "да" или "нет".
- Из ответа LLM парсим награду. В данной работе рассматриваются только бинарная награда. Ответ "да" соответствует получению reward, ответ "нет" соответствует штрафу.
- На основе награды, обновляем политику с помощью любого RL-алгоритма (в данной работе использовался Deep Q-Learning)
По результатам авторы показали, что с помощью такого подхода вполне можно достичь уровня RL-агента, обученного с помощью ground truth-наград, и требует это меньше примеров в промптах, чем данных для supervised learning-бейзлайна. Целевых "стилизованных" поведений также удалось достичь (или, по крайней мере убедить в этом группу из 10 человек).
В целом, подход довольно интересный, но имеет один главный недостаток — учитывая, что источником награды являлась GPT-3, расширить такой подход на реальные роботехнические задачи: во-первых, скорее всего, нужна будет мультимодальная модель, и, во-вторых, скорее всего, обучение будет занимать очень много времени из-за инференса LLM (а на практике зачастую нужны тысячи и десятки тысяч эпизодов). Какие у нас есть альтернативы?
3. SayTap: Language to Quadrupedal Locomotion (Tang et al., 2023)
Link
В данной работе авторы рассматривают задачу управления роботом-собакой с помощью LLM. Управление подразумевает как выполнение простых команд, например, "Иди вперед" или "Иди назад", так и менее структурированных и более "стилизованных", как в предыдущей работе, например, "Радуйся, мы идем на пикник!" или "Осторожно, перед тобой белка, отойди!" (отличные видосики смотрите на сайте работы).
Предложенный подход состоит из двух главных блоков:
- Блок генерации паттерна (шаблона) походки на основе LLM: языковая модель на основе промпта генерирует шаблон, то есть некоторое описание походки для робота. Важно отметить, что этот блок не требует никакого обучения.
- Контроллер походки: принимает на вход сгенерированный паттерн и отвечает за то, чтобы робот двигался в соответствии этому паттерну. Данный блок обучается с помощью RL-я, во время обучения генерируются случайные паттерны.
Блог генерации паттерна, получив команду "Good news, we are going to a picnic this weekend", создает последовательность, говорящую роботу, что ты должен прыгать от радости :) Контроллер, принимая, этот паттерн исполняет его и мы видим, как прыгает робот
Паттерн походки имеет вид последовательностей из T (число дискретных шагов) нулей и единиц для каждой из ног робота, где 0 означает, что нога должна быть поднята, а 1 — что она должна касаться земли. На рисунках выше ноги обозначены как FL — front left (передняя левая), FR — front right (передняя правая), RL — rear left (задняя левая), RR — rear right (задняя правая). Имхо, чем-то это напоминает игру Guitar Hero :)
Теперь самое интересное — как эти паттерны предлагается генерировать. Авторы использовали GPT-4 и промпты, состоящие из следующих блоков:
- Общее описание задачи
- Общее описание того, что вообще такое походка, базовая классификация типов походок для робособак
- Общие правила генерации шаблона и походки и его формат. Здесь также указывается, что общая скорость тела робота задается дискретными значениями — это помогает обрабатывать неформальные запросы типа "быстрее" или "медленнее".
- Блок с примерами
В итоге, взаимодействие с человеком выглядит следующим образом:
- Пользователь вводит команду для робота
- LLM на основе базового промпта и введенной команды пользователя генерирует паттерн походки
- Сгенерированный паттерн походки "исполняется" контроллером походки.
Контроллер походки обучался с помощью PPO, в ходе обучения генерировались случайные паттерны в соответствии с определенным механизмом, позволяющим получить более-менее информативные и выполняемые сэмплы.
Предложенный подход показывает важные свойства LLM, касающиеся понимания "динамики" мира на основе лишь текстовых описаний. Однако, хоть с помощью данного подхода и получилось добиться интересных результатов по "стилизации" движения, его расширение на другие типы роботов или на другие задачи в рамках роботов-собак, как отмечают авторы, ограничено за счет привязки предложенной структуры паттерна для узкого круга задач.
4. Language to Rewards for Robotic Skill Synthesis (Yu et al., 2023)
Link; пост в блоге Google Research
Данная работа также посвящена управлению и генерации навыков для роботов с помощью LLM, однако, помимо четвероного робота, рассматривается также управление манипулятором. В предыдущей статье "связующим звеном" между LLM и роботом выступал паттерн походки и соответствующий контроллер; в этой же работе таким звеном выступает контроллер на основе подхода Model Predictive Control (MPC).
В предыдущих постах мы уже упоминали MPC, и в целом он заслуживает отдельного поста, поскольку совмещение MPC и Deep Learning-методов тема довольно интересная. Для тех, кому прямо сейчас интересен более подробный разбор MPC — добро пожаловать в дополнительный раздел после заключения ( через идею шахмат вы легко поймете MPC).
Здесь же для краткости просто скажу так: MPC оптимизирует последовательность действий агента за счет минимизации функции стоимости (cost), либо максимизации функции награды (последняя формулировка используется реже, хоть и понятия взаимозаменяемы, но авторы пользуется именно ей). MPC не требует обучения — процесс оптимизации сам по себе является политикой, выдающей действия для агента. Но взамен для этой оптимизации требуется модель агента, и, в зависимости от задачи, среды.
Возвращаясь к статье, авторы предлагают связывать LLM и физическую платформу с помощью функций награды для контроллера на основе MPC: LLM генерирует набор функций наград, их весов и параметров, которые далее использует MPC (как финальная награда используется линейная комбинация из сгенерированных наград и их весов).
Обращение к LLM (в данном случае — GPT-4) состоит из двух этапов (в тексте это упоминается как использование двух LLM): Motion Description и Reward Coding. Вместе эту схему генерации авторы называют Reward Translator, а MPC-контроллер — Motion Controller.
Motion Description подразумевает описание требуемого движения робота. Цель — получить от LLM высокоуровневое описание движения робота в соответствии с заданным шаблоном. Промпт имеет следующую структуру:
- Шаблон, по которому должныо генерироваться описание движения (motion template)
- Разъяснения по шаблону и дополнительные правила для генерации (rules)
Reward Coder принимает сгенерированное описание движения с предыдущего этапа, и генерирует необходимые функции награды и их параметры. Промпт имеет следующую структуру:
- Описание доступных функций наград и их аргументов (reward API): предполагается, что у нас есть некая библиотека доступных функций наград и краткая документация к ней — за что какая функция отвечает и какие у неё есть аргументы. Задача LLM — подобрать нужные функции и значения их аргументов.
- Блок с примерами
- Блок с правилами для генерации
Как и в предыдущем случае, Reward Translator не требует какого-либо дообучения. Motion Controller на основе MPC также не требует обучения, но зато требует отдельной настройки, как в общем-то любой "классический" контроллер.
Тесты проводились в симуляторе MuJoCo на четвероногом роботе и манипуляторе, а также на реальном манипуляторе. Как показывают авторы, получилось достичь лучших результатов, чем с Code-as-Policies (об этом подходе речь пойдет далее).
Резюмируя, авторы предложили метод, позволяющий объединить мощь как LLM, так и MPC, причем предложенная схема является довольно универсальной. Из недостатков, и, соответственно, тем для будущих исследований, авторы отмечают сложности с "продвинутой" стилизацией движения, т.к. генерация сильно зависит от шаблонов, используемых в промптах, а также невозможность использовать изменяющиеся во времени (time-varying) награды.
5. Code as Policies: Language Model Programs for Embodied Control (Liang et al., 2023)
Link
Вообще, первая версия данной работы вышла раньше, чем Language-to-Rewards, но по смыслу, учитывая остальные рассматриваемые работы, будет удобнее поместить её после. Авторы предлагают применять LLM для генерации программ (такие программы они называют Language Model Programs — LMP) для роботов, использующих как first-party библиотеки (т.е. "внутренняя" библиотека с функциями и классами, касающимися непосредственно управлением роботом), так и third-party библиотеки (сторонние библиотеки, такие как NumPy, Shapely, и др.). В целом, идея заставить LLM генерировать код для решения какой-либо задачи, не связанной напрямую с программированием, не нова (см., например, ViperGPT и Toolformer). Одно из преимуществ такого подхода — код в общем-то является довольно универсальной и интерпретируемой формой, которая при этом явно предоставляет LLM информацию о возможностях целевой платформы (в частности, как мы увидим далее, за счет описания API и примеров в промптах).
First-party библиотека состоит из двух компонентов: Perception API — функции, касающиеся детекции объектов (в частности, использовались open-vocabulary детекторы ViLD и MDETR) и оценки состояния робота, и Control API — функции, касающиеся управления роботом. Важно отметить, что обе эти библиотеки написаны и затюнены людьми.
Задача LLM — сгенерировать код, который объединит perception и control модули (авторы называют это perception-to-control feedback logic) необходимым для достижения описанной пользователем цели.
Предлагаемый подход также подразумевает иерархическую генерацию кода, подразумевающую как простое использование API-функций, так и генерацию вспомогательных функций и их объединение в основной программе. LLM, использовавшиеся в работе — варианты OpenAI Codex и GPT-3.
Промпты довольно сложные. В основном состоят из подсказок (hints — по сути просто аннотации того, что делает пример) и примеров (examples). Примеры делятся на две группы: низкоуровневые (low-level) и высокоуровневые (high-level).
Низкоуровневые примеры показывают LLM, как работать с third-party и first-party библиотеками.
Из интересного — авторы говорят, что добавление постфиксов к переменным (например, _np для NumPy-массивов) помогает LLM понять, с какими данными она работает в соответствующей строке, что сильно улучшает качество генерации.
Также к низкоуровневым примерам авторы относят примеры reasoning-а, например, соотношение объектов с их описаниями.
Высокоуровневые примеры по большей части посвящены общей структуре кода и возможности иерархической генерации. Из важных моментов — авторы отмечают:
- LLM может использовать в генерации функции, для которых был описан только интерфейс, но не реализация, что потенциально это позволяет использовать две отдельные языковые модели, одну для реализации функций, другую — для композиции финальной программы.
- Использование возможностей иерархической генерации сильно улучшает качество генерируемого кода и перформанс робота в соответствующих задачах.
Оценка качества генерации кода проводилась на кастомных бенчмарках, и сгенерированные программы-политики запускались на реальных роботах, в частности, для решения задач манипуляции и навигации.
Предложенный подход частично похож на подход из Language-to-Rewards. Если в последнем был фокус на генерацию скорее псевдокода из списка функций наград и их параметров, то здесь происходит генерация полноценного кода.
Code-as-policies хорошо подходит для генерации высокоуровневого поведения робота, однако, сильно зависит от доступных Perception и Control API. Language-to-rewards же фокусируется скорее на автоматической настройке низкоуровневых контроллеров. В целом, кажется, что эти два подхода могут в будущем дополнить друг друга, позволив одновременно произвести тонкую настройку необходимых скиллов и объединить их в сложное высокоуровневое поведение.
6. Заключение
В данном разборе мы увидели, как можно построить "мост" между LLM и реальным железом. Предложенные подходы имеют разную степень универсальности, но одно из их главных общих преимуществ — возможность сократить потребность в обучении агента. Представленные результаты также говорят о том, что LLM способны производить некий reasoning относительно представлений о движении роботов. В будущем, как отмечают многие авторы, одним из главных направлений исследований в этой области станет применение мультимодальных моделей, которые позволят расширить промпты за пределы текстовой модальности.
7 Supplementary: подробнее про MPC
Дисклеймер: здесь будет много аналогий с RL-ем, поскольку в общем-то MPC и RL имеют общие корни, и некоторые относят MPC к model-based RL, но я все же считаю, что это достаточно сильно разные подходы.
Для начала, приведем небольшую аналогию. Представьте, что вы играете в шахматы. Чаще всего, вы планируете свои действия на несколько ходов вперед, на основе некоторых представлений — то есть модели — действий противника. Имея в голове план на несколько ходов вперед, вы, в соответствии с правилами игры, делаете лишь один ход. Далее, в зависимости от хода противника, вы либо придерживаетесь своего текущего плана, либо составляете новый план, если видите, что действия противника сильно отклоняются от ваших ожиданий. MPC работает по схожей схеме: его задача состоит в создании плана на H шагов вперед (либо H секунд, если мы работаем с непрерывной задачей) в соответствии с заранее известной моделью процессов. Обычно величину H называют горизонтом.
На изображении выше представлена базовая математическая формулировка задачи MPC (в дискретном и детерминированном случае; непрерывные и стохастические варианты MPC тоже существуют). Здесь векторы состояний (states) и управлений (controls) имеют те же значения, что и состояния и действия (actions) в RL-е — разница в названиях сложилась исторически. Состояние может включать в себя как непосредственно состояние агента, так и состояние среды, управления же обычно относятся только к агенту. Модель представляет собой математическое выражение того, как изменяется состояние агента (и, возможно, среды) в зависимости от приложенного управления. Эта модель может иметь вид как, например, простейших кинематических формул из школьного курса физики, так и сложную систему дифференциальных уравнений. Модель — это тот компонент, который считается неизвестным в model-free RL.
Следующий важный компонент — это функция стоимости (cost). Стоимость в MPC играет ту же роль, что и награда (reward) в RL — инкапсулируют нашу задачу. Функцию награды на два компонента: стоимость на этапе (stage cost), т.е. стоимость на каждом шаге горизонта, и финальную стоимость (final cost) т.е. стоимость в конечном состоянии горизонта, как показано на изображении выше, но это уже детали реализации.
Простой пример функции стоимости: расстояние от текущего положения робота до целевой точки в задаче навигации мобильного робота. На практике, правда, добавляются дополнительные члены, связанные с особенностями управления роботом, но об этих деталях мы, возможно, поговорим в отдельном посте.
Важно отметить, как именно происходит минимизация стоимости. Поскольку у нас в явном виде известны и функция стоимости, и наша модель, то у нас в общем-то есть вполне определенная задача оптимизации, и, соответственно, мы можем воспользоваться аппаратом методов оптимизации. Оптимизация в MPC — отдельная большая тема, поэтому пока что лишь кратко упомяну, что здесь довольно популярны алгоритмы выпуклой оптимизации и нелинейного программирования. Существуют также и альтернативные методы решения данной задачи, например, за счет динамического программирования или сэмплирования, но об этом, возможно, тоже в отдельном посте. Пока что важно усвоить отличие от RL-я: здесь мы не используем никакого обучения, а напрямую решаем нашу задачу минимизации стоимости в соответствии с используемой моделью.
Последний важный компонент в MPC — это ограничения (constraints). Использование методов оптимизации, многие из которых подразумевают решение задачи оптимизации с ограничениями, позволяет нам в явном виде учитывать ограничения системы, с которой мы работаем — это одна из главных причин, по которой MPC стал популярен в индустрии. В простейшем виде ограничения могут иметь вид, например, отрезков, в которых могут находится компоненты вектора управлений (конкретный пример — ограничения на управляющий сигнал скорости робота). Ограничения можно наложить и на состояния агента — возвращаясь к примеру с навигацией мобильного робота, мы можем наложить ограничения на положение робота для избежания столкновений с объектами на карте.
Выше мы упоминали, что на выходе MPC выдает план — этот план имеет вид последовательности управлений на H шагов вперед. На практике, из этой последовательности применяется только первое управление, после чего вновь начинается процесс планирования (вспоминаем пример с шахматами выше). Такая схема позволяет, с одной стороны, выработать управление, которое будет оптимально в контексте будущего, и, с другой стороны, быть более устойчивым к внезапным изменениям во внешней среде.