RAG 재정렬의 성능은 후보 목록에서 시작된다

검색 결과를 재정렬하는 모델을 붙여도 처음부터 빠진 근거가 돌아오지는 않는다. Sentence Transformers의 공식 문서와 예제를 바탕으로 후보 회수, 순위 개선, 답변 검증을 나누어 RAG를 점검하는 방법을 살펴본다.

GPT Image 2로 생성한 개념 이미지.

사내 장비를 외부 행사에 빌려 가는 방법을 물었는데, AI가 내부 회의실 예약 안내를 가져온다고 하자. 팀은 검색 결과를 더 꼼꼼하게 읽는 재정렬 모델을 붙인다. 답변에 붙는 문서는 한결 그럴듯해졌지만, 외부 반출에 필요한 승인 절차는 여전히 빠져 있다.

이것은 검색 파이프라인을 설명하기 위한 가상의 사례다. 실제 서비스에서 측정한 결과가 아니다. 이때 먼저 확인할 것은 재정렬 모델의 크기가 아니라 그 모델이 받은 후보 목록이다. 필요한 절차 문서가 처음 검색에서 빠졌다면, 후보의 순서만 바꾸는 단계가 그 문서를 새로 찾아오지는 않는다.

RAG에 재정렬을 넣는 일은 읽기 순서를 한 번 더 판단하는 일이다. 이 판단을 활용하려면 넓게 후보를 모으는 단계, 후보를 비교하는 단계, 답에 필요한 근거를 확인하는 단계의 역할을 나누어야 한다. 그래야 더 좋은 모델을 붙였다는 설명을 실제 업무의 개선과 연결할 수 있다.

먼저 모으고, 그다음 함께 읽는다

Sentence Transformers의 공식 Retrieve & Re-Rank 안내는 먼저 검색기로 후보를 회수하고, 이어 Cross-Encoder로 후보의 관련도를 평가하는 구성을 설명한다.[1] 첫 단계에는 어휘 검색이나 임베딩 기반 검색을 사용할 수 있다. 여기서 재정렬은 하나의 검색 방식을 모두 대체하는 기능이 아니라, 먼저 얻은 결과를 다시 비교하는 단계다.

임베딩 검색에 쓰는 Bi-Encoder는 질의와 문서를 각각 표현한다. 문서 표현을 준비해 두고 새 질의의 표현과 비교할 수 있다는 점이 많은 문서를 다루는 데 유리하다. Cross-Encoder는 질의와 문서를 한 쌍으로 함께 입력받아 점수를 계산한다. 공식 안내는 두 입력 사이의 상호작용을 살피는 이 구조와, 많은 쌍을 일일이 계산할 때 드는 비용을 함께 설명한다.[1][2]

이를 단순히 “앞 모델은 대충 읽고 뒤 모델은 정확히 읽는다”로 이해하면 곤란하다. 어떤 데이터와 언어에서 학습했는지, 질의와 문서가 얼마나 긴지, 업무가 무엇을 관련 있다고 보는지에 따라 결과가 달라진다. 공식 문서의 방식 설명은 특정 조직의 검색 품질을 보증하는 실험 결과가 아니다.

문서 안에서 찾을 단락이 적다면 모든 단락을 바로 비교할 수도 있다. 공식 저장소의 in_document_search_crossencoder.py는 문서를 구간으로 나누고, 각 질의와 모든 구간을 짝지어 model.predict에 전달한 뒤 점수 내림차순으로 정렬한다.[3] 이는 후보를 넓게 찾는 별도 검색 단계가 언제나 필수라는 뜻은 아니라는 점을 보여 준다. 다만 비교 대상이 많아지면 매 질의마다 계산할 쌍도 늘어난다.

큰 문서 집합에서 두 단계를 나누는 이유는 이 계산을 어디에 쓸지 정하기 위해서다. 검색기는 전체 집합에서 후보를 좁히고, 재정렬기는 그 후보를 대상으로 더 많은 비교 계산을 수행한다. 어느 단계가 잘못됐는지 따로 볼 수 있어야 이 분업을 조정할 수 있다.

후보에 없는 근거는 순위에서도 찾을 수 없다

