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

Работа оказалась настолько сложной и интересной, что нам захотелось рассказать о ней большему числу людей, а не только тем, кто был на школе. Ну а чтобы контекст работы был немного понятнее, мы добавили в наше повествование небольшой обзор методов планирования (в том числе с помощью языковых моделей), а также распознавания речи. Надеемся, наш рассказ будет интересным и полезным. Погнали!

Часть 1. Введение

Как там поживает робототехника?

В наши дни одним из глобальных трендов является всеобщая роботизация. Из-за пандемии в роботизации нуждается множество быстрорастущих рынков, в частности электронная коммерция и логистика. Перемещение объектов и планирование  поведения  — это одно из самых естественных действий для человека, но попытки  инженеров и робототехников научить этому машину постоянно сталкиваются с трудностями. Задачи, которые часто кажутся нам обыденными — загрузка посудомоечной машины, уборка на столе, складывание белья — остаются невероятно сложными задачами для роботов и находятся на переднем крае исследований в области робототехники. Эта ситуация отражена в парадоксе Моравека, который утверждает, что высококогнитивные процессы требуют относительно небольших вычислений, в то время как для низкоуровневых сенсомоторных операций их требуется гораздо больше. 

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

Научить робота каждой из перечисленных способностей — это отдельная отрасль исследования. Интерес нашей команды был сконцентрировать исключительно вокруг планирования. Далее речь пойдет именно о нем.

Про задачи планирования и подходы к их решению 

Начнем с того, что такое планирование поведения? Это поиск последовательности действий (плана), ведущий к намеченной цели. Для решения такого сорта задач традиционно используют два подхода: классическое планирование (Planning) и обучение с подкреплением (Reinforcement Learning, RL).

RL основано на машинном обучении какой-либо модели, которая приспосабливается к поиску оптимальной среды. Для этого агент взаимодействует с ней или с её моделью. В этом случае еще говорят про использование model‑based подхода к планированию. «Model‑based» в RL означает, что агент строит модель среды (то есть, грубо говоря, оценивает матрицу перехода из одного состояния в другое). Альтеранива — это model‑free‑подходы (например, DQN), в которых агент вместо этого использует нейросеть для аппроксимирования функции Q‑значений.

В классическом планировании, наоборот, обычно известна модель среды. То есть мы очень подробно описываем среду, как будут взаимодействовать объекты между собой, какие действия мы можем применять. В таком подходе агент взаимодействует уже не с самой средой, а с ее моделью. Однако предполагается, что в Planning она должна быть довольно точной.  

Но в прошлом году исследователи предложили третий подход к планированию, основанный на применении больших языковых моделей (Large language models, LLMs). Их применение нельзя отнести ни к одному из упомянутых подходов. С одной стороны, у нас в явном виде нет обучения модели, которое некоторым образом выучивает стратегию для агента. С другой стороны, у нас вроде бы есть модель среды, но мы не можем сказать, что это модель полная. То есть она какая-то есть и мы надеемся, что она хорошая. Но не всегда это так.

Так почему же использовать большие языковые модели для планирования — это хорошая идея? На это есть две причины:

1. Для планирования нам всегда нужно сформулировать задачу, и во всех случаях мы можем использовать для этого естественный язык — это достаточно удобно для нас, кожанных меш людей. Обычно задачи сформулированы так, чтобы их понимал тот агент, с которым мы работаем: робот, система, и т.д. Сегодня агенты все чаще создаются в парадигме воплощенного искусственного интеллекта (Embodied AI), для которой характерно обучение через взаимодействие со средой. При таких условиях использование естественного языка естественно! 

2. Языковая модель уже содержит знания о мире, в котором будет планировать действия, и этих знаний достаточно, чтобы разбить задачу на подзадачи. 

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

Специализированные модели 

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

Минусом данного подхода является то, что модель необходимо обучать, а значит у нас в любом случае будут какие-то размеченные данные, даже когда мы работаем с языковой моделью (LLMs, напомним, учатся на неразмеченных данных!). Если же появляется новая задача, то модель надо переобучать, что делает seq2seq весьма неудобным. 

Другой специализированный подход — это использование шаблонов. Если у нас количество задач не очень большое, и они довольно простые, мы можем подготовить специальные шаблоны, которые содержат языковые инструкции в нужным образом структурированных формах. Так, например, поступили авторы модели под названием FiLM, которая позволяет извлекать из текстового запроса объекты взаимодействия и быстро создавать план на основе шаблонов-модулей. 

