Hermes 에이전트를 위한 Hindsight: 로컬 LLM을 활용한 자체 호스팅 메모리

자체 호스팅된 AI 에이전트에는 긴 컨텍스트 윈도우만으로는 부족합니다. 유용한 사실들을 유지하고, 이전 결정들을 검색하며, 프로젝트가 발전함에 따라 자신이 알고 있다고 생각하는 것들을 수정할 수 있는 방식이 필요합니다.

Hermes Agent는 내장된 메모리 파일들을 제공하지만, 외부 프로바이더는 세션 간에 훨씬 더 풍부한 검색을 제공할 수 있습니다. Hindsight는 해당 분야에서 가장 흥미로운 옵션 중 하나입니다. 이 가이드는 클라우드 추론 없이 Hermes를 위해 Hindsight를 설치하는 방법을 설명합니다. 처음에는 올인원 Docker 컨테이너로, 그 다음에는 기존 PostgreSQL 서버와 독립적인 로컬 모델 엔드포인트를 함께 사용하여 설치합니다.

이 가이드는 배포, 로컬 임베딩, 리랭킹, 생성형 모델의 선택 및 연결, auto-retain이 뱅크에 기록하는 것의 제어, Hermes 연결, 그리고 운영 계층인 백업, 마이그레이션, 일상적인 뱅크 위생 관리까지 다룹니다. 예제들은 의도된 포트 스킴을 사용합니다 — 8080은 메인 llama.cpp 서버, 8081은 임베딩, 8082은 리랭킹, 11434은 Ollama — 따라서 이미 사용 중인 포트로 변경하고 메인 모델의 포트와 작은 서버들을 분리해 두어야 합니다.

Hindsight가 하는 일

Hindsight는 retain(보존), recall(기억), reflect(성찰) 세 가지 주요 운영을 가진 영구적인 에이전트 메모리 엔진입니다. Retain은 정보를 추출하고 저장하며, recall은 의미론적, 키워드, 그래프, 시간적 검색을 조합합니다. Reflect는 축적된 메모리로부터 답변을 종합합니다. 백그라운드 통합(consolidation)은 중복된 관찰들을 더 유용한 지식 계층으로 바꿀 수 있습니다.

이것은 단순히 임베딩 데이터베이스가 아닙니다. 벡터 스토어는 유사한 구절을 찾아낼 수 있지만, 메모리 시스템은 또한 시간 순서, 프로젝트 경계, 모순되는 증거, 그리고 결정의 변화도 보존해야 합니다. 이러한 실패 모드는 자기 강화 메모리 루프에서 탐색됩니다.

더 넓은 시장을 보려면 에이전트 메모리 프로바이더 비교를 참조하세요. Hermes의 내장 MEMORY.md, USER.md, 및 메모리 모드는 Hermes Agent 메모리 시스템 가이드에서 다루므로, 이 글은 내장 계층이 어떻게 작동하는지 알고 있다고 가정합니다.

Mnemosyne를 넘어선 이유

Hermes용 Mnemosyne는 SQLite 저장 및 하이브리드 검색을 포함한 매력적인 로컬 퍼스트 아이디어를 제공합니다. 실제로는 설치 제약 사항, 버전 호환성, 쓰기 승인 동작, 그리고 4.0 프리릴리즈를 둘러싼 빠른 변화로 인해 예측 가능하게 운영하기가 어려울 수 있습니다. 이러한 것들은 운영상의 우려 사항이지, Mnemosyne의 메모리 모델이 근본적으로 결함이 있다는 증거는 아닙니다.

Hindsight도 의존성이 없는 것은 아닙니다: 그 Docker 이미지와 로컬 모델은 상당한 디스크 공간을 소모할 수 있습니다. 그 API를 독립 서비스로 실행하고 추론은 다른 곳에서 수행하면, 업그레이드와 문제 해결을 에이전트 자체와 격리할 수 있습니다.

배포 방식 선택

여기서 “올인원"은 Hindsight API, UI, 그리고 데이터베이스가 하나의 컨테이너에 있다는 뜻이며, 추론용 LLM은 여전히 다른 곳에 호스팅됩니다. 이것은 의도적인 것입니다: Docker 공식 Hindsight 이미지는 즉시 사용 가능한 로컬 생성형 llama.cpp 서버를 번들하지 않습니다.

다른 호스트에서 실행 중인 서비스에는 localhost 대신 LAN에 도달 가능한 주소를 사용하세요. 이러한 포트는 신뢰할 수 있는 클라이언트에게만 제한하세요. 예제의 dummy 키는 인증이 아닌 호환성을 위한 플레이스홀더입니다.

옵션 A: 올인원 Hindsight 컨테이너

이것은 Python, Torch, 로컬 모델 의존성으로 Hermes VM을 채우지 않고 Hindsight를 평가하는 가장 간단한 방법입니다. 컨테이너는 Hindsight와 내장 PostgreSQL을 실행하며, 메인 llama.cpp LLM은 메모리 추출과 성찰을 담당합니다.

여기서는 두 개의 이미지 태그가 중요합니다. ghcr.io/vectorize-io/hindsight:latest는 큰 이미지로(AMD64에서 약 9GB), BGE 임베더, MiniLM 리랭커, 그리고 내장 PostgreSQL을 번들하기 때문입니다. latest-slim은 약 500MB이며 그 두 모델이 다른 곳에 존재한다고 가정합니다. 이는 Hindsight를 로컬 모델 서빙 및 연결 섹션의 임베딩 및 리랭킹 설정으로 향하게 했을 때 원하는 것입니다. 헬스 체크가 통과한 후, 특정 태그를 고정하세요. 이동하는 태그는 유지하려는 데이터베이스에 적합하지 않습니다.

Hindsight 호스트에서 디렉터리와 Compose 파일을 생성하세요:

mkdir -p ~/services/hindsight
cd ~/services/hindsight
cat > compose.yaml <<'YAML'
services:
  hindsight:
    image: ghcr.io/vectorize-io/hindsight:latest
    container_name: hindsight
    restart: unless-stopped
    shm_size: 1gb
    extra_hosts:
      - "host.docker.internal:host-gateway"
    ports:
      - "8888:8888"  # Memory API
      - "9999:9999"  # Control-plane UI
    environment:
      HINDSIGHT_API_WORKER_ID: hindsight-standalone
      HINDSIGHT_API_LLM_PROVIDER: openai
      HINDSIGHT_API_LLM_BASE_URL: http://WORKSTATION_IP:8080/v1
      HINDSIGHT_API_LLM_MODEL: LocalMegaLLM
      HINDSIGHT_API_LLM_API_KEY: dummy
      HINDSIGHT_API_LLM_MAX_CONCURRENT: "2"
    volumes:
      - hindsight-pg0:/home/hindsight/.pg0
