Postgres 하나로 벡터 검색까지 미루기
전용 벡터 DB 를 도입하는 시점은 생각보다 훨씬 늦다.
목차
문서가 수만 건 아래라면 Postgres 로 충분하다. 운영해야 할 저장소를 하나 더 늘리는 비용이 검색 성능의 이득보다 크다.
이미 있는 것으로 시작한다
CREATE EXTENSION IF NOT EXISTS vector;
ALTER TABLE document_chunk ADD COLUMN embedding vector(1536);
CREATE INDEX ON document_chunk USING hnsw (embedding vector_cosine_ops);트랜잭션 하나로 원문과 임베딩을 함께 쓸 수 있다는 점이 크다. 저장소가 둘이면 "문서는 지웠는데 벡터가 남은" 상태를 직접 관리해야 한다.
키워드 검색과 섞기도 쉽다
같은 DB 안에 있으니 한 쿼리로 합칠 수 있다. 고유명사·제품 코드처럼 임베딩이 약한 것들을 키워드가 받쳐 준다.
옮겨야 할 때의 신호
- 색인 재생성이 배포 창을 넘긴다
- 벡터 크기가 원본 데이터보다 커진다
- 검색 부하가 서비스 쿼리를 밀어낸다
셋 중 하나라도 나오기 전에 옮기는 것은 대체로 이르다.