RAG 검색 품질 개선: Hybrid Search, Reranking, Query Transformation

RAG의 응답 품질은 검색 품질에 의해 결정됩니다. 아무리 좋은 LLM을 사용해도, 검색 단계에서 관련 문서를 가져오지 못하면 정확한 답변을 생성할 수 없습니다. 이 글에서는 검색 품질을 개선하는 세 가지 핵심 전략을 다룹니다.

핵심 요약

• 순수 벡터 검색(Dense Retrieval)만으로는 키워드 매칭이 필요한 질문에 취약합니다. BM25와 결합한 Hybrid Search로 커버리지를 높일 수 있습니다.
• 검색 결과의 순위를 Cross-encoder로 재정렬하는 Reranking은 적은 비용으로 정밀도를 높이는 효과적인 방법입니다.
• 사용자 질문을 그대로 검색하지 않고, LLM으로 변환하는 Query Transformation은 질문-문서 간 의미 격차를 줄입니다.
• 세 전략은 독립적이지 않으며, Hybrid Search → Reranking → Query Transformation 순으로 조합하면 누적 효과가 큽니다.
• 전략 도입 전에 현재 검색 품질의 baseline을 측정하고, 각 전략 추가 후 개선폭을 확인하는 방식이 실무적입니다.

1. 문제 상황: 왜 벡터 검색만으로는 부족한가

RAG 시스템을 구축하고 사내 문서를 임베딩해서 질문에 답하게 만들었습니다. 그런데 운영을 시작하면 이런 문제가 반복됩니다.

사례 1: 키워드 매칭 실패

• 질문: "ERROR-4032 에러 코드 해결 방법은?"
• 기대: ERROR-4032를 설명하는 문서
• 실제: "에러 처리 일반 가이드"가 반환됨

벡터 검색은 의미적 유사도 기반입니다. "ERROR-4032"라는 구체적인 코드와 의미적으로 유사한 벡터를 찾지만, 해당 코드가 정확히 포함된 문서를 우선하지는 않습니다.

사례 2: 검색 결과 순위 문제

• Top-5 검색 결과 중 정답이 4번째에 있음
• LLM은 1~2번째 결과에 더 가중치를 두어 부정확한 답변 생성

벡터 유사도 점수 차이가 미세한 경우, 실제 관련성이 높은 문서가 순위에서 밀릴 수 있습니다.

사례 3: 질문과 문서의 표현 격차

• 질문: "서버가 느려졌을 때 어떻게 해야 해?"
• 문서: "Latency 증가 시 수평 확장 전략과 캐시 레이어 도입을 검토합니다"
• 의미는 같지만 표현이 달라 유사도가 낮게 측정됨

이 세 가지 문제를 각각 해결하는 전략이 Hybrid Search, Reranking, Query Transformation입니다.

RAG 검색 품질 개선 전략 개요

2. Hybrid Search: BM25와 Dense Retrieval의 결합

2.1 왜 두 가지를 결합하는가

Dense Retrieval(벡터 검색)과 Sparse Retrieval(BM25)은 서로 다른 강점을 가집니다.

특성	Dense Retrieval (벡터 검색)	Sparse Retrieval (BM25)
강점	의미적 유사성, 동의어/패러프레이즈 처리	정확한 키워드 매칭, 희귀 용어 검색
약점	희귀 키워드나 코드에 취약	의미적 연관성을 이해하지 못함
적합한 질문	"환불 정책 알려줘" (문서에는 "반품 절차")	"ERROR-4032 해결 방법" (정확한 코드 매칭)
인덱스	벡터 인덱스 (HNSW, IVF 등)	역인덱스 (Inverted Index)

운영 환경에서 들어오는 질문은 한 가지 유형으로 통일되지 않습니다. 의미 기반 질문과 키워드 기반 질문이 섞여 있으므로, 두 방식을 결합해야 전체 커버리지가 높아집니다.

2.2 Hybrid Search 아키텍처

Hybrid Search 아키텍처

Hybrid Search의 기본 흐름은 다음과 같습니다.

1. 병렬 검색: 동일한 쿼리를 BM25 인덱스와 벡터 인덱스에 각각 전달합니다.
2. 개별 결과 수집: BM25에서 Top-N, 벡터 검색에서 Top-N 결과를 가져옵니다.
3. 결과 융합(Fusion): 두 결과 리스트를 하나로 합칩니다.
4. 최종 Top-K 선택: 융합된 순위에서 상위 K개를 LLM에 전달합니다.

