Vector Database

앞 편의 ANN(HNSW) 알고리즘을 실제로 구현·운영해 주는 도구가 벡터 데이터베이스(vector database)다. 프로덕션 RAG는 보통 벡터를 이 전용 DB에 저장·검색한다. 이번 편은 벡터 DB가 무엇이고, RAG를 위해 어떤 작업을 하는지 흐름으로 정리한다.

 

 

1. 벡터 데이터베이스란

벡터 DB는 고차원 벡터 데이터를 저장하고, 앞서 본 ANN 같은 벡터 지향 알고리즘을 구현하도록 처음부터 설계된 데이터베이스다. LLM과 시맨틱 검색 같은 임베딩 기반 기법이 폭발적으로 늘어난 2020년대 초에 인기를 얻었다. 일반 관계형 DB는 시맨틱 검색에서 성능이 나빠 비효율적인 KNN에 가까운 속도를 보였다. 반면 벡터 DB는 HNSW용 proximity graph 구축이나 벡터 거리 계산 같은 작업에 최적화돼, 대부분의 벡터 기반 애플리케이션(특히 RAG)에서 훨씬 빠르고 잘 확장된다.

그림 1. 벡터 DB는 고차원 벡터 저장과 벡터 검색에 특화돼 있다. 이 시리즈에서는 오픈소스 벡터 DB인  Weaviate 를 예로 든다(로컬·클라우드 모두 가능). 다른 벡터 DB도 기능은 거의 비슷하다.

 

 

 

2. 검색을 준비하는 단계

벡터 DB가 검색을 처리할 수 있게 만드는 과정은 몇 단계로 이뤄진다(일부는 자동 처리된다).

• 데이터베이스를 설정한다.
• 문서를 로드한다.
• 키워드 검색을 위한 sparse vector를 만든다.
• 시맨틱 검색을 위한 dense 임베딩 벡터를 만든다.
• ANN 검색을 위한 인덱스(예: HNSW)를 만든다.

여기까지 되면 실제 검색을 실행할 준비가 끝난다.

그림 2. 전형적인 벡터 DB 작업 — 설정 → 문서 로드 → sparse(키워드)·dense(시맨틱) 벡터 생성 → ANN 인덱스 생성 → 검색.

 

 

 

3. 컬렉션 생성

먼저 DB 인스턴스를 만들거나 기존 인스턴스에 연결한다. 그다음 데이터를 담을 컬렉션(collection)을 만든다. 예를 들어 뉴스 기사의 제목·본문을 담는 article 컬렉션을 만들고, 각 필드의 데이터 타입과 — 중요하게는 — 각 기사의 시맨틱 벡터를 만들 임베딩 모델(vectorizer)을 지정한다.

그림 3. 컬렉션을 만들며 필드 타입과 임베딩 모델(vectorizer)을 지정한다.

 

 

 

4. 데이터 추가

컬렉션 설정이 끝나면 데이터를 넣는다. batch(배치) 방식으로 객체를 추가하면 삽입과 동시에 오류를 세고 추적할 수 있어, 나중에 바로잡거나 오류가 너무 많으면 루프를 멈출 수 있다.

그림 4. batch로 객체를 추가하며 오류를 함께 추적한다.

 

 

 

5. 벡터 검색

데이터가 들어가면 벡터 검색을 할 수 있다. 검색할 컬렉션을 지정하고 텍스트 질의를 넘긴다. 이때 metadata로 distance를 요청하면, 각 객체의 벡터와 질의 벡터 사이의 거리를 함께 돌려받는다.

그림 5. 컬렉션에 텍스트 질의를 넘겨 벡터 검색을 수행하고, 거리(distance)를 함께 받는다.

 

 

6. 키워드 검색

키워드 검색도 가능하다. Weaviate는 inverted index를 자동 생성해, 어떤 단어가 각 문서에 얼마나 쓰였는지 매핑한다. 앞 모듈에서 배운 BM25 질의로 상위 문서를 요청할 수 있다.

그림 6. inverted index 위에서 BM25 키워드 검색을 수행한다.

 

 

7. 하이브리드 검색

벡터 검색과 키워드 검색을 합친 하이브리드 검색도 지원한다. 두 검색이 백그라운드에서 병렬로 수행되고, alpha 파라미터로 두 점수의 가중치를 조절한다. 예를 들어 alpha = 0.25면 벡터 검색 25%, 키워드 검색 75%로 가중해 재순위화한다. 실무에서 대다수 기업이 이 방식을 쓴다 — 벡터의 의미 유사성과 키워드의 엄격한 매칭을 균형 있게 쓸 수 있기 때문이다.

그림 7. 하이브리드 검색 —  alpha 로 벡터·키워드 가중치를 조절한다(예: 0.25 = 벡터 25%·키워드 75%).

 

 

 

8. 필터 검색

그 위에 필터를 적용할 수도 있다. 특정 property의 값이 조건에 맞는 객체만 통과시키는 방식으로, 앞 모듈의 metadata 필터링을 그대로 적용한다.

그림 8. property 조건으로 metadata 필터를 적용해, 조건에 맞는 객체만 반환한다.

 

 

9. 전체 워크플로

처음부터 끝까지의 흐름은 이렇다 — DB 설정 → 데이터 로드·인덱싱 → 하이브리드 검색·필터를 포함한 질의 실행.

그림 9. 전체 워크플로 — 설정 → 로드·인덱싱 → 질의(하이브리드 + 필터).

 

다음 글부터는 검색 품질을 크게 좌우하는 전처리 — 청킹(chunking)으로 넘어간다. 문서를 어떤 단위로 쪼개 인덱싱하느냐가 왜 중요한지 살펴본다.