결정론적 통합 (Deterministic consolidation), SQLite 내의 타입화된 그래프 (typed graph), 그리고 에이전트 메모리 벤치마크가 측정할 수 있는 것과 없는 것에 대한 솔직한 고찰.

당신은 에이전트를 구축하고 있습니다. 이 에이전트는 여러 세션에 걸쳐 질문에 답하지만, 세션 3에 도달하면 세션 1에서 배웠던 내용을 잊어버립니다.

이에 대한 반사적인 대응은 에이전트 앞에 벡터 데이터베이스 (vector database)를 두는 것입니다. 하지만 그렇게 하면 에이전트는 코사인 유사도 (cosine distance)에 따라 순위가 매겨진, 모든 것의 흐릿한 평균치를 기억하게 됩니다. 이는 스스로 모순을 일으키며, 3주 전의 선호도와 오래되어 쓸모없어진 정보를 구분하지 못하게 만듭니다. 그래프 데이터베이스 (graph database)는 구조를 제공하지만, 자체적인 쿼리 언어와 배포 방식이 필요한 두 번째 영속성 모델 (persistence model)을 도입해야 하는 비용이 발생합니다. 관리형 메모리 서비스 (managed memory service)는 몇 줄의 코드로 시작할 수 있게 해주지만, 에이전트가 무엇을 기억할지에 대한 결정권을 타인의 인프라에 맡기게 됩니다.

이 모든 방식의 밑바닥에는 한 가지 문제가 있습니다. 만약 가능한 모든 사실이 나타나는 즉시 기록된다면, 메모리는 판단 계층 (judgement layer)이 아닌 축적 계층 (accumulation layer)으로 변질됩니다. Engrava는 이에 대한 우리의 해답입니다. 로컬(local) 방식이며, 구조화되어 있고, 무엇을 손에 닿는 곳에 유지할지에 대해 신중하게 결정합니다. 이것이 Engrava가 구축된 방식이며, 그 이유입니다.

우리는 스키마 (schema)가 아닌 질문에서 시작했습니다

저장소 설계를 하기 전, 인지 아키텍처 (cognitive-architecture) 연구를 읽으며 한 가지 질문을 반복했습니다. 만약 메모리가 검사 가능한 상태로 유지되어야 한다면, 장기 실행되는 에이전트에게 실제로 필요한 메모리는 무엇인가? 이러한 프레임워크 설정이 Engrava가 임베딩 뭉치 (bag of embeddings)가 아닌 타입화된 그래프 (typed graph)인 이유이며, 통합 (consolidation)이 LLM 재작성 단계 대신 결정론적 (deterministic)으로 이루어지는 이유이며, 추출 (extraction)이 데이터베이스 내부에 숨지 않고 데이터베이스 상단에 머무는 이유입니다.

메모리의 실체

Engrava는 단일 SQLite 파일 내에 하이브리드 검색 (hybrid search) 기능을 갖춘 타입 지정 지식 그래프 (typed knowledge graph)입니다. 생각 (thoughts)은 노드 (nodes)이며, 타입 지정된 엣지 (typed edges)는 단순한 벡터 (vector)가 담을 수 없는 관계들, 즉 'A가 B를 유발했다'거나 'C가 D를 전문화한다'와 같은 관계를 전달합니다. 검색 (retrieval)은 코사인 유사도 (cosine distance)에만 의존하는 대신 벡터 유사도 (vector similarity), 키워드 매칭 (keyword match), 최신성 (recency), 그리고 우선순위 (priority)를 융합합니다. 저널 (journal) 기능을 켜면 모든 생각과 엣지의 변이 (mutation)가 변조 방지 기능이 있는 SHA-256 체인에 기록됩니다. 이 모든 기능은 무료 패키지에 포함되어 있습니다.

통합 (consolidation) 작동 방식

모든 생각에는 우선순위 (priority)가 있으며, 통합 사이클 (consolidation cycle, 즉 꿈꾸기: dreaming: 블록)이 실행될 때마다 재계산됩니다. 이 사이클은 저장소에 대해 결정론적 (deterministic)으로 한 번의 패스를 수행하며, 최신성 (recency), 노후성 (staleness), 확인 (confirmation), 신뢰도 (confidence), 빈도 (frequency)라는 다섯 가지 신호 (signals)를 평가합니다. 이 신호들은 하나의 점수로 결합되며, 승격 (promotion) 전 게이트 (gates)를 통해 검증됩니다:

dreaming:
  enabled: true
  signals: [recency, staleness, confirmation, confidence, frequency]
...

기본 설정은 의도적으로 보수적입니다. min_confirmations: 2 설정 시, 에이전트가 한 번 본 사실은 승격되지 않습니다. 해당 사실은 완전히 검색 가능한 상태로 유지되지만, 에이전트가 이를 재확인할 때까지 활성 세트 (active set)로 격상되지 않습니다. 이것이 사이클의 핵심입니다. 메모리를 판단 계층 (judgement layer)으로 유지함으로써, 단 한 번의 노이즈 섞인 패스가 에이전트가 확정된 것으로 간주하는 내용을 재형성하지 못하도록 하는 것입니다. 언어 모델 (language-model) 호출도, 네트워크 호출도, 임베딩 (embedding) 재계산도 필요하지 않습니다. SQLite 행 (rows)에 대한 산술 연산일 뿐이며, 매 실행마다 동일한 입력과 동일한 출력을 보장합니다. 또한 정책 (policy)은 풀 리퀘스트 (pull request)를 통해 검토할 수 있는 YAML 파일로 관리됩니다.

왜 뇌의 메모리와 닮았는지 — 그리고 닮지 않은 점

세 가지 발견이 세 가지 선택을 결정했습니다. Diekelmann & Born (2010)은 수면 중 메모리 안정화 (memory stabilization) 과정을 선택적 (selective)인 것으로 설명합니다. 즉, 뇌는 모든 흔적을 유지하는 것이 아니라 그중 일부 하위 집합 (subset)만을 유지하며, 이것이 바로 우선순위 점수 (priority score)와 승격 게이트 (promotion gates)가 수행하는 역할입니다. Yassa & Stark (2011)는 해마 (hippocampus)가 어떻게 유사한 경험들이 하나의 평균값으로 붕괴되는 것을 방지하는지 설명하며, 이에 따라 Engrava에서 생각 (thoughts)들은 별개의 노드 (nodes)로 유지되고 유사성 (similarity) 때문에 자동으로 병합되지 않습니다. Rao & Ballard (1999)와 Clark의 종합 연구 (2013)는 뇌를 반복된 경험이 확인해 주는 것을 안정화하는 체계로 정의하며, 이것이 바로 확인 (confirmation) 및 신뢰 (confidence) 신호가 발생하는 지점입니다. 우리는 뇌를 구축한 것이 아닙니다. 우리는 생물학적 메모리가 진화하며 겪었던 압박을 가져와 디스크 상의 파일에 적용했을 뿐입니다.

아무도 말하고 싶어 하지 않는 벤치마크의 부분

우리는 Engrava를 리더보드 (leaderboard) 1위를 차지하도록 튜닝하지 않았습니다. 그리고 Engrava의 특징을 부여하는 통합 사이클 (consolidation cycle)인 '꿈꾸기 (dreaming)'는 우리의 검색 (retrieval) 벤치마크 수치를 변화시키지 않습니다. 기능을 켰을 때와 껐을 때를 비교해 보아도 정확도 (accuracy)는 거의 변하지 않습니다.

이것은 우리가 숨기고 있는 버그가 아닙니다. 오히려 벤치마크가 '꿈꾸기'의 목적과는 다른 무언가를 측정하고 있다는 신호입니다. 이러한 벤치마크들은 고정된 전사본 (transcript)에 대한 단기적 질문 답변 (short-horizon question-answering) 방식입니다. 반면 꿈꾸기는 라이프사이클 관리 (lifecycle management)입니다. 에이전트 (agent)가 살아있는 몇 주 동안, 꿈꾸기는 무엇을 손에 닿는 곳에 남겨두고 무엇을 가라앉힐지를 결정하여, 저장소 (store)가 단순한 축적 계층 (accumulation layer)으로 부패하지 않도록 합니다. 이러한 규율이 장기적인 관점 (long horizons)에서 결실을 맺을지는 진정으로 측정하기 어려우며, 현재 존재하는 벤치마크들은 이를 포착할 수 없습니다.