2.3 결과 융합: Reciprocal Rank Fusion (RRF)

두 검색 결과의 점수 스케일이 다르므로(BM25는 0~수십, 코사인 유사도는 0~1), 단순 점수 합산은 효과적이지 않습니다. Reciprocal Rank Fusion(RRF)은 점수 대신 순위만 사용하여 이 문제를 해결합니다.

RRF_score(d) = Σ  1 / (k + rank(r, d))
               r∈R

• d: 문서
• R: 결과 리스트 집합 (BM25 결과, 벡터 검색 결과)
• rank(r, d): 결과 리스트 r에서 문서 d의 순위
• k: 스무딩 상수 (일반적으로 60)

예시: 문서 A가 BM25에서 3위, 벡터에서 7위인 경우

RRF_score(A) = 1/(60+3) + 1/(60+7) = 0.0159 + 0.0149 = 0.0308

RRF의 장점은 점수 보정(calibration)이 불필요하다는 것입니다. BM25 점수와 코사인 유사도의 스케일이 달라도, 순위 기반으로 동작하므로 안정적으로 융합됩니다.

2.4 구현 예시: LangChain + Elasticsearch

from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever
from langchain_community.vectorstores import OpenSearchVectorSearch

# BM25 Retriever 설정
bm25_retriever = BM25Retriever.from_documents(documents)
bm25_retriever.k = 20  # 상위 20개 후보

# Vector Retriever 설정
vector_store = OpenSearchVectorSearch(
    index_name="documents",
    embedding_function=embeddings,
    opensearch_url="https://opensearch-endpoint:443"
)
vector_retriever = vector_store.as_retriever(search_kwargs={"k": 20})

# Hybrid: EnsembleRetriever (RRF 기반 융합)
hybrid_retriever = EnsembleRetriever(
    retrievers=[bm25_retriever, vector_retriever],
    weights=[0.4, 0.6]  # BM25 40%, Vector 60% 가중치
)

results = hybrid_retriever.invoke("ERROR-4032 에러 해결 방법")

2.5 가중치 설정 기준

BM25와 Dense Retrieval 간 가중치는 질문 유형 분포에 따라 조정합니다.

질문 유형 분포	권장 가중치 (BM25 : Vector)	이유
키워드/코드 질문이 많음	0.5 : 0.5 또는 0.6 : 0.4	BM25가 정확 매칭에 강함
의미 기반 질문이 많음	0.3 : 0.7	벡터 검색이 패러프레이즈에 강함
혼합	0.4 : 0.6	일반적인 시작점

운영 중에는 실제 질문 로그를 분석하여 키워드형과 의미형 비율을 측정하고, 가중치를 조정합니다.

2.6 Hybrid Search를 지원하는 벡터 DB

벡터 DB	Hybrid Search 지원 방식	비고
OpenSearch	네이티브 BM25 + kNN 통합	RRF 내장 지원
Elasticsearch	BM25 + dense_vector kNN	RRF 내장 지원 (8.x+)
Weaviate	BM25 + Vector 하이브리드 모드	alpha 파라미터로 가중치 조정
Pinecone	Sparse-Dense 벡터 결합	단일 인덱스에서 하이브리드 지원
pgvector	벡터 검색만 네이티브, BM25는 별도 구현 필요	pg_search 또는 별도 BM25 레이어 필요

3. Reranking: 검색 결과 재정렬

3.1 왜 Reranking이 필요한가

Hybrid Search로 후보를 가져온 후에도, Top-K 내 순위가 최적이 아닐 수 있습니다. 이유는 다음과 같습니다.

• Bi-encoder의 한계: 벡터 검색에 사용되는 Bi-encoder는 질문과 문서를 각각 독립적으로 인코딩합니다. 두 벡터 간 유사도를 계산하므로 속도는 빠르지만, 질문과 문서의 세밀한 상호작용을 포착하지 못합니다.
• Cross-encoder의 강점: 질문과 문서를 하나의 입력으로 결합하여 동시에 처리합니다. 질문의 각 토큰이 문서의 모든 토큰과 상호작용(attention)하므로, 관련성 판단이 훨씬 정밀합니다.

Bi-encoder:   query → [Encoder] → q_vec   }→ cosine(q_vec, d_vec)
              doc   → [Encoder] → d_vec   }

