RAG reranking, 왜 쓰고 어떻게 실험할까

세 줄 요약

무슨 변화/핵심이슈인가? RAG 검색 파이프라인에서 1차 검색(top‑K) 뒤에 reranking을 붙여 상위 결과 순서를 다시 정하는 방식이 자주 쓰인다.
왜 중요한가? reranking은 Recall@K를 직접 올리지 못하고 top-K 내부에서만 작동하므로, 도입 자체보다 비용·지연 대비 NDCG@10 개선폭을 측정하는 실험 설계가 핵심이다.
독자는 뭘 하면 되나? K(예: 100) → rerank → N(예: 3–10) 구조를 고정해 비교 실험을 만들고, 오프라인 지표와 실패 케이스로 효과를 확인한다.

검색이 “맞는 듯한” 문서를 가져왔는데 답이 계속 틀리면, 원인은 종종 상위 몇 개 결과의 순서에 있다. LLM은 컨텍스트 창에 들어온 내용만 근거로 삼는 경향이 있다. 그래서 1차 검색이 정답 후보를 포함하더라도(top‑K 안에 있어도) 상위로 올라오지 않으면, RAG는 그럴듯하지만 틀린 답을 낼 수 있다.

예: 한 팀이 사내 문서 검색을 붙인 챗봇을 운영한다. 검색 결과는 관련 있어 보이지만, 답변은 반복해서 엇나간다. 사용자는 상단에 뜬 문서가 왜 선택됐는지 설명을 요구한다.

핵심 이슈는 단순하다. reranking(재순위화) 은 1차 검색기가 뽑은 후보를 더 강한 모델로 다시 채점해, “정답에 가까운 것”을 상단으로 올리는 방식이다. retrieve‑and‑rerank 패턴이 쓰이는 이유도 여기에 있다. 다만 비용이 든다. reranking은 정확도를 올릴 수 있는 대신, 지연시간과 비용을 추가한다. 따라서 “도입” 자체보다 “어디에, 얼마나, 어떤 조건으로” 붙일지가 더 중요하다.

현황

retrieve‑and‑rerank는 두 단계로 움직인다. 먼저 1차 검색이 비교적 가벼운 방식(예: bi‑encoder)으로 후보 K개(예: K=100) 를 빠르게 모은다. 이후 reranker가 후보를 다시 점수화해 순서를 바꾼다. ReFIT 논문은 이를 “초기 검색이 후보를 가져오고, 더 강력하지만 비용이 큰 cross‑encoder가 재순위화한다”는 흐름으로 설명한다.

RAG에서 reranking의 효용은 결국 “LLM에 무엇을 넣는가”로 정리된다. NVIDIA 기술 블로그는 RAG 시스템이 보통 상위 N개 청크(일반적으로 3–10) 를 LLM 컨텍스트로 보낸다고 적는다. N을 늘리면 정답이 포함될 가능성이 커질 수 있지만, 비용과 지연시간도 같이 커진다. reranking은 여기서 ‘N을 늘려서 맞히기’ 가 아니라 ‘같은 N에서 더 나은 청크를 고르기’ 로 초점을 바꾼다.

제약도 분명하다. reranking은 1차 검색이 가져온 top‑K 내부에서만 순서를 바꾼다. 따라서 Recall@K를 직접 올리지는 못한다(정답이 K 바깥이면 reranking이 할 수 있는 일이 없다). reranking을 먼저 붙이기 전에, “정답이 K 안에 들어오는가”를 확인할 필요가 있다.

분석

reranking이 효과를 내기 쉬운 경우는 “후보에는 있는데 답이 틀리는” 상황이다. 1차 검색이 정답 후보를 포함했지만, 상단에 덜 관련된 문서가 올라가 LLM 입력이 흐려지는 케이스다. reranker는 질문‑문서 쌍 (q,d)을 더 직접적으로 비교하는 방식(대표적으로 cross‑encoder 계열)으로 관련도를 다시 평가해 상단 precision을 올리는 것을 노린다. 그 결과 NDCG@10 같은 랭킹 품질 지표가 개선될 수 있다. 같은 정확도를 목표로 하면서도 LLM에 넘기는 top‑N을 3–10 같은 범위에서 더 작게 유지하려는 설계도 가능해진다.

