임베딩과 벡터 운영

분류: Layer 12 - AI 시스템 & LLM 애플리케이션 | 선수지식: L11-70 (토크나이저·임베딩), L12-10 (LLM API)

임베딩과 벡터 운영 — Vector Store, ANN Index, Chunking, Hybrid Search

1. 한 줄 정의

임베딩 운영은 텍스트·이미지를 벡터로 변환·저장·검색하는 시스템이며, vector store + ANN 인덱스 + chunking + hybrid search + reranker가 핵심 구성요소다. RAG·검색·추천의 토대.

2. 왜 중요한가

RAG의 인프라: 의미 검색 품질이 RAG 답변 품질의 절반 이상 결정
운영 비용: 1억 벡터 × 1024차원 fp32 = 400GB. 압축·차원 선택이 storage 비용 직결
latency 핵심: P99 100ms 이하 검색이 챗봇 UX 표준
품질의 출처: chunking·hybrid·reranker 하나만 빠져도 검색 품질 폭락
갱신·동기화: 문서 수정 시 어떻게 임베딩을 다시 계산·교체할지가 운영 난제

2.5 선행 기술의 한계 — ANN·압축·재정렬이 등장한 이유

bi-encoder 임베딩(L11-70)은 텍스트를 의미 벡터로 매핑하는 데 성공했지만, 운영 단계에서 세 가지 정량적 벽에 부딪힌다. 이 토픽의 세 축(ANN · quantization · hybrid+rerank)은 각 한계에 1:1 대응한다 — frontmatter lineage_oneliner와 같은 구조다.

Exact NN(Flat / brute force)의 latency 폭발: 1M × 768d fp32 코퍼스에서 200 query brute force ≈ 12.4s, 메모리 18.7GB (recall 100%). P99 < 100ms 챗봇 UX 표준과 양립 불가능. → HNSW가 등장한 이유: 그래프 기반 sublinear(≈O(log N)) 탐색으로 동일 데이터에서 0.95s · recall@10 0.962 (~13× 빠름, 13.2GB), default 설정에서 brute force 대비 96% recall @ 44× throughput. 1B+ 메모리 벽은 DiskANN(Microsoft NeurIPS 2019)이 Vamana 그래프를 SSD로 외부화해 64GB RAM + SSD에서 5000 qps · <3ms 평균 latency · 95% recall@1로 해소. 운영 비용: HNSW 인메모리 500GB ≈ $2,000/월 → DiskANN 32GB RAM + SSD ≈ $400/월(5× ↓).
fp32 메모리 비용: 1B × 768d fp32 ≈ 3TB, HNSW 오버헤드 포함 시 45TB RAM. → Quantization(§3.7)이 등장한 이유: int8(4×)·binary(32×) 절감. 사례 — 미디어사 10M 기사 임베딩에서 fp32 → int8 전환만으로 vector DB 비용 $5,600/월 → $1,400/월(75% ↓), 사용자 검색 품질 메트릭에서는 변화 미감지(Cohere blog). binary는 단독 9098% 품질 → fp32 rescoring으로 99%+ 복원.
단일 dense vector의 lexical blind spot: 고유명사·코드 식별자·법령 번호·신조어는 의미 공간에서 잘 클러스터링되지 않아 dense만으로는 recall이 폭락한다. → Hybrid search(§3.4) + Cross-encoder reranker(§3.5)가 등장한 이유: BM25로 lexical 매칭 보완 + reranker가 top-100을 정렬, 보통 recall@10 +10~30%로 RAG 단일 도구 최대 ROI.

이 토픽이 사라지면 RAG는 brute force NN의 초 단위 latency, TB급 RAM 요구, 고유명사 검색 불가 상태로 즉시 회귀한다.

3. 핵심 개념

3.1 Vector Store 종류

종류	운영 모델	특징
FAISS (Meta)	라이브러리 (in-process)	가장 빠름. persist는 직접. 단일 머신
pgvector (Postgres extension)	RDBMS	SQL 통합·트랜잭션. <10M 벡터에 강점
Pinecone	SaaS	managed, 운영 부담 없음. 비싸짐
Weaviate	self-host or cloud	hybrid search 빌트인, GraphQL
Qdrant	self-host or cloud	Rust 기반, payload filter 강함
Milvus / Zilliz	self-host or cloud (Zilliz)	scale-out (10억+ 벡터)
Chroma	embedded / server	prototype에 편함
Vespa	self-host	검색 엔진 + vector 통합. 큰 규모
Elasticsearch / OpenSearch	self-host or AWS	hybrid (BM25 + dense) 자연
Turbopuffer	SaaS (object storage)	콜드 스토리지 + serverless 검색