Cross-encoder: [query + doc] → [Encoder] → relevance_score

Cross-encoder는 정확도가 높지만, 모든 문서에 적용하면 속도가 느립니다. 따라서 1단계에서 후보를 좁히고(Retrieval), 2단계에서 소수의 후보만 재정렬하는(Reranking) 2단계 구조가 표준입니다.

Reranking 파이프라인

3.2 2단계 Retrieval-Reranking 파이프라인

[전체 문서 인덱스]
    ↓ 1단계: Retrieval (Hybrid Search)
[Top-50 후보] ← 빠른 검색 (ms 단위)
    ↓ 2단계: Reranking (Cross-encoder)
[Top-5 재정렬] ← 정밀 평가 (수백 ms)
    ↓
[LLM에 전달]

• 1단계 (Retrieval): Hybrid Search로 Top-50 후보를 빠르게 가져옵니다. 여기서는 Recall(관련 문서를 빠뜨리지 않는 것)이 중요합니다.
• 2단계 (Reranking): 50개 후보를 Cross-encoder로 정밀 평가하여 Top-5를 선별합니다. 여기서는 Precision(상위 결과의 정확도)이 중요합니다.

3.3 Reranking 모델 선택지

모델/서비스	컨텍스트 윈도우	특징	비고
Cohere Rerank 4	32,000 토큰	100+ 언어 지원, JSON 구조 데이터 처리 가능	rerank-v4.0 (품질 우선) / rerank-v4.0-fast (속도 우선)
Cohere Rerank 3.5	4,096 토큰	다국어 SOTA, 추론 능력 포함	비용 대비 효율 높음
Cross-encoder/ms-marco-MiniLM	512 토큰	오픈소스, 로컬 실행 가능	영어 중심, 짧은 문서에 적합
BGE-reranker-v2-m3	8,192 토큰	오픈소스, 다국어 지원	로컬 GPU 필요
Jina Reranker v2	8,192 토큰	코드, 다국어 지원	API 또는 로컬 실행

3.4 구현 예시: Cohere Rerank

import cohere

co = cohere.ClientV2()

# 1단계: Hybrid Search로 후보 검색 (위 예시에서 가져온 결과)
candidates = hybrid_retriever.invoke(query)

# 2단계: Reranking
rerank_response = co.rerank(
    model="rerank-v4.0",
    query="ERROR-4032 에러 해결 방법",
    documents=[doc.page_content for doc in candidates],
    top_n=5,  # 상위 5개만 반환
    return_documents=True
)

# 재정렬된 결과
for result in rerank_response.results:
    print(f"Score: {result.relevance_score:.4f}")
    print(f"Content: {result.document.text[:100]}...")

3.5 Reranking 비용-성능 trade-off

Reranking은 후보 수에 비례하여 비용과 지연 시간이 증가합니다.

후보 수	지연 시간 (일반적)	정밀도 향상	비용 영향
10개	50~100ms	소폭 향상	낮음
20~30개	100~200ms	중간 향상	중간
50개	200~400ms	높은 향상	높음
100개 이상	400ms+	추가 향상 미미	높음

운영 환경에서는 후보 수를 20~50개로 설정하는 것이 일반적입니다. 그 이상에서는 비용 대비 품질 향상이 감소합니다.

3.6 Reranking 없이 대안: Lost in the Middle 문제

Reranking을 적용하지 않으면, LLM이 긴 컨텍스트의 중간에 있는 정보를 놓치는 "Lost in the Middle" 현상이 발생할 수 있습니다. 연구에 따르면, LLM은 컨텍스트의 처음과 끝에 있는 정보는 잘 활용하지만, 중간에 있는 정보는 간과하는 경향이 있습니다.

Reranking으로 가장 관련성 높은 문서를 상위에 배치하면, LLM이 핵심 정보를 먼저 읽게 되어 이 문제를 완화할 수 있습니다.

4. Query Transformation: 질문을 검색에 최적화하기

4.1 왜 질문을 변환하는가

사용자 질문은 검색에 최적화된 형태가 아닌 경우가 많습니다.

• 모호한 질문: "이거 어떻게 해?" → 무엇을 어떻게 하는 건지 불명확
• 대화체 질문: "서버가 느려졌는데 왜 그런 거야?" → 문서에는 "Latency 증가 원인"으로 기술
• 복합 질문: "VPC 설계하려는데 서브넷 분리 기준이랑 보안 그룹 설정 방법 알려줘" → 두 가지 주제가 혼합

