리랭커
리랭커(Reranker)는 1차 검색이 가져온 후보 문서들을 쿼리와 함께 다시 평가해 관련도가 높은 순서로 재정렬하는 2차 정밀 정렬 단계입니다. 주로 크로스엔코더(cross-encoder)를 사용해 쿼리와 문서를 한 번에 입력받아 정밀한 관련도 점수를 매깁니다.
- 리랭커는 1차 검색(임베딩·BM25 등)이 가져온 상위 후보를 쿼리와 함께 다시 평가해 관련도 순으로 재정렬하는 2차 단계입니다.
- 핵심 기술은 크로스엔코더로, 쿼리와 문서를 하나의 입력으로 함께 트랜스포머에 통과시켜 정밀한 관련도 점수를 산출합니다.
- 바이엔코더(임베딩)는 빠르지만 문서를 단일 벡터로 압축하며 정보가 손실되고, 크로스엔코더는 느리지만 훨씬 정확합니다.
- 크로스엔코더는 후보 1건마다 트랜스포머 추론을 실행해야 해서 전체 코퍼스에 직접 적용하기는 비용·지연이 큽니다.
- 그래서 "빠른 검색으로 넓게 후보를 모으고(리콜) → 리랭커로 좁혀 정밀 정렬한다(정밀도)"는 2단계 검색이 표준 패턴입니다.
리랭커란 무엇인가
리랭커(Reranker)는 검색이나 RAG(검색 증강 생성) 파이프라인에서 1차 검색이 반환한 후보 문서들을 쿼리와 함께 다시 평가해 관련도가 높은 순서로 재정렬하는 2차 정밀 정렬 단계입니다. 1차 검색은 보통 임베딩 기반 벡터 검색이나 BM25 같은 키워드 검색으로 수백 개의 후보를 빠르게 가져옵니다. 리랭커는 이 후보 중 상위 일부만 골라 쿼리와의 실제 관련도를 정밀하게 다시 채점하고, 그 점수로 순위를 다시 매깁니다.
리랭커의 핵심 기술은 크로스엔코더(cross-encoder)입니다. Pinecone의 설명에 따르면 리랭커는 "쿼리와 문서 쌍이 주어지면 유사도 점수를 출력"하며, 임베딩 모델이 쿼리와 문서를 따로 처리하는 것과 달리 둘을 함께 분석합니다. Elastic 문서도 크로스엔코더가 "쿼리와 문서 텍스트를 하나의 연결된 입력으로 받아 쿼리를 인식하는 문서 표현을 생성"한다고 설명합니다.
바이엔코더(임베딩) vs 크로스엔코더(리랭커)
리랭커를 이해하려면 1차 검색에 쓰이는 바이엔코더(bi-encoder)와의 차이를 알아야 합니다. 두 방식의 근본적 차이는 "쿼리와 문서를 따로 인코딩하느냐, 함께 인코딩하느냐"에 있습니다.
| 구분 | 바이엔코더 (임베딩) | 크로스엔코더 (리랭커) |
|---|---|---|
| 입력 방식 | 쿼리와 문서를 따로 인코딩 | 쿼리와 문서를 하나로 합쳐 함께 인코딩 |
| 출력 | 재사용 가능한 임베딩 벡터 | 쿼리-문서 쌍의 관련도 점수(0~1) |
| 쿼리 인식 | 문서 임베딩이 쿼리를 모름(사전 계산) | 쿼리 문맥에 맞춰 문서를 평가 |
| 속도 | 빠름(코사인 유사도 비교만) | 느림(후보마다 트랜스포머 추론) |
| 정확도 | 상대적으로 낮음 | 높음 |
| 확장성 | 수십억 문서까지 사전 색인 가능 | 상위 소수 후보에만 실시간 적용 |
| 역할 | 1차 검색(넓게, 리콜 중심) | 2차 재정렬(좁게, 정밀도 중심) |
바이엔코더의 한계는 정보 손실에 있습니다. Pinecone은 바이엔코더가 "문서의 가능한 모든 의미를 단일 벡터로 압축해야 하므로 정보를 잃는다"고 지적합니다. 또한 쿼리는 런타임에야 알 수 있어서, 미리 만들어 둔 문서 임베딩은 쿼리 문맥을 반영하지 못합니다. 반면 크로스엔코더는 "원본 정보를 거대한 트랜스포머 연산에 직접 넣어 정보 손실이 적고", 문서를 "사용자 쿼리에 특화해" 분석합니다.
크로스엔코더는 왜 임베딩을 만들지 않는가
Sentence Transformers(SBERT) 문서는 "크로스엔코더는 문장 임베딩을 생성하지 않으며, 크로스엔코더에 개별 문장만 따로 넣을 수도 없다"고 명시합니다. 두 문장을 동시에 트랜스포머에 통과시켜 0~1 사이의 유사도 값만 출력하기 때문입니다. 즉 크로스엔코더는 "이 쿼리와 이 문서가 얼마나 관련 있는가"라는 질문에는 매우 정확하지만, 재사용 가능한 벡터를 만들어 대규모 검색 색인을 구성하는 용도로는 쓸 수 없습니다.
왜 2단계로 나누는가: 속도와 정밀도의 균형
크로스엔코더가 더 정확하다면 처음부터 모든 문서에 적용하면 될 것 같지만, 비용과 지연 때문에 불가능합니다. Pinecone은 "리랭커는 느리고 검색기는 빠르다"고 요약하며, 구체적 수치를 제시합니다. 4,000만 건의 레코드를 작은 BERT 모델과 V100 GPU로 리랭킹하면 50시간 이상 걸리지만, 벡터 검색은 100밀리초 미만이면 끝납니다.
SBERT 문서도 같은 맥락의 예를 듭니다. 1만 개 문장을 크로스엔코더로 군집화하면 약 5천만 개 조합의 유사도를 계산해야 해서 약 65시간이 걸리지만, 바이엔코더로 각 문장 임베딩을 구하면 5초면 됩니다.
그래서 표준 패턴은 두 방식을 연결하는 2단계 검색(two-stage retrieval)입니다. SBERT가 권장하는 흐름은 다음과 같습니다. 먼저 효율적인 바이엔코더로 쿼리에 대한 상위 100개 후보를 빠르게 검색하고, 그다음 크로스엔코더로 그 100개를 (쿼리, 후보) 쌍마다 점수를 매겨 재정렬합니다. 바이엔코더가 넓게 가져와 리콜을 확보하고, 크로스엔코더가 정밀도를 끌어올리는 구조입니다. Elastic도 시맨틱 리랭킹이 "비교적 크고 복잡한 머신러닝 모델을 실시간으로 돌리므로, 작은 top-k 결과 집합에 파이프라인 마지막 단계로 적용하는 것이 합리적"이라고 설명합니다.
실제 효과와 사례
리랭커는 1차 검색이 놓친 관련 문서를 상위로 끌어올립니다. Pinecone의 예시에서는 RLHF 관련 쿼리에 대해 정작 가장 관련 높은 정보가 1차 검색 결과의 23번째에 있었는데, 리랭킹 후 1번째로 올라왔습니다. 그 결과 LLM에 "훨씬 관련성 높은 정보"가 전달되고 노이즈가 줄었습니다. Pinecone은 리랭킹을 "RAG나 검색 기반 파이프라인에서 리콜 성능을 극적으로 끌어올리는 가장 단순한 방법 중 하나"이며, 대개 "몇 줄의 코드와 약간의 지연을 대가로 훨씬 관련성 높은 결과를 얻는다"고 평가합니다.
상용 리랭커도 널리 쓰입니다. Cohere의 Rerank 모델은 "쿼리에 대한 의미적 관련도로 텍스트 입력을 정렬"하며, 기존 검색 솔루션이 반환한 결과를 다시 정렬하는 데 자주 사용됩니다. Cohere Rerank는 요청마다 쿼리 토큰과 문서 토큰을 결합해 처리하고, rerank-v3.5 등의 모델은 문서당 컨텍스트 한도가 4,096 토큰입니다. 쿼리와 문서를 합친 토큰 수가 한도를 넘으면 문서를 자동으로 청크로 나눠 여러 번 추론합니다.
적용 체크리스트
- 1차 검색(벡터·BM25)으로 후보를 넉넉히(예: 상위 50~100개) 가져온 뒤 리랭커를 적용합니다.
- 리랭커는 전체 코퍼스가 아니라 상위 top-k 후보 집합에만 적용해 지연과 비용을 통제합니다.
- RAG라면 리랭킹 후 상위 소수만 LLM 컨텍스트에 넣어 노이즈를 줄이고 정확도를 높입니다.
- 다국어 문서는 다국어 리랭커(예: Cohere multilingual, rerank-v3.5)를 선택합니다.
- 긴 문서는 모델의 문서당 토큰 한도(예: 4,096)를 고려해 청킹 전략을 함께 설계합니다.