Reranker는 Vector DB 검색 뒤에서 후보 문서의 순서를 다시 매기는 단계입니다. Vector DB가 의미적으로 가까운 문서를 빠르게 찾는다면, reranker는 그 후보 중 지금 질문에 더 직접적으로 답하는 문서를 앞으로 올립니다.
RAG 검색 품질이 흔들릴 때 핵심은 검색 후보를 모으는 문제와 후보의 순서를 고르는 문제를 분리하는 것입니다. 둘을 같은 문제로 보면 embedding 모델만 계속 바꾸게 됩니다.
Reranker가 필요한 문제
Vector DB 검색 결과가 항상 나쁜 것은 아닙니다. 문제는 top-k 안에 답이 될 문서가 들어와도, 그 문서가 앞쪽에 놓이지 않거나 비슷한 문서에 밀려 context에서 빠지는 경우입니다.
- 주제는 비슷하지만 질문에 직접 답하지 않는 문서가 앞에 온다
- 같은 주제의 중복 문서가 context를 차지한다
- 정확한 API 이름이나 오류 메시지가 의미 검색에서 약해진다
- top-k 값을 키우면 recall은 늘지만 비용과 noise도 늘어난다
Vector DB 검색과 Reranker의 역할 차이
Vector DB 검색은 대량 문서에서 후보를 빠르게 좁히는 1차 필터입니다. 보통 embedding 벡터 사이의 거리나 유사도를 기준으로 후보를 가져옵니다. 이 단계는 빠르지만, 질문과 문서의 세부 관계를 깊게 읽지는 않습니다.
Reranker는 이미 추려진 후보를 더 자세히 비교합니다. 많은 reranker는 query와 document를 함께 넣고 관련성을 다시 계산하는 방식으로 쓰입니다. 그래서 전체 문서에 바로 쓰기보다, Vector DB가 가져온 후보 20~100개 정도를 다시 정렬하는 식이 일반적입니다.
1. user question
"MissingGreenlet은 왜 response_model에서 터질까?"
2. Vector DB search
top 50 후보 문서 검색
3. Reranker
질문과 문서를 함께 보고 관련성 재점수화
4. Context packing
상위 5개 근거만 답변 context에 포함Reranker가 해결하지 못하는 문제
Reranker는 후보의 순서를 바꾸는 도구입니다. 그래서 1차 검색 후보 안에 정답 근거가 아예 없다면 reranker를 붙여도 해결되지 않습니다.
- 문서가 index에 들어가지 않은 문제
- chunk가 너무 잘게 잘려 근거가 깨진 문제
- metadata filter가 필요한 문서를 제외한 문제
- 질문 언어와 문서 언어가 달라 embedding이 약해진 문제
이런 경우에는 reranker보다 indexing, chunking, metadata 설계, hybrid search를 먼저 봐야 합니다.
top-k를 키우는 것과 무엇이 다를까
top-k를 키우면 좋은 문서가 후보 안에 들어올 확률은 올라갑니다. 하지만 그대로 LLM context에 많이 넣으면 비용이 늘고, 관련 없는 근거가 답변을 흐릴 수 있습니다.
reranker는 top-k를 넓게 가져온 뒤 실제로 넣을 문서를 줄이는 데 유용합니다. 예를 들어 1차 검색은 top 50으로 넓게 가져오고, reranker 이후 상위 5개만 context에 넣는 방식입니다.
실무에서 보는 판단 순서
- 검색 로그에서 질문과 top-k 문서를 함께 저장한다
- 정답 근거가 top-k 안에 있는지 확인한다
- 근거는 있는데 순서가 낮으면 reranker를 검토한다
- 근거가 없으면 chunking, embedding, filter부터 고친다
- reranker 도입 후 지연시간과 비용을 함께 측정한다
비용과 지연시간 tradeoff
reranker는 품질을 올릴 수 있지만 무료가 아닙니다. 후보 문서 수가 많을수록 재점수화 비용과 지연시간이 늘어납니다. 그래서 모든 요청에 무조건 붙이기보다, 검색 난도가 높은 요청이나 중요한 답변 경로에 먼저 적용하는 편이 안전합니다.
candidates = vector_db.search(query, top_k=50)
reranked = reranker.rank(query=query, documents=candidates)
context = reranked[:5]
# 후보를 많이 가져오되, LLM에는 적은 근거만 넣는다.
answer = llm.generate(question=query, context=context)Reranker 도입 체크리스트
- 검색 후보 안에 정답 근거가 들어오는가
- 상위 문서의 순서가 실제 관련성과 어긋나는가
- 동일 문서 중복이 context를 낭비하는가
- reranker 비용과 지연시간을 감당할 수 있는가
- 평가셋으로 도입 전후를 비교할 수 있는가
정리
Reranker는 Vector DB를 대체하지 않습니다. Vector DB가 넓게 후보를 찾고, reranker가 그 후보를 질문 기준으로 다시 정렬합니다.
RAG 검색 품질이 나쁠 때는 먼저 후보 안에 정답 근거가 있는지 확인해야 합니다. 근거는 있는데 순서가 좋지 않다면, 그때 reranker가 가장 현실적인 개선책이 될 수 있습니다.
관련해서 RAG chunk size 선택 기준도 함께 보면 검색 후보가 왜 처음부터 흔들리는지 이해하기 쉽습니다. 외부 기준은 Pinecone rerank 문서를 참고할 수 있습니다.