Query Transformation은 이런 질문을 검색에 더 적합한 형태로 바꾸는 전처리 단계입니다.

Query Transformation 전략 비교

4.2 Multi-Query: 질문을 여러 관점으로 확장

하나의 질문을 여러 버전으로 변환하여 각각 검색한 후 결과를 합칩니다. 하나의 표현으로 검색하면 놓칠 수 있는 관련 문서를 다양한 표현으로 커버합니다.

from langchain.retrievers.multi_query import MultiQueryRetriever
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0.3)

multi_query_retriever = MultiQueryRetriever.from_llm(
    retriever=vector_retriever,
    llm=llm
)

# 원본: "EKS에서 Pod가 외부 통신이 안 되는 이유는?"
# 생성되는 변형:
# 1. "EKS Pod outbound traffic 실패 원인"
# 2. "Kubernetes Pod 인터넷 접근 불가 해결 방법"
# 3. "EKS NAT Gateway VPC 설정 문제"
results = multi_query_retriever.invoke(
    "EKS에서 Pod가 외부 통신이 안 되는 이유는?"
)

장점: 원래 질문으로는 검색되지 않던 관련 문서를 추가로 찾을 수 있습니다. 단점: LLM 호출이 추가되므로 지연 시간과 비용이 증가합니다.

4.3 HyDE: Hypothetical Document Embeddings

질문을 그대로 임베딩하지 않고, LLM이 가상의 답변 문서를 먼저 생성한 뒤 그 문서를 임베딩하여 검색합니다.

일반 RAG:     질문 → 임베딩 → 벡터 검색 → 결과
HyDE:         질문 → LLM(가상 답변 생성) → 가상 답변 임베딩 → 벡터 검색 → 결과

핵심 아이디어는 "질문과 문서의 표현 격차(gap)를 줄이는 것"입니다. 질문 벡터보다 문서와 비슷한 형태의 벡터로 검색하면, 문서 인덱스에서 더 정확한 매칭이 가능합니다.

from langchain.chains import HypotheticalDocumentEmbedder
from langchain_openai import ChatOpenAI, OpenAIEmbeddings

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
base_embeddings = OpenAIEmbeddings(model="text-embedding-3-small")

# HyDE Embedder: LLM으로 가상 문서 생성 후 임베딩
hyde_embeddings = HypotheticalDocumentEmbedder.from_llm(
    llm=llm,
    base_embeddings=base_embeddings,
    prompt_key="web_search"  # 프롬프트 템플릿 유형
)

# "서버가 느려졌을 때 대응 방법" 질문에 대해
# LLM이 먼저 가상의 답변 문서를 생성:
# "서버 응답 시간 증가 시 수평 확장, 캐시 레이어 도입,
#  DB 쿼리 최적화, CDN 적용을 검토합니다..."
# → 이 가상 문서의 임베딩으로 검색

장점: 질문-문서 간 어휘 불일치(vocabulary mismatch) 문제를 효과적으로 해결합니다. 단점: LLM이 생성한 가상 답변이 부정확하면 오히려 검색 품질이 떨어질 수 있습니다. 사실 기반 질문(수치, 코드명 등)에서는 효과가 제한적입니다.

4.4 Query Decomposition: 복합 질문 분해

하나의 복합 질문을 여러 단순 질문으로 분해하여 각각 검색합니다.

from langchain.output_parsers import NumberedListOutputParser
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

decomposition_prompt = """
다음 질문을 2~4개의 단순한 하위 질문으로 분해하세요.
각 하위 질문은 독립적으로 검색할 수 있어야 합니다.

질문: {question}
"""

# 원본: "VPC 설계 시 서브넷 분리 기준과 보안 그룹 설정 방법은?"
# 분해 결과:
# 1. "VPC 서브넷 분리 기준은?"
# 2. "Public/Private 서브넷 설계 패턴은?"
# 3. "보안 그룹 설정 방법과 규칙 설계 기준은?"

적합한 경우: 사용자가 여러 주제를 한 번에 질문하는 패턴이 많은 시스템. FAQ 챗봇보다는 기술 문서 검색, 리서치 보조 도구에 적합합니다.

4.5 Step-back Prompting: 추상화된 질문으로 검색

