HyDE + Reranking + Query Expansion: 2026년 6월 기준 “진짜” RAG 성능을 끌어올리는 고급 검색 스택

게시 2026/06/28

By Daewook Kwon

17 분읽는 시간

들어가며

프로덕션 RAG에서 성능이 “거의 맞는데 결정적으로 틀리는” 케이스는 보통 retrieval 단계에서 top-k 안에 정답 근거가 못 들어오거나, 들어와도 상위에 못 올라와 LLM 프롬프트에 실리지 않아서 발생합니다. 2026년 기준 현업에서 가장 재현성 있게 먹히는 처방은 크게 3가지 축입니다:

Query Expansion: 사용자의 짧고 모호한 query를 여러 개로 “펼쳐” recall을 올림
HyDE (Hypothetical Document Embeddings): LLM이 “그럴듯한 답변 문서”를 먼저 써주고, 그 문서를 임베딩해 retrieval의 semantic gap을 줄임 (ocadefusion.fr)
Reranking (Cross-Encoder / ColBERT): 1차 후보(대개 50~200개)를 “질문-문서 쌍”으로 정밀 채점해 top-n을 재정렬 (presenc.ai)

언제 쓰면 좋나

문서가 길고 다양하며(내부 위키/정책/기술문서), query가 짧고 모호한 편
“정답 문서가 아예 안 잡히는” recall 문제가 있거나
하이브리드(BM25+dense)만으로는 domain mismatch가 자주 나는 경우

언제 쓰면 안 되나

이미 1차 retrieval top-10에 정답이 안정적으로 들어오는데 “생성/프롬프트”가 문제인 경우(이때는 rerank/HyDE는 비용만 늘고 효과가 작을 수 있음) (callsphere.ai)
초저지연(수십 ms) 요구가 강한 실시간 서비스에서 cross-encoder rerank를 무턱대고 넣는 경우(캐싱/게이팅 없으면 곧바로 비용 폭발)

🔧 핵심 개념

1) Query Expansion: “recall을 돈으로 사는” 전략

정의: 하나의 query를 여러 variant로 확장(재작성/분해/동의어/약어 풀기 등)하고, 각 query로 검색한 결과를 RRF(Reciprocal Rank Fusion) 같은 방식으로 합치는 접근입니다. SemEval/TREC 계열 시스템도 multi-stage에서 query rewriting + hybrid + rerank 조합을 반복적으로 사용합니다. (arxiv.org)

흐름

LLM(또는 rule)로 query variant N개 생성
각 variant로 BM25 + dense(또는 둘 중 하나) 검색
결과를 RRF로 fuse → 후보 풀을 크게 확보
(선택) reranker로 최종 상위만 정밀 선별

차이점

HyDE가 “문서 형태로 변환”이라면, Query Expansion은 “질문 자체를 여러 개로” 늘립니다.
Expansion은 coverage(포괄성), HyDE는 semantic gap 완화에 강점.

2) HyDE: “질문을 문서로 바꿔서” 임베딩 공간의 위치를 이동

정의: LLM이 query에 대해 답변에 가까운 hypothetical document를 생성하고, 그 문서를 임베딩해 검색합니다(원 query 임베딩 대신/또는 함께). 원 아이디어는 retrieval에서 query가 너무 짧아 임베딩이 불안정한 문제를 줄이는 것. (ocadefusion.fr)

내부 작동(실무 관점)

query → (LLM) hypothetical doc 생성
hypothetical doc → embedding
embedding으로 vector search 수행
(보통) 원 query vector search도 같이 수행하고 fuse(RRF)하는 편이 안전

2026년식 관찰 포인트

임베딩/하이브리드가 강해진 환경에서는 HyDE의 평균 이득이 작아져서, “어려운 query에만 켠다(gating)”가 수익성이 좋다는 경험칙이 보고됩니다. (callsphere.ai)

3) Reranking: 2-stage RAG의 “결정타”

정의: 1차 retriever가 뽑은 top-K(보통 50~200)를 cross-encoder가 query-document를 직접 입력으로 받아 점수를 내고 재정렬합니다. embedding 기반 유사도(=bi-encoder)와 달리, cross-encoder는 질문과 문서를 함께 보며 미세한 관련성을 잡습니다. (bge-model.com)

