프로덕션 RAG 2026: 하이브리드 검색 + 리랭킹으로 검색 품질 끌어올리기

왜 지금 검색 단계가 RAG의 병목인가

RAG(Retrieval-Augmented Generation)를 프로덕션에 올려본 팀이라면 한 번쯤 같은 벽에 부딪힙니다. 모델은 충분히 똑똑한데, "엉뚱한 문서를 근거로" 그럴듯하게 틀린 답을 합니다. 2026년의 합의는 분명합니다. RAG의 실패는 대부분 생성이 아니라 검색에서 일어납니다. 단순 벡터 검색만 쓰는 나이브 파이프라인일수록 실패가 검색 단계에 집중됩니다.

원인은 단일 검색 방식의 구조적 한계입니다. 밀집 벡터 검색은 "이 문장이 무슨 의미인가"에는 강하지만, 제품 코드(KERN-4421)나 사내 약어, 정확한 함수명 같은 정확 일치(exact match) 에는 약합니다. 반대로 키워드 검색(BM25)은 정확 일치엔 강하지만 동의어·문맥을 놓칩니다. 두 방식은 서로 상보적으로 실패합니다. 그래서 프로덕션 RAG는 하이브리드 검색(dense + sparse)으로 넓게 건진 뒤, 리랭커로 정밀하게 좁히는 2단계 구조로 수렴했습니다.

이 글에서는 BM25 + 밀집 벡터를 RRF(Reciprocal Rank Fusion)로 결합하고, cross-encoder 리랭커로 상위 문서만 정밀 재정렬하는 프로덕션 파이프라인을 코드와 함께 정리합니다. 운영 벡터 스토어는 pgvector를 기준으로 하되, Qdrant 대안도 함께 다룹니다.

배경: 검색 전략별 강·약점과 2026년 선택지

먼저 세 가지 검색 전략의 특성을 비교합니다.

검색 방식	강점	약점	대표 구현
밀집 벡터 (Dense)	의미·동의어·문맥	정확 일치, 희귀 토큰, 신조어	임베딩 + ANN(HNSW/IVFFlat)
희소 키워드 (Sparse)	정확 일치, 코드/약어, 설명가능	동의어·의미 누락	BM25, SPLADE++
하이브리드 (Dense+Sparse)	상보적 결합, 리콜·정밀 균형	융합·튜닝 복잡도 ↑	RRF로 두 결과 병합

2026년 기준 주요 벡터 스토어의 하이브리드 지원 현황도 정리해 둡니다.

스토어	하이브리드(RRF)	특징	IntentCode 적용 관점
pgvector 0.9	PG full-text + 벡터로 근사	Postgres 단일 스택, 운영 단순	운영 RAG 기본(이미 Postgres 사용)
Qdrant	일급 RRF, BM25/SPLADE++/miniCOIL	하이브리드·late-interaction 선두	대규모·고급 검색 시 후보
Weaviate	일급 RRF	모듈형, 내장 벡터화	멀티모달 확장 시 후보

핵심은 "어떤 DB가 최고냐"가 아니라, 하이브리드 + 리랭킹이라는 패턴 자체가 검색 품질을 좌우한다는 점입니다. IntentCode는 운영 RAG를 Postgres + pgvector로 단일화해 운영 복잡도를 낮추고, BM25는 Postgres 전문 검색(또는 애플리케이션 레벨)으로 보완하는 구성을 기본으로 둡니다.

심층 분석: 2단계 검색 파이프라인

전체 흐름은 다음과 같습니다.

질의 → [밀집 검색 top-20] ┐
      → [희소 검색 top-20] ┴→ RRF 융합 top-20 → cross-encoder 리랭크 top-5 → LLM

원칙은 한 줄로 요약됩니다. "넓게 건지고(recall 최적화), 정밀하게 좁힌다(precision 최적화)." 1차 검색은 리콜을 위해 top-20처럼 넓게 가져오고, 리랭커가 top-5로 정밀하게 추립니다.

1) RRF로 두 검색 결과 융합하기

RRF는 점수 스케일이 전혀 다른 두 검색 결과(코사인 유사도 vs BM25 점수)를 순위(rank)만으로 안전하게 합칩니다. 공식은 단순합니다.

$$\text{RRF}(d) = \sum_{r \in \text{rankings}} \frac{1}{k + \text{rank}_r(d)}$$

k는 상수로 보통 60을 씁니다. k=60은 다양한 데이터셋에서 상위·하위 항목의 영향 균형이 좋은 값으로 알려져 있습니다(예: rank 1 → 1/61 ≈ 0.0164, rank 10 → 1/70 ≈ 0.0143).

