Vector DB와 RAG에 대해 궁금한 점 정리
Vector DB 정리해보기
데이터 (문장, 이미지, 코드)의 “의미"를 벡터로 표현하고, 이 벡터들 간의 유사도를 빠르게 검색하기 위한 데이터베이스
ex) “apple"과 “fruit company"는 다르기 때문에 기존 DB에서는 연관지어 검색이 어렵지만, embedding을 통해 벡터화하면 두 벡터의 거리가 가까워서 같은 의미로 분류될 수도 있음
Vector DB의 핵심 구성 요소
Vector Embeddings
- 텍스트(또는 이미지, 코드)를 고정된 길이의 숫자 벡터로 변환한 것
- ex) [0.23, -0.11, 0.89, …]
Index (벡터 인덱스)
- 수백만 개의 벡터 중에서 “가장 가까운 것들"을 빠르게 찾기 위한 자료구조
- HNSW, IVP, PQ 등
Metadata
- 벡터와 함께 저장되는 추가 정보(회사명, 회계년도, Ticker 등)로 필터링이나 정렬에 사용됨
Similarity Metric
- 벡터 간의 유사도를 계산하는 방법
- 코사인 유사도, L2 거리, dot product 등
동작 방식
Index 생성
- HNSW라는 그래프 기반 인덱스 사용
- 벡터들을 그래프로 연결해서 “근처 노드"만 탐색 -> 속도 향상
Search 시
- Query 벡터 기준으로 가까운 후보를 찾음 (근사치)
- 후보군에서 정확한 거리 계산 후 top-k 선택
결과 반환
- 각 결과의 distance, similarity 점수와 metadata 포함
의미론적 유사도 측정
- 서로 다른 벡터들의 의미적 유사도를 측정하려면, 두 벡터가 얼마나 같은 방향을 향하고 있는가 봐야 함.
- 코사인 유사도와 내적(dot product)가 흔히 사용됨
코사인 유사도(Cosine Similarity)
- 두 벡터가 이루는 각의 코사인 값
- 1이면 완전히 같은 방향, 0이면 서로 완전히 무관, -1이면 정 반대 의미
- 방향(각)만 보고 길이는 무시하므로 embedding의 크기가 달라도 비교가 가능
내적(Dot Product)
- 길이와 방향을 동시에 보는 척도
- 두 벡터를 좌표별로 곱한 뒤 합산한 값
- 같은 방향을 바라보는 정도 + 얼마나 강하게 닮았는가?
- 내적 = 두 벡터의 길이 곱 * 방향(코사인 유사도)
- 두 벡터의 길이가 비슷하면 내적도 코사인 유사도처럼 유사도 척도로 사용 가능.
- 모든 벡터를 정규화(normalize)해서 길이를 1로 만들면, 코사인 유사도 = 내적 성립
기존 RDB와 비교
| 항목 | 벡터 DB | 전통적 DB |
|---|---|---|
| 데이터 형태 | 고차원 벡터 (예: 1536 floats) | 텍스트, 숫자, 키-값 |
| 검색 기준 | 의미적 유사도 (코사인 거리 등) | 정확한 키 매칭 |
| 주요 알고리즘 | HNSW, IVF, PQ | B-Tree, Hash index |
| 응용 분야 | RAG, 추천 시스템, 이미지 검색, 코드 검색 | CRUD, 트랜잭션, 정형 데이터 |
| 대표 예시 | Qdrant, Milvus, Pinecone | MySQL, MongoDB, PostgreSQL |
Embedding Model
Embedding Model간 호환성
- 각 embedding 모델은 텍스트를 “숫자 벡터 공간"으로 투사(projection)하는 고유한 방식을 가진다.
- 따라서 서로 다른 embedding model의 벡터는 좌표계 자체가 다르다 (호환 불가)
- RAG를 구현할 때, vector DB 저장시에 사용한 embedding model을 query시에도 반드시 사용해야 함
Embedding Vector의 복원
- Embedding은 손실압축으로 원문 정보가 보존되지 않음.
- 따라서 Embedding Vector를 자연어로 복원하는 것은 거의 불가능함
- Embedding은 비가역적(irrevocable)이다.
- 검색 결과를 사람이 이해하려면 원문 텍스트를 metadata로 함께 저장해야 한다
LLM과 Vector
- LLM은 자연어 토큰(token) 단위로 학습된 모델이라, 텍스트 문자열만 이해할 수 있음
- Vector를 prompt에 포함시켜도 LLM이 그 내용을 정확히 추론하지 못할 수 있음. 따라서 metadata에 원본 text를 함께 저장하고, LLM prompt에는 원본 text를 포함시켜야 함
- Vector DB는 의미의 위치(semantic position)만 다루고, LLM은 언어의 문맥(language structure)만 다룸. 따라서 LLM은 현재로서는 embedding space를 직접 이해하지 못함.
차세대 RAG의 방향
두 세계의 통합
Generative Retrieval (생성형 검색)
- 쿼리와 DB 벡터들을 LLM이 함께 보면서 어떤 벡터를 참조하거나 생성할지 스스로 결정
- LLM이 Retrieval 단계를 내부적으로 수행
- RAG-Fusion: LLM 스스로 retrieval candidate를 생성하고 refinement
Semantic Caching (의미 기반 캐시)
- 기존에 했던 질문과 의미적으로 비슷한지 embedding space에서 판단한 후 이전에 생성된 답변을 벡터 유사도로 재활용
- inference 비용 절감
- LangChain Semantic Cache
- Vercel AI SDK’s semantic caching
End-to-End Embedding-Language Fusion
- Embedding 모델과 LLM을 아예 같은 네트워크로 통합하자
- 별도의 embedding API 없이, 모델 내부에서 의미 기반 검색을 하고, 벡터 공간과 언어 공간을 통합적으로 이해
- ColBERTv2, HyDE, Contriever, GTR, Jina Embeddings
- OpenAI의 unified text-embedding-3 model (기존보다 언어-의미 간 alignment 강화)
- LLM-as-a-VectorDB (LangChain, LlamaIndex에서 실험 중)
OpenAI에서 memory API를 공개 예정
추가로 공부할 수학 지식
- 선형대수: 벡터, 행렬, 외적, 벡터공간, norm, unit vector, orthogonal, proejction
- 벡터 기하학: 벡터 사이의 각, 코사인 법칙, 벡터 정규화