대표 모델/트렌드(2026년 상반기)

오픈 웨이트 쪽은 Qwen3-Reranker, BGE-Reranker-v2 계열이 자주 언급됩니다. (presenc.ai)
BGE 쪽 문서도 reranker가 “embedding이 아니라 query+doc → score”라는 점을 명확히 합니다. (bge-model.com)
연구/실험에서는 retriever(HyDE/HyPE/Fusion) + reranker(BGE/MiniLM 등) 조합 평가가 계속 나오고 있습니다. (link.springer.com)

💻 실전 코드

아래는 현실적인 내부 문서 RAG를 가정한 파이프라인 예시입니다.

Vector DB: Qdrant
1차 검색: Dense(top=80) + BM25(top=80) + RRF fuse
Query Expansion: LLM으로 3개 variant 생성
HyDE: LLM으로 hypothetical doc 1개 생성(어려운 query일 때만)
Rerank: BGE cross-encoder로 최종 top-12 선별
출력: 상위 문서의 score/메타데이터

0) 의존성/실행 준비

  
pip install qdrant-client sentence-transformers transformers torch --upgrade
# OpenAI 사용 시:
pip install openai

1) 파이프라인 코드 (Python)

  
import os
from dataclasses import dataclass
from typing import List, Dict, Tuple
from qdrant_client import QdrantClient
from sentence_transformers import SentenceTransformer, CrossEncoder

# ---- 설정 ----
QDRANT_URL = os.getenv("QDRANT_URL", "http://localhost:6333")
COLLECTION = os.getenv("QDRANT_COLLECTION", "internal_docs")

# Dense embedder (예: BGE-M3 같은 계열을 가정)
EMBED_MODEL = os.getenv("EMBED_MODEL", "BAAI/bge-m3")

# Reranker: cross-encoder (2026년 현업에서 자주 쓰는 BGE reranker 계열)
RERANK_MODEL = os.getenv("RERANK_MODEL", "BAAI/bge-reranker-v2-m3")

# ---- 데이터 구조 ----
@dataclass
class Hit:
    doc_id: str
    text: str
    source: str
    score: float  # retrieval or rerank score
    meta: Dict

# ---- 유틸: RRF ----
def rrf_fuse(rank_lists: List[List[Hit]], k: int = 60) -> List[Hit]:
    # RRF score = sum(1 / (k + rank))
    # doc_id 기준으로 합산
    acc: Dict[str, Tuple[Hit, float]] = {}
    for hits in rank_lists:
        for rank, h in enumerate(hits, start=1):
            add = 1.0 / (k + rank)
            if h.doc_id not in acc:
                acc[h.doc_id] = (h, add)
            else:
                acc[h.doc_id] = (acc[h.doc_id][0], acc[h.doc_id][1] + add)

    fused = []
    for doc_id, (h, s) in acc.items():
        fused.append(Hit(doc_id=doc_id, text=h.text, source=h.source, score=s, meta=h.meta))
    fused.sort(key=lambda x: x.score, reverse=True)
    return fused

# ---- (선택) LLM 기반 Query Expansion / HyDE ----
# 여기서는 OpenAI를 예로 들되, 사내 LLM/로컬 LLM로 대체 가능하도록 함수로 분리
def llm_generate_variants(query: str) -> List[str]:
    """
    현실 팁: variant는 3~5개가 보통 sweet spot.
    - 약어 풀기
    - 동의어/제품명 변형
    - 한글/영문 혼용
    """
    try:
        from openai import OpenAI
        client = OpenAI()
        prompt = f"""
너는 검색 최적화 전문가다.
원문 질의: {query}
목표: 내부 기술문서 검색 recall을 올리기 위한 query variants 3개를 만들어라.
조건:
- 원문의 의도를 유지
- 약어/영문/한글 변형 포함
- 출력은 JSON 배열 문자열로만
"""
        r = client.responses.create(
            model="gpt-4.1-mini",
            input=prompt,
            temperature=0.2,
        )
        import json
        return json.loads(r.output_text)
    except Exception:
        # LLM 미구성 시 fallback
        return [query, query + " 가이드", query + " troubleshooting"]

