RAG Re-ranking 파이프라인 — Cross-Encoder와 하이브리드 검색으로 정확도 높이기

목차

1. 개요
2. Re-ranking 파이프라인의 핵심 구조
3. 하이브리드 검색 — BM25와 Dense Retrieval 결합
4. Cross-Encoder Re-ranking 구현
5. 성능 비교와 트레이드오프
6. 운영 환경 적용 시 고려사항
7. 맺음말

개요

검색 품질 문제의 본질

RAG(Retrieval-Augmented Generation) 시스템에서 생성 품질은 검색 단계의 결과에 직접 의존합니다. 아무리 뛰어난 언어 모델을 도입하더라도, 관련성이 낮은 문서가 컨텍스트에 포함되면 답변 정확도가 급격히 낮아지고 할루시네이션이 증가합니다. 이 글은 Cross-Encoder Re-ranking과 하이브리드 검색을 결합하여 RAG 파이프라인의 검색 품질을 실질적으로 개선하는 방법을 다룹니다. 두 기법이 왜 보완 관계에 있는지, 어떻게 조합해야 하는지를 구체적으로 살펴봅니다.

검색 관련성 문제는 크게 두 가지 양상으로 나타납니다. 첫째는 의미적으로 유사하지만 실제 답변에 필요한 정보가 아닌 문서가 상위 순위를 차지하는 경우입니다. 벡터 유사도 기반 검색(Dense Retrieval)은 전반적인 의미 유사도를 잘 포착하지만, 질문의 핵심 키워드나 특정 수치·고유명사 등을 놓치기 쉽습니다. 둘째는 키워드 기반 검색(BM25)이 용어 매칭에는 강하지만 동의어나 문맥 의존적 표현을 처리하지 못하는 한계입니다. 이 두 방식의 약점은 서로 보완적이어서, 함께 사용할 때 시너지가 납니다.

RAG 파이프라인에서 하이브리드 검색이 후보 문서를 넓히고, Cross-Encoder Re-ranking이 그 중 관련성 높은 문서만 추려냅니다.

기존 단일 검색 방식의 한계

RAG 시스템의 초기 구현에서 가장 많이 사용된 방식은 단순 벡터 유사도 검색입니다. 질문을 임베딩하고, 문서 임베딩과의 코사인 유사도를 계산해 상위 k개를 반환하는 방식입니다. 이 접근법은 구현이 간단하고 대규모 문서 집합에서도 빠르게 작동하는 장점이 있습니다.

그러나 실제 프로젝트에서 이 방식을 사용해 보면 눈에 띄는 문제가 드러납니다. 특히 도메인 특화 용어가 많은 금융·법률·의료 분야에서 임베딩 모델이 충분히 학습하지 못한 개념이 포함되어 있을 때, 표면적으로 유사해 보이는 문서가 실제로는 전혀 다른 내용을 담고 있는 경우가 자주 발생합니다. Bi-Encoder 기반 임베딩 모델은 질문과 문서를 각각 독립적으로 인코딩하기 때문에, 두 텍스트의 상호작용을 직접 포착하지 못한다는 구조적 한계가 있습니다. 이 한계를 보완하는 것이 바로 Re-ranking 전략의 출발점입니다.

Re-ranking 파이프라인의 핵심 구조

Bi-Encoder와 Cross-Encoder의 구조적 차이

Re-ranking을 이해하려면 먼저 Bi-Encoder와 Cross-Encoder의 작동 방식 차이를 명확히 파악해야 합니다. Bi-Encoder는 질문과 문서를 각각 별도의 인코더로 처리하여 고정 크기의 벡터를 만들고, 두 벡터 간 유사도를 계산합니다. 이 방식은 문서 임베딩을 미리 계산해 두고 인덱싱할 수 있어 대규모 검색에 필수적입니다. 수백만 건의 문서에서 밀리초 단위로 검색이 가능한 이유가 바로 여기에 있습니다.

