MemGPT: LLM 시스템, context window 한계 극복법

MemGPT는 UC Berkley AI Research 랩에서 제안한 기술이며 LLM을 OS 형태로 구성한 새로운 시도 중 하나이다. ArXiv에서는 LLM OS 혹은 LLM system이라고도 말한다. 다른 여타 LLM 모델과는 다르게 output이function call이며, 이 function call은 시스템의 메모리에 대한 접근, read, write 등의 task를 수행한다.

논문에서 그림을 발췌, event에 의해 트리거되는 MemGPT와 function call을 만들어내는 LLM Processor

 

이들이 MemGPT를 통해 궁극적으로 이루고자 했던 바는 OS로의 활용보다는 LLM의 context window 한계를 극복하는 것이다. 개인적으로는 이 부분이 명백하게 와닿지 않았다. Context window를 극복하기 위한 방법 중 하나로 OS가 메모리와 디스크에 번갈아 접근하여 단기 및 장기 기억을 보유하는 것에서 착안하다니. 이렇게 완성된 모델을 시스템의 컴포넌트 중 하나로 사용했던 것이 아니라 결국 여느 언어모델과 동일한 '대화형 챗봇' 혹은 '긴 문서를 읽고 이해하는 AI' 로서의 성능 테스트를 진행했기 때문이다. 즉 저자들이 제안한 MemGPT의 활용처는 챗봇이었다.

 

앞서 밝혔듯 MemGPT의 목적은 언어모델의 내재된 한계인 fixed context window를 극복하기 위함이다. 이를 위해 MemGPT가 접근할 메모리에 hierarchy를 구성하여 main context (RAM과 유사)와 external context (Disk와 유사)로 나누었고 모델이 각각에 대한 접근 및 활용여부를 스스로 판단하게끔 fine-tuning되었다. 다시 말하면 MemGPT는 두 메모리 모두 접근이 가능하며 external context를 활용함으로써 유저에게 context window가 커진 것처럼 보이게 한다. 여기까지 읽어도 잘 이해가가지 않았어도 괜찮다. 아래에 좀 더 자세히 설명해보려고 한다.

 

구성

hierarchical memory + OS function + event-based control flow

즉 event가 발생함에 따라 트리거되는 LLM system인데 event는 OS function의 결과물이며 OS function은 계층구조가 있는 메모리 중에서 어디를 접근하는지와 어떤 작업을 할 것인지를 담고 있다.

 

메모리 구조

1. main context = main memory/physical memory (~ RAM)

우리가 GPT 등 다른 프롬프트 기반 AI 모델들을 사용할 때 흔히 접하는 pre-prompts, 혹은 system messages라고 부르는 것이다. 여타 모델들과 마찬가지로 context window 사이즈가 정해져있으며 여기에는 세 가지 정보가 담기게 된다.

(1) system instruction + (2) conversational context + (3) working context

이 때 system instruction, conversational context는 LLM processor가 read-only인 영역이며 (3) working context에 대해서만 LLM processor가 직접 function call로 writable한 영역이다.

논문에서 발췌한 예시 사진을 보면 대화 내용을 바탕으로 LLM Processor가 working context에 유저에 관한 새로운 정보를 추가하도록 append function call을 호출하고 있는 상황이다. 이 정보를 main context 혹은 external context에 작성해두어 대화형 Agent가 추후 유저의 주요 정보를 장기적으로 기억할 수 있도록 돕는다.

 

2. external context = disk memory/disk storage (~ OS disk memory)

LLM의 고정된 context window에서 벗어난 모든 정보를 담고 있다. 말이 어려운데 다시 쓰자면 context window의 제약 때문에 보관하지 못하는 정보들을 따로 담고 있는 공간이라고 보면 된다. 하지만 이 context는 main memory가 아닌 이상 LLM processor가 추론(inference)할 때 활용되는 정보가 아니다. 즉 여기에 기록된 정보가 LLM이 실제 답변할 때 활용되어(=기억하는 것처럼 보임)야할 경우 main context로 이전되어야만 한다. 그럼 external context → main context로의 이전은 누가 판단할까? 당연히 function call을 생성하는 LLM processor가 담당한다.

 

LLM processor는 external context에 세 가지 방법으로 쿼리할 수 있다고 한다.

