Memoryfields: 에이전트 메모리의 이식 가능한 파일 형식

에이전트 메모리는 다단계 처리 파이프라인보다는 이식 가능한 데이터 형식으로 간주되어야 한다. Memoryfields 제안은 기존의 에이전트 메모리 시스템—독점적인 플랫폼 종속 허브, 지나치게 복잡한 데이터베이스 아키텍처, 또는 고정된 지식 그래프—가 메모리를 프로세스로 보는 데서 실패한다고 주장한다. 메모리를 마크다운 파일의 집합과 선택적 SQLite 벡터 인덱스로 표현함으로써, 에이전트는 훨씬 낮은 지연 시간과 더 높은 유연성으로 정보를 유지하고 검색할 수 있다.

기존 메모리 시스템의 실패

전통적인 에이전트 메모리 시스템은 일반적으로 세 가지 유형으로 나뉘며, 각각 고유한 단점이 있다:

독점적 허브: 이들은 대개 대화 기록에서 정보를 추출하며, 사용자 중심 데이터에 집중하고 일반적인 세계 지식은 무시한다. 또한 사용자를 특정 제공자 플랫폼에 고정시킨다.
복잡한 아키텍처: 일부 시스템은 무엇을 기억할 만한지 판단하기 위해 pgvector, Neo4j 그래프 데이터베이스, 전용 LLM을 복합적으로 사용한다. 이 복잡성은 관리 부담을 증가시키며, 모델을 혼란스럽게 만든다.
고도로 현대적인 지식 그래프: 이러한 시스템은 정보를 맥락에서 분리하여 정제된 사실이나 논리적 명제를 만든다. 이 접근법은 정보를 고립시켜 에이전트와 사용자에게 의미를 잃게 만든다.

Memoryfield 사양

Memoryfield는 일반적으로 .zip 파일로 아카이브되는 이식 가능한 메모리 파일 형식으로, 다음과 같은 구성 요소를 포함한다:

마크다운 페이지: 메모의 주요 저장소로, 논설문 형식으로 작성된다.
YAML 프론트마터: 각 페이지에 대한 선택적 메타데이터(제목, 생성일, 수정일, UUID, 요약)를 포함한다.
SQLite 벡터 인덱스: 의미적 검색을 위한 선택적 인덱스로, 에이전트가 관련 콘텐츠로 직접 이동할 수 있게 한다.

설계 결정 1: 청크보다는 논설문

전통적인 RAG(Retrieval-Augmented Generation)에서 볼 수 있는 복잡한 청크화 및 재순위 파이프라인 대신, Memoryfields는 논설문을 사용한다. 에이전트 자체가 메모를 작성하므로, 이미 최적화된 마크다운 형식으로 직접 작성할 수 있다.

벡터 임베딩과의 호환성을 보장하기 위해, 페이지당 약 8KB(~2,000 토큰)의 소프트 한계를 두었다. 이 제약은 단일 문서가 아닌 여러 초점이 명확한 페이지를 만드는 것을 장려하며, 이는 에이전트와 검색기 모두에게 유익한 제약이다.

설계 결정 2: 그래프 탐색 대신 의미적 점프

지식 그래프(Karpathy 위키 등)는 에이전트가 링크를 순차적으로 탐색해야 하므로 'N+1 도구 호출 문제'를 야기한다. 관련 정보가 N단계 깊이에 있다면, 에이전트는 N+1번의 순차적 도구 호출을 해야 하며, 각 호출마다 몇 초의 지연이 발생한다. 게다가 페이지 제목이나 링크 텍스트가 검색에 최적화되지 않으면 에이전트가 정보를 찾기 어려운 경우가 많다.

Memoryfields는 그래프 탐색을 의미적 검색으로 대체한다. 이로써 에이전트는 콘텐츠 기반으로 관련 페이지를 직접 점프하여 병렬로 읽을 수 있다. 이 과정은 최대 두 번의 도구 호출로 줄어든다: 하나는 검색, 하나는 읽기.

