[Review] Enhancing Large Language Model with Self-Controlled Memory Framework

1. Abstract

대규모 언어 모델(LLM)은 긴 입력을 처리할 수 없다는 제약을 받아 중요한 과거 정보가 손실된다. 이러한 한계를 해결하기 위해 본 논문에서는 장기 메모리를 유지하고 관련 정보를 회상하는 LLM의 기능을 향상시키기 위해 자체 제어 메모리(SCM) 프레임워크를 제안한다. 이 SCM 프레임워크는 프레임워크의 백본 역할을 하는 LLM 기반 Agent, Agent 메모리를 저장하는 Memory Stream, 메모리를 업데이트하고 메모리 스트림에서 메모리를 사용하는 시기와 방법을 결정하는 Memory Controller, 세 가지 핵심 구성 요소로 구성됩니다. 또한 제안된 SCM은 수정이나 fine-tuning 없이 ultra-long 텍스트를 처리할 수 있으며, 이는 plug-and-play paradigm에서 LLM을 따르는 모든 명령과 통합할 수 있습니다. 또한 긴 입력을 처리하기 위한 SCM의 효과를 평가하기 위해 데이터 세트를 공개한다. 데이터 세트는 long-term dialog, book summarization, meeting summarization의 3가지 task를 다룬다. 실험 결과는 당사의 방법이 장기 대화의 경쟁 기준선에 비해 더 나은 검색 리콜을 달성하고 더 많은 정보를 제공하는 응답을 생성한다는 것을 보여줍니다.

 

2. Self-Controlled Memory: 

• Workflow of SCM:SCM의 워크플로우는 6개의 명시적인 단계 (Input Acquisition, Memory Activation, Memory Retrieval, Memory Reorganization, Input Fusion, Response Generation)로 구성된다.
  • 처음에, Agent는 turn T에서 observation을 얻는다.
  • 다음에, Memory activation process가 시작된다. 여기서 Memory controller는 현재 observation에 기초하여 메모리를 활성화할 필요가 있는지를 결정한다.
  • 다음에, Top K-랭킹 메모리를 검색하기 위한 쿼리로서 observation를 사용하여 메모리 retrieval이 시작된다.
  • 네 번째 단계는 Memory reorganization을 포함하고, 컨트롤러는 원본 또는 요약된 메모리를 직접 사용할지를 결정한다. 이어서, 프레임워크는 검색된 메모리를 미리 정의된 형식으로 결합하여 응답 생성을 위한 배경 정보를 제공한다.
  • 다섯 번째 단계인 Input fusion은 재구성된 메모리를 현재 관측치와 fusion하는 미리 정의된 프롬프트를 포함하며, 모델의 입력 역할을 한다.
  • 마지막으로, LLM 기반 에이전트는 관찰 및 응답을 포함한 현재 상호 작용을 메모리 스트림에 통합하여 이전 단계의 결과에 기초하여 응답을 생성한다.
• LLM-based Agent: text-davinci-003 + gpt-3.5-turbo
• Memory Stream: 메모리 스트림은 모든 과거 메모리 항목을 저장하고 Redis와 같은 캐시 저장 기술이나 Pinecon 와 같은 벡터 데이터베이스를 통해 고속 액세스를 쉽게 달성할 수 있다. 구체적으로 각 메모리 항목은 (1) Interaction index, (2) Observation, (3) System index, (4) Memory summarization (세부 사항은 다음 단락 참조) 및 (5) 현재 상호 작용 의미를 설명하는 interaction embedding으로 구성된다. Interaction representative embedding을 얻기 위해 observation과 시스템 응답의 텍스트 내용을 결합하고 text-embedding-ada-002 모델을 활용하여 텍스트의 임베딩 벡터를 얻는다. 메모리 검색이 필요한 경우, 메모리 스트림은 관련 과거 메모리를 저장하는 Activation Memory와 이전 턴 T - 1의 상호 작용 메모리를 저장하는 Flash Memory의 두 가지 항목을 검색하여 반환한다.
  • Memory Summarization: 메모리 요약은 단일 상호 작용 또는 대화 턴이 3,000개 이상의 토큰으로 구성될 수 있는 긴 입력을 처리하는 데 중요한 역할을 한다. 턴 요약을 통해 개별 턴의 주요 정보를 얻는 것은 제한된 컨텍스트 윈도우 내에 멀티 턴 정보를 통합하려고 시도할 때 사소하지 않은 작업이다. 그림 3은 개별 상호 작용(즉, 대화 작업)에서 메모리 요약을 위해 특별히 설계된 영어 프롬프트를 보여준다. 이 외에도 프롬프트의 다른 언어 버전은 부록 A에서 찾을 수 있다.
    (예) prompt: Below is a conversation between a user and an AI assistant. Please provide a summary of the user's question and the assistant's response in one sentence each, with separate paragraphs, while preserving key information as much as possible. ( 아래는 사용자와 AI 비서의 대화 내용이다. 핵심 정보는 최대한 보존하면서 사용자의 질문과 비서의 답변을 각각 한 문장으로 요약하여 별도의 문단으로 출력하세요.)
  • Memory Retrieval: 본 연구에서는 observation summary과 system response summary (즉, 각 항목의 메모리 요약 결과)을 연결하여 개별 항목에 대한 의미 표현을 도출하는 경험적 접근 방식을 사용한다. 이 연결은 메모리 스트림 내의 관찰과 시스템 응답 간의 길이에 잠재적으로 상당한 차이가 있기 때문에 필요하다. 이러한 변화는 원본 텍스트에서만 캡처한 의미 정보에 불균형을 일으킬 수 있다. 결과적으로 원본 텍스트에서 얻은 의미 벡터를 직접 활용하는 것은 관찰과 시스템 응답 간의 의미 정보의 균형을 효과적으로 유지하지 못할 수 있다.
