대규모 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)부터 검색 계층을 다시 구축했습니다. 지표를 실제로 움직이는 요소들은 다음과 같습니다.

청킹(Chunking): 만능 사이즈는 없다

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

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

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

순수 벡터 검색(pure vector search)은 정확한 일치(에러 코드, 함수 이름 등)를 놓칩니다. 순수 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의 상관관계를 가집니다. 크로스 인코더(cross-encoder)는 약 0.92입니다. 50개에서 5개로 줄이는 깔때기(funnel) 과정은 50ms의 비용이 들지만, 15%의 재현율(recall)을 얻습니다.

쿼리 변환(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) 경고 = 페이징 알림 (이메일 요약본이 아닌 즉각적인 알림)

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

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