Diving into Minecraft Embodied AI: Exploring Recent Research in Team CraftJarvis
안녕하세요, 저는 마음에이아이에서 Senior AI Researcher로 근무하고 있으며 현재 WoRV팀에서 SketchDrive 기반 자율주행 상용화 프로젝트를 진행중인 정재윤입니다.
이번 글에서는 Minecraft 환경에서 수행중인 Embodied AI 연구에 대해 소개하는 시간을 가지고자 합니다. 최신 마인크래프트 AI 연구를 이해하기 위해서 필수로 알고있어야 하는 핵심 연구들을 가볍게 소개한 뒤, 이 분야의 선두주자라고 할 수 있는 CraftJarvis 마인크래프트 연구팀 논문을 위주로 이야기를 풀어가려고 합니다.
마인크래프트를 해보지 않은 분들도 누구나 이해할 수 있도록 간단한 설명이 사이사이 추가되어 있습니다. (팀원중에도 한분 계셨습니다...) 저도 아직 이 연구 분야를 이해하는 중이기 때문에 정확하지 않은 설명이 있을 수 있다는 점에 대한 너른 양해 부탁드리며, 피드백 및 커피챗이나 메일 항상 환영합니다.
시작하기에 앞서 이 글에서 Embodied AI/Embodied Agent라는 용어는 이전 포스트에서 최수환 연구원님이 적어주신 정의를 토대로 사용하고 있습니다.
"An agent that can behave and live in an environment."
이 정의에 따라 Minecraft environment 안에서 동작하는 agent는 Embodied AI라고 정의할 수 있습니다. 혹시라도 이러한 용어나 task에 익숙하지 않다면 아래 글을 한번 읽어보는것도 좋을 것 같습니다.
Suhwan Choi
Embodied AI for Minecraft Because...
연구자들은 왜 체스, 바둑, 아타리게임, 마리오게임, 스타크래프트 게임 AI를 넘어서 마인크래프트에서의 Embodied AI 연구로 넘어왔을까요?
Minecraft is hard to play
우선 앞에서 이야기한 다른 게임에 비해서 샌드박스 게임인 마인크래프트는 아직도 AI가 어려워하는 게임입니다. 그렇다면 왜 마인크래프트는 어려울까요? 그 이유는 아래와 같습니다.
- 참고할 만할 리플레이(인간이 보는 출력 화면과 함께 WASD, 마우스 이동 등 모든 인간의 입력이 기록된 데이터)가 없습니다. 여기서 중요한 부분은 "영상은 많지만 WASD, 마우스 이동 등 모든 인간의 입력이 기록되지 않았다는 점" 입니다.
- 샌드박스 게임이기 때문에 바둑, 스타크래프트와 같이 상대를 이긴다는 명확한 목표가 있지 않고, 다음 task로 뭘 해야하는지에 대한 정확한 정답이 나와있지 않습니다.
- 바둑에서는 한눈에 정세가 보이고, 이전에 뭘 했는지 쉽게 기억할 수 있으며, 마리오게임의 경우에는 앞으로 스테이지를 나아가기만 하면 이전 기억은 필요없습니다. 하지만 마인크래프트에서는 이전에 뭘 진행했는지/해냈는지에 대한 기억이 수반되어야 작업을 수행할 수 있습니다.
마인크래프트 플레이 영상은 차고 넘치기 때문에, 이런 World Model을 만드는데는 GPU만 있으면...
예를 들어 마인크래프트에서 다이아몬드 곡괭이를 만들기 위해서 필요한 지식이나 행동은 현재 플레이어의 상태에 따라서 천차만별이고, 제작을 위해 수행해야 하는 task가 상황마다 다릅니다.
다이아 곡괭이를 만들기 위해서는 다이아몬드가 필요하다 -> 다이아몬드 광맥은 지하에서 나오며 철곡괭이가 필요하다 -> 철곡괭이가 필요하면 화덕에서 철을 구워야한다 -> 인벤토리를 보니까 철이 있는거같은데 화덕은 없네? 제작을 위한 돌이 인벤토리에 없으니 돌을 구해야하는데 여긴 어디지? ... 여기 초원이니까 손에 들고있는 돌곡괭이로 아래를 파내려가면 돌이 나올거야!
이 상황에 해당하는 Task: 아래로 내려가서 돌을 캔다.
Minecraft has diverse biome(environment)
마인크래프트에는 평원, 눈내린 평원, 사막, 사바나, 숲, 정글 등등 다양한 바이옴(환경)이 존재합니다. 그렇기 때문에 같은 나무여도 색이나 모양과 같은 생김새가 다르기 때문에 다양한 환경에서의 실험이 가능합니다. (평원에서 학습한 모델이 정글에서도 잘 동작하는지 등 모델의 일반화 능력 검증 가능)
Minecraft has diverse task
오픈 샌드박스 게임을 추구하는 마인크래프트에서 할 수 있는 일들은 다양합니다. 몬스터 사냥을 할 수도 있고, 농사, 건축 등의 일을 할 수 있습니다. 그 중에서 VPT 연구를 시작으로 대부분의 연구들은 "다이아몬드 곡괭이"와 같은 정량적 비교가 가능한 목표를 선정해서 연구를 진행하고 있습니다. (다이아몬드를 캐는 미래에 도달할 확률, 얼마나 빠른 시간 안에 다이아몬드를 캐는지 등)
마인크래프트에는 다양한 태스크가 존재할 뿐만 아니라, 등장하는 몬스터의 종류, 제작 가능한 아이템, 그리고 아이템 제작을 위한 조합법 역시 매우 다양합니다. 이로 인해 모든 것을 사람처럼 수행하는 마인크래프트 AI를 개발하는 것은 여전히 도전적인 과제로 남아 있습니다.
이러한 이유로, 마인크래프트 환경에서는 계속해서 Embodied AI 연구가 활발하게 진행되고 있습니다.
Previous Work (Need to Know History)
최신 마인크래프트 AI 연구들을 더 잘 이해하기 위해, 먼저 주요 시초 논문들의 핵심 내용을 필요한 부분만 간략히 설명하겠습니다.
Previously on VPT
OpenAI에서 ChatGPT를 발표하기 이전에, MineCraft 플레이 영상을 이용해서 학습을 진행한 VPT(Video PreTraining) 모델을 발표했습니다. VPT는 이전 마인크래프트 연구들에 비해 월등한 성능을 보여줬기 때문에 매우 화제가 되었습니다.
VPT의 핵심중 하나는 대량의 마인크래프트 영상을 학습 데이터로 활용하는 것에 있습니다. 이 영상들은 키보드/마우스와 같은 인간의 입력(action)이 기록되지 않은 라벨링 되지 않은 데이터였습니다. 이에 VPT는 모델을 이용한 라벨링 방식을 통해 대량의 학습 데이터를 구축했습니다.
방식은 다음과 같습니다:
- 작업자들이 게임 화면과 키보드/마우스 입력(action)이 기록된
2,000시간 분량의 매우 비싼데이터를 제작합니다. - 이 데이터를 활용해 IDM(Inverse Dynamics Model)을 학습합니다. IDM은 과거와 미래의 게임 화면을 보고 현재의 action을 예측하는 모델입니다.
- 학습된 IDM 모델을 사용해 인터넷에서 수집한 약 70,000시간 분량의 마인크래프트 플레이 영상에 action 라벨링을 수행합니다.
- 라벨링된 데이터를 활용해 마인크래프트 환경에서 기본적인 행동 능력을 가진 Pretrain 모델을 학습합니다.
이 과정을 통해 사람과 유사한 방식으로 마인크래프트 환경에서 동작들을 수행하는 Pretrain 모델의 학습은 완료되었으나, 우리가 원하는 task를 수행하기 위해서는 LLM처럼 Fine-Tuning 과정을 통해 특정 task 수행 능력을 부여해야합니다.
VPT에서는 이러한 task 수행 능력을 부여하기 위해 인간이 집을 짓는 영상이나, 초반 튜토리얼 영상들을 활용한 Behavior Cloning 학습이나, 다이아몬드 곡괭이를 만들기 위해 필요한 각 단계에 리워드를 부여하는 Reinforcement Learning 학습을 진행했습니다.
이러한 학습을 통해 VPT는 기존 연구들에 비해 훨씬 더 높은 성능을 보였으며,이전에는 불가능했던 다이아몬드 곡괭이 제작 task에 대해서 2.5%의 확률로 성공하는 모습을 보였습니다. 하지만 VPT는 구조상 인간이 지시나 해야 할 일을 직접적으로 명령할 수 없으며(condition을 줄 수 없음), 어떤 지시를 따르는 모델을 만들기 위해서는 그 지시를 수행하는 데이터를 기반으로 추가학습이 필요하다는 단점이 존재했습니다.
Previously on STEVE-1
위와 같은 단점을 극복하기 위해서 STEVE-1 논문에서는 VPT를 활용해서 Instruction Following Minecraft Agent를 만들었습니다. STEVE-1에서는 visual goal을 condition으로 활용해서 모델에 인간의 지시를 전달하는 방법을 사용했습니다.
STEVE-1은 마인크래프트에 특화된 대조학습 모델인 MineClip을 활용했습니다. MineClip의 Video Encoder를 통과해서 visual goal embedding을 생성했기 때문에, 이에 대응되는 embedding을 Text Encoder로도 뽑아낼 수 있습니다.
하지만 학습할때 visual goal embedding을 condition으로 활용했기 때문에, video instruction이 아닌 text instruction을 모델에 전달하기 위해서는 Text Encoder를 통과한 text goal embedding을 visual goal embedding으로 변환하는 과정이 필요합니다. 이를 해결하기 위해 STEVE-1에서는 CVAE 아키텍처를 이용해서 textual goal embedding에 대응하는 visual goal embedding으로 변환하는 방식을 선택했습니다.
이렇게 Video/Text Instruction Following이 가능한 모델인 STEVE-1은 Instruction에 따라서 키보드/마우스 조작 수행할 수 있어, 개조된 VPT와 함께 후속 논문에서 종종 작은 Latency로 goal state에 따라 동작하는 Controller로 사용되기도 합니다.
Previously on Voyager
위에 다른 논문들이 키보드/마우스 동작까지 포함한 Low-level 제어를 End-to-End로 수행하는 반면, Voyager에서는 마인크래프트 API를 function call처럼 사용하여 동작을 수행합니다. Voyager 내부 코드를 살펴보면 mineflayer라는 자바스크립트 기반 마인크래프트 API를 활용하는 부분을 확인할 수 있으며, 이 API를 통해 특정 동작을 수행하는 자바스크립트 코드를 skill로 정의하고 있습니다.
Voyager의 파이프라인에서는 task 수해을 위해 skill로 표현된 일련의 동작을 함수 형태로 생성합니다. 이후 이 함수가 성공적으로 task를 수행하면, skill library에 저장되어 이후 다른 skill 제작에 재사용됩니다. Voyager는 이런 방식으로 LLM Agent처럼 function call을 통해 기본 skill을 호출하거나, 이를 바탕으로 task 해결에 필요한 새로운 skill을 제작합니다. 이는 reasoning이나 planning 부분을 GPT와 같은 LLM과 프롬프팅을 통해 처리하는 연구로, function calling agent나 code agent task라고 할 수 있습니다.
개인적으로, 그리고 팀 차원에서도 이렇게, Low-level 동작을 API에 위임하는 연구는 function call LLM Agent 연구의 범주에 벗어나지 않는다고 생각하며, 저희가 지향하고 있는 Embodied AI 연구와는 다르다고 생각합니다.
예를 들어, Combat Zombie와 같은 태스크를 End-to-End 방식으로 접근해려면 다음과 같은 방식을 수행해야 합니다. 먼저 planning(현재 무기가 있는지, 체력이 얼마나 남아있는지 등)을 통해 게임 화면을 분석하고 현재 상황에 알맞는 계획을 수립해야 합니다. 그런 다음, 분석 결과를 바탕으로 실시간 액션(키보드/마우스 입력)을 통해 마우스 트래킹 좀비의 위치를 추적하고, 키보드 동작을 통해 다가가며, 마우스 클릭으로 검을 휘두르는 복잡한 과정을 거쳐야 합니다.
반면, Voyager와 같은 API를 사용하는 마인크래프트 AI 연구에서는 보다 단순화된 접근 방식을 취합니다. planning 단계의 결과에 따라서 LLM이 "인벤토리 안에 무기가 있다면 든다" 또는 "가까이 있는 좀비에게 팔을 휘두른다"와 같은 함수를 호출하면, API 내부의 함수가 동작하며 자동으로 좀비에게 접근해 사정거리 안에 접근하자 마자 칼같이 칼을 휘두르는 방식으로 동작합니다. 이는 마치 치트와 같은 게임 플레이를 구현하며, 이러한 동작은 전부 게임 내 환경이기 때문에 가능한 일입니다.
따라서 저희 팀은 Voyager와 같이 Low-level의 동작을 API의 위임하는 연구보다는, 실제 환경에도 적용될 수 있는 End-to-End 방식의 연구에 중점을 두고 있습니다.
Previously on Ghost in the Minecraft
기존 RL-based method에서는 에이전트가 복잡한 목표(goal)을 직접 수행하는 구조를 가지고 있었습니다. 그러나 GITM에서는 이러한 구조가 복잡한 목표에서 낮은 성공률을 초래한다고 지적하며, LLM을 이용해서 복잡한 목표를 세부적으로 나누어 수행하는 방식을 소개했습니다.
예를 들어, "다이아를 캐자!"라는 목표가 주어졌을 때, 기존 방법에서는 에이전트에게 곧바로 "다이아 채굴"이라는 goal을 전달해 수행하도록 했습니다. 반면, GITM은 이 목표를 LLM Decomposer를 통해 세분화합니다.
"다이아 채굴"이라는 목표는 LLM Decomposer에 의해 나무 → 나무 곡괭이 제작 → 돌 곡괭이 제작 → 철 곡괭이 제작 → 다이아 채굴과 같은 단계로 분해되며, 분해된 sub-goal을 기반으로 전체 목표를 달성하기 위한 계획을 수립합니다. 에이전트는 이 계획에 따라 동작을 수행하며, 기존 방법보다 복잡한 목표에서 더욱 우수한 성능을 보였습니다.
Team CraftJarvis
이제 기본적인 Minecraft AI 연구와 흐름을 소개드렸으니, Minecraft Agent 연구를 주로 진행하는 CraftJarvis 팀의 주요 연구들을 살펴보겠습니다.
Team CraftJarvis: GROOT
첫 번째로 살펴볼 CraftJarvis 팀의 논문은 GROOT입니다. GROOT는 특정 목표를 수행하는 Gameplay Video를 입력으로 받아, 동일한 목표를 수행하는 Embodied AI 모델입니다.
GROOT의 아키텍처는 Encoder-Decoder 구조로 설계되었으며 학습 시에는 Input Video를 이용해서 Encoder에서는 goal embedding을 잘 뽑아내도록, Decoder에서는 이 goal embedding과 state에 따라서 action을 잘 수행하도록 학습됩니다.
위에서 소개된 VPT는 개조되어 GROOT의 Decoder로 사용됩니다. 원본 VPT 구조를 이용하면 observation만 받을 수 있고 goal embedding과 같은 condition을 전달할 방법이 없기 때문입니다. 따라서 GROOT에서는 VPT가 사용하는 Transformer-XL layer에 gated cross-attention dense layer를 추가하는 방식을 사용해서 goal embedding의 정보를 전달합니다. (key는 environment states, query & value는 goal embedding)
이렇게 학습된 GROOT는 추론 단계에서는 Reference Video를 이용해서 goal embedding을 추출하고, 이 goal embedding에 따라서 현재 환경에서 관찰된 observation에 따라 action을 수행합니다.
GROOT는 reference video를 Instruction으로 활용하기 때문에, 학습 데이터에 해당 영상이 어떤 goal을 수행하는지에 대한 text annotation이 필요하지 않다는 장점이 있습니다. 그러나 추론 시에는 명령을 내리기 위해 반드시 해당 명령을 수행하는 reference video가 필요하다는 단점이 존재합니다.
GROOT의 Action Space는 사람과 같이 마우스와 키보드 부분으로 분리되어 있습니다. 추가적인 디테일로는 null action, 즉 아무 행동도 하지 않는것을 방지하기 위해서 VPT와 같이 joint hierrchical action space를 이용했다고 합니다.
이렇게 아무 행동도 하지 않는 Action이 나오거나, 학습되는것을 방지하는 디테일은 생각보다 매우 중요합니다. 사람과 다르게 모델 입장에서는 아무 행동도 하지 않았다가 언제 다시 행동을 재개해야 하는지와 같은 기준이 명확하지 않기 때문입니다.
실제로 OpenVLA 논문의 Appendix-C를 보면 BridgeData라는 데이터에 all-zero actions(null actions)이 많이 포함되어있는데, RT-2-X 모델의 경우에는 이런 데이터를 정제하지 않고 그냥 학습했기 때문에 second-most-likelly action (top 2번째 action token)을 사용했다고 하고 있습니다. (이렇게 안하면 매번 첫번째 토큰이 all-zero actions가 나오게 되고, 이후 계속 동작하지 않고 멈춰있는 모습을 보인다고 함.)
Button Space는 모든 키보드 operation의 조합을 이용하는 동시에 마우스를 사용했는지에 대한 flag까지 총 8461개의 action이 있으며, Camera Space에서는 마우스 움직임을 121 action으로 discretize했습니다. 따라서 agent의 action head로는 8461(button space)/121(camera space) dimension을 사용하고 있습니다.
Goal embedding을 사용해서 Instruction을 Decoder에게 잘 전달하려면, 해당 goal embedding이 goal의 의미를 잘 내포하고 있어야 합니다. GROOT에서는 이를 확인하기 위해서 t-sne를 활용하여 goal space를 시각화했습니다.
시각화 결과는 세 가지로 나뉩니다. 맨 왼쪽은 랜덤하게 초기화된 video encoder를 사용한 goal space를, 중간은 GROOT로 학습된 goal space를, 오른쪽은 두 가지 goal state를 포함하도록 영상을 합친 경우의 goal space를 나타냅니다. 결과를 분석해보면, 랜덤 초기화된 encoder에 비해 GROOT에서 동일한 의미를 가진 goal끼리 더 잘 클러스터링된 모습을 확인할 수 있습니다. 또한, 두 가지 goal을 포함한 state는 각 goal 사이에 위치하며, goal embedding이 각 goal의 의미를 효과적으로 반영하고 있음을 보여줍니다.
이를 통해 GROOT의 구조에서 충분히 goal embedding이 goal의 의미를 내포하고 이를 기반으로 동작할 수 있다는 것을 확인할 수 있었습니다.
Team CraftJarvis: JARVIS-1
다음으로 살펴볼 것은 JARVIS-1입니다. JARVIS-1은 마인크래프트 테크트리를 이용해서 GITM과 유사한 방식으로 목표를 단계적으로 달성하며 진행합니다. 따라서 위에 소개된 영상에서와 같이 task를 최종 목표, goal을 최종 목표를 이루기 위한 서브목표로 두고 명령을 수행합니다.
위의 테크트리만 보더라도 레드스톤과 황금 아이템을 얻는 과정은 10가지 이상의 중간 아이템 수집이 필요한 어려운 task입니다. 그 중에서 다이아몬드 곡괭이를 제작하는 task도 어려운 task에 속하는데, JARVIS-1에서는 6%의 성공 확률을 보이며 VPT보다 더 높은 성능을 보이고 있습니다. JARVIS-1에서는 어떻게 이렇게 좋은 성능을 보이고, 다양한 아이템을 잘 만들 수 있었을까요?
JARVIS-1은 Situation-Aware Planning을 활용합니다. 현재 상황을 반영해서 계획을 세운다는 이야기인데 사실 인간의 입장에서는 당연한 이야기를 하고있습니다.
예를 들어 보편적으로 마인크래프트에서 침대를 만드는 일반적인 방법은 거미를 잡아서 실을 얻고, 양을 잡아서 양털을 얻는 것입니다. 여기서 인벤토리에 가위가 있으면 양을 깎아서 한번에 많은 양털을 얻을 수 있고, 현재 마을에 있다면 주민과 거래를 통해 침대 제작에 필요한 재료를 획득할 수 있습니다. 또 다른 예로, 특정 목표 광물을 캐던 도중 도구가 부서지는 상황이 발생한다면, 목표 광물을 캐는것보다 곡괭이를 다시 제작하는 작업이 우선적으로 수행되어야 합니다. (곡괭이를 만들지 않으면 광물을 손으로 캐게 되고, 영원히 얻지 못하는...)
사실 이건 새로운 방식은 아니며, Voyager랑 GiTM에서도 어떤 동작을 수행하다 발생한 error message를 피드백해주는 방식으로 실제 인간처럼 현재 상황에 따라서 목표는 같더라도 중간에 계획을 변형하는 부분이 구현되어 있습니다.
JARVIS-1의 아키텍처를 보면 Planner와 Controller 2가지 구조로 이루어져 있습니다. 여기서 JARVIS-1논문은 Controller는 건드리지 않고 Planner 부분을 주로 다루며 Planner 부분에 retrieval 과정이 추가되어 있습니다.
Planner에서는 어떤 task를 수행하라는 명령이 들어오면, Query Gen 모듈이 주어진 task를 이루기 위해서 필요한 reasoning을 진행한 이후, 여기서 도움이 될만한 성공 경험을 Multi-Modality Memory에서 검색해서 가져온 이후 이를 참고해서 계획을 세웁니다.
또한 task를 달성하기 위한 모든 시도가 Shared Multi-Modality Memory라는 체계 하에서 공유되고 있습니다. 이를 통해 첫 번째 시도에서 goal 달성에 실패한 경우, 실패 경험을 기반으로 다음 시도를 수행하는 self-improving이 가능합니다.
예제 사진을 보면 현재 상황과 task에 따라서 JARVIS-1이 task를 이루기 위해 어떤 sub-goal이 필요한지 정의합니다. 이후 sub-goal을 이루는데 성공한 경험이 memory 안에 있다면 그 경험을 활용합니다.
특히 Multi-Modal Memory에 성공 경험이 많으면 많을수록 모델 성능이 올라가기 때문에, 모든 성공 경험을 Memory에 task, plan, state와 함께 기록합니다.
JARVIS-1은 기존 논문들에서 자주 사용된 마인크래프트 X-ray나 Lidar 기능을 활용해 observation에서 우위를 얻는 방식과는 달리, 순수한 RGB pixel 데이터만을 사용하여 task를 수행합니다. 이를 통해 JARVIS-1은 인간과 유사한 방식으로 환경을 이해하고 목표를 달성하며, 보다 현실적인 상황에서의 Embodied AI를 구축했다고 할 수 있습니다.
실험 결과를 들여다보면 JARVIS-1은 다양한 바이옴(환경)에서도 잘 동작하고, Shared Multi-Modality Memory를 이용해서 Self-improving 능력을 보여주는것을 확인할 수 있습니다.
또한, JARVIS-1은 위에서 언급한 것처럼 Situation-Aware Planning을 활용합니다. 이로 인해 목표 달성에 실패한 경우, 실패에 대한 피드백을 받고 이를 기반으로 reflection(반성) 및 re-planning(재계획)을 수행합니다. 이러한 반복적인 개선 과정을 통해 JARVIS-1은 목표 달성의 성공률을 지속적으로 높이는 강력한 성능을 보여줍니다.
사실상 LLM Agent와 같이 Controller 부분은 기존 모델에 위임했기 때문에, Table2에서는 GPT나 ReAct같은 기법들과 성능을 비교하고 있습니다. 이 논문에서 Voyager와 GiTM을 비교하지 않은 이유로는 아키텍처적인 차이가 있기 때문에 비교하기 어렵다고 합니다. (GITM의 경우 observation으로 LiDAR를 사용하는 등 구현이 많이 다름) 이후 LLM 성능에 따라서 성공 확률이 올라가고, GPT4를 사용했을때 가장 좋은 성능을 보여주는것을 확인할 수 있었습니다. (LLaMA2 Pre-Trained 모델은 왜 성능 비교 대상으로 넣은건지는 이해가 가지 않습니다.)
성공 경험을 저장하는 Multi-Modality Memory가 크면 클수록 더 어려운 task에 대해서 더 높은 성능을 보여준다는 것을 확인할 수 있었으며
Memory를 사용할때 어떤 방식으로 retrieval을 하는지에 대해서도 image + text 전부 사용해서 retrieval하는 방식이 가장 좋았다는 실험 결과도 확인할 수 있었습니다.
이러한 실험 결과와는 별개로 JARVIS-1이 어떤 컨트롤러에 의존하고 있는지 확인하기 위해 Implementation Details를 살펴보았습니다. 마인크래프트의 대표적인 태스크인 mine과 craft에 대해 JARVIS-1은 각각 다른 방식을 사용했습니다. mine 태스크를 위해서는 STEVE-1을 활용했으며, text instruction을 STEVE-1에 전달하여 작업을 수행했습니다. 한편, craft 태스크에서는 MineDojo와 유사한 방식을 차용했습니다. 즉, crafting 과정에서 재료를 드래그&드롭하는 방식이 아니라, craft(4 wood plank, crafting table)과 같은 함수를 호출하면 환경에서 자동으로 제작이 이루어지는 방식을 사용했습니다.
따라서 JARVIS-1은 다양한 Minecraft task 수행이 가능하고, 다른 Agent들보다 높은 성능을 보여주지만, 너무 컨트롤러의 성능에 의존하는 부분이 많다는 bottleneck을 가지고 있다는 점을 단점으로 가지고 있습니다. 논문에서도 컨트롤러를 위해서 좀 더 자세한 instruction을 제공하거나, 컨트롤러의 instruction following 능력을 늘리는 것이 필요하다고 이야기하고 있습니다.
Team CraftJarvis: OmniJARVIS
CraftJarvis 팀은 JARVIS-1이 다소 부족하다고 판단했는지, 다음으로 OmniJARVIS를 공개했습니다. OmniJARVIS는 기존 JARVIS-1의 한계를 보완하고, 더욱 강력한 상황 인식 및 태스크 수행 능력을 제공하기 위해 설계되었습니다. OmniJARVIS는 Planner뿐만 아니라 Controller까지 전부 다루고 있습니다.
기본적으로 OmniJARVIS는 VLA model이며, Vision(observations), Language(instructions, memories, thoguts), Actions(behavior trajectories)를 전부 autoregressive sequence prediction하는 모델입니다.
OmniJARVIS의 behavior token은 Planner와 Controller를 더욱 효과적으로 연결하기 위해서 설계되었습니다. 구체적으로, behavior encoder가 목표를 달성하기 위한 action을 discrete behavior token으로 변환하는 과정을 수행합니다.
OmniJARVIS의 아키텍처를 전체적으로 살펴보면, behavior token이 추가된 multimodal language model 이라고 볼 수 있습니다.
동작 과정은 다음과 같습니다:
- OmniJARVIS 모델은 입력으로 Task Instruction, Initial Memory, 그리고 Observation을 받습니다.
- 이를 기반으로 OmniJARVIS는 chain-of-thought reasoning을 수행하여 행동을 결정하는 behavior token을 생성합니다.
- 생성된 behavior token은 Decoder에 의해 사용되며 128 step 동안 Decoder는 환경과 상호작용을 수행합니다.
- 이후 OmniJARVIS는 마지막 Observation을 바탕으로 다시 chain-of-thought reasoning을 수행하여 behavior token을 생성하고, Decoder와 동작을 반복하며 지속적으로 태스크를 해결해 나갑니다.
OmniJARVIS에서는 기존의 자주 쓰이는 구조들과 OmniJARVIS와의 차별점을 아래와 같이 설명하고 있습니다.
- (a) VPT(Small model): Weak Reasoning, fast Hz(20Hz) / RT-2(Large model): Strong Reasoning, slow Hz(2~3Hz)
- (b) JARVIS-1: Utilize vision-language models for planning, subsequently outputting language goals. A language-conditioned policy then translates these language goals into actions at a real-time interaction rate of 20Hz, with high-level models re-planning at less than 1Hz.The training process of high-level vision-language models and language-conditioned policies are separate, thus performing poorly on tasks that can not be easily connected by language.
- (c) OmniJarvis: mirrors the hierarchical structure of (b) but differentiates by employing a self-supervised encoder-decoder policy and FSQ quantization as a behavior tokenizer
(a)와 같은 구조 는 Auto-regressive Transformer가 직접 환경과 상호작용하는 방식으로 설계되어 있습니다. 이 구조는 VPT처럼 작은 모델을 사용하면 빠르게 상호작용할 수 있는 장점이 있지만, Reasoning 능력이 약하다는 단점이 있습니다. 반대로 RT-2와 같이 큰 모델을 사용하면 Reasoning은 강력해지지만, 상호작용 속도가 느려지는 문제가 발생합니다.
이를 보완하기 위해, OmniJARVIS 이전 모델들은 (b)와 같은 아키텍처를 채택하고 있었습니다. 이 구조에서는 큰 모델이 Reasoning 능력을 활용하여 Planning을 진행하고, 생성된 Plan을 기반으로 Controller가 상호작용을 수행합니다. 여기서 Controller는 STEVE-1과 같이 Plan을 Language 형태로 받아 동작을 실행합니다. 이러한 설계는 Reasoning 능력을 강화하면서도 빠른 상호작용이 가능하다는 장점이 있습니다. 하지만, 이 구조의 단점으로는 VLM(Visual Language Model) Planner와 Controller가 따로 학습되기 때문에, Language로 표현하기 어려운 task를 잘 수행하지 못하는 한계가 존재합니다.
따라서 OmniJARVIS(c)에서는 이러한 단점을 해결하기 위해 self-supervised encoder-decoder policy를 도입하고, FSQ quantization을 활용한 behavior tokenizer를 적용했습니다. 생성된 behavior tokens는 vision-language-action 모델의 학습 데이터에 삽입되어, end-to-end 추론을 가능하게 합니다. 이러한 접근 방식은 외부 언어 감독 없이도 효율적으로 작동하며, 복잡한 task를 처리할 수 있도록 확장성과 성능을 크게 향상시킨다고 합니다.
이제 OmniJARVIS의 성능을 확인해보겠습니다. 먼저 Atomic Task에서 OmniJARVIS는 재료를 넉넉하게 수집하며 좋은 성능을 보여주고 있습니다. 여기서 주의할점은 atom tasks는 매우 쉬운 task이기 때문에 "성공할 확률"이 아니라 "수집한 개수"로 표기하고 있다는 점입니다.
다음으로 더 긴 과정을 요구하는 Programmatic Task에서도 기존 연구에 비해 높은 성공률을 보여주는것을 확인할 수 있습니다. 대부분 chain of atom tasks를 통해서 최종 목표로 하는 item을 얻을 수 있으며 난이도에 따라서 Wooden, Food, Stone, Iron, Diamond 총 5가지의 그룹으로 묶어서 평가합니다. 아마 Food 부분이 낮은 이유는 Food를 만드는데 필요한 과정이 길게 필요하지는 않지만, 데이터에서 적게 존재하는 task이기 때문에 성공률이 낮게 나타났다고 생각합니다.
(Stone - 돌 곡괭이 만들기: 나무 캐기 -> 나무 곡괭이 -> 돌 캐기 -> 돌 곡괭이, chain of 4가지 atom task)
마지막으로 마인크래프트 도메인으로 학습된 OmniJARVIS의 reasoning 성능을 확인하기 위해서 Minecraft에 관련된 QA를 구성하고 평가했습니다. 위의 평가 결과를 보면 OmniJARVIS의 Instruction Following 및 Question Answering 성능이 타 모델에 비해 더욱 높은 것을 확인할 수 있습니다.
추가적으로, OmniJARVIS는 데이터 양에 따른 성능 향상 결과를 제시하며, Omni-Tokenizer를 활용한 OmniJARVIS 아키텍처가 scaling law를 따름을 실험적으로 입증했습니다. OmniJARVIS가 데이터의 확장성에 따라 효율적으로 학습하며, 대규모 데이터에서 더욱 강력한 성능을 발휘할 수 있음을 확인할 수 있었습니다.
Team CraftJarvis: ROCKET-1
마지막으로 소개할 CraftJarvis 팀의 논문은 ROCKET-1입니다. 이 논문은 NeurIPS 2024 Open World Agent Workshop에서 저희 CANVAS 논문과 함께 구두 발표를 진행했습니다.
ROCKET-1의 데모 영상을 살펴보면, 작업 수행 과정에서 molmo에게 주기적으로 plan에 따라 점을 찍어달라고 요청하는 장면을 확인할 수 있습니다. 이후, SAM(Segment Anything Model)이 해당 점이 찍힌 부분을 segment하고, 이를 바탕으로 ROCKET-1 controller가 action을 수행합니다.
이 과정의 앞 단계에서는 GPT가 reasoning을 통해 어떤 물체와 어떤 상호작용을 할지 planning하는 부분이 포함되어 있습니다. 이처럼 ROCKET-1은 GPT의 reasoning, molmo와 SAM의 시각적 이해, 그리고 controller의 행동 수행을 결합하여 복잡한 태스크를 효율적으로 처리할 수 있도록 설계되었습니다.
GPT는 Planning을 통해 molmo에게 전달할 instruction을 생성하는 것뿐만 아니라, segmentation에서 수행할 interaction의 정보도 지정합니다. (figure에서는 알기 쉽게 Segmentation의 색으로 interaction type을 표기하고 있습니다)
위 영상에서도 볼 수 있듯이, ROCKET-1에서 주로 사용하는 모듈은 SAM2와 Molmo 모델입니다. SAM2는 segmentation을 진행해주는 모델로, point만 입력으로 줘도 point된 object를 segment할 수 있는 능력을 가지고 있습니다. 반면 Molmo 모델은 AI2에서 학습한 Vision Language Model로 PixMo라는 자체제작 데이터를 이용해 학습되었고, 어떤 물체를 Pointing할 수 있는 능력이 있습니다.
따라서 ROCKET-1에서는 이 두 모델의 시너지를 이용해서 Molmo를 이용해 point를 하고, SAM2를 이용해 point된 물체를 Segmentation하는 방식으로 GPT의 계획에 따라 환경과 interaction하는 파이프라인을 구현했습니다.
Molmo가 처음 나왔을때 SAM2을 함께 사용하는 예제 데모를 제시했다!
저는 이 논문을 읽으면서 Molmo가 처음 출시했을때 공식에서 SAM2와 Molmo를 같이 사용하는 예제 비디오를 제공했는데, 여기서 바로 아이디어를 얻어서 논문으로 착수하지 않았을까? 라는 생각이 들었습니다. 위의 Molmo 데모 비디오를 보면 논문의 key pipeline과 비슷한 방식으로 동작하는것을 확인할 수 있습니다.
OmniJARVIS와 비슷하게, ROCKET-1에서도 embodied decision-making task를 수행하기 위해 쓰이는 pipeline을 5가지로 정리했습니다.
- (a) End-to-End pipeline modeling token sequences of language, observations, and actions. (RT-2, OpenVLA)
- (b) Language Prompting: VLMs decompose instructions for language-conditioned policy execution. (JARVIS-1)
- (c) Latent Prompting: maps discrete behavior tokens to low-level actions. (OmniJARVIS)
- (d) Future-Image Pompting: fine-tunes VLMs and diffusion models for image-conditioned control. (Minedreamer)
- (e) Visual-Temporal Prompting: VLMs generate segmentations and interaction cues to guide ROCKET-1.
이 중 ROCKET-1의 파이프라인은 5번째인 Visual-Temporal Prompting 구조에 속하며, segmentation과 interaction cue를 이용해서 control을 수행합니다.
전체적인 구조는 다음과 같이 동작합니다. Task에 따라 GPT-4o가 낮은 빈도로 planning을 수행하며, interaction type과 language instruction을 생성하여 Molmo에게 pointing 지시를 내립니다. 이후, SAM2는 Molmo가 pointing한 물체를 지속적으로 tracking하며, 생성된 object segment 결과를 ROCKET-1에 전달합니다.
이후 ROCKET-1은 전달된 interaction type, observation, object segmantation을 받아서 Low-level action을 환경과 수행합니다. 이처럼 ROCKET-1의 구조는 생각보다 단순한 파이프라인을 사용하고 있습니다.
ROCKET-1의 학습 데이터는 SAM2를 활용한 Backward Trajectory Relabeling 기법을 통해 생성되었습니다. 예를 들어, 양을 죽이는 영상이 주어졌을 때, 영상의 끝 지점에서 양이 죽는 순간을 기준으로 SAM2를 사용해 죽은 양을 역방향으로 추적하며 Segmentation을 진행했습니다. 이를 통해 새롭게 정의된 ROCKET-1 모델의 학습 데이터를 자동으로 손쉽게 대량으로 제작할 수 있었다고 합니다.
ROCKET-1의 장점을 강조하기 위해, 논문에서는 Minecraft Interaction Benchmark를 제작하여 모델의 상호작용 능력을 평가했습니다. 이를 통해 ROCKET-1이 복잡한 상호작용을 잘 수행한다는 점을 입증했습니다.
Long-Horizon Task에서도 ROCKET-1은 기본적인 reasoning 성능을 GPT에 의존하고 있기 때문에, 계획 수립은 비교적 안정적으로 이루어질 것으로 예상됩니다. 실제로, ROCKET-1의 구조는 복잡한 상호작용 수행 능력이 뛰어나기 때문에, 잘 수립된 계획에 따라 높은 성공률을 보여준다는 점이 확인되었습니다.
하지만 여전히 단점이 존재합니다. ROCKET-1은 목표가 플레이어 화면에 보이거나 가까운 곳에 위치해야만 원활히 동작하며, Long-Context 처리 능력이 부족하다는 한계를 드러냈습니다. 이는 장기적인 계획과 더 먼 거리의 목표를 다루는 데 제약이 있을 수 있음을 시사합니다.
Altera
마인크래프트 AI 연구로 유명한 그룹이 CraftJarvis라면, 마인크래프트 AI 연구로 유명한 회사로는 Altera가 있습니다.
Altera의 관련 영상을 보면, 움직임이 매우 매끄럽다는 점에서 End-to-End 방식은 아니며, LLM Agent처럼 Planning만 진행하고, 이후 Low-level 컨트롤 부분은 코드로 실행하는 구조로 보입니다. 이는 Voyager와 비슷한 방식으로, Minecraft Agent를 개발하고 있다고 추측할 수 있습니다.
이러한 설계는 Altera의 목표가 "게임을 함께 해주는 AI"를 만드는 데 있기 때문에, 굳이 Low-level 컨트롤을 포함할 필요가 없기 때문인 것 같아서 이런 방식을 채택한 것으로 보입니다. 더불어, Altera 에서도 컨트롤 부분을 코드로 실행하는 방식을 사용하고 있기 때문에 마인크래프트뿐만 아니라, 다른 게임에서도 API만 잘 구현되어 있다면 쉽게 적용이 가능하다는 장점을 내세우고 있기 때문에 Altera의 입장에서는 어짜피 게임 속에서만 동작할 Agent를 만들고 있기 때문에 Low-level 컨트롤을 API에게 맡기는게 옳다고 느껴집니다. (저희 회사는 이것과 반대로 실제 환경에서만 동작할 Agent를 만들고 있기 때문에 Low-level 컨트롤까지 해야하고요...)
또한, Altera는 최근 Project Sid라는 이름으로 마인크래프트 환경에서 여러 Agent를 모아두고 사회 실험을 진행해 큰 화제를 모았습니다. 아마 뉴스로 한번쯤 접해보셨을거 같은데 이 프로젝트는 다양한 Agent 간의 상호작용을 관찰하며, Agent의 사회적 행동과 협업 가능성을 탐구하는 데 중점을 두고 있습니다.
자세히는 읽어보지 않았지만, 안에서 meme같은것도 잘 퍼진다고 합니다. (Church of the Flying Spaghetti Monster... / 플라잉 스파게티 몬스터 신이시어...)
Conclusion
이번 글에서는 마인크래프트의 Embodied AI 연구에 대해 다뤄보았습니다. 글을 읽으면서 "마인크래프트 잘하는 Embodied AI를 하면 뭐가 좋은거임?"이라는 의문이 들 수도 있습니다. 하지만 현실 세계에서 Embodied AI가 해결해야 할 문제와 환경이 마인크래프트와 크게 다르지 않습니다. 현실 세계에서의 Embodied AI에는 상호작용, 장기 계획, 유연한 적응 등을 요구하며, 이는 Minecraft를 잘 하기 위해서 필요한 능력과 동일합니다.
이러한 Embodied AI 연구들을 살펴보면, 아키텍처는 점점 발전하고 특정 벤치마크에 대한 성능은 계속해서 개선되고 있지만, In-context Learning, Long Context 처리, Multimodal Pretrain 등과 같이 여전히 근본적으로 개선해야하는 부분이 여럿 존재하는것을 느낄 수 있습니다. 이런 근본적인 문제들 때문에 여전히 복잡하고 장기적인 태스크를 다루거나 대규모 환경에서의 안정적인 동작에는 어려움이 존재하며, 이러한 문제를 해결하는 것은 앞으로의 Embodied AI 연구에서 중요한 과제로 남아 있다고 생각합니다.
실제로 Waymo에서도 Gemini의 Long-Context 처리 능력을 이용한 LMM(Large Multi Modal)을 개발하고 있으며, 이렇게 개발된 EMMA와 같은 모델을 이용해서 End-to-End 자율주행을 시도하고 있습니다. 아래 블로그 글에서도 확인할 수 있는것처럼, 복잡한 문제를 해결하기 위해서는 Long-term memory와 같은 부분이 정말 중요하다고 언급하고 있습니다.
While EMMA shows great promise, we recognize several of its challenges. EMMA's current limitations in processing long-term video sequences restricts its ability to reason about real-time driving scenarios — long-term memory would be crucial in enabling EMMA to anticipate and respond in complex evolving situations.
Author:The Waymo Team
웨이모 인턴 Ph.D가 하는일: gemini 교육하기, 시급 60불.
또한 Embodied AI 연구의 경우에는 추가적인 데이터를 수집하는 과정이 비용이 매우 크다는 비용적인 한계도 존재합니다.
네이버랩스와 같은 대기업은 실제 로봇을 가지고 Real Environment에서 어느정도 대규모 데이터를 모으는 방식이 가능하겠지만, 작은 기업이 이러한 Embodied AI 데이터를 잘 모을 수 있는 방법은 현실적으로 마인크래프트 게임과 같은 시뮬레이터 환경을 사용하는 것이라고 생각합니다.
실제로 저희 회사는 CANVAS 논문의 경우 저희 회사 오피스에서 동작하는 Sim2Real 데이터를 수집하기 위해 게임 회사가 아니지만 언리얼 엔진을 이용해서 Real 환경과 비슷한 환경을 구축하고 Issac Sim을 이용해서 훈련 데이터를 모은 이후 학습해서 성공적으로 가상 환경에서의 데이터 수집 및 학습 후 실제 환경에 모델 배포를 성공한 사례가 있습니다.
Zhou Xian
최근에는 물리 법칙을 따르는 Genesis라는 가상 환경이 공개되며 많은 Embodied AI 연구자들의 관심을 끌었습니다. 이러한 환경을 사용한다면 실험을 위해 더 손쉬운 데이터 수집이 가능할 것으로 전망됩니다.
또한 저희 팀원인 Suhwan Choi가 주도하는 오픈소스 프로젝트의 desktop-env를 활용한다면, OpenAI의 VPT 학습 데이터 제작 과정과 비슷하게 게임 화면을 녹화하는 동시에 키보드/마우스 입출력을 저장해서 쉽게 학습 데이터를 수집할 수 있습니다. 특히 다른 오픈소스 코드들보다 더욱 최적화된 코드를 통해 적은 스펙의 desktop/laptop에서 원천 데이터를 더 높은 Latency로 저장할 수 있습니다. 혹시나 Game Agent / Game World Model 구축에 관심이 있다면 한번 써보시는것도 좋을 것 같습니다. (Contribution은 언제나 환영합니다)
open-world-agents
팀 내부적으로도 Minecraft 환경을 이용한 Embodied AI 연구 프로젝트를 desktop-env로 수집한 데이터를 사용해서 진행할 예정입니다.
예전부터 Embodied AI 연구 시장은 커져 왔지만, 최근에는 계속해서 이러한 수요가 정말로 늘고 있는것 같습니다. 당장에 GPT-5만 하더라도 들려오는 소문으로는 엄청난 자원과 데이터를 사용했지만 2번 실패했다고 하지않나, 데이터 양의 한계로 스케일링의 끝이 온것인가,
neo
우리나라에서 Foundation모델들을 제대로 개발하고 있다고 생각하는 회사 중 하나인 LG AI 팀의 수장이신 배경훈 원장님께서도 Large Action Model (물론 여기서의 Action은 Embodied를 상정한것은 아니긴 하지만)을 한다고 하시고있으며, 이러다가 로봇도?
김태성 기자
ktsmk.co.kr
어디서는 o1, o3, qwq와 같은 모델이 등장하면서 Test Time Compute같이 추론 시간을 늘려서 성능을 끌어올리는 시대가 왔다고 하고있고, Neurips2024에서는 LLM의 스케일링은 끝났다고 수츠게버 형님이 발표하며, 페이페이리 누님이 이젠 환경과 상호작용하는 데이터가 필요하다고 World Model을 만드는 추세 상, Embodied AI 붐은 오고 있다고 느낍니다. 이상한 World Model도 일단 대세니까 Diffusion처럼 엄청 만들어지는거 같습니다
이 글을 쓰는 현재는 엔비디아에서도 CES에서 젠슨 황이 AI 로봇을 띄우고 있고, NVIDIA Cosmos와 같은 월드모델을 공개하고 있으며, OpenAI도 2020에 접었던 사업인 로봇팀을 제대로 부활시키고 있습니다. (이 분야가 매우 각광받는 동시에 경쟁이 치열해질 것을 알 수 있었습니다.)
앞으로 WoRV 팀에서는 계속해서 Embodied AI 연구를 진행할 예정이며, 많은 분들이 최근에 각광받고 있는 Embodied AI/Embodied Agent 연구 흐름에 참여하지는 않으시더라도, 어느 정도 관심을 가졌으면 하는 바입니다.
관련 연구나 협업에 대해 이야기해보고 싶으신 분들은 언제나 커피챗 환영합니다. 또, 화면 오른쪽 하단의 구독 버튼도 눌러주시면 감사하겠습니다. 긴 글 읽어주셔서 감사합니다.
