Vector DB 회사에 2년간 다니면서 배운 것들

벡터 DB인 Weaviate에 다니면서, 실제 운영 경험에서 얻은 37가지 교훈을 정리
↳ BM25, 키워드 검색의 효용부터 벡터 검색·임베딩·하이브리드 검색까지

1. BM25는 검색에서 강력한 베이스라인임

• 복잡한 벡터 검색보다 BM25 등 단순 키워드 검색부터 적용해 성능을 확인한 뒤 점진적으로 벡터 검색으로 확장하는 것이 실전적임

2. 벡터 검색은 근사적(Approximate)이지 정확(Exact)하지 않음

• 대규모 데이터에서는 근접 이웃(ANN) 알고리듬(HNSW, IVF, ScaNN 등)을 사용해 속도를 높이지만, 정확성에서 일부 타협함
• 벡터 인덱싱이 벡터DB의 대규모 속도를 보장하는 핵심

3. 벡터DB는 임베딩만 저장하지 않음

• 원본 데이터(텍스트 등)와 메타데이터도 함께 저장, 메타데이터 필터링, 키워드 검색, 하이브리드 검색 등이 가능

4. 벡터DB의 주용도는 생성AI가 아닌 ‘검색’

• LLM에 context를 넣는 것도 본질적으로 ‘검색’이며, 벡터DB와 LLM은 매우 잘 어울리는 조합임

5. 검색 결과 개수를 직접 지정해야 함

• limit 또는 top_k 파라미터를 지정하지 않으면 쿼리와 가장 가까운 모든 결과가 정렬되어 반환됨

6. 임베딩 종류는 다양함

• Dense(밀집) 벡터 외에도, sparse(희소), binary(이진), multi-vector 등 다양한 임베딩 벡터 포맷이 존재

7. 임베딩 모델 선택을 위한 벤치마크

• MTEB는 다양한 임베딩 태스크(분류, 클러스터링, 검색 등)를 포괄
• 정보검색에 특화된 벤치마크는 BEIR 참고

8. MTEB의 대부분 모델은 영어 전용

• 다국어/비영어 환경이면 MMTEB 벤치마크 활용 추천

9. 임베딩의 역사: Static vs Contextual

• Word2Vec, GloVe 등 정적 임베딩은 단어별 고정 표현
• BERT 등 컨텍스트 임베딩은 문맥에 따라 동적으로 벡터를 생성
• 정적 임베딩은 리소스 제약 환경에서 빠르게 참조 가능

10. Sparse vector와 sparse embedding의 차이

• sparse vector: TF-IDF/BM25 등 통계 기반 혹은 신경망 기반(sparse embedding, SPLADE 등)으로 생성
• 모든 sparse embedding은 sparse vector이지만, 반대는 아님

11. 텍스트 외 다양한 데이터 임베딩 가능

• 이미지, PDF(이미지 변환), 그래프 등도 임베딩하여 멀티모달 벡터 검색 가능

12. 임베딩 차원수와 저장 비용

• 차원수가 많아지면 스토리지 비용도 증가
• “챗봇용” 등 간단한 용도엔 고차원 모델이 불필요할 수 있음
• Matryoshka Representation Learning으로 저차원화도 가능

13. “Chat with your docs” 튜토리얼은 생성AI의 헬로월드

14. 임베딩 모델은 반복적으로 호출해야 함

• 문서 인입(ingestion)뿐 아니라, 쿼리 시, 문서 추가/수정 시, 임베딩 모델 변경 시마다 임베딩·인덱싱 필요

15. 벡터 유사도와 실질적 relevance는 다를 수 있음

• 유사 문장(예: “수도꼭지 고치는 법” vs “수도꼭지 구매처”)이 실질적으로 관련성이 낮을 수도 있음

16. Cosine similarity와 cosine distance는 다름

• 유사도와 거리는 수학적으로 반비례 관계
• 동일한 벡터면 유사도 1, 거리 0

17. 벡터 정규화 시 cosine similarity와 dot product는 동일

