2026년 5월 · 10분 분량 · Fran Olivares, Founder of OlivaresAI
영속 메모리 저장소 자체는 아무것도 하지 않습니다. 저장소는 다음 사용자 메시지가 도착하기 전에 쿼리되고, 스코어링되고, 모델의 컨텍스트 창에 맞는 시스템 프롬프트로 형성되어야 합니다. 그 단계 — 컨텍스트 조립 — 가 "메모리 데이터베이스가 있다"와 "AI가 기억한다"의 차이입니다. 이 가이드는 /docs/context-assembly의 기술 참조에 대한 긴 형식 동반이며 파이프라인의 모든 단계, Alma가 기본적으로 사용하는 숫자, 조정할 수 있는 트레이드오프를 안내합니다.
모델은 프롬프트에 있는 것만 보기 때문입니다. 만 개의 항목이 있는 메모리 저장소는 무언가가 이 턴을 위한 올바른 30개를 선택하지 않는 한 모델에게 보이지 않습니다. 선택이 잘못되면 모델은 관련 사실을 놓치고 일반적인 답변을 생성합니다. 선택이 너무 광범위하면 프롬프트가 컨텍스트 창을 초과하거나 노이즈에 토큰을 낭비합니다. 조립은 게이트키퍼입니다 — 사용자가 결코 보지 못하는 조용한 단계이지만, "AI가 기억한다"의 전체 느낌이 그 품질에 달려 있습니다.
조립은 또한 엄격한 지연 시간 예산에 부딪힙니다. 사용자가 기다리고 있습니다; ~100 ms 이상은 단일 모델 토큰이 스트리밍되기 전에 굼뜨게 느껴지기 시작합니다. 이것이 조립이 전체 스캔이 아닌 인덱싱된 검색에 의존하는 이유, 스코어링이 가중 합(LLM 호출이 아님)인 이유, 티어별 토큰 예산이 동적으로 협상되는 대신 미리 계산되는 이유입니다.
세 메모리 레이어 전반에 하이브리드 검색 — memories, episodes, procedures — 키워드와 시맨틱 신호 모두 사용. 사용자의 쿼리는 저장소를 인덱싱한 동일한 모델로 임베딩되고(Alma의 기본 구성에서 bge-m3 1024차원), 임베딩은 시맨틱하게 유사한 항목을 표면화하기 위해 벡터 인덱스에 대해 실행됩니다. 병렬로 키워드 검색은 시맨틱 검색이 때때로 놓치는 정확한 용어 매치(고유 명사, 코드 식별자, 희귀 기술 용어)에 대해 관계형 인덱스를 칩니다.
두 결과 세트는 병합되고, 중복 제거되고, 후보 예산(기본 레이어당 100 — 기본 벡터 인덱스가 쿼리당 지원하는 최대)으로 캡됩니다. 후보 풀은 스코어링에 들어가는 것입니다; 이 단계 이후에는 검색이 표면화하지 않은 항목을 구할 수 없습니다.
다섯 가지 신호, 프로덕션 스코어링 함수에서 다음과 같이 가중치 부여:
가중치는 의도적으로 조정됩니다: 관련성이 지배하지만 보조 신호는 관련성이 동점일 때 중요합니다(밀도가 높은 메모리 저장소에서 자주 발생합니다). 가중치는 코드베이스에서 위반할 수 없는 불변량입니다 — "AI가 올바른 것을 기억했나"의 사용자가 느끼는 품질이 이 정확한 혼합에 달려 있기 때문에 변경에는 A/B 벤치마크가 필요합니다.
각 티어(memories, episodes, procedures, Soul 블록)는 자체 토큰 예산을 가집니다. 기본값: memories ~2 K 토큰, episodes ~1 K, procedures ~500, Soul 블록 ~500. 총 ~4 K — 어떤 현대 모델의 컨텍스트 창 아래로 잘 들어가고, 캐시 친화적으로 유지될 만큼 작습니다. 각 티어 내에서 스코어링된 항목은 예산이 충족될 때까지 순위 순서로 추가됩니다.
예산은 두 가지 이유로 존재합니다. 첫째, 특정 밀도를 넘어 채우면 모델의 효과적인 컨텍스트가 축소됩니다 — 100K 토큰 프롬프트의 하단에 있는 관련된 것은 어텐션 패턴에 사실상 보이지 않습니다. 둘째, 프롬프트 캐싱은 캐시된 접두사가 안정적인 경우에만 작동합니다; 낮은 신호 메모리로 프롬프트를 부풀리면 캐시가 깨지고 모든 턴이 전체 가격 토큰을 지불하게 됩니다. 엄격한 예산은 품질과 경제 모두를 일치시킵니다.
다섯 섹션이 있는 구조화된 시스템 프롬프트(이 순서로): 정체성(XML로 렌더링된 활성 Soul 블록), 선호도(선호도로 플래그가 지정된 높은 중요도 메모리 항목), 관련 사실(이 쿼리에 대한 최고 점수 memories), 최근 컨텍스트(최고 점수 episodes), 워크플로(최고 점수 procedures). 구조가 중요합니다: 정체성을 맨 위에 두면 완전한 주의를 받습니다; 워크플로를 하단에 두면 모델이 쿼리가 절차적이라고 결정하는 경우에만 참조됩니다.
그런 다음 사용자 메시지가 다음 턴으로 추가됩니다. 모델은 조립된 프롬프트 + 사용자 메시지를 받고 응답을 생성합니다. 사용자의 관점에서 AI는 그냥 답했습니다. 후드 아래에서 조립은 조용히 수천 개의 메모리 레코드를 참조하고 모델에 올바른 30개를 보여주었습니다.
Alma의 프로덕션 배포에서 종단 간 조립 지연 시간은 일반적인 사용자(수백 개의 메모리, 몇 십 개의 episodes)에 대해 30-80 ms 범위에 있습니다. 벡터 검색이 지배(~20-40 ms), 키워드 검색은 병렬로 실행(~5-10 ms), 스코어링은 한 자릿수 ms, 프롬프트 빌드는 본질적으로 무료입니다. 100 ms 목표는 수천 개의 메모리가 있는 사용자에 대해서도 편안한 헤드룸으로 충족됩니다 — 후보 캡과 티어 예산이 저장소가 성장함에 따라 작업을 제한합니다.
스코어링 전, 후보 풀에 대한 모순 감지 패스는 시맨틱하게 충돌하는 0.75-0.92 유사도 범위의 쌍을 플래그합니다. 새 항목이 기본적으로 이깁니다; 이전 항목은 대체로 표시되고 이 턴의 후보 세트에서 제거됩니다(그리고 전역적으로 다음 통합 패스에서). 이는 모델이 "사용자가 X라고 말했다"와 "사용자가 X가 아니라고 말했다"를 함께 받고 사용자가 결코 동의하지 않은 합성을 즉흥적으로 만드는 것을 방지합니다.
전체 라이프사이클(중복 제거, 대체, 감쇠)은 완전한 영속 메모리 가이드에 문서화되어 있습니다; 조립은 이러한 라이프사이클 결정이 쿼리 시간에 나타나는 곳일 뿐입니다.
아키텍처적으로 유사(둘 다 검색, 둘 다 순위, 둘 다 프롬프트에 주입)하지만 코퍼스와 라이프사이클이 다릅니다. RAG는 한 번 작성되고 일정에 따라 재인덱싱되는 외부 문서 코퍼스에서 검색합니다; 항목은 일반적으로 진화하지 않습니다. 메모리 조립은 사용자 자신의 지속적으로 성장하는 저장소에서 검색하며, 항목이 모순되고, 병합되고, 감쇠됩니다. 스코어링 가중치도 다릅니다 — RAG는 주로 유사도와 문서 권위로 순위를 매깁니다; 메모리 조립은 저장소가 개인적일 때 그 신호가 더 중요하기 때문에 중요도, 최근성, 빈도에 가중치를 둡니다. 영속 메모리 vs RAG에서 더 깊은 비교를 참조하세요.
예. POST /api/v1/context/assemble 엔드포인트는 티어별 예산, 최소 점수 임계값, 후보 캡, 카테고리 태그에 대한 부스트 가중치(PM 에이전트가 결정을 부스트할 수 있고, 작가의 에이전트가 목소리 규칙을 부스트할 수 있도록)에 대한 재정의를 허용합니다. 대부분의 팀은 기본값에 머무릅니다 — 즉시 유용하도록 조정되었습니다 — 하지만 레버는 전문화된 수직 시장을 위해 존재합니다.
alma.olivares.ai에서 시작하고, 관심 있는 프로젝트에 대해 20-30개의 메모리를 채운 다음 채팅을 시작하세요. 새 대화에서 모델의 첫 번째 응답은 메모리 저장소의 특정 사실을 참조할 것입니다 — 그것이 조립이며, 사용자 대상 채팅 뒤에 숨겨져 있을 뿐입니다. 직접 통합하는 개발자의 경우: REST API는 원시 조립된 프롬프트를 노출하므로 각 쿼리에 대해 정확히 무엇이 선택되었는지 검사할 수 있습니다.
관련 자료: 컨텍스트 조립 기술 참조 · 3-레이어 메모리 아키텍처 · AI를 위한 영속 메모리: 완전한 2026 가이드 · 영속 메모리 vs RAG · Soul Engine 설명.