설계 결정 3: 모델 확장에 대한 낮은 메커니즘

복잡한 API가 아닌 간단한 파일 형식을 사용함으로써, Memoryfields는 에이전트가 자체 강점—Bash, 마크다운, SQLite에 능숙함—을 활용해 자체 접근 패턴을 창출할 수 있게 한다. 이 '낮은 메커니즘' 접근은 모델의 경계가 진전됨에 따라 시스템이 확장되도록 보장한다. 모델이 더 강력해질수록, 고정된 API에 제한되지 않고 더 지능적으로 메모리를 관리할 수 있다.

설계 결정 4: 전송 불변성

잠금을 피하기 위해 형식은 개방적이며 전송 불변성을 갖는다. 공식 아카이브 형식은 ZIP 파일이지만, 사양은 메모리를 로컬 파일, Amazon S3, GitHub, HTTP를 통해 제공할 수 있도록 허용한다. 이는 사용자가 축적한 지식이 다양한 에이전트와 모델 간에 이식 가능하고 교환 가능하게 보장한다.

구현 및 기술적 제약

임베딩 모델로는 nomic-embed-text-v1.5를 제안한다. 이 모델은 크기(270MB)와 성능의 균형을 잘 맞추고 있어, GPU가 없는 하드웨어에서도 실행 가능하면서도 널리 권장되는 기본값이다.

보안 고려사항

메모가 직접 컨텍스트 창에 주입되기 때문에, 프롬프트 인젝션에 취약하다. 저자는 신뢰할 수 없는 당사자와 컨텍스트 창이나 Memoryfield를 공유해서는 안 된다고 강조한다. 정적 ZIP 파일 형식을 사용하면 사용자가 sha256sum을 통해 메모리 필드를 수동으로 검토하고 고정할 수 있어 보안에 유리하다.

커뮤니티의 시각과 반론

기술 사용자들 간의 논의는 파일 기반 메모에 대한 몇 가지 중요한 고려사항을 드러낸다:

"중독" 문제: 일부 사용자는 메모 내 단일 줄의 "중독"되거나 잘못된 텍스트가 모든 후속 출력에 부정적인 영향을 미칠 수 있다고 주장한다. 한 사용자는 소음과 편차를 피하기 위해 공식적인 메모리 시스템보다 단순한 문서 디렉터리가 더 바람직하다고 제안한다.
RAG 비교: 일부는 이를 "단지 RAG일 뿐"이라고 본다. 그러나 다른 이들은 메모의 저자 역할이 에이전트라는 점에서 차이가 있으며, 이는 쓰기와 읽기 모두에 최적화된 시스템이라는 점을 강조한다.
외부화의 공백: 철학적 비판은 트랜스포머에 데이터베이스를 붙이는 것을 "일시적인 해결책"이라고 평가한다. 진정한 메모는 외부 프레임워크가 아니라 모델의 학습이나 아키텍처에 통합되어야 한다는 주장이다.
유지보수 부담: 비판자들은 의미적 검색이 "잊는다"거나 오래된 정보를 업데이트하는 문제를 해결하지 못한다고 지적한다. 메모가 틀렸다는 것이 입증되었더라도, 미래의 검색에서 여전히 의미적으로 관련성이 있을 수 있어, 에이전트가 오래된 경로를 따를 위험이 있다.

"의미 없는 자료는 의미적 검색에 의해 절대 표시되지 않는다... 매우 낙관적인 시각이다. 많은 '메모'나 과거의 대화는 잘못된 방향을 탐색했거나 결국 틀렸다는 것이 입증되었기 때문에 억제하고 잊어야 할 것이다."

데이터 우선 워크플로우 요약

쓰기: 에이전트가 마크다운 파일로 메모를 작성한다.
임베딩: 파일이 임베딩되고 벡터가 SQLite 데이터베이스에 저장된다.
검색: 에이전트는 의미적 검색을 사용해 관련 메모를 병렬로 찾아 읽는다.