대규모 RAG 최적화: 청킹(Chunking), 검색(Retrieval), 그리고 지연 시간을 40% 단축한 베이지안 탐색(Bayesian Search)

우리가 "의미론적 검색(semantic search) + 요행"에서 95%의 recall@10을 달성하는 측정 가능하고 조정 가능한 검색 파이프라인으로 전환한 방법

RAG의 현실 점검

모두가 똑같은 방식으로 RAG를 배포합니다: 512 토큰 단위로 청킹(chunking)하고, text-embedding-3-small로 임베딩(embedding)하며, top-k=5로 설정하여 컨텍스트(context)에 집어넣습니다. 데모용으로는 작동합니다.

하지만 프로덕션(production) 환경에 직면하면 다음과 같은 문제가 발생합니다:

• 법률 계약서: 512 토큰 단위 분할이 문장 중간에서 조항을 끊어버림
• API 문서: 1000 토큰 청크(chunk)가 노이즈 속에서 신호를 희석시킴
• 고객 티켓: 대화형 컨텍스트(conversational context)에는 고정된 윈도우(window)가 아닌 오버랩(overlap)이 필요함
• 지연 시간(Latency): 500ms 임베딩(embedding) + 200ms 벡터 검색(vector search) + 300ms LLM = 쿼리당 1초 이상

우리는 제1원칙(first principles)부터 검색 레이어(retrieval layer)를 다시 구축했습니다. 지표를 실제로 움직이는 요소들은 다음과 같습니다.

청킹(Chunking): 모든 상황에 맞는 단일 사이즈는 없다

# rag/chunking.py
from abc import ABC, abstractmethod
from dataclasses import dataclass
...

문서 유형별 프로덕션 설정:

하이브리드 검색(Hybrid Retrieval): BM25 + 벡터(Vector) + 리랭크(Rerank)

순수 벡터 검색은 정확한 일치(에러 코드, 함수 이름 등)를 놓칩니다. 순수 BM25는 의미론적 일치(semantic matches)를 놓칩니다. 하이브리드 방식이 승리합니다.

# rag/retrieval.py
class HybridRetriever:
    def __init__(self, vector_store, bm25_index, reranker, weights=(0.4, 0.3, 0.3)):
...

왜 크로스 인코더(cross-encoder) 리랭크(rerank)인가? 바이 인코더(bi-encoder, 임베딩) 유사도는 관련성(relevance)과 약 0.75의 상관관계를 가집니다. 크로스 인코더는 약 0.92입니다. 50개에서 5개로 줄이는 깔때기(funnel) 과정에서 50ms가 소요되지만, 재현율(recall)을 15% 높일 수 있습니다.

쿼리 변환(Query Transformation): 사용자가 질문한 그대로 검색하지 마라

사용자는 질문을 잘못합니다. 먼저 변환하십시오.

# rag/query_transform.py
class QueryTransformer:
    def __init__(self, llm_model="gpt-4o-mini"):
...

쿼리 확장(Query expansion) 결과:

• 단일 쿼리 recall@10: 78%
• 3개 확장 쿼리 (합집합): 94%
• 5개 확장 쿼리 (합집합): 96%
• 비용: 임베딩(embedding) 호출이 3~5배 증가하지만, 병렬 처리가 가능함

베이지안 최적화 (Bayesian Optimization): 하이퍼파라미터(Hyperparameters) 추측을 멈추세요

chunk_size=512, top_k=5, similarity_threshold=0.7 — 이 값들을 누가 정했을까요?

우리는 검색 (retrieval)을 블랙박스 함수 f(chunk_size, overlap, top_k, weights) → recall@10, latency로 취급하며, 베이지안 탐색 (Bayesian search)을 통해 최적화합니다.

# rag/optimization.py
import optuna
from dataclasses import dataclass
...

우리의 파레토 프런티어 (Pareto frontier) (법률 문서, 200개 쿼리 골든 세트):

프로덕션 메트릭 대시보드 (Production Metrics Dashboard)

# rag/metrics.py
from prometheus_client import Histogram, Counter, Gauge

...

결과: 6개월간의 반복 개선 (Iteration)

당신의 RAG를 위한 체크리스트

• 고정된 토큰이 아닌 문서 구조에 따라 청킹 (Chunking) 할 것
• 하이브리드 검색 (Hybrid retrieval) (BM25 + 벡터 + 재순위화 (rerank)) 사용 — 단일 모달리티(modality)는 지양할 것
• 모호하거나 짧은 쿼리를 위한 쿼리 확장 (Query expansion)
• 계층화된 케이스를 포함한 골든 데이터셋 (Golden dataset) 구축 (Git에서 버전 관리)
• 하이퍼파라미터의 베이지안 최적화 (Bayesian optimization) (매달 재실행)
• 모든 검색 단계에 대한 계측 (Instrumentation) (지연 시간, Recall 샘플링)
• 검색 변경 사항을 위한 A/B 프레임워크 (A/B framework) (피처 플래그 (feature flags) 활용)

사고방식의 전환 (The Mental Shift)

검색 (Retrieval)은 사후 고려 사항이 아니라 인프라입니다.

• 청킹 전략을 일급 객체 코드 (first-class code)로 취급할 것 (버전 관리, 테스트, 리뷰 수행)
• 골든 데이터셋 = 당신의 가장 가치 있는 지식재산 (IP) (철저하게 큐레이션할 것)
• 모든 검색 변경 = 평가 실행 (CI에 의해 강제됨)
• 회귀 (Regression) 경고 = 페이징 알림 (Paging alerts) (이메일 요약본이 아닌 즉각적인 알림)

사용자들은 당신이 어떤 임베딩 모델 (embedding model)을 쓰는지 관심이 없습니다. 그들은 답변이 정확한지에만 관심이 있습니다. 자동화된 평가 (Automated evaluation)는 대규모 환경에서 이를 보장할 수 있는 유일한 방법입니다.

코드: github.com/yourname/rag-eval-framework |
토론: Hacker News |
팔로우: @yourname