임베딩 (Embeddings)은 의미를 벡터 (vectors)로 변환합니다 (지난 포스트 참고). 하지만 만약 수백만 개의 벡터가 있다면, 쿼리에 맞는 적절한 벡터를 어떻게 빠르게 찾을 수 있을까요? 그것이 바로 벡터 데이터베이스 (vector database)가 하는 역할이며, 모든 RAG 앱의 뒤편에서 작동하는 검색 엔진 (retrieval engine)입니다. 여기 실시간 의미론적 검색 (semantic search) 데모가 있습니다.

🗂️ 의미로 검색하기 (키워드가 아닌): https://dev48v.infy.uk/ai/days/day14-vector-databases.html

검색은 "가장 가까운 벡터 찾기"가 됩니다

쿼리를 문서와 동일한 공간에 임베딩 (embed)한 다음, 코사인 유사도 (cosine similarity)를 통해 그와 가장 가까운 문서 벡터를 찾습니다. 근접함이 곧 의미와 같기 때문에, "비밀번호를 어떻게 재설정하나요"라는 쿼리는 공유하는 키워드가 전혀 없더라도 "계정 액세스 복구"에 관한 문서와 일치하게 됩니다. 데모에서는 아무것도 반환하지 못하는 키워드 검색 (keyword search)보다 이 방식이 더 뛰어나다는 것을 보여줍니다.

for-loop가 아닌 데이터베이스가 필요한 이유

쿼리를 모든 벡터와 비교하는 것 (브루트 포스 kNN, brute-force kNN)은 수백 개 정도라면 괜찮지만, 수백만 개라면 불가능합니다. 벡터 DB는 HNSW와 같은 ANN (근사 최근접 이웃, approximate nearest neighbour) 인덱스를 사용하여 밀리초 단위로 가장 가까운 벡터를 찾아냅니다. 이는 약간의 정확도를 희생하는 대신 엄청난 속도를 얻는 방식입니다.

벡터 DB가 실제로 저장하는 것

ANN 인덱스 뒤에는 벡터 (Vectors) + 원본 텍스트 + 메타데이터 (metadata)가 저장됩니다. 파이프라인: 문서를 청크 (chunk)로 나누기 → 임베딩 (embed) → 업서트 (upsert). 쿼리: 질문을 임베딩 (embed) → 상위 k개 (top-k) 검색 → (종종) 메타데이터로 필터링하거나 키워드 검색과 결합 (하이브리드, hybrid).

이것이 RAG의 검색 (retrieval) 단계입니다. 실제 선택지: Pinecone, Weaviate, Chroma, pgvector, FAISS.

🔨 페이지에서 직접 구축해 보세요 (임베딩 → 업서트 → 유사도 검색 → 상위 k개 → RAG): https://dev48v.infy.uk/ai/days/day14-vector-databases.html

AIFromZero의 일부입니다. 🌐 https://dev48v.infy.uk