하이브리드 검색

검색 품질이 흔들릴 때 많은 팀은 먼저 임베딩 모델을 바꾸려 한다. 더 비싼 모델로 바꾸면 다 해결될 것처럼 느껴지기 때문이다. 하지만 실무에서 자주 벌어지는 일은 그 반대다. 모델은 좋아졌는데도 사용자는 여전히 엉뚱한 문서를 받는다. 이유는 간단하다. 검색 문제에는 두 종류가 섞여 있기 때문이다. 의미를 잘 찾아야 하는 문제와 정확한 단어를 놓치면 안 되는 문제다. 하이브리드 검색은 이 둘을 싸움 붙이지 않고 같은 팀으로 묶는 방법이다.

Dense 검색은 질문의 뜻을 읽는 데 강하다. 사용자가 문서와 다른 표현을 써도 관련 문서를 찾아올 수 있다. 반면 BM25 같은 키워드 기반 검색은 제품명, 버전, 조항 번호, 함수명, 에러 코드처럼 정확히 그 단어가 중요한 상황에서 놀라울 정도로 강하다. 좋은 RAG는 둘 중 하나를 고르는 시스템이 아니라, 둘의 장점을 겹쳐 쓰는 시스템에 가깝다.

왜 의미 검색만으로는 불안정한가

Dense 임베딩 검색은 문장을 벡터로 바꿔 의미적으로 비슷한 문서를 찾는다. 그래서 사용자가 "로그인이 자꾸 막혀요"라고 물었을 때 문서에 "authentication failure"라고 적혀 있어도 이어줄 수 있다. 이건 아주 강력하다. 사람의 표현 습관과 문서의 표현 습관이 다를 때, Dense 검색은 그 간극을 메워준다.

문제는 세상 모든 검색이 의미만으로 작동하지 않는다는 점이다. 실무 문서는 생각보다 훨씬 자주 정답 같은 토큰에 매달려 있다. 예를 들어 이런 질문을 떠올려 보자.

• "모델 XG-500 펌웨어 2.3.7 배포 문서 찾아줘"

• "제17조 3항 예외 규정이 어디 있었지?"

• "에러 코드 E4299 처리 방법 알려줘"

• "get_user_acl 함수가 어디서 호출돼?"

이런 질문은 의미가 비슷한 문서를 찾는 것만으로는 부족하다. XG-500, 2.3.7, 제17조 3항, E4299, get_user_acl 같은 토큰은 거의 비밀번호처럼 작동한다. 하나만 틀려도 전혀 다른 문서가 나올 수 있다.

Dense 검색이 이런 exact term 문제에서 흔들리는 이유는 몇 가지다. 우선 모델은 토큰을 그대로 사전처럼 저장하는 기계가 아니다. 숫자, 버전 문자열, 긴 제품 코드, 약어, 희귀한 함수명은 의미 공간에서 잘 뭉개질 수 있다. 또 임베딩은 "이 문장이 무엇에 대한 이야기인가"를 잘 잡는 대신, "바로 이 문자열이 있는가"에는 상대적으로 둔감할 수 있다. 사람이 보기엔 사소한 차이인 v2.3.7과 v2.3.8이 실제 운영에서는 치명적인 차이인데, Dense 검색은 이를 충분히 날카롭게 구분하지 못할 때가 있다.

바로 여기서 BM25가 등장한다. 그리고 많은 팀이 이 지점에서 처음 깨닫는다. 의미 검색이 최신 기술이고, 키워드 검색이 구식 기술인 것이 아니다. 둘은 서로 다른 실패를 막는 장치다.

BM25는 왜 아직도 강한가

BM25는 전통적인 키워드 검색 랭킹 방식이다. 이름은 조금 딱딱하지만 직관은 단순하다. 질문에 들어 있는 단어가 문서에 얼마나 잘 등장하는지, 그리고 그 단어가 전체 문서 집합에서 얼마나 희귀한지를 함께 본다. 흔한 단어보다 드문 단어를 더 중요하게 치고, 문서 안에서 적절히 등장하는 매치를 높게 평가한다.

중요한 것은 수식이 아니라 감각이다. BM25는 이렇게 생각한다.

"사용자가 E4299라고 정확히 말했다면, 그 단어가 들어 있는 문서를 먼저 보여줘야 하지 않을까?"