선택 기준

<1M 벡터, prototype: pgvector 또는 Chroma
1M~100M 벡터, self-host: Qdrant 또는 Weaviate
100M+ 벡터, scale-out: Milvus 또는 Vespa
운영 부담 회피: Pinecone, Zilliz, Turbopuffer
Postgres 생태계: pgvector + pg_search (BM25 결합)
검색 엔진과 통합: Elasticsearch / OpenSearch

3.2 ANN (Approximate Nearest Neighbor) 인덱스

수백만~수십억 벡터에서 정확한 NN은 비현실적. 근사 검색이 표준.

알고리즘	메모리	latency	recall	비고
Flat	100% (원본)	O(N) 매우 느림	100%	brute force. <100k에만
HNSW	~1.5× 원본	매우 빠름	95~99%	운영 표준. 그래프 기반
IVF	~원본	k-means cluster + 탐색	90~95%	큰 규모, 빠른 색인 가능
IVF-PQ	원본의 4~32× ↓	빠름	85~95%	Product Quantization. 메모리 절감
DiskANN	디스크 사용	디스크 latency	95%+	메모리 부족 시. Vamana 그래프
SCANN	메모리·디스크	Google 표준	95%+	TPU·SSD 최적화

HNSW 파라미터

M: 그래프 연결 수 (16~64). 클수록 recall ↑, 메모리 ↑
efConstruction: 색인 시 탐색 폭 (100~500)
efSearch: 검색 시 탐색 폭 (50~500). 늘리면 recall ↑, latency ↑

운영 권장 시작값: M=32, efConstruction=200, efSearch=100. 측정 후 튜닝.

결정 트리거 (silent failure 예방):

메모리 예산 < 코퍼스 × 1.5 → HNSW 인메모리 불가, DiskANN 또는 IVF-PQ로 전환. 그대로 HNSW를 강행하면 OOM 또는 swap으로 P99가 100ms → 수 초로 튀어오른다 (감지: kubectl top pod RSS와 mlock 실패 로그).
recall@10 < 0.9 측정 시 efSearch 우선 ↑(100→200), 그래도 미달이면 M ↑(16→32). 반대로 efSearch만 무한히 올리면 latency가 brute force 수준으로 회귀 — recall 한계점에서 모델·chunking·hybrid를 의심해야 한다.
코퍼스 < 100k에 ANN 적용은 오버헤드만 떠안는다 — Flat exact로 회귀(여기서 brute force는 ms 단위).

3.3 Chunking 전략

문서를 어떻게 쪼개느냐가 검색 품질의 50%.

방식	설명	장점	단점
Fixed-size	N 토큰 단위 (예: 512)	단순, 빠름	의미 단위 깨짐
Recursive	paragraph → sentence → token 순 분할	의미 구조 부분 보존	LangChain `RecursiveCharacterTextSplitter` 표준
Semantic	임베딩 거리 기반 분할	의미 단위 보존	비용 ↑, latency ↑
Structural	markdown heading·HTML 구조	문서 구조 보존	구조 없는 텍스트엔 무력
Sliding window	overlap 두고 슬라이드	경계 정보 보존	중복 ↑

표준 권장 (Chunk Size + Overlap)

일반 텍스트: chunk 512~~1024 토큰, overlap 50~~100
코드: 함수·class 단위 (structural)
표·리스트: 행 단위 또는 entire structural unit 보존
한국어: 토큰 효율 감안해 영어 대비 ~50% chunk size

Late chunking

NEW (Jina, 2024-2025): 문서 전체를 임베딩한 뒤 token-level 임베딩에서 chunk를 추출. context-aware chunking으로 품질 ↑.

3.4 Hybrid Search — BM25 + Dense

dense embedding만으로는 약한 영역(고유명사·신조어·법률·코드 식별자) 보완 (L11-70 §3.13).

1. BM25 (lexical) → top-100
2. Dense embedding (semantic) → top-100
3. RRF (Reciprocal Rank Fusion): score = Σ 1/(k + rank_i)
4. 합쳐서 top-K 반환

