#임베딩과 벡터 검색

임베딩(embedding)은 텍스트·이미지 같은 데이터를 의미가 비슷할수록 서로 가까이 놓이도록 학습된 고정 길이 벡터로 바꾼 것입니다. 벡터 검색은 질의 벡터와 가장 가까운 벡터를 찾는 일이고, 이것이 RAG의 검색 단계를 떠받치는 기반입니다.

#임베딩이란

"환불은 어떻게 받나요?"      → [ 0.021, -0.113,  0.087, ...]   (예: 1024차원)
"결제 취소 절차를 알려주세요" → [ 0.019, -0.098,  0.091, ...]   ← 단어는 달라도 가까움
"오늘 서울 날씨"             → [-0.142,  0.051, -0.033, ...]   ← 멀리 떨어짐

• 초기에는 Word2Vec처럼 단어 하나에 벡터 하나를 대응시켰습니다. 문맥을 보지 못해 "배(과일)"와 "배(선박)"가 같은 벡터였습니다.
• 지금은 Transformer 인코더로 문장·문단 전체의 의미를 벡터 하나로 요약하는 문장 임베딩 모델(Sentence-BERT 계열 등)을 씁니다. 질의와 문서를 각각 독립적으로 인코딩하는 이 구조를 bi-encoder라고 부르며, 문서 벡터를 미리 계산해 둘 수 있어 대규모 검색에 적합합니다.
• 임베딩 공간이 어떻게 생겼는지는 Embedding Projector에서 시각적으로 확인할 수 있습니다.

LLM 내부의 토큰 임베딩(입력 토큰 ID를 벡터로 바꾸는 첫 층)과 검색에 쓰는 임베딩 모델의 출력 벡터는 다른 개념입니다. 검색용 벡터는 대조 학습(contrastive learning) 등으로 "의미 유사도"를 직접 목표로 학습된 별도 모델에서 나옵니다. → LLM 기초

#주요 용도

#최소 예제

# pip install -U sentence-transformers
from sentence_transformers import SentenceTransformer

model = SentenceTransformer("nlpai-lab/KURE-v1")  # 한국어 검색 특화, 1024차원

docs = ["환불은 결제일로부터 7일 이내에 신청할 수 있습니다.",
        "배송은 영업일 기준 2~3일이 소요됩니다."]
query = "돈 돌려받으려면 어떻게 해?"

doc_vecs = model.encode(docs, normalize_embeddings=True)
query_vec = model.encode([query], normalize_embeddings=True)

scores = query_vec @ doc_vecs.T   # 정규화했으므로 내적 = 코사인 유사도
print(scores)                     # 환불 문서 점수가 더 높게 나옵니다

#유사도 측정

벡터를 길이 1로 정규화하면 세 지표의 검색 순위가 같아집니다. 예를 들어 OpenAI 임베딩은 길이 1로 정규화되어 나오므로 코사인 대신 내적으로 계산해도 됩니다.

⚠️ 함정: 모델은 특정 지표를 기준으로 학습됩니다. 모델 문서가 권장하는 지표와 벡터 DB 인덱스에 설정한 지표가 다르면 에러 없이 검색 품질만 조용히 떨어집니다. 정규화하지 않은 벡터를 내적 인덱스에 넣는 실수도 흔합니다. 인덱스를 만들 때 지표와 정규화 여부를 함께 확인하세요.

#키워드 검색 vs 의미 검색

#키워드(어휘) 검색

• TF-IDF (Term Frequency–Inverse Document Frequency): 문서 안에서 자주 나오고(TF), 전체 문서에서는 드문(IDF) 단어일수록 그 문서에서 중요하다고 보는 통계적 가중치입니다.
• BM25 (Best Matching 25): TF-IDF를 개선한 랭킹 함수로, 현재 검색 엔진의 사실상 표준입니다. 두 가지를 보정합니다.
  • TF 포화 (k1): 같은 단어가 10번 나온다고 1번보다 10배 관련 있지는 않으므로, 빈도 효과를 점점 둔화시킵니다.
  • 문서 길이 정규화 (b): 긴 문서가 단지 길어서 점수를 많이 받는 것을 막습니다.

#의미 검색

질의와 문서를 임베딩으로 바꾸고 벡터 간 거리로 관련성을 판단합니다. 단어가 하나도 겹치지 않아도 의미가 같으면 찾을 수 있습니다.

#비교

한국어 키워드 검색은 조사·어미 때문에 공백 단위 분리로는 잘 맞지 않습니다. Elasticsearch·OpenSearch의 Nori 같은 형태소 분석기를 쓰거나, 질의 전처리를 함께 설계하세요. → Lexical, Stopword, Normalization

더 깊은 비교는 BM25와 벡터 검색을 참고하세요.

#Sparse · Dense · Hybrid

• 희소 벡터는 0이 대부분이라 0이 아닌 값만 저장하므로 메모리 효율이 좋고, 각 차원이 특정 단어에 대응해 결과를 설명하기 쉽습니다.
• 밀집 벡터는 차원 하나하나에 사람이 읽을 수 있는 의미가 없지만, 전체로 의미를 압축해 담습니다. 모든 차원을 저장하므로 메모리를 더 씁니다.

#하이브리드 검색과 RRF

BM25 점수(상한 없음)와 코사인 유사도(-1~1)는 척도가 달라 그대로 더할 수 없습니다. 가장 널리 쓰는 병합 방법은 점수 대신 순위만 쓰는 RRF(Reciprocal Rank Fusion)입니다.