가상의 장비 대여 질문으로 돌아가 보자. 외부 반출 절차가 후보에 있었는데 아래쪽으로 밀렸다면 재정렬을 개선할 여지가 있다. 반대로 후보 목록 어디에도 없다면 먼저 검색 질의, 문서 수집 상태, 청크 구성, 후보 개수 등을 조사해야 한다. 두 실패를 모두 “RAG가 답을 못했다”로 기록하면 다음 수정도 막연해진다.

단순한 계산 예를 들어 보자. 질문마다 정답으로 인정할 근거 문서가 하나씩 있는 질문 10개를 준비했다고 하자. 처음 검색한 후보에 그 근거가 들어온 질문이 7개라면, 같은 후보를 재정렬하는 단계가 정답 근거를 맨 위에 올릴 수 있는 질문도 최대 7개다. 나머지 질문의 후보를 새로 가져오지 않는다는 조건에서 성립하는 예다. 실제 측정치도, 모든 RAG 답변 정확도의 상한을 뜻하는 공식도 아니다.

실무에서는 근거가 한 문서에만 있지 않을 수 있다. 일반 규칙과 예외 조항을 함께 읽어야 한다면, 둘 중 하나를 회수한 것만으로 질문을 해결했다고 셀 수 없다. 평가 자료에는 필요한 문서뿐 아니라 필요한 근거 묶음도 표시하는 편이 좋다. 단일 문서의 순위가 올라가도 예외 조항이 잘려 나가면 답은 여전히 불완전하다.

다음 표는 필자가 제안하는 단계별 점검표다. 라이브러리가 자동으로 만들어 주는 평가표는 아니다.

재정렬기 자체를 비교할 때는 먼저 같은 질문과 같은 후보를 사용해야 차이를 해석하기 쉽다. 후보 회수 방식까지 동시에 바꾸면 새 모델이 잘한 것인지, 더 좋은 문서가 처음부터 들어온 것인지 구분하기 어렵다. 그다음 실제 검색 단계와 결합한 전체 파이프라인을 평가하면 두 개선을 함께 볼 수 있다.

후보가 잘 들어온 질문만 골라 재정렬 품질을 측정하는 것도 쓸모는 있다. 다만 그 결과는 후보가 있다는 조건에서의 성능이다. 전체 질문 중 후보가 빠진 비율과 함께 제시해야 업무 전체의 성공률처럼 읽히지 않는다.

높은 관련도 점수가 답의 자격을 대신하지는 않는다

재정렬 점수는 질의와 후보 사이의 관련도를 판단하는 신호다. 이것을 문서가 최신이라는 보증이나 문장 하나가 참일 확률로 바꾸어 읽을 근거는 없다. 점수의 정의와 출력 처리는 사용하는 모델과 설정에서 확인해야 하며, 숫자가 보기 좋은 범위에 들어간다는 이유만으로 확률처럼 해석해서는 안 된다.

가령 장비 반출과 같은 단어가 반복되는 오래된 안내문이 높은 순위에 올라도, 지금 적용할 규정인지는 별도의 질문이다. 문서의 적용 대상과 유효 상태, 근거의 출처는 관련도와 함께 확인해야 한다. 이는 재정렬의 결함을 지적하려는 것이 아니라 관련도 모델에 맡긴 책임의 범위를 정하는 일이다.

기존 글에서 다룬 RRF는 여러 검색 결과의 순위를 결합하는 방법이다. Cross-Encoder 재정렬은 질의와 후보 내용을 함께 입력해 다시 점수를 계산한다. 두 단계는 함께 사용할 수 있지만, 순위를 합친 값과 모델이 낸 값을 같은 의미의 신뢰도로 취급하면 안 된다. 후보 결합에서 무엇을 남겼고 재정렬에서 무엇이 바뀌었는지를 따로 기록하는 편이 낫다.

후보 수와 최종 제공 개수도 구분해야 한다. 넓게 모은 후보를 모두 답변 모델에 전달할 필요는 없다. 반대로 최종 답변에 넣을 문서가 적다는 이유로 처음부터 후보를 지나치게 좁히면, 재정렬기가 비교할 기회도 줄어든다. 후보 깊이를 바꿨을 때 근거 회수와 처리 시간이 함께 어떻게 변하는지 확인해야 한다.