Cross-Encoder는 이와 전혀 다르게 작동합니다. 질문과 문서를 하나의 입력 시퀀스로 연결하여 트랜스포머 모델에 통째로 넣고, 관련성 점수를 직접 예측합니다. [CLS] 질문 [SEP] 문서 [SEP] 형태로 입력이 구성되며, 모델은 두 텍스트 사이의 세밀한 상호작용(token-level attention)을 충분히 활용해 관련성을 판단합니다. 이 방식은 Bi-Encoder보다 훨씬 높은 정확도를 제공하지만, 모든 (질문, 문서) 쌍에 대해 개별적으로 추론을 실행해야 하므로 속도가 느립니다.

Bi-Encoder는 속도를 위해 상호작용을 포기하고, Cross-Encoder는 정확도를 위해 속도를 포기합니다. Re-ranking은 두 특성을 단계적으로 활용합니다.

Re-ranking이 정확도를 높이는 이유

두 모델의 특성을 계단식으로 활용하는 것이 Re-ranking 전략의 핵심입니다. 첫 번째 단계에서는 속도가 빠른 Bi-Encoder(또는 하이브리드 검색)를 활용해 전체 문서 코퍼스에서 후보 집합을 빠르게 추립니다. 일반적으로 상위 20~100개 정도를 후보로 선택합니다. 두 번째 단계에서는 그 후보들에 대해서만 Cross-Encoder로 정밀하게 관련성 점수를 매기고 재정렬합니다. 최종적으로 LLM에는 상위 3~5개 문서만 전달합니다.

이 접근법이 효과적인 이유는 검색 문제를 두 가지 서로 다른 난이도로 분리하기 때문입니다. "이 문서가 질문과 관련이 있을 가능성이 조금이라도 있는가"라는 느슨한 판단은 Bi-Encoder가 빠르게 처리하고, "이 문서가 질문에 정확히 답하는가"라는 정밀한 판단은 Cross-Encoder가 담당합니다. BEIR 벤치마크 결과를 보면, BM25나 단독 Dense Retrieval 대비 Re-ranking을 추가했을 때 nDCG@10 기준으로 평균 5~15% 향상을 확인할 수 있습니다.

전체 코퍼스를 Cross-Encoder로 직접 순위 매기는 것은 비현실적이며, 이 두 단계 파이프라인이 품질과 속도 사이의 실용적인 균형점입니다.

파이프라인 설계 원칙

Re-ranking 파이프라인을 설계할 때 고려해야 할 핵심 원칙이 있습니다. 첫째, 리콜(Recall)과 프리시전(Precision)의 분리입니다. 1단계 검색은 리콜을 극대화하는 것이 목표입니다. 관련 문서를 빠뜨리지 않는 것이 우선이며, 다소 관련성이 낮은 문서가 포함되더라도 괜찮습니다. 반면 Re-ranking 단계는 프리시전을 높이는 것이 목표입니다. 후보 중에서 진짜 관련성 높은 문서만 선별하면 됩니다.

둘째, 후보 수와 품질의 트레이드오프입니다. 1단계에서 후보를 많이 가져올수록 Cross-Encoder의 부담이 커지고 지연시간이 늘어납니다. 후보를 너무 적게 가져오면 관련 문서를 놓칠 위험이 있습니다. 실제 프로젝트에서는 20~50개 정도가 합리적인 균형점으로 확인됩니다. 셋째, 모델 선택입니다. Cross-Encoder 모델은 태스크 도메인과 언어를 고려해야 합니다. 한국어 RAG 시스템이라면 다국어 또는 한국어 특화 모델을 사용하는 것이 좋습니다. 언어 불일치는 Re-ranking 품질을 크게 저하시키는 가장 흔한 원인입니다.

하이브리드 검색 — BM25와 Dense Retrieval 결합

Sparse 검색과 Dense 검색의 상호보완

BM25는 TF-IDF를 개선한 전통적인 키워드 기반 검색 알고리즘입니다. 문서에 등장하는 단어의 빈도와 역문서빈도를 기반으로 관련성을 계산합니다. 특정 키워드가 질문에 포함되어 있고 그 키워드가 정확히 문서에 있는 경우 BM25는 뛰어난 성능을 보입니다. 고유명사, 제품명, 코드 스니펫, 버전 번호 같은 정확한 용어 매칭이 중요한 경우가 대표적입니다.

