개념
리랭킹(reranking)은 검색으로 뽑아 낸 후보 문서들을 다시 한 번 정밀하게 채점해 순서를 매기는 단계다. RAG 파이프라인은 보통 두 단계로 구성된다. 먼저 벡터 데이터베이스에서 유사도 기준으로 수십 개의 후보를 빠르게 건져 올리고, 그다음 리랭커가 그 후보들만 정밀 검토해 상위 몇 개를 남긴다.
굳이 두 단계로 나누는 이유는 속도와 정확도가 서로 다른 방향을 요구하기 때문이다. 1차 검색은 임베딩 벡터를 미리 계산해 두고 거리만 재기 때문에 수백만 건을 훑어도 빠르지만, 질문과 문서를 각각 따로 벡터로 압축한 뒤 비교하는 방식이라 미묘한 차이를 놓치기 쉽다. 반면 리랭커는 질문과 문서를 한 쌍으로 묶어 함께 읽고 관련도를 점수로 내놓는다. 후보마다 매번 계산해야 해서 훨씬 느리지만 판단은 정확하다. 그래서 넓게 건지는 일은 1차 검색에, 정밀하게 고르는 일은 리랭커에 맡긴다.
리랭커로는 질문과 문서를 한 쌍으로 입력받는 전용 모델을 쓰기도 하고, LLM에게 후보들을 보여 주고 관련도 순으로 정렬하게 시키기도 한다. 1차 검색이 쓰는 방식을 바이 인코더, 리랭커가 쓰는 방식을 크로스 인코더라 부르기도 하는데, 이 이름은 질문과 문서를 따로 인코딩하는가 한데 묶어 인코딩하는가의 차이에서 왔다.
쓰임새
1차 검색만으로 상위 3개를 뽑으면 정작 필요한 문단이 8등쯤에 밀려 있는 경우가 흔하다. 리랭킹은 이때 후보를 넉넉히 받아 놓고 그중 진짜 상위를 다시 고르는 식으로 쓰인다. 검색은 되는 것 같은데 답변이 엉뚱하다는 증상을 겪는 시스템에서, 비교적 적은 작업으로 체감 품질을 끌어올릴 수 있는 지점이다.
키워드 검색과 벡터 검색을 함께 돌리는 하이브리드 구성에서는 성격이 다른 두 결과를 하나의 순위로 합쳐야 하는데, 이 병합 단계에서도 리랭커가 공통 기준 역할을 한다. 다만 후보 수만큼 추가 연산이 붙으므로, 응답 시간 요구사항과 토큰 비용을 함께 따져 후보 개수를 정해야 한다.
도입할지 판단할 때는 1차 검색 결과를 사람이 직접 훑어보는 편이 빠르다. 정답 문단이 후보 안에는 들어 있는데 상위 몇 개에 들지 못하고 있다면, 리랭킹이 정확히 그 간극을 메운다. 반대로 후보 어디에도 정답이 없다면 리랭커를 붙여도 달라지는 것이 없다. 두 경우는 고쳐야 할 곳이 전혀 다르므로 순서를 지켜 확인하는 편이 낫다.
자주 하는 오해
리랭커를 붙이면 검색 자체가 좋아지나?
리랭커는 1차 검색이 건져 온 후보 안에서만 순서를 바꾼다. 정답 문단이 애초에 후보에 없었다면 순위를 아무리 잘 매겨도 나오지 않는다. 이 경우 손볼 곳은 청킹이나 1차 검색 쪽이다.
임베딩 모델을 더 좋은 것으로 바꾸면 리랭킹은 필요 없지 않나?
두 방식은 질문과 문서를 비교하는 구조 자체가 다르다. 임베딩 품질이 올라가도 한 쌍으로 놓고 정밀 비교하는 데서 오는 이득은 남는다.
리랭커에 후보를 많이 넣을수록 좋은 것 아닌가?
후보 수에 비례해 지연 시간과 비용이 늘어난다. 어느 지점부터는 상위 순위가 거의 바뀌지 않으므로, 후보 수를 늘려 가며 결과가 더 이상 변하지 않는 지점을 실제 데이터로 찾는 편이 낫다.