На практике подход с шаблонами хорошо работает только для простых случаев. Например, когда вы общаетесь с Яндекс Алисой и даете ей какие-то команды, ваши слова понять не сложно: вы попросили включить музыку — запускается шаблон, музыка играет. Но когда вы даете задачи, связанные с ориентированием каких-либо агентов в пространстве вашего дома, готовых шаблонов может не хватать.

Часть 2. Планирование с помощью LLM

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

Авторегрессионная генерация

Первыми, кто попробовал использовать LLM для планирования были уже упомянутые выше американские исследователи. В статье под названием «Language Models as Zero‑Shot Planners» они применяли принцип авторегрессионной генерации. Для этого предобученная модель принимала на вход промпт, а на выходе выдавала законченный план действий для агента. Авторы провели серию экспериментов в среде VirtualHome, в которой управляли аватаром человека, заставляя его делать привычные для нас вещи вроде бритья или использования лосьона. Из-за этого планирование было довольно коротким и, по понятным причинам, к роботам пока не применимым.

В какой-то момент ученые столкнулись с тем, что модель начала «галлюцинировать»: вместо названий объектов или действий использовала синонимы, из-за чего агент делал совсем не то. Тогда авторы предложили генерировать план не сразу от начала и до конца, а шаг за шагом, подправляя его на каждом шаге генерации таким образом, чтобы он соответствовал тем действием, которые робот может выполнять

Так как генерация происходит на естественном языке, они взяли другую LLM-модель, которая, по сути, считала эмбеддинги (то есть, векторное представление) для полученного шага. Алгоритм хранит эмбеддинги всех действий, которые есть для нашего робота в кодовой базе. На этапе подправки плана он сверяет с ней действие, которое сгенерировала модель, и, в случае необходимости, заменяет его. Такая пошаговая авторегрессионная генерация плана — как её назвали ученые — работает гораздо лучше.

Ранжирование действий с помощью SayCan (Subtask Evaluation Mode)

Другой подход, который носит название SayCan, был предложен коллаборацией стартапов Robotics at Google и Everyday Robots. Его название — это сокращение принципа «Do As I Can, Not As I Say», а архитектура представлена на картинке ниже:

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

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

Для того, чтобы получить значения выполнимости действия, используется обратная связь от среды. Для этого предлагается специальная affordance-функция (может быть различной для разных действий), которая выдает число от 0 до 1. Например если объект на сцене отсутствует, то все действия с ним получают маленькую оценку и их приоритет занижается.

Мультимодальная модель PaLM-E

Весной этого года все те же специалисты из Google вместе с коллегами из Берлинского технического университета предложили применять для планирования воплощенную мультимодальную языковую модель PaLM-E (An Embodied Multimodal Language Model). Для этого они взяли большую языковую модель PALM на 540 миллиардов параметров, и добавили в нее токены изображения. То есть идея в том что, картинка от внешней среды, представление которой они получали с помощью Vision Transformer c Q-Former из BLIP-2 ввиде некоторых эмбеддингов, подмешивается в текстовый запрос. Таким образом это позволяет модели, грубо говоря, видеть и уметь интерпретировать визуальное окружающее представление. 

В статье, посвященной PALM‑E, помимо задачи планирования решаются еще и другие: Visual Q/A, Captioning, Task and motion planning, — другими словами, авторы развивали комплексный подход к проблеме управления действиями роботом. В работе произведена тонкая настройка модели, что показало её превосходство над чистыми (или, если угодно «ванильными») представлениями. В конечном итоге, исследователи показали, что дополнительная визуальная информация, используемая для обучения, дает прирост к точности планирования нижнеуровневых стратегий, которые могут перевести описание действий в команды робота.

Наша мотивация

Перед началом выполнения проекта мы внимательно изучили существующие методы планирования с помощью LLM, про которые сказано выше. Нам показалось, что большинство из них очень топорные и весьма не оптимизированные. А при масштабировании на большее количество команд, расширение на более экстравагантные задачи или выполнении операций на ранее невиданных местностях, точность и качество существующих алгоритмов страдает. 

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

В результате мы с ребятами реализовали целый фреймворк, который закрывает вышеуказанные проблемы. Для этого мы взяли наиболее перспективные подходы, такие как PALM-E или miniGPT4, поигрались с ними и предложил на основе них свое решение: иные языковые модели (лучше по качеству инференса ответов), иные архитектурные части, такие, например, как модальность картинок, дополнительные возможности тонкой настройки под конкретные задачи. Наконец, во имя юзер-френдли интерфейса мы прикрутили распознавание речи. 

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

