에이전트 메모리: 7가지 유형, 그리고 실제로는 기억하지 못하는 2가지
에이전트에게 메모리 문제가 있는 것이 아닙니다. 에이전트에게는 일곱 가지의 서로 다른 유형의 메모리가 있습니다. 대부분의 팀은 그중 두 가지만 구축합니다.
가장 먼저 이해해야 할 점은 모델은 아무것도 기억하지 못한다는 것입니다. LLM은 순수 함수(pure function)입니다. 입력을 받아 출력을 내보낼 뿐입니다. 호출 간에 상태를 유지하지 않습니다. 메모리처럼 느껴지는 것은 매 요청마다 히스토리를 다시 보내는 레이어일 뿐입니다. 당신은 매번 그 토큰에 대한 비용을 지불해야 합니다.
대부분의 엔지니어링 노력은 대화 기록(conversation history)과 RAG라는 두 가지 패턴으로 수렴합니다. 이것들은 일곱 가지 유형 중 두 가지에 불과합니다. 문제는 무엇일까요? 이 방식들은 시간이 흐른다고 해서 에이전트를 더 똑똑하게 만들어주지 않는다는 점입니다.
메모리의 일곱 가지 유형은 다음과 같습니다:
• Working (작업): 현재 컨텍스트 윈도우에 있는 모든 것. • Semantic (의미): 사실, 선호도 및 도메인 지식. • Episodic (일화): 과거 사건의 로그와 무엇이 성공하거나 실패했는지에 대한 기록. • Procedural (절차): 기술, 워크플로우 및 도구 패턴. • Retrieval (검색): 유사도 검색을 통해 지식을 가져오는 것. • Parametric (매개변수): 모델 가중치에 내장된 지식. • Prospective (미래): 미래의 의도 및 예정된 작업.
이 중 두 가지는 실제 메모리가 아닙니다. RAG는 단순한 전달 메커니즘일 뿐입니다. 그것은 물이 아니라 배관입니다. 저장소에서 작업 메모리로 데이터를 이동시키는 역할을 합니다. 벡터 데이터베이스만 사용한다면, 당신은 파이프만 만들고 액체는 잊어버린 셈입니다.
실제로 학습하는 에이전트를 구축하려면 '공고화 루프(consolidation loop)'가 필요합니다. 이는 일화 메모리(episodic memory)를 의미론적 메모리(semantic memory)로 전환하는 것을 의미합니다.
프로세스는 다음과 같이 작동합니다:
- 에이전트가 이벤트를 경험합니다 (Episodic).
- 에이전트가 동일한 패턴이 여러 번 반복되는 것을 관찰합니다.
- 에이전트가 해당 패턴을 영구적인 규칙으로 추상화합니다 (Semantic).
이제 에이전트는 12개의 예시를 통해 추론할 필요가 없습니다. 단 하나의 사실을 적용하기만 하면 됩니다.
구축 우선순위를 정하는 방법:
- 작업 메모리(working memory)를 예산처럼 관리하세요. 비용이 가장 많이 드는 부분입니다. 요약(summarization)과 제거(eviction)를 조기에 활용하세요.
- 저장소를 분리하세요. 사실, 이벤트, 규칙을 서로 다른 곳에 보관하세요.
- 미래 메모리(prospective memory)를 위해 스케줄러를 사용하세요. 특정 날짜에 수행되어야 하는 작업에 벡터 저장소를 사용하지 마세요.
- 매개변수 메모리(parametric memory)에 명확한 선을 그으세요. 모델은 추론에 사용하되, 이자율이나 제품 규칙과 같이 변동성이 큰 데이터는 자체 저장소를 사용하세요.
오늘날 대부분의 에이전트는 그저 컨텍스트 윈도우와 벡터 DB에 불과합니다. 승리하는 에이전트는 어제의 실수를 내일의 규칙으로 바꿀 수 있는 에이전트입니다.
Source: https://dev.to/shudiptotrafder/agent-memory-7-types-and-2-of-them-arent-memory-6oi
Optional learning community: https://t.me/GyaanSetuAi