def rrf(result_lists: list[list[str]], k: int = 60) -> list[tuple[str, float]]:
    """각 검색 결과(문서 ID 순위 리스트)를 RRF 점수로 병합합니다."""
    scores: dict[str, float] = {}
    for results in result_lists:
        for rank, doc_id in enumerate(results, start=1):
            scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)
    return sorted(scores.items(), key=lambda x: x[1], reverse=True)

bm25_hits = ["doc3", "doc1", "doc7"]
vector_hits = ["doc1", "doc5", "doc3"]
print(rrf([bm25_hits, vector_hits]))  # 양쪽에서 모두 상위인 doc1, doc3가 앞으로

k=60은 RRF 원 논문에서 쓴 값으로, 관례적인 기본값입니다. 병합 뒤에는 질의-문서 쌍을 함께 보고 점수를 다시 매기는 리랭커(cross-encoder) 를 붙이는 경우가 많습니다. → Rerank는 언제 필요한가, 검색 전략 3층 설계

#ANN 인덱스

질의 벡터를 모든 문서 벡터와 비교하는 정확한 검색(Flat, brute-force)은 문서 수에 비례해 느려집니다. ANN(Approximate Nearest Neighbor) 인덱스는 약간의 재현율(recall)을 포기하는 대신 검색을 크게 빠르게 합니다. 모든 ANN은 재현율 · 속도 · 메모리 사이의 트레이드오프입니다.

벡터 자체를 줄이는 스칼라 양자화(float32 → int8, 약 4배 절감)와 이진 양자화(부호만 남김, 약 32배 절감)도 인덱스와 함께 자주 씁니다. 압축 벡터로 후보를 넓게 찾고 원본 벡터로 다시 정렬(rescoring)하는 방식이 일반적입니다.

⚠️ 함정: "카테고리 = 가전" 같은 메타데이터 필터와 ANN을 함께 쓸 때 조심하세요. ANN으로 상위 10개를 먼저 찾고 나중에 필터링(post-filter)하면, 조건에 맞는 문서가 드물 때 결과가 0~2개로 줄어듭니다. 필터를 인덱스 탐색 중에 적용하는지(필터링 인식 HNSW 등) 벡터 DB의 방식을 확인하고, 선택도가 낮은 필터로 재현율을 꼭 측정하세요.

#벡터 DB · 라이브러리 비교

라이브러리는 인덱스 알고리즘만 제공하고, 벡터 DB는 여기에 저장·메타데이터 필터링·CRUD·복제·접근 제어 같은 운영 기능을 더합니다.

NMSLIB은 HNSW 구현을 초기에 대중화한 라이브러리지만, 현재는 같은 nmslib 프로젝트에서 나온 hnswlib이나 위 DB들이 주로 쓰입니다.

#pgvector 예시

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE docs (
  id        bigserial PRIMARY KEY,
  content   text,
  embedding vector(1024)
);

-- 코사인 거리용 HNSW 인덱스
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);

-- <=> 코사인 거리, <-> L2 거리, <#> 음의 내적
SELECT id, content
FROM docs
ORDER BY embedding <=> $1   -- $1: 질의 임베딩
LIMIT 5;

⚠️ 함정: pgvector는 vector 타입 인덱스가 최대 2,000차원까지만 지원합니다(halfvec은 4,000차원). 3,072차원 모델을 그대로 넣으면 인덱스를 만들 수 없으므로, 모델의 차원 축소 옵션을 쓰거나 halfvec으로 캐스팅해 인덱싱하세요.

#선택 가이드

• 이미 PostgreSQL을 쓴다 → pgvector부터 시작합니다. 별도 시스템을 늘리지 않는 이점이 큽니다.
• 프로토타입·노트북 실험 → Chroma, FAISS.
• 복잡한 필터 + 셀프 호스팅 → Qdrant.
• 수억 건 이상, 분산 클러스터 → Milvus.
• 하이브리드 검색을 DB에서 해결 → Weaviate, Elasticsearch/OpenSearch.
• 운영 인력이 없다 → Pinecone 같은 관리형, 또는 각 오픈소스의 클라우드 버전.

어느 쪽이든 공개 벤치마크 수치보다 내 데이터·필터 조건·동시성으로 측정한 재현율과 지연을 기준으로 결정하세요.

#임베딩 모델 선택

#대표 모델

모델 순위는 MTEB 리더보드에서 확인할 수 있지만, 순위는 자주 바뀌고 과제별 편차가 큽니다.

#고려사항

⚠️ 함정: 서로 다른 임베딩 모델의 벡터는 호환되지 않습니다. 같은 모델이라도 차원 설정이 바뀌면 마찬가지입니다. 모델을 교체하면 전체 문서를 다시 임베딩하고 인덱스를 새로 만들어야 하므로, 벡터와 함께 모델명·버전·차원을 메타데이터로 저장하고 교체 시 새 인덱스를 병행 구축한 뒤 전환하세요. → 전량 재구축 금지와 증분 색인

#RAG로 이어서 보기

• RAG 개요 — 검색 결과를 LLM 답변에 붙이는 전체 흐름
• RAG 심화 시리즈 — 청킹, 검색 전략, Top-K, 리랭크, 인덱스 운영
• 질의 개선 기법 — Multi-Query, HyDE, Expansion
• 지식 그래프와 벡터 DB 선택

#참고 자료

• TensorFlow — Embedding Projector
• OpenAI — Vector embeddings guide
• Google — Gemini API Embeddings
• MTEB Leaderboard
• Qwen3-Embedding 모델 카드
• BAAI/bge-m3 모델 카드, Chen et al. — M3-Embedding
• nlpai-lab/KURE-v1 모델 카드
• Kusupati et al. — Matryoshka Representation Learning
• Malkov & Yashunin — HNSW 논문
• FAISS, pgvector
• ANN-Benchmarks