반면 Dense Retrieval은 BERT 기반 임베딩 모델을 활용해 텍스트를 고차원 벡터 공간에 매핑합니다. 동의어, 패러프레이즈, 의미적으로 유사한 개념을 함께 처리하는 데 강점이 있습니다. "심근경색"을 "심장마비"로, "자동차"를 "차량"으로 검색해도 적절한 결과를 반환합니다. 하지만 도메인 특화 용어나 임베딩 모델이 사전학습 과정에서 충분히 노출되지 않은 개념에는 취약합니다.

Reciprocal Rank Fusion으로 점수 통합

두 검색 방식의 결과를 통합하는 가장 간단하고 효과적인 방법이 **Reciprocal Rank Fusion(RRF)**입니다. RRF는 각 검색 방식에서 반환된 문서의 순위(rank)만을 사용하여 통합 점수를 계산합니다. 점수의 절대값을 사용하지 않아 서로 다른 스케일의 점수를 정규화하는 작업이 필요 없다는 것이 큰 장점입니다.

RRF 점수는 RRF(d) = Σ 1 / (k + rank_i(d)) 공식으로 계산됩니다. 여기서 k는 일반적으로 60을 사용하며, 낮은 순위의 영향을 완화하는 역할을 합니다. 예를 들어 BM25에서 1위, Dense에서 5위인 문서의 RRF 점수는 1/(60+1) + 1/(60+5) = 0.0164 + 0.0154 = 0.0318이 됩니다. 이 방식은 어느 한 검색 방식에서만 높은 순위를 차지한 문서보다, 두 방식 모두에서 상위권에 있는 문서에 더 높은 점수를 부여합니다.

RRF는 두 검색 결과의 순위만 사용하므로 스케일 정규화 없이도 안정적으로 통합됩니다.

하이브리드 검색 구현 — RRF 코드 예시

아래 코드는 rank_bm25 라이브러리와 sentence-transformers를 활용해 하이브리드 검색을 구현하는 예시입니다. BM25와 Dense 검색 결과를 RRF로 통합하는 핵심 로직에 집중합니다.

from rank_bm25 import BM25Okapi
from sentence_transformers import SentenceTransformer
import numpy as np
from typing import List, Tuple

def reciprocal_rank_fusion(
    ranked_lists: List[List[int]],
    k: int = 60
) -> List[Tuple[int, float]]:
    """여러 순위 목록을 RRF로 통합한다."""
    scores: dict[int, float] = {}
    for ranked in ranked_lists:
        for rank, doc_id in enumerate(ranked):
            scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank + 1)
    # 점수 내림차순 정렬 후 반환
    return sorted(scores.items(), key=lambda x: x[1], reverse=True)

class HybridRetriever:
    def __init__(self, documents: List[str]):
        self.documents = documents
        # BM25: 공백 기반 토크나이징 (한국어는 형태소 분석기 교체 권장)
        tokenized = [doc.split() for doc in documents]
        self.bm25 = BM25Okapi(tokenized)
        # Dense: 다국어 임베딩 모델 (한국어 포함)
        self.encoder = SentenceTransformer("BAAI/bge-m3")
        self.doc_embeddings = self.encoder.encode(documents, normalize_embeddings=True)

    def retrieve(self, query: str, top_k: int = 20) -> List[Tuple[int, float]]:
        # BM25 순위 산출
        bm25_scores = self.bm25.get_scores(query.split())
        bm25_ranked = np.argsort(bm25_scores)[::-1][:top_k].tolist()

        # Dense 순위 산출 (내적 = 코사인 유사도, normalize 적용 시)
        query_emb = self.encoder.encode(query, normalize_embeddings=True)
        dense_scores = self.doc_embeddings @ query_emb
        dense_ranked = np.argsort(dense_scores)[::-1][:top_k].tolist()

        # RRF 통합 → 상위 top_k 반환
        fused = reciprocal_rank_fusion([bm25_ranked, dense_ranked])
        return fused[:top_k]
        # 결과: [(doc_id, rrf_score), ...] 내림차순

