RAG 파이프라인 설계: 청킹, 임베딩, 재순위화, 운영 체크리스트

벡터 검색만으로는 충분하지 않다

벡터 데이터베이스에서 임베딩을 검색하는 것은 RAG(Retrieval-Augmented Generation) 파이프라인의 한 단계일 뿐이다. 실제로 RAG 품질은 청킹 전략, 임베딩 모델 선택, 하이브리드 검색, 재순위화 네 가지 결정에 의해 갈린다. 이 챕터는 그 네 가지를 깊이 다루고, 프로덕션 운영 체크리스트로 마무리한다.

RAG 파이프라인 전체 구조

RAG 파이프라인 전체 흐름

파이프라인은 크게 인덱싱 경로와 질의 경로로 나뉜다. 인덱싱은 오프라인에서 배치로, 질의는 실시간으로 실행된다.

청킹 전략

청킹은 원본 문서를 검색 단위로 분할하는 과정이다. 청크 크기와 방식은 Recall의 첫 번째 결정 요소다.

청킹 전략 비교

방식	특징	적합한 상황	주의점
고정 크기 (Fixed-size)	토큰/문자 수 기준 분할	균일한 문서, 빠른 프로토타입	의미 단위 파괴 가능
재귀 분할 (Recursive)	단락→문장→단어 순서로 재귀 분할	대부분의 범용 RAG 기본값	설정 비용 낮음
시맨틱 청킹 (Semantic)	문장 임베딩 유사도 기반 경계 탐지	의미 단위 보존이 중요한 경우	청킹 자체에 임베딩 비용 발생
계층형 (Hierarchical)	소청크(검색용) + 대청크(컨텍스트용)	프로덕션 기본값 (정밀도+컨텍스트 균형)	스토리지 2배, 인덱스 관리 복잡
Late Chunking	전체 문서 임베딩 후 분할	긴 문서의 경계 컨텍스트 손실 방지	장문 컨텍스트 모델 필요
부모-자식 (Parent-child)	소청크 검색 → 부모청크 컨텍스트 반환	계층형의 구현 패턴	LangChain/LlamaIndex에서 직접 지원

실용 기준

기본값: 재귀 분할, 512 토큰, 10~20% 오버랩. 2026년 다수 벤치마크에서 범용 최고 성능(69% 정확도)을 기록.

프로덕션 기본값: 계층형 청킹. 소청크(128~256 토큰)로 Recall을 높이고 대청크(512~1,024 토큰)로 컨텍스트를 제공.

계층형 청킹 구조:
  대청크 (1,024 토큰) — LLM에 전달할 전체 컨텍스트
    ├─ 소청크 A (256 토큰) — ANN 검색 대상
    ├─ 소청크 B (256 토큰)
    ├─ 소청크 C (256 토큰)
    └─ 소청크 D (256 토큰)

  검색: 소청크 ANN → 상위 K개 소청크의 부모 대청크 반환
  → 검색 정밀도 + 생성 컨텍스트 동시 확보

Late Chunking

Late Chunking은 긴 문서에서 발생하는 "경계 컨텍스트 손실"을 해결한다. 일반 청킹은 청크를 독립적으로 임베딩해 청크 경계 전후의 문맥을 잃는다. Late Chunking은 전체 문서를 한 번에 임베딩해 토큰-레벨 벡터를 얻은 다음 청크 단위로 집계한다.

일반 청킹:                     Late Chunking:
[청크A] → 임베딩A              전체 문서 → [t1 t2 t3 ... tn] 토큰 임베딩
[청크B] → 임베딩B   (독립)     청크 경계로 집계:
[청크C] → 임베딩C               → 임베딩A = mean(t1..t50)  (문서 전체 컨텍스트 반영)
                                  → 임베딩B = mean(t51..t100)

한계: 장문 컨텍스트 임베딩 모델(Jina-v3 등) 필요. 문서당 임베딩 비용이 더 크다.

임베딩 모델 선택

선택 기준