이 감각이 실무에서 아주 자주 맞아떨어진다. 특히 다음 같은 경우 BM25는 여전히 무섭도록 강하다.

• 제품명, 모델명, SKU, 버전 번호처럼 문자열 자체가 중요한 경우

• 법률 조항 번호, 계약 조항, 규정 코드처럼 정확한 참조가 필요한 경우

• 함수명, 클래스명, API 엔드포인트, 에러 코드처럼 표기 하나가 의미를 바꾸는 경우

• 고유명사, 사내 약어, 프로젝트 코드명처럼 외부 임베딩 모델이 잘 모르는 경우

예를 들어 사용자가 "POST /v1/billing/close 문서"를 찾는다고 해보자. Dense 검색은 "청구 종료 API", "billing close endpoint", "정산 마감" 같은 비슷한 의미 문서를 넓게 가져올 수 있다. 하지만 사용자가 정말 원하는 것이 특정 엔드포인트 문서라면, BM25가 정확한 문자열 매치로 훨씬 빨리 정답 근처에 도달할 가능성이 높다.

법률 문서도 비슷하다. "근로기준법 제74조"를 찾는 질문은 사실상 의미 검색 문제가 아니라 참조 검색 문제다. 이때 BM25는 정면승부를 한다. 정확한 조항 번호가 문서에 있으면 거의 주저하지 않고 그 문서를 끌어올린다.

Dense 검색이 잘하는 일, BM25가 잘하는 일

둘을 비교할 때 흔히 하는 실수는 "누가 더 좋으냐"를 묻는 것이다. 실무에서는 그 질문보다 "누가 어떤 실패를 막아주느냐"가 더 중요하다.

Dense 검색은 이런 상황에서 강하다. 사용자의 표현과 문서의 표현이 다를 때, 동의어와 패러프레이즈가 많을 때, 질문이 자연어 설명 중심일 때, 문서가 긴 설명문일 때 특히 잘 버틴다. 사용자가 "재택근무 승인 흐름"이라고 말했는데 문서에는 "remote work approval process"라고 적혀 있다면 Dense 검색이 다리를 놓아준다.

반면 BM25는 이런 상황에서 강하다. 질문에 특정 토큰이 있고, 그 토큰이 정답 판별의 핵심일 때다. 예를 들어 "RLS", "JWT", "Qdrant", "429", "PII", "XG-500", "auth.middleware.ts" 같은 문자열은 비슷한 뜻보다 같은 표기가 더 중요하다. 여기서는 BM25가 훨씬 믿음직하다.

이 둘의 차이는 마치 사람 두 명이 문서를 찾는 방식과 비슷하다. 한 사람은 "이 질문이 대체 무슨 뜻인지"를 잘 파악한다. 다른 한 사람은 "아, 방금 저 단어가 정확히 들어 있는 문서가 있네"를 잘 잡는다. 하이브리드 검색은 둘을 같은 방에 앉혀 놓는 일이다.

Sparse가 Dense의 exact term 문제를 어떻게 보완하는가

하이브리드 검색의 핵심은 Sparse 검색이 Dense 검색의 약점을 메우는 방식에 있다. 여기서 sparse는 보통 BM25처럼 키워드 신호를 사용하는 검색을 뜻한다. 문서를 벡터의 의미 공간으로 압축하기보다, 어떤 단어가 문서에 들어 있는지를 날카롭게 본다.

예를 들어 사용자가 "A100 GPU 대신 H100 권장되는 문서 있어?"라고 물었다고 해보자. Dense 검색은 GPU 업그레이드 가이드, 인프라 권장 사양, 모델 학습 성능 문서를 폭넓게 가져올 수 있다. 하지만 정말 중요한 차이는 A100과 H100이라는 정확한 모델명이다. 이 토큰을 무디게 처리하면 문서는 많이 나오는데 정작 핵심 비교 문서가 뒤로 밀릴 수 있다.

BM25는 이런 exact term 신호를 강하게 밀어준다. 그래서 Dense 검색이 넓게 후보를 주워오는 동안, BM25는 "그래도 사용자가 방금 말한 그 단어가 있는 문서는 놓치지 말자"라고 안전핀을 꽂는다. 이 안전핀이 실무에서 아주 중요하다. 사용자는 종종 질문의 절반을 자연어로 말하고, 나머지 절반을 제품 코드나 숫자로 말하기 때문이다.