normalize_embeddings=True를 설정하면 내적(@)이 코사인 유사도와 동일해져 별도 정규화 없이 계산이 가능합니다. 한국어 문서에는 BM25의 토크나이저를 공백 분리 대신 형태소 분석기(kiwipiepy, konlpy 등)로 교체하는 것이 중요합니다. 형태소 분석 없이 공백만으로 토크나이징하면 어미 변화로 인해 동일 단어가 다른 토큰으로 처리되어 BM25의 매칭 품질이 낮아집니다.

Cross-Encoder Re-ranking 구현

Cross-Encoder 모델 선택 기준

Cross-Encoder 모델 선택은 성능과 지연시간 모두에 영향을 미칩니다. 현재 널리 사용되는 선택지는 다음과 같습니다.

한국어 포함 다국어 RAG 시스템에서는 BAAI/bge-reranker-v2-m3가 현재 가장 좋은 오픈소스 선택지 중 하나입니다. GPU가 없는 환경에서는 경량 모델이 현실적인 대안이 됩니다. Cohere Rerank API 같은 외부 서비스는 별도 모델 관리가 필요 없다는 장점이 있지만, API 호출 비용과 지연시간, 데이터 외부 전송 이슈를 고려해야 합니다.

Cross-Encoder 선택 시 가장 중요한 기준은 대상 도메인과 언어입니다. 일반 도메인 텍스트와 법률·금융·의료 같은 특화 도메인은 성능 차이가 큽니다. 가능하다면 실제 운영 데이터로 소규모 평가를 수행하여 모델 간 비교를 직접 확인하는 것을 권장합니다.

GPU 유무와 언어 요구사항이 Cross-Encoder 모델 선택의 핵심 분기점입니다.

Re-ranking 파이프라인 구현

하이브리드 검색으로 얻은 후보 문서에 Cross-Encoder를 적용하는 전체 파이프라인 코드입니다. 배치 처리와 점수 정렬까지 포함합니다.

from sentence_transformers import CrossEncoder
from typing import List, Tuple

class CrossEncoderReranker:
    def __init__(self, model_name: str = "BAAI/bge-reranker-v2-m3"):
        # Cross-Encoder는 (질문, 문서) 쌍을 받아 관련성 점수를 직접 예측
        self.model = CrossEncoder(model_name, max_length=512)

    def rerank(
        self,
        query: str,
        candidate_docs: List[str],
        top_n: int = 5
    ) -> List[Tuple[int, float, str]]:
        # (질문, 문서) 쌍 구성 — Cross-Encoder 입력 형태
        pairs = [(query, doc) for doc in candidate_docs]
        # 배치 추론: GPU 메모리에 따라 batch_size 조정
        scores = self.model.predict(pairs, batch_size=16, show_progress_bar=False)
        indexed = [(i, float(scores[i]), candidate_docs[i]) for i in range(len(scores))]
        reranked = sorted(indexed, key=lambda x: x[1], reverse=True)
        return reranked[:top_n]
        # 결과 예: [(2, 0.923, "관련 문서 내용..."), (0, 0.871, "..."), ...]

def run_rag_pipeline(query: str, retriever: HybridRetriever, reranker: CrossEncoderReranker):
    # 1단계: 하이브리드 검색으로 후보 20개 수집
    candidates = retriever.retrieve(query, top_k=20)
    candidate_docs = [retriever.documents[doc_id] for doc_id, _ in candidates]
    # 2단계: Cross-Encoder로 상위 5개 재정렬
    reranked = reranker.rerank(query, candidate_docs, top_n=5)
    return [doc for _, _, doc in reranked]