• Memory Controller: 이 Section에서는 중심 구성 요소인 메모리 컨트롤러에 초점을 맞추고, 메모리 컨트롤러의 작업 흐름을 그림 4에 나타냈다. 메모리 컨트롤러 설계의 주요 목적은 모델의 성능을 방해할 수 있는 과도한 노이즈를 방지하기 위해 필요한 최소한의 정보를 도입하는 것이다. 구체적으로 이를 세 가지 시나리오로 나누어 논의할 수 있다. 첫째, 사용자 입력 또는 명령이라고도 하는 모든 관측치가 과거 메모리에 대한 액세스를 필요로 하는 것은 아니다. 예를 들어, "농담을 해줘"라는 사용자 명령은 사용자의 과거 메모리를 검색할 필요가 없다. 그러나 "지난 주에 피트니스 다이어트에 대해 내린 결론을 기억하니?"와 같은 특정 사용자 입력은 과거 메모리를 검색할 필요가 있다. 둘째, 메모리의 양은 수백에서 수천, 심지어 수만 개에 이르기까지 방대할 수 있다. 메모리를 검색하고 필터링하기 위해서는 컨트롤러가 필요하다. 셋째, 모델의 제한된 입력 길이를 고려할 때, 컨트롤러는 메모리의 전체 내용 또는 요약을 사용할지 여부를 결정해야 한다. 원본 전체 텍스트가 지나치게 길어질 수 있으며 모델의 최대 길이 용량을 초과할 수 있다. 다음 하위 섹션에서는 앞서 언급한 각 시나리오를 고려한 메모리 컨트롤러의 세부 작업 흐름을 제시한다.
  • Memory Controller Workflow: 메모리 컨트롤러는 새로운 Observation에 응답하여 메모리를 검색할 시기와 검색된 메모리를 어떻게 사용할 것인지를 결정하도록 설계된다.
    컨트롤러는 언어 모델이기도 한데, 언어 모델은 다음과 같은 두 가지 질문을 스스로 함으로써 전체 과정을 제어한다: 1. 현재 사용자의 입력이 주어졌을 때 메모리를 활성화할 필요가 있는가? 2. 현재의 사용자 입력은 기억의 요약만을 가지고 올바르게 답할 수 있는가? (예) Given a user command, determine whether executing the command requires historical or previous information, or whether it requires recalling the conversation content. Simply answer yes (A) or no (B) without explaining the information. (User command가 주어졌을 때, Command를 실행하는 것이 과거 정보 또는 이전 정보를 필요로 하는지, 또는 대화 내용을 회상하는 것을 필요로 하는지를 결정한다. 정보에 대한 설명 없이 단순히 "예" (A) 또는 "아니오" (B)라고 대답한다)
  • Activate Memories: 첫 번째 질문을 해결하기 위해 컨트롤러가 메모리를 활성화할지 여부를 결정하는 프롬프트를 고안했다. 이 프롬프트는 그림 5에 나와 있다. 모델이 "yes(A)"로 응답하면 관련 메모리가 활성화되어 현재 질문에 대한 답을 제공한다. 메모리를 검색하는 과정에서 현재 observation을 쿼리로 사용하고 Recency과 Relevance이라는 두 가지 요소를 기반으로 각 메모리의 순위 점수를 평가한다. Recency 요소는 최근에 액세스한 메모리 항목을 매우 중요하게 여겨 가장 최근의 상호 작용에 대한 Agent의 attention를 강조한다. 또한 현재 쿼리 임베딩과 메모리 임베딩 간의 cosine similarity를 계산하여 각 메모리의 Relevance 점수를 계산한다. 각 메모리의 최종 rank score는 자신의 Recency 및 Relevance 스코어인 rank_score = recency_score + relevance_score를 합산하여 결정된다. 길이 제한에 따라 랭크 스코어가 가장 높은 상위 k개의 메모리를 활성화 메모리로 선택한다. 여기서, k의 값은 3 내지 10의 범위가 될 수 있다.
  • Use Summary: 두 번째 질문을 해결하기 위해 Turn memory를 사용하여 사용자의 질문에 답할 수 있는지 여부를 평가하는 프롬프트를 설계했다. 이 프롬프트는 그림 6에 나와 있다. 우리는 800개의 토큰을 초과하는 활성화 메모리 각각에 대해 이 평가를 수행한다. Summary assessment는 활성화 메모리 토큰의 총 수가 2000개를 초과하는 경우에만 수행된다는 점을 강조하는 것이 중요하다. 평가에서 사용자의 질문에 요약이 실제로 답할 수 있다는 긍정적인 결과가 나오면, 우리는 메모리 요약을 사용하여 해당 특정 메모리를 표현한다.

Given the conversation content and the user question, please answer the command question. Conversation Content: {content} User Question: {query} Command Question: Based on the conversation content, can the user question be answered by conversation content? Respond with (A) for yes, (B) for no. Please strictly follow the format below to answer the questions: [Answer]: (A) / (B)

Figure 6. summary of memory를 사용할지 하지 않을지에 대한 prompt

Here is a conversation between a user and an AI assistant. Please answer the user's current question based on the history of the conversation: History of the conversation: {history_turn} Previous conversation: {last_turn}

Figure 7. ultra-long dialog generation을 위한 prompt