volumes:
  hindsight-pg0:
YAML

WORKSTATION_IP를 llama.cpp를 실행하는 호스트로 교체하세요. Linux에서 host.docker.internal은 컨테이너가 위에 표시된 host-gateway 매핑을 선언한 경우에만 해석됩니다. 없다면 http://host.docker.internal:8080/v1의 기본 URL은 아무 곳도 가리키지 않습니다. 1GB의 공유 메모리 예약은 내장 PostgreSQL 인덱싱에 특히 유용합니다; Docker의 작은 기본 /dev/shm은 실패를 초래할 수 있습니다. 이름이 지정된 볼륨은 컨테이너가 다시 생성될 때 데이터베이스를 보존하며, 바인드 마운트 대안은 이미지 내부의 사용자인 uid 1000에 의해 소유되어야 합니다.

HINDSIGHT_API_WORKER_ID는 재작성(재생성) 사이에 안정적으로 유지되어야 합니다 — Docker의 기본값은 컨테이너 호스트명이며, 컨테이너가 사망했을 때 진행 중이던 작업은 구 worker id 아래에서 막혀 있게 됩니다.

docker compose up -d
docker compose logs -f --tail=100
curl -f http://localhost:8888/health

설치된 Hindsight 버전이 다른 경로에서 health를 노출하는 경우, http://localhost:8888/docs와 컨테이너 로그를 확인하세요. 제어 평면은 일반적으로 http://HINDSIGHT_HOST:9999에서 사용할 수 있습니다. 기본 배포가 작동한 후, 컨테이너 내부에서 기본 모델을 로드하는 대신 그 임베딩과 리랭킹 프로바이더를 로컬 모델 서빙 및 연결의 설정으로 향하게 할 수도 있습니다.

포트 8888 또는 9999를 인터넷에 직접 노출하지 마세요. 사설 네트워크 또는 인증된 리버스 프록시를 사용하세요. 내장 PostgreSQL은 테스트에는 편리하지만, 외부에서 관리되는 데이터베이스는 백업 및 유지 보수가 더 쉽습니다.

옵션 B: 기존 PostgreSQL 서버를 사용하는 Hindsight

장기간 실행될 설치의 경우, Hindsight API, 데이터베이스, 추론 엔드포인트를 분리해 두는 것을 선호합니다. Hindsight VM은 무거운 모델이 아닌 오케스트레이션과 HTTP 서비스를 실행하므로 작게 유지할 수 있습니다.

PostgreSQL 및 pgvector 준비

Hindsight에는 PostgreSQL 14 이상과 hindsight 데이터베이스에 벡터 확장(extension)이 필요합니다. 이 확장은 데이터베이스별로 작동합니다: 서버에서 패키지를 설치해도 CREATE EXTENSION이 실행되기 전까지는 아무것도 하지 않습니다. Debian 또는 Ubuntu PostgreSQL 서버에서, 실제 PostgreSQL 메저 버전에 맞는 pgvector 패키지를 설치하세요; 예를 들어 PostgreSQL 16의 경우:

sudo apt update
sudo apt install postgresql-16-pgvector

패키지 이름과 가용성은 구성된 apt 저장소에 따라 다릅니다. 사용할 수 없다면 pgvector 설치 설명서를 따르거나, PostgreSQL PGDG 저장소에서 호환 가능한 패키지를 설치하세요. 공유 서버에서 PostgreSQL 메저 버전을 무심코 변경하지 마세요.

PostgreSQL 관리자로서 전용 역할과 데이터베이스를 생성하세요:

CREATE ROLE hindsight LOGIN PASSWORD 'REPLACE_WITH_LONG_PASSWORD';
CREATE DATABASE hindsight OWNER hindsight;

새 데이터베이스에 연결하고 확장을 활성화하세요:

sudo -u postgres psql -d hindsight -c \
  'CREATE EXTENSION IF NOT EXISTS vector;'
sudo -u postgres psql -d hindsight -c \
  "SELECT extname, extversion FROM pg_extension WHERE extname = 'vector';"

확장은 보통 설치에 elevated 권한이 필요합니다; 애플리케이션 역할은 superuser일 필요가 없습니다. Hindsight는 기본적으로 pgvector를 사용하며, 반복적 ANN 스캔을 위해 0.8.0 이상을 원합니다; 오래된 서버는 그 설정을 거부합니다. HINDSIGHT_API_VECTOR_EXTENSION은 대안으로 pgvectorscale(Hindsight가 매우 큰 뱅크를 위해 문서화한 DiskANN 옵션) 또는 vchord를 선택할 수 있으며, 둘 다 이 정확한 PostgreSQL 빌드에 추가 패키징이 필요합니다. 메모리가 존재한 후 알고리즘을 전환하면 시작이 멈추고 마이그레이션을 요구하므로, 첫 retain 전에 선택하세요. 개인 Hermes 뱅크의 경우, pgvector를 설치하고 그 후로 변경하지 않는 것이 좋습니다.

pg_hba.conf를 통해 Hindsight 호스트만 허용하세요, 예를 들어:

host  hindsight  hindsight  192.168.1.50/32  scram-sha-256

PostgreSQL listen_addresses를 적절히 설정하고, 호스트 간 연결에는 TLS 또는 신뢰할 수 있는 사설 네트워크를 사용하세요. 이 데이터베이스는 Hindsight Docker 컨테이너와 독립적으로 백업하세요. 서버가 다른 애플리케이션과 공유되는 경우, Hindsight를 그 자체 데이터베이스에 두거나, 자신이 소유한 스키마로 HINDSIGHT_API_DATABASE_SCHEMA를 설정하세요; 기본 스키마는 public입니다.

PostgreSQL에 대한 Hindsight 실행

Hindsight VM에서 compose.yaml을 생성하세요. 이 버전은 의도적으로 로컬에서 PostgreSQL을 시작하지 않습니다:

services:
  hindsight:
    image: ghcr.io/vectorize-io/hindsight:latest-slim
    restart: unless-stopped
    ports:
      - "8888:8888"
      - "9999:9999"
    env_file: .env
    environment:
      HINDSIGHT_API_LLM_PROVIDER: openai
      HINDSIGHT_API_LLM_BASE_URL: http://WORKSTATION_IP:8080/v1
      HINDSIGHT_API_LLM_MODEL: LocalMegaLLM
      HINDSIGHT_API_LLM_API_KEY: dummy
      HINDSIGHT_API_LLM_MAX_CONCURRENT: "2"
      HINDSIGHT_API_DB_POOL_MIN_SIZE: "2"
      HINDSIGHT_API_DB_POOL_MAX_SIZE: "10"
      HINDSIGHT_API_WORKER_ID: hindsight-standalone