코드 검색은 이 특성이 더 도드라진다. 사용자가 "세션 만료 체크하는 함수"라고 물으면 Dense 검색이 도움이 된다. 하지만 "isSessionExpired 함수"라고 물으면 키워드 신호의 가치가 훨씬 커진다. 제품 검색, 법률 검색, 사내 위키 검색, API 문서 검색이 하이브리드에 특히 잘 맞는 이유도 여기에 있다. 자연어 질문과 exact term 참조가 한 문장 안에 함께 들어오기 때문이다.

하이브리드 검색의 기본 구조

가장 단순한 하이브리드 검색은 같은 질문을 두 검색기에 동시에 넣는 것에서 시작한다. 하나는 BM25, 다른 하나는 Dense 검색이다. 그리고 두 결과를 모아서 하나의 순위로 합친다.

흐름은 대체로 이렇다.

• 질문을 정규화한다.

• 필요한 메타데이터 필터를 추출한다.

• BM25와 Dense 검색을 병렬로 수행한다.

• 두 결과를 합친다.

• 중복을 제거한다.

• 하나의 최종 순위를 만든다.

여기서 가장 중요한 단계가 바로 합치는 방법이다. 같은 문서를 두 검색기가 서로 다른 점수 체계로 평가하기 때문에, 결과를 아무렇게나 더하면 생각보다 쉽게 망가진다.

점수를 합치는 일은 생각보다 어렵다

BM25 점수와 Dense 유사도 점수는 숫자의 의미가 다르다. BM25의 12점과 Dense의 0.82는 같은 단위가 아니다. 둘을 그대로 더해서 "점수가 더 큰 문서가 더 좋다"라고 해버리면, 사실상 서로 다른 온도계 숫자를 같은 컵에 붓는 셈이 된다.

그래서 하이브리드 검색에서는 보통 두 가지 결합 방식이 많이 쓰인다. 순위 기반 결합과 점수 기반 결합이다. 대표적인 순위 기반 결합이 Reciprocal Rank Fusion, 즉 RRF이고, 대표적인 점수 기반 결합이 가중 결합이다.

Reciprocal Rank Fusion은 왜 실무에서 사랑받는가

RRF는 이름은 어렵지만 아이디어는 소박하다. 각 검색기에서 문서가 몇 등으로 나왔는지만 본다. 1등에 가까울수록 높은 점수를 주고, 여러 검색기에서 동시에 상위권에 뜬 문서를 끌어올린다. 즉, 점수 자체보다 랭크의 합의를 중시한다.

이 방식의 가장 큰 장점은 점수 스케일 차이에 둔감하다는 것이다. BM25는 점수가 3, 7, 12처럼 나올 수 있고, Dense 검색은 0.61, 0.78, 0.84처럼 나올 수 있다. 점수 분포가 매번 흔들려도 RRF는 "몇 등이었는가"만 보기 때문에 비교적 안정적이다.

예를 들어 어떤 문서가 BM25에서는 2등이고 Dense에서는 4등이라면, RRF는 이 문서를 꽤 강한 후보로 본다. 두 시스템이 모두 "이 문서는 상위권이다"라고 동의한 셈이기 때문이다. 반대로 Dense에서는 1등인데 BM25에서는 한참 아래거나, BM25에서는 1등인데 Dense에서는 전혀 안 보이는 문서는 다소 신중하게 다룬다. 이 특성 덕분에 RRF는 한쪽 검색기가 과하게 튀는 상황을 완화하는 데 좋다.

실무에서 RRF가 자주 선택되는 이유는 세 가지다.

• 구현이 단순하다.

• 점수 정규화에 덜 민감하다.

• 검색기별 점수 체계가 달라도 비교적 안정적으로 동작한다.

특히 처음 하이브리드 검색을 도입할 때는 RRF가 아주 좋은 출발점이다. 정교함은 조금 덜할 수 있어도, 쉽게 망가지지 않는다.

가중 결합은 더 세밀하지만 더 까다롭다

가중 결합은 BM25 점수와 Dense 점수를 정규화한 뒤, 각각에 가중치를 곱해서 합산하는 방식이다. 예를 들어 어떤 시스템은 exact term가 중요하니 BM25에 0.7, Dense에 0.3을 줄 수 있고, 어떤 시스템은 의미 매칭이 더 중요하니 반대로 둘 수 있다.

