RAG가 “거의 맞는데” 마지막 10%가 안 오를 때: HyDE × Reranking × Query Expansion 실전 최적화 가이드 (2026년 6월)

게시 2026/06/10

By Daewook Kwon

19 분읽는 시간

들어가며

프로덕션 RAG에서 가장 흔한 실패 패턴은 단순합니다. 정답 문서가 인덱스에 존재하는데도 LLM이 못 봅니다. 이유는 대개 (1) query가 코퍼스 표현과 어긋나거나, (2) 1차 retrieval이 후보를 충분히 못 모으거나(Recall 문제), (3) 후보는 모였는데 top-k에 못 올라오는(Precision 문제) 케이스입니다. 이때 2026년 기준으로 “질을 올리는” 대표 레버가 HyDE(가상 문서 기반 retrieval), Reranking(2단계 정밀 정렬), Query Expansion/Rewrite(질의 재작성/다중 질의) 조합입니다. TREC RAG 2025 1위 시스템도 HyDE와 hybrid retrieval, reranking을 묶어서 성과를 냈고, HyDE embedding과 원 query embedding을 섞는 HyDE Vector Mix 같은 실용적 변형까지 제시합니다. (trec.nist.gov)

언제 쓰면 좋나:

질문이 애매하거나 짧고, 문서 표현이 다양해 “표현 불일치”가 큰 도메인(내부 위키/설계문서/정책/FAQ)
멀티턴 대화에서 대명사/생략이 많아 query 자체가 retrieval에 부적합한 경우(standalone rewrite 필요) (docs.nvidia.com)
top-k 컨텍스트가 “거의 맞는데” 정답 chunk가 20~200위에 숨어있는 경우(= reranking이 가장 잘 먹힘)

언제 쓰면 안 되나(혹은 제한적으로):

정밀 숫자/표 기반 질의(재무/지표/정책 조항 번호): 2026년 벤치마크에서 HyDE·multi-query 같은 expansion이 “정확한 수치 질의”에는 이득이 제한적이라는 보고가 있습니다. 이런 경우 BM25/hybrid + reranking이 더 일관되게 유리합니다. (arxiv.org)
latency/budget가 빡센 서비스에서 multi-query를 무제한으로 쓰는 것(LLM 호출/검색 호출 폭증)

🔧 핵심 개념

1) HyDE (Hypothetical Document Embeddings)

HyDE는 “query를 그대로 embed”하지 않고, LLM으로 query에 대한 가상의 답변/문서(= hypothetical document) 를 생성한 뒤 그 텍스트를 embedding해서 retrieval에 쓰는 기법입니다. 요지는 query → (LLM) 가상 문서 → embedding → vector search 로, query가 너무 짧거나 키워드가 빈약할 때 “문서처럼 생긴” 텍스트로 의미 신호를 증폭합니다. (emergentmind.com)

실무적으로 중요한 포인트는 HyDE가 “사실”을 만들려고 하는 게 아니라, retrieval space에서 가까워질 표현을 만들어내는 것입니다. 그래서 TREC RAG 2025에서는 원 query embedding과 HyDE embedding을 섞는 mixing ratio α를 두고, query 타입에 따라 최적 α가 다를 수 있다고 분석합니다. (trec.nist.gov)
→ 즉, HyDE는 “항상 on”이 아니라 게이팅/믹싱이 핵심입니다.

2) Reranking (2-stage retrieval의 정석)

대부분의 프로덕션 RAG는 이제 “1차(cheap)로 많이 뽑고, 2차(expensive)로 정확히 줄이는” 구조가 기본입니다. 1차는 dense/sparse/hybrid로 50~200개 후보를 모으고, 2차에서 cross-encoder reranker가 query-문서 쌍을 직접 읽고 점수화해 top-k를 재정렬합니다. 이 패턴은 SemEval-2026 MTRAGEval 제출 시스템에서도 query rewriting → hybrid(BM25+dense, RRF) → cross-encoder reranking(BGE reranker) 로 명확히 나타납니다. (arxiv.org)