배치 크기(batch_size)는 GPU 메모리와 후보 문서 길이에 따라 조정이 필요합니다. max_length=512는 토큰 기준이므로, 긴 문서는 청킹(chunking) 전략을 통해 적절한 길이로 분할하는 것이 중요합니다. 청크 크기가 너무 작으면 문맥이 손실되고, 너무 크면 Cross-Encoder의 관련성 판단 정확도가 낮아집니다. 일반적으로 256~512 토큰 크기의 청크에 50~100 토큰의 overlap을 두는 방식이 효과적입니다.

청킹 전략과 Re-ranking의 상호작용

문서 청킹 방식은 Re-ranking 성능에 직접 영향을 미칩니다. 청크 단위로 임베딩하고 검색하면 동일 문서의 여러 청크가 후보에 포함될 수 있습니다. 이 경우 Cross-Encoder 이후 LLM에 전달할 컨텍스트를 구성할 때, 동일 문서의 여러 청크를 이어 붙이는 부모 문서 검색(Parent Document Retrieval) 전략을 함께 고려하는 것이 좋습니다. 청크 단위로 관련성을 판단하되, 최종 컨텍스트는 그 청크가 속한 원본 단락을 넓게 포함시키는 방식입니다.

전체 문서 단위로 Re-ranking을 수행하는 방식도 있습니다. 이 경우 Dense Retrieval 단계에서는 청크 임베딩을 활용하고, Re-ranking 단계에서는 청크가 속한 원본 문서의 넓은 컨텍스트를 Cross-Encoder에 제공합니다. 그러나 원본 문서가 길면 Cross-Encoder의 max_length 제한에 걸리므로, 문서를 적절히 요약하거나 관련 청크만 추출해서 제공하는 중간 단계가 필요합니다. 어떤 전략을 선택하든, 청크 경계와 Cross-Encoder 입력 길이의 정합성을 사전에 확인하는 것이 안정적인 파이프라인 구축의 기본입니다.

성능 비교와 트레이드오프

검색 품질 벤치마크 분석

Re-ranking 파이프라인의 효과는 벤치마크 데이터를 통해 정량적으로 확인할 수 있습니다. BEIR(Benchmarking Information Retrieval) 데이터셋은 다양한 도메인에서 검색 성능을 측정하는 표준 벤치마크입니다. 주요 지표는 nDCG@10(Normalized Discounted Cumulative Gain at 10)으로, 상위 10개 결과의 관련성 품질을 0~1 사이 값으로 나타냅니다.

일반적인 결과 패턴을 보면, BM25 단독 대비 Dense Retrieval은 평균 5~10% 향상을 보이며, 하이브리드 검색(BM25 + Dense + RRF)은 추가로 3~7% 개선됩니다. 여기에 Cross-Encoder Re-ranking을 적용하면 단독 BM25 대비 최대 15~25% 향상을 확인할 수 있습니다. 단, 도메인과 질문 유형에 따라 편차가 크므로 실제 서비스에서는 자체 평가 셋 구축이 필수입니다.

각 단계는 이전 방식보다 점진적으로 검색 품질을 높이며, 최종적으로 Re-ranking까지 적용했을 때 가장 높은 정확도를 달성합니다.

지연시간 vs 정확도 트레이드오프

파이프라인 단계가 늘어날수록 지연시간이 증가합니다. 실제 운영 환경에서 측정한 대략적인 수치는 다음과 같습니다.

전체 지연시간의 대부분은 Cross-Encoder 추론에서 발생합니다. GPU가 있는 환경에서는 수백 밀리초 수준이지만, CPU 전용 환경에서는 수 초에 달할 수 있습니다. 실시간 응답이 중요한 서비스라면 이 지연시간을 사전에 반드시 측정하고 수용 가능한 수준인지 확인해야 합니다. 지연시간을 줄이는 주요 전략으로는 후보 수 감소(20→10개), 경량 모델 사용, 모델 양자화(INT8), 비동기 처리 등이 있습니다. 특히 모델 양자화는 품질 손실을 최소화하면서 추론 속도를 2~4배 개선할 수 있어 CPU 환경에서 효과적입니다.

어떤 상황에서 어떤 조합을 선택할 것인가