이 방식의 장점은 제어력이 좋다는 점이다. 검색 도메인에 따라 의도적으로 한쪽 신호를 더 강하게 밀 수 있다. 예를 들어 코드 검색이나 규정 검색이라면 BM25 쪽 비중을 높이는 것이 자연스럽고, 일반 FAQ나 설명형 문서 검색이라면 Dense 비중을 더 줄 수도 있다.

하지만 대가가 있다. 가중 결합은 정규화가 어렵다. BM25 점수 분포는 질문 길이, 희귀 단어 수, 문서 길이에 따라 흔들릴 수 있고, Dense 유사도 점수도 모델과 인덱스, 검색 설정에 따라 분포가 달라진다. 이 상태에서 정규화가 조금만 어긋나도 어느 한쪽 신호가 지나치게 커져 버린다. 그러면 하이브리드가 아니라 사실상 "BM25만 쓰는 시스템" 또는 "Dense만 쓰는 시스템"이 된다.

또 가중 결합은 운영 중 드리프트에 취약하다. 문서가 늘어나거나, 청킹 전략이 바뀌거나, 임베딩 모델을 교체하거나, 필터 조건이 달라지면 점수 분포가 달라질 수 있다. 어제 잘 맞던 0.6 대 0.4 비율이 오늘 갑자기 엉망이 되는 이유가 여기에 있다.

RRF와 가중 결합, 언제 무엇을 쓸까

둘 중 하나가 절대적으로 우월한 것은 아니다. 다만 성격이 다르다.

처음에는 RRF로 시작하고, 평가 데이터가 쌓인 뒤 가중 결합으로 세밀하게 조정하는 흐름이 안전하다. 아직 어떤 질의에서 무엇이 실패하는지 모르는 상태에서 너무 일찍 가중 결합으로 들어가면, 숫자를 만지는 재미는 있는데 시스템 이해는 오히려 흐려질 수 있다.

하이브리드 검색이 특히 강한 분야

하이브리드 검색은 모든 곳에서 무조건 필요한 것은 아니다. 하지만 다음 같은 분야에서는 아주 자주 큰 차이를 만든다.

코드 검색

코드 검색에는 자연어 질문과 exact term가 동시에 등장한다. "로그인 토큰 검증 로직"처럼 의미 중심 질문도 있고, "verifyAccessToken 함수"처럼 정확한 이름 중심 질문도 있다. Dense만 쓰면 함수명을 놓칠 수 있고, BM25만 쓰면 설명형 질문에 약할 수 있다. 둘을 같이 쓰면 "무슨 일을 하는 코드인지"와 "정확히 어떤 식별자인지"를 동시에 잡을 수 있다.

제품명 검색

전자제품, 제조업, SaaS 제품 문서에는 모델명과 버전 정보가 늘 붙는다. 사용자는 "A 시리즈 방수 등급 비교표"처럼 의미를 묻다가도 중간에 "XG-500" 같은 모델명을 함께 던진다. 이런 검색은 BM25가 모델명을 놓치지 않게 붙잡고, Dense가 비교 의도와 관련 문서를 넓게 찾는다.

법률·규정 문서 검색

법률 문서는 조항 번호, 시행일, 규정 코드, 예외 조항처럼 정확한 참조가 중요하다. 동시에 사용자는 이를 자연어로 질문한다. "출산휴가 관련 예외 규정"처럼 물을 수도 있고 "제74조"라고 바로 찍을 수도 있다. 하이브리드 검색은 이 두 질문 모두를 버틸 가능성이 높다.

메타데이터 필터를 함께 쓰면 왜 순위가 이상해지는가

실무의 하이브리드 검색은 거의 언제나 메타데이터 필터와 함께 움직인다. 예를 들어 이런 조건이 붙는다.

• 특정 테넌트의 문서만 검색

• 최신 버전 문서만 검색

• 한국어 문서만 검색

• 권한이 있는 문서만 검색

• 제품군이 특정 라인업인 문서만 검색

문제는 필터가 들어오는 순간 검색 결과의 모양이 크게 바뀐다는 점이다. 이때 순위 왜곡이 자주 생긴다.

가장 흔한 왜곡은 한쪽 검색기만 유리해지는 현상이다. 예를 들어 필터를 건 뒤 BM25는 후보를 50개 쉽게 찾았는데 Dense 검색은 7개밖에 못 찾았다고 해보자. 이 상태에서 단순 융합을 하면 후보 수가 많은 쪽이 순위를 사실상 장악할 수 있다. 반대로 매우 좁은 필터에서는 exact term가 있는 BM25 결과만 살아남고 Dense 쪽 다양성은 거의 사라질 수 있다.