외부 데이터베이스 URL을 .env라는 파일에 저장하세요:

HINDSIGHT_API_DATABASE_URL=postgresql://hindsight:YOUR_PASSWORD@POSTGRES_IP:5432/hindsight

chmod 600 .env
docker compose up -d
docker compose logs -f --tail=100

패스워드에 @, :, / 또는 기타 예약된 URL 문자가 포함된 경우, 연결 문자열에 넣기 전에 URL 인코딩하세요. Hindsight VM이 PostgreSQL 포트 5432에 도달할 수 있는지, 그리고 pg_hba.conf가 Hindsight 호스트를 허용하는지 테스트하세요 — 127.0.0.1에만 바인딩된 서버는 URL이 올바르게 보여도 연결을 거부합니다. 첫 시작 시 데이터베이스 마이그레이션이 실행되도록 허용하세요; HINDSIGHT_API_RUN_MIGRATIONS_ON_STARTUP=false를 설정하지 않는 한 시작 시 마이그레이션이 실행됩니다. API와 데이터베이스가 실행되면, Hermes를 연결하기 전에 Hindsight용 모델 선택과 로컬 모델 서빙 및 연결을 계속하세요.

Hindsight용 모델 선택

Deploy는 API와 데이터베이스를 네트워크에 올려놓습니다. 다음 결정은 세 가지 추론 역할(검색을 위한 임베딩, 정렬을 위한 리랭커, retain, reflect, 통합을 위한 생성형 LLM)에 어떤 모델이 들어갈 것인지입니다. 이미 대화로 GPU가 분주한 CPU Hindsight 호스트에 대한 실용적인 기본값은 인-프로세스 Qwen/Qwen3-Embedding-0.6B, 인-프로세스 BAAI/bge-reranker-v2-m3, 그리고 생성 작업에 대한 공유 llama.cpp 챗 모델입니다.

임베딩 모델

Hindsight는 시작 시 임베딩 차원을 읽고 뱅크를 그에 맞춰 크기 조절하므로, 첫 retain 시 선택한 모델은 재구축할 때까지 뱅크가 유지하는 모델입니다. 리더보드 순위보다 차원 및 인스트럭션 동작이 더 중요합니다: 뱅크가 이미 384차원 또는 1024차원이라면, 더 강한 8B 임베더가 마이그레이션을 할 가치가 있는 것은 아닙니다. 아래 행들은 가장 가볍从重에서 가장 무겁게 정렬되어 있으며, RAM 수치는 CPU(FP16 / 일반적인 로컬 로드)의 근사치 로드 부피이지, GGUF 파일 크기가 아닙니다.

모델이 어떻게 실행되는지도 선택의 또 다른 절반입니다. Hindsight의 임베딩 프로바이더, 가장 단순한 것에서 가장 많은 부품이 필요한 것까지:

Qwen3-Embedding-0.6B는 외부 임베딩 서비스가 필요하지 않습니다. CPU Hindsight 호스트에서는 local 프로바이더로 API 프로세스 내에서 로드됩니다 — Hugging Face는 첫 시작 시 가중치를 다운로드하고, 프로바이더는 모델의 검색 인스트럭션을 스스로 적용합니다:

# Compose environment (or equivalent .env keys)
HINDSIGHT_API_EMBEDDINGS_PROVIDER: local
HINDSIGHT_API_EMBEDDINGS_LOCAL_MODEL: Qwen/Qwen3-Embedding-0.6B

외부 OpenAI 호환 엔드포인트는 임베더를 다른 머신이나 API 프로세스 밖으로 두기를 원할 때만 사용하세요. Ollama는 그러한 호스트 중 하나입니다:

# Embeddings: Qwen3-Embedding-0.6B on Ollama
HINDSIGHT_API_EMBEDDINGS_PROVIDER: openai
HINDSIGHT_API_EMBEDDINGS_OPENAI_BASE_URL: http://192.168.1.123:11434/v1
HINDSIGHT_API_EMBEDDINGS_OPENAI_MODEL: qwen3-embedding:0.6b-q8_0
HINDSIGHT_API_EMBEDDINGS_OPENAI_API_KEY: dummy

추론 머신의 ollama list에서 보이는 대로 호스트, 포트, 태그를 교체하세요.

HINDSIGHT_API_EMBEDDINGS_QUERY_PREFIX는 프로바이더에 따라 다릅니다:

외부 경로의 경우, 다음을 설정하세요:

# Real newline before Query:. Bash $'...' is the reliable way to pass it.
HINDSIGHT_API_EMBEDDINGS_QUERY_PREFIX=$'Instruct: Given a web search query, retrieve relevant passages that answer the query\nQuery:'
HINDSIGHT_API_EMBEDDINGS_PASSAGE_PREFIX=

Compose YAML에서 동일한 문자열은 명시적인 \n(또는 리터럴 멀티라인 값)이 필요합니다. 첫 retain 전에 프리픽스를 설정하세요: 나중에 변경하면 구 벡터와 새 쿼리가 더 이상 같은 공간에 존재하지 않게 됩니다.

리더보드 위치보다 더 많은 것을 결정하는 두 가지 속성입니다. 인스트럭션 민감성: Qwen3 임베딩은 query 측에서 검색 인스트럭션을 적용합니다; OpenAI 호환 서버에서 매칭되는 프리픽스가 없으면, 저장 측과 query 측이 더 이상 같은 공간에 존재하지 않게 됩니다. 차원 고정: 폭은 시작 시 한 번만 읽히므로, 나중에 0.6B에서 4B로 이동하는 것은 설정 변경이 아닌 뱅크 마이그레이션이며 — 심지어 같은 차원의 교환(BGE-M3 ↔ Qwen3-0.6B, 또는 768에서 EmbeddingGemma 2 ↔ nomic)도 벡터 공간을 변경하므로, 뱅크 벡터는 자동으로 재계산되지 않습니다. 새로운 뱅크 또는 수동 재임베딩/재인덱싱을 계획하세요; 메모리 뱅크의 내보내기, 가져오기, 마이그레이션을 참조하세요. BGE-small을 떠난 후, 새 점수 분포에 대해 recall_min_scores를 탐색하세요 — BGE-small에서 교정된 임계값은 Qwen3-0.6B에 대해 너무 조일 수 있어 리랭커가 후보를 얻지 못하게 할 수 있습니다. Qwen3 가족의 벤치마크 및 GGUF/Ollama 배경을 보려면 Ollama의 Qwen3 Embedding 및 Reranker 모델을 참조하세요.

리랭킹 모델