모든 RAG 시스템에 동일한 파이프라인을 적용할 필요는 없습니다. 서비스 요구사항에 따라 적절한 단계를 선택해야 합니다.

응답 속도 요구사항이 가장 먼저 결정해야 할 제약 조건이며, 그 안에서 정확도 목표를 달성하는 조합을 선택하는 것이 현실적입니다.

문서 도메인이 일반 텍스트(뉴스, 위키피디아 등)라면 Dense Retrieval만으로도 충분한 경우가 많습니다. 반면 도메인 전문 용어가 많거나 정확한 수치·날짜·제품명이 질문에 포함되는 경우라면 하이브리드 검색이 필수적입니다. 정답이 하나인 사실 기반 질의(fact-based QA)에서는 Re-ranking의 효과가 특히 두드러집니다. 반면 창의적 생성이나 요약 태스크에서는 Re-ranking의 추가 효과가 상대적으로 작아지는 경향이 있습니다.

운영 환경 적용 시 고려사항

흔한 실수와 함정

Re-ranking 파이프라인을 처음 도입하는 팀이 자주 겪는 문제를 정리합니다. 첫 번째 함정은 평가 없이 도입하는 것입니다. Re-ranking을 추가하면 무조건 좋아질 것이라고 가정하는 경우가 있습니다. 그러나 Cross-Encoder 모델의 도메인 적합성이 낮은 경우에는 오히려 순위가 나빠질 수 있습니다. 반드시 실제 데이터로 before/after 비교를 수행하고, nDCG, MRR(Mean Reciprocal Rank), Recall@k 같은 검색 지표를 측정해야 합니다.

두 번째 함정은 청크 길이와 Cross-Encoder max_length의 불일치입니다. 문서를 1000 토큰 단위로 청킹했는데 Cross-Encoder의 max_length가 512라면, 문서의 후반부 정보가 잘립니다. 이 경우 Re-ranking이 문서의 앞부분만 보고 판단하기 때문에 정확도가 예상보다 낮게 나올 수 있습니다. 청크 크기를 Cross-Encoder의 처리 가능 길이에 맞추거나, 더 큰 컨텍스트를 지원하는 모델을 사용해야 합니다.

세 번째는 BM25 토크나이저와 언어의 불일치입니다. 한국어의 경우 형태소 분석 없이 공백 기반 토크나이징을 사용하면 "먹었다", "먹는다", "먹어"가 모두 다른 토큰으로 처리됩니다. 형태소 분석기를 적용하면 모두 어간으로 환원되어 BM25의 매칭 품질이 크게 향상됩니다.

평가 지표가 없는 상태로 파이프라인을 변경하면 개선인지 개악인지 알 수 없습니다. 검색 품질 평가 셋을 먼저 구축한 뒤 파이프라인을 변경하는 것이 올바른 순서입니다.

모니터링과 디버깅

프로덕션 RAG 시스템에서 검색 품질을 지속적으로 모니터링하는 것은 매우 중요합니다. 모델과 데이터가 변화함에 따라 검색 성능이 저하될 수 있기 때문입니다.

Re-ranking 점수 분포 모니터링은 파이프라인 이상 징후를 빠르게 감지하는 핵심 수단입니다.

주요 모니터링 지표로는 첫째로 Re-ranking 점수 분포가 있습니다. 1위 문서의 Cross-Encoder 점수가 지속적으로 낮다면(예: 0.5 이하) 질문 유형이 바뀌었거나 문서 코퍼스의 커버리지가 부족한 신호일 수 있습니다. 둘째로 **1위와 2위 문서 간 점수 차이(score gap)**입니다. 이 차이가 크면 검색 결과가 명확히 구분되고 있다는 긍정적 신호입니다. 반면 차이가 매우 작으면 여러 문서가 비슷한 관련성을 가진다는 뜻으로, LLM이 컨텍스트를 혼동할 가능성이 높아집니다. 셋째로 지연시간 p95, p99 모니터링입니다. Cross-Encoder 추론은 후보 문서 길이에 따라 변동이 크므로, 평균값보다 꼬리 분포를 중점적으로 관찰해야 합니다.

