rag에서 벡터 검색은 의미가 비슷한 문서를 넓게 찾는 후보 생성기다. 하지만 최종 답변에 넣을 문서는 질문에 가장 직접 답하는 조각이어야 한다. 리랭킹(reranking)은 상위 후보만 더 정교한 모델로 다시 읽어 이 간극을 줄이는 두 번째 단계다.
두 단계로 나누는 이유
질문 → 키워드·벡터·하이브리드 검색(후보 20~100개)
→ 리랭커(질문-문서 쌍 재평가)
→ 상위 3~10개를 LLM 컨텍스트로 전달첫 단계는 재현율(recall)이 목표다. 비슷한 의미, 정확한 제품명, 오류 코드 중 하나라도 맞는 후보를 빠뜨리지 않아야 한다. 두 번째 단계는 정밀도(precision)가 목표다. cross-encoder처럼 질문과 문서를 함께 읽는 모델은 비용이 더 들지만 후보 수가 작으므로 실용적이다.
적용 순서
- 기준선으로 벡터 검색과 BM25를 RRF 같은 방식으로 합쳐 후보를 넓힌다.
- 후보 수를 먼저 정한다. 너무 적으면 정답이 없어지고, 너무 많으면 지연·비용이 늘어난다.
- 리랭커 점수 상위 문서만 컨텍스트에 넣는다. 점수 임계값 아래면 “근거 부족”으로 보류하는 정책도 둔다.
- 인용한 청크 ID, 1차 점수, 리랭킹 점수, 최종 순위를 요청 로그에 남긴다.
Azure AI Search의 의미 순위기는 1차 검색 결과 상위 50개를 재정렬하는 cross-encoder 계열이다. 제품마다 후보 수와 모델은 다르므로 50을 고정값으로 삼기보다, 실제 정답 세트에서 top_k와 지연을 함께 최적화해야 한다.
실패를 피하는 기준
- 후보에 정답이 없다: 리랭커 문제가 아니다. 청킹, 메타데이터 필터, 임베딩, BM25를 먼저 점검한다.
- 정답이 있는데 순위가 낮다: 질문 재작성, 하이브리드 검색, 도메인 리랭커를 시험한다.
- 점수는 높은데 답이 틀린다: LLM이 근거를 잘못 사용한 문제이므로 프롬프트·인용 검증을 점검한다.
리랭킹은 생성 모델을 더 큰 것으로 교체하기 전에 시도할 수 있는 비용 효율적인 품질 개선이다. 단, 검색 품질과 답변 품질을 같은 지표로 섞지 말고 각각 평가해야 원인을 빠르게 찾을 수 있다.
관련 문서
- rag — 검색 증강 생성 파이프라인과 리랭커의 위치
- rag-tutorial-hybrid-search-python — BM25·임베딩 검색 결과를 RRF로 합치는 구현
- rag-tips-production — 리랭킹 점수를 포함한 검색 추적 설계
참고 자료
- Vector search finds candidates; reranking decides what your RAG app reads — Microsoft Developer Community Blog (2026-08-13)