Часть 3. Описание данных 

В качестве основы для нашего исследования мы выбрали Language-Table Dataset от Google. Такой выбор был обусловлен тем, что этот датасет успешно использовался при обучении модели для решения аналогичной задачи PaLM-E.

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

Эпизод — это команда, подаваемая роботу, вместе с коротким видео, разделенным на отдельные фреймы. Хотя логично было бы ожидать наличие текстовых инструкций или указаний к каждому фрейму, этой связи изначально не было. Впоследствии мы поняли, что авторы PaLM-E дополнительно его аннотировали: каждая команда была разбита на микрокоманды, и количество микрокоманд соответствовало количеству фреймов в эпизоде. Это усложнило нам задачу, поскольку изначально предполагалось подавать на вход в языковую модель мультимодальные данные: фрейм и соответствующая микрокоманда, а получать на выходе инструкцию для следующего шага (фрейма). 

Чтобы продвинуться дальше, нам нужно было использовать аннотацию как у них (то есть, разбивать на микрокоманды) или свой вариант аннотации (об этом ниже).

Кроме того, обнаружилось, что эпизоды в датасете не следовали друг за другом последовательно, и их необходимо было объединить. Мы предположили, что последний фрейм одного эпизода можно склеить с первым фреймом следующего с использованием метода среднеквадратичной ошибки (MSE), однако эта гипотеза не подтвердилась. Также, стоит отметить, что один из «недостатков» данного датасета заключался в том, что он был представлен в формате tensorflow records. Этот формат данных не поддерживается «из коробки» в PyTorch и, поэтому, требовались дополнительные преобразования данных для совместимости с PyTorch.

Что касается дополнительной аннотации фреймов, это был крайне ресурсоемкий процесс, который мы решили отложить на самый конец. Мы выбрали собственный подход, который заключался в записи координат местоположения объекта на каждом фрейме. Суть идеи заключается в том, чтобы представить стол (то есть пространство, в котором оперирует робот) в виде 2D координатной сетки и обучить языковую модель предсказывать не инструкцию, куда нужно поместить объект, а координаты центра местоположения объекта, куда робот должен его разместить. Иными словами, вместо того чтобы говорить модели «поставь объект туда», мы говорим «вот координаты объекта», и модель должна предсказать, куда переместить объект.

В конечном итоге, в результате работы с датасетом Language-Table от Google мы сделали несколько важных шагов:

1. Изучили датасет Language Table и убедились, что для работы с ним необходимо проводить дополнительную аннотацию фреймов как авторы в статье про PaLM-E.

2. Обнаружили, что эпизоды в датасете Language Table идут не по порядку и их необходимо дополнительно сортировать.

3. Написали Torch Dataset, который подгружает Language Table датасет в формате tensor flow records.

4. Предложили аннотацию данных не по «инструкциям» для каждого фрейма, а по «координатам».

Часть 4. Описание бейзлайна 

Теперь расскажем о бейзлайне моделей, которые нам удалось реализовать в рамках проекта.

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

Первым делом нужно определиться с методом генерации плана. Мы имплементировали 3 способа — генерация полного плана, итеративная генерация плана и Saycan. Выше мы подробно о них рассказывали. Если вкратце, то во время полной генерации плана, модель просто выдает ответ, который мы обрезаем до нашего стоп‑слова — «done», во время итеративной генерации шаги генерируются последовательно, заземляясь на доступные действия в среде, а подход SayCan использует ранжирование действий с помощью языковой модели. В последнем случае, однако, мы не использовали affordance-функцию, из-за отсутствия обратной связи со средой.

За работу с промптами у нас отвечал еще один важный класс — Processor. Его основные задачи — это взять пример из данных и превратить его в пример для модели, а затем распарсить ответ до структуры данных, для подсчета метрик.