RRF k: 보통 60. 두 ranking을 동등하게 결합
가중치 조정: α·rank_dense + (1-α)·rank_bm25. 도메인에 따라
BGE-M3 통합 모드: 한 모델이 dense + sparse + ColBERT 동시 출력 → 셋을 RRF로 결합 (L11-70 §3.8)
Elasticsearch / OpenSearch / Weaviate / Vespa: hybrid 빌트인

도메인별 가중치

일반 자연어 QA: dense 0.7 / BM25 0.3
법률·의학·고유명사 多: dense 0.4 / BM25 0.6
코드 검색: dense 0.3 / BM25 0.7 (식별자 매칭이 중요)

Semantic retrieval 품질 튜닝 순서

semantic retrieval 품질은 한 번에 한 기법으로 해결되지 않는다. production에서는 recall을 먼저 확보하고, rerank·filter로 precision을 회복하는 순서가 안정적이다.

1. Query rewriting: 사용자 표현을 문서 표현으로 정규화
2. Hybrid search: dense가 놓치는 고유명사·식별자·숫자를 BM25로 보완
3. Metadata filter: tenant, permission, product, language, updated_at 범위 제한
4. Rerank: top-50~100 후보를 cross-encoder로 정렬
5. Context packing: parent chunk, dedupe, 최신 문서 우선순위 적용

Query rewriting: “그거 비용은?” 같은 후속 질문을 “RAG 아키텍처 운영 비용은?”처럼 독립 검색어로 만든다. chat history를 무조건 붙이면 noise가 늘므로 최근 intent와 entity만 보존한다.
Hybrid: dense recall이 부족한 도메인(한국어 고유명사, 코드, 법령 번호)에서 기본값. RRF로 넓게 합친 뒤 reranker가 정리한다.
Metadata filter: 품질 기법이면서 보안 기법이다. tenant_id, acl, doc_type, language, version, updated_at은 검색 전에 pre-filter하는 것이 원칙이다. 응답 직전 필터는 permission leak을 막지 못한다.
Recall / precision trade-off: top-K를 키우면 recall은 오르지만 context precision과 generation 품질은 떨어진다. 권장 흐름은 retrieve top-100 → rerank top-10 → context top-5~7이다.
최신성 가중치: 정책·가격·장애 문서는 cosine score만으로 정렬하면 오래된 문서가 이길 수 있다. rerank 후 updated_at decay 또는 version filter를 적용한다.

3.5 Reranker — 2단계 검색

bi-encoder embedding은 빠르지만 정확도 한계. 2단계 검색이 표준 (L11-70 §3.12).

Stage 1 (retrieve): bi-encoder로 top-100 후보 (10ms)
Stage 2 (rerank):   cross-encoder reranker로 top-10 (50~100ms)

운영 표준 reranker

BGE-reranker-v2-m3 (open, 다국어)
voyage-rerank-2 / 2-lite (API)
Cohere Rerank 3.5 (API)
Jina Reranker v2 (다국어)
MS MARCO MiniLM-L6: 가장 작고 빠른 baseline

ROI: recall@10 보통 10~30% 개선 — RAG 운영에서 가장 큰 ROI 도구.

3.6 Multi-Vector / Late Interaction (ColBERT)

문서 하나 = 단일 vector 대신 token별 vector 집합.

ColBERT: 각 query token이 각 document token과 max 유사도, 합 = 점수

장점: bi-encoder보다 정확, cross-encoder보다 빠름
단점: storage 多 (token 수만큼 vector)
운영 도구: ColBERT-v2, BGE-M3 multi-vector mode, RAGatouille
사용처: 정확도가 중요한 검색, code search

3.7 Quantization과 차원 축소 (재방문)

L11-70 §3.10·3.11을 운영 시점으로.

기법	storage 절감	품질 영향	권장 사용
fp32 → fp16	2×	~0	단순 적용
fp32 → int8	4×	<1%	운영 default
fp32 → binary (1bit)	32×	~5%	1차 후 fp32로 rerank 권장
Matryoshka 256d	6× (vs 1536)	1~3%	256+binary = 192× 절감
PQ (Product Quant)	4~32× (구성)	5~15%	FAISS 표준

운영 패턴

