리랭커는 1차 검색으로 모은 후보 문서에 점수를 다시 매겨 순서를 정하는 구성 요소입니다. 후보 중 질문과 더 관련 있는 문서를 앞에 배치합니다. 크로스 인코더가 대표적인 구현 방식이지만, 다른 모델이나 규칙으로도 재정렬할 수 있습니다.
검색과 재정렬을 나누는 이유
전체 문서에 질문을 하나씩 대조해 관련도를 계산하면 문서가 늘어날수록 시간과 비용이 커집니다. 먼저 빠른 검색으로 후보를 좁히면, 계산량이 큰 모델을 일부 문서에만 적용할 수 있습니다. 리랭커를 두는 이유는 이렇게 평가할 문서 수를 줄이면서 상위 결과의 관련도를 높이기 위해서입니다.
신경망 검색에서는 바이 인코더로 후보를 찾고 크로스 인코더로 재정렬하는 구성이 대표적입니다.
| 방식 | 처리 방법 | 주로 맡는 역할 |
|---|---|---|
| 바이 인코더 | 질문과 문서를 각각 벡터로 만든 뒤 유사도를 비교합니다. | 많은 문서에서 후보 검색 |
| 크로스 인코더 | 질문과 문서를 한 쌍으로 모델에 입력해 관련도를 계산합니다. | 추린 후보의 평가와 재정렬 |
바이 인코더는 문서의 임베딩을 미리 계산해 저장할 수 있습니다. 검색할 때는 질문을 벡터로 바꾸고 저장된 문서 벡터와 비교하면 됩니다. 크로스 인코더는 질문과 문서를 함께 입력받아 둘의 관계를 평가하므로, 질문이 바뀔 때마다 각 후보와 짝지어 다시 계산해야 합니다.
크로스 인코더를 추가했다고 항상 더 정확한 결과를 얻는 것은 아닙니다. 실제 질문과 문서로 시험하면서 모델, 문서 길이, 후보 수에 따른 검색 품질과 지연 시간을 측정해야 합니다. 같은 모델도 실행하는 하드웨어에 따라 처리 속도가 달라집니다.
RAG에서 맡는 역할
RAG에서는 검색한 문서를 답변 생성 모델에 전달하기 전에 리랭커로 순서를 다시 정할 수 있습니다. 1차 검색에서는 관련 문서를 놓치지 않도록 후보를 비교적 많이 가져오고, 그중 질문과 관련도가 높은 일부를 골라 모델에 전달합니다.
따라서 1차 검색의 후보 수를 늘려도 생성 모델에 보내는 문서 수까지 늘릴 필요는 없습니다. 후보 수와 최종 전달 수를 따로 정할 수 있기 때문입니다. 다만 리랭커는 RAG의 필수 단계가 아닙니다. 문서 수가 적거나 1차 검색이 필요한 근거를 충분히 찾아준다면 생략할 수 있습니다.
재정렬 전후를 비교하는 예시
다음은 “무료 반품이 가능한 기간”이라는 질문에 1차 검색이 문서 세 개를 반환한 가상 예시입니다.
- 반품 신청 방법
- 무료 배송 안내
- 구매 후 14일 이내 무료 반품 정책
세 번째 문서에는 무료 반품 조건과 기간이 함께 들어 있습니다. 리랭커가 질문과 각 문서의 관련도를 적절히 평가한다면 이 문서를 가장 앞에 놓을 수 있습니다. 실제 순서는 사용할 모델과 문서 본문으로 시험해야 합니다.
검증할 때는 질문마다 답의 근거가 되는 문서를 지정하고, 같은 후보 목록을 재정렬하기 전과 후에 그 문서의 순위를 비교합니다. 생성 모델에 전달할 문서 수를 고정하면 필요한 근거가 최종 목록에 얼마나 자주 포함되는지도 비교할 수 있습니다. 이때 응답 시간과 호출 비용의 증가도 기록합니다.
정답 근거가 1차 후보에 없으면 리랭커가 그 문서를 새로 찾을 수는 없습니다. 이 경우에는 재정렬보다 검색 범위와 후보 수, 검색어 처리 방식을 먼저 점검해야 합니다.
공개 검색엔진에 적용해 해석할 때의 주의점
Google Cloud의 기업용 Agent Search 문서는 데이터와 색인 규모에 따라 수천 건의 문서를 검색하고, 랭킹 모델이 순서를 정해 상위 400건을 제공한다고 설명합니다. 전체 문서를 한꺼번에 평가하는 계산 비용을 줄이기 위해 검색과 순위 결정을 나눈 구성입니다.
그러나 이 문서는 기업용 제품의 설명입니다. 이를 근거로 공개 Google 검색이나 AI Overviews가 동일한 모델과 후보 수를 쓴다고 할 수는 없습니다. 다른 AI 검색 서비스에도 각 서비스의 공개 근거가 필요합니다.
웹사이트 운영자는 자신의 글이 AI 답변에 인용되지 않았다는 이유만으로 리랭커에서 탈락했다고 판단할 수 없습니다. 해당 서비스가 그 글을 검색 후보로 가져왔는지, 어떤 방식으로 후보를 골랐는지부터 알려져 있지 않기 때문입니다.
자주 묻는 질문
크로스 인코더와 바이 인코더는 어떻게 다른가요?
바이 인코더는 질문과 문서를 각각 벡터로 표현해 비교합니다. 크로스 인코더는 둘을 함께 입력해 관련도 점수를 계산합니다. 후보 검색과 재정렬에 각각 자주 쓰이지만, 실제 정확도와 비용은 사용할 모델과 데이터로 시험해야 합니다.
처음부터 정밀한 모델로 검색하면 안 되나요?
문서가 적다면 질문과 모든 문서를 직접 대조할 수도 있습니다. 문서가 많아지면 처리 시간과 비용 때문에 먼저 후보를 줄이는 구성이 유리할 수 있습니다. 후보 수를 줄였을 때 정답 근거까지 빠지는지 확인해야 하므로, 속도만으로 후보 수를 정하지 않습니다.
RAG에 리랭커가 꼭 필요한가요?
필수는 아닙니다. 1차 검색이 정답 근거를 찾지만 최종 전달 목록에서는 자주 빠진다면 리랭커를 시험할 이유가 있습니다. 도입 전후에 필요한 근거가 포함되는 비율과 실제 답변의 정확도를 비교하고, 추가되는 응답 시간과 비용을 감당할 수 있는지 판단합니다.
Google이나 네이버 검색도 같은 구조인가요?
Cohere, Sentence Transformers와 Google Cloud의 문서는 각 모델과 제품의 구조를 설명합니다. 공개 Google 검색이나 네이버가 같은 모델과 후보 수를 쓴다는 근거가 되지는 않습니다. 비슷한 결과가 나온다는 사실만으로 내부 구조까지 같다고 판단할 수는 없습니다.
함께 알아두면 좋은 용어
- 임베딩: 데이터를 숫자 벡터로 나타낸 표현
- 벡터 데이터베이스: 벡터와 관련 데이터를 저장하고 검색하는 시스템
- RAG: 검색한 자료를 답변 생성의 근거로 제공하는 구조
- 하이브리드 검색: 키워드 검색과 벡터 검색 등 여러 검색 방식을 결합한 방식