Для работы с таким классом, как языковая модель, нужны 2 метода — обычная генерация текста и скоринг для подхода SayCan. В самом начале мы использовали обычную языковую модель LLAMA и большинство экспериментов провели на ней. В процессе выполнения проекта мы добавили к ней MiniGPT4, на вход которой вместе с текстом можно подавать изображение сцены, которое учитывается при генерации выходной последовательности. В качестве энкодера изображения в MiniGPT4 стоит Q-Former & ViT, а за языковую часть отвечает модель Vicuna, которая в свою очередь основана на LLaMA. Кстати, примерно в это же время появилась вторая версию LLaMA, которая на некоторых датасетах показывает результаты лучше/сравнимые с Vicuna. Мы попробовали поработать с LLaMA 2, запросили и получили веса и заменили языковую часть в MiniGPT4 на неё.

В качестве бейзлайна мы сгенерировали небольшой датасет на 300 планов, похожий на датасет из ALFRED (еще один из бенчмарков для задач по дому, выполняемых роботом, который использовали авторы упомянутого выше seq2seq-подхода), в котором задачей является перемещение какого-либо объекта в указанное место. 

Ну и наконец, стоит отметить классы метрик, каждая из которых вычисляет какую-то характеристику по исходному и предсказанному планам. В основном это LCS (Longest Common Subsequence) в различных вариациях: полностью верный план, наибольший непрерывный отрезок из правильных шагов, наиболее длинная подпоследовательность правильных шагов и все это еще раз, но учитывая только действия без аргументов.

Часть 5. Распознавание голосовых команд 

Одной из важных проблем во взаимодействии с роботом для, например, генерации плана, является создание интерфейса для задания ему команд. Наиболее доступным и интуитивным вариантом общения с роботом является голосовое управление, ведь оно не требует интерфейса ввода текста и даже умения писать или читать. Но оно затруднено наличием различных мешающих распознаванию речи шумов, как окружения робота, так и производимых им самим. Вариантом решения такой проблемы может быть создание модуля автоматического распознавания речи (Automatic Speech Recognition, ASR), устойчивого к шуму. Создание такого модуля также было частью нашей работы.

Сбор данных

Для создания такого ASR модуль требуются еще данные — теперь уже звуковые. В качестве набора данных по речи на русском языке в зашумленных условиях мы использовали Sber Golos Crowd, а точнее предобработанный вариант данного датасета, опубликованный на HuggingFace. К его преимуществам относится то, что многие записи в нем представляют собой фразы в повелительном наклонении — как раз такие и нужны для командования роботом. Существуют и другие датасеты по речи на русском языке, содержащие достаточно зашумленный материал из-за условий записи: Common Voice, Sova, rulibrispeech и др., которые мы не успели попробовать . 

Также нам были предоставлены 15 минут записи команд роботу в условиях его работы (шума запуска и передвижения) и 15 минут самого шума, что позволило проверить модели ASR в приближенных к реальным условиях, а также попробовать наложить шум поверх записей из Sber Golos, чтобы получить большее количество материала для проверки качества.

State-of-the-art ASR

Следующий этап нашей работы — это распознавание речи. Кратко поговорим о некоторых готовых API и модулей для этого, например: Whisper, Wav2Vec и т.д..

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

Wav2Vec — это модель ASR, хорошо себя показывающая в задачах распознавания речи в отсутствие больших объемов размеченного материала для дообучения. На HuggingFace выложены в свободный доступ многоязычные и англоязычные модели разных размеров.

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

Предобработка звука

Для очистки звука от шумов можно использовать объективные знания о природе речи, например, что частота основного тона голоса человека находится в диапазоне частот от 80 до 500 Гц — это позволяет, возможно несколько грубо, но очистить звуковой материал. Однако более тонких результатов можно достичь используя нейросетевые методы, такие, как: 

• модели обнаружения времени начала голоса (Voice Activity Detection, VAD), позволяющие избавиться от лишних пауз, которые могут содержать шум (например паузы хезитации: «Мммм», «Ээээ» и т.д.); 

• модели повышения качества речи (Speech Enchancement, SE); 

• расшумители (Denoiser), которые на основе нейросетей очищают голосовой сигнал от шума, основываясь на статистической информации о звуках речи и тех звуках, которые в речи встречаться не должны. 

Постобработка текста

Еще одним способом борьбы с шумом является улучшение выходного текста, с помощью, например, моделей проверки правописания. Идея данного подхода заключается в том, что модель распознавания речи может не иметь представления о грамматическом строе языка или словарном запасе языка или же допускать ошибки в случаях, когда звуковое представление слова не соответствует письменному (пример — «здрасте» вместо «здравствуйте»).

Доступным вариантом является API к YaSpeller — модели исправления ошибок на русском и других языках от Яндекс, основанной на алгоритме CatBoost. Существуют и другие методы, например основанные на генеративных нейросетях.