또 다른 왜곡은 필터 적용 시점 차이에서 나온다. 한 시스템은 필터를 검색 전에 걸고, 다른 시스템은 검색 후에 걸면 공정한 비교가 되지 않는다. Dense는 전체 코퍼스에서 상위 문서를 찾은 뒤 대부분이 필터에서 탈락할 수 있고, BM25는 처음부터 필터된 집합 안에서 검색해 훨씬 유리한 결과를 낼 수 있다. 이 상태에서 둘을 합치면 "누가 더 잘 찾았는가"가 아니라 "누가 더 좋은 경기장에서 뛰었는가"를 비교하게 된다.

필터와 하이브리드를 함께 설계하는 방법

하이브리드 검색에 필터를 넣을 때는 검색기를 하나의 팀으로 봐야 한다. 둘 다 가능한 한 같은 조건에서 후보를 만들게 해야 한다.

첫째, 같은 필터를 같은 시점에 적용하는 것이 기본이다. BM25와 Dense 모두 검색 전 필터를 적용할 수 있으면 가장 좋다. 최소한 둘 다 동일한 후보 집합 제약을 공유해야 한다.

둘째, 필터가 강할수록 각 검색기 후보 수를 넉넉히 가져와야 한다. 필터 후에 남는 문서 수가 적으면 한쪽 검색기에서 top-k가 너무 빨리 바닥난다. 이때는 필터된 집합 안에서 BM25와 Dense 각각 더 넓은 후보를 뽑고, 그 후에 융합하는 편이 낫다.

셋째, 소스별 최소 보장 수량을 두는 방법이 유효하다. 예를 들어 최종 융합 전 후보군을 만들 때 BM25 상위 n개, Dense 상위 n개를 각각 확보한 뒤 합치는 식이다. 이렇게 하면 특정 필터 상황에서 한쪽 검색기가 지나치게 결과를 독식하는 문제를 줄일 수 있다.

넷째, 후보가 너무 적은 쪽을 위한 폴백 전략이 필요하다. 예를 들어 권한 필터 때문에 Dense 결과가 거의 비는 경우, BM25만으로라도 답변 가능한지 확인하거나, 반대로 키워드 매치가 빈약하면 Dense 비중을 높이는 식의 적응형 전략을 둘 수 있다.

다섯째, 가중 결합을 쓸수록 필터별 튜닝이 필요해질 수 있다. 같은 0.5 대 0.5 비중이 전체 코퍼스에서는 잘 맞아도, language=ko나 tenant=A 같은 제한된 부분집합에서는 전혀 다른 결과를 낼 수 있다. 그래서 필터가 강한 시스템에서는 RRF가 더 안전한 선택이 되는 경우가 많다.

순위 왜곡을 줄이는 실전 보정법

이제 조금 더 실무적으로 보자. 메타데이터 필터와 하이브리드 검색을 함께 쓸 때는 다음 보정법이 유용하다.

• BM25와 Dense 모두에 동일한 필터를 선적용한다.

• 각 검색기에서 가져오는 후보 수를 최종 top-k보다 충분히 크게 잡는다.

• 융합 전 중복 문서를 먼저 정리하고 문서 ID 기준으로 병합한다.

• 한쪽 검색기 결과 수가 지나치게 적을 때는 최소 보장 슬롯이나 적응형 가중치를 둔다.

• 필터 조합별 성능을 따로 평가한다. 전체 평균만 보면 왜곡이 숨는다.

여기서 특히 마지막이 중요하다. 많은 팀이 "전체 검색 품질은 좋아졌는데 특정 고객사만 불만이 많다"는 상황을 겪는다. 이유는 대개 필터 조건이 다른 부분집합에서 랭킹 특성이 달라졌기 때문이다. 예를 들어 영어 문서가 많은 테넌트에서는 Dense가 유리하고, 한국어 규정 문서가 많은 테넌트에서는 BM25가 더 유리할 수 있다. 전체 평균 점수는 좋아 보여도, 실제 사용자는 자기 데이터 안에서만 시스템을 경험한다.

하이브리드 검색에서 자주 하는 실수