def llm_generate_hyde_doc(query: str) -> str:
    """
    HyDE: '답변이 실린 것 같은 문서'를 생성하되,
    사실성보다 '검색용 표현 다양성'이 핵심.
    """
    try:
        from openai import OpenAI
        client = OpenAI()
        prompt = f"""
다음 질문에 답하는 내부 기술 문서의 한 섹션을 작성해라.
질문: {query}

조건:
- bullet/절차/키워드를 풍부하게 포함
- 특정 회사 비밀/가정 데이터는 만들지 말고 일반화
- 길이: 200~350자
"""
        r = client.responses.create(
            model="gpt-4.1-mini",
            input=prompt,
            temperature=0.3,
        )
        return r.output_text
    except Exception:
        return f"{query}\n\n키워드: 설정, 오류, 원인, 해결, 체크리스트"

def is_hard_query(query: str) -> bool:
    # 실무에서는 (1) 길이, (2) OOV 비율, (3) 과거 실패율, (4) 초기 top-k score gap 등으로 게이팅
    return len(query) < 12 or ("?" in query)

# ---- 검색기 ----
class RagRetriever:
    def __init__(self):
        self.qdrant = QdrantClient(url=QDRANT_URL)
        self.embedder = SentenceTransformer(EMBED_MODEL)
        self.reranker = CrossEncoder(RERANK_MODEL)

    def dense_search(self, query: str, limit: int = 80) -> List[Hit]:
        qv = self.embedder.encode(query, normalize_embeddings=True).tolist()
        res = self.qdrant.search(
            collection_name=COLLECTION,
            query_vector=qv,
            limit=limit,
            with_payload=True,
        )
        hits = []
        for p in res:
            payload = p.payload or {}
            hits.append(Hit(
                doc_id=str(p.id),
                text=payload.get("text", ""),
                source=payload.get("source", "unknown"),
                score=float(p.score),
                meta=payload
            ))
        return hits

    def bm25_search(self, query: str, limit: int = 80) -> List[Hit]:
        # Qdrant의 full-text 인덱싱/필터를 사용한다고 가정 (구현은 스키마에 따라 달라짐)
        # 여기서는 예시로 "text" 필드 full-text match를 사용했다고 가정한 pseudo.
        res = self.qdrant.search(
            collection_name=COLLECTION,
            query_filter={
                "must": [
                    {"key": "text", "match": {"text": query}}
                ]
            },
            limit=limit,
            with_payload=True
        )
        hits = []
        for p in res:
            payload = p.payload or {}
            hits.append(Hit(
                doc_id=str(p.id),
                text=payload.get("text", ""),
                source=payload.get("source", "unknown"),
                score=float(p.score),
                meta=payload
            ))
        return hits

    def rerank(self, query: str, candidates: List[Hit], top_n: int = 12) -> List[Hit]:
        pairs = [(query, h.text[:2000]) for h in candidates]  # 너무 길면 잘라서 비용/지연 관리
        scores = self.reranker.predict(pairs)
        reranked = []
        for h, s in zip(candidates, scores):
            reranked.append(Hit(doc_id=h.doc_id, text=h.text, source=h.source, score=float(s), meta=h.meta))
        reranked.sort(key=lambda x: x.score, reverse=True)
        return reranked[:top_n]

    def retrieve(self, query: str) -> List[Hit]:
        variants = llm_generate_variants(query)

        rank_lists = []
        for q in variants:
            rank_lists.append(self.dense_search(q, limit=80))
            rank_lists.append(self.bm25_search(q, limit=80))

        if is_hard_query(query):
            hyde_doc = llm_generate_hyde_doc(query)
            rank_lists.append(self.dense_search(hyde_doc, limit=80))  # HyDE는 doc를 query로 넣는 셈

        fused = rrf_fuse(rank_lists, k=60)[:200]   # rerank 입력 풀은 100~200 사이가 흔함
        reranked = self.rerank(query, fused, top_n=12)
        return reranked

