‘메모리를 가진 AI’ 데모는 모두 같은 방식으로 시작합니다: 사용자의 노트를 임베딩(embed)하여 벡터를 저장하고, 가장 가까운 상위 k개 청크(chunk)를 검색한 다음, 이를 프롬프트에 붙여 넣습니다. 데모에서는 충분히 잘 작동합니다. 하지만 실제 사용 사례가 닥치면 문제점이 드러납니다.
이 게시물은 개인적인 메모리 측면에서 벡터 검색이 더 이상 충분하지 않은 지점과 그 옆에 무엇이 위치해야 하는지에 대한 내용입니다. 이는 벤치마크가 아니라 디자인 노트입니다. 저희는 수치를 주장하는 것이 아니라, 기억하려는 대상이 한 사람의 삶일 때 나타나는 실패 모드를 설명하고 있습니다.
벡터가 잘하는 것들
임베딩(Embeddings)은 의미적 유사성(semantic similarity)을 포착합니다. 만약 누군가가 “치과 의사가 3월에 스케일링 예약을 하라고 했다”라는 메모를 저장했고, 나중에 “내 치아에 대해 뭘 해야 했지?”라고 질문한다면, 공유된 키워드가 없어도 가장 가까운 이웃 검색(nearest-neighbour search)이 해당 정보를 찾아냅니다. 이것은 정말 유용하며, 모호한 회상(fuzzy recall) 측면에서는 따라오기 힘듭니다.
개인 메모리에서 문제가 발생하는 지점들
1. 유사성이 관련성을 의미하지 않는다. “사라의 번호가 뭐야?”라는 질문과 “사라의 생일 저녁 식사는 정말 좋았어”라는 메모는 의미적으로 가깝습니다. 필요한 것은 가장 가까운 단락이 아니라 구조화된 사실(전화번호)입니다.
2. 시간은 임베딩 공간에 존재하지 않는다. 1월에 저장된 “새 아파트로 이사했다”와 9월에 저장된 “다음 달에 이사한다”라는 메모는 모두 거주지에 대한 질문과 일치합니다. 어느 것이 최신 정보일까요? 벡터로는 알 수 없습니다. 타임스탬프(timestamps)나 대체 규칙(supersession rules), 또는 둘 다가 필요합니다.
3. 사실은 추가되는 것이 아니라 업데이트된다. 치과 예약이 화요일에서 목요일로 변경됩니다. 벡터 스토어는 이 두 가지를 모두 기꺼이 반환할 것입니다. 개인 메모리는 “이것이 저것을 대체한다”라는 개념이 필요합니다.
4. 개체(Entities)는 청크(chunks)가 아닙니다. 사람, 장소, 날짜 등은 여러 메모에 걸쳐 반복됩니다. 만약 "Sara"가 오직 청크 내부의 토큰으로만 존재한다면, 검색기(retriever)가 운이 좋기를 바라는 것 외에는 "Sara와 관련된 모든 것"을 요청할 수 없습니다. 개체를 자체 기록으로 추출하면 이는 도박이 아니라 조회(lookup) 작업이 됩니다. (개체 추출 측면에 대해서는 여기에서 다루었습니다: AI가 메모에서 사람, 장소, 날짜를 추출하는 방법.)
5. 망각은 기능입니다. 모든 것을 영원히 동일한 가중치로 보존한다면, 저장소가 커질수록 검색 결과는 더 노이즈가 많아집니다. 무엇을 유지하고, 요약할지, 아니면 버릴지를 결정하는 것은 스토리지 문제가 아니라 설계 문제입니다.
벡터 인덱스 옆에 배치할 것들
개인 기억을 위한 실용적인 스택은 다음과 같은 모습을 띨 가능성이 높습니다:
- 원시 캡처(Raw capture) — 원본 메모, 메시지 또는 음성 녹취록을 진실의 근원으로 보존합니다.
- 구조화 계층(Structured layer) — 추출된 개체, 날짜 및 관계를 실제 필드(field)로 저장하여 정확한 질문에 정확한 답변을 얻게 합니다.
- 벡터 인덱스(Vector index) — 모호하거나 "그거 뭐였지..."와 같은 회상(recall)을 위해 사용합니다.
- 최신성 및 대체 로직(Recency and supersession logic) — 업데이트된 사실이 오래된 사실보다 우선하도록 합니다.
- 라우팅 검색 단계(A retrieval step that routes) — 질문이 정확할 때는 정확한 조회를 먼저, 모호할 때는 의미론적 검색을, 그리고 둘 다일 때는 조합을 사용합니다.
구조화 계층이 단순 관계형 테이블인지 그래프인지는 별개의 결정이며, 그 답은 데이터가 실제로 얼마나 연결되어 있는지에 달려 있습니다. 저희는 지식 그래프 대 일반 메모: 구조가 도움이 되는 경우에서 두 가지를 비교하고, 개인 메모를 위한 검색 증강 생성(RAG)의 기본 개념 설명에서 검색의 기초를 다루었습니다.
단기 기억 대 장기 기억
한 가지 더 구분해야 할 점이 있습니다: 어시스턴트가 대화에서 지금 당장 필요한 것(단기 기억)과 사용자에 대해 영구적으로 알아야 하는 것(장기 기억)은 다릅니다. 이 둘을 모두 '벡터 DB에 저장되는 정보'로 취급하는 것은 이러한 차이를 가립니다. 더 자세한 내용은 AI 어시스턴트가 단기 및 장기 메모리를 통해 어떻게 기억하는지를 참고하세요.
핵심 요약 (Takeaway)
벡터 검색은 기억 _시스템_이 아니라 검색 _도구_입니다. 개인용 AI의 어려운 부분은 무엇이 현재 유효한지, 무엇과 연결되어야 하는지, 그리고 무엇을 버려야 하는지를 아는 것입니다. 이 분야에서 무언가를 구축하고 있다면, 구조부터 시작하고 모호성이 실제로 도움이 되는 곳에 임베딩(embeddings)을 추가하세요.
저희는 Brinn이라는 개인용 AI를 통해 바로 이 문제를 해결하고 있습니다. Brinn은 WhatsApp, 이메일, 웹 및 데스크톱 전반에 걸쳐 알림, 목록, 메모리를 처리합니다. 만약 유사한 것을 구축하고 있다면, 댓글로 어떤 것이 효과가 있었는지 알려주시면 좋겠습니다.