하이브리드 검색은 왜 필요한가: BM25·벡터·재정렬의 역할

검색 질문에는 서로 다른 종류의 단서가 있다

두 질문을 비교해 보자. 첫째는 “ERR-1042 오류의 해결 절차”, 둘째는 “퇴사한 직원의 접근 권한을 빠짐없이 회수하려면?”이다. 첫 질문에서는 정확한 오류 코드가 강한 단서다. 둘째에서는 문서에 질문과 같은 표현이 없어도 계정 비활성화·토큰 회수·기기 반납 등 관련 내용을 찾아야 한다.

하나의 검색 방식이 두 상황에서 언제나 우세하다고 가정하면 설계가 단순해지는 대신 실패를 놓치기 쉽다. 벡터가 질문의 의미와 가까운 문서를 찾더라도 오류 코드의 숫자 한 자리가 달라질 수 있다. 키워드 검색은 정확한 용어가 없는 문서를 지나칠 수 있다. 어떤 신호를 합치고 어디까지 후보를 가져올지 고민하는 이유다.

이 글은 특정 임베딩 모델이나 검색 제품의 순위를 매기는 비교 실험이 아니다. 문헌과 공식 구현 설명을 바탕으로 후보 검색·결합·재정렬을 분리하고, 작은 가상 순위 목록으로 계산을 확인한다. 전체 RAG 구조와의 관계는 긴 문맥과 RAG 해설에서 이어 읽을 수 있다.

BM25와 벡터 검색은 점수의 의미부터 다르다

BM25 계열의 어휘 검색은 질의 용어가 문서에 나타나는 정도, 용어의 희소성, 문서 길이 등의 신호를 사용한다. 분석기가 문자열을 어떻게 토큰으로 나누는지도 결과에 영향을 준다. 한국어 복합어와 띄어쓰기, 코드·제품명 처리에서 분석 설정을 빼고 알고리즘 이름만 비교하면 실제 동작을 설명하기 어렵다.

벡터 검색은 질의와 문서를 임베딩으로 표현한 뒤 유사도에 따라 후보를 찾는다. 여기에는 임베딩 모델, 문서 조각의 크기와 내용, 거리 함수, 근사 검색 인덱스의 설정이 함께 작용한다. 관련 문서의 표현이 질문과 다를 때 도움이 될 수 있지만 “의미 검색”이라는 이름이 숫자·부정문·권한 조건의 정확한 처리를 보장하지는 않는다.

Microsoft의 하이브리드 검색 문서는 검색 방식마다 점수 범위가 다르며 결합 뒤의 RRF 점수와 의미 재정렬 점수도 구분한다고 설명한다. 따라서 BM25 점수 12와 벡터 점수 0.82를 더해 12.82로 만드는 것은 값의 크기와 분포를 무시한 결합일 수 있다. 가중합을 쓰려면 정규화와 튜닝의 기준이 필요하다.

단계	입력	무엇을 결정하나
어휘·벡터 후보 검색	전체 검색 가능한 문서	어떤 문서를 후보로 가져올지
중복 처리·순위 결합	여러 후보 목록	겹치는 문서를 합치고 초기 순위를 만들기
재정렬	제한된 후보와 질의	더 비싼 판단으로 우선순위를 다시 고르기
문맥 구성	최종 후보	어떤 구간·주변 맥락·출처를 모델에 넣을지

모든 단계가 필수인 것은 아니다. 문서가 작고 질문이 단순하다면 어휘 검색만으로 충분할 수 있다. 새로운 단계를 넣는 이유는 실제 실패를 줄일 수 있는지 확인하기 위해서여야 한다.

RRF는 숫자의 척도 대신 순위를 합친다

Elastic의 RRF 설명은 각 결과 목록에서 문서가 차지한 순위를 이용해 점수를 합치는 방식을 제시한다. 동일 가중치인 단순 형태는 다음과 같다.

RRF(d) = Σ 1 / (k + rankᵢ(d))