구체적인 질문을 한 단계 추상화하여 더 넓은 범위의 관련 문서를 찾습니다.

원본 질문:    "EKS 1.28에서 CoreDNS가 CrashLoopBackOff 되는 이유?"
Step-back:   "Kubernetes CoreDNS 장애 원인과 해결 방법"

구체적인 질문으로만 검색하면 해당 버전에 국한된 문서만 찾을 수 있습니다. Step-back으로 범용적인 문서를 함께 검색하면, 배경 지식과 구체적 해결책을 모두 LLM에 제공할 수 있습니다.

4.6 전략별 비교

전략	추가 LLM 호출	지연 시간 증가	효과적인 상황	주의할 점
Multi-Query	1회 (변형 생성)	+200~500ms	다양한 표현의 문서가 있을 때	결과 중복 제거 필요
HyDE	1회 (가상 답변 생성)	+300~800ms	질문-문서 표현 격차가 클 때	사실 기반 질문에는 비효과적
Query Decomposition	1회 (분해)	+200~500ms	복합 질문이 많을 때	단순 질문에는 오버헤드만 증가
Step-back Prompting	1회 (추상화)	+200~500ms	구체적 문제에 배경 지식이 필요할 때	추상화가 너무 넓으면 노이즈 증가

5. 전략 조합: 실무 파이프라인 설계

5.1 권장 파이프라인 구성

세 전략을 조합한 실무 파이프라인의 일반적인 구성입니다.

[사용자 질문]
    ↓ (선택) Query Transformation
[변환된 질문(들)]
    ↓ Hybrid Search (BM25 + Dense)
[Top-50 후보]
    ↓ Reranking (Cross-encoder)
[Top-5 재정렬]
    ↓
[LLM 응답 생성]

5.2 시나리오별 권장 조합

전략 조합 의사결정 흐름

시나리오 1: 사내 기술 문서 검색 (에러 코드 + 개념 질문 혼합)

구성 요소	선택	이유
검색	Hybrid Search (BM25 0.4 : Vector 0.6)	에러 코드는 BM25, 개념 질문은 벡터
Reranking	Cohere Rerank 4	다국어(한국어 문서) 지원, 긴 문서 처리
Query Transformation	Multi-Query	동일 개념의 다양한 표현을 커버

시나리오 2: 고객 지원 FAQ 챗봇 (짧은 질문, 빠른 응답 필요)

구성 요소	선택	이유
검색	Hybrid Search (BM25 0.3 : Vector 0.7)	고객 질문은 대부분 의미 기반
Reranking	Cohere Rerank v4.0-fast 또는 경량 Cross-encoder	지연 시간 최소화
Query Transformation	미적용	FAQ 질문은 보통 단순하고 직접적

시나리오 3: 법률/계약서 분석 시스템 (정확도 최우선)

구성 요소	선택	이유
검색	Hybrid Search (BM25 0.5 : Vector 0.5)	조항 번호 매칭 + 의미 검색 균형
Reranking	Cohere Rerank 4 (Top-50 → Top-5)	정밀도 최우선, 지연 시간 허용
Query Transformation	Query Decomposition + Step-back	복합 법률 질문 분해 + 배경 조항 검색

5.3 점진적 도입 전략

모든 전략을 한 번에 도입하기보다, 단계적으로 추가하며 각 단계의 효과를 측정하는 방식을 권장합니다.

1단계: Dense Retrieval만 (baseline 측정)
   → Recall@10: 65%, Precision@5: 40%

2단계: + BM25 Hybrid Search 추가
   → Recall@10: 80% (+15%), Precision@5: 48% (+8%)

3단계: + Reranking 추가
   → Recall@10: 80% (유지), Precision@5: 68% (+20%)

4단계: + Query Transformation 추가
   → Recall@10: 88% (+8%), Precision@5: 72% (+4%)

각 단계에서 개선이 확인되면 다음 단계로 진행합니다. 특정 전략이 효과가 없으면 해당 단계를 건너뛰거나 다른 방식으로 대체합니다.

6. 비용/운영 고려사항

6.1 전략별 비용 영향

전략	추가 API 호출	지연 시간 영향	인프라 요구사항
Hybrid Search	없음 (인덱스 추가만)	+10~50ms	BM25 인덱스 추가 (Elasticsearch 등)
Reranking	Rerank API 1회/쿼리	+100~400ms	외부 API 또는 GPU 서버
Multi-Query	LLM 1회/쿼리	+200~500ms	LLM API 비용
HyDE	LLM 1회/쿼리	+300~800ms	LLM API 비용

