■ LLM은 고정된 context window를 사용하기 때문에, 대화가 길어지거나 입력 문서가 길어질수록 긴 문맥을 온전히 반영하는 데 한계가 있다.
■ 제한된 context window를 넘어선 context 사용을 가능하게 하기 위해, 저자들은 운영체제의 가상 메모리 개념을 적용한 virtual context management라는 개념을 제안한다.
■ virtual context management를 사용한 시스템이 바로 MemGPT(MemoryGPT)이며, context window 자체는 제한되어 있더라도 여러 저장 계층을 지능적으로 관리함으로써 마치 더 큰 문맥을 가진 것처럼 동작하게 하는 방향을 제시한다.
[2310.08560] MemGPT: Towards LLMs as Operating Systems
MemGPT: Towards LLMs as Operating Systems
Large language models (LLMs) have revolutionized AI, but are constrained by limited context windows, hindering their utility in tasks like extended conversations and document analysis. To enable using context beyond limited context windows, we propose virt
arxiv.org
1. Introduction
■ LLM은 fixed-length의 context window를 사용하기 때문에, 긴 상호작용이나 긴 문서에 대한 추론에서는 활용성이 크게 떨어진다.
■ 단순히 context window를 늘리는 방식은 충분한 해결책이 되기 어려운데, 이는 트랜스포머 아키텍처의 self-attention 메커니즘으로 인해 계산 시간과 메모리 비용이 \( O(n^2) \)으로 이차적으로 증가하기 때문이다.
■ 이러한 계산적 문제를 해결하더라도, context scaling에 대한 연구에 따르면 long-context 모델이 추가된 context를 항상 효과적으로 활용하는 데 어려움을 겪는다.
■ 저자들은 SOTA LLM 학습에 필요한 비용까지 고려하면, 단순 context 확장만이 아니라, long context를 다룰 수 있는 대안이 필요하다고 주장한다.
■ 논문에서는 고정된 context 모델을 그대로 사용하면서도 무한한 context를 가진 것처럼 동작하게 하는 방법을 다룬다. 핵심 아이디어는 운영체제의 virtual memory paging에서 가져온 것이다.
■ 그리고 LLM 에이전트의 function calling 능력을 활용한다. function calls을 사용하여 LLM 에이전트는 외부 데이터 소스에 읽고 쓰며, 자신의 context를 수정하고, 사용자에게 응답을 반환할 시점을 선택할 수 있다.
■ 이러한 function calling 능력 덕분에 LLM은 운영체제의 계층적 메모리처럼, 현재 context window 안의 정보와 외부 저장소의 정보 사이를 오가며 필요한 내용을 page in / page out할 수 있게 된다.
■ MemGPT에서는 function call이 단지 외부 정보를 가져오는 데만 쓰이는 것이 아니라, 문맥 관리, 응답 생성, 사용자 상호작용 사이의 제어 흐름(control flow)까지 조정하는 데 사용된다.
■ 하나는 표준 텍스트 파일의 길이가 현대 LLM의 입력 한계를 쉽게 초과할 수 있는 document analysis이고, 다른 하나는 conversational agents이다. 후자에서 일반적인 LLM은 긴 대화가 이어질수록 context 인식, 페르소나 일관성, 그리고 장기 기억 유지 측면에서 한계를 드러내게 된다.
■ MemGPT는 두 설정 모두에서 기존의 유한한 context의 한계를 극복하여 기존 LLM 기반 접근법보다 더 나은 성능을 보인다.
2. MemGPT (MemoryGPT)
■ MemGPT의 multi-level memory architecture에는 main context (주기억장치/RAM에 해당)와 external context (디스크 메모리/디스크 저장소에 해당)라는 두 가지 메모리 유형이 있다.
■ main context는 in-context의 영역으로 LLM의 prompt tokens로 구성된다.
■ main context에 있는 모든 것은 in-context에 있는 것으로 간주되며, 추론 중에 LLM processor가 접근할 수 있다.
■ external context는 LLM의 fixed context window 외부에 저장된 모든 정보를 뜻하며, 이 정보는 곧바로 추론에 사용될 수 없다.
■ 이러한 out-of-context 데이터가 추론 중에 LLM processor에 전달되려면, main context 안으로 이동되어야 한다.
■ MemGPT는 사용자가 직접 개입하지 않아도 function calls을 통해 LLM processor가 스스로 자신의 메모리를 관리할 수 있다.
2.1 Main context (prompt tokens)
■ MemGPT의 prompt tokens(즉, main context)는 system instructions, working context, FIFO Queue라는 세 개의 연속적인 섹션으로 나뉜다. (Fig 3)
■ system instructions은 read-only이며, 여기에는 MemGPT의 control flow, 각 메모리 계층을 어떻게 사용해야 하는지에 대한 내용, 그리고 MemGPT 함수(예: out-of-context 데이터를 검색) 사용법에 대한 정보가 들어 있다.
■ 다음으로 working context는 fixed-size의 read/write 가능한 영역이다. 단, MemGPT function calls을 통해서만 쓰기가 가능하다.
■ 이러한 working context는 conversational settings을 위해 고안된 것으로, 사용자에 대한 핵심 사실, 선호, 그리고 에이전트 페르소나 및 기타 중요한 정보가 저장된다. 이를 통해 에이전트가 사용자와 유창하게 대화할 수 있다.
■ 마지막으로, FIFO queue는 에이전트와 사용자 간의 메시지뿐만 아니라 시스템 메시지(예: memory warnings)와 function call의 입출력을 포함하는 메시지들의 history를 저장한다.
■ FIFO queue의 첫 번째 인덱스에는 큐에서 축출된 메시지들의 재귀적 요약을 포함하는 시스템 메시지를 저장한다.
■ 이는 오래된 대화를 완전히 잃어버리지 않기 위한 장치로, 핵심 내용은 요약 형태로 계속 남도록 한 것이다. 즉, FIFO queue는 최근 대화를 저장하는 공간인 동시에, 오래된 상호작용의 핵심 내용을 압축적으로 유지하는 역할을 한다.
2.2 Queue Manager
■ queue manager는 recall storage와 FIFO queue의 메시지를 관리한다.
■ 새로운 메시지가 들어오면, 큐 매니저는 들어온 메시지를 FIFO queue에 append(즉, 큐의 뒤쪽에 추가)한다.
■ 그 다음 prompt tokens을 연결한 뒤, LLM inference를 트리거하여 LLM output (completion tokens)을 얻는다.
■ 큐 매니저는 들어온 메시지와 생성된 LLM output 모두를 recall storage (MemGPT message database)에 기록한다.
■ recall storage에 저장된 메시지가 MemGPT의 function call을 통해 검색될 때, 큐 매니저는 검색 결과를 큐의 맨 뒤에 추가하여 LLM의 context window 안으로 삽입한다. 이렇게 하면 out-of-context 상태의 데이터는 LLM이 직접 볼 수 없지만, 큐 매니저를 거쳐 FIFO queue로 되돌아오고 다시 in-context 정보가 된다.
■ 또한 큐 매니저는 queue eviction policy를 통해 context overflow를 제어하는 역할도 수행한다.
■ prompt tokens의 수가 "warning token count"(예: context window의 70%)를 초과하면, 큐 매니저는 LLM에게 queue eviction을 경고하는 시스템 메시지(memory pressure warning)를 큐에 삽입한다.
■ 이 경고 메시지의 목적은 완전히 꽉 차기 전, LLM이 MemGPT functions을 사용해서 FIFO queue 안에 있는 중요한 정보를 working context나 archival storage(임의 길이의 텍스트 객체를 저장하는 read/write database)에 옮기도록 유도하는 것이다.
■ prompt tokens이 "flush token count"(예: context window의 100%)를 초과하면, 큐 매니저는 큐를 비워 context window의 공간을 확보한다.
■ 구체적으로, 큐 매니저는 특정 개수의 메시지(예: context window의 50%)를 축출하고, 기존의 재귀적 요약과 새로 축출된 메시지들을 합쳐 새로운 재귀적 요약을 생성한다. 이를 통해 오래된 메시지들의 핵심 내용은 요약된 형태로 계속 남게 된다.
■ 축출된 메시지들은 더 이상 in-context 안에 존재하지 않아 LLM이 즉시 볼 수는 없다. 그렇다고 해당 메시지들이 완전히 버려지는 것은 아니다.
■ 축출된 메시지들은 recall storage에 저장되며, MemGPT function calls을 통해 다시 읽을 수 있다.
■ 정리하면 큐 매니저의 역할은 (1) 새로 들어온 메시지와 LLM output을 저장하고, 동시에 현재 context에 반영하는 입출력 조정 (2) 과거 메시지를 현재 문맥 안으로 다시 호출해 주는 메커니즘도 담당 (3) 용량이 초과하기 전에 미리 경고
2.3 Function executor (handling of completion tokens)
■ MemGPT는 LLM processor가 생성한 function calls을 통해 main context와 external context 간의 데이터 이동을 조율한다.
■ 메모리 수정과 검색은 전적으로 self-directed이다. 즉, MemGPT는 현재 context를 바탕으로 스스로 판단하여 자신의 메모리를 자율적으로 업데이트하고 검색한다.
■ 예를 들어, 대화 기록이 너무 길어지면 MemGPT는 어떤 정보를 옮길고 어떤 정보를 현재 context에 유지할지 스스로 결정할 수 있다. (Fig 1)
■ 또한, 현재 목표나 역할에 대한 이해가 바뀌면, 그에 맞추어 main context의 내용을 수정할 수도 있다.
■ 즉, MemGPT는 자신의 메모리를 능동적으로 관리하는 자율적 메모리 시스템이다.
■ 이러한 self-directed editing과 retrieval이 가능하도록 하기 위해, 저자들은 system instructions 안에 명시적인 가이드를 포함시킨다. 이러한 instructions은 두 가지 요소로 구성된다.
- (1) 메모리 계층 구조와 각 계층의 용도에 대한 상세 설명
- (2) 메모리 접근 및 수정을 위해 호출할 수 있는 function schema(자연어 설명 포함)
■ 매 inference cycle에서의 흐름은 다음과 같다.
■ LLM processor는 main context를 입력으로 받아 출력 문자열을 생성한다. 이 출력 문자열은 곧바로 실행되는 것이 아니라, MemGPT에 의해 파싱되어 검증이 진행된다.
■ parser가 함수 인자가 올바르다고 판단하면, 해당 function call이 실행된다. 실행 결과는 발생한 런타임 에러(예: main context가 이미 최대 용량에 도달했는데 추가하려는 경우)를 포함하여 MemGPT에 의해 다시 processor로 피드백된다.
■ 이 피드백 루프를 통해 시스템이 자신의 행동으로부터 학습하고 그에 따라 행동을 조정할 수 있게 한다.
■ 중요한 점은 MemGPT가 이 과정에서 항상 context limit을 인식하고 있다는 점이다. 저자들은 이 점이 self-editing 메커니즘이 제대로 작동하는 데 핵심적이라고 설명한다.
■ context limit 인식을 위해, MemGPT는 processor에게 token limitation에 대한 경고를 프롬프트로 제공하여, 메모리 관리 결정을 더 잘 내릴 수 있도록 한다.
■ 그리고 메모리 검색 메커니즘도 이러한 token constraint을 인지하도록 설계되었다. 검색된 결과를 한꺼번에 많이 불러올 경우 context window에 대해 overflow가 발생할 수 있기 때문이다.
■ 이를 막기 위해 MemGPT는 pagination을 사용한다. 검색 결과를 한 번에 전부 들여오는 것이 아니라, 여러 페이지로 나누어 단계적으로 불러온다.
2.4 Control flow and function chaining
■ MemGPT에서는 LLM inference는 events에 의해 트리거된다.
- 여기서 event는 MemGPT에 들어오는 generalized inputs이며, 이는 사용자 메시지, 시스템 메시지(예: main context 용량 경고), 사용자 상호작용, 그리고 정해진 일정에 따라 실행되는 예약된 events일 수도 있다.
- 예약된 events을 통해 MemGPT는 사용자 개입 없이 스스로 실행될 수 있다.
■ MemGPT는 parser를 사용하여 event를 일반 텍스트 메시지로 변환하며, 이 변환된 메시지는 main context에 추가되어 최종적으로 LLM processor의 input으로 전달된다.
■ 많은 tasks에는 여러 functions을 연속적을오 호출해야 하는 경우가 많다. 예를 들어, 하나의 쿼리로부터 나온 여러 페이지의 결과를 탐색하거나 별도의 쿼리를 통해 main context에 있는 여러 문서들의 데이터를 대조하는 경우이다.
■ 이런 상황에서는 한 번의 함수 호출만으로는 충분하지 않으며, 여러 함수 호출을 순차적으로 수행하는 메커니즘이 필요하다.
■ 저자들은 이를 function chaining이라고 부르며, MemGPT가 사용자에게 control을 돌려주기 전에 여러 function calls을 순차적으로 실행할 수 있게 하는 장치라고 설명한다.
■ MemGPT에서 functions은, 요청된 함수 실행이 완료된 후 즉시 processor로 control이 반환되도록 요청하는 special flag와 함께 호출될 수 있다.
■ 이 flag가 있으면 MemGPT는 함수의 실행 결과를 main context에 추가하고 추론을 이어나간다. qkseofh flag가 없으면, 함수 실행 이후에는 다음 외부 event가 들어올 때까지 LLM processor 실행을 중단한다.
■ 즉, MemGPT는 function call마다 "기서 바로 다음 추론을 이어 갈지, 아니면 여기서 멈추고 외부 입력을 기다릴지"를 구분할 수 있도록 설계되어 있다.
3. Experiments
■ MemGPT를 두 가지 long-context domains에서 평가한다: conversational agents, document analysis
■ conversational agents의 경우, 기존의 Multi-Session Chat dataset을 확장해 사용한다. 그리고 여기에 긴 대화 전반에 걸쳐 지식을 요구하는 에이전트의 능력을 평가하는 두 가지 dialogue tasks을 추가한다.
■ document analysis에서는 기존의 long-context tasks을 기반으로 MemGPT를 평가한다. 여기에는 긴 문서들에 대한 question answering과 key-value retrieval이 포함된다.
■ 더 나아가 저자들은 새로운 nested key-value retrieval task를 제안한다. 여기서는 여러 데이터 소스로부터 정보를 대조하는 에이전트의 능력 (multi-hop retrieval)을 테스트한다.
Implementation details
■ 논문에서 별도 언급이 없을 경우, GPT-4 Turbo는 gpt-4-1106-preview 엔드포인트를 의미하며 context window는 128,000이다.
■ GPT-4는 gpt-4-0613으로 context window는 8,192, GPT-3.5 Turbo는 gpt-3.5-turbo-1106으로 context window는 16,385이다.
■ 실험에서는 모델의 성능이 MemGPT의 성능에 어떠한 영향을 미치는지 확인하기 위해 모든 베이스라인 모델(GPT-4, GPT-4 Turbo, GPT 3.5)에 MemGPT를 결합하여 실행한다.
3.1 MemGPT for conversational agents
■ personalized assistant 같은 conversational agent는 사용자와 장기적인 상호작용을 수행하는 것을 목표로 한다. 그러나 고정 길이의 context를 가진 기존 LLM은 이를 만족시키기 어렵다.
■ 저자들은 이런 점에서 이상적인 "infinite context" agent라면, 대화가 길어져도 자연스럽게 상호작용을 이어갈 수 있어야 하며, 이와 관련해 에이전트는 두 가지 다음 핵심 기준을 충족해야 한다고 주장한다.
- (1) Consistency: 에이전트는 대화의 논리적 일관성을 유지해야 한다. 새롭게 언급된 사실, 선호도 및 이벤트는 사용자나 에이전트가 말했던 내용과 충돌하지 않아야 한다.
- (2) Engagement: 에이전트는 사용자에 대한 장깆거인 정보를 활용하여 응답을 개인화해야 한다. 이전 대화를 참조하면 대화가 더 자연스럽고 매력적으로 만들어진다.
■ 저자들은 MemGPT를 바로 이 두 기준에 따라 평가한다.
- (1) MemGPT가 대화 일관성을 개선하기 위해 메모리를 활용하는지, 그리고 일관성을 유지하기 위해 과거 상호작용의 관련 사실, 선호도, 이벤트를 기억할 수 있는지
- (2) MemGPT가 메모리를 활용해 더 매력적인 대화를 생성하는지, 메시지를 개인화하기 위해 장기적인 사용자 정보를 자발적으로 생성할 수 있는지
3.1.1. DEEP MEMORY RETRIEVAL TASK (CONSISTENCY)
■ conversational agent의 일관성을 평가하기 위해 설계된 MSC dataset 기반의 "deep memory retrieval" (DMR) task를 도입한다.
■ DMR에서 conversational agent는 이전 대화를 명시적으로 참조하며 예상 답변 범위가 매우 좁은 질문을 사용자로부터 받는다.
■ 이를 위해 저자들은 별도의 LLM을 사용하여, 이전 세션들에서 얻은 지식을 사용해야만 정확하게 답할 수 있는 DMR question-answer pairs을 생성했다.
■ DMR의 평가는 생성된 응답을 gold response와 일치하는지 여부로 이루어진다. 이 평가를 위해 ROUGE-L 점수와 LLM judge를 사용한다. LLM judge는 생성된 응답의 품질을 gold response와 대조하여 평가한다.
■ MemGPT와 baseline 모두 gold answer보다 더 장황한 답변을 생성하는 경우가 많았기 때문에, 길이가 더 긴 응답에 불리하지 않도록 ROUGE-L recall을 사용한다.
MemGPT utilizes memory to maintain coherence
■ Table 2를 보면, 베이스라인을 그대로 사용한 것보다 MemGPT를 사용하는 것이 accuracy와 ROUGE 점수 모두에서 뚜렷하게 우수하다.
■ 베이스라인들은 재귀적 요약 절차를 모방하기 위해 과거 5개 대화에 대한 요약을 볼 수 있는 반면, MemGPT는 전체 대화 기록에 접근할 수 있지만, 필요할 때마다 paginated search query를 통해 recall memory를 불러와 main context에 다시 삽입해야 한다.
3.1.2. CONVERSATION OPENER TASK (ENGAGEMENT)
■ conversation opener task에서는 이전 대화에 축적된 지식을 이끌어내어 사용자에게 매력적인 메시지를 작성하는 에이전트의 능력을 평가한다.
■ 에이전트가 사용자를 향해 대화 시작 문장(opener)을 만들 수 있는지를 본다. 그리고 인간이 작성한 첫 응답, human-generated gold opener와도 비교한다. 평가 지표로는 CSIM score를 사용한다.
MemGPT utilizes memory to increase engagement:
■ Table 3에서 볼 수 있듯이 MemGPT는 사람이 직접 작성한 human opener와 비슷하거나 더 뛰어난 opener를 생성할 수 있다.
■ 저자들은 MemGPT가 human opener보다 전반적으로 더 장황하면서도 페르소나 정보의 더 많은 측면을 다루는 opener를 생성하는 경향이 있음을 관찰했으며, working context에 정보를 저장하는 것이 engaging openers을 생성하는 데 핵심이었다고 한다.
3.2 MemGPT for document analysis
■ document analysis는 현재 트랜스포머 기반 LLM의 제한된 context window 때문에 어려움을 겪는다.
■ Table 1에서 보이듯, open 및 closed source 모델 모두 제한된 context length를 가지며, OpenAI 모델의 경우 최대 128k tokens 수준에 머문다.
■ 그러나 많은 문서들은 이 길이를 쉽게 능가한다. 예를 들어 Annual Reports (SEC Form 10-K)와 같은 법률 또는 금융 문서는 100만 토큰을 쉽게 넘길 수 있다.
■ 그리고 실제의 많은 document analysis tasks은 긴 문서를 여러 개 교차하여 연관성을 도출할 것을 요구한다.
■ 또한, context를 무작정 확장하는 접근 자체에도 한계가 있다. 이전 연구에 따르면, long-context 모델은 문맥 전체를 균등하게 활용하지 못한다.
- 문맥의 앞부분이나 끝부분 정보는 잘 회상하는 반면, 가운데 부분 정보는 상대적으로 잘 활용하지 못하는 경향을 보였다.
■ 그러므로, 여러 문서에 걸친 추론을 가능하게 하려면 MemGPT와 같은 보다 유연한 메모리 아키텍처가 필요하다.
3.2.1. MULTI-DOCUMENT QUESTION-ANSWERING
■ MemGPT의 문서 분석 능력을 평가하기 위해, retriever-reader document QA task에서 fixed-context baselines과 MemGPT를 비교한다.
■ 이 task에서는 NaturalQuestions-Open dataset에서 질문을 선택하고, retriever가 해당 질문과 관련된 위키피디아 문서를 선택한다.
■ 그런 다음 reader LLM에 이 문서들이 입력으로 제공되며, 제공된 문서를 사용하여 질문에 답하도록 지시받는다.
■ 이 실험에서는 검색된 문서의 수 \( K \)가 증가함에 따라 reader의 accuracy가 어떻게 달라지는지를 평가한다.
■ 평가 설정에서 베이스라인들과 MemGPT 모두 동일한 retriever를 사용하며, 이 retriever는 OpenAI의 text-embedding-ada-002 embeddings에 대한 similarity search (cosine distance)를 사용하여 top \( K \)개의 문서를 선택한다.
■ MemGPT는 임베딩된 전체 문서 집합이 archival storage에 저장되며, PostgreSQL과 pgvector를 이용한 vector search, 그리고 HNSW 인덱스를 통해 빠른 검색이 가능하도록 구성된다.
■ 반면 베이스라인들은 retriever가 미리 top \( K \) 문서를 선택해 LLM에게 제공하는 전통적인 retriever-reader 방식이 사용된다.
■ 즉, 베이스라인은 처음에 주어진 문서들만 보고 답해야 하는 구조이고, MemGPT는 필요할 때 archival storage를 다시 검색하고 결과를 페이지 단위로 불러오며 추가 탐색할 수 있는 구조이다.
■ NaturalQuestions-Open에 대한 이전 연구를 따라 2018년 후반의 위키피디아 덤프를 사용하며, 평가를 위해 50개 질문을 샘플링하여 사용한다.
■ 그리고 평가 시에는, 답변이 검색된 문서로부터 제대로 도출되었는지 확인하고 정확한 문자열 일치(EM)가 아닌 경우 오답으로 간주되는 것을 방지하기 위해 LLM judge를 사용한다.
■ Fig 5를 보면, 베이스라인들은 자신의 context window에 제공된 정보만을 사용하기 때문에 그 성능은 retriever의 성능 수준에서 상한선이 정해진다.
■ 반면, MemGPT는 archival storage에 쿼리함으로써 retriever에 여러 번의 호출을 효과적으로 수행할 수 있어, 사실상 더 큰 context length를 갖게 된다.
■ 저자들은 이를 통해 MemGPT가 LLM processor의 고정 context window에 들어갈 수 있는 문서의 수에 의해 제한되지 않는다고 본다.
■ 논문에 따르면 NaturalQuestions-Open의 gold document가 실제로는 상위 몇 개 검색 결과 안에 나타나지 않고, 그보다 더 뒤에 위치하는 경우도 많다.
■ 그래서 베이스라인은 검색된 문서 수가 적을수록 정확도가 낮고, 더 많은 문서를 context에 넣을수록 점차 성능이 좋아진다.
■ 반면 MemGPT는 이론적으로 ranking에 gold document가 포함되어 있기만 한다면, 충분히 많은 pagination을 통해 결국 찾을 수 있다.
■ 추가로, 저자들은 베이스라인과 MemGPT를 더 공정하게 비교하기 위해, retriever가 반환한 문서를 잘라 사용 가능한 context 내에 동일한 개수의 문서를 넣는 설정도 시험한다.
■ 그러나 문서를 잘라서 넣으면, 예상대로 정답 문서 내의 관련 스니펫이 누락될 확률이 커지기 때문에 정확도가 떨어진다.
■ 마지막으로 MemGPT가 GPT-3.5를 기반으로 할 때는 function calling 능력이 제한적이라 성능이 크게 떨어지고, GPT-4 기반일 때 가장 좋은 성능을 보인다.
3.2.2. NESTED KEY-VALUE RETRIEVAL (KV).
■ 이 task는 기존 Key-Value retrieval를 확장한 multi-hop retrieval으로, 목표는 MemGPT가 어떻게 여러 데이터 소스로부터 정보를 대조할 수 있는지 확인하는 것이다.
■ 원래 task에서는 각 key-value 쌍 데이터셋이 주어지고, 하나의 key를 입력받으면 그에 대응하는 value를 반환하면 된다. 즉, 기존 task는 단순한 retrieval 문제이다.
■ 이에 비해 저자들이 새롭게 만든 nested KV retrieval에서는 어떤 value가 다시 또 다른 key가 될 수 있도록 설계함으로써, 에이전트가 최종 답을 얻기 위해서는 여러 차례의 조회를 수행해야 한다.
■ 즉, 이 task의 목적은 MemGPT가 단순히 한 번의 검색을 잘하는지를 넘어, 여러 단계의 조회를 조합해 최종 정보를 도출할 수 있는지 multi-hop lookup 능력을 시험하는 데 있다.
■ GPT-3.5와 GPT-4는 원래의 단순 검색 task에서는 좋은 성능을 보였지만, nested KV retrieval에서는 모두 어려움을 겪는다.
■ 특히 GPT-3.5는 nested variant를 거의 해결하지 못하며, nesting level이 1에서 정확도 0%를 기록했다.
■ 반면 GPT-4를 적용한 MemGPT는 nesting level에 영향을 받지 않으며, function query를 통해 main context에 저장된 key-value pair에 반복적으로 접근하여 nested lookup을 수행할 수 있다.
■ 즉, 이 설정에서 MemGPT의 장점은 단순히 많은 정보를 한 번에 담아 두는 것이 아니라, 여러 차례의 함수 호출을 통해 조회 결과를 순차적으로 연결하는 능력에 있다. 또한, 성능이 기반 모델에 따라 달라진다는 점도 볼 수 있다.