왜 cross-encoder가 강한가?

bi-encoder(embedding)는 query와 문서를 독립적으로 벡터화해 근사 유사도를 봅니다.
cross-encoder는 query와 문서를 동시에 넣고 attention으로 상호작용을 보며 “이 문서가 이 질문에 답이 되는가”를 직접 학습해 점수화합니다.
대신 비용은 큽니다(후보 개수 × 모델 추론).

3) Query Expansion / Query Rewriting / Multi-Query

여기서 용어가 섞이기 쉬운데, 실무 관점에서 이렇게 나누면 판단이 쉽습니다.

Query Rewriting(standalone rewrite): 멀티턴에서 “그거/저거/거기” 같은 지시어를 풀어 독립 질의로 바꿈. NVIDIA RAG blueprint도 “정확도는 올라가지만 LLM 호출로 latency가 추가된다”는 점을 명시합니다. (docs.nvidia.com)
Multi-Query(다중 질의 확장): 같은 의도를 다양한 표현으로 N개 질의로 만들어 각각 retrieval한 뒤 합치고(rerank/fusion) 최종 top-k를 뽑음. recall에 강하지만 비용이 폭증합니다.
Keyword Expansion(BM25 보강): sparse retrieval의 약점을 보완하기 위해 동의어/연관어를 생성해 BM25 query를 확장. TREC RAG 2025에서도 “BM25 query expansion용 키워드 생성 프롬프트”를 별도로 둡니다. (trec.nist.gov)

핵심 차이:

HyDE는 ‘문서형 텍스트’를 만들어 dense 신호를 강화
Query expansion은 ‘질의 표현’을 늘려 recall을 넓힘
Reranking은 후보를 “정답 우선”으로 정렬해 precision을 올림

💻 실전 코드

아래는 “내부 기술문서(Confluence/Notion export/Markdown) + Qdrant + hybrid + HyDE mix + cross-encoder rerank”를 한 번에 엮는 현실적인 파이프라인 예시입니다. 포인트는 (1) hybrid로 후보 풀을 넓히고, (2) HyDE는 mix로 과신을 막고, (3) rerank는 top-N 후보에만 적용하는 것입니다.

0) 의존성/환경

  
python -m venv .venv && source .venv/bin/activate
pip install qdrant-client "fastembed>=0.3.0" sentence-transformers rank-bm25 openai python-dotenv

Qdrant: vector store
fastembed: 빠른 embedding(로컬)
sentence-transformers: cross-encoder reranker
rank-bm25: 로컬 BM25(예시는 간단화를 위해 인메모리; 실무에선 Elasticsearch/OpenSearch 권장)
openai: HyDE/rewriting용 LLM(다른 LLM으로 대체 가능)

1) 인덱싱(현실 시나리오: “제품 장애 대응 런북 + 설계 문서”)

  
# rag_advanced.py
import os
from dataclasses import dataclass
from typing import List, Dict, Tuple

from qdrant_client import QdrantClient
from qdrant_client.http import models as qm
from fastembed import TextEmbedding

from rank_bm25 import BM25Okapi
from sentence_transformers import CrossEncoder

from openai import OpenAI


@dataclass
class Chunk:
    id: str
    text: str
    meta: Dict