6.2 비용 최적화 방법

• Reranking 후보 수 제한: 50개 이상은 비용 대비 효과가 감소합니다. 20~30개로 시작합니다.
• Query Transformation 조건부 적용: 모든 질문에 HyDE를 적용하면 비용이 2배 증가합니다. 질문 유형을 분류하여 필요한 경우에만 적용합니다.
• 캐시 활용: 동일하거나 유사한 질문에 대한 검색 결과를 캐시하면 반복 비용을 줄일 수 있습니다.
• 경량 Reranker 사용: 실시간 응답이 중요한 경우 Cohere Rerank v4.0-fast나 오픈소스 경량 모델을 선택합니다.

6.3 모니터링 지표

운영 중 검색 품질을 지속적으로 관찰하기 위한 지표입니다.

지표	설명	목표
Retrieval Latency	검색 완료까지 소요 시간 (Reranking 포함)	< 500ms (일반), < 200ms (실시간)
Reranker Score Distribution	Top-K 결과의 relevance score 분포	상위 결과가 0.8+ 유지
Empty Result Rate	검색 결과가 비어 있는 비율	< 5%
User Feedback	사용자가 응답에 만족했는지 (thumbs up/down)	만족도 80%+
Fallback Rate	Query Transformation 후에도 검색 실패하는 비율	< 10%

7. 자주 하는 실수

1. Reranking 없이 Top-K를 바로 LLM에 전달: 벡터 유사도 순위가 실제 관련성 순위와 다를 수 있습니다. 특히 Top-5 내 순서가 중요한 경우 Reranking 없이는 "Lost in the Middle" 문제가 발생합니다.
2. 모든 질문에 HyDE 적용: 사실 기반 질문(코드, 수치, 이름 검색)에 HyDE를 적용하면 LLM이 잘못된 가상 답변을 생성하여 오히려 검색 품질이 떨어집니다.
3. BM25 인덱스를 관리하지 않음: 벡터 인덱스만 업데이트하고 BM25 인덱스 동기화를 놓치면, Hybrid Search에서 오래된 BM25 결과가 반환됩니다.
4. Reranking 후보를 너무 적게 설정: Top-5만 가져와서 Reranking하면, 원래 6위에 있던 정답 문서를 놓칩니다. Recall을 확보하려면 1단계에서 충분한 후보(20~50개)를 가져와야 합니다.
5. 전략 효과를 측정하지 않음: 각 전략이 실제로 검색 품질을 개선하는지 A/B 테스트 없이 도입하면, 비용만 증가하고 품질은 개선되지 않을 수 있습니다.
6. RRF의 k값을 조정하지 않음: RRF의 스무딩 상수 k(기본 60)는 순위 상위 문서에 얼마나 가중치를 줄지를 결정합니다. 도메인에 따라 k값을 실험해볼 필요가 있습니다.

8. 정리

• Hybrid Search는 키워드 매칭과 의미 검색을 결합하여 단일 방식의 맹점을 보완합니다. RRF로 점수 보정 없이 안정적으로 융합할 수 있습니다.
• Reranking은 Cross-encoder로 검색 결과의 순위를 정밀하게 재조정합니다. 비용 대비 정밀도 향상 효과가 가장 큰 전략입니다.
• Query Transformation은 사용자 질문과 문서 간 표현 격차를 줄여 Recall을 높입니다. 다만 모든 질문에 적용할 필요는 없으며, 질문 유형에 따라 선택적으로 적용합니다.
• 세 전략의 도입 순서는 일반적으로 Hybrid Search → Reranking → Query Transformation입니다. 각 단계에서 효과를 측정하고, 비용 대비 개선이 확인되면 다음 단계로 진행합니다.
• 측정 없는 최적화는 불가능합니다. Baseline을 먼저 측정하고, 각 전략 추가 후 Retrieval Precision/Recall 변화를 추적하는 체계가 가장 먼저 필요합니다.

참고 문서

• LangChain 공식 문서: Retrievers
• Cohere 공식 문서: Rerank
• Pinecone 공식 문서: Hybrid Search
• OpenSearch 공식 문서: Hybrid Search
• RAGAS 공식 문서: RAG Evaluation