확장과 비용 관리

RAG 시스템의 트래픽이 증가할 때 Re-ranking 파이프라인은 병목이 될 가능성이 있습니다. 확장 전략을 미리 고려해야 합니다. 첫 번째 전략은 모델 서빙 계층 분리입니다. Cross-Encoder 추론을 별도의 마이크로서비스(Triton Inference Server, TorchServe 등)로 분리하면 검색 서비스와 독립적으로 스케일 아웃이 가능합니다. 두 번째는 캐싱입니다. 동일한 (질문, 문서) 쌍에 대한 Re-ranking 점수를 캐싱하면 반복 요청에서 추론 비용을 절감할 수 있습니다. 질문 정규화(소문자 변환, 공백 처리 등)를 거친 캐시 키를 사용하는 것이 좋습니다.

세 번째는 비용과 정확도의 균형입니다. Cohere Rerank API 같은 서비스는 요청 단위로 과금되며, 문서 수와 길이에 따라 비용이 달라집니다. 대규모 서비스에서는 API 비용이 상당할 수 있으므로, 자체 호스팅 모델과 API 서비스 사이의 비용 임계점을 계산하는 것이 중요합니다. 월간 수십만 건 이상의 검색 요청이 있다면 자체 호스팅이 경제적으로 유리해지는 경우가 많습니다.

맺음말

핵심 요약

이 글에서 다룬 내용을 정리합니다. RAG Re-ranking 파이프라인은 크게 두 단계로 구성됩니다. 첫 번째는 하이브리드 검색으로, BM25의 키워드 정확성과 Dense Retrieval의 의미적 유연성을 RRF 알고리즘으로 통합하여 1단계 리콜을 극대화합니다. 두 번째는 Cross-Encoder Re-ranking으로, 질문과 후보 문서를 함께 입력하는 구조적 특성을 활용해 관련성을 정밀하게 판단하고 최종 컨텍스트를 정제합니다.

Bi-Encoder는 속도를, Cross-Encoder는 정확도를 담당하는 계단식 설계 덕분에 전체 파이프라인은 대규모 문서 집합에서도 수백 밀리초 안에 고품질 컨텍스트를 제공할 수 있습니다. 여기에 하이브리드 검색이 더해지면 키워드 정확 매칭이 중요한 도메인에서도 안정적인 성능을 유지합니다. 평가 지표 없이 파이프라인을 구성하는 것은 언제나 위험합니다. 자체 평가 셋과 정량 지표를 먼저 갖추는 것이 전체 과정에서 가장 중요한 선행 조건입니다.

적용 판단 기준

Re-ranking 파이프라인을 도입하기에 적합한 상황은 다음 조건 중 하나 이상이 해당될 때입니다. 답변 정확도가 비즈니스에 직접 영향을 미치는 경우 — 고객 지원, 법률 정보 검색, 의료 정보 시스템 등에서는 잘못된 문서가 컨텍스트에 포함될 때의 비용이 크므로 Re-ranking 투자가 정당화됩니다. 도메인 전문 용어가 많은 경우 — 단순 벡터 검색으로는 커버하기 어려운 특화 용어를 BM25와 조합하면 리콜이 크게 향상됩니다. 기존 RAG 시스템의 검색 정확도가 이미 병목인 경우 — LLM을 더 큰 모델로 교체하기 전에 검색 단계 개선을 먼저 시도하는 것이 비용 효율적입니다.

반면 도입을 재고할 상황도 있습니다. 실시간 응답(100ms 이하)이 반드시 필요하고 GPU 인프라가 없는 환경에서는 Cross-Encoder Re-ranking이 현실적이지 않을 수 있습니다. 그 경우 하이브리드 검색만 도입하거나, 비동기 처리(스트리밍 응답)로 체감 지연시간을 줄이는 접근이 대안입니다. 도메인과 질문 유형에 따라 각 기법의 효과가 달라지므로, 자체 평가 데이터를 기반으로 정량적으로 의사결정하는 것이 가장 안전하고 확실한 방법입니다.