통합 (consolidation) 시스템 전반에 걸친 비교 가능한 증거 또한 부족합니다. 구현 방식, 데이터셋 (datasets), 리더 모델 (reader models), 평가 설정 (evaluation setups)이 너무 다양하여 깔끔한 비교가 어렵고, 근간이 되는 수면-통합 (sleep-consolidation) 연구 자체도 논쟁의 여지가 있습니다. 따라서 우리는 자체적인 검색 테스트가 뒷받침하지 않는 '꿈꾸기'에 대한 성능 향상 주장을 내세우지 않을 것입니다. 꿈꾸기는 결정론적 (deterministic)이고, 검사 가능 (inspectable)하며, 특정한 작업을 수행합니다. 그 작업이 중요한지는 여러분이 결정할 몫입니다.

이 더 넓은 관점은 이 분야 전체에 적용됩니다. 이러한 벤치마크(benchmarks) 중 절반은 동일한 메커니즘을 측정하고 있지 않습니다. 어떤 것들은 메모리 파이프라인(memory pipeline) 내부에서 언어 모델(language model)을 실행하지만, 어떤 것들은 그렇지 않습니다. 그리고 리더 모델(reader model)이 메모리 아키텍처(memory architecture)보다 헤드라인 수치를 더 크게 변화시킬 수 있습니다. 메모리를 고정해 두고 더 강력한 리더를 교체하면, 동일한 시스템이라도 매우 다른 점수를 기록합니다. 우리가 수치를 발표할 때는 누구나 재현할 수 있도록 리더(reader), 저지(judge), 데이터셋(dataset), 설정(setup)을 포함한 전체 실행 과정을 함께 발표합니다.

SQLite의 태도(posture)를 모방하기

SQLite는 호스트 프로세스(host process) 내부에서 실행되고, 하나의 파일에 기록하며, 하나의 라이브러리로 배포되며, 현존하는 가장 많이 테스트된 데이터베이스 중 하나입니다. 우리는 그러한 태도를 원했습니다. Engrava는 Python 라이브러리입니다. pip install engrava로 설치하며, 저장소(store)는 여러분의 디스크에 있는 파일입니다. 실행할 서버도, 열어야 할 포트도, 별도의 인증도 필요 없습니다. 여러분의 에이전트(agent)는 다른 의존성(dependency)처럼 이를 임포트(import)하며, 여러분이 직접 원격 임베딩 제공자(remote embedding provider)를 연결하지 않는 한 호스트 외부로 나가는 것은 아무것도 없습니다. 또한 MIT 라이선스를 따릅니다. 이것은 멀티 테넌트(multi-tenant) 플릿 서비스(fleet service)가 아닙니다. 만약 여러분의 에이전트가 여러 머신 간에 공유 메모리가 필요한 수평 확장(horizontally-scaled) 클러스터라면, 임베디드(embedded) 방식은 적합한 형태가 아닙니다. 단일 에이전트의 경우에는 대개 이것이 더 단순하고 적합한 선택입니다.

현재 이 카테고리의 상황

우리가 시작했을 때, 이 영역은 상당히 개방된 공간이었습니다. 하지만 우리가 제품을 출시할 때쯤에는 상황이 달라져 있었습니다. Anthropic을 포함한 여러 팀이 비슷한 시기에 동일한 "꿈꾸기(dreaming)"라는 이름과 동일한 수면 은유(sleep metaphor)를 빌려와 통합(consolidation) 기능을 출시했습니다. 카테고리는 빠르게 수렴되었습니다. 이제 이러한 도구들을 구분 짓는 것은 어휘가 아닙니다. 그것은 통합(consolidation)이 여러분이 직접 열고, 설정하고, 실행할 수 있는 것인지, 아니면 여러분을 대신해 다른 곳에서 일어나는 일인지의 차이입니다.

다음 단계

Engrava는 PyPI에서 사용할 수 있습니다. 그래프(graph), 결정론적 통합(deterministic consolidation), 하이브리드 검색(hybrid search), 감사 저널(audit journal), 그리고 MindQL은 모두 무료 패키지에 포함되어 있습니다.
에이전트를 구축하고 있다면, 직접 시도해 보세요:

pip install engrava

저장소는 GitHub에서 확인할 수 있으며, 이슈(issues)와 토론(discussions)이 열려 있습니다.