2-stage retrieval: binary로 1차 (top-1000) → fp32로 rerank (top-10). 이 패턴은 columnar DB의 “bloom filter로 1차 page skip → 원본 page에서 verify”와 동형이고, anti-spam 시스템의 “MinHash 후보군 추출 → 정밀 비교”와도 같다. 일반 공식: 근사·고압축 1차 → 정밀·고비용 2차.
Cohere int8/binary 측정값: int8 — storage 4× ↓, 검색 품질 ~~100% 유지(거의 free win), 검색 속도 최대 40× 향상. binary — storage 32× ↓, 단독 품질 90~~98% 유지, fp32 rescoring 결합 시 99%+ 복원 (Cohere int8/binary blog).
사례 (Cohere blog): 미디어사 10M 기사 임베딩 fp32 → int8 단순 전환, vector DB 비용 $5,600/월 → $1,400/월(75% ↓), 사용자 검색 품질 변화는 메트릭상 감지되지 않음.
언제 쓰면 안 되는가 (Inversion): ① 코퍼스 < 100k라 latency가 이미 ms 단위면 quantization 품질 손실만 떠안는다. ② reranker 단계가 없는 단일 단계 검색에서 binary 단독 사용 → recall 5%+ 손실, fp32 rerank 동반 필수. ③ Matryoshka 절단은 학습 시 정해진 단계(예: 1536 → 768 → 256 → 128)에서만 안전 — 임의 절단(예: 256 → 200) 시 품질 폭락.

3.8 갱신·동기화

운영의 가장 어려운 영역.

패턴

Append-only: 새 문서만 추가, 옛날 것은 그대로. 가장 단순
Soft delete + reindex: 삭제된 문서는 metadata 마킹, 주기적 reindex
Versioning: 문서마다 version 키. 검색 후 latest만
CDC (Change Data Capture): DB의 변경을 Kafka·event stream으로 → 임베딩 파이프라인 자동 갱신

CDC / Outbox 기반 freshness architecture

문서 원본이 DB·CMS·S3·Git 등 여러 곳에 있으면 “문서가 바뀌었는데 벡터는 옛날 것”이 가장 흔한 장애가 된다. RAG freshness는 batch cron보다 변경 이벤트를 잃지 않는 파이프라인으로 설계한다.

source DB/CMS commit
  → outbox row 또는 CDC event
  → embedding job queue
  → chunk 재생성 + embedding
  → vector upsert(new version)
  → old version soft delete
  → freshness lag metric 기록

Outbox: 업무 트랜잭션과 document_changed 이벤트를 같은 DB commit에 넣는다. 이벤트 발행 실패로 색인이 누락되는 문제를 줄인다.
CDC: Debezium·Kafka 등으로 변경 로그를 읽어 embedding queue에 넣는다. 원본 DB를 polling하지 않아도 되고, 장애 후 offset부터 재처리 가능하다.
Idempotency key: doc_id + version + chunk_hash로 upsert를 멱등화한다. 같은 이벤트가 두 번 와도 vector가 중복 생성되면 안 된다.
Freshness SLA: “문서 수정 후 5분 안에 검색 반영”처럼 lag 목표를 둔다. 모니터링은 event_time → indexed_at p95/p99로 본다.
Blue-green index: 임베딩 모델·chunking 전략 변경은 partial upsert가 아니라 새 index를 만들고 shadow query로 검증한 뒤 alias를 전환한다.

흔한 silent failure

Stale embedding: 문서 수정됐지만 임베딩이 옛것 → 잘못된 답변
Orphan vectors: 원본 문서 삭제됐는데 vector 남음
임베딩 모델 변경: 모델 교체 시 전체 reindex 필요 — 비용 大. blue-green 패턴 또는 dual-index 운영
Tokenizer drift: chunk를 다시 만들 때 토크나이저 차이로 chunk 경계 변화

3.9 모니터링과 평가

검색 품질을 production에서 측정.

Retrieval 품질 지표

Recall@k: 정답 문서가 top-k 안에 들어왔는가
MRR (Mean Reciprocal Rank): 정답 평균 rank의 역수
NDCG@k: 순위까지 고려한 품질 지표
Hit@k: top-k 안에 적어도 1개 정답

모니터링 지표

query latency P50/P95/P99
recall@k (gold dataset로)
index size, vector count
cache hit ratio (자주 쓰는 query는 cache)
임베딩 API 호출 비용 / drift

표준 도구

Ragas (L11-80): faithfulness·context recall·context precision·answer relevance
TruLens: RAG triad
DeepEval: 자동 평가
자체 gold dataset + Promptfoo