def reciprocal_rank_fusion(
    rankings: list[list[str]], k: int = 60
) -> list[tuple[str, float]]:
    """여러 검색 결과(문서 id 리스트)를 RRF로 융합한다.

    rankings: 각 검색기가 반환한 '순위대로 정렬된' 문서 id 리스트들
    반환: (doc_id, score) 내림차순
    """
    scores: dict[str, float] = {}
    for ranking in rankings:
        for rank, doc_id in enumerate(ranking, start=1):
            scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)
    return sorted(scores.items(), key=lambda x: x[1], reverse=True)

점수 정규화(min-max 등) 없이도 동작하는 점이 RRF의 실전 장점입니다. 검색기를 추가/교체해도 융합 로직을 건드릴 필요가 없습니다.

2) pgvector + BM25 하이브리드 검색

pgvector로 밀집 검색을, Postgres 전문 검색(ts_rank)으로 희소 검색을 수행한 뒤 위 RRF로 합칩니다. 먼저 스키마와 인덱스입니다.

-- 확장 및 테이블
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE chunks (
  id          bigserial PRIMARY KEY,
  doc_id      text NOT NULL,
  content     text NOT NULL,
  embedding   vector(1024) NOT NULL,           -- 임베딩 차원에 맞춤
  tsv         tsvector GENERATED ALWAYS AS (to_tsvector('simple', content)) STORED
);

-- 밀집: HNSW (코사인)
CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);
-- 희소: 전문 검색 GIN
CREATE INDEX ON chunks USING gin (tsv);

애플리케이션 레벨에서 두 검색을 각각 수행하고 RRF로 융합합니다.

import asyncpg

DENSE_SQL = """
  SELECT id::text
  FROM chunks
  ORDER BY embedding <=> $1          -- <=> : 코사인 거리
  LIMIT $2
"""

SPARSE_SQL = """
  SELECT id::text
  FROM chunks
  WHERE tsv @@ plainto_tsquery('simple', $1)
  ORDER BY ts_rank(tsv, plainto_tsquery('simple', $1)) DESC
  LIMIT $2
"""

async def hybrid_search(
    pool: asyncpg.Pool, query: str, query_vec: list[float], top_k: int = 20
) -> list[str]:
    async with pool.acquire() as conn:
        dense_rows = await conn.fetch(DENSE_SQL, str(query_vec), top_k)
        sparse_rows = await conn.fetch(SPARSE_SQL, query, top_k)

    dense_ids = [r["id"] for r in dense_rows]
    sparse_ids = [r["id"] for r in sparse_rows]
    fused = reciprocal_rank_fusion([dense_ids, sparse_ids])
    return [doc_id for doc_id, _ in fused[:top_k]]

참고: pgvector의 HNSW 탐색 폭은 SET hnsw.ef_search = 100; 으로 조정합니다. 리콜이 부족하면 키우고, 지연이 문제면 낮춥니다.

Qdrant를 쓴다면 동일 패턴을 일급 API로 처리할 수 있습니다(BM25 sparse + dense를 RRF로 한 번에).

from qdrant_client import QdrantClient, models

client = QdrantClient(url="http://qdrant:6333")

results = client.query_points(
    collection_name="chunks",
    prefetch=[
        models.Prefetch(query=query_vec, using="dense", limit=20),
        models.Prefetch(query=models.Document(text=query, model="Qdrant/bm25"),
                        using="sparse", limit=20),
    ],
    query=models.FusionQuery(fusion=models.Fusion.RRF),  # 일급 RRF
    limit=20,
)

3) Cross-encoder 리랭킹

RRF로 추린 top-20을 cross-encoder로 재정렬합니다. bi-encoder(임베딩)는 질의·문서를 따로 인코딩하지만, cross-encoder는 (질의, 문서) 쌍을 함께 인코딩해 관련성을 직접 점수화합니다. 정밀도가 크게 오르는 대신 비용이 듭니다. 그래서 전체가 아니라 상위 후보에만 적용합니다. 오픈소스 bge-reranker-v2-m3는 정확도·지연 균형이 좋아 sub-500ms 엔드투엔드 RAG에 무난히 들어갑니다.

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("BAAI/bge-reranker-v2-m3", max_length=512)

def rerank(query: str, candidates: list[dict], top_n: int = 5) -> list[dict]:
    """candidates: [{'id':..., 'content':...}, ...] (RRF top-20)"""
    pairs = [(query, c["content"]) for c in candidates]
    scores = reranker.predict(pairs)          # 쌍별 관련성 점수
    ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)
    return [c for c, _ in ranked[:top_n]]