길이 역시 입력의 일부다. 문서 전체를 넘겼다고 생각했어도 선택한 모델과 전처리에서 어디까지 읽었는지는 실제 입력으로 확인할 문제다. 질문에 필요한 예외가 뒷부분에 있다면 그 구간이 점수 계산에 들어갔는지 먼저 본다. 긴 원문을 적절히 나누는 일과 짧게 잘린 텍스트의 점수를 해석하는 일은 분리할 수 없다.

작은 업무 비교로 도입 효과를 확인한다

재정렬을 처음 붙이는 팀이라면 실제로 자주 받는 질문과 오답 사례를 함께 모을 수 있다. 장비 이름이 정확히 나온 질문, 줄임말을 쓴 질문, 일반 절차와 예외를 함께 묻는 질문은 서로 다른 실패를 드러낸다. 아래의 순서는 이 글의 적용 제안이며 특정 제품의 검증 결과가 아니다.

먼저 현재 검색 결과를 기준선으로 저장한다. 질문, 문서 버전, 회수한 후보, 후보의 기존 순위를 남긴다. 재정렬을 적용한 뒤에는 같은 후보의 순위와 최종 선택 결과를 비교한다. 실제 답변에 필요한 조건이 보존됐는지 사람이 확인할 수 있어야 한다. 관련 있어 보이는 제목이 위로 올라왔다는 관찰만으로 도입 효과를 확정하지 않는다.

그다음 후보 수를 바꾸며 회수율과 지연의 변화를 살핀다. 평균 처리 시간만 보면 동시 요청이 몰릴 때 늦어지는 경험을 놓칠 수 있다. 질문과 문서 길이가 다른 사례를 포함하고, 서비스가 허용하는 응답 시간 안에서 어떤 설정이 근거를 더 안정적으로 가져오는지 비교한다. 이 글은 특정 모델의 속도나 적정 후보 수를 측정하지 않았다.

한국어 업무라면 한국어 질문과 문서로 평가해야 한다. 영문 예제에서 잘 작동하는 모델을 불러오는 데 성공했다는 사실과 조직의 약어, 상품명, 예외 표현을 잘 구분한다는 사실은 다르다. 설치 성공은 실행 경로를 확인하고, 업무 평가는 맡길 수 있는 일을 확인한다.

마지막으로 근거가 없는 질문도 남겨 두어야 한다. 모든 질문에 반드시 상위 문서가 나오더라도 그 문서로 답할 수 있다는 뜻은 아니다. 문서 부족을 드러내고 답변을 보류하는 흐름까지 포함해야 검색 개선이 그럴듯한 오답을 더 빠르게 만드는 일로 끝나지 않는다.

재정렬의 가치는 후보 목록의 순서를 바꾼 뒤 업무에 필요한 근거가 더 잘 보이는지에서 확인할 수 있다. 그 효과를 판단하려면 먼저 어떤 후보를 건넸는지 알아야 한다. 좋은 재정렬 모델을 고르는 일과 좋은 후보를 공급하는 일은 함께 설계할 때 비로소 같은 답변을 돕는다.

---

[1] Sentence Transformers, Retrieve & Re-Rank. 2026년 11월 2일 확인. 기본 브랜치 main의 관측 커밋 7bfaf1ccb3dcacd613aeec668e9f0921991e366a에 있는 문서 원본도 대조했다. 문서의 예시 개수나 성능 설명을 이 업무의 측정값으로 사용하지 않았다.

[2] Sentence Transformers, Cross-Encoders. 질의·문서 쌍 입력과 독립 임베딩 방식의 차이, 많은 쌍을 비교하는 비용에 관한 설명. 문서의 특정 출력 범위나 과거 속도 예시를 모든 모델의 공통 보장으로 확대하지 않았다.

[3] Hugging Face sentence-transformers, 문서 내부 검색 예제. 같은 커밋의 실제 파일에서 질의·구간 쌍 구성과 점수 내림차순 정렬을 확인했다. 이 회차에서 예제를 실행하거나 모델을 벤치마크하지는 않았다.

함께 읽기: 검색 점수는 더할 수 없지만 순위는 합칠 수 있다 · 관련 문서를 찾았는데도 RAG가 답하면 안 되는 이유