3.10 운영 silent failure

운영자가 자주 만나는 함정.

Chunk size 부적절: 너무 작아 context 부족, 너무 커 noise 多
Hybrid 가중치 미튜닝: dense만 쓰면 고유명사·법령 검색 약함
Reranker 누락: top-10 정렬이 엉망
임베딩 모델 mismatch: query·document를 다른 모델로 임베딩. 에러는 안 나고 recall@10이 random 수준(<10%)으로 떨어진다. 감지: SELECT model_version, COUNT(*) FROM vectors GROUP BY 1 결과가 2종 이상이면 의심. 복구: 두 모델 중 하나로 통일 reindex, 마이그레이션 중에는 dual-index로 query를 두 인덱스에 동시 라우팅.
Cold start: 새 문서 임베딩 큐 처리 지연 → 검색 안 됨. 감지: 임베딩 큐 lag(p99 > 분 단위)과 “최근 24h 신규 문서 검색 hit rate”를 동시 모니터링 — 어느 한쪽만 보면 놓친다.
Storage 폭증: 의도한 양보다 vector 수 多 (중복 문서 등). 감지: vector_count / source_doc_count 비율이 평소(예: 5±1 chunks/doc) 대비 2× 이상 튀면 중복 chunking 또는 reindex 누적이 원인.
Permission leak (가장 silent): 권한 없는 문서가 top-k에 섞여 노출. HTTP 200, recall·latency 메트릭 정상이라 자동 알람이 안 걸린다. 감지: 매 query 응답에 assert all(doc.tenant_id == ctx.tenant_id for doc in results) 강제 + 일 단위 tenant cross-leak audit job(표본 query × tenant pair). 복구: 메타데이터에 tenant_id NOT NULL 제약, ANN 인덱스를 tenant별 분리하거나 pre-filter 강제 (pgvector WHERE tenant_id = $1 partial index, Qdrant payload index + filter, Pinecone namespace). RBAC가 검색 stage가 아니라 응답 stage에서만 걸린 경우가 가장 흔한 leak 패턴이다.
Over-filtering: metadata filter가 너무 강해 정답 문서가 후보군에 들어오지 않음. 감지: 필터 적용 전 recall@50과 필터 적용 후 recall@50을 분리 측정. 복구: 필수 보안 필터와 품질 필터(language, date, doc_type)를 분리하고, 품질 필터는 fallback 완화 규칙을 둔다.

3.11 깨지는 조건 정량 표 (운영 결정용)

기법	효과 발휘 범위	깨지는 조건
Flat (exact)	<100k 벡터, 정확도 100%	1M+ → ANN 필수
HNSW M=16	일반 운영 (1M~100M)	매우 큰 데이터(>1B) → IVF·DiskANN
HNSW efSearch=100	표준 (recall ~95%)	더 높은 recall 필요 → ef=200~500 (latency↑)
IVF	큰 데이터셋, 빠른 색인	small dataset에선 HNSW가 더 빠르고 정확
DiskANN	메모리 부족 환경	latency 민감 작업엔 부적합
RRF (k=60)	hybrid search 표준	k 너무 작으면(<10) 한쪽 ranking 압도
BGE-M3 통합	다국어·multi-mode 운영	단일 dense만 필요한 단순 작업엔 오버헤드
Reranker	top-100 → top-10 재정렬	latency budget <50ms면 적용 어려움
Metadata filter	권한·언어·버전 제한	과도하면 recall 손실, 누락 시 permission leak
Binary embedding	32× storage·40× 속도	단독 사용 품질 ~95% — fp32 rerank 필수
Matryoshka 256d	1~3% 손실, 6× 절감	256d 미만 절단은 품질 폭락

3.12 Silent Failure 시나리오와 복구

증상	정량 시그널	원인	복구
Stale embedding	검색 결과 옛 정보	문서 수정 후 reindex 누락	CDC + 임베딩 큐 자동화
Orphan vectors	vector count > document count	삭제 미반영	soft delete + 주기적 cleanup
모델 버전 변경 후 검색 깨짐	recall@10 50%+ ↓	전체 reindex 필요	blue-green 또는 dual-index 운영
Permission leak	다른 tenant 문서 검색됨	metadata filter 누락	tenant_id 필수 filter, audit
Over-filtering	filter 후 recall@50 급락	language/date/doc_type 과제한	보안 필터와 품질 필터 분리, fallback
Hybrid 가중치 실수	dense·BM25 한쪽만 적용	RRF 또는 α 미설정	도메인별 가중치 default 표준화
Reranker latency 초과	P99 > 200ms	top-100 너무 많음	top-50으로 줄임, 작은 reranker (MiniLM)
HNSW recall 낮음	recall@10 < 90%	efSearch 부족	efSearch ↑(100→200), M ↑(16→32)