임베딩은 후보 집합을 검색하고; 리랭커는 각 query/passage 쌍에 점수를 매겨 Hindsight가 주입하기 전에 재배열합니다. local 프로바이더로, Hindsight는 SentenceTransformers 크로스 인코더(또는 지원되는 생성형 리랭커)를 로드합니다. 외부 Cohere 호환 엔드포인트로, 그것은 전체 Cohere 스타일 바디를 HINDSIGHT_API_RERANKER_COHERE_BASE_URL로 POST합니다. 리랭커는 선택 사항이지만, 임베더가 고정된 후에는 보통 가장 큰 검색 품질 레버이며 — 그리고 CPU에서는 종종 검색 벽시계의 대부분을 차지합니다. 행들은 가장 가볍从重에서 가장 무겁게 정렬되어 있습니다.

클라우드 API 리랭커(Cohere, ZeroEntropy, Alibaba qwen3-rerank, TypeSafe 등)는 Hindsight에서 작동하지만 메모리 텍스트를 박스 밖으로 전송합니다. 로컬 전용 크로스 도메인 레이아웃에서는 범위 밖입니다.

선택을 지배하는 두 가지 운영 제약 사항이 있습니다. VRAM: 대화 모델이 이미 GPU를 포화시키고 있다면(예: 여유가 없는 16GB 카드에서 Qwen3.8-27B Q5), 모든 “GPU 권장” 행은 제외되고 라이브 선택은 CPU의 MiniLM 또는 BGE-v2-m3로 축소됩니다. 후보 수: HINDSIGHT_API_RERANKER_MAX_CANDIDATES(아래 외부 엔드포인트 예시에서 30)는 모델이 점수를 다시 매기는 passage 수를 제한합니다; 각 후보는 전체 전달 패스이므로, 모델 계층을 뛰기 전에 하한을 줄이세요. llama.cpp를 통한 Qwen3의 경우, GGUF는 랭킹 헤드를 유지해야 합니다 — 이를 떨어뜨리는 오래된 convert_hf_to_gguf.py는 모든 passage를 0 근처로 점수 매깅니다 — 그리고 생성형 스코어링 경로가 확인될 때까지 알려진 좋음/나쁨 passage 테스트가 필요합니다.

생성형 LLM 계층

임베딩 및 리랭킹 모델은 메모리를 추출하고 추론하는 데 사용되는 생성형 LLM의 대체재가 아닙니다. Hindsight는 기본 LLM과 운영 특화 오버라이드를 지원하며, 이는 같은 llama.cpp 서버 또는 독립 엔드포인트를 대상으로 할 수 있습니다.

이것들은 운영 권장 사항이지, Hindsight 공식 최소 파라미터 수치가 아닙니다. 작은 모델은 포트 번호를 올바르게 추출하되, 이전 아키텍처 결정이 대체되었음을 놓칠 수 있습니다. 명명된 파라미터 수보다 구조화된 출력 신뢰성과 부정 표현의 충실한 처리가 더 중요합니다. Hindsight 자체의 온도 기본값은 그대로 두는 것이 좋습니다 — retain에 0.1, 통합에 0.0, reflect에 0.9 — 그리고 retain과 통합의 경우, llama.cpp 빌드에 있다면 non-thinking 별명을 서빙하는 가치가 있습니다. 작은 Qwen3.5 체크포인트는 사고 모드에서 많은 토큰을 소비하기 때문입니다.

기존 Qwen3.8-27B llama.cpp 엔드포인트가 있는 배포의 경우, 낮은 동시성으로 생성형 Hindsight 작업에 걸쳐 공유하는 것으로 시작하세요:

HINDSIGHT_API_LLM_PROVIDER=openai
HINDSIGHT_API_LLM_BASE_URL=http://WORKSTATION_IP:8080/v1
HINDSIGHT_API_LLM_MODEL=LocalMegaLLM
HINDSIGHT_API_LLM_API_KEY=dummy
HINDSIGHT_API_LLM_MAX_CONCURRENT=2
HINDSIGHT_API_RETAIN_LLM_MAX_CONCURRENT=1
HINDSIGHT_API_CONSOLIDATION_LLM_MAX_CONCURRENT=1

나중에, 일상적인 추출을 독립 9B 모델로 라우팅하고 27B를 어려운 reflect에 예약하세요:

HINDSIGHT_API_RETAIN_LLM_PROVIDER=openai
HINDSIGHT_API_RETAIN_LLM_BASE_URL=http://MEMORY_LLM_HOST:8083/v1
HINDSIGHT_API_RETAIN_LLM_MODEL=MemoryLLM
HINDSIGHT_API_RETAIN_LLM_API_KEY=dummy

HINDSIGHT_API_REFLECT_LLM_PROVIDER=openai
HINDSIGHT_API_REFLECT_LLM_BASE_URL=http://WORKSTATION_IP:8080/v1
HINDSIGHT_API_REFLECT_LLM_MODEL=LocalMegaLLM
HINDSIGHT_API_REFLECT_LLM_API_KEY=dummy

작은 4B 모델은 경제적이지만 테스트가 필요합니다; 9B는 품질/성능 타협점에서 합리적입니다. retain과 통합이 작은 모델을 공유하면, HINDSIGHT_API_CONSOLIDATION_LLM_BATCH_SIZE를 2로 낮추세요 — 8인 기본 배치의 작은 컨텍스트 윈도우에는 긴 프롬프트입니다. Qwen3.6-35B-A3B는 별도의 잘 공급된 추론 서버에는 매력적입니다(약 30억 활성 파라미터를 가진 mixture-of-experts 모델이므로, 작은 활성 모델로 예산을 세우세요), 반면 27B dense 모델은 모든 일상적인 retain 이벤트에 대해 보통 불필요합니다. 백그라운드 동시성 제한은 Hermes 대화 모델을 메모리 유지보수 버스트로부터 보호합니다.

로컬 모델 서빙 및 연결

모델 선택 섹션의 인-프로세스 local 임베딩 및 리랭커 설정이 충분하다면, 외부 Ollama 및 llama.cpp 하위 섹션을 건너뛰고 연결으로 점프하거나, Compose를 거기에 표시된 local 기본값으로 남겨둘 수 있습니다. 임베더 또는 리랭커를 다른 호스트에 두어야 할 때 외부 엔드포인트가 중요합니다.

외부 임베딩: Ollama 또는 llama.cpp

외부 임베딩은 Qwen3-Embedding-0.6B(또는 다른 모델)를 별도 호스트에 두기를 원할 때입니다. 두 가지 실용적인 옵션이 있습니다: 모델 획득과 서빙을 거의 설정 없이 처리하는 Ollama, 그리고 GGUF 양자화, CPU 스레드, 디바이스 배치, 배치 처리에 대한 정밀한 제어를 제공하는 llama.cpp. 두 Qwen3 모델 모두의 모델 배경 및 벤치마크는 Ollama의 Qwen3 Embedding 및 Reranker 모델에 있습니다.

