로컬 AI 에이전트의 메모리 시스템을 마크다운 파일 검색에서 벡터 임베딩 기반 의미 검색으로 전환해 문맥 윈도우 효율성 극대화

Context

로컬 AI 에이전트는 모든 메모리를 마크다운 파일에 저장하고 세션 시작 시 전체 로드하는 방식을 사용하고 있었다. 이 방식은 세 가지 실패 모드를 야기했다: 인덱스가 없어 선형 검색만 가능하고, 컨텍스트 윈도우 크기(128k 토큰)가 유한하며, 키워드 기반 검색으로는 의미적 유사성을 찾을 수 없다(예: "food preferences"로는 "Boss likes shawarma from that Lebanese spot on Sunset"을 검색하지 못함).

Technical Solution

• 벡터 임베딩 모델 도입: mxbai-embed-large-v1(335M 파라미터, 1024 차원)을 사용해 텍스트를 의미 기반 수치 벡터로 변환
• 로컬 실행 환경 구성: Ollama를 통해 임베딩 모델을 로컬에서 실행하거나 GGUF 포맷으로 직접 로드해 외부 API 호출 제거
• 벡터 데이터베이스 최소화: sqlite-vec(SQLite 확장)을 사용해 외부 Pinecone, Weaviate 같은 벡터 DB 없이 KNN 검색 구현
• 메모리 구조 계층화: 에피소딕(타임스탬프 기반 이벤트), 의미론적(추출된 사실), 절차적(학습된 패턴) 메모리로 분류해 검색 정확도 향상
• 메모리 유지 루프 자동화: 일일 파일 → 주기적 리뷰 → 고신호 메모리 추출 → 분류 → 정기적 중복 제거 및 인덱스 재구성

Impact

• M3 Pro에서 임베딩 처리 속도: 초당 200개 임베딩(1년치 메모리 재인덱싱 1초 이내)
• 벡터 검색 속도: sqlite-vec에서 1ms 이하(수백~수천 개 청크 규모)
• 비용 대비: mxbai-embed-large는 $0/1M 토큰 대 OpenAI text-embedding-3-large $0.13/1M 토큰
• 네트워크 레이턴시: ~5ms/임베딩 대 OpenAI 100-300ms(네트워크 왕복)
• 리소스 사용: M시리즈 맥에서 GGUF 모델 로드 시 약 670MB 디스크, 약 1.3GB RAM

Key Takeaway

로컬 임베딩 모델(mxbai-embed-large)은 OpenAI 플래그십 모델과 MTEB 벤치마크 점수가 동일(64.68 vs 64.59)하면서 비용은 무료이고 레이턴시는 20배 이상 빠르므로, 개인 정보를 다루는 로컬 AI 에이전트 설계 시 외부 API 대신 로컬 임베딩과 sqlite-vec 조합이 정확한 선택지다.