리랭킹은 프로덕션 RAG에서 단일 항목으로 가장 효과가 큰 최적화로 꼽힙니다. top-20 → top-5로 좁히면 LLM에 들어가는 컨텍스트의 신호 대 잡음비가 확연히 좋아집니다.

실전 가이드: 엔드투엔드 조립

위 조각을 하나의 검색 함수로 묶습니다.

async def retrieve(pool, embed_fn, query: str) -> list[dict]:
    # 1) 질의 임베딩
    query_vec = await embed_fn(query)
    # 2) 하이브리드 검색 (RRF top-20)
    ids = await hybrid_search(pool, query, query_vec, top_k=20)
    # 3) 본문 로드
    rows = await pool.fetch(
        "SELECT id::text, content FROM chunks WHERE id::text = ANY($1)", ids
    )
    candidates = [{"id": r["id"], "content": r["content"]} for r in rows]
    # 4) cross-encoder 리랭크 (top-5)
    return rerank(query, candidates, top_n=5)

운영 파라미터는 환경별로 분리해 관리합니다.

# config/retrieval.yaml
retrieval:
  dense_top_k: 20
  sparse_top_k: 20
  rrf_k: 60
  rerank_top_n: 5
  hnsw_ef_search: 100
reranker:
  model: BAAI/bge-reranker-v2-m3
  max_length: 512
  batch_size: 32

품질을 "측정"하기 (RAGAS)

체감이 아니라 숫자로 회귀를 잡아야 합니다. RAGAS 프레임워크의 대표 지표와 실무 임계값은 다음과 같습니다.

지표	의미	권장 임계값
Faithfulness	답변이 근거 문서에 충실한가	> 0.9
Answer Relevancy	답변이 질문에 적합한가	> 0.85
Context Precision	검색 컨텍스트의 정밀도	> 0.8
Context Recall	정답 근거를 얼마나 건졌나	가능한 높게

from ragas import evaluate
from ragas.metrics import (
    faithfulness, answer_relevancy, context_precision, context_recall,
)

result = evaluate(
    dataset,   # question / answer / contexts / ground_truth 컬럼
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
)
print(result)  # CI 게이트: 임계값 미달 시 빌드 실패 처리

골든 질의 50~100개를 고정해 두고 PR마다 위 스코어를 회귀 테스트로 돌리면, 검색기·프롬프트·청크 전략을 바꿀 때 품질 변화를 객관적으로 추적할 수 있습니다.

트러블슈팅

1) 하이브리드를 켰는데 정밀도가 오히려 떨어졌다 대개 1차 리콜이 부족한 상태에서 리랭커가 "나쁜 후보 중 최선"을 고르는 경우입니다. dense_top_k/sparse_top_k를 20→40으로 늘려 리콜을 먼저 확보한 뒤, 리랭크 top_n은 그대로 두세요. 리랭커는 좋은 후보가 후보군에 들어와 있어야 제 역할을 합니다.

2) 리랭킹 지연이 p95에서 튄다 cross-encoder를 전체 결과에 돌리고 있지 않은지 확인하세요. 반드시 RRF 상위 후보(예: 20개)에만 적용하고, batch_size로 한 번에 추론합니다. CPU만 있다면 ONNX/quantize 또는 더 작은 리랭커로 내리고, 부하가 크면 리랭커를 별도 서비스로 분리해 수평 확장합니다.

3) 정확한 코드/약어 질의가 여전히 누락된다 밀집 검색만 타고 있을 가능성이 큽니다. BM25 쪽 plainto_tsquery가 토큰을 제대로 만드는지(특수문자·대소문자) 점검하고, 식별자성 토큰은 simple 사전 사용 + 별도 정규화를 적용하세요. 희소 검색의 기여가 RRF에 실제로 반영되는지 두 검색의 결과 id를 로깅해 확인합니다.

결론: IntentCode의 관점

2026년 프로덕션 RAG의 정답은 더 큰 모델이 아니라 더 나은 검색입니다. 하이브리드(dense + sparse) + RRF + cross-encoder 리랭킹이라는 2단계 구조는 이제 선택이 아니라 기본기입니다. IntentCode는 운영 RAG를 Postgres + pgvector로 단일화해 운영 복잡도를 낮추고, 여기에 BM25 보완 검색과 리랭킹, 그리고 RAGAS 기반 회귀 게이트를 더해 "측정 가능한 검색 품질"을 고객 환경에 이식하는 일을 합니다. 검색이 흔들리면 그 위의 모든 에이전트가 흔들립니다 — RAG는 검색부터 단단하게 세워야 합니다.