리랭킹 (Reranking)

리랭킹(Reranking)은 1차 검색이 뽑아 온 후보 문서들을 더 정교한 모델로 다시 채점해 순서를 바꾸는 단계입니다. 검색을 한 번 더 하는 것이 아니라, 이미 좁혀진 후보 안에서 '이 질문에 정말 답이 되는 문서'를 위로 올리는 작업입니다. RAG 파이프라인에서 답변 품질을 가장 적은 노력으로 끌어올리는 구간으로 꼽힙니다.

왜 한 번 더 채점하는가

벡터 검색은 질문과 문서를 각각 따로 임베딩한 뒤 벡터 거리만 비교합니다. 이런 구조를 바이 인코더(bi-encoder)라고 부릅니다. 문서를 미리 벡터로 만들어 두면 되니 수백만 건도 순식간에 훑을 수 있지만, 질문과 문서가 서로를 보지 못한 채 각자 압축되기 때문에 미묘한 관련성을 놓칩니다. '환불이 가능한가'와 '환불이 불가능한 경우'는 벡터 공간에서 아주 가깝게 놓입니다.

리랭커는 크로스 인코더(cross-encoder) 방식을 씁니다. 질문과 문서를 하나의 입력으로 붙여 모델에 함께 넣고 관련도 점수를 하나 뽑습니다. 두 텍스트가 모델 안에서 서로를 참조하면서 계산되기 때문에 훨씬 정확합니다. 대신 문서 하나마다 모델을 한 번씩 돌려야 해서 전체 문서에 적용하는 것은 불가능합니다. 이 비용 구조가 2단계 파이프라인이 생긴 이유입니다.

2단계 검색의 형태

실제 구성은 대체로 이렇습니다. 먼저 하이브리드 검색이나 벡터 검색으로 후보 50~100개를 넓게 가져옵니다. 여기서는 정확도보다 정답 문서를 후보에 반드시 포함시키는 재현율이 목표입니다. 그다음 리랭커가 이 후보만 다시 채점해 상위 3~5개를 남깁니다. 넓게 훑는 단계와 정밀하게 고르는 단계를 분리해 속도와 정확도를 동시에 챙기는 구조입니다.

이 단계가 주는 효과는 답변 품질만이 아닙니다. LLM에 넘기는 문서 수가 줄면 컨텍스트 윈도우에 여유가 생기고 토큰 비용과 응답 지연이 함께 내려갑니다. 관련 없는 문서가 프롬프트에 섞여 들어가 모델을 헷갈리게 만드는 일도 줄어 할루시네이션 위험이 낮아집니다. 문서를 많이 넣을수록 좋을 것 같지만 실제로는 반대인 경우가 많습니다.

후보를 몇 개 넘길지는 생각보다 중요한 결정입니다. 후보가 너무 적으면 정답 문서가 애초에 들어오지 않아 리랭커가 손쓸 방법이 없고, 너무 많으면 계산 시간이 그대로 사용자 대기 시간이 됩니다. 리랭커가 아무리 좋아도 1차 검색이 놓친 문서를 되살릴 수는 없기 때문에, 리랭킹 도입 전에 1차 검색의 재현율부터 확인하는 순서가 맞습니다.

무엇으로 구현하는지

선택지는 세 갈래입니다. 첫째, Cohere Rerank처럼 API로 제공되는 상용 리랭커입니다. 붙이기 쉽고 다국어 지원이 잘 되어 있어 시작점으로 무난합니다. 둘째, BGE-reranker 계열처럼 가중치가 공개된 모델을 직접 띄우는 방식입니다. 데이터를 밖으로 내보내지 않아도 되고 호출량이 많을수록 비용에서 유리합니다. 셋째, 범용 LLM에게 후보 목록을 주고 순위를 매기게 하는 방식입니다. 별도 모델 없이 시작할 수 있지만 느리고 비쌉니다.

도입 효과를 확인하려면 리랭커를 켠 경우와 끈 경우를 같은 질문 세트로 비교해야 합니다. 검색 단계의 지표로는 정답 문서가 상위 k개 안에 들어왔는지를 보는 Recall@k와, 몇 번째에 들어왔는지를 함께 반영하는 NDCG를 씁니다. 최종 답변 품질까지 보려면 모델 평가 관점의 지표를 따로 두어야 합니다.

한국어 문서를 다룬다면 리랭커의 언어 지원을 먼저 확인해야 합니다. 영어 데이터로만 학습한 리랭커는 한국어 질문에서 오히려 순위를 흐트러뜨리기도 합니다. 다국어를 지원한다고 표기된 모델이라도 도메인 용어가 많은 문서에서는 체감 성능이 갈리므로, 실제 사내 문서 100건 정도로 짧게 비교해 보고 고르는 편이 확실합니다.

주의할 점은 지연입니다. 후보를 100개씩 넘기면 리랭커 한 번에 수백 밀리초가 더 붙습니다. 대화형 서비스라면 후보 수를 줄이거나, 짧은 질문에는 리랭킹을 건너뛰는 식으로 조건을 나누는 편이 낫습니다. 리랭킹은 항상 켜 두는 기능이라기보다, 검색 품질이 부족하다는 근거가 있을 때 비용과 지연을 내주고 사는 옵션에 가깝습니다.