# Agent AI2THOR 회고 및 정리

## 주제 선정 

AI@Sogang에서 프로젝트 팀빌딩을 위해 여러 주제를 둘러보던 중, 가장 흥미로워 보이는 주제를 골랐다. Vision처리와 action, 그리고 RAG로 에이전트를 개선한다고? 물론 Vision 관련 프로젝트 경험도 없었고, 시뮬레이션 경험도 없었지만 공부한다는 마음으로 시작해보았다.

우리의 초기 가설과 목표는 다음과 같았다. 

“RAG 를 기억장치로 활용해서 성공-실패 패턴을 저장하면, 파인튜닝 없이도 에이전트를 개선할 수 있지 않을까?”

## 전체 흐름

### 1. 초반: 플랫폼과 문제 정의를 정하자

![Image](https://upload.cafenono.com/image/slashpageHome/20260318/010321_8SRsoxNDuIjUoVmdUU?q=80&s=1280x180&t=outside&f=webp)

1주차에는 Habitat와 AI2-THOR를 비교한 뒤, 객체 조작 중심 실험에는 AI2-THOR가 더 적합하다는 결론을 내렸다. 동시에 ALFRED benchmark를 핵심 과제로 보고, planner-executor 구조와 long-term memory 가능성을 조사했다. 이 시기에는 Planner, Executor, Verifier, Memory/RAG 모듈이 분리된 형태의 아키텍처를 많이 상상했고, "메타데이터를 최대한 덜 쓰면서도 agent가 과거 관찰을 기억하게 만들 수 있을까"가 중요한 질문이었다.

![Image](https://upload.cafenono.com/image/slashpageHome/20260318/010322_e1WS1DpWV3oiDKVEti?q=80&s=1280x180&t=outside&f=webp)

![Image](https://upload.cafenono.com/image/slashpageHome/20260318/010323_1y3yWxTnmWaJJ5Ok2d?q=80&s=1280x180&t=outside&f=webp)

2주차와 3주차에는 EPO, RoboGPT, SCOUT, RLEF, CAPEAM 같은 선행 연구를 조사하면서, 단순히 논문을 읽는 수준을 넘어서 우리 구조에 무엇을 가져올 수 있을지를 계속 비교했다. 이 과정에서 팀의 관심사는 크게 세 가지로 모였다.

- subgoal을 계층적으로 나눌 것인가

- 현재 시점에서 greedy하게 행동할 것인가? 아니면 Plan 후 따를 것인가.

- RAG를 장기기억으로 둘 것인가, 혹은 episode 내부 메모리처럼 쓸 것인가

특히 EPO의 planner/controller 분리, RoboGPT의 semantic map, SCOUT의 spatial map, RLEF의 reward 관점은 이후 논의의 기준점이 됐다.

### 2. 중반: 무엇을 학습할지보다 무엇을 기억할지를 정하자 

4주차와 5주차쯤부터는 DPO나 reward model 같은 학습 방법론 자체보다, RAG에 어떤 형태의 정보를 저장해야 실제로 agent가 덜 헤매는지가 더 중요한 문제라는 공감대가 생겼다. 성공/실패 trajectory 전체를 넣을지, 부분 성공을 넣을지, 공간 정보만 저장할지, 상호작용 정보까지 저장할지 계속 논의했다.

이 시기에 얻은 중요한 인식은 두 가지였다.

- 실패 로그를 그대로 많이 넣는다고 좋은 기억이 되지는 않는다.

- 장기 task에서는 "무엇을 봤는가"만큼이나 "이미 어디를 확인했고, 왜 실패했는가" 같은 episode 내부 메모가 중요하다.

즉, RAG는 단순 검색기가 아니라 행동의 문맥을 붙들어주는 외부 메모리에 가까웠다.

### 3. 후반: 실제 구현과 디버깅을 통해 E2E 환상이 깨짐

6주차 이후에는 컨테이너 환경, 모델 실험, 프롬프트 조정, 실제 episode 실행을 통해 구현 중심으로 넘어갔다. BLIP2, Gemma 계열, EPO식 구조, LaMMa-P, ProcTHOR/AllenAct 가능성 등을 검토했지만, 실험을 해볼수록 단순한 E2E VLM 방식에는 한계가 컸다.

![Image](https://upload.cafenono.com/image/slashpageHome/20260318/010324_V1eKk4Lo0FUJfDPbFk?q=80&s=1280x180&t=outside&f=webp)

대표적인 사례가 **LookUp 반복 문제**였다. 처음에는 이미지 전송 문제를 의심했지만, 디버깅 결과 실제로는 이미지가 정상 전달되고 있었고, 모델이 현재 상황을 충분히 구조적으로 이해하지 못한 채 단순한 탐색 행동만 반복하고 있었다. 이후 이전 프레임 전달, reasoning/action/success 누적, 프롬프트 수정 등을 통해 "앞으로만 가는" 수준까지는 바뀌었지만, 그 역시 근본 해결은 아니었다.

Stateless한 VLM 하나가 현재 시야만 보고 long-horizon task를 그리디하게 끝까지 해결해주길 기대하는 것은 어렵다.

그래서 최종적으로는 단순 E2E보다 다음과 같은 agentic 구조에 가까운 방향으로 생각이 정리됐다.

1. 최종 goal 기준의 base plan 생성

2. 현재 turn의 subgoal 생성

3. 단기기억 RAG에서 관련 공간정보와 행동 이력 검색

4. 현재 시야 + 검색 결과 + 누적 이력을 바탕으로 action 선택

5. 결과를 다시 메모리에 반영

이 변화는 초기 기획에서 약간 벗어난 것처럼 보일 수 있지만, 실제로는 문제를 더 정확히 정의하게 된 결과라고 보는 편이 맞다.

## 최종 방법론

우리의 목표는 다음과 같았다.

> RAG를 기억장치로 사용하여, 모르는 공간에서의 navigation과 여러 단계의 object interaction task를 수행하는 에이전트를 만든다.

이를 위해 우리 팀은 두 가지 방향을 시도해보았다. 

### 시도 1. 연관관계 RAG

![Image](https://upload.cafenono.com/image/slashpageHome/20260318/010325_IHwwE21QFvKn1aMywC?q=80&s=1280x180&t=outside&f=webp)

첫 번째 시도는 물체들 사이의 관계와 장소 정보를 텍스트로 저장하는 방식이었다. 예를 들어 특정 물체가 어느 방 근처에 있는지, 어떤 물체와 함께 자주 보이는지를 기록해 두고, retrieval을 통해 현재 행동에 참고하게 하는 구조다.

이 방식의 장점은 공간의 전반적인 맥락을 가볍게 저장할 수 있다는 점이었다. 하지만 실제로는 VLM hallucination이 쉽게 개입했고, 검색된 텍스트 관계가 현재 시야와 정밀하게 연결되지 못하는 문제가 있었다. 즉, "대략 어디쯤 있다"는 힌트는 줄 수 있지만, 지금 이 순간 어떤 행동을 해야 하는지까지 안정적으로 이어주지는 못했다.

### 시도 2. 상대좌표 RAG

![Image](https://upload.cafenono.com/image/slashpageHome/20260318/010325_8vvF7zdaUtaMVklCDo?q=80&s=1280x180&t=outside&f=webp)

두 번째 시도는 현재 보고 있는 물체의 상대좌표를 추정해 기억하는 방법이었다. depth estimation, lateral distance estimation, dead reckoning을 결합해, 단순한 설명 텍스트보다 더 구조화된 공간 기억을 만들고자 했다.

이 접근은 첫 번째 방법보다 훨씬 "기억장치"답다는 장점이 있었다. 즉, dead reckoning으로 현재 위치를 계속 갱신하면서, 발견한 상호작용 가능한 객체를 세션 안팎에서 다르게 관리하려는 의도가 분명했다. 다만 발표자료에서도 정리했듯, 여기에는 분명한 한계가 있었다.

- VLM의 거리 추정 정확도가 매우 낮았다.

- object category 자체를 혼동하는 hallucination이 존재했다.

- AI2-THOR의 상호작용 거리 제약과 VLM 추정 오차가 충돌했다.

- zero-shot 성능 개선을 목표로 하다 보니, 실제 행동 안정성을 높이기 위한 fine-tuning과는 상충이 있었다.

결국 상대좌표 RAG는 "더 구조적인 메모리"라는 점에서는 의미 있었지만, 좌표 자체의 신뢰도가 충분히 높지 않으면 오히려 잘못된 확신을 줄 수 있다는 점도 함께 확인했다.

## 이번 프로젝트에서 얻은 점

### 1. RAG는 많이 저장하는 것이 아니라, 잘 쪼개서 저장해야 한다

성공/실패 로그를 전부 넣는다고 해서 agent가 똑똑해지지 않았다. 오히려 특정 실패에 과몰입하거나, 컨텍스트만 불필요하게 커지는 문제가 생겼다. 따라서 RAG는 "많은 기억"보다도 현재 subgoal과 연결되는 적절한 기억 단위가 중요했다.

### 2. long-horizon task에서는 단기기억이 특히 중요하다

장기기억도 중요하지만, 실제 에피소드 안에서는 "내가 방금 어디를 봤고 무엇을 시도했는지"를 잊지 않는 것이 훨씬 직접적인 성능 차이를 만들었다. 이번 프로젝트에서 RAG를 세션 내 메모리처럼 사용하려는 방향이 나온 것도 이 이유 때문이다.

### 3. VLM의 perception과 planning을 한 모델에 모두 기대하기 어렵다

실험을 통해 VLM이 물체 인식, 거리 판단, 행동 선택, 실패 회피까지 모두 안정적으로 수행하기는 어렵다는 점이 드러났다. 특히 zero-shot 조건에서는 더 그랬다. 그래서 perception, memory, planning을 적절히 분리하는 구조적 설계가 중요하다는 교훈을 얻었다.

### 4. 문제를 더 잘 정의한 것이 성과였다

처음 기대했던 형태의 "완성된 agent"를 만들지는 못했더라도, 어떤 조건에서 agent가 막히는지, 무엇을 메모리로 써야 하는지, zero-shot setting에서 어디까지 가능한지를 훨씬 구체적으로 이해하게 됐다. 이 점에서 이번 프로젝트는 단순 구현보다 문제정의와 설계공간 탐색에 큰 의미가 있었다.

## 아쉬웠던 점

- 중간중간 좋은 아이디어가 많았지만, 이를 하나의 일관된 실험 프로토콜로 빨리 고정하지 못한 점은 아쉬웠다.

- 모델 자체의 한계와 시스템 설계의 한계를 분리해서 측정하는 실험이 더 있었으면 좋았을 것 같다.

- RAG schema를 더 빠르게 단순화하고, 작은 단위의 ablation으로 갔으면 비교가 더 명확했을 수 있다.

## 향후 시도할 개선 방법

1. **시도 1과 시도 2의 결합**

장소/관계 중심 기억과 상대좌표 중심 기억을 분리하지 말고, "전역적 장소 힌트 + 국소적 상호작용 정보"를 함께 쓰는 방식으로 합칠 필요가 있다.

1. **객체별 skill 정보 추가**

예를 들어 냉장고, 서랍, 램프처럼 자주 등장하는 객체에 대해 "어떻게 접근하고 어떤 조건에서 조작하는가"를 skill처럼 명시해주면, zero-shot 한계를 꽤 줄일 수 있다.

1. **단순 VLM 액션 선택기에서 planner-memory-actor 구조로 고도화**

현재까지의 경험상, 앞으로는 단일 모델의 직관에 맡기기보다 base plan, subgoal, retrieval, action을 나누는 편이 훨씬 현실적이다.

1. **실험 지표를 success 외에 path efficiency와 failure type까지 확장**

발표자료에서 말한 것처럼 최소 step, PLW Success Rate 같은 관점이 중요하고, 여기에 반복 행동이나 hallucination 유형 같은 failure taxonomy를 붙이면 연구적으로도 더 설득력이 생길 것 같다.

## 마무리하며…

처음엔 진짜 간단하게 ‘RAG로 기억을 저장하면 되지 않을까?’라고 생각했지만, 어떤 데이터를 어떤 구조로 저장하고, 언제 꺼내올지와 같은 디테일을 정해야했다. 그리고 아무리 e2e 가 좋다지만, 플로우를 수정하고 시도해보는 것 자체가 아직 의미 없다고 말할 수는 없을 것 같다. 

팀프로젝트에 대해서도 배웠다. 솔직하게 말하자면, 8주까지의 시간 중에 실제 실행에 옮긴 시점이 늦었다. 빠르게 시도하고, 실험결과를 얻어야하는데, 팀원이 많다보니 책임은 분산되었다. 하나의 통합된 프로세스기에 role을 나누기도 애매했다. 다음 프로젝트에서는 더 주인의식을 가지고 프로젝트를 이끌어나가야겠다.

For the site tree, see the [root Markdown](https://slashpage.com/yejun-cheon.md).