- 벡터 검색 자체는 '쉬운' 문제가 아니며, 벡터 데이터베이스가 해결해야 할 전통적인 데이터베이스 문제들이 더 어렵다.
- 벡터 데이터베이스는 원자성, 일관성, 성능 최적화, 스케일링 등 많은 문제를 해결해야 한다.
- 새로운 벡터를 추가할 때마다 빠른 조회 속성이 빠르게 떨어지므로 주기적으로 인덱스를 처음부터 다시 구축해야 한다. 이러한 문제를 해결하기 위한 각 VDB의 접근 방식은 서로 상이한데, 예를 들어 Milvus는 일정한 주기마다 full-reindex를 시도하는 데 이 때 높은 CPU 로드를 경험하여 서비스 다운의 원인이 될 수 있다.
- 벡터를 생성하고 얼마나 빨리 검색 가능해야 하는지가 시스템의 주 설계 요소가 될 수 있다. 이러한 비용과 데이터 지연성 간의 중요한 트레이드오프가 있다.
- 내가 도입하려고 하는 VDB는 Indexing 전략에 따라 In memory인가 On-disk index인가?
- 실제 세계의 검색 쿼리는 특정 키워드를 요청하는 단순한 텍스트 쿼리 수준이 아니라 일반적으로 다른 메타데이터 속성에 대한 필터링이 포함된다.
- 대규모, 상대적으로 정적이고 일체형의 벡터 인덱스 특성상 벡터 + 메타데이터 검색을 효율적으로 결합하는 것은 어렵다. 또한 메타데이터 필터링이 중요하다면 pre-filtering이나 post-filtering에서 사용하기 용이한 형태의 VDB여야 한다.
- Qdrant는 인덱스 시간에 카테고리 간에 연결을 형성하여 다양한 조건 하에서 연결된 HNSW 그래프를 보장하는 자체 필터링 방법을 사용한다.
- 내가 도입하려고 하는 VDB의 Pre/post filtering 전략은 어떻게 되는가?
- High Saving Cost: HNSW 인덱싱 알고리즘을 사용하는 엔진은 벡터 검색을 위해 복잡한 그래프 구조를 구축하기 때문에 저장 비용이 높다. 상대적으로 많은 메모리와 저장 공간을 필요로 하므로 쿠버네티스와 같은 오케스트레이션 시스템에서 관리될 때 리소스 비용이 증가한다
- Low Serving Cost: HNSW 알고리즘은 효율적인 탐색을 가능하도록 하므로 검색 쿼리에 대한 빠른 응답을 제공한다. 또한 쿠버네티스 환경에서는 컨테이너화된 환경으로 자원을 효율적으로 활용, 자동으로 확장 및 축소할 수 있으므로 운영 비용을 절감할 수 있다.
- Accuracy: HNSW 알고리즘이 구현되어 있고 1536차원 이상의 임베딩인 경우에 대하여 정확하면서도 비교적 빠른 검색이 가능하다. Milvus의 경우 32,768차원까지 지원한다.
- 대표적인 제품군: Milvus, Qdrant, Weaviate, Pinecone
- 사이드카로 덕지덕지 라이브러리를 붙여둔 Milvus는 “kitchen sink” 정도로 평가되고 query speed > insertion speed인 Qdrant의 선호가 높음
Low Saving Cost: PostgreSQL은 전통적인 RDBMS로서 데이터 압축과 저장 구조가 효율적이다. 따라서 분산 아키텍처를 활용하여 비용 효율적인 하드웨어 리소스를 통해 데이터를 저장할 수 있다.
- 기존의 SQL의 문법 형태로 사용할 수 있고 데이터베이스를 한 곳으로 통합하여 관리할 수 있다는 측면, 그리고 실시간 삽입/인덱싱/조회라는 데이터 접근성에서 높은 효율성을 보인다.
- High Serving Cost: pgvector는 필터나 하이브리드 검색이 적용될 경우 전체 스캔을 수행하는데, 선형 시간복잡도를 보이기 때문에 느리며 이는 1536차원 이상 높은 데이터의 문제에서 두드러지게 나타나는 현상이다.
- pgvector는 2023년 9월 0.5.0부터 HNSW 인덱싱 지원을 추가했다.
- PASE (PostgreSQL Ultra-High Dimensional) 이라는 경우 960차원을 “울트라 하이” 라 부르고 있는데, OpenAI나 Cohere는 1536 차원 이상을 주고 있다.