하이브리드 검색은 이름만 들으면 "둘을 섞자"로 끝나는 것 같지만, 실제로는 섬세한 실패가 많다.

두 검색기를 돌렸다는 사실만으로 만족하는 실수

BM25와 Dense를 둘 다 호출해 놓고, 사실상 한쪽 결과만 쓰는 경우가 생각보다 많다. 점수 정규화가 엉망이거나 가중치가 극단적이면 하이브리드가 아니라 위장 단일 검색이 된다.

exact term 문제를 임베딩 모델 교체로만 해결하려는 실수

버전 번호와 에러 코드가 자꾸 틀리는데 임베딩 모델만 계속 교체하는 팀이 있다. 이런 문제는 대개 하이브리드 설계의 문제다. 정확한 토큰 매치가 중요한데 의미 검색만 더 세게 밀고 있는 셈이다.

필터를 검색기마다 다르게 적용하는 실수

BM25는 필터 전, Dense는 필터 후로 처리하면 랭킹을 공정하게 비교할 수 없다. 융합 결과가 이상하다면 먼저 필터 적용 시점을 의심해야 한다.

평가를 전체 평균으로만 보는 실수

하이브리드 검색은 질문 유형에 따라 체감 차이가 매우 크다. 코드 질의, 규정 질의, 제품명 질의, 자연어 FAQ 질의를 섞어 평균만 보면 어떤 케이스가 좋아졌고 어떤 케이스가 망가졌는지 보이지 않는다.

어떤 질문에 하이브리드를 우선 적용해야 할까

모든 질의에 똑같이 하이브리드를 거는 것이 반드시 정답은 아니다. 하지만 다음과 같은 신호가 보이면 우선 적용을 고려할 만하다.

• 질문에 숫자, 버전, 모델명, 함수명, 코드, 조항 번호가 포함된다.

• 문서 코퍼스에 한국어와 영어, 자연어와 코드가 섞여 있다.

• 사용자의 표현과 문서의 공식 용어가 자주 다르다.

• 동일 질문군에서 exact match 실패와 semantic miss가 번갈아 발생한다.

• Dense만 썼을 때는 비슷한 문서는 많은데 정확한 문서가 자꾸 뒤로 밀린다.

이런 환경에서는 하이브리드 검색이 단순한 성능 향상 기법이 아니라, 검색 품질을 안정화하는 장치가 된다. 평균 점수를 조금 올리는 수준이 아니라, 실패 패턴 자체를 줄여준다.

하이브리드 검색의 현실적인 출발점

처음부터 완벽한 융합 공식을 만들 필요는 없다. 오히려 다음 순서가 안전하다.

먼저 BM25와 Dense를 각각 독립적으로 평가해, 어떤 질의군에서 누구의 장점이 드러나는지 본다. 그다음 RRF로 단순하게 합쳐 본다. 여기서 이미 많은 exact term 실패가 줄어드는지 확인한다. 이후에야 도메인별로 가중 결합이나 적응형 결합을 검토한다. 그리고 메타데이터 필터가 강한 시스템이라면 전체 평균뿐 아니라 테넌트별, 언어별, 문서 유형별 평가를 따로 본다.

이 순서를 거치면 중요한 사실이 보인다. 하이브리드 검색은 "Dense 검색이 부족하니 옛날 검색을 덧붙이자"는 발상이 아니다. 오히려 검색이라는 문제를 더 정확히 이해한 결과다. 사용자는 의미로도 찾고, 단어로도 찾는다. 문서도 의미로 연결되고, 단어로 식별된다. 그러니 검색기도 두 축을 모두 가져야 한다.

좋은 RAG는 질문의 뜻을 이해하면서도, 질문 속 정확한 단어를 놓치지 않는다. 바로 그 균형이 하이브리드 검색의 본질이다. 의미와 키워드는 경쟁 관계가 아니다. 하나는 넓게 찾게 해주고, 다른 하나는 정확히 붙잡아준다. 그리고 둘이 함께 움직일 때, 검색은 비로소 실무에서 믿을 만해진다.

다음 장에서는 이렇게 넓게 모아 온 후보 문서를 어떻게 더 정밀하게 줄일지, 즉 리랭킹의 역할을 살펴보자. 하이브리드 검색이 좋은 후보군을 만드는 기술이라면, 리랭킹은 그 후보군 안에서 정말 쓸모 있는 문서를 앞줄로 세우는 기술이다.