하이브리드 검색: BM25 vs 벡터 검색 (그리고 왜 둘 다 필요한가)

하이브리드 검색: BM25 vs 벡터 검색 (그리고 왜 둘 다 필요한가)

지원 담당자가 "SKU-4471"을 RAG 챗봇에 입력합니다. 네 개의 결과가 나옵니다. 모두 자신 있게 틀렸습니다. 범용 임베딩 모델은 그 정확한 문자열을 벡터 공간에서 자신과 가까이 배치할 이유가 없습니다. 이 단 하나의 실패 모드가 바로 하이브리드 검색이 존재하는 이유이며, 팀들이 계속해서 묻는 특정 질문이기도 합니다: BM25와 벡터 검색을 튜닝 노브를 계속 조정하지 않고 실제로는 어떻게 결합하는가?

더 광범위한 RAG 도구를 평가 중이라면, 우리의 최고의 RAG 도구 종합 가이드가 주변 스택을 다룹니다.

핵심 요점

• BM25는 정확한 키워드 매칭(SKU, 오류 코드)을 찾습니다. 벡터 검색은 개념적으로 유사한 텍스트를 찾으며, 동일한 문자열이 아닙니다.
• 하이브리드 검색은 일반적으로 상호 순위 융합(RRF)을 통해 둘을 결합하며, 혼합 쿼리 워크로드에서 어느 하나보다 더 나은 성능을 보입니다.
• WANDS 벤치마크에서 순수 RRF는 0.7068 NDCG(BM25의 0.6983에 비해)를 달성하며, 튜닝을 통해 0.7497까지 올라가 7.4% 성능 향상을 제공합니다.
• Postgres/pgvector는 ts_rank + pgvector를 통해 하이브리드 검색을 기본적으로 실행할 수 있으며, 전용 벡터 데이터베이스가 필요하지 않습니다.

하이브리드 검색이란? (BM25 + 벡터, 결합)

하이브리드 검색은 동일한 쿼리에 대해 BM25와 벡터 검색을 두 개의 별도 검색 패스로 실행한 후, 상호 순위 융합(RRF)이라는 융합 알고리즘을 사용하여 두 개의 순위 결과 목록을 단일 출력으로 병합합니다. 이는 세 번째 검색 방법이 아니라, 두 개의 기존 방법 위에 있는 오케스트레이션 계층입니다.

이 구분이 중요한 이유는 이 주제에 대한 검색 자료의 상당 부분이 BM25와 벡터 검색을 마치 같은 것인 냥 혼동하기 때문입니다. 그들은 다릅니다. BM25는 1970년대 정보 검색의 뿌리를 가진 희소하고 키워드 기반의 점수 매김 함수입니다. 벡터 검색은 밀집하고 임베딩 기반의 유사도 검색으로, 지난 10년 동안만 규모있게 실용적이 되었습니다. 하이브리드 검색은 이들을 경쟁 기술이 아닌 상호 보완적인 입력으로 취급하며, 미리 승자를 고르기보다는 출력을 융합합니다.

BM25 vs 벡터 vs 하이브리드: 빠른 비교

WANDS 전자상거래 벤치마크에서 BM25만 사용했을 때 0.6983 NDCG를 달성했고, 벡터 검색만 사용했을 때는 0.6953(거의 비슷)을 달성했습니다. 말뭉치별 튜닝 없이 순수 RRF 융합을 적용하면 0.7068에 도달하여 BM25만 사용했을 때 대비 1.2% 향상을 이루었습니다. Doug Turnbull의 벤치마크는 또한 RRF 위에 제품명 부스트를 계층화한 튜닝된 변형도 테스트했으며, 그 버전은 0.7497에 도달했습니다. 이는 7.4% 향상입니다. 인용하는 수치가 어느 것인지 솔직해야 합니다: RRF만 해도 즉시 사용 가능한 작은 실질적인 이점을 제공합니다. 더 큰 7.4% 수치는 대부분의 팀이 1일 차에 건너뛰는 추가 도메인별 튜닝이 필요했습니다. BM25도 벡터 검색도 단독으로는 지배적이지 않습니다. 이들은 서로 다른 실패 모드를 다루며, 이들을 융합하면 두 간격을 한 번에 닫습니다.

BM25 메커니즘: 키워드 검색이 실제로 관련성을 점수 매기는 방법

BM25는 용어 빈도로 문서를 점수 매기며, 전체 말뭉치에서 그 용어가 얼마나 드문지를 가중치로 적용한 후 문서 길이에 대해 정규화합니다. Robertson과 Zaragoza는 그들의 2009년 논문 "The Probabilistic Relevance Framework: BM25 and Beyond"에서 이 공식화를 제시했습니다. 이는 TF-IDF의 대체제가 아닌 개선입니다.

두 개의 매개변수가 BM25 동작의 대부분을 제어합니다. k1(일반적으로 1.2-2.0)은 단어 빈도 포화를 제어합니다. 이는 단어를 반복하면 점수가 어느 정도까지만 올라가게 하므로, "invoice"를 40번 말하는 문서가 더 좁고 관련성 높은 구절에서 4번만 말하는 문서를 자동으로 순위 매기지 않도록 합니다. b(기본값 0.75)는 문서 길이 정규화를 제어합니다. 이는 BM25가 자연스럽게 더 많은 용어 일치를 포함하는 긴 문서를 얼마나 가혹하게 처벌하는지를 결정합니다.

