일화·의미·절차적 기억으로 완성하는 AI 에이전트 장기 기억 전략
RAG가 LLM 기반 AI 에이전트의 컨텍스트 창 한계를 극복하는 핵심 기술로 부상했다. LLM 기반 AI 에이전트의 고질적인 기억 한계를 검색 증강 생성(RAG)으로 해결하는 세 가지 방법을 살펴본다.
AI 에이전트가 작업에 대한 컨텍스트 데이터를 많이 기억할수록 에이전트의 성능은 좋아진다.
문제는 에이전트가 의존하는 대규모 언어 모델(LLM)이 상태를 유지하지 않기 때문에 에이전트의 기억 용량이 그다지 크지 않다는 점이다. 에이전트 메모리가 바닥나면 에이전트는 오작동하거나 멈추거나 엉뚱한 답을 쏟아낸다. 에이전트 메모리 자르기, 압축 등의 기법으로 어느 정도 보완할 수는 있지만 진정한 해결책은 아니다.
AI 에이전트의 메모리 부족에 대처하기 위한 더 나은 방법은 에이전트의 외부에 메모리를 두는 것이다. 당면한 작업에는 여전히 에이전트 메모리를 사용하고, 장기적이고 전체적인 정보는 다른 서비스에 덜어낸 후 필요에 따라 가져오는 방식이다.
외부 메모리를 활용하는 이 방식을 검색 증강 생성, 즉 RAG라고 한다. 이제 RAG는 AI 에이전트와 LLM 못지않게 중요한 기술이다. 두 기술의 역량을 즉각 확장해주기 때문이다.
RAG의 기본
LLM에는 “컨텍스트 창”이라는 개념이 있다. 컨텍스트 창은 입력을 처리하는 데 사용되는 작업 메모리 블록으로, 그 크기에 한도가 있다. 창의 최대 크기는 모델에 따라 다르다. 컨텍스트 창에 할당되는 메모리가 많을수록 모델은 더 많은 정보를 처리하고 더 복잡한 대화를 지속할 수 있다.
RAG의 전제는 단순하다. 현재 대화에서 중요한 정보는 LLM의 컨텍스트 창에 저장하고, 그 외의 정보에는 영구 스토리지 시스템(RAG)에 저장하는 것이다. 모델의 컨텍스트 창은 단기 메모리 역할을, RAG는 장기 메모리 역할을 한다.
또한 RAG 스토리지의 형태는 여러 가지다. 각 형태에 대한 상세한 내용은 2024년에 발표된 “언어 에이전트를 위한 인지 아키텍처(Cognitive Architectures for Language Agents)” 논문에서 다루는데, 그 내용을 좀더 이해하기 쉬운 언어로 풀어 살펴보자.
다양한 RAG 기억 종류
RAG 스토리지의 기본적인 세 가지 작동 방식은 일화 기억, 의미 기억, 절차적 기억이다.
일화 기억 : 흐름과 프로세스
일화 기억은 과거의 어느 시점에 LLM이 생성한 데이터, 즉 LLM의 의사결정과 그 결정의 결과를 저장한다. 이런 경험을 시간순으로 배열해 앞서 언급한 논문에 나오는 “이력 이벤트 흐름(history event flows)”(특정 출력에 이른 프로세스)을 구성할 수 있다. LLM은 일화 기억을 통해 이전에 내린 의사결정이나 프로세스를 재구성하고, 그 경험을 사용해 미래의 동작을 유도할 수 있다.
의미 기억 : 사실과 사물
논문에 따르면 의미 기억은 “세계와 에이전트 자신에 대한” 구조적 데이터를 저장한다. 사용자 선호도를 위한 기본적인 키/값 저장소일 수도 있고, 벡터 임베딩과 같은 복잡한 시스템이 포함될 수도 있다. 핵심은 이런 “세계 지식”을 즉시 조회하고 현재 상태 그대로 사용할 수 있는 방법을 에이전트에 제공하는 것이다.
또한 의미 기억은 가급적 통제가 가능해야 한다. 논문에서도 지적하듯이 위키피디아와 같은 외부 소스는 “다른 사용자에 의해 예기치 않게 수정될 수 있는 외부 환경”인 반면 오프라인 버전(특정 시점의 스냅샷)에는 이와 같은 문제가 없다.
절차적 기억 : 작업과 기술
절차적 기억은 추론 프로세스, 학습 절차와 같은 정보를 저장하는 데 사용되므로 표면적으로는 일화 기억과 비슷해 보일 수 있다. 그러나 절차적 기억은 단순히 LLM이 어떤 프로세스에 따랐다는 사실이 아니라, 그 프로세스의 각 단계를 LLM이 다시 재현할 수 있도록 한다. 즉, 절차적 기억은 이런 절차를 매번 처음부터 다시 찾거나 만들 필요 없이 반복해서 수행할 수 있게 해준다.
각 기억 유형에서 한 가지 중요한 점은 쓰기보다 읽기에 중점을 둔다는 것이다. 예를 들어 의미 기억은 에이전트가 자신의 세계에 대해 새롭게 알게 된 사실을 기록하는 데 유용할 수는 있지만 기록의 빈도가 그다지 높지는 않다. 논문에서 언급한 바와 같이 에이전트가 절차적 기억에 자유롭게 쓸 수 있도록 허용할 경우 버그가 발생하거나 설계자의 의도와 어긋나게 작동할 수 있다.
RAG 구현
에이전트 측면에서 RAG 자체는 표준적이지만 RAG 스토리지를 구현하는 정해진 방식은 없다. 스토리지 계층은 일반적으로 벡터 데이터베이스인데, 요즘 나오는 데이터베이스도 상당수가 벡터 기능을 지원한다.
기억의 위치에 대해서도 마찬가지로 정해진 답은 없다. 예를 들어 LLM 액세스를 제공하는 서비스는 서버 측 RAG를 상품 패키지의 일부로 포함할 수 있다. 로컬에서 실행되는 LLM의 경우 모델을 호스팅하는 그 시스템에서 RAG 스토리지 서비스도 함께 실행할 수 있다. 다만 그만큼 더 많은 로컬 스토리지와 처리 성능이 필요하다는 단점이 있다.
RAG 스토리지에는 별도의 유지보수 작업도 필요하다. 각 에이전트와 사용례마다 스토리지 관리 방법도 다르다. 예를 들어 오래된 데이터는 주기적으로 버리거나 더 새로운 데이터 또는 더 자주 액세스되는 데이터보다 낮은 가중치를 부여해야 할 수 있다.
