하이브리드 검색 (Hybrid Search)

하이브리드 검색(Hybrid Search)은 키워드 기반 검색과 의미 기반 검색을 동시에 돌린 뒤 두 결과를 하나의 순위로 합치는 방식입니다. 어느 한쪽이 다른 쪽보다 우월해서가 아니라, 두 방식이 서로 다른 종류의 질문에서 실패하기 때문에 나온 절충안입니다. RAG 파이프라인의 검색 단계에서 가장 널리 쓰이는 기본 구성이기도 합니다.

두 검색이 각각 놓치는 것

키워드 검색은 질문에 들어 있는 단어가 문서에도 그대로 있어야 찾습니다. BM25 같은 점수 함수가 대표적이고, 흔한 단어에는 낮은 가중치를, 드문 단어에는 높은 가중치를 주는 식으로 작동합니다. 정확히 일치하는 단어를 잡아내는 데는 강하지만, 사용자가 '결제가 안 돼요'라고 쓰고 문서에는 '카드 승인 실패'라고 적혀 있으면 아무것도 찾지 못합니다.

시맨틱 검색은 그 반대입니다. 질문과 문서를 각각 임베딩 벡터로 바꾼 뒤 코사인 유사도로 가까운 것을 고르기 때문에, 표현이 달라도 의미가 통하면 찾아냅니다. 대신 고유명사에 약합니다. 제품 코드 'XR-2200'이나 사번, 오탈자가 섞인 검색어는 임베딩 공간에서 비슷한 다른 값과 뭉개지기 쉽습니다. 숫자와 기호가 많은 문서일수록 이 약점이 크게 드러납니다.

결과를 합치는 방법

두 검색의 점수는 척도가 달라서 그대로 더할 수 없습니다. 그래서 가장 많이 쓰는 방법이 RRF(Reciprocal Rank Fusion)입니다. 점수를 무시하고 각 검색 결과에서의 등수만 가져와 등수의 역수를 더하는 방식이라, 어느 한 검색에서 1등이든 다른 검색에서 3등이든 양쪽 모두에서 상위권에 든 문서가 최종 순위에서 올라옵니다. 척도 보정이 필요 없어 조정할 값이 적다는 것이 장점입니다.

다른 방법은 점수를 0에서 1 사이로 정규화한 뒤 가중치를 곱해 더하는 방식입니다. 도메인에 따라 키워드 쪽 비중을 높이거나 낮출 수 있어 세밀한 조정에 유리하지만, 그만큼 가중치를 잘못 잡으면 한쪽 검색이 사실상 무시되는 결과가 나옵니다. 처음에는 RRF로 시작하고, 실제 질문 로그를 모은 뒤에 가중치 방식으로 넘어가는 순서를 권합니다.

합치기 전에 각 검색이 몇 개를 가져올지도 정해야 합니다. 보통 양쪽에서 각각 20~50개를 뽑아 합친 뒤, 최종적으로 LLM에 넘길 문서는 3~5개로 줄입니다. 후보를 너무 적게 뽑으면 정답 문서가 아예 후보에 들어오지 못하고, 너무 많이 뽑으면 뒤 단계의 계산량과 지연이 늘어납니다. 이 두 숫자는 문서 성격에 따라 달라지므로 실제 질문 세트로 재 보는 수밖에 없습니다.

실무에서 붙이는 자리

요즘 검색 엔진과 벡터 데이터베이스는 대부분 하이브리드 검색을 기본 기능으로 제공합니다. Elasticsearch와 OpenSearch, Weaviate, Qdrant가 그렇고, PostgreSQL에서도 pgvector와 전문 검색 인덱스를 함께 쓰면 같은 구성을 만들 수 있습니다. 별도 인프라를 늘리지 않고 이미 쓰는 데이터베이스 안에서 해결할 수 있다는 점이 도입 문턱을 낮춥니다.

검색 품질을 더 끌어올리고 싶다면 하이브리드 검색으로 후보를 넉넉히 뽑은 다음 리랭킹(reranking) 단계를 붙이는 조합이 표준에 가깝습니다. 하이브리드 검색은 '놓치지 않고 가져오는' 재현율을 담당하고, 리랭커가 '그중 진짜 관련 있는 것만 남기는' 정밀도를 담당하는 역할 분담입니다. 어느 한쪽만 손보면 개선 폭이 금방 멈춥니다.

여기에 메타데이터 필터를 함께 거는 구성도 흔합니다. 부서, 문서 종류, 작성 연도 같은 조건으로 먼저 범위를 좁히고 그 안에서 하이브리드 검색을 돌리는 방식입니다. '작년 이후 인사 규정'처럼 조건과 의미가 섞인 질문은 검색 방식만으로는 풀리지 않고, 질문에서 조건을 뽑아 필터로 옮겨 주어야 정확도가 올라갑니다.

마지막으로 청킹을 함께 점검해야 합니다. 문서를 어떻게 잘랐는지에 따라 두 검색 방식 모두 결과가 크게 달라지기 때문입니다. 표나 코드가 문단 중간에서 끊기면 키워드도 의미도 살아남지 못합니다. 검색이 잘 안 될 때 검색 알고리즘부터 바꾸는 경우가 많은데, 실제 원인은 청크 경계에 있는 경우가 적지 않습니다.