Vector Index Tuning은 “빠르게"와 “정확하게"를 동시에 맞추는 작업입니다. 벡터 검색은 기본값만 써도 동작하지만, 실제 서비스에서는 쿼리 패턴에 맞춰 인덱스 파라미터를 조정해야 합니다.
개요 #
인덱스 튜닝은 보통 HNSW의 그래프 밀도, 탐색 폭, 재계산 비용을 조절하는 일로 시작합니다. 여기에 quantization이나 filtering 전략이 섞이면 latency와 recall이 같이 변합니다.
운영 중인 시스템이라면 Qdrant나 Qdrant Cloud를 기준으로 튜닝하는 경우가 많습니다. 검색 품질의 결과는 Retrieval Quality Metrics에서 같이 검증해야 합니다.
왜 중요한가 #
인덱스를 잘못 잡으면 다음 문제가 생깁니다.
- recall이 낮아져 검색이 빠르기만 하고 쓸모가 없어집니다.
- ef_search를 올리면 품질은 오르지만 latency와 CPU가 늘어납니다.
- quantization을 과하게 쓰면 저장 비용은 줄어도 품질 손실이 커집니다.
- 필터링이 많은 데이터셋에서는 인덱스 구조보다 query 분포가 더 중요해집니다.
즉, 인덱스 튜닝은 단일 파라미터 조정이 아니라 검색 워크로드 전체를 맞추는 일입니다.
선택 기준 #
튜닝 순서는 가장 안전한 변화부터 시작해야 합니다. 보통은 ef_search 같은 런타임 파라미터를 먼저 보고, 그다음에 quantization과 구조적 변경을 검토합니다.
튜닝 포인트 #
핵심 튜닝 항목은 다음입니다.
- HNSW graph size와 edge density
- ef_construct와 ef_search
- quantization 적용 여부
- payload filter 선택성
- batch ingest와 incremental update 비율
- shard별 데이터 분포
Hybrid Search를 쓰는 경우 dense search만 보면 안 되고 BM25나 keyword signal도 같이 봐야 합니다. reranking이 포함되면 인덱스는 더 공격적으로 압축할 수도 있습니다.
아키텍처 도식 #
권장 절차는 다음과 같습니다.
- 기준 데이터셋을 만듭니다.
- recall과 latency 기준선을 측정합니다.
- HNSW와 quantization 파라미터를 하나씩 바꿉니다.
- filter-heavy query와 broad query를 따로 측정합니다.
- 운영 트래픽과 같은 분포로 재검증합니다.
체크리스트 #
- recall 목표가 먼저 정해져 있는가
- latency와 cost를 함께 본 benchmark가 있는가
- filter가 많은 query와 없는 query를 분리했는가
- ingestion 후 index 안정화 시간을 확인했는가
- quantization 적용 후 품질 손실을 측정했는가
- production traffic 샘플로 재검증했는가
결론 #
Vector Index Tuning은 벡터 DB를 “잘 쓰는 방법"의 핵심입니다. 기본값으로 시작하되, 검색 분포가 보이는 순간부터는 파라미터를 데이터에 맞춰 조정해야 합니다.