기억 없는 AI 에이전트는 대화마다 자기소개를 다시 하는 데 발이 묶입니다. 해법은 벡터 데이터베이스입니다 — 당신의 문서, 메모, 지난 채팅의 임베딩을 저장해 에이전트가 필요할 때 관련 부분을 떠올릴 수 있게 합니다(그것이 RAG의 "R"). 그것을 관리형 서비스로 빌릴 수도, VPS에서 직접 돌려 데이터 — 흔히 당신의 사적 데이터 — 를 당신이 통제하는 박스에 둘 수도 있습니다. 여기 그 방법과, RAM으로 실제 얼마가 드는지를 적습니다.
두 가지 좋은 선택
별난 건 필요 없습니다. 두 경로가 거의 모두를 커버합니다:
pgvector — Postgres 확장. 이미 Postgres를 돌리고 있다면(또는 기꺼이) 이미 가진 데이터베이스에 벡터 검색을 더합니다. 서비스 하나, 백업 하나, 아는 SQL. 큰 차이로 가장 품이 덜 드는 출발.
Qdrant — 목적 특화 벡터 엔진. 벡터가 많거나(낮은 수백만+) 빠른 메타데이터 필터링과 전용 API를 원할 때 손을 뻗습니다. 돌릴 별도 서비스지만, 바로 이 일을 위해 만들어졌습니다.
발판을 다지는 대부분의 에이전트에는 pgvector가 알맞은 첫 답입니다. 그것을 넘어 자랐을 때 Qdrant로, 그 전엔 아닙니다.
RAM의 현실(사람들이 과소평가하는 부분)
벡터 검색이 빠른 것은 인덱스가 메모리에 살기 때문 — 그래서 디스크가 아니라 RAM이 진짜 제약입니다. 대략적 안내:
- 수십만 임베딩 — 2 GB에서 편안.
- 낮은 수백만 — 4 GB 이상을 계획하고 인덱스를 튜닝.
- 디스크는 쉬운 부분: 100만 임베딩은 겨우 몇 GB이므로, 25~45 GB가 진지한 스토어를 커버합니다.
그러니 파일이 아니라 인덱스에 맞춰 크기를. (일반 사이징 가이드와 같은 논리 — 무거운 것은 측정하기 전엔 뻔하지 않습니다.)
빠른 시작: pgvector
Postgres가 있는 박스에서(Docker가 가장 쉬움 — n8n 자체 호스팅과 같은 패턴):
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE memory (
id bigserial PRIMARY KEY,
content text,
embedding vector(1536) -- 당신 임베딩 모델의 차원에 맞추세요
);
-- 데이터가 생긴 뒤, 빠른 검색을 위해 인덱스를 만드세요:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);
당신의 에이전트는 content + 그 임베딩을 삽입하고, 가장 가까운 기억을 끌어오려 ORDER BY embedding <=> $query_embedding LIMIT 5로 쿼리합니다. 그것이 전체 루프입니다.
Qdrant가 좋은가요? HTTP/gRPC API를 노출하는 단일 Docker 컨테이너로, 벡터 크기로 컬렉션을 만들고 포인트를 upsert합니다. 같은 발상, 전용 엔진.
에이전트와 박스를 공유할 수 있나
네 — 소~중 기억 스토어에는 벡터 DB를 에이전트와 같은 VPS에서 돌리세요. 더 간단하고 지연은 사실상 0입니다. 한쪽이 다른 쪽을 RAM에서 밀어내기 시작할 때만 별도 서버로 나누세요. 그것은 나중의, 있어 반가운 문제의 결정이지 첫날의 것이 아닙니다.
솔직한 주의점
- RAM이 벽이고, 조용합니다. 검색은 인덱스가 메모리에 들어가는 동안 빠르다가, 그 뒤 저하됩니다. 메모리를 보고 물기 전에 크기를 올리세요 — 느린 쿼리가 알려주길 기다리지 마세요.
- 임베딩은 만드는 데 토큰이 듭니다. 임베딩하는 문서마다 임베딩 모델로의 API 호출입니다. 스토어는 호스팅에 싸고; 벡터를 생성하는 것이 반복 비용입니다 — 에이전트를 돌리는 데 실제 얼마가 드는지와 관련.
- 백업하세요. 에이전트의 기억은 다른 것과 같은 데이터입니다. 중요하면 스냅샷을.
그 안에서, 자체 호스팅 벡터 스토어는 사적 데이터를 제3자에게 건네지 않고 에이전트에게 지속되는 기억을 주는 깔끔한 방법입니다. 2 GB 박스의 pgvector로 시작하고, RAM에 눈을 두고, 숫자가 말할 때만 Qdrant나 더 큰 요금제로 자라나세요.
댓글
아직 댓글이 없습니다. 첫 번째가 되세요.