BM25 키워드 검색, 2026년에도 1차 검색기로 쓸 수 있을까?
결론부터 말하면 "단독으로는 조건부, 1차 후보 검색기로는 아직 유효"다. 정확한 용어·숫자·식별자 질의에서는 BM25가 dense retrieval보다 높은 회수율을 보였지만, 표현이 바뀐 질문에서는 성능이 뚜렷하게 떨어졌다. 그래서 "BM25 대 벡터"가 아니라 "BM25를 파이프라인 어디에 둘 것인가"가 더 정확한 질문이다.
핵심 정리
- 금융 문서 QA에서 BM25 Recall@5는 0.644, dense retrieval은 0.587로 BM25가 더 높았다 — 단, 7,318개 문서·23,088개 질의 조건 한정 출처
- BM25+dense RRF는 0.695, 여기에 Cohere Rerank까지 더하면 0.816까지 올라간다 — BM25 단독 대비 약 26.7% 상승
- 위키 실험에서는 페이지 수가 200→2,000개로 늘면서 패러프레이즈 질문의 Top-5 적중률이 71%→48%로 떨어졌다 출처
- 실용적 설계는 "BM25 1차 후보 + dense 보완 + reranker 정밀화"의 3단 구성이 반복적으로 좋은 결과를 보였다
- 수치는 데이터셋·청킹·모델 버전에 종속되므로 실험 조건 표기 없이 인용하면 재현이 안 된다
지금 이 글이 검증하려는 것은 하나다. "BM25를 지금 새 RAG 파이프라인의 1차 검색기로 놓는 게 합리적인 선택인가, 아니면 dense retrieval로 완전히 대체해야 하는가." 이걸 판단하려면 단일 수치가 아니라 질의 유형별 비교군이 필요하다.
BM25 실험을 어떻게 설계해야 공정한 비교가 될까?
비교군을 최소 4개로 나눠야 BM25 단독의 강점과 약점이 동시에 드러난다. 구성은 BM25 단독, dense embedding 단독, BM25+dense RRF, 하이브리드 상위 결과에 cross-encoder reranker를 얹은 구성이다. 여기에 테스트 세트도 하나로 섞지 않는 게 중요하다. 정확한 용어 질의, 패러프레이즈 질의, 숫자 질의, 표 질의, 긴 문서 질의를 분리해서 각각 Recall@5, Recall@10, MRR, nDCG, 답변 포함률, 지연시간을 따로 기록해야 한다.
이렇게 나누는 이유는 단일 평균 점수가 질의 유형별 강약을 가려버리기 때문이다. 실제로 금융 QA 실험에서도 HyDE나 다중 질의 확장은 정밀한 수치 질의에서는 효과가 제한적이었던 반면, 문맥 검색은 전반적으로 일관된 개선을 보였다고 보고됐다 출처. 한 가지 보강 기법이 모든 질의 유형에 똑같이 작동하지 않는다는 뜻이고, 이건 설계 단계에서 질의 유형을 미리 쪼개놓지 않으면 나중에 원인을 역추적하기 어렵다.
BM25 구현에서 무엇을 먼저 맞춰야 할까?
구현 단계에서 가장 먼저 고정해야 할 것은 토크나이저·형태소 분석기, 불용어 처리, 동의어 사전, k1·b 파라미터, 청크 크기와 오버랩, 검색 후보 수, RRF의 k 값이다. 이 값들을 바꾸지 않고 "BM25가 약하다"고 결론 내리면 실제로는 토크나이징 문제를 BM25의 한계로 오해하는 실패가 흔하다.
공개 사례들은 이 조건을 구체적으로 명시한다. LiveRAG Challenge 2025 사례는 OpenSearch BM25에서 상위 30개 문서를 검색하고, doc2query로 보강한 인덱스에 512토큰 청크를 사용했다 출처. 위키 실험에서는 BM25 상위 20개를 BAAI/bge-small-en-v1.5 임베딩으로 재정렬하거나, BM25 상위 20개와 벡터 검색 상위 20개를 합쳐 RRF(순위 r에 대해 1/(60+r))로 결합했다. 로컬 문서 QA 구현 사례는 BGE 임베딩과 BM25를 결합하고 Ollama·Llama 3.2로 답변을 생성했는데, sparse 30%·dense 70% 가중치를 최적값으로 보고했다 — 단 이건 SQuAD·MS MARCO·Natural Questions 조건에서 나온 값이라 그대로 가져다 쓰기보다는 10~20% 간격으로 비중을 바꿔가며 다시 측정하는 편이 안전하다.
검색이 잘 됐는지 어떻게 확인해야 할까?
"검색 성공"과 "답변 성공"을 분리해서 측정해야 한다. 검색 단계는 Recall@k, MRR, nDCG@k로, 답변 단계는 정답 포함 여부, 최종 답변의 정확성·근거성·인용 신뢰도로 따로 본다. 이 둘을 하나로 뭉뚱그리면 검색은 잘 됐는데 생성 단계에서 근거를 놓치는 경우와, 검색 자체가 실패한 경우를 구분할 수 없다.
TREC 2025 RAG 트랙은 이 구분을 실제로 적용한 사례다. 한 참가 시스템은 BM25 기준선, DPR dense retrieval, BM25+dense+cross-encoder 하이브리드를 비교했고, 하이브리드가 MAP 0.1037, nDCG@30 0.527, Recall@100 0.158을 기록했다. 46개 런 가운데 Retrieval 부문에서 좋은 성적을 낸 다른 4중 결합 시스템은 nDCG@30 0.693, Recall@100 0.257을 보고했다 출처. 같은 벤치마크 안에서도 결합 방식에 따라 수치 차이가 크다는 점이 평가 단계를 가볍게 넘기면 안 되는 이유다.
공개 벤치마크는 무엇을 보여주나?
표로 정리하면 BM25 단독과 하이브리드, 재순위화 사이의 간격이 일관되게 드러난다.
| 구성 | 지표 | 값 | 출처 조건 |
|---|---|---|---|
| BM25 단독 | Recall@5 | 0.644 | 금융 문서 QA |
| Dense 단독 | Recall@5 | 0.587 | 동일 조건 |
| BM25+Dense RRF | Recall@5 | 0.695 | 동일 조건 |
| +Cohere Rerank | Recall@5 | 0.816 | 동일 조건 |
| BM25 단독(SQuAD) | MRR / Recall@10 | 0.717 / 0.840 | 로컬 QA 구현 |
| 하이브리드(SQuAD) | MRR / Recall@10 | 0.805 / 0.974 | 로컬 QA 구현 |
| BM25+임베딩 | Recall@5000 | 0.6554→0.7555 | TREC 2025 |
출처: ar5iv 2604.01733, 출처: arxiv 2511.10297, 출처: TREC 2025
이 표에서 눈에 띄는 건 BM25가 항상 최하위가 아니라는 점이다. 금융 QA에서는 BM25가 dense 단독보다 높았고, SQuAD 기반 로컬 구현에서도 BM25 단독이 MRR 0.717이라는 적지 않은 수치를 냈다. 다만 모든 경우에서 하이브리드나 재순위화가 추가되면 수치가 더 올라갔다는 공통점도 있다.
BM25가 막히는 지점은 어디인가?
BM25의 한계는 표현이 달라진 질문에서 뚜렷하게 나타난다. 1,985~2,000페이지 규모 위키 실험에서 원문 용어를 그대로 쓴 질문은 BM25가 거의 전부(약 99~100%) 상위권에 올렸지만, 패러프레이즈 질문의 Top-5 적중률은 문서가 늘어날수록 71%에서 48%로 떨어졌다 출처. 이 실험은 개인 운영 규모의 결과라서 일반화보다는 "패러프레이즈를 꼭 별도로 테스트해야 한다"는 체크리스트로 쓰는 게 적절하다.
또 하나 주의할 점은 모든 수치가 특정 데이터셋·청킹·모델 버전에 묶여 있다는 것이다. 금융 QA 수치는 표가 섞인 7천여 문서 규모에서 나왔고, SQuAD 수치는 일반 QA 텍스트에서 나왔다. 두 결과를 섞어서 "BM25는 항상 이 정도 성능"이라고 말하면 틀린 결론이 된다. 실험을 옮길 때마다 문서 구성, 청크 크기, 토크나이저를 다시 맞추고 재측정해야 한다.
이번 실험에서 남은 질문은?
이번에 확인한 건 BM25가 정확한 용어·숫자 질의에서 쓸만한 기준선이라는 것과, 패러프레이즈 질의에서는 혼자 버티기 어렵다는 것 두 가지다. 아직 확인하지 못한 건 한국어 환경에서의 형태소 분석기 선택이 BM25 성능에 얼마나 영향을 주는지다. 이 글에서 인용한 자료는 대부분 영문 토크나이저 기준이라, 한국어 문서 QA에 그대로 적용하려면 별도 실험이 필요하다. 다음 실험에서는 같은 질의 세트에 형태소 분석기만 바꿔가며 Recall@5 변화를 기록해볼 계획이다.