• 정규화된 벡터라면 계산상 dot product가 더 효율적임

18. RAG의 R은 ‘vector search’가 아닌 ‘retrieval’

• RAG에서 retrieval 방식은 다양(키워드, 벡터, 필터 등)

19. 벡터 검색은 검색 도구의 하나일 뿐

• 키워드 검색, 필터링, 리랭킹 등 다양한 방법과 조합(하이브리드) 이 중요

20. 키워드/벡터 검색의 적절한 적용

• 의미적/동의어 매칭은 벡터 검색, 정확 키워드는 키워드 검색, 둘 다 필요한 경우 하이브리드 검색 및 alpha 가중치 조절 활용

21. 하이브리드 검색의 의미

• 보통 키워드+벡터 조합을 의미하나, 메타데이터 등 다른 검색 방식과의 조합도 모두 ‘하이브리드’로 부름

22. 필터링이 항상 속도를 올리진 않음

• 예를 들어 HNSW 그래프의 connectivity가 깨질 수 있고, 사후 필터링 시 결과가 없을 수 있음
• 벡터DB마다 이를 위한 최적화 기법이 다름

23. 2단계 검색 파이프라인의 유용성

• 추천 시스템뿐 아니라, RAG 등에서 1차 후보군 추출 후, 2차 고성능 리랭킹으로 품질 개선 가능

24. 벡터 검색과 리랭킹의 차이

• 벡터 검색은 전체 DB에서 일부 결과 반환, 리랭킹은 받은 결과 집합을 순서 재조정

25. 임베딩할 chunk 크기 선정의 어려움

• 너무 작으면 컨텍스트 손실, 너무 크면 의미 희석
• mean pooling 등으로 전체 문서를 벡터화할 수도 있으나, 정보가 희석될 수 있음(모든 영화 프레임을 합친 포스터 비유)

26. 벡터 인덱싱 라이브러리와 벡터DB의 차이

• 둘 다 빠르지만, 벡터DB는 내구성, CRUD, 필터/하이브리드 등 데이터 관리 기능까지 제공

27. LLM context 확장에도 RAG는 계속 진화

• 긴 컨텍스트 LLM 등장 때마다 ‘RAG는 죽었다’는 논의가 있지만, 실제로는 계속 필요

28. 벡터 양자화로 97% 정보 줄여도 검색 유지

• binary quantization 등 활용 시, 스토리지 32배 절감 가능(32-bit float→1-bit 등)

29. 벡터 검색은 오타에 robust하지 않음

• 대규모 텍스트 코퍼스에도 모든 오타가 반영되는 것은 아니며, 일부 오타만 커버

30. 검색 품질 평가 지표 다양

• NDCG@k 등 랭킹 기반, Precision/Recall 등 단순 지표도 상황에 따라 효과적

31. Precision-Recall trade-off 실전 예시

• 한 결과만 반환(Precision ↑/Recall ↓), 전체 결과 반환(Recall ↑/Precision ↓) 등 극단적 사례로 설명

32. 검색 결과의 순서 반영 지표

• Precision/Recall은 순서 반영 X, MRR@k, MAP@k, NDCG@k 등 순서 고려 지표 필요

33. 토크나이저의 영향력

• BPE만이 아니라, 키워드/하이브리드 검색 품질에도 토크나이저가 영향

34. Out-of-domain과 out-of-vocabulary는 다름

• OOV는 스마트 토크나이저로 해결 가능하지만, out-of-domain은 임베딩 자체가 의미 없음

35. 쿼리 최적화의 필요성

• 키워드 검색처럼 벡터 검색에도 쿼리 입력 최적화 습관 필요

36. 벡터 검색 이후의 패러다임

• 키워드 검색 → 벡터 검색 → LLM reasoning 기반 리트리벌로 진화

37. 정보검색(리트리벌)은 지금 가장 ‘핫’한 분야

• LLM과 함께, LLM에 제공할 ‘최적의 정보’를 찾는 것이 가장 핵심적이고 중요한 과제임