class AdvancedRAG:
    def __init__(
        self,
        qdrant_url: str,
        collection: str = "runbooks",
        embed_model: str = "BAAI/bge-small-en-v1.5",
        reranker_model: str = "BAAI/bge-reranker-v2-m3",
    ):
        self.collection = collection
        self.qdrant = QdrantClient(url=qdrant_url)
        self.embedder = TextEmbedding(model_name=embed_model)
        self.reranker = CrossEncoder(reranker_model)  # cross-encoder
        self.llm = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

        self._bm25 = None
        self._bm25_chunks: List[Chunk] = []

    def create_collection(self, dim: int):
        self.qdrant.recreate_collection(
            collection_name=self.collection,
            vectors_config=qm.VectorParams(size=dim, distance=qm.Distance.COSINE),
        )

    def index(self, chunks: List[Chunk]):
        # 1) dense index
        texts = [c.text for c in chunks]
        vecs = list(self.embedder.embed(texts))
        dim = len(vecs[0])
        self.create_collection(dim)

        points = []
        for c, v in zip(chunks, vecs):
            points.append(
                qm.PointStruct(
                    id=c.id,
                    vector=v,
                    payload={"text": c.text, **c.meta},
                )
            )
        self.qdrant.upsert(collection_name=self.collection, points=points)

        # 2) bm25 index (toy 아님: 실무에선 문서량 커지면 ES로 대체)
        tokenized = [t.lower().split() for t in texts]
        self._bm25 = BM25Okapi(tokenized)
        self._bm25_chunks = chunks

    def _hyde(self, query: str) -> str:
        prompt = (
            "Generate a hypothetical answer (~150 words) to improve dense retrieval. "
            "It does NOT need to be factually correct. Avoid specific numbers/dates.\n\n"
            f"Query: {query}"
        )
        r = self.llm.responses.create(
            model="gpt-4.1-mini",
            input=prompt,
        )
        return r.output_text

    def _rewrite_standalone(self, query: str, history: List[Tuple[str, str]]) -> str:
        # 멀티턴이면 rewrite, 아니면 원문 유지
        if not history:
            return query
        hist = "\n".join([f"User: {u}\nAssistant: {a}" for u, a in history[-2:]])
        prompt = (
            "Rewrite the user's last question into a standalone search query. "
            "Preserve constraints and identifiers. Output ONLY the rewritten query.\n\n"
            f"{hist}\n\nUser: {query}"
        )
        r = self.llm.responses.create(model="gpt-4.1-mini", input=prompt)
        return r.output_text.strip()

    def _dense_search(self, query_vec, top_n: int) -> List[Tuple[str, float, Dict]]:
        res = self.qdrant.search(
            collection_name=self.collection,
            query_vector=query_vec,
            limit=top_n,
            with_payload=True,
        )
        return [(str(p.id), float(p.score), p.payload) for p in res]

    def _bm25_search(self, query: str, top_n: int) -> List[Tuple[str, float, Dict]]:
        scores = self._bm25.get_scores(query.lower().split())
        ranked = sorted(enumerate(scores), key=lambda x: x[1], reverse=True)[:top_n]
        out = []
        for idx, s in ranked:
            c = self._bm25_chunks[idx]
            out.append((c.id, float(s), {"text": c.text, **c.meta}))
        return out

    def _rrf_fuse(self, runs: List[List[Tuple[str, float, Dict]]], k: int = 60) -> List[Tuple[str, float, Dict]]:
        # Reciprocal Rank Fusion: score = sum 1/(k + rank)
        # TREC 계열에서 널리 쓰는 간단/강력한 fusion ([trec.nist.gov](https://trec.nist.gov/pubs/trec34/papers/UTokyo.rag.pdf))
        agg: Dict[str, Tuple[float, Dict]] = {}
        for run in runs:
            for rank, (doc_id, _score, payload) in enumerate(run, start=1):
                rrf = 1.0 / (k + rank)
                if doc_id not in agg:
                    agg[doc_id] = (0.0, payload)
                agg[doc_id] = (agg[doc_id][0] + rrf, payload)

        fused = [(doc_id, sc, payload) for doc_id, (sc, payload) in agg.items()]
        fused.sort(key=lambda x: x[1], reverse=True)
        return fused

    def answer(
        self,
        query: str,
        history: List[Tuple[str, str]] = None,
        dense_top: int = 80,
        bm25_top: int = 80,
        rerank_top: int = 40,
        final_k: int = 6,
        hyde_alpha: float = 0.35,  # HyDE mix ratio (0~1)
    ):
        history = history or []

        q = self._rewrite_standalone(query, history)  # multiturn 대응 ([docs.nvidia.com](https://docs.nvidia.com/rag/latest/multiturn.html))

        # HyDE vector mix: v = (1-a)*v(q) + a*v(hyde(q)) ([trec.nist.gov](https://trec.nist.gov/pubs/trec34/papers/UTokyo.rag.pdf))
        q_vec = list(self.embedder.embed([q]))[0]
        hyde_txt = self._hyde(q)
        h_vec = list(self.embedder.embed([hyde_txt]))[0]
        mix_vec = [(1 - hyde_alpha) * a + hyde_alpha * b for a, b in zip(q_vec, h_vec)]

        dense_run = self._dense_search(mix_vec, top_n=dense_top)
        bm25_run = self._bm25_search(q, top_n=bm25_top)

        # hybrid + fusion
        fused = self._rrf_fuse([dense_run, bm25_run])

        # rerank: fused 상위 rerank_top만 cross-encoder로 점수화
        candidates = fused[:rerank_top]
        pairs = [(q, c[2]["text"]) for c in candidates]
        rerank_scores = self.reranker.predict(pairs)

        rescored = []
        for (doc_id, _sc, payload), s in zip(candidates, rerank_scores):
            rescored.append((doc_id, float(s), payload))
        rescored.sort(key=lambda x: x[1], reverse=True)
        top_ctx = rescored[:final_k]

        # 예상 출력(컨텍스트)
        print("=== Retrieved Context (top) ===")
        for i, (doc_id, s, p) in enumerate(top_ctx, 1):
            print(f"{i}. score={s:.4f} id={doc_id} title={p.get('title')}")
        return top_ctx


