리랭커란? RAG 검색 결과를 다시 정렬해도 못 고치는 오류

펼친 카드 가운데를 비추는 돋보기. 이해를 돕기 위한 AI 생성 개념 이미지입니다.

RAG 답변이 틀렸다고 모델부터 바꿀 필요는 없습니다. 검색 결과 안에 정답 문서가 있는데 뒤로 밀린 것인지, 애초에 후보에 없는 것인지 먼저 구분해야 합니다. 리랭커는 주로 앞의 문제를 다룹니다.

정답 문서가 후보에 있는지 먼저 보고, 들어 있는데 순위만 낮을 때 리랭커를 검토하세요.

처음에는 넓게 찾고, 다음에는 함께 읽습니다

Sentence Transformers의 Retrieve & Re-Rank 문서는 검색기로 후보를 모은 뒤 Cross-Encoder로 질문과 후보 문서의 관련성을 다시 평가하는 흐름을 설명합니다.

임베딩 검색에서는 보통 문서 벡터를 미리 만들고 질문 벡터와 가까운 것을 찾습니다. Cross-Encoder는 질문과 문서를 한 쌍으로 함께 읽습니다. 후보별로 다시 계산해야 하므로 모든 문서를 처음부터 이 방식으로 훑기보다, 줄여 놓은 후보를 정렬하는 데 사용합니다.

개념적인 호출은 다음과 같습니다. 모델 이름과 점수는 예시이며, 운영에서는 1차 검색 결과의 ID와 원문을 함께 보존해야 합니다.

from sentence_transformers import CrossEncoder

model = CrossEncoder("RERANKER_MODEL")
pairs = [(query, doc_text) for doc_text in candidates]
scores = model.predict(pairs)
reranked = sorted(
    zip(scores, candidates),
    key=lambda item: item[0],
    reverse=True,
)

이 모델은 query-document 쌍을 평가할 뿐, 인덱스에 없거나 1차 검색에서 잘린 문서를 되살리지는 않습니다. 모델별 점수 범위와 의미도 다르므로 서로 다른 리랭커의 점수를 확률이나 공통 척도로 바로 비교하지 않습니다.

후보 50개 중 18위라면 할 일이 있습니다

가상의 검색 로그를 보겠습니다. “충전 표시등이 꺼졌을 때 확인할 것”이라는 질문에 정답 설명서가 후보 50개 중 18위로 들어왔고, 답변 모델에는 상위 5개만 전달됩니다.

이 경우 정답은 검색 단계에서 발견됐지만 최종 문맥에 들어가지 못했습니다. 리랭커가 그 문서를 위로 올릴 수 있는지 검토할 이유가 있습니다. 다만 실제로 올리는지는 평가해야 하며, 이름에 rerank가 있다고 보장되지는 않습니다.

반대로 후보 50개 어디에도 정답이 없으면 그 후보만 정렬하는 리랭커는 정답을 새로 찾아올 수 없습니다. 문서 추출 누락, 잘못된 청크 분할, 필터, 임베딩 검색 실패부터 확인할 차례입니다. 50과 5는 이 사례를 위한 가상 값이지 권장 고정 설정이 아닙니다.

두 번의 검사를 별도로 남깁니다

첫 번째는 후보 포함 검사입니다. 질문별 정답 문서가 초기 후보에 들어왔는지 셉니다. 두 번째는 최종 순위 검사입니다. 포함된 정답이 답변에 전달할 범위까지 올라왔는지 봅니다.

CrossEncoder 평가 도구 설명처럼 정답·비정답 문서가 연결된 질문 묶음을 준비할 수 있습니다. 이 도구는 예를 들어 MRR@k, NDCG@k, MAP으로 재정렬 전후 순위를 비교합니다. 평가 이름보다 데이터 구성에 주의해야 합니다. 실제로는 후보에 없던 정답을 평가할 때만 끼워 넣으면, 운영 검색 전체가 좋아진 것처럼 오해하기 쉽습니다.

평가기가 모든 positive 문서를 후보에 강제로 포함하는 설정을 제공하더라도, 그것은 리랭커의 상한이나 순수 재정렬 능력을 보는 별도 실험입니다. 실제 1차 검색을 그대로 평가하려면 정답이 후보에 없을 수 있는 목록을 사용하고, 두 결과를 섞어 보고하지 않습니다.

점수가 높아도 문서 사용 조건은 따로 봅니다

관련성이 높다는 이유로 오래된 정책이 최신 정책보다 먼저 전달되거나, 권한 밖 자료가 들어오면 안 됩니다. 리랭커 점수는 접근 허가도 사실 보증도 아닙니다.

또한 원문이 길면 입력 길이 제한으로 필요한 문장이 잘릴 수 있습니다. 질문 언어와 문서 언어가 다른 경우에도 실제 조합으로 확인해야 합니다. 모델이 제공하는 점수 범위를 확률처럼 읽는 것도 피하세요. 모델과 출력 변환에 따라 의미가 달라집니다.