Qwen3-Embedding-0.6B는 1024차원 벡터를 반환하며, Hindsight는 시작 시 그 폭을 읽고 데이터베이스를 그에 맞춰 크기 조절합니다. 번들된 384차원 BGE 모델로 생성된 뱅크는 이 모델을 받아들일 수 없습니다 — 빈 데이터베이스 또는 볼륨에서 시작하고, 첫 retain 전에 임베딩 모델을 결정하세요. 나중에 임베딩 프로바이더를 전환하면, 두 모델이 같은 차원을 사용하더라도 저장된 레코드를 재임베딩해야 합니다.

옵션 1: Qwen3-Embedding-0.6B를 위한 Ollama

공식 Linux 설치 문서를 사용하여 추론 호스트에 Ollama를 설치한 후, 임베딩 모델을 시작하세요:

ollama pull qwen3-embedding:0.6b
ollama serve

원격 액세스를 위해, Ollama의 서비스 환경에서 OLLAMA_HOST=0.0.0.0:11434를 구성하고, 서비스를 재시작하며, Hindsight VM에 대한 방화벽을 설정하세요 — 절차는 Ollama 원격 액세스에서 다룹니다. 127.0.0.1에만 바인딩된 데몬은 Hindsight 컨테이너에 보이지 않습니다. ollama list로 모델 이름을 먼저 확인하고, 표준 임베딩 엔드포인트를 테스트하세요:

curl http://EMBED_HOST:11434/api/embed \
  -H 'Content-Type: application/json' \
  -d '{"model":"qwen3-embedding:0.6b","input":"A test memory"}'

Hindsight의 OpenAI 임베딩 프로바이더는 대신 Ollama의 OpenAI 호환 /v1/embeddings 엔드포인트를 호출합니다. Hindsight를 구성하기 전에 그 엔드포인트가 Ollama 버전과 함께 작동하는지 확인하세요. Ollama는 임베딩에 대해 단순합니다; 그 API가 호환되는 리랭킹 엔드포인트를 제공한다고 가정하지 마세요. 리랭킹을 위해, 아래 인-프로세스 local BGE 경로를 선호하거나, 점수를 검증한 후 별도의 llama.cpp / TEI 엔드포인트를 사용하세요.

옵션 2: Qwen3-Embedding-0.6B를 위한 llama.cpp

검증된 Qwen3-Embedding-0.6B GGUF 변환을 다운로드하세요. 실제로 다운로드한 GGUF 파일명을 사용하세요:

#!/bin/sh
# start-embedding.sh - CPU-only embedding server
set -eu
cd "$HOME/prj"
exec ./llama.cpp/llama-server \
  --host 0.0.0.0 --port 8081 \
  --model "$HOME/ggufs/Qwen3-Embedding-0.6B-Q8_0.gguf" \
  --alias qwen3-embedding-0.6b \
  --embedding --pooling last \
  --ctx-size 4096 --parallel 1 \
  --threads 4 --threads-batch 4 \
  --batch-size 512 --ubatch-size 256 \
  --n-gpu-layers 0

Qwen3 임베딩은 일부 BGE 모델이 사용하는 CLS 풀링과 달리 last-token 풀링을 사용합니다. GPU가 큰 대화 모델로 점유된 워크스테이션에서 CUDA 초기화를 전혀 원하지 않는다면 CPU 전용 llama.cpp 빌드를 선호하세요. 이 임베딩 서버에서 --reranking을 활성화하지 마세요: 그 조합은 제로 벡터를 얻는 알려진 방법입니다.

curl -s http://EMBED_HOST:8081/v1/embeddings \
  -H 'Content-Type: application/json' \
  -d '{"model":"qwen3-embedding-0.6b","input":"A test memory"}' \
  | jq '.data[0].embedding | length'

전체 차원 Qwen3-Embedding-0.6B 출력에는 1024개의 부동소수점이 포함되어야 합니다. GGUF 변환과 Hindsight query/document 인스트럭션 처리가 호환되는지 확인하세요; 인스트럭션에 민감한 임베딩 모델은 프롬프트가 잘못되면 정확도를 잃을 수 있습니다.

리랭커: 로컬 BGE 또는 llama.cpp를 통한 Qwen3

리랭킹은 임베딩과 다릅니다: 모델은 각 query/document 쌍에 점수를 매겨 관련성 점수를 반환합니다. CPU 전용 Hindsight 호스트에서 — 또는 대화 GPU에 VRAM 여유가 없을 때 — 실용적인 경로는 BAAI/bge-reranker-v2-m3(또는 가벼운 MiniLM 기본값)를 사용한 Hindsight의 local 프로바이더입니다. 사이드카가 필요하지 않습니다:

HINDSIGHT_API_RERANKER_PROVIDER=local
HINDSIGHT_API_RERANKER_LOCAL_MODEL=BAAI/bge-reranker-v2-m3
HINDSIGHT_API_RERANKER_MAX_CANDIDATES=20

Qwen3-Reranker-0.6B는 생성형 yes-token 스코어러이지, 고전적 크로스-인코더가 아닙니다. 랭킹을 위한 GGUF 변환으로 llama.cpp를 통해 서빙할 수 있지만, 알려진 좋음/나쁨 쌍에서 점수를 확인하기 전까지 그 경로를 실험적이라 취급하세요: 랭킹 헤드를 떨어뜨리는 오래된 convert_hf_to_gguf.py는 모든 passage를 0 근처로 점수 매깅고, llama.cpp의 네이티브 /rerank 경로에는 이 가족에 대한 알려진 오타점수 보고가 있습니다.

#!/bin/sh
# start-reranker.sh - GPU or CPU as selected by --n-gpu-layers
set -eu
cd "$HOME/prj"
exec ./llama.cpp/llama-server \
  --host 0.0.0.0 --port 8082 \
  --model "$HOME/ggufs/Qwen3-Reranker-0.6B-Q8_0.gguf" \
  --alias qwen3-reranker-0.6b \
  --embedding --reranking --pooling rank \
  --ctx-size 4096 --parallel 1 \
  --batch-size 512 --ubatch-size 256 \
  --n-gpu-layers 99

CPU에서 실행하려면 --n-gpu-layers 0을 설정하세요. GPU 버전은 모델 가중치뿐만 아니라 계산 버퍼와 컨텍스트에 추가 VRAM이 필요합니다; 파일 크기가 GPU 할당의 전체라고 가정하지 마세요.

curl -s http://RERANK_HOST:8082/v1/rerank \
  -H 'Content-Type: application/json' \
  -d '{"model":"qwen3-reranker-0.6b", "query":"PostgreSQL storage", "documents":["Hindsight stores memories in PostgreSQL.","A recipe for bread."], "top_n":2}' \
  | jq