if __name__ == "__main__":
    # 현실적인 chunk 예시(짧게만)
    chunks = [
        Chunk("1", "Runbook: Kafka consumer lag spikes after deploy... mitigation: scale consumers, check rebalance, ...", {"title": "Kafka Lag Runbook"}),
        Chunk("2", "Design: Request routing uses consistent hashing. Edge cache TTL policy ...", {"title": "Routing Design"}),
        Chunk("3", "Postmortem 2026-02: elevated 5xx due to connection pool exhaustion; fix: tune maxPoolSize ...", {"title": "5xx Postmortem"}),
        # ... 실제로는 수천~수만 chunk
    ]

    rag = AdvancedRAG(qdrant_url="http://localhost:6333")
    rag.index(chunks)

    rag.answer(
        "배포 후 특정 서비스에서 5xx가 늘고 latency도 튀는데, connection pool 관련 점검 포인트가 뭐였지?",
        history=[("어제 배포한 결제 서비스가 불안정해.", "어떤 증상이야?")],
    )

2) 왜 이 구성이 “실무형”인가

rewrite(멀티턴) → hybrid 후보 풀 확대 → rerank로 top-k 정제는 2026년 대회/블루프린트류에서 반복되는 패턴입니다. (docs.nvidia.com)
HyDE는 “올인”이 아니라 mix(α) 로 제어해야 하며, query 타입별 최적이 다를 수 있다는 관찰이 있습니다. (trec.nist.gov)
숫자 정밀 질의에서는 HyDE/multi-query가 제한적일 수 있으니, 이 코드처럼 BM25 채널을 반드시 남겨두는 hybrid가 안전합니다. (arxiv.org)

⚡ 실전 팁 & 함정

Best Practice

1) Reranker는 “정답이 후보에 들어오는가”가 전제

rerank는 recall을 만들지 못합니다. 먼저 hybrid(RRF)나 multi-query로 후보 풀(50~200)을 안정적으로 만들고, rerank는 그 위에 얹으세요. SemEval-2026 파이프라인도 이 순서를 따릅니다. (arxiv.org)

2) HyDE는 숫자/고유명사에 약해질 수 있으니 ‘제약 프롬프트’가 필수