실전 적용

reranking은 “단계”와 “조건”을 분리해 적용하는 편이 안전하다. 한 가지 기본형은 다음 흐름이다. 1차 검색에서 K를 넓게 가져와 후보 포함(예: K=100)을 확보하고, reranker로 상단을 정리한 뒤, LLM에는 작은 N(예: 3–10) 만 보낸다. 이후 K, N, reranking on/off를 바꿔가며 지연시간과 품질의 균형을 측정한다. 이때 “reranking은 top‑K 안에서만 작동한다”는 제약을 설계와 평가에 그대로 반영해야 한다.

예: 어떤 내부 지식 검색에서 질문은 짧고 문서는 길다. 1차 검색은 키워드가 겹치는 문서를 상단에 올리지만, 실제 답은 다른 문서의 한 단락에 있다. K를 늘리면 정답 단락이 후보에 들어오지만, N을 늘리면 LLM이 불필요한 단락까지 읽어 혼선이 생긴다. reranking은 후보 안에서 정답 단락을 상단으로 올려, 작은 N에서도 답을 맞히는 방향을 노린다.

오늘 바로 할 일:

오프라인 평가 셋을 준비하고, 1차 검색과 reranking을 NDCG@10 및 정답률로 함께 비교한다.
파이프라인을 K(예: 100) → rerank → N(예: 3–10) 으로 고정한 뒤, K·N·rerank on/off를 A/B로 돌려 지연시간과 비용을 기록한다.
실패 케이스를 “정답이 K 밖(리콜)”과 “정답이 K 안인데 순서 문제(정밀도)”로 구분해, reranking이 필요한 구간을 분리한다.

FAQ

Q1. reranking은 1차 검색을 완전히 대체하나?
A. 보통은 아니다. reranking은 1차 검색이 뽑아온 후보(top‑K)를 재정렬한다. 일반적으로 1차 검색이 후보를 빠르게 모으고, reranking이 상단 결과를 다듬는 역할을 나눠 가진다.

Q2. reranking을 쓰면 Recall@K도 올라가나?
A. 원칙적으로 reranking은 top‑K 내부 순서만 바꾸므로 Recall@K 자체를 직접 올리기 어렵다. 정답이 K 밖이면 reranker가 개입할 수 없다. 먼저 “정답이 후보에 들어오는가”를 확인해야 한다.

Q3. 지연시간/비용은 어떻게 관리하나?
A. 핵심은 rerank 대상 후보 수 K 를 관리하는 것이다. cross‑encoder는 (q,d) 단위 추론이 필요해 K에 따라 비용이 커진다. 연구에서는 쿼리‑타임 프루닝처럼 연산량을 줄이는 접근도 제안되지만, 운영 환경에서 캐시 전략이 유효한지는 별도 검증이 필요하다.

결론

reranking은 RAG에서 “검색은 했는데 답이 엇나가는” 문제를 상단 결과 품질 문제로 좁혀 다루는 도구다. 다만 top‑K 안에서만 작동하고 비용을 늘릴 수 있으므로, 지표(NDCG@10 등)와 평가 셋을 먼저 두고 K→rerank→N 구조로 실험해야 효과를 판단할 수 있다. “성능이 올랐다”는 서술보다, 어떤 쿼리에서 K/N이 얼마일 때 좋아졌는지를 남기는 편이 운영과 개선에 도움이 된다.

Aionda

RAG reranking, 왜 쓰고 어떻게 실험할까

세 줄 요약

현황

분석

실전 적용

FAQ

결론

다음으로 읽기

참고 자료

업데이트 받기