도메인 적합성: MTEB 점수는 일반 기준. 실제로는 내 데이터로 직접 테스트해야 한다. E5-small이 특정 도메인에서 70배 큰 모델을 앞선 사례가 있다.
인덱싱·질의 동일 모델 필수: 임베딩 모델을 바꾸면 전체 벡터 인덱스를 재구축해야 한다.
다국어·멀티모달: 한국어 문서라면 다국어 모델(BGE-M3, multilingual E5 등) 필요.
추론 지연: 온라인 질의에는 작은 모델이 유리. 오프라인 인덱싱에는 큰 모델 허용.

2026년 주요 임베딩 모델 (MTEB 기준)

모델	MTEB 점수	차원	특징
Cohere embed-v4	~65.2	1,024	멀티모달(이미지+텍스트), API
OpenAI text-embedding-3-large	~64.6	3,072 (가변)	Matryoshka: 차원 축소 가능
BGE-M3	~63.0	1,024	오픈소스, 다국어, 희소+밀집 동시
E5-large-v2	중상	1,024	오픈소스, 범용
Jina-v3	중상	1,024	Late Chunking 지원

Matryoshka 임베딩: 1,024차원 모델을 256차원으로 잘라도 품질이 크게 떨어지지 않는다. 스토리지·검색 속도 절약에 유용.

하이브리드 검색: BM25 + 벡터 + RRF

순수 벡터 검색은 정확한 키워드(제품 코드, 고유명사, 기술 용어)에 취약하다. 프로덕션 트래픽의 20~40%가 이런 정확 매칭 쿼리다. 하이브리드 검색은 BM25(희소)와 벡터(밀집)를 융합해 두 장점을 모두 활용한다.

BM25 vs 벡터 검색 비교

특성	BM25	벡터 검색
강점	정확한 키워드, 희귀 용어	의미적 유사성, 동의어, 패러프레이즈
약점	동의어·맥락 이해 불가	정확 용어에서 silent failure
인프라	역색인 (Elasticsearch, Opensearch 등)	ANN 인덱스 (pgvector, Qdrant 등)

Reciprocal Rank Fusion (RRF)

RRF는 두 검색 결과의 점수 단위를 통일하지 않고 순위 기반으로 융합한다. 점수 범위가 다른 BM25와 벡터 검색을 단순 가중합으로 합치면 스케일 불일치 문제가 생긴다. RRF는 이를 해결한다.

RRF 점수 = 1/(k + rank_bm25) + 1/(k + rank_vector)
  k = 60 (기본값, 고순위 결과 가중치 완화)
  rank = 해당 검색에서의 순위 (1부터 시작)

실측 성능: WANDS e-commerce 벤치마크에서 하이브리드(RRF) → NDCG 0.7497. BM25 단독 0.6983, 벡터 단독 0.6953 대비 +7.4%.

하이브리드 검색: BM25 + 벡터 + RRF 융합 구조

재순위화 (Reranking)

크로스 인코더(Cross-Encoder) 재순위화는 RAG에서 가장 과소 활용되는 기법이다. 2026년 기준 프로덕션 RAG 배포의 30% 미만만 포함하고 있지만, 도입 시 답변 정확도를 15~25% 개선한다.

바이 인코더 vs 크로스 인코더

방식	동작	속도	정확도
바이 인코더 (벡터 검색)	질의·문서 별도 임베딩 → 코사인 유사도	빠름 (ANN)	중
크로스 인코더 (재순위화)	질의+문서 쌍을 한 번에 처리 → 관련성 점수	느림 (페어별 추론)	높음

크로스 인코더는 질의와 문서를 함께 넣어 토큰 수준의 상호작용을 계산한다. 정밀도가 훨씬 높지만 N개 후보에 대해 N번 추론이 필요하므로 ANN 이후 단계에서만 사용한다.

재순위화 파이프라인

1단계 — ANN 검색: Top-50~100개 후보 후보군 확보 (빠름)
2단계 — 크로스 인코더: Top-50~100 → 관련성 점수 재계산 (정밀)
3단계 — 상위 K개 선택: 재정렬된 결과 → LLM 컨텍스트에 전달

오버샘플링 비율: ANN에서 최종 K의 3~5배를 가져와 재순위화. K=5 목표면 ANN Top-20 또는 Top-25를 재순위화한다.

주요 재순위화 모델