PostgreSQL 문서가 관련 없는 문서보다 높은 순위를 받아야 하며, 모든 관련성 점수가 제로이면 GGUF가 잘못된 변환을 의미하며, 사실이 저장되어 있어도 검색은 무작위로 보일 것입니다. results[].index와 results[].relevance_score의 정확한 구조를 확인하세요: Hindsight는 Cohere 호환 리랭킹 응답을 기대하고, llama.cpp 호환성은 빌드마다 달라질 수 있습니다.

엔드포인트를 Hindsight에 연결

Hindsight Compose 서비스에 다음 환경 설정을 추가하거나, .env 파일에 저장하세요. 하나의 임베딩 경로를 선택하세요 — 인-프로세스 local, Ollama, 또는 llama.cpp — 두 가지를 동시에 사용하지 마세요.

# Option A: in-process Qwen3 on the Hindsight host (CPU; no sidecar)
HINDSIGHT_API_EMBEDDINGS_PROVIDER=local
HINDSIGHT_API_EMBEDDINGS_LOCAL_MODEL=Qwen/Qwen3-Embedding-0.6B

# Option B: llama.cpp embedding service
# HINDSIGHT_API_EMBEDDINGS_PROVIDER=openai
# HINDSIGHT_API_EMBEDDINGS_OPENAI_BASE_URL=http://EMBED_HOST:8081/v1
# HINDSIGHT_API_EMBEDDINGS_OPENAI_MODEL=qwen3-embedding-0.6b
# HINDSIGHT_API_EMBEDDINGS_OPENAI_API_KEY=dummy
# HINDSIGHT_API_EMBEDDINGS_OPENAI_BATCH_SIZE=8
# HINDSIGHT_API_EMBEDDINGS_QUERY_PREFIX=$'Instruct: Given a web search query, retrieve relevant passages that answer the query\nQuery:'
# HINDSIGHT_API_EMBEDDINGS_PASSAGE_PREFIX=

# Option C: Ollama on another host
# HINDSIGHT_API_EMBEDDINGS_PROVIDER=openai
# HINDSIGHT_API_EMBEDDINGS_OPENAI_BASE_URL=http://192.168.1.40:11434/v1
# HINDSIGHT_API_EMBEDDINGS_OPENAI_MODEL=qwen3-embedding:0.6b-q8_0
# HINDSIGHT_API_EMBEDDINGS_OPENAI_API_KEY=dummy
# HINDSIGHT_API_EMBEDDINGS_QUERY_PREFIX=$'Instruct: Given a web search query, retrieve relevant passages that answer the query\nQuery:'
# HINDSIGHT_API_EMBEDDINGS_PASSAGE_PREFIX=

# Option: local BGE reranker (no sidecar; preferred on CPU)
HINDSIGHT_API_RERANKER_PROVIDER=local
HINDSIGHT_API_RERANKER_LOCAL_MODEL=BAAI/bge-reranker-v2-m3
HINDSIGHT_API_RERANKER_MAX_CANDIDATES=20

# Option: llama.cpp Cohere-compatible rerank endpoint (validate Qwen3 scores first)
# HINDSIGHT_API_RERANKER_PROVIDER=cohere
# HINDSIGHT_API_RERANKER_COHERE_BASE_URL=http://RERANK_HOST:8082/v1/rerank
# HINDSIGHT_API_RERANKER_COHERE_MODEL=qwen3-reranker-0.6b
# HINDSIGHT_API_RERANKER_COHERE_API_KEY=dummy
# HINDSIGHT_API_RERANKER_MAX_CANDIDATES=30

변수 이름은 프로바이더 특화이며, 거의 일치하는 것은 침묵합니다: HINDSIGHT_API_EMBEDDINGS_BASE_URL은 잘못된 키이며, Hindsight는 로컬 서버 대신 OpenAI 자체의 임베딩 엔드포인트를 조용히 목표로 삼습니다. HINDSIGHT_API_EMBEDDINGS_OPENAI_BASE_URL을 사용하세요. Cohere 호환 리랭커 경로로, Hindsight는 전체 Cohere 스타일 바디를 HINDSIGHT_API_RERANKER_COHERE_BASE_URL로 POST합니다; 컨테이너 로그에 /v1/rerank/rerank에 대한 404가 표시되면, 여러분의 빌드가 스스로 /rerank를 추가하는 것이고, 값은 /v1에서 끝나야 합니다.

옵션 B와 C의 경우, 임베딩 모델의 HINDSIGHT_API_EMBEDDINGS_QUERY_PREFIX 값을 사용하세요(옵션 A는 설정 안 함). 첫 retain 후 실제 메모리로 query-to-passage 검색을 테스트하세요.

무엇을 기억하는지 제어

스택이 실행되면, 다음 실패 모드는 보통 쓰기 경로입니다: Hermes는 기본적으로 auto_retain: true이므로, 모든 대화 턴이 뱅크에 추출될 수 있습니다. 잘못된 추측, 폐기된 계획, 탐색적 진술이 검색 가능한 사실이 되며, 나중에 recall은 그것들을 증거로 취급합니다 — 자기 강화 메모리 루프에서 설명된 루프입니다. Hindsight를 포함한 다른 프로바이더에 대한 캡처 정책은 에이전트 메모리 프로바이더 비교에서 요약됩니다.

현재 존재하는 캡처 모드

auto_retain을 false로 설정하면 자동 저장이 비활성화됩니다. 이것은 각 쓰기 전에 인간 승인 대화상자를 추가하지 않습니다. 에이전트는 여전히 툴이 허용할 때 언제든지 hindsight_retain을 호출할 수 있으며, 명시적 retain을 검토 대기 큐가 아닌 의도된 캡처로 취급하세요.

승인 큐의 공백

일반적인 바람은 뱅크에 들어가기 전에 검토하고 승인할 후보 메모리의 대기 큐입니다. Hindsight under Hermes는 오늘 그 계약을 제공하지 않습니다. Hermes용 Mnemosyne는 일부 버전에서 프로바이더 특화 단계별 쓰기를 구현합니다; 그 경로는 공유 Hermes 표준이 아니며 Hindsight 플러그인에 적용되지 않습니다. 상위 승인 흐름이 존재할 때까지, 실행 가능한 패턴은 auto_retain: false, 의도적인 hindsight_retain, 그리고 다음 세션이 잘못된 사실에 의존하기 전에 Hindsight 제어 평면 UI에서 검사 또는 삭제입니다. config.json에서 찾을 Hindsight를 위한 누락된 write_approval 키는 없습니다.

뱅크 스티어링(미션, 레이블, 지시사항, 정신 모델)