3.13 임베딩 운영의 일반 매핑 (Transferable Pattern)

벡터 검색 시스템 = “근사 검색 + 정확 재정렬 + 압축”. 다른 검색 시스템과 같은 패턴.

임베딩 운영 구성요소	일반 시스템 매핑
Vector store (FAISS, pgvector)	DB·search engine (Elasticsearch)
ANN index (HNSW)	DB index (B-tree, LSM-tree)
Chunking	document partitioning, sharding
Hybrid search (BM25 + dense)	full-text + structured query
RRF (Reciprocal Rank Fusion)	weighted vote, ensemble ranking
Cross-encoder rerank	2-stage cache lookup, allowlist + verify
Quantization (int8, binary)	columnar compression, bloom filter
Stale embedding	cache invalidation, MV refresh
Permission filter	row-level security, RBAC

일반 공식: “근사 검색(빠름·낮은 정확) → 정확 재정렬(느림·정확)“의 2단계 패턴이 RAG·검색·추천·anti-spam 시스템 전반에 공통이다. 이 위에 갱신·권한·압축이 추가된다.

운영 시나리오 — 사내 RAG vector store 결정 (예시)

상황: 사내 정책 1M 문서, P95 < 80ms, recall@10 > 0.8, 한국어
선택지:
  A. pgvector + HNSW: PostgreSQL 통합, 1M에 적합
     - storage: 1M × 1024d × fp32 = 4GB
     - latency P95 ~50ms (HNSW efSearch=100)
  B. Qdrant self-host: payload filter 강함
  C. pgvector + BGE-M3 hybrid (BM25 + dense + RRF):
     - 한국어 고유명사·법령 정확도 ↑
     - latency +20ms
  D. C + Matryoshka 256d + Cohere int8 quantization:
     - storage: 4GB → 256MB (16×↓)
     - 품질 ~99% 유지

선택: D.
대안 비선택: A 단독 한국어 약함, B 단독 PostgreSQL 분리, C는 storage 비효율.
silent failure 모니터링 (§3.12):
  - stale embedding: CDC 큐
  - permission leak: tenant_id metadata filter
  - reranker latency: top-50 cap

결과 (가상): storage 256MB, P95 75ms, recall@10 0.84.

§3.1 vector store + §3.4 hybrid + §3.7 quantization + §3.11 깨지는 조건 + §3.12 silent failure 모두 적용.

4. 실무에서 어디에 쓰이나

RAG (L12-40 깊이 다룸)
의미 검색 (사내 문서, FAQ)
추천 시스템 (사용자·아이템 임베딩)
중복 탐지 (문서·이미지)
클러스터링·토픽 분석
코드 검색

5. 현재 내 업무와 연결점

플랫폼 엔지니어가 임베딩 인프라를 운영할 때 다음에 도움된다.

Vector store 선택: <1M = pgvector, 1M+ = Qdrant·Weaviate, scale-out = Milvus
HNSW 튜닝: M·efConstruction·efSearch sweep으로 recall vs latency 최적
Hybrid + Reranker 패턴: 한국어·고유명사 운영에 가장 큰 ROI
Quantization 비용 절감: int8로 4× 절감 (품질 거의 그대로) 또는 binary + rerank
갱신 파이프라인: CDC + 임베딩 큐 + reindex 자동화
모니터링 dashboard: recall@k, latency P99, vector count, drift

6. 자주 헷갈리는 개념 비교

개념 A	개념 B	차이점
Flat (exact)	HNSW (ANN)	100% recall vs 95~99%, latency 차이 큼
HNSW	IVF	그래프 vs cluster 기반. HNSW가 일반적으로 빠름·정확
Bi-encoder	Cross-encoder	1단계 (빠름·낮은 정확) vs 2단계 (느림·정확)
Bi-encoder	ColBERT (multi-vec)	단일 vector vs token별 vector + late interaction
Dense	BM25 (sparse)	semantic 매칭 vs lexical 매칭. hybrid가 정답
Fixed chunk	Semantic chunk	단순·빠름 vs 의미 단위 보존·비용 ↑
Recall@k	NDCG@k	들어왔는가 vs 순위까지 고려
FAISS	pgvector	라이브러리 (in-process) vs Postgres extension (SQL)