if __name__ == "__main__":
    rr = RagRetriever()
    q = "HyDE를 RAG에 넣었는데 reranking까지 해야 하나?"
    top = rr.retrieve(q)
    for i, h in enumerate(top, 1):
        print(f"{i:02d}. score={h.score:.4f} source={h.source} id={h.doc_id}")
        print(h.text[:180].replace("\n", " "))
        print("-" * 80)

예상 출력(형태)

rerank score 기반으로 상위 문서가 재정렬되며, 동일 문서가 여러 query variant에서 걸려도 RRF로 합쳐진 뒤 1회만 rerank 됩니다.

⚡ 실전 팁 & 함정

Best Practice (효과 큰 순)

1) Rerank는 “후보 풀 품질”이 전제
reranker는 top-200 안에 정답이 있어야 이깁니다. 그래서 보통 “hybrid + expansion + (필요 시 HyDE)”로 후보 풀 recall을 먼저 올리고, 그 다음 rerank로 precision을 올립니다. (arxiv.org)

2) HyDE는 상시 ON보다 ‘게이팅’이 현실적
HyDE는 LLM 호출 + 추가 검색이므로 비용이 누적됩니다. 최근 글/경험 공유에서는 강한 baseline(좋은 embedding + hybrid) 위에서는 평균 이득이 작아 어려운 query에만 켜는 전략이 수익성이 좋다고 봅니다. (callsphere.ai)

3) 오픈 웨이트 reranker는 BGE 계열이 디폴트 옵션이 됨
cross-encoder 기반 reranker가 “프로덕션 RAG의 2nd stage”라는 점, 그리고 BGE reranker가 대표 오픈 모델로 널리 쓰인다는 점이 여러 자료에서 반복됩니다. (presenc.ai)

흔한 함정/안티패턴

“reranker 넣었더니 오히려 나빠짐”:
- (a) reranker가 cross-encoder가 아니라 bi-encoder(임베딩 모델)를 잘못 쓴 경우
- (b) 언어/도메인 mismatch(특히 비영어, 사내 용어)
- (c) 후보 풀이 너무 작아 rerank가 의미 없음
  현업에서도 이런 케이스가 꽤 보고됩니다. (reddit.com)
rerank 입력 텍스트를 무제한으로 넣기: 토큰/지연/VRAM이 바로 터집니다. 상위 chunk의 앞부분만, 혹은 “query 주변 window”만 잘라 넣는 게 비용 대비 효율이 좋습니다.

비용/성능/안정성 트레이드오프

Query Expansion/HyDE는 LLM 호출 비용 + 지연이 추가되지만, retriever가 약한 구간에서 recall을 올리는 데 강합니다.
Cross-encoder rerank는 후보 K에 선형으로 비용이 늘어납니다(대개 K=100~200에서 타협). “항상 최고 모델”이 아니라, 트래픽 구간별로 MiniLM급(저가) vs BGE급(고품질) 이원화도 흔합니다. (presenc.ai)

🚀 마무리

정리하면, 2026년 6월 시점의 실전형 RAG 성능 최적화는 “한 방”이 아니라 스택 설계입니다.

Recall이 문제면: Query Expansion + (필요 시) HyDE로 후보 풀을 키우고 (ocadefusion.fr)
Precision이 문제면: cross-encoder reranking을 2nd stage로 고정하고, K/top-n/텍스트 길이로 비용을 제어 (presenc.ai)
HyDE는 강력하지만, 강한 baseline 위에서는 게이팅이 도입 판단의 핵심 (callsphere.ai)

다음 학습/실험 추천:

내 데이터셋에서 “정답 문서가 top-200 안에 있나?”(oracle recall@200) 먼저 재고, 그 다음 rerank/HyDE/expansion을 단계적으로 추가하세요.
retriever–reranker 조합을 통제 실험으로 비교한 2026년 평가 연구(예: retriever/ reranker 페어링 비교)를 읽고, 본인 도메인에 맞게 K, fusion, reranker 모델 크기를 튜닝하는 게 가장 빠릅니다. (link.springer.com)

AI, RAG

ai rag trend 2026-06