먼저 로그 한 건으로 실패 단계를 분류합니다

관찰	리랭커 후보인가	먼저 볼 것
정답이 초기 후보에 없음	아니오	추출·청크·필터·검색 모델
정답이 후보에 있으나 최종 k 밖	예	리랭커와 최종 k
정답이 최종 문맥에 있으나 답이 틀림	직접 원인 아님	생성 프롬프트·인용·답변 검증
오래된 문서가 정답보다 앞섬	조건부	최신성 필터와 버전 정책 우선
권한 밖 문서가 후보에 있음	아니오	접근 제어를 후보 생성부터 수정

이 분류 없이 “RAG 품질이 낮다”는 이유만으로 리랭커를 붙이면 계산 단계만 늘어날 수 있습니다. 특히 생성 모델이 문맥의 정답을 무시한 경우 검색 순서를 바꿔도 같은 실패가 남습니다.

파이프라인에서 후보와 최종 문맥을 분리합니다

질문
  → 1차 검색 top-50
  → 질문·후보 쌍을 Cross-Encoder로 평가
  → 재정렬 top-5
  → 권한·버전·중복 검사
  → 답변 모델에 전달

50과 5는 설명용입니다. 후보 수를 늘리면 정답 포함 가능성은 커질 수 있지만 리랭커 계산량과 지연도 늘어납니다. 너무 긴 문서는 질문과 함께 넣을 때 중요한 부분이 잘릴 수 있으므로 청크 크기와 최대 입력 길이도 함께 확인해야 합니다.

운영 로그에는 질문, 초기 순위, 재정렬 점수와 순위, 최종 전달 여부를 남깁니다. 점수만 남기면 모델을 바꿨을 때 범위가 달라 비교하기 어렵습니다. 정답 문서의 순위 변화와 최종 포함 여부가 더 직접적인 관찰입니다.

평가에서 정답을 몰래 후보에 넣지 않습니다

리랭커 자체를 평가하려고 정답과 어려운 오답을 직접 구성할 수 있습니다. 그러나 검색 파이프라인 전체의 품질을 말할 때는 실제 1차 검색 결과를 사용해야 합니다. 검색이 놓친 정답을 평가 데이터에서만 후보에 추가하면 리랭커는 좋아 보이지만 운영 답변은 고쳐지지 않습니다.

질문별로 다음 값을 나눠 기록합니다.

• 초기 후보 안에 정답이 있었는가.
• 초기 순위는 몇 위였는가.
• 재정렬 뒤 몇 위가 됐는가.
• 최종 문맥에 포함됐는가.
• 답변이 해당 근거를 사용했는가.
• 잘못된 문서가 상위로 올라온 경우가 있는가.
• 추가 지연과 계산 비용은 얼마였는가.

한국어 질문과 한국어 문서, 한국어 질문과 영문 문서처럼 실제 조합도 따로 봅니다. 평균 점수 하나로 제품 코드, 날짜, 부정 표현, 동의어 질문의 실패를 가리지 않습니다.

관련성 점수 바깥의 규칙

리랭커는 질문과 문서가 얼마나 관련돼 보이는지 평가합니다. 문서가 최신인지, 사용자가 읽을 권한이 있는지, 법적·업무적으로 사용할 수 있는지는 별도 규칙입니다. 권한과 유효 기간으로 먼저 금지 문서를 제거하고, 허용 후보 안에서 관련성을 정렬하는 구조가 필요합니다. 후보를 정렬한 뒤 권한 문서를 숨기는 것만으로는 리랭커 입력, 로그, 생성 모델 문맥에 이미 들어간 노출을 되돌릴 수 없습니다.

같은 내용을 가진 중복 청크 다섯 개가 상위 결과를 차지하면 답변 문맥이 좁아집니다. 문서 단위 다양성이나 중복 제거도 최종 전달 단계에서 확인할 수 있습니다. 리랭커 점수가 높다는 이유로 같은 출처만 반복 전달하지 않습니다.

리랭커를 붙이지 않는 선택도 가능합니다

검색기가 이미 필요한 문서를 앞에 두고 있고 지연이 민감하다면 추가 계산의 이득이 작을 수 있습니다. 후보 개수와 최종 전달 개수를 바꾸면서 정확도뿐 아니라 응답 시간을 함께 기록해야 합니다.

2026년 9월 7일 확인한 문서를 바탕으로 쓴 구조 설명입니다. 특정 한국어 리랭커의 우열이나 개선율은 측정하지 않았습니다. 먼저 실패 질문 한 개에서 후보 목록과 최종 문맥을 나란히 열어보면, 무엇을 고칠지 훨씬 좁혀집니다.