RAG의 검색 단계를 설계할 때, "벡터 검색(Vector Search)만으로 충분하다"고 생각하기 쉽지만, 고유명사나 제품 코드와 같이 키워드 일치가 중요한 쿼리에서는 놓치는 부분이 발생한다.

반면, 키워드 검색만으로는 유의어(Paraphrasing)에 취약하다. **하이브리드 검색(Hybrid Search)**과 **리랭킹(Reranking)**은 이 간극을 메우는 전형적인 2단계 구성이다.

이 기사에서는 초보자를 위해 구조, 활용 시점, 설계의 핵심 포인트를 정리한다.

벡터 검색은 "의미의 유사성"으로 문서를 찾는다. 자연어 질문에는 강한 반면, 다음과 같은 약점이 있다.

이 두 가지 약점을 서로 보완하는 것이 하이브리드 검색이다.

하이브리드 검색(hybrid search)은 여러 검색 방식의 점수를 조합하여 최종적인 후보 리스트를 만드는 기법의 총칭이다.

전형적으로 다음 두 가지를 병용한다.

[벡터 검색] 쿼리 임베딩 → 코사인 유사도(Cosine Similarity)로 Top-N
↓ 점수 융합
[키워드 검색] BM25 / 전문 검색으로 Top-N
...

BM25(Best Matching 25)는 전문 검색에서 가장 널리 사용되는 랭킹 함수 중 하나다. 단어의 출현 빈도와 문서 길이를 고려하여 "쿼리의 단어가 얼마나 매치되는가"로 점수를 매긴다.

RRF 계산식(개념):

RRF_score(d) = Σ 1 / (k + rank_i(d))

rank_i(d)는 검색 방식 $i$에서의 문서 $d$의 순위이며, k는 상수(많은 구현에서 60)이다. Weaviate, Elasticsearch, Pinecone 등이 RRF 또는 그와 동등한 융합을 지원한다.

리랭킹(reranking)은 제1단계 검색에서 얻은 후보 리스트를 더 정밀한 모델로 다시 정렬하는 처리다.

[제1단계: 고속·거친 검색]
하이브리드 검색으로 Top-50〜100을 취득 (속도 우선)
[제2단계: 정밀·느린 리랭킹]
...

임베딩 모델 (Bi-Encoder)은 쿼리(Query)와 문서(Document)를 각각 별도로 벡터화하기 때문에 빠르지만, 양자 사이의 상호작용을 직접적으로 볼 수 없다. 크로스 엔코더 (Cross-Encoder)는 쿼리와 문서를 동시에 입력하여 관련도를 직접 예측하기 때문에 정밀도가 높지만, 모든 데이터에 적용하면 너무 느리다.

따라서 "먼저 넓게 후보를 뽑고, 상위 후보만 정밀하게 다시 정렬한다"는 설계가 된다.

[Bi-Encoder (제1단계)]
query → embed(query) ─┐
├─ cosine similarity → 스코어
...

대표적인 오픈 소스 리랭킹 (Reranking) 모델:

BEIR 등의 정보 검색 벤치마크에서는 벡터 검색에 리랭킹을 추가하면 nDCG@10이 5~15포인트 정도 개선되는 사례가 보고되고 있다 (데이터셋 및 모델에 따라 변동). 절대적인 수치가 아니라 "제1단계만 사용했을 때보다 순위 정밀도가 높아지는 경향이 있다"로 이해하면 된다.

실무에서 자주 보이는 구성을 도식화한다.

[인덱스 구축]
문서
→ 청크 (Chunk) 분할
...

다음은 sentence-transformers의 CrossEncoder를 사용한 최소 예제다. 실무에서는 벡터 DB의 하이브리드 API를 사용하는 것이 더 일반적이다.

from sentence_transformers import CrossEncoder
# 제1단계에서 얻은 후보 (하이브리드 검색 결과라고 가정)
query = "PostgreSQL 에서 벡터 검색 인덱스를 만드는 방법"
...

출력 이미지:

0.892 pgvector 에서는 HNSW 인덱스를 CREATE INDEX로 생성할 수 있다.
0.756 HNSW는 근사 최근접 이웃 (ANN) 탐색 알고리즘으로, pgvector가 지원한다.
0.124 MySQL의 전문 검색 (Full-text search) 인덱스 설정 절차에 대해 설명한다.

