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

> Clean Markdown view of GeekNews topic #22209. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=22209](https://news.hada.io/topic?id=22209)
- GeekNews Markdown: [https://news.hada.io/topic/22209.md](https://news.hada.io/topic/22209.md)
- Type: news
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-07-28T11:11:01+09:00
- Updated: 2025-07-28T11:11:01+09:00
- Original source: [leoniemonigatti.com](https://www.leoniemonigatti.com/blog/what_i_learned.html)
- Points: 42
- Comments: 1

## Summary

벡터DB의 주용도는 "**검색**"으로, 최근 RAG 와 생성AI와 결합하면서 **정보검색(리트리벌)** 이 더욱 부각되고 있습니다.  **BM25 등 키워드 검색**이 여전히 벡터 DB에서 강력한 **기본 검색 방식**이며, **벡터 검색**은 대규모 데이터에서 속도를 위해 근사적 알고리즘을 활용하지만 정확성과 트레이드오프가 존재한다는 것을 강조합니다. 벡터 DB는 **원본 데이터와 메타데이터** 저장, **하이브리드 검색** 지원 등 데이터 관리에 강점을 가지며, 검색 품질 개선과 효율적 리트리벌을 위해 다양한 **임베딩 포맷, 검색 지표, 데이터 파이프라인**이 필요합니다.

## Topic Body

벡터 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](https://huggingface.co/spaces/mteb/leaderboard)는 다양한 임베딩 태스크(분류, 클러스터링, 검색 등)를 포괄  
- 정보검색에 특화된 벤치마크는 [BEIR](https://github.com/beir-cellar/beir) 참고  
  
### 8. **MTEB의 대부분 모델은 영어 전용**  
- 다국어/비영어 환경이면 [MMTEB](https://arxiv.org/html/2502.13595v1) 벤치마크 활용 추천  
  
### 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](https://arxiv.org/abs/2205.13147)으로 저차원화도 가능  
  
### 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에 제공할 ‘최적의 정보’를 찾는 것이 가장 핵심적이고 중요한 과제임

## Comments



### Comment 41898

- Author: mhj5730
- Created: 2025-07-29T07:46:47+09:00
- Points: 1

벡터 검색을 다루면서 고민해본 내용들이 많아서 좋네요.