모델	특징
Cohere Rerank v3	API. 멀티링구얼, 엔터프라이즈 기본값
Jina Reranker v2	오픈소스 가능. 한국어 포함 다국어 지원
BGE-Reranker-v2-m3	오픈소스. BGE-M3 기반
MS MARCO 모델 (cross-encoder)	Hugging Face에서 자가 호스팅 가능

RAG 평가

RAG 파이프라인은 세 레이어에서 평가해야 한다.

평가 레이어

레이어	지표	측정 도구
검색 품질	Recall@K, NDCG@K, MRR	정답 셋 + 브루트포스 비교
재순위화 품질	P@K (재순위 후), MRR 향상	A/B 비교
종단 생성 품질	Faithfulness, Answer Relevance, Context Precision	RAGAS, TruLens, Giskard

RAGAS 지표 설명:

Faithfulness: 생성 답변이 검색된 컨텍스트에 근거하는가? (환각 탐지)
Answer Relevance: 답변이 질의에 얼마나 관련 있는가?
Context Precision: 컨텍스트 중 실제 답변 생성에 기여한 비율
Context Recall: 정답에 필요한 정보가 컨텍스트에 포함됐는가?

실용 평가 흐름:
1. 대표 질의 100~500개 골든 셋 구성
2. 각 질의에 대한 정답 문서/청크 레이블링
3. Recall@K로 검색 단계 단독 평가
4. 재순위화 전후 Recall@K 비교
5. RAGAS로 종단 생성 품질 측정
6. 주간 회귀 테스트: 데이터·모델 변경 후 지표 비교

프로덕션 운영 체크리스트

인덱싱 운영

✅ 청킹 파라미터(크기·오버랩·방식)를 설정 파일로 관리 — 변경 시 버전 기록

✅ 임베딩 모델 버전 고정 — 모델 변경 시 전체 인덱스 재구축 스케줄링

✅ 신규 문서·업데이트 시 증분 인덱싱 파이프라인 운영

✅ 삭제된 문서 벡터도 삭제 처리 — 오래된 청크 잔류 방지

✅ 배치 임베딩 비용 추적 (토큰 수 × 단가)

검색 운영

✅ BM25 인덱스도 벡터 인덱스와 동기화 유지 — 청크 추가/삭제 반영

✅ ef_search / nprobe를 목표 Recall에서 최소값으로 고정

✅ ANN 오버샘플링: 최종 K의 3~5배를 재순위화 단계로 전달

✅ 검색 지연 P99 모니터링: 벡터 + BM25 + 재순위화 각 단계별 측정

품질 모니터링

✅ 주간 Recall@K 회귀 테스트 — 데이터·모델 변경 후 자동 실행

✅ Faithfulness 점수 추적 — 환각(hallucination) 증가 조기 탐지

✅ "검색 결과 없음" 비율 모니터링 — 0-result 질의 패턴 분석

✅ 사용자 피드백(좋아요/싫어요) → 골든 셋 업데이트 주기 운영

비용 관리

✅ 임베딩 캐시: 동일 질의 반복 시 재임베딩 방지 (TTL 설정)

✅ 재순위화 API 호출 비용 추적 (오버샘플링 크기 × 요청 수)

✅ LLM 컨텍스트 길이 제한: 재순위화 후 실제로 전달되는 청크 수·토큰 수 측정

✅ 양자화 임베딩(int8/binary) 도입 시 Recall 영향 측정 후 적용

RAG 파이프라인 운영 체크리스트

흔한 실수

실수	결과	대응
청킹 크기를 한 번 정하고 재검토 안 함	도메인 특성 변화 시 Recall 조용한 저하	분기별 청킹 파라미터 회귀 테스트
BM25 없이 벡터만 사용	고유명사·코드명 쿼리 silent failure	하이브리드 검색을 기본값으로
재순위화 모델을 직접 평가 없이 선택	도메인 미적합 모델 사용	내부 골든 셋으로 MRR 비교 후 선택
인덱싱 임베딩 모델 ≠ 질의 임베딩 모델	분포 불일치로 검색 품질 급락	CI에서 모델 버전 동일성 체크
RAG 평가 없이 LLM 품질만 측정	검색 병목 원인 불명	Recall@K → Faithfulness 단계별 측정
삭제 문서 벡터를 남겨둠	오래된 정보가 계속 검색됨	삭제 이벤트에 벡터 삭제 파이프라인 연동