Заземляем языковую модель на робота
Поздним вечером, вернувшись с работы, я отправился на кухню, чтобы приготовить ужин. Вернее, я собирался съесть то, что приготовил мой собственный домашний робот. А еще он разложил разбросанные вещи и убрал мое рабочее место. Звучит как начало фантастической книги, не правда ли? Роботы, которые готовят еду, подают инструменты и убираются в помещениях, — это кажется утопичным. Ведь роботы, принимающие самостоятельные решения — это лишь несбывшаяся мечта фантастов XX века… Сейчас мы покажем, что воплощенный ИИ скоро станет еще одной такой же обыденной технологией для нас!
Совместная команда Центра робототехники Сбера и студентов Кафедры инженерной кибернетики НИТУ МИСИС пришла к новому подходу к управлению роботами. Конечно же, готовить наш робот еще не может, однако сервировать стол уже способен. Вы скажите: «Ну это очередной робот-мороженщик!» Но нет.
Что было?
В конце XX века в массовой культуре все чаще упоминали человекоподобных роботов, и казалось, будто в скором времени, искусственный разум будет неотличим от человеческого, или хотя бы приближен к нему. Думаю, что не нужно рассказывать о функциональных возностях Вертера («Гостья из Будущего») или Электроника. И сам факт, что этих героев из фильмов вспоминают с улыбкой и по сей день, говорит о том, что для обывателя такие роботы все еще являются результатом фантазий.
Но тренд развития роботизации пошел в сторону промышленных роботов, не сервисных. Существующие сервисные роботы служили скорее символом технологичности компаний, нежели инструментом автоматизации процессов. Это связанно со многими факторами, но во многом ограничивающим является отсутствие разума у подобной машины. Сейчас каждое устройство в вашем доме является не более чем инструментом для решения детерминированной задачи. Они не способны к рассуждению, взаимодействуют с окружающим миром строго по заданному алгоритму, а набор функций заранее заложен на этапе разработки. В современных роботах с голосовым интерфейсом предписан набор интентов при вызове которых запускается процесс принятия решений, вариации бывают разные: МППР, Деревья Поведения, Конечный Автомат и др.
Мы же говорим про подход, позволяющий роботам не только выполнять задачи, но и адаптироваться в изменяющейся среде, принимая решения на основе анализа данных и обучения. Технология, которая решает задачу высокоуровневого планирования действий. Например, наш робот уже обладает базовыми навыками: взять предметы, положить предмет, передвинуть предмет, толкнуть предмет. Заставить робота выполнять такие, с виду простые действия, уже невероятно трудно. Но что делать, если их нужно объединить в последовательности? А если задача для робота поставлена не на алгоритмическом языке? Чтобы решить неформально поставленное задание в реальном мире нужно обладать способностью к логическому мышлению и иметь понимание что произойдет вследствие воздействия на среду.
К нашей удачи, именно сейчас фундаментальные модели находятся на пике «Кривой хайпа». Эти модели обучены на огромных массивах данных и могут быть применены для задач робототехники. К ним относятся и большие языковые модели (LLM — Large language Models). Мы хотим поделиться с вами тем, как нам удалось адаптировать подход команды Google Research для собственных задач, а еще, как мы сделали первый шаг в развитии Embodied AI в стране. В своих экспериментах мы вдохновлялись опытом команды Everyday Robots и использовали метод SayCan.
Пайплайн
Идея заключается в обучении робота примитивным навыкам, оцениванию возможности выполнения действий и выборе действия, приближающего исполнителя к глобальной цели.
Пайплайн можно представить следующим образом:
1. Человек ставит задачу голосом
2. Система распознавания речи транскрибирует речь
3. Система технического зрения составляет список объектов перед роботом
4. Генератор описания сцены предлагает возможные действия с предметами
5. Формулировка задачи и список объектов, предоставленных зрением, передаются в качестве промпта на вход языковой модели
6. LLM на основании собственных знаний оценивает каждое действие
7. Affordance-блок дает собственную оценку выполнимости каждого действия
8. Оценки affordance-блока и языковой модели сопоставляются и выбирается следующее действие
9. Выполнение базового навыка
Архитектура решения
Распознавание речи
Задача распознавания речи выходит за рамки данного решения, ограничимся тем, что мы использовали SaluteSpeech. Взаимодействие реализовано через gRPC: мы посылаем чанки аудио, получаем нормализованный текст. Также можно указать слова-подсказки, появление которых в речи вероятно. Распознанный текст в обязательном порядке переводится на английский язык.
Система компьютерного зрения
Система зрения робота состоит из двух модулей: детекция и сегментация.Команда исследователей из Google применила метод детектирования с использованием открытого словаря — ViLD. Мы в свою очередь используем связку моделей: Grounding DINO и Segment Anything (SAM). На вход подается список предметов, которые мы ожидаем увидеть, на выходе получаем маски объектов, находящихся перед роботом.
Пример детектирования и сегментации предметов по заданному промпту
Описание сцены
Идея подхода SayCan состоит в том, чтобы предложить языковой модели список тех действий, что может выполнить исполнитель. И в той формулировке, которую он может интерпретировать. Таким образом, мы решаем задачу «приземления»(англ. grounding) ответа языковой модели на возможности робота. Фактически, мы не просим LLM генерировать новые токены, лишь хотим оценить наши варианты ответа.
Промпт разделен на следующие блоки:
базовый промпт с несколькими примерами и установками
описание сцены перед началом эпизода
поставленная задача
список выполненных задач
одно из предложенных действий
Формулировка варианта действия выглядит так: pick_place ({pick_name}, {place_name})
В итоге получается промпт следующего вида:
Write each action as: pick_place(a, b).
Separate actions with a new line.
At the end of the work, type "done()".
There are: blue block, red block, … on the scene.
…
Solve the task: place blocks into the plates of appropriate color.
pick_place(red b lock, red plate) – выполненное действие
[pick_place (red block, green plate), pick_place (blue block, green plate), pick_place (blue block, blue plate), pick_place (fish, blue block), …, done ()] — список предложенных вариантов
LLM
Мы используем самую маленькую модель LLaMA-7B, завернутую в OpenAI–совместимое API. Для сокращения времени инференса используется кэширование. В кэш попадает весь промпт кроме вариантов действий. Также, выгодно использовать batch–инференс, так как длина последовательностей токенов схожа.
Из модели мы получаем список логарифмических вероятностей (logprobs) для всего промпта. На него мы накладываем маску, отсекая logprobs для базового промпта. Этот список пересчитывается в единственное число и передается дальше по стеку. Таким образом, на выходе получется таблица:
pick_place (blue block, blue plate) — 27.178297
pick_place (blue block, red plate) — 27.121231
pick_place (red block, blue block) — 26.812892
pick_place (blue block, blue plate) — 26.671289
pick_place (fish, blue red block) — 26.323421
done () — 25.234902
…
Считаю важным еще раз напомнить, что мы не просим языковую модель предложить собственный вариант и не используем сгенерированные ею токены. Мы лишь используем её для оценки предложенных нами же вариантов действий.
Affordance и планирование движения
В оригинальной статье разработчики постарались приблизиться к End-to-end подходу, когда affordances-scoring выполняется RL агентом. В открытой имплементации в симуляции они применили оценку на основе детекции объектов. А путь захвата планируется предобученной моделью CLIPort. Таким образом, оценка является дискретной.
Given this environment does not have RL-trained policies or an asscociated value function, we use affordances through an object detector.
Так как в нашем стенде используется двупалый захват, в отличии от присоски в симуляции, мы были вынуждены все же применить оценку возможности выполнения действия. Наша оценка строится на различных эвристиках, учитывающих данные с камеры глубины, но за планирование пути манипулятора отвечает MoveIt!. Планировщик пути возвращает значение fraction–процент траектории который возможно выполнить. Эту метрику можно принять в качестве оценки блока skill-affordnce. Если не удалось полностью спланировать путь, выполняется перебор точек в окрестности первоначальной и выбирается наилучший результат fraction.
Модуль skill-affordance
Итог
В конце, оценка языковой модели сопоставляется с оценкой модуля skill-affordance и выбирается действие, приближающее агента к выполнению поставленной задачи,
Таким образом, большая языковая модель выполняет задачу долгосрочного планирования, а ее ответы валидируются и «приземляются» при помощи данного подхода. Такое использование языковых моделей позволяет значительно расширить спектр решаемых задач, имея в основе небольшой набор примитивных навыков робота. А чем «умнее» модель, тем более логически-сложные задачи и разнообразные задачи она может решить без специальных усилий со стороны программиста.
Результат
Промежуточной целью текущего эксперимента была оценка, насколько языковая модель, обученная на массиве разнообразных данных способна решать задачи в ограниченном пространстве ответов. Порой, решение, предложенное моделью, может быть хитрым, иногда — неправильным. Приведу несколько удачных кейсов и расскажу про специфику промпта.
Вот пример, наиболее запомнившийся всей команде. Во время демонстрации после эпизода кубик оказался на синей тарелке, и следующее задание сформулировали как: «Положи селедку в ту тарелку, где лежит желтый кубик». Вот наглядная демонстрация действий робота:
Пример задачи
Напомним, модель не знает контекст сцены если сама не запросила действие, а после выполнения эпизода, поле «done actions» очищается. Поэтом она сначала переложила кубик, а затем положила к нему рыбку. И задача формально выполнена, хоть и в несколько действий. Строго говоря, иначе ее решить было невозможно.
К сожалению, не всегда модель верно трактует формулировку, либо вовсе ее не понимает. Например, задачу: «Собери (assemble) башенку из блоков» робот выполняет как и задумано, а вот при запросе: «Построй (build) башенку из блоков» модель может «галлюцинировать». Это дает понимание, что для языковой модели, казалось бы, синонимы, несут разный смысл и трактуются по-разному.
Интересно, что добавив в базовый промпт несколько примеров построения башенки, модель стала понимать последовательность выкладывания блоков. И она стала справляться с заданием: «собери башенку из кубиков так, чтобы красный блок оказался в основании».
С запросами с описанной последовательность действий формата: «Положи зеленый кубик на красный, а затем перенеси синий кубик на красную тарелку» и «Положи рыбку на все кубики по очереди» в большинстве случаев модель справляется без проблем. А вот задачи, на высоту башенки вызывают трудности. Если попросить построить башню высоты 2, модель выдаст два действия, построив башню из трех кубиков. На башню высоты 3, модель выдает три действия, соответственно башня состоит из четырех блоков.
Также мы заметили, что после выполнения атомарных действий вида: «положи красный кубик на зеленую тарелку», языковая модель продолжает выполнять другие действия, напрямую не относящиеся к выполнению задачи. От такого поведения частично удалось избавиться добавлением в промпт фразы »… after that stop.» Но возникла проблема преждевременного окончания работы на задачах с большим горизонтом планирования. Поэтому от такого чита мы отказались и придумали как понять момент окончания последовательности опираясь на историю значений перплексии.
Демонстрация нескольких экспериментов