사람들은 종종 다음 계층을 “파인튜닝"이라고 부릅니다. Hindsight에서는 대부분 Hermes config.json만이 아니라 뱅크 구성입니다: 미션과 추출 설정은 retain이 무엇을 유지하는지 스티어링하며; 레이블은 엔티티를 구조화하고; 지시사항과 정신 모델은 나중에 종합을 형성합니다.

미션, 간결한 추출, 레이블은 노이즈를 줄이고 검색을 개선합니다. 정확성이 완전성보다 중요할 때 auto-retain을 끄는 것을 대체하지 않습니다. 내구적인 프로젝트 결정을 이름으로 지목하고 채팅 로지스틱스를 무시하는 짧은 retain 미션을 선호하세요; 실제 분류법이 있을 때만 엔티티 레이블을 추가하세요; 뱅크가 이미 깨끗한 사실을 가지고 있을 때 2~3개의 반복 질문에 대한 정신 모델을 추가하세요.

권장 위생 프로필

개인 Hermes 뱅크를 위한 구체적인 시작점:

{
  "mode": "local_external",
  "api_url": "http://HINDSIGHT_VM_IP:8888",
  "bank_id": "hermes",
  "memory_mode": "hybrid",
  "auto_recall": true,
  "recall_sync": false,
  "auto_retain": false,
  "retain_async": true,
  "recall_prefetch_method": "recall"
}

뱅크에서 retain 미션을 설정하고 추출을 concise 모드로 남겨두세요(제어 평면 또는 Banks API를 통해). 명시적 retain 후, UI를 열고 관찰을 확인하며, 통합 또는 정신 모델 갱신 실행 전에 실수를 삭제하세요. recall_prefetch_method은 recall로 남겨두세요 — reflect는 각 턴 전에 챗 모델 호출을 소비하며 근본적인 사실 대신 종합을 주입합니다.

Hermes Agent를 Hindsight에 연결

Hermes VM에서, 카탈로그 플러그인을 설치한 후, 설정 마법사를 실행하세요. Hindsight와 local_external 모드를 선택하세요; 플러그인은 내장 PostgreSQL을 시작하거나 로컬에서 Hindsight 모델 스택을 실행할 필요가 없으며, local_embedded는 방금 실행한 컨테이너 옆에 두 번째 Hindsight 데몬을 시작할 것입니다.

hermes plugins install hindsight
hermes memory setup hindsight

Hindsight를 사용하는 에이전트 역할의 흥미로운 옵션 세트가 있습니다.

hermes memory status

외부 Hindsight 연결은 ~/.hermes/hindsight/config.json에 있습니다. 연속 캡처(Hermes 기본값)를 유지하는 일러스트레이티브 구성은 다음과 같습니다:

{
  "mode": "local_external",
  "api_url": "http://HINDSIGHT_VM_IP:8888",
  "bank_id": "hermes",
  "memory_mode": "hybrid",
  "auto_recall": true,
  "recall_sync": false,
  "auto_retain": true,
  "retain_async": true,
  "retain_every_n_turns": 1
}

명시적 전용 retain 및 뱅크 스티어링을 위해, auto_retain을 켜둔 대신 무엇을 기억하는지 제어의 위생 프로필을 사용하세요. recall_sync: false는 상호작용 응답성을 우선시하지만 다음 턴에 검색된 컨텍스트를 주입할 수 있습니다. 현재 요청이 모델이 답변을 시작하기 전에 최신 메모리를 포함해야 하는 경우 동기식 recall을 사용하세요. retain_async: true은 메모리가 처리되는 동안 일상적인 응답을 차단하지 않습니다.

플러그인의 recall 기본값은 관찰 전용입니다; 원시 월드 및 경험 사실은 통합이 관찰을 쓰기 전이거나, recall_types를 observation,world,experience로 넓히기 전까지 뱅크에 남아 프롬프트 밖으로 유지됩니다. 첫 주 동안 이를 넓히고 제어 평면을 관찰한 후, 좁히는 것은 합리적인 순서입니다.

내장 Hermes 메모리는 프로바이더 옆에서 활성 상태로 유지됩니다; Hindsight가 무엇을 추가하는지 배우는 동안 MEMORY.md와 USER.md를 켜둔 것은 괜찮으며, 메모리 시스템 아티클은 평평한 파일들을 유지할지 결정할 곳입니다.

게이트웨이가 이미 실행 중이면 재시작하세요:

hermes gateway restart
hermes memory status

상태는 Hindsight가 활성 프로바이더라고 식별해야 합니다. 더 넓은 명령 레퍼런스를 포함하여, Hermes TUI 및 플러그인 명령을 보려면 Hermes Agent CLI 치트시트를 참조하세요.

설치만이 아닌 메모리 검증

Hermes에게 테스트 프로젝트에 대한 일회용 사실을 기억하라고 요청하고, 다른 세션을 시작하여 그 사실을 다시 요청하세요. Retention은 기본적으로 비동기이며 추출은 챗 모델을 기다리므로, 판단하기 전에 메인 llama.cpp 서버에게 잠시 시간을 주세요. 그런 다음 더 어려운 경우를 테스트하세요: Hermes에게 이전 결정이 변경되었다고 말하고 어떤 결정이 현재이며 왜인지 요청하세요. memory status가 수집과 검색이 정확하다는 것을 증명한다고 가정하기보다 Hindsight UI와 저장된 관찰을 확인하세요.

답변이 비어 돌아오면, 모델을 변경하기 전에 제어 평면을 검사하세요. recall_types가 관찰 전용이고 통합이 실행되지 않은 동안, retain은 성공할 수 있으면서도 recall에 보이지 않을 수 있습니다 — recall_types를 넓히는 것이 첫 번째 확인입니다. 임베딩 서버 로그에서 연결 거부는 컨테이너가 임베딩 포트에 도달할 수 없음을 의미하며, 모든 제로 리랭커 점수는 GGUF가 잘못된 변환임을 의미합니다.

쓰기 경로 선택(auto_retain, 미션, 승인 공백)은 무엇을 기억하는지 제어에서 다룹니다.

문제 해결 및 운영 노트

실용적인 작은 배포는 Hindsight API VM에 대해 2-4 vCPU와 4-6 GB RAM입니다(PostgreSQL 및 모든 추론이 외부일 때). 디스크 할당은 여전히 선택된 Docker 이미지 및 유지된 이미지 레이어에 따라 달라지며; 확장 여지를 두고 초기에 약 30-40 GB를 할당하세요. PostgreSQL 호스트는 실제 메모리 볼륨, 저장 성능, 그리고 그것이 서빙하는 다른 데이터베이스를 기반으로 크기를 설정하세요.

Hindsight 뱅크 백업 및 복구

