벡터 데이터베이스는 일반적으로 기계 학습 모델이 생성한 임베딩인 고차원 벡터를 대량으로 저장, 색인, 조회하기 위한 시스템으로, 쿼리 벡터를 정확한 키워드나 키 조회가 아닌 거리 기준으로 가장 가까운 저장 벡터와 대조할 수 있게 한다. 기존의 관계형 및 문서 데이터베이스는 구조화된 필드에 대한 정확한 일치와 범위 쿼리를 중심으로 구축되어 있으며, "이 백만 개 항목 중 어느 것이 이 항목과 의미상 가장 유사한가?"라는 벡터 데이터베이스가 잘 해결하는 질문에는 적합하지 않다.
등장 배경
전용 벡터 검색의 필요성은 Transformer (architecture)와 이를 기반으로 구축된 대규모 언어 모델의 부상에서 직접적으로 비롯되었다. 조직이 문서, 이미지 및 기타 콘텐츠를 Semantic search 및 Retrieval-augmented generation을 위해 임베딩하기 시작하면서, 쿼리 벡터를 저장된 모든 벡터와 하나씩 비교하는 단순한 유사도 검색은 수만 개 항목을 넘어서면 계산적으로 실행 불가능해졌다. 근사 최근접 이웃(ANN) 알고리즘, 특히 계층적 내비게이블 소규모 세계 그래프(HNSW)와 곱 양자화를 결합한 역파일 색인은 회상 정확도에서 작고 조정 가능한 손실을 대가로 수백만 또는 수십억 개의 벡터를 밀리초 단위로 검색할 수 있게 했다.
Pinecone, Weaviate, Milvus, Qdrant와 같은 목적 전용 벡터 데이터베이스는 2020년대 초에 등장하여 이러한 ANN 알고리즘을 데이터베이스에서 기대되는 운영 기능, 즉 영속성, 복제, 메타데이터 필터링, 수평 확장과 함께 패키지화했다. 동시에 기존 데이터베이스는 독립형 제품이 아닌 기능으로 벡터 검색을 추가했는데, PostgreSQL용 pgvector와 Elasticsearch, Redis, MongoDB의 벡터 색인이 그 예이며, "벡터 데이터베이스"라는 별도 범주와 기존 인프라에 부착된 기능으로서의 벡터 검색 사이의 경계를 흐리게 만들었다.
작동 방식
일반적인 워크플로는 임베딩 모델을 사용하여 말뭉치의 각 항목을 임베딩하고, 결과 벡터를 식별자와 선택적 메타데이터와 함께 저장한 다음, 벡터 모음에 대해 ANN 색인을 구축한다. 쿼리 시점에는 입력 텍스트나 이미지를 동일한 모델로 임베딩하고, 색인은 선택된 거리 측도(가장 일반적으로 코사인 유사도, 내적, 또는 유클리드 거리)에 따라 k개의 가장 가까운 벡터를 반환한다. 많은 시스템은 하이브리드 검색을 지원하여 벡터 유사도를 전통적인 키워드 필터링이나 메타데이터 제약 조건(예: 특정 날짜 범위나 범주의 문서로 결과 제한)과 결합한다.
AI 애플리케이션에서의 역할
벡터 데이터베이스는 Retrieval-augmented generation의 성장과 함께 AI 인프라의 핵심 요소가 되었으며, 여기서 벡터 색인에서 검색된 관련 구절이 LLM의 Context window에 삽입되어 특정 문서에 기반한 답변을 뒷받침하고 Hallucination (AI)을 줄인다. 또한 추천 시스템, 이미지 및 오디오 유사도 검색, 중복 제거 파이프라인, 이상 탐지에서도 기반을 제공하며, "이와 유사한 것을 찾아라"가 핵심 쿼리인 모든 곳에 적용된다.
한계와 트레이드오프
ANN 검색은 약간의 정확도를 대가로 큰 속도 향상을 얻으며, 색인 유형과 매개변수 선택은 쿼리 지연 시간, 메모리 사용량, 회상 간의 실질적인 트레이드오프를 수반한다. 임베딩 품질은 검색 품질을 제한한다. 벡터 데이터베이스는 이를 공급하는 임베딩 모델만큼만 좋을 수 있으며, 말뭉치 색인에 사용된 임베딩 모델과 쿼리 시점에 사용된 모델 간의 불일치는 결과를 조용히 저하시킨다. 2020년대 중반 기준으로 벡터 데이터베이스는 대량의 원시 텍스트를 직접 처리할 수 있는 긴 컨텍스트 LLM(일부 애플리케이션에서 검색의 필요성을 줄이지만 완전히 제거하지는 않음)과 벡터 검색을 별도 운영 시스템이 아닌 내장 기능으로 흡수하는 범용 데이터베이스로부터 경쟁 압력을 받고 있다.