"MySQL"은 키워드 측면에서 "인덱스"로 매칭되지만, 리랭커는 쿼리의 의도 (PostgreSQL + 벡터)를 고려하여 올바른 문서를 상위에 배치한다.

자체 구현할 경우에는 후보 ID의 중복 제거 (벡터와 BM25에서 동일한 청크가 모두 히트하는 경우)를 잊지 말고 수행해야 한다.

제1단계와 제2단계에서 동일한 청크 ID를 키로 사용하여 후보를 관리하고 있는가 -
하이브리드 융합 방식 (RRF 또는 가중치 합산)과 $\alpha$ 값을 설정 파일에 명시했는가 -
제1단계 추출 수 (50100)와 리랭킹 후 채택 수 (35)를 레이턴시 목표로부터 역산했는가 -
리랭커 스코어에 **임계값 (Threshold)**을 설정하여, 모든 점수가 이를 밑돌 경우 "관련 정보 없음" 플로우로 처리하는가 -
테스트 쿼리 20개로 벡터 단독 vs 하이브리드 vs 하이브리드+리랭킹의 Recall@K를 비교했는가 -
리랭커 모델의 레이턴시 (후보 50개 기준 몇 ms인지)를 측정하여 SLA 내에 들어오는지 확인했는가 -

패턴 1: 하이브리드로 전환했으나 융합 파라미터를 고정한 채 유지

데이터의 성격(FAQ vs API 레퍼런스)에 따라 최적의 $\alpha$가 달라짐에도 불구하고, 0.5로 고정한 채 운영한다.

→ 대책: 분기마다 평가 세트(Evaluation Set)를 통해 $\alpha$를 재튜닝(Re-tuning)한다. 데이터 추가 시에도 재평가한다.

패턴 2: 리랭킹(Rerank)의 후보 수가 너무 적어 정답이 1단계에서 탈락

top_10만 가져오는데, 정답 청크(Chunk)가 11위 이하에 있는 경우.

→ 대책: 1단계는 top_50 이상으로 설정한다. 리랭킹은 '좁히는' 처리이지 '넓히는' 처리가 아니다.

패턴 3: 리랭커(Reranker)를 전수 조사에 적용하여 레이턴시(Latency) 폭발

10만 건의 인덱스 전부에 크로스 엔코더(Cross-Encoder)를 적용한다.

→ 대책: 반드시 1단계에서 후보를 좁힌 후 리랭킹을 수행한다. 전수 리랭킹은 현실적이지 않다.

패턴 4: BM25와 벡터 검색의 청크 분할 방식이 다름

전문 인덱스(Full-text Index)와 벡터 DB의 청크 경계가 어긋나, 융합(Fusion) 시 동일 문서의 파편이 서로 다른 ID가 되는 경우.

→ 대책: 청크 분할은 한 곳에서 수행하고, 동일한 ID로 양쪽 인덱스에 모두 등록한다.

**하이브리드 검색 (Hybrid Search)**은 벡터(의미)와 키워드(단어의 일치)를 결합하여 검색 누락을 줄인다. -
**리랭킹 (Reranking)**은 1단계의 후보를 정밀 모델로 재정렬하여, LLM에 전달하는 청크의 질을 높인다. -
전형적인 구성은 "하이브리드로 top 50 $\rightarrow$ 리랭킹으로 top 5 $\rightarrow$ LLM"이다.

RRF는 스코어 융합(Score Fusion)의 무난한 기본값(Default)이다. $\alpha$는 데이터에 따라 평가를 통해 조정한다.

벡터 검색의 기초(코사인 유사도, ANN)를 이해한 상태에서 이 2단계 구조를 추가하면, RAG의 검색 품질은 한 단계 격상된다.

• Weaviate — Hybrid search
• Elasticsearch — Reciprocal rank fusion
• Pinecone — Hybrid search
• Cohere — Rerank
• Sentence Transformers — Cross-Encoders
• BAAI/bge-reranker-v2-m3 — Hugging Face
• BEIR Benchmark