rank는 1부터 시작한다.
문서 d가 없는 목록은 더하지 않는다.
k는 순위의 영향 크기를 조절하는 상수다.

여기서 k는 벡터 검색에서 몇 개 후보를 가져올지 정하는 top-k와 다르다. 같은 글자라고 같은 설정이 아니다. 아래는 k=60, 어휘 순위 [A, B, C], 벡터 순위 [C, B, D]인 자체 예시다. 문서의 실제 내용이나 정답 여부는 아직 주어지지 않았다.

문서	어휘 순위	벡터 순위	RRF 점수
C	3	1	0.032266
B	2	2	0.032258
A	1	없음	0.016393
D	없음	3	0.015873

C는 1/63 + 1/61, B는 1/62 + 1/62다. 두 검색에 모두 나타난 문서가 한쪽에만 나타난 문서보다 위로 올라간다. 하지만 이것이 C의 내용이 B보다 정확하다는 증거는 아니다. C와 B의 차이도 매우 작다. 표는 서로 다른 검색 결과가 어떻게 결합되는지를 보여 줄 뿐, 품질 개선률을 측정하지 않는다.

계산 입력·전체 결과 내려받기에서 반올림 전 값을 확인할 수 있다. 이 예시의 k=60을 모든 자료에 맞는 최적값으로 해석하면 안 된다. 후보 창, 검색 신호의 수와 중복 성격도 결과에 영향을 준다.

재정렬은 더 정교한 판단을 좁은 범위에 쓴다

Sentence Transformers의 retrieve-and-rerank 설명은 빠른 검색으로 후보를 가져온 뒤 Cross-Encoder가 질의와 문서를 함께 보고 순서를 평가하는 구성을 다룬다. 문서 벡터를 미리 계산해 비교하는 방식과 달리, 질의·문서의 조합에 대한 더 비싼 계산을 후보에 적용하는 것이다.

그 비용 때문에 모든 문서에 곧바로 재정렬 모델을 적용하는 대신 후보 수를 제한한다. 후보를 많이 가져오면 정답이 들어올 가능성은 높아질 수 있지만 지연·연산 비용과 잡음도 늘 수 있다. 후보가 너무 적으면 재정렬기가 아무리 좋아도 읽어 보지 못한 정답은 선택할 수 없다.

가령 정답 문서 X가 어휘·벡터 목록 모두에서 잘려 나갔다면 그 뒤의 RRF와 reranker는 X를 복원할 재료가 없다. 이때 답변 모델만 바꾸거나 재정렬 점수를 조정하는 것은 문제의 앞단을 건너뛰는 대응일 수 있다. 정답이 후보에 들어오는지부터 확인해야 한다.

반대로 정답이 후보에는 있지만 최종 상위 결과에 오르지 못한다면 결합과 재정렬을 살펴볼 이유가 있다. 문서가 질문과 유사한 단어를 많이 쓰지만 실제 적용 조건은 다르거나, 최신 규정과 오래된 규정이 함께 후보에 들어온 상황을 따로 평가할 수 있다.

권한과 최신성은 검색 점수의 보너스 항목이 아니다

검색 품질을 점수 문제로만 다루면 중요한 경계가 빠진다. 권한 없는 문서가 높은 유사도를 얻었다고 사용자에게 보여도 되는 것은 아니다. 최신 정책이 필요할 때 과거 버전이 잘 맞는다는 이유로 답변 근거가 돼서도 안 된다.

접근 권한·유효 기간을 어디서 제한하는지 설계하고, 후보 검색과 후속 단계에서 그 경계가 유지되는지 확인해야 한다. 정확한 적용 위치는 제품과 인덱스 구현에 따라 달라질 수 있다. 권한을 최종 답변의 자연어 지시만으로 처리하는 설계와, 검색 가능한 문서 집합을 제한하는 설계는 다른 보호를 제공한다.