Эксперименты и метрики

Было решено провести несколько экспериментов с различными моделями распознавания речи и методами борьбы с шумом в зашумленных условиях, а затем и в условиях реальной эксплуатации робота. Для оценки качества распознавания использовались метрики WER (Word Error Rate) и CER (Character Error Rate).

WER — метрика, измеряющая частоту ошибок в словах, основанная на измерении расстояния Левенштейна между словами истинного текста и словами распознанного текста. Её значение, правда, может не отражать полностью качество распознанного текста в случае небольших орфографических или грамматических ошибок, поэтому часто вместе с ней используется метрика CER. CER — это метрика, измеряющая частоту ошибок в символах, по принципу идентичная WER.

В качестве проверяемых предобученных моделей распознавания речи мы решили попробовать устойчивую к шумам многоязычную модель Whisper-medium, а также русскоязычную Wav2Vec-large с и без языковой модели. Также попробовали VAD от Silero и YaSpeller.

Таблица 1. Оценки качества с разными методами борьбы с шумом

Из таблицы 1 можно заметить, что Voice Activity Detection не дал значительного прироста в качестве, и даже наоборот понизил его. Также использование языковой модели в дополнение к Wav2Vec незначительно повлияло на качество. Лучшим вариантом оказалось использование одноязычной модели Wav2Vec с автоматическим исправлением ошибок YaSpeller. 

Далее было решено проверить лучший вариант сборки на реальных данных и сборном датасете реальных данных с частью записей из Sber Golos. А также попробовать дообучить Wav2Vec на сборной части датасета. Суммарная длительность реальных данных — 15 минут, а обобщенной версии — 2 часа.

В таблице 2 представлены оценки качества распознавания речи на реальных данных и сборном датасете Wav2Vec без и с дообучением.

Таблица 2. Оценки качества на реальных данных

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

Демо и дальнейшее развитие модуля распознавания речи в шуме

В рамках времени, которое было предоставлено нам на проект на школе AIRI, мы реализовали небольшое демо ASR в дополнение к общему фреймворку. Оно опубликовано на Spaces в HuggingFace и используюет дообученную на зашумленных данных Wav2Vec и исправление ошибок с YaSpeller.

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

Хотелось бы отметить, что перспективными и часто используемыми являются методы Speech Enchancement для борьбы с шумом, поэтому в будущем хотелось бы поглубже в них погрузиться. Также отличных результатов по распознаванию речи можно достичь, используя Whisper больших размеров. Whisper, помимо прочего, можно было бы использовать для перевода команд с русского на английский, что позволило бы удобнее связать данную часть проекта с основной частью задачи команд роботу планирования его действий с помощью LLM, в которых используется преимущественно англоязычный материал. И конечно 15 минут записей с шумом робота — это очень малый объем для обучения или проверки качества. Запись большего объема или аугментация шумом робота большего количества записей могли бы дать больше возможностей для дальнейшего развития данного модуля.

Заключение и выводы

На то, чтобы реализовать все описанное выше и собрать его вместе у нас было всего две недели — ровно столько, сколько длилась школа (кстати, подробнее о том, как прошло это мероприятие, вы можете прочитать тут). Репозиторий проекта можно посмотреть здесь. В конце состоялась защита проекта, на которой мы заработали самые высокие баллы. Это была командная работа: каждый член команды внёс ощутимый вклад в создание фреймворка и в презентацию на защите. Даже этот текст мы писали вчетвером :).

Было очень приятно работать с нашим куратором от AIRI Алексеем Ковалёвым, который направлял нас при поисках решения, мотивировал на реализацию сложных частей и помогал с презентацией — огроменное ему за это спасибо! 

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

PS. По ссылкам ниже можно познакомится с нашими гитхабами и каналами

Николай (магистратура Сколтеха) — гитхаб

Арсений, (бакалавриат кафедры инженерной кибернетики МИСИС) — телеграм-канал

Михаил, (магистратура ИТМО) — гитхаб

Александр, (магистратура МФТИ) — гитхаб

Алексей (научный сотрудник AIRI, младший научный сотрудник ФИЦ ИУ РАН, ассистент Центра когнитинвого моделирования МФТИ) — телеграм-канал

Полезно также будет посмотреть лекцию Алексея Ковалёва, сделанную им на школе, которая как раз посвящена применению LLM в планировании.