HyDE 텍스트에 구체 수치/날짜를 마구 생성하면 embedding이 “그럴듯한데 틀린 디테일” 쪽으로 끌려가 drift가 납니다.
그래서 예시 코드처럼 “Avoid specific numbers/dates” 같은 제약을 걸고, α를 낮게(예: 0.2~0.4) 시작한 뒤 오프라인 평가로 올리세요. (TREC 시스템도 α를 튜닝 대상으로 둡니다.) (trec.nist.gov)

3) 멀티턴은 history를 retrieval에 넣지 말고, rewrite로 ‘독립 질의’를 만들기

NVIDIA RAG blueprint는 query rewriting이 “best retrieval accuracy”를 주지만 LLM 호출로 latency가 늘어난다고 명시합니다. 즉, 정확도/지연의 교환을 의도적으로 선택해야 합니다. (docs.nvidia.com)

흔한 함정/안티패턴

multi-query를 top-k마다 다 돌려버리기: N개의 질의 × (dense+BM25) × rerank까지 겹치면 비용이 기하급수로 증가합니다. expansion은 “애매한 query에서만” 게이팅하세요.
rerank에 너무 큰 chunk를 그대로 넣기: cross-encoder는 입력 길이에 민감합니다. “문단 단위 chunk + title/section header prepend” 정도가 대체로 안정적입니다.
도메인/언어 미스매치: reranker가 영어 위주 데이터로 학습된 경우 한국어/사내 약어에서 역효과가 날 수 있습니다. (모델/도메인 적합성 검증 없이 rerank on은 금물)

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

성능(정확도) 순 대체로: hybrid + rerank > 단일 dense > 단일 BM25 (단, 금융/표처럼 sparse가 강한 코퍼스는 예외) (arxiv.org)
비용(지연) 순: multi-query/HyDE(LLM 추가 호출) 가 가장 비싸고, 그 다음이 rerank(후보 수에 비례), 그 다음이 1차 retrieval입니다.
안정성은 “게이팅”으로 확보합니다: (a) HyDE는 query 타입별 on/off, (b) rerank는 후보 수 제한, (c) multi-query는 실패 시 원 query fallback.

🚀 마무리

정리하면, 2026년 6월 시점의 RAG 성능 최적화는 “새 임베딩 하나 갈아끼우기”보다 파이프라인을 2~3단으로 구조화하는 쪽이 더 큰 이득을 줍니다.

Recall 문제면: query rewriting / keyword expansion / HyDE / multi-query로 후보 풀을 넓히고
Precision 문제면: cross-encoder reranking으로 top-k를 정제하세요
단, 정밀 숫자 질의는 HyDE·multi-query가 제한적일 수 있으니 BM25/hybrid 채널을 유지하는 게 안전합니다. (arxiv.org)
HyDE는 “항상 on”이 아니라, TREC RAG 2025의 HyDE Vector Mix처럼 α 믹싱/게이팅이 실무적으로 핵심입니다. (trec.nist.gov)

다음 학습 추천(바로 실무로 이어지는 순서): 1) 내 서비스 쿼리를 “대화형/서술형/정밀수치형”으로 분류하고, 타입별로 rewrite/HyDE/multi-query 게이팅 규칙 만들기
2) hybrid(RRF) + rerank의 후보 수(dense_top, bm25_top, rerank_top)를 바꿔가며 Recall@k / MRR / latency를 같이 튜닝하기 (trec.nist.gov)
3) 최종적으로는 “좋은 retrieval이면 generation은 따라온다”가 아니라, retrieval-then-rerank-then-cite까지 포함한 E2E 평가 루프를 붙이기

원하시면, 당신의 코퍼스 특성(문서 길이/언어/표 포함 여부/평균 query 길이/실시간성)과 현재 지연 예산을 기준으로 HyDE α 범위, rerank 후보 수, multi-query 개수를 구체적인 튜닝 플랜으로 내려드릴게요.

AI, RAG

ai rag trend 2026-06