7. 체크리스트

8. 추가 학습 키워드

Vector store: FAISS, pgvector, Pinecone, Weaviate, Qdrant, Milvus, Chroma, Vespa, Elasticsearch, Turbopuffer
ANN 인덱스: HNSW, IVF, IVF-PQ, DiskANN, SCANN, ANNoy, NSG
Chunking: fixed, recursive, semantic, structural, sliding, late chunking, contextual chunking
Hybrid: BM25, RRF (Reciprocal Rank Fusion), SPLADE (learned sparse), ColBERT (late interaction)
Semantic retrieval 품질: query rewriting, metadata pre-filter, recall/precision trade-off, freshness boosting, context packing
Reranker: BGE-reranker-v2-m3, voyage-rerank-2, Cohere Rerank 3.5, Jina Reranker, MiniLM
Quantization: int8, binary, PQ (Product Quantization), Matryoshka, OPQ
운영: CDC, outbox pattern, Kafka, Debezium, Airflow, Prefect, dbt + embedding pipeline, blue-green index

9. 내가 직접 확인해볼 것

인덱스 비교

같은 1만개 벡터에 Flat vs HNSW vs IVF로 검색 latency·recall@10 비교 (FAISS Python). 예상: HNSW가 1ms 미만, recall 99%
HNSW의 efSearch를 50, 100, 200, 500으로 sweep — recall vs latency 곡선 그리기

Chunking 실험

같은 PDF에 fixed-512 vs recursive vs semantic chunking — RAG 답변 품질 비교
한국어 chunk size 256 vs 512 vs 1024 비교 — 토큰 효율 감안한 최적 size 식별

Hybrid Search

pgvector + tsvector(BM25)로 hybrid search 구현. RRF k=60으로 결합 → dense 단독 대비 recall@10 변화
도메인별 dense:BM25 가중치 sweep (0.3:0.7 vs 0.7:0.3) — 한국어 법률 도메인에선 어느 쪽이 우세?
metadata filter 적용 전/후 recall@50·precision@10을 분리 측정 — over-filtering과 permission leak을 동시에 확인

Reranker

같은 top-100을 BGE-reranker-v2-m3로 rerank → top-10 정렬 변화. 정답 문서가 더 위로 올라가는지

Quantization

OpenAI text-embedding-3-large 1000개를 fp32 vs int8 vs binary로 저장하고 검색 — recall@10 비교
Matryoshka 256d + binary 결합 → 192× storage 절감 확인

갱신 시뮬레이션

100개 문서 인덱싱 → 50% 수정 → reindex vs upsert 패턴 비교
outbox 이벤트 100건을 중복·역순으로 넣고 doc_id + version + chunk_hash 멱등 upsert가 중복 vector를 만들지 않는지 확인

결과가 예상과 다를 때

HNSW recall이 낮음 → efSearch ↑ 또는 M ↑
Hybrid 결과가 dense 단독보다 나쁨 → BM25 분석기 한국어 미설정 (Nori, Mecab 필요)
Metadata filter 후 정답이 사라짐 → 보안 필터와 품질 필터 분리, 품질 필터 fallback 적용
Reranker 효과 미미 → bi-encoder 모델이 이미 강함 (다국어 SOTA), reranker 도메인 mismatch
Binary 후 품질 폭락 → 2-stage retrieval로 fp32 rerank 추가

10. 5줄 요약

Vector store 선택은 규모·운영 부담으로 결정 — pgvector(<1M), Qdrant·Weaviate(1M+), Milvus·Vespa(scale-out).
HNSW가 ANN 인덱스 표준이고 M·efConstruction·efSearch가 핵심 튜닝 노브.
Chunking·Hybrid search·Metadata filter·Reranker가 RAG 검색 품질과 보안의 핵심 경로다.
Quantization(int8 4×, binary 32×) + Matryoshka로 storage 비용을 192×까지 절감 가능.
운영 silent failure는 stale embedding, orphan vector, 모델 변경 시 reindex, tokenizer drift, over-filtering이 흔하다.

11. 출처

최종 수정: 2026-05-21