b를 잘못 설정하는 것은 실제로 흔한 튜닝 실수입니다. 짧은 기술 문서(오류 로그, 제품 제목)는 길이 변동이 작으므로 낮은 b를 원합니다. 장편 콘텐츠(문서 페이지, 기사)는 일반적으로 기본값에 가까운 b를 원합니다. BM25의 핵심 약점은 어휘 불일치입니다. 사용자가 "how do I get my money back"을 묻고 문서에 "refund policy"라고만 되어 있으면, BM25는 공유하는 토큰이 없어서 아무것도 반환하지 않습니다.

밀집 벡터 검색 메커니즘 (그리고 어디에서 무너지는가)

벡터 검색은 모델을 사용하여 텍스트를 고정 차원 임베딩으로 매핑한 후, 일반적으로 근사 최근접 이웃 인덱스로 가속되는 코사인 유사도 또는 내적을 통해 가까운 벡터를 찾습니다. HNSW는 Weaviate, Qdrant, Milvus 전반에 걸쳐 지배적인 알고리즘이며, 규모에서 속도 향상을 위해 소량의 재현율을 트레이드합니다.

이것이 BM25의 어휘 불일치 문제를 해결하는 것입니다: "get my money back"과 "refund policy"는 공유하는 토큰이 없더라도 임베딩 공간에서 서로 가까이 있습니다. 왜냐하면 모델이 표면 형태가 아닌 의미를 포착하기 때문입니다. 올바른 모델을 선택하는 것이 여기서 중요합니다. 올바른 임베딩 모델 선택에 대한 우리의 가이드를 참조하세요. 그리고 Voyage, OpenAI, Cohere 임베딩을 비교한 방법에 대한 우리의 분석을 참조하세요(옵션을 고려 중이신 경우).

하지만 밀집 검색도 자신만의 맹점이 있으며, 이는 BM25의 정반대입니다. 우리가 클라이언트를 위해 RAG 시스템을 구축할 때, 우리가 가장 자주 마주치는 정확한 매칭 실패는 이국적이지 않습니다. 이는 지원 담당자가 특정 주문 번호나 SKU를 묻는 경우이며, 벡터 인덱스는 의미론적으로 유사하지만 잘못된 것을 자신 있게 반환합니다. 범용 임베딩 모델은 "SKU-4471" 또는 "ERR_CONN_RST"를 벡터 공간에서 자신과 가까이 배치할 이유가 없으며, 관련이 있지만 잘못된 토큰에 비해서도 그렇습니다. 왜냐하면 그러한 문자열들은 훈련 데이터에서 구별되는 고립된 개념으로 거의 나타나지 않기 때문입니다. BigData Boutique는 자신의 SKU 및 오류 코드 예제로 이 정확한 실패 패턴을 문서화합니다. 이는 RAG 배포 전반에 걸쳐 독립적으로 검증된 잘 확립된 현상이며, 일회성 특이점이 아닙니다.

BM25와 벡터 검색을 결합하는 방법: RRF vs 알파 가중 융합

BM25와 벡터 결과를 융합하는 두 가지 실제 방법이 있으며, 하이브리드 검색에 대해 쓰는 거의 누구도 명확하게 대비하지 않습니다. 상호 순위 융합(RRF)(Cormack, Clarke, Buettcher의 2009 SIGIR 논문)은 순위에서 작동합니다. 점수 = sum(1 / (k + rank_i))(각 결과 목록 전반에서), k는 일반적으로 60으로 설정됩니다. 실제 점수가 아닌 위치만 신경 쓰기 때문에, RRF는 BM25의 무제한 점수와 코사인 유사도의 0에서 1 범위 사이의 스케일 불일치를 불만 없이 처리하며, 말뭉치별 튜닝이 필요하지 않습니다.

알파 가중(볼록) 융합은 다르게 작동합니다: final = alpha * dense_score + (1 - alpha) * sparse_score. 순위 대신 정규화된 점수에서 작동합니다. 신뢰도 크기를 더 잘 반영할 수 있습니다(0.95 유사도에서의 벡터 히트는 0.61에서의 히트보다 진정으로 더 강합니다). 하지만 말뭉치별로 알파를 튜닝해야 하며, 그 튜닝은 점수 분포가 이동할 때 조용히 무너집니다(새로운 임베딩 모델, 재색인된 말뭉치, 다른 쿼리 믹스).

실제로는 점수 보정을 얼마나 신뢰하는지가 선택을 결정합니다. 단일의 안정적인 임베딩 모델에 대해 일반 BM25를 실행하면, 알파 가중은 실제 점수 갭을 사용하고 위치만이 아닌 것을 사용하기 때문에 약간 더 나은 순위를 낼 수 있습니다. 하지만 그 보정은 사람들이 예상하는 것보다 더 많이 변합니다. 새로운 임베딩 모델 버전으로 바꾸거나, 문서를 재청크하거나, 업스트림에 순위 재조정 패스를 추가하면, 밀집 점수 분포가 이동합니다. 알파=0.6이 더 이상 올바른 값이 아닐 때 누가 호출을 받지 않습니다. 순위는 그냥 조용히 조금 더 나빠질 뿐이며, 정기적으로 검색 평가를 실행하지 않는 한 놓치기 쉽습니다. RRF는 실제 점수를 절대 보지 않고 오직 순위 위치만 보기 때문에 이것을 완전히 피합니다. 따라서 재인덱싱이나 모델 교환이 알파 가중을 깨뜨릴 수 있는 방식으로 조용히 이를 깨뜨릴 수 없습니다.

RRF는 말뭉치별 튜닝이 필요하지 않습니다. 알파 가중은 데이터가 변함에 따라 지속적인 감시가 필요합니다.

...

출처 바로가기