08. 임베딩과 벡터 DB

RAG의 "관련 문서 찾기"를 가능하게 하는 두 부품이 임베딩과 벡터 DB다.

임베딩 — 의미를 숫자(벡터)로

임베딩(Embedding) 은 단어·문장의 의미를 숫자 배열(벡터)로 바꾸는 것이다.

"고양이"  →  [0.21, -0.03, 0.88, ...]   (수백~수천 개의 숫자)
"강아지"  →  [0.19, -0.01, 0.85, ...]   ← 고양이와 '가까운' 숫자
"자동차"  →  [-0.4, 0.7, 0.02, ...]     ← 둘과 '먼' 숫자

핵심은 의미가 비슷하면 벡터도 가깝다는 점이다.

• "고양이"와 "강아지"는 벡터 공간에서 가까이 위치
• "고양이"와 "자동차"는 멀리 위치
• 그래서 단어가 달라도 의미가 비슷하면 찾아낼 수 있다. (키워드가 아니라 의미 기반 검색)

:::info 키워드 검색과의 차이 키워드 검색은 "방화벽"을 쳐야 "방화벽" 문서를 찾는다. 임베딩 기반은 "불법 접근 차단 장비"라고 쳐도 의미가 가까운 "방화벽" 문서를 찾아낸다. :::

벡터 DB — 벡터를 저장하고 빠르게 검색

문서를 조각내 각각 임베딩(벡터)으로 바꿔 저장하고, 질문 벡터와 가장 가까운 조각을 빠르게 찾아주는 특수 데이터베이스가 벡터 DB다.

[문서들]
  │  조각내서 각각 임베딩
  ▼
[벡터 DB]  ← 수많은 벡터 저장
  ▲
  │  질문도 임베딩해서 "가장 가까운 벡터" 검색 (유사도 검색)
[질문]

대표 예: Pinecone, Weaviate, Milvus, Chroma, pgvector(PostgreSQL 확장) 등.

RAG 전체에서의 위치

문서 → (임베딩) → 벡터 DB 저장        [미리 준비]
질문 → (임베딩) → 벡터 DB에서 유사 조각 검색 → LLM에 근거로 전달 → 답   [실행 시]

즉 07. RAG의 "① 검색" 단계가 바로 임베딩 + 벡터 DB로 이뤄진다.

정리

• 임베딩: 의미를 벡터(숫자)로 → 의미 기반 비교 가능
• 벡터 DB: 벡터를 저장하고 가장 가까운 것을 빠르게 검색
• 이 둘이 RAG의 "관련 문서 찾기"를 떠받친다.
• 다음: 지식을 넣는 세 방법을 비교. → 09. 파인튜닝 vs RAG vs 프롬프트