에이전트를 위한 메모리 (Memory for agents)
요약
에이전트의 핵심 요소인 메모리의 정의와 중요성을 다루며, 메모리는 LLM 자체의 기능이 아닌 의도적으로 구현해야 하는 애플리케이션 특화적 요소임을 설명합니다. 인간의 메모리 구조를 모방한 CoALA 논문을 인용하여 에이전트가 활용할 수 있는 다양한 메모리 유형 중 절차적 메모리에 대해 소개합니다.
핵심 포인트
- 메모리는 이전 상호작용을 기억하여 에이전트의 사용자 경험(UX)을 개선하는 필수 시스템입니다.
- LLM은 본질적으로 기억 능력이 없으므로 개발자가 의도적으로 메모리 시스템을 설계하고 추가해야 합니다.
- 메모리는 애플리케이션의 목적(코딩, 연구 등)에 따라 무엇을, 어떻게 기억할지가 결정되는 특화적 요소입니다.
- LangChain은 사용자가 메모리에 대해 저수준 제어권을 가질 수 있도록 LangGraph의 Memory Store 등을 통해 맞춤 설정을 지원합니다.
- 에이전트 메모리는 인간의 기억 구조를 모방한 CoALA 논문의 프레임워크를 참고하여 유형화할 수 있습니다.
지난 3월 Sequoia의 AI Ascent 컨퍼런스에서 저는 에이전트(agents)의 세 가지 한계점인 계획(planning), UX, 그리고 메모리(memory)에 대해 이야기했습니다. 해당 강연은 여기에서 확인하실 수 있습니다. 이 포스트에서는 메모리에 대해 더 깊이 파고들어 보겠습니다. 계획(planning)에 관한 이전 포스트는 여기에서, UX에 관한 이전 포스트들은 여기, 여기, 그리고 여기에서 확인하세요.
만약 에이전트(agents)가 2024년 LLM 애플리케이션 개발의 가장 큰 화두라면, 메모리(memory)는 두 번째로 큰 화두가 될 것입니다. 그런데 메모리란 정확히 무엇일까요?
높은 수준에서 정의하자면, 메모리는 이전의 상호작용(interactions)에 관한 무언가를 기억하는 시스템일 뿐입니다. 이는 좋은 에이전트 경험을 구축하는 데 매우 중요할 수 있습니다. 당신이 말한 것을 전혀 기억하지 못해 계속해서 같은 정보를 반복하게 만드는 동료가 있다고 상상해 보세요. 정말 미칠 듯이 답답할 것입니다!
사람들은 종종 LLM 시스템이 본래부터 메모리를 가지고 있을 것이라 기대하곤 합니다. 아마도 LLM이 이미 매우 인간처럼 느껴지기 때문일 것입니다. 하지만 LLM 자체는 본질적으로 무언가를 기억하지 못합니다. 따라서 의도적으로 메모리를 추가해 주어야 합니다. 그렇다면 정확히 어떻게 이를 구현해야 할까요?
메모리는 애플리케이션 특화적입니다 (Memory is application-specific)
저희는 한동안 메모리에 대해 고민해 왔으며, 메모리는 애플리케이션 특화적(application-specific)이라고 믿습니다.
Replit의 코딩 에이전트(coding agent)가 특정 사용자에 대해 기억하기로 선택하는 것은 Unify의 연구 에이전트(research agent)가 기억하는 것과 매우 다를 것입니다. Replit은 사용자가 좋아하는 Python 라이브러리를 기억하기로 선택할 수 있고, Unify는 사용자가 조사 중인 기업의 산업 분야를 기억할 수 있습니다.
에이전트가 무엇을 기억하는지가 애플리케이션마다 다를 뿐만 아니라, 에이전트가 어떻게 기억하는지도 다를 수 있습니다. 이전 포스트에서 논의했듯이, 에이전트의 핵심 측면 중 하나는 에이전트를 둘러싼 UX입니다. 서로 다른 UX는 피드백을 수집하고 그에 따라 업데이트하는 별개의 방식을 제공합니다.
그렇다면 LangChain은 메모리에 어떻게 접근하고 있을까요?
💡
에이전트에 대한 저희의 접근 방식과 마찬가지로, 저희는 사용자에게 메모리에 대한 저수준 제어(low-level control) 권한을 부여하고 사용자가 적절하다고 판단하는 대로 맞춤 설정할 수 있는 능력을 제공하는 것을 목표로 합니다.
이러한 철학은 지난주 LangGraph에 추가된 Memory Store 개발의 많은 부분을 안내했습니다.
메모리의 유형 (Types of memory)
에이전트가 가지는 메모리의 정확한 형태는 애플리케이션에 따라 다를 수 있지만, 우리는 몇 가지 고수준의 메모리 유형을 확인할 수 있습니다. 이러한 메모리 유형은 새로운 것이 아니며, 인간의 메모리 유형을 모방합니다.
이러한 인간의 메모리 유형을 에이전트 메모리로 매핑하기 위한 훌륭한 연구들이 진행되어 왔습니다. 제가 가장 좋아하는 것은 CoALA 논문입니다. 아래는 각 유형에 대한 저의 거칠고 쉬운(ELI5) 설명과, 오늘날의 에이전트들이 이러한 메모리 유형을 사용하고 업데이트할 수 있는 **실질적인 방법 (practical ways)**입니다.
CoALA 논문(Sumers, Yao, Narasimhan, Griffiths 2024)의 의사결정 절차 다이어그램
절차적 메모리 (Procedural Memory)
이 용어는 뇌의 핵심 명령 집합(instruction set)과 유사하게, 작업을 수행하는 방법에 대한 장기 기억을 의미합니다.
인간의 절차적 메모리: 자전거를 타는 법을 기억하는 것.
에이전트의 절차적 메모리: CoALA 논문은 절차적 메모리를 LLM 가중치(weights)와 에이전트 코드의 결합으로 설명하며, 이는 근본적으로 에이전트가 작동하는 방식을 결정합니다.
실제로, LLM의 가중치를 자동으로 업데이트하거나 코드를 다시 작성하는 에이전트 시스템은 거의(혹은 전혀?) 볼 수 없습니다. 하지만 에이전트가 자신의 시스템 프롬프트(system prompt)를 업데이트하는 몇 가지 사례는 볼 수 있습니다. 이것이 가장 가까운 실질적인 예시이긴 하지만, 여전히 상대적으로 흔하지는 않습니다.
의미적 메모리 (Semantic Memory)
이것은 누군가의 지식에 대한 장기 저장소입니다.
인간의 의미적 메모리: 학교에서 배운 사실, 개념의 의미 및 개념 간의 관계와 같은 정보 조각들로 구성됩니다.
에이전트의 의미적 메모리: CoALA 논문은 의미적 메모리를 세상에 대한 사실들의 저장소(repository)로 설명합니다.
오늘날, 이는 에이전트가 애플리케이션을 개인화(personalize)하는 데 가장 자주 사용됩니다.
실질적으로, 우리는 LLM을 사용하여 에이전트가 수행한 대화나 상호작용으로부터 정보를 추출하는 방식을 볼 수 있습니다. 이 정보의 정확한 형태는 대개 애플리케이션에 따라 다릅니다. 그런 다음 이 정보는 향후 대화에서 검색(retrieved)되어 시스템 프롬프트에 삽입됨으로써 에이전트의 응답에 영향을 미칩니다.
일화적 메모리 (Episodic Memory)
이는 특정한 과거 사건을 회상하는 것을 의미합니다.
인간의 일화적 메모리 (Episodic memory): 사람이 과거에 경험한 특정한 사건(또는 "에피소드")을 회상할 때를 말합니다.
에이전트의 일화적 메모리 (Episodic memory): CoALA 논문에서는 일화적 메모리를 에이전트의 과거 행동 시퀀스 (sequences of the agent’s past actions)를 저장하는 것으로 정의합니다.
이는 주로 에이전트가 의도한 대로 수행하도록 만드는 데 사용됩니다.
실제로 일화적 메모리는 퓨샷 예시 프롬프팅 (few-shot example prompting)으로 구현됩니다. 이러한 시퀀스를 충분히 수집하면 동적 퓨샷 프롬프팅 (dynamic few-shot prompting)을 통해 수행할 수 있습니다. 이는 이전에 수행된 특정 행동을 수행하는 정확한 방법이 있는 경우, 에이전트를 안내하는 데 매우 효과적입니다. 반면, 반드시 정해진 정답이 없거나 에이전트가 끊임없이 새로운 일을 수행하여 이전의 예시들이 큰 도움이 되지 않는 경우에는 의미론적 메모리 (semantic memory)가 더 적절합니다.
메모리를 업데이트하는 방법
에이전트에서 어떤 유형의 메모리를 업데이트할지 생각하는 것 외에도, 개발자들은 에이전트 메모리를 어떻게 업데이트할지에 대해서도 고민합니다.
에이전트 메모리를 업데이트하는 한 가지 방법은 "핫 패스 (in the hot path)" 방식입니다. 이는 에이전트 시스템이 응답하기 전에 (주로 도구 호출 (tool calling)을 통해) 사실을 기억하기로 명시적으로 결정하는 방식입니다. ChatGPT가 채택하고 있는 접근 방식입니다.
메모리를 업데이트하는 또 다른 방법은 "백그라운드 (in the background)" 방식입니다. 이 경우, 대화 중 또는 대화 후에 백그라운드 프로세스가 실행되어 메모리를 업데이트합니다.
이 두 가지 접근 방식을 비교하면, "핫 패스" 방식은 응답이 전달되기 전에 추가적인 지연 시간 (latency)을 유발한다는 단점이 있습니다. 또한 메모리 로직을 에이전트 로직과 결합해야 합니다.
하지만 백그라운드에서 실행하면 이러한 문제들을 피할 수 있습니다. 추가적인 지연 시간이 발생하지 않으며 메모리 로직이 분리된 상태로 유지됩니다. 그러나 "백그라운드" 실행 역시 자체적인 단점이 있습니다. 메모리가 즉시 업데이트되지 않으며, 백그라운드 프로세스를 언제 시작할지 결정하기 위한 추가적인 로직이 필요합니다.
메모리를 업데이트하는 또 다른 방법은 사용자 피드백 (user feedback)을 포함하는 것이며, 이는 특히 에피소드 메모리 (episodic memory)와 밀접한 관련이 있습니다. 예를 들어, 사용자가 특정 상호작용을 긍정적인 것으로 표시하면, 해당 피드백을 저장하여 나중에 다시 불러올 수 있습니다.
에이전트를 위한 메모리가 왜 중요한가요?
이것이 LangChain에서 우리가 만들고 있는 것들에 어떤 영향을 미칠까요? 메모리는 에이전트 시스템 (agentic system)의 유용성에 큰 영향을 미치기 때문에, 우리는 애플리케이션에서 메모리를 최대한 쉽게 활용할 수 있도록 만드는 데 매우 큰 관심을 기울이고 있습니다.
이를 위해 우리는 제품에 다음과 같은 많은 기능을 구축했습니다:
- 에이전트의 메모리를 완전히 제어할 수 있도록 LangGraph 내의 메모리 저장소 (memory store)를 위한 저수준 추상화 (Low-level abstractions) 제공
- LangGraph에서 메모리를 "핫 패스 (hot path)"와 "백그라운드 (background)" 모두에서 실행할 수 있는 템플릿 제공
- 빠른 반복 (rapid iteration)을 위한 LangSmith의 동적 퓨샷 예시 선택 (Dynamic few shot example selection)
우리는 메모리를 활용하는 자체 애플리케이션도 몇 가지 구축했습니다! 아직 초기 단계이지만, 우리는 에이전트 메모리와 그것이 효과적으로 사용될 수 있는 분야에 대해 계속해서 배워나갈 것입니다 🙂
AI 자동 생성 콘텐츠
본 콘텐츠는 LangChain Blog의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기