Hybrid RAG 심화 가이드

1. RAG의 본질과 한계

왜 RAG인가?

LLM은 파라미터에 지식을 "압축 저장"합니다. 그래서 두 가지 약점이 있습니다:

1. 최신성 부족 — 학습 시점 이후 정보 모름 (Claude는 2026-01 cutoff)
2. 개별 문서 부재 — 내 회사 내부 문서, 특정 PDF 내용 모름
3. 환각(Hallucination) — 모르는 걸 아는 척

RAG는 검색(Retrieval)으로 관련 문서를 찾고, 생성(Generation)할 때 근거로 제시합니다.

단순 RAG의 한계

Vector 검색 하나로는 부족합니다. 이유:

• 의미 유사도 ≠ 질문에 답하는 능력 — "애플 실적"과 "Apple earnings"는 의미상 비슷해도 원하는 답이 다를 수 있음
• 문맥 손실 — 청크 경계에서 중요 정보 잘림
• Bi-encoder 한계 — 쿼리·문서를 독립적으로 임베딩, 세밀한 매칭 불가

2. Bi-encoder vs Cross-encoder 원리

Hybrid RAG의 구조를 이해하려면 두 모델 패러다임의 차이를 알아야 합니다.

왜 둘을 합치는가?

Cross-encoder로 100만 문서를 매번 계산하면 너무 느림. Bi-encoder로 빠르게 20개 거르고, 그 20개만 Cross-encoder로 정밀 판정. 속도와 정확도의 타협.

3. 청킹 전략 — Size & Overlap 튜닝

청킹은 RAG 성능의 가장 큰 레버입니다. 잘못하면 정답률이 반 토막.

청크 크기 (Chunk Size)

오버랩 (Overlap)

강의 기본 설정 (권장값)

RecursiveCharacterTextSplitter(
    chunk_size=1000,       # 약 500 토큰 (한국어 기준)
    chunk_overlap=200,      # 20% 오버랩
    separators=['\n\n', '\n', '. ', ' ', '']
)

Recursive Splitter의 우선순위

separators 리스트는 위에서 아래로 순차 시도:

1. \n\n (빈 줄) — 문단 경계. 가장 자연스러운 분할점
2. \n (줄바꿈) — 문단 내부 분할이 필요할 때
3. . (마침표+공백) — 문장 단위. 한국어는 다. 도 추가 고려
4. ' ' (공백) — 단어 단위. 어쩔 수 없을 때
5. '' (빈 문자열) — 글자 단위. 마지막 수단

Advanced: 계층적 청킹 (Hierarchical Chunking)

큰 문서의 경우 parent 청크(2000자) + child 청크(500자)를 함께 관리. 검색은 child로 하고 맥락은 parent를 반환.

# Parent chunks (맥락용, 임베딩 안 함)
parent_splitter = RecursiveCharacterTextSplitter(chunk_size=2000)
parents = parent_splitter.split_text(doc)

# Child chunks (검색용, 임베딩)
child_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=100)
for parent_id, parent_text in enumerate(parents):
    children = child_splitter.split_text(parent_text)
    for child in children:
        embedding = embed(child)
        store(child, embedding, metadata={'parent_id': parent_id})

# 검색 시: child로 찾고 parent 반환
results = vector_search(query, top_k=5)
parent_ids = [r.metadata.parent_id for r in results]
final_context = [parents[pid] for pid in set(parent_ids)]

4. Embedding 모델 선택

주요 Embedding 모델 비교 (2026-04 기준)

언제 어떤 모델?

차원 축소 옵션

OpenAI text-embedding-3는 Matryoshka 기법으로 차원을 줄일 수 있습니다:

response = openai.embeddings.create(
    model='text-embedding-3-small',
    input=text,
    dimensions=512   # 1536 → 512 (1/3 크기)
)
# 정확도는 ~3% 하락, 저장·검색 속도 3배 향상

5. Reranker 딥다이브

Reranker 모델 비교

Reranker 호출 규칙

최적의 Top-K 결정

RRF (Reciprocal Rank Fusion) — Advanced

Dense(벡터) + Sparse(BM25/키워드) 검색을 결합하는 기법:

def rrf_fusion(vector_results, bm25_results, k=60):
    """두 검색 결과를 RRF로 융합."""
    scores = {}
    
    for rank, doc in enumerate(vector_results):
        scores[doc.id] = scores.get(doc.id, 0) + 1 / (k + rank + 1)
    
    for rank, doc in enumerate(bm25_results):
        scores[doc.id] = scores.get(doc.id, 0) + 1 / (k + rank + 1)
    
    # 점수 높은 순 정렬
    return sorted(scores.items(), key=lambda x: -x[1])

8주 강의의 RAG 구조 재확인

6. 성능 측정 + 벤치마크

핵심 메트릭 3종

강의 구조의 실측 성능

간단한 벤치마크 코드

# 평가 세트: 질문 + 정답 문서 ID
test_set = [
    {'q': 'FOMC 점도표 2026년 중간값', 'answer_ids': ['doc_42']},
    {'q': '인플레이션 전망', 'answer_ids': ['doc_17', 'doc_23']},
    # ... 20~50개 이상 준비
]

def recall_at_k(retrieval_fn, test_set, k=3):
    hits = 0
    for t in test_set:
        results = retrieval_fn(t['q'], top_k=k)
        result_ids = {r['id'] for r in results}
        if set(t['answer_ids']) & result_ids:
            hits += 1
    return hits / len(test_set)

# 측정
r3_vector = recall_at_k(vector_search, test_set, k=3)
r3_hybrid = recall_at_k(hybrid_search, test_set, k=3)

print(f'Vector Recall@3: {r3_vector:.1%}')
print(f'Hybrid Recall@3: {r3_hybrid:.1%}')

7. RAG 실패 패턴 + 해결

실패 패턴 Top 7

8. 운영 체크리스트

구축 전

• □ 예상 문서 수 + 평균 크기 추정 (벡터 DB 용량 예측)
• □ 쿼리 유형 분석 (factoid / summarization / comparison)
• □ 타겟 메트릭 결정 (Recall@3 80%+? MRR 0.7+?)
• □ 테스트 세트 구축 (최소 20개 질문+정답)

구축 중

• □ 청킹 설정 기본값으로 시작 (1000자 + 200 overlap)
• □ 저장 시 metadata 필수 (source·page·chunk_id·file_hash·timestamp)
• □ 1차 검색 top_k=20 이상
• □ Reranker top_n=3~5
• □ 컨텍스트 인용 프롬프트 엄격 작성
• □ 환각 방지 Guardrail 추가 ("출처 없으면 모름")

배포 후

• □ 첫 주 Recall@K 측정 → 목표치 미달이면 청크 크기부터 조정
• □ 사용자 피드백 수집 ("좋아요/싫어요" 버튼)
• □ 실패 케이스 로그 → 주간 리뷰
• □ 신규 문서 주기적 reindex (월 1회)
• □ Embedding / Reranker 모델 업데이트 추적
• □ 비용 모니터링 (임베딩 · 검색 · 생성 각각)