초급
AI 메모리의 진짜 도전: 벡터 스토어 + 임베딩만으로는 턱없이 부족하다
AI 메모리의 진짜 도전: 벡터 스토어 + 임베딩만으로는 턱없이 부족하다
AI 에이전트와 개인화 AI의 부상과 함께 **AI 메모리(AI memory systems)**가 점차 뜨거운 주제가 되고 있습니다. 많은 프로젝트에서 AI의 장기 기억을 구축하여 모델이 사용자 정보, 과거 행동, 장기 선호도를 기억할 수 있도록 실험하기 시작했습니다.
하지만 현재 대부분의 AI 메모리 프로젝트는 여전히 비교적 단순한 아키텍처에 의존하고 있습니다.
벡터 스토어 + 임베딩 검색
예를 들어, 일반적인 구현 방식은 다음과 같습니다.
- 사용자 대화나 행동에서 임베딩 생성
- 임베딩을 벡터 데이터베이스에 저장
- 새 요청이 도착하면 쿼리 임베딩 생성
- 유사도 검색을 통해 상위 k개의 관련 메모리 찾기
이 아키텍처는 "과거 정보 검색" 문제를 해결하지만, 진정한 메모리 시스템이라기보다는 검색 가능한 로그 시스템에 가깝습니다.
실제로 어려운 문제는 다음 세 가지 측면에 집중됩니다.
- 메모리 압축
- 메모리 진화
- 메모리 충돌 해결
이 세 가지 문제는 AI 메모리가 단순한 "로그 검색"에서 진정한 "장기 지식 시스템"으로 진화할 수 있는지를 결정합니다.
1. 메모리 압축: 기억 압축하기#
문제: 메모리가 무한히 증가함#
시스템이 모든 대화를 단순히 벡터 스토어에 저장하면 메모리 크기가 빠르게 폭발합니다.
예를 들어, 사용자가 비슷한 의견을 여러 번 표현하는 경우:
나는 스시를 좋아해
나는 스시를 사랑해
스시는 내가 가장 좋아하는 음식이야
나는 스시 먹는 걸 즐겨단순한 시스템은 4개 또는 그 이상의 메모리를 저장합니다.
하지만 진정으로 가치 있는 메모리는 단 하나입니다.
사용자는 스시를 좋아함따라서 메모리 시스템은 다음 기능을 갖춰야 합니다.
대량의 원시 상호작용을 더 높은 수준의 지식 표현으로 압축하는 것.
데이터베이스 시스템과의 유사성#
이 문제는 실제로 데이터베이스의 LSM-트리 압축과 매우 유사합니다.
데이터베이스의 데이터는 일반적으로 다음 패턴을 따릅니다.
이벤트 로그 → 압축 → 스냅샷원시 로그는 더 높은 수준의 상태로 압축됩니다.
AI 메모리도 비슷합니다.
원시 상호작용 → 메모리 압축 → 구조화된 지식예를 들어:
원시 상호작용:
사용자: 나 시애틀로 이사했어
사용자: 시애틀 날씨는 비가 많이 오네
사용자: 나는 여기 사는 게 좋아압축된 메모리:
사용자는 시애틀에 거주함기술적 과제#
메모리 압축은 단순한 요약을 훨씬 넘어섭니다.
1. 추상화 수준 문제
시스템이 다음을 관찰한다고 가정해 봅시다.
사용자는 스시를 좋아함
사용자는 라멘을 좋아함
사용자는 피자를 좋아함시스템이 생성해야 하는 것은:
사용자는 음식을 좋아함또는:
사용자는 일식 음식을 좋아함추상화 수준을 자동으로 결정하는 방법은 매우 어려운 문제입니다.
2. 압축 시점
일반적인 두 가지 전략이 있습니다.
- 주기적 압축 예를 들어, N개의 메모리가 누적된 후 압축을 수행합니다.
- 유사성 기반 트리거 시스템이 임베딩 공간에서 메모리 클러스터를 발견하면 압축을 트리거합니다.
3. 정보 손실 방지
압축 과정은 잘못된 추상화로 이어질 수 있습니다.
예를 들어:
사용자는 스시를 좋아함
사용자는 조개류에 알레르기가 있음다음과 같이 압축된 경우:
사용자는 해산물을 좋아함이는 명백히 잘못된 것입니다.
따라서 메모리 압축은 매우 신중하게 수행되어야 합니다.
2. 메모리 진화: 기억의 진화#
인간의 기억은 정적이지 않으며 시간이 지남에 따라 끊임없이 업데이트됩니다.
예를 들어:
2023: 사용자는 뉴욕에 거주
2024: 사용자는 시애틀로 이사시스템은 다음을 이해해야 합니다.
뉴욕 → 오래된 정보
시애틀 → 현재 정보하지만 벡터 스토어는 이러한 기능이 없으며, 추가 전용입니다.
메모리의 본질#
벡터 스토어는 다음과 같습니다.
추가 전용 로그반면 진정한 메모리 시스템은 다음이 필요합니다.
상태 기계즉, 메모리는 업데이트와 진화를 지원해야 합니다.
핵심 문제#
1. 사실 업데이트
예를 들어:
사용자 선호 언어: Python나중에 사용자가 말합니다.
나는 Rust로 전환했어.시스템이 해야 할 일은:
메모리 업데이트단순히 새 메모리를 추가하는 것이 아닙니다.
2. 시간 차원
메모리에는 일반적으로 다음이 포함되어야 합니다.
- 타임스탬프
- 신뢰도
- 유효 기간
예를 들어:
사용자는 NYC에 거주 (2019–2024)
사용자는 시애틀에 거주 (2024–)이를 통해 시스템이 현재 상태를 올바르게 추론할 수 있습니다.
3. 장기 vs. 단기 메모리
모든 메모리가 장기적으로 유효한 것은 아닙니다.
예를 들어:
장기 안정:
사용자는 스시를 좋아함단기 정보:
사용자는 도쿄 여행 중인지 과학에서는 일반적으로 다음과 같이 구분합니다.
- 일화 기억
- 의미 기억
AI 메모리 시스템은 종종 유사한 계층 구조가 필요합니다.
3. 메모리 충돌 해결: 기억 충돌 해결하기#
이는 AI 메모리에서 가장 어려운 문제 중 하나입니다.
메모리는 쉽게 서로 모순될 수 있기 때문입니다.
예를 들어:
메모리 A
사용자는 채식주의자임
메모리 B
사용자는 스테이크를 좋아함시스템은 결정해야 합니다. 어느 것이 올바른가?
충돌의 원인#
1. 사용자 행동 변화
사용자는 채식주의자였음
사용자는 더 이상 채식주의자가 아님2. 일관되지 않은 사용자 진술
사용자: 나는 Python이 싫어
사용자: Python은 사실 괜찮아3. 모델 추론 오류
LLM이 문맥에 따라 잘못된 메모리를 추론할 수 있습니다.
일반적인 해결 전략#
1. 시간 우선순위 (최신 우선)
최신 정보가 우선합니다.
2023: 채식주의자
2024: 고기 섭취시스템은 2024 상태를 채택합니다.
하지만 이 전략이 항상 올바른 것은 아닙니다.
2. 신뢰도 메커니즘
메모리에는 다음이 포함될 수 있습니다.
신뢰도 점수예를 들어:
사용자가 명시적으로 말함 → 높은 신뢰도
LLM 추론 → 낮은 신뢰도충돌 시 신뢰도가 높은 메모리를 우선시합니다.
3. 출처 추적
메모리의 출처를 기록합니다.
출처 = 사용자_진술
출처 = 추론
출처 = 시스템충돌 시 직접 사용자 진술을 우선시합니다.
4. 다중 버전 메모리
또 다른 전략은 여러 시간 버전을 유지하는 것입니다.
사용자는 채식주의자였음 (2018–2023)
사용자는 고기를 섭취함 (2023–)이를 통해 시스템이 다른 시간적 맥락에서 다른 메모리를 사용할 수 있습니다.
왜 이 세 가지 문제가 그렇게 어려운가?#
AI 메모리는 사실 단순한 검색 시스템이 아니라 지식 관리 시스템이기 때문입니다.
벡터 데이터베이스는 다음을 해결합니다.
유사도 검색반면 메모리 시스템은 다음을 해결해야 합니다.
- 지식 표현
- 지식 진화
- 지식 충돌 해결
이는 임베딩 인덱스가 아니라 다음을 구축하는 것에 더 가깝습니다.
- 지식 그래프
- 데이터베이스 시스템
- 추론 엔진
더 완전한 AI 메모리 아키텍처#
성숙한 AI 메모리 시스템은 일반적으로 다음 구조가 필요합니다.
원시 상호작용
│
▼
메모리 추출 (LLM)
│
▼
구조화된 메모리 저장소
│
├── 압축
├── 진화
└── 충돌 해결
│
▼
검색 계층여기서 메모리 저장소는 다음과 같을 수 있습니다.
- 그래프 데이터베이스
- 문서 저장소
- 관계형 데이터베이스
벡터 데이터베이스만 있는 것은 아닙니다.
결론#
현재 많은 AI 메모리 프로젝트(예: mem0)는 다음과 같은 사실을 깨달았습니다:
Memory ≠ Retrieval이들은 다음과 같은 영역을 탐구하기 시작했습니다:
- 메모리 추출
- 메모리 점수화
- 메모리 업데이트
하지만 전반적으로 이는 여전히 1세대 AI 메모리 시스템에 불과합니다.
진정으로 성숙한 AI 메모리는 아마도 지속적으로 진화하는 지식 시스템에 훨씬 더 가까울 것입니다—경험을 압축하고, 사실을 업데이트하며, 모순을 해결할 수 있는 시스템 말입니다.
그리고 이면의 핵심 문제는 실제로 단 하나입니다:
"메모리" 자체를 어떻게 표현해야 하는가?