(1) timestamp-based search (2) text-based search (3) embedding-based search

이름이 직관적이라 더 추가적인 설명은 하지 않아도 될 것 같다.

 

그리고 저장공간은 recall storage와 archival storage를 구분한다고 한다. recall storage는 유저와의 대화 내용들을 특정 쿼리 혹은 시간대에 맞추어 검색할 수 있는 구조로 되어있으며 archival storage는 앞서 반복적으로 이야기되는 context length 한계에 따른 정보들을 장기 기억처럼 담기 위해 read-write할 수 있는 database로 활용된다고 한다. Archival storage는 key-value 페어로 데이터를 저장하는 듯해 보였다. 단적인 예로는 recall storage는 대화 내용 전체를 그냥 로깅해놓는다면 archival storage는 생일: {날짜}, 취미: {취미}와 같이 정보를 기록해둔다.

(왼) Recall Storage를 이용하는 경우 (오) Archival Storage를 이용하는 경우

Function call

그럼 LLM processor가 메모리를 매니징할 수 있는 function call은 무엇일까?

MemGPT는 LLM processor에서 만들어진 function call로 main context ←→ external context 간의 data movement를 통제한다. 이 때 OS에서 영감을 받았다는 말에서 유추가 가능하지만 이러한 일련의 과정에는 유저의 개입이 허용되지 않는다. MemGPT가 시스템적으로 알아서 처리하는 것이다.

이러한 function call을 통해 메모리 변경(edit), 정보검색(retrieval)을 모두 자발적으로 수행(self-directed)할 수 있다.

앞서 잠깐 언급되었는데 MemGPT는 LLM processor가 function call을 생성하도록 fine-tuning되었다. 매 inference cycle마다 MemGPT는 현재까지의 context를 바탕으로 자체 메모리를 업데이트할지 search할지 등을 결정하게 된다. 구체적인 방법은 기재되어있지 않지만 system message에 가이드(explicit instruction)를 담아 언제 edit, retrieval할 지 결정하도록 하였다고 한다. 가이드라 함은 아래와 같이 두 가지 정보를 포함하고 있다고 한다.

(1) 메모리 계층구조와 각 메모리의 역할에 대한 설명

(2) 함수에 대한 스키마 설명: 실제 function 구현 코드와 각 call이 메모리를 접근할지 혹은 수정할지에 대한 가이드

{
 "functionName": "calculateArea",
 "arguments": [
	{
	 "name": "radius",
	 "type": "float",
	},
	{
	 "name": "shape",
	 "type": "string",
	 "allowedValues": ["circle", "square"]
	}
 ],
 "returnType": "float",
}

 

대신 LLM processor가 만들어낸 function call 코드가 올바른 형태인지를 판단하기 위해 parser가 앞뒤로 개입한다. 생성형 모델인 LLM의 특성상 hallucination 혹은 syntax error을 만들어낼 수 있으니 parser가 function의 argument 등을 포함하여 검증 단계를 거치고 통과된 경우 function call을 만들어내어 수행된다. 이 수행 결과를 다시 processor로 넘겨 일종의 feedback loop도 형성한다. 예를 들어 main context의 토큰이 고정된 길이를 넘기게 될 경우 limitation warning을 발생시켜 processor에 인지시키고, processor은 메모리 관리를 할 function call을 만들어낼지 결정하게 되는 것이다.

 

Event

MemGPT는 event에 의해 트리거되어 추론(inference)를 수행하게 된다. 다르게 보면 event는 MemGPT의 input이며 user message, system message, user interaction을 포함하고 있다. MemGPT는 이 이벤트를 parser로 프로세싱하여 평문(plain text message)로 바꾼 뒤 main context에 추가하여 LLM processor로 전달한다.

---

MemGPT는 GPT4로 fine-tuning되었다고 한다. Llama, GPT3.5로도 fine-tuning해보았지만 valid한 function call을 생성하는 것은 GPT4가 가장 잘했다고 한다.

 

이처럼 LLM OS로의 프로토타입 모델로 소개된 MemGPT는 메모리 접근이 가능한 processor 형태로 개발되어 가상으로 context window를 늘려 document analysis 혹은 conversational agent와 같이 프롬프트 길이가 긴 use case에서 활용되도록 설계된 모델이라 정리할 수 있다.