필터를 적용한 뒤 결과 수가 급격히 줄어드는 경우도 평가에 포함해야 한다. 단순한 “전체 문서 중 정답 검색”과 “이 사용자가 볼 수 있는 문서 중 정답 검색”은 같은 과제가 아니다. 빈 결과를 정상적인 거절로 처리할지, 권한 있는 다른 근거를 더 찾을지 제품 동작도 정해야 한다.

중복 문서 역시 주의할 점이다. 같은 원문을 여러 조각이나 복제본으로 넣으면 상위 후보가 한 자료로 채워질 수 있다. 순위 결합은 중복된 근거를 자동으로 독립된 지지 증거로 바꿔 주지 않는다. 문서·버전·구간 식별자를 관리해야 결합 후 무엇이 반복됐는지 볼 수 있다.

평균 점수보다 질문별 실패를 먼저 읽는다

BEIR 연구는 다양한 검색 과제를 묶어 도메인 밖에서도 방법을 평가할 필요를 보여 준다. 이 연구의 당시 모델 결과를 최신 임베딩 제품의 서열로 사용해서는 안 된다. 여기서 가져올 것은 평가셋의 질문과 자료가 바뀌면 성능 판단도 달라질 수 있다는 문제의식이다.

사내 문서 검색을 평가한다면 다음 묶음을 분리하는 방법을 생각해 볼 수 있다. 이는 이 글의 평가 설계안이며 이미 수집한 독자 데이터가 아니다.

질문 묶음	대표 실패	먼저 볼 관측
오류 코드·부품 번호	유사하지만 다른 식별자	정답 후보 포함, 코드 정확 일치
표현이 다른 업무 질문	동의어·다단계 관계 누락	어휘·벡터별 후보 차이
개정 규정·시점 질문	오래된 정답 제시	문서 버전과 적용일
여러 문서를 연결하는 질문	한 문서만 검색	필요한 근거들의 동시 포함
답이 없는 질문	관련 있어 보이는 문서로 억지 답변	근거 부족 판정
권한이 다른 사용자	허용되지 않은 근거 유출	접근 경계와 거절 결과

후보 단계에는 Recall@k처럼 정답 근거가 들어왔는지 보는 지표가 유용하다. 최종 순위에는 첫 유효 결과의 위치나 단계별 관련성을 반영하는 지표를 사용할 수 있다. 다만 정답 문서가 여러 개일 때 무엇을 분모로 삼고 어느 정도 관련성을 인정할지 먼저 정해야 한다. 지표 이름만 같아도 정답셋이 다르면 숫자를 곧바로 비교할 수 없다.

검색 시스템의 지연도 평균만으로 충분하지 않다. 긴 질의, 큰 필터 집합, 재정렬 후보 증가에서 느린 요청이 어떻게 달라지는지 보고, 품질 향상이 사용자가 기다릴 수 있는 시간 안에서 얻어졌는지 평가해야 한다.

복잡도를 한 단계씩 추가하는 실험 설계

비교를 시작할 때는 문서 버전과 질문·정답셋을 고정한다. 어휘 검색, 벡터 검색, 결합, 결합 후 재정렬의 순서로 같은 질문을 실행하고 각 단계의 후보 목록을 남기면 어떤 단계가 실패를 줄였는지 보기 쉽다. 동시에 임베딩·문서 분할·인덱스·reranker를 모두 바꾸면 개선의 원인을 분리하기 어렵다.

일부 질문은 좋아지고 다른 질문은 나빠질 수 있다. 전체 평균이 올랐어도 업무상 중요한 식별자 질의나 권한 경계가 악화됐다면 배포 판단은 달라져야 한다. 질문 묶음별 성능·지연·운영 비용을 함께 보는 이유다.

하이브리드 검색은 여러 신호를 활용할 수 있는 설계 선택이고, 재정렬은 후보 안에서 판단을 더 정교하게 만드는 선택이다. 어느 단계도 문서 품질·권한·정답 정의를 대신하지 않는다. “더 많은 모델을 붙였는가”보다 어떤 실패가 어느 단계에서 줄었는가를 남기면 검색 시스템을 계속 개선할 근거가 생긴다.