메모리 뱅크는 유일한 중요한 상태이며, PostgreSQL에 있습니다. 옵션 B에서는 그것이 여러분이 관리하는 데이터베이스이고; 옵션 A에서는 컨테이너 내부의 내장 pg0 이름이 지정된 볼륨입니다. Hindsight 컨테이너와 독립적으로 백업하세요 — 볼륨 또는 데이터베이스를 먼저 캡처하지 않고 컨테이너를 재창조하면 뱅크가 폐기되며, hermes backup은 별도 서비스에서 실행 중인 뱅크에 도달하지 않습니다.

옵션 B — 외부 PostgreSQL. 커스텀 형식으로 hindsight 데이터베이스를 덤프하고, 신뢰하기 전에 스크래치 데이터베이스로 복원하여 아카이브를 검증하세요:

pg_dump -h POSTGRES_IP -U hindsight -Fc hindsight > hindsight-bank.dump

# restore into a scratch database to prove the dump is usable
createdb -h POSTGRES_IP -U postgres hindsight-verify
pg_restore -h POSTGRES_IP -U postgres -d hindsight-verify hindsight-bank.dump

원시 덤프 타겟을 삭제하기 전에 복원된 사본에 pgvector 확장 및 샘플 recall이 존재하는지 확인하세요. 덤프를 Hindsight VM과 다른 호스트에 유지하고, 애플리케이션 역할이 아닌 PostgreSQL 관리자(데이터베이스를 생성할 수 있는 역할)로서 실행하세요.

옵션 A — 올인원 컨테이너. 내장 데이터베이스는 이름이 지정된 볼륨이므로, 컨테이너를 중지하고 throwaway 이미지를 통해 볼륨을 tar하세요:

docker stop hindsight
docker run --rm -v hindsight-pg0:/data -v "$PWD":/backup alpine \
  tar czf /backup/hindsight-bank.tgz -C /data .
docker start hindsight

tar 컨테이너 내부의 마운트 포인트(/data)는 임의입니다; 단순히 tar가 읽을 수 있도록 이름이 지정된 볼륨에 별명을 붙입니다. 복원하려면, 컨테이너를 중지하고, 볼륨을 클리어한 후, 아카이브를 다시 해제하여 원래 위치로 가져가거나, 옵션 B의 외부 PostgreSQL 복원으로 컨테이너를 향하게 하세요.

캘린더 스케줄이 아닌 세 가지 시점에서 스냅샷을 찍으세요: 임베딩 모델을 변경하기 전에, Hindsight 또는 PostgreSQL의 주요 업그레이드 전에, 그리고 뱅크를 재작성하는 reflect 또는 통합 패스가 있기 전에. 스크래치 뱅크로 복원한 백업은 단순히 작성한 백업보다 가치 있습니다.

메모리 뱅크의 내보내기, 가져오기, 마이그레이션

백업 및 복구는 제자리에 있는 뱅크를 보호합니다. 내보내기/가져오기는 Hindsight 인스턴스 간으로 이동하며, 모델 변경이 실제로 강제하는 것이 바로 그것입니다.

임베딩 모델을 변경하는 것은 구성 편집이 아닙니다. 뱅크의 벡터는 구 모델로 계산되었으며, 다른 모델(예: 번들된 384차원 BGE 임베더 대 1024차원 Qwen3-Embedding-0.6B)은 다른 공간에, 보통 다른 폭으로 씁니다. 기존 인스턴스를 새 임베더로 다시 가리키고 구 벡터를 유지할 수 없습니다; 차원은 새 임베딩 모델로 모든 메모리를 재임베딩하여 재계산되어야 합니다.

임베더와 그 구성이 Hindsight 인스턴스별로 설정되므로, 깨끗한 경로는 이미 recall을 서빙하고 있는 것 안에서 벡터를 재구축하는 대신, 새 임베딩 구성으로 새 인스턴스를 설정하고 뱅크를 туда 마이그레이션하는 것입니다. Hindsight API는 뱅크를 이동할 수 있지만, 일회성 변경에 대해서는 내보내기/가져오기가 더 쉽고 검사 가능한 경로입니다:

# export the bank from the old instance
docker exec hindsight \
  hindsight-admin export-bank \
    --bank hermes2 \
    --output /tmp/hermes2.zip

docker cp hindsight:/tmp/hermes2.zip ./hermes2.zip

ls -lh hermes2.zip
unzip -t hermes2.zip

# import the bank into the new instance
docker cp ./hermes2.zip hindsight-q06:/tmp/hermes2.zip

docker exec hindsight-q06 \
  hindsight-admin import-bank \
    --archive /tmp/hermes2.zip

unzip -t은 새 인스턴스에 보내기 전에 아카이브를 검증합니다. 가져오기 후, ~/.hermes/hindsight/config.json에서 Hermes의 api_url을 새 인스턴스로 다시 가리키고, 게이트웨이를 재시작하며, 이전의 메모리 검증을 실행하세요: 보존된 사실이 새 임베더를 통해 검색되어야 합니다. 새 것이 작동할 때까지 구 뱅크와 그 벡터를 구 인스턴스에 두세요, 그러면 여전히 작동하는 폴백이 있습니다.

모니터링, 가지치기, 뱅크 안정성 유지

뱅크가 실행되면, 일상적인 작업은 추출 모델이 저장하기로 결정한 것을 관찰하고 파생 상태를 점검하는 것입니다. memory status가 수집과 검색이 정확하다는 것을 증명한다고 가정하기보다, 관찰, 관련성 점수, 통합 출력을 검사하기 위해 제어 평면 UI(hindsight-embed -p hermes ui start)를 사용하세요. 중복되거나 오래된 메모리는 보통 약한 추출 또는 과소 실행된 통합이므로, 검색을 넓히기 전에 추출 계층 또는 통합 cadence를 수정하세요.

뱅크를 신뢰하기 전에 테스트할 가치가 있는两个维护 함정이 두 가지 있습니다. 첫째, 관찰을 삭제한다고 해서 모든 파생 표현이 사라진다는 보장은 없습니다 — 그것에서 구축된 reflect 사실 또는 그래프 엣지는 삭제를 생존할 수 있으므로, 자기 강화 메모리 루프에서 다룬 것과 같은 소싱 우려와 같이 삭제를 끝까지 검증하세요. 둘째, HINDSIGHT_API_WORKER_ID를 재작성 사이에 안정적으로 유지하고 특정 이미지 태그를 고정하세요: 컨테이너가 사망했을 때 진행 중이던 작업은 구 worker id 아래에서 막혀 있게 되고, 이동하는 태그는 유지하려는 데이터베이스에 적합하지 않습니다.

참고 자료

• Hindsight 소스 및 문서
• 공식 Hindsight 설치 가이드
• Hindsight 구성 레퍼런스
• Hindsight Hermes 통합
• Hindsight 추론 모델 및 리랭킹 프로바이더
• pgvector
• llama.cpp 서버
• Ollama