BEIR 논문을 읽었다.
처음에는 BM25, Dense Retrieval, ColBERT, Cross-Encoder의 성능을 비교한 논문이라고 생각했다. 다 읽고 나서는 모델 순위보다 검색 모델을 어떤 데이터로 평가했는가가 더 오래 남았다. 같은 모델도 domain과 task가 달라지면 순위가 바뀌었고, 정답을 만드는 과정 자체가 특정 검색 방식에 유리할 수도 있었다.
요약본
BEIR는 검색 모델의 zero-shot 일반화 성능을 비교하기 위한 benchmark다. 저자들은 9개 retrieval task에서 18개 영어 dataset을 모으고, lexical·sparse·dense·late-interaction·reranking의 5개 계열에 속한 10개 방식을 같은 기준으로 평가했다.
핵심 결과는 네 문장으로 줄일 수 있다.
- MS MARCO 안에서 높은 성능을 낸 neural retriever가 다른 domain과 task에서도 잘하는 것은 아니었다.
- BM25는 오래된 방식이라서 남은 baseline이 아니라, 여러 dataset에서 쉽게 무너지지 않는 강한 zero-shot baseline이었다.
- 평균 성능은
BM25 + Cross-Encoderreranking이 가장 높았지만, top-100 문서를 다시 비교하는 계산 비용이 컸다. - 평가용 relevance judgment를 lexical retriever의 후보로 만들면 dense retriever가 찾은 관련 문서가 오답으로 처리될 수 있었다.
이 논문을 “BM25가 Dense보다 좋다”로 요약하면 중요한 부분을 놓친다. 더 정확한 요약은 다음에 가깝다.
모든 dataset에서 이기는 검색 방식은 없었다. 품질, 일반화, latency, index size, 평가셋의 편향을 함께 봐야 한다.
논문이 묻는 질문
기존 neural retrieval 연구는 주로 Natural Questions나 MS MARCO처럼 큰 dataset에서 학습하고 같은 종류의 test set으로 평가했다. 이 환경에서는 학습 dataset의 query 형태, document 길이, domain vocabulary가 test에도 이어진다.
실제 서비스에서는 이 조건이 잘 성립하지 않는다. 공개 web query로 학습한 모델을 biomedical paper, finance Q&A, StackExchange 중복 질문, fact checking에 바로 적용할 수 있다. target domain의 relevance label이 없는 경우도 많다.
BEIR에서 zero-shot은 이런 상황을 뜻한다. 평가할 target dataset의 relevance label로 모델을 supervised fine-tuning하지 않은 채 검색한다. 논문은 질문 답변만 모으지 않고 다음처럼 성격이 다른 task를 함께 넣었다.
fact checking
citation prediction
duplicate-question retrieval
argument retrieval
news retrieval
question answering
tweet retrieval
biomedical information retrieval
entity retrieval
corpus 크기는 약 3,600개에서 1,500만 개까지, 평균 query 길이는 약 3단어에서 193단어까지 달랐다. 하나의 benchmark 안에서 domain shift뿐 아니라 task shift와 길이 차이도 같이 보려 한 구성이다.
비교한 검색 방식
논문은 10개 방식을 5개 계열로 나눴다.
| 계열 | 모델 | 내가 이해한 역할 |
|---|---|---|
| Lexical | BM25 | query와 document의 term overlap을 이용한 기준선 |
| Sparse | DeepCT, SPARTA, docT5query | term weight를 학습하거나 document에 예상 query를 확장 |
| Dense | DPR, ANCE, TAS-B, GenQ | query와 document를 각각 vector로 만들고 가까운 문서를 검색 |
| Late interaction | ColBERT | token별 vector를 보존한 뒤 query-document token 상호작용으로 점수 계산 |
| Reranking | BM25 + CE | BM25 top-100만 Cross-Encoder로 다시 정렬 |
평가 지표는 nDCG@10이다. 관련 문서가 상위에 있을수록 높은 점수를 주고, relevance가 여러 단계인 dataset도 같은 지표로 다룰 수 있다. 검색 결과 열 개의 순서를 보는 문제이므로, 단순히 관련 문서가 포함됐는지만 세는 recall과는 목적이 다르다.
한 가지 조건도 같이 봐야 한다. neural architecture에는 모든 document의 앞 512 word pieces만 입력했다. 긴 문서 전체를 이해한 결과로 읽으면 안 된다.
결과를 읽으며 이해한 것
In-domain 성능은 일반화 성능이 아니었다
MS MARCO에서는 여러 neural model이 BM25를 크게 앞섰다. 하지만 18개 zero-shot dataset으로 이동하면 순위가 바뀌었다. DeepCT와 SPARTA는 거의 모든 dataset에서 BM25보다 낮았고, dense model도 domain이나 task가 크게 달라지면 흔들렸다.
특히 같은 MS MARCO 계열 학습 데이터를 사용한 model도 BEIR 성능은 같지 않았다. 학습 dataset 이름만 보고 일반화 성능을 예상할 수 없고, negative sampling, loss, teacher model 같은 학습 방식까지 결과에 영향을 준다는 뜻으로 이해했다.
BM25는 출발점이지 최종 승자가 아니었다
BM25는 복잡한 model보다 여러 dataset에서 안정적이었다. 그렇다고 모든 dataset에서 가장 높았던 것은 아니다.
BM25 + CE는 18개 중 16개 dataset에서 BM25를 넘었고, 논문이 계산한 BM25 대비 평균 성능은 11% 높았다. docT5query는 11개, ColBERT는 9개 dataset에서 BM25를 넘었다. 반대로 argument retrieval인 ArguAna와 Touché-2020에서는 BM25 + CE도 BM25보다 낮았다.
그래서 이 결과는 “BM25-only를 선택하라”보다 다음 순서를 지지한다.
BM25로 재현 가능한 baseline을 만든다.
→ dataset과 query 유형별 실패를 찾는다.
→ 개선 모델이 같은 조건에서 실제로 그 실패를 줄이는지 측정한다.
그럼 BM25-only는 언제 정답에 가까울까
여기부터는 논문의 결론이 아니라, BEIR의 결과를 MES·SCM 검색에 대입해 본 내 설계 가설이다. 아직 사내 corpus와 실제 query로 검증하지 않았기 때문에 확정안으로 보지는 않는다.
먼저 “코드·품번·화면 ID에는 BM25가 좋다”는 생각부터 조금 고쳐야 했다. 사용자가 WO-20260721-0031을 정확히 입력했다면 BM25보다 keyword field나 registry의 exact lookup이 먼저다. analyzer가 하이픈을 나누거나 대소문자를 바꾸면 BM25가 원래 식별자를 보존한다는 보장이 없기 때문이다.
BM25는 정확한 식별자를 조회하는 기능이라기보다, 같거나 비슷한 term을 포함한 문서의 순위를 정하는 검색기에 가깝다. 품번 일부만 기억하거나 화면 이름과 설명을 함께 입력한 경우에는 좋은 fallback이 될 수 있다.
내가 현재 생각하는 BM25-only의 조건은 다음과 같다.
- query와 정답 문서가 같은 업무 용어, 메뉴명, 에러 코드처럼 강한 lexical signal을 공유한다.
- 학습용 relevance label이 거의 없어 복잡한 model의 개선을 증명하기 어렵다.
- CPU만으로 짧은 latency를 내야 하고 index와 운영 비용을 작게 유지해야 한다.
- 한국어 analyzer, 사용자 사전, exact field를 먼저 정리했다.
- 실제 query 평가에서
Recall@k와 상위 결과 품질이 요구 기준을 넘었다.
마지막 조건이 가장 중요하다. 단순해서 BM25-only를 고르는 것이 아니라, 측정해 보니 더 복잡한 경로가 필요 없을 때 BM25-only가 정답이 된다.
반대로 다음 query에서는 BM25-only가 불안하다.
| 질문 유형 | 먼저 고려할 경로 | 이유 |
|---|---|---|
| 정확한 품번·LOT·W/O·화면 ID | Exact lookup | 순위 계산보다 동일한 key를 보존하는 일이 먼저다. |
| 메뉴명·버튼명·에러 코드가 포함된 매뉴얼 질문 | BM25 | query와 문서가 같은 단어를 공유할 가능성이 높다. |
| 표현이 다른 절차 질문 | BM25 + Dense 후보 결합 | 같은 의미를 다른 단어로 표현하는 lexical gap이 생긴다. |
| 원인 표현이 다양한 장애 사례 | Hybrid 후보 + 선택적 Reranker | error code의 lexical signal과 증상의 semantic signal이 모두 필요하다. |
| 실시간 재고·WIP·납기 수치 | API·SQL | 최신 값을 계산하는 일은 문서 검색 문제가 아니다. |
| BOM·공정·설비 조건이 섞인 조회 | 구조화 filter + 검색 | field 조건을 text relevance 하나로 대신하면 정확한 제약을 잃는다. |
BM25보다 더 좋은 것은 하나가 아니었다
처음에는 Dense Retrieval이 BM25의 다음 세대라고 생각했다. BEIR를 읽고 이 선형적인 순서를 버렸다. 방식마다 잘 고치는 실패가 다르다.
Dense Retrieval은 query와 문서의 단어가 달라도 의미가 가까운 후보를 찾을 가능성이 있다. “자재 투입이 자꾸 밀린다”와 “원재료 공급 지연”처럼 표현이 다른 현장 기록에 유리할 수 있다. 대신 품번 한 글자 차이처럼 표면형이 중요한 검색에서는 가까운 의미가 오히려 오답을 만들 수 있다. BEIR에서도 dense model은 dataset에 따라 BM25보다 크게 좋아지거나 나빠졌다.
Hybrid Retrieval은 BM25와 Dense 중 하나를 고르지 않고 두 후보 집합을 합친다. MES처럼 식별자와 자연어가 한 query에 같이 등장하는 환경에서는 가장 먼저 비교해 볼 만하다. 다만 “Hybrid를 쓴다”만으로 설계가 끝나지는 않는다. 각 retriever에서 몇 개를 가져올지, 점수 scale을 어떻게 맞출지, 중복을 어떻게 합칠지를 정해야 한다.
Reranker는 후보 안에 정답이 있지만 순서가 나쁠 때 유용하다. BEIR의 BM25 + CE처럼 BM25 top-100을 query와 함께 다시 읽으면 lexical score만으로 구분하기 어려운 문맥을 비교할 수 있다. 하지만 첫 단계에서 정답을 놓치면 reranker도 복구하지 못한다. BM25의 Recall@100이 낮은 문제라면 reranker보다 Dense 후보를 추가하는 일이 먼저다.
Document expansion이나 learned sparse retrieval은 lexical index의 운영 방식을 유지하면서 표현 차이를 줄이는 중간 선택지다. BEIR에서 docT5query는 BM25보다 11개 dataset에서 높았지만, document마다 synthetic query를 생성하는 index 구축 비용과 domain에 맞지 않는 확장어가 붙을 가능성도 같이 봐야 한다.
그래서 “BM25보다 무엇이 더 좋은가?”라는 질문에는 조건이 빠져 있다. 지금 내 답은 다음과 같다.
식별자를 정확히 찾는 데에는 exact lookup이 더 맞다.
표현이 다른 관련 문서를 놓치지 않는 데에는 Dense를 합친 후보가 더 나을 수 있다.
후보는 맞지만 순서가 나쁠 때에는 Reranker가 더 나을 수 있다.
최신 값과 구조화 조건에는 문서 검색보다 API·SQL이 더 맞다.
전체 질문을 하나의 검색기로 보내는 대신 질문의 성격에 따라 경로를 나누는 편이 더 자연스럽다.
user query
├─ identifier ─────→ exact field / registry
├─ live value ─────→ API / SQL
└─ document search
├─ BM25 candidates
├─ Dense candidates, 필요한 query만
├─ merge / deduplicate
└─ rerank, 순위 개선 가치가 비용보다 클 때만
이 구조도 정답이라고 단정할 수는 없다. 처음에는 exact lookup과 BM25만 구현하고, 그것이 놓친 query 유형이 확인될 때 Dense와 reranker를 추가하는 편이 낫다. 복잡한 model을 먼저 넣으면 품질이 오른 이유와 장애가 난 지점을 설명하기 어려워진다.
좋은 성능에는 계산 비용이 붙었다
논문은 DBPedia 문서 100만 개를 표본으로 latency와 index size도 비교했다. 당시 측정 환경에서 BM25의 CPU latency는 20ms였다. BM25 top-100을 Cross-Encoder로 재정렬하면 GPU 450ms, CPU 6,100ms가 걸렸다. ColBERT는 GPU 350ms였고 index는 20GB였다. BM25 index는 0.4GB였다.
반면 dense retriever의 GPU latency는 14~20ms 수준이고 index는 3GB였다. 절대 수치는 2021년 hardware와 구현에 묶여 있으므로 현재 서비스의 예상 latency로 가져오면 안 된다. 다만 품질이 높은 interaction을 corpus 전체에 바로 적용하지 않고, 먼저 후보를 줄인 뒤 비싼 비교를 수행하는 two-stage 구조는 분명하게 보였다.
평균보다 dataset별 역전이 중요했다
GenQ는 target corpus에서 synthetic query를 만들어 TAS-B를 추가 학습한다. specialized domain인 scientific publication, finance, StackExchange에서는 TAS-B보다 좋아졌지만, Wikipedia처럼 넓고 일반적인 domain에서는 오히려 약해졌다.
TAS-B와 ANCE의 차이도 단순한 model 크기 문제로 끝나지 않았다. TREC-COVID에서 TAS-B가 가져온 문서의 median length는 10단어, ANCE는 160단어였다. 부록의 통제 실험에서는 cosine similarity를 사용한 model이 짧은 문서를, dot product를 사용한 model이 긴 문서를 더 선호했다. similarity function 하나가 점수뿐 아니라 검색되는 문서 길이 분포까지 바꿀 수 있었다.
여기서 새로 배운 점은 embedding model 이름만 기록해서는 실험을 재현하기 어렵다는 것이다. pooling, similarity, normalization, chunk length도 retrieval model의 일부로 남겨야 한다.
가장 인상적이었던 부분은 평가셋도 편향된다는 점이다
retrieval dataset은 모든 query-document 쌍을 사람이 판정할 수 없다. 보통 기존 검색 시스템이 가져온 후보 pool만 사람이 관련·비관련으로 표시하고, pool에 없던 문서는 사실상 비관련으로 취급한다.
문제는 후보를 BM25 같은 lexical system 위주로 모으면 lexical overlap이 적은 관련 문서가 애초에 판정 대상에 들어오지 않을 수 있다는 점이다. 새로운 dense retriever가 그런 문서를 찾아도 기존 qrels에는 정답이 없으므로 점수가 깎인다.
저자들은 TREC-COVID에서 각 model의 top-10 중 판정되지 않은 문서를 확인했다. Hole@10은 BM25 6.4%, docT5query 2.8%였지만 DPR 30.6%, TAS-B 31.8%였다. 누락된 980개 query-document 쌍을 추가로 판정하자 ANCE의 nDCG@10은 0.654에서 0.735로 올랐다. 기존 점수에서는 BM25 0.656보다 약간 낮았지만, 보완 후에는 BM25의 보완 점수 0.668보다 높았다.
이 부분에서 내 생각이 가장 많이 바뀌었다. 이전에는 benchmark score를 model의 결과라고만 봤다. 실제로는 다음 세 요소가 합쳐진 결과였다.
model이 검색한 결과
+ 정답 후보를 수집한 기존 retriever
+ 사람이 판정한 범위와 기준
새 방식이 기존 방식과 다른 문서를 많이 찾을수록, 미판정 문서가 늘어 불리해질 수도 있다. offline metric이 낮을 때 model만 의심하지 말고 qrels가 어떤 pool에서 만들어졌는지 확인해야 한다.
새로 배운 것
Zero-shot은 model checkpoint의 속성이 아니었다
“zero-shot model”이라는 이름만 보고 어디서나 비슷하게 동작한다고 생각하기 쉽다. BEIR에서는 학습 분포와 target의 domain, task, query 길이, document 길이가 얼마나 다른지가 성능을 바꿨다. zero-shot은 label을 사용하지 않았다는 실험 조건이지, 일반화를 보장하는 품질 인증이 아니다.
Reranker는 검색기를 대체하지 않는다
Cross-Encoder는 query와 document를 함께 읽기 때문에 세밀한 비교가 가능하지만, corpus 전체와 비교하기에는 비싸다. 논문의 BM25 + CE는 BM25가 가져온 100개 안에서만 순서를 바꾼다. 첫 단계가 관련 문서를 놓치면 reranker는 복구할 수 없다.
그래서 retriever는 Recall@k, reranker는 nDCG@10이나 MRR처럼 역할을 나눠 측정하는 편이 이해하기 쉽다. 최종 metric 하나만 보면 후보 생성 실패와 정렬 실패가 섞인다.
Benchmark의 다양성은 dataset 개수와 같지 않다
BEIR는 dataset을 많이 모으는 데서 끝나지 않았다. task, domain, corpus size, query와 document 길이, annotation strategy가 서로 다른지를 선택 기준으로 삼았다. 저자들은 unigram weighted Jaccard similarity로 dataset 사이 vocabulary overlap도 확인했다.
사내 평가셋을 만들 때도 query 수만 늘리는 것으로는 부족하다. 식별자 검색, 절차 질문, 장애 사례, 정의 확인처럼 검색 실패 방식이 다른 유형을 의도적으로 나눠야 한다.
느낀 점
이 논문은 새 retrieval architecture를 제안하지 않는다. 대신 “우리 model이 잘한다”는 말을 하기 어렵게 만드는 평가판을 만들었다. 읽기 전에는 benchmark 논문이 model 논문보다 덜 기술적일 것이라고 생각했는데, 오히려 실무와 가까웠다. 운영에서 필요한 것은 한 dataset의 최고점보다 domain이 바뀌었을 때 얼마나 무너지는지, 그 성능을 얻는 데 얼마가 드는지이기 때문이다.
BM25를 보는 시선도 달라졌다. BM25는 Dense Retrieval 이전의 임시 단계가 아니다. 새 model이 정말 나아졌는지 확인하는 통제군이고, lexical signal이 중요한 query에서는 운영 경로로 남을 수 있다. 반대로 BEIR 하나만 근거로 Dense Retrieval을 포기하는 것도 맞지 않다. TREC-COVID의 추가 판정처럼 evaluation pool이 dense 방식에 불리했을 가능성도 확인해야 한다.
가장 크게 남은 문장은 논문에 그대로 적힌 model 순위가 아니라 다음 질문이다.
이 점수는 내가 풀려는 검색 문제를 측정하고 있는가?
model을 바꾸기 전에 query 유형, corpus, relevance 기준, candidate pool, latency budget부터 적어야 한다. 이 조건이 없으면 높은 benchmark score를 가져와도 내 검색 시스템의 답은 되지 않는다.
이 논문의 한계
저자들이 부록에서 밝힌 한계도 분명하다.
- 18개 dataset이 모두 영어다.
- 대부분의 document는 평균 수백 단어 이내이며, long-document retrieval을 충분히 다루지 않는다.
- PageRank, 최신성, authority, click signal 같은 multi-factor search를 평가하지 않는다.
- 한두 개 text field 중심이라 복잡한 multi-field retrieval과 거리가 있다.
- 범용 일반화를 보는 benchmark이므로 특정 task에 최적화한 model의 가치를 대신 판단하지 않는다.
여기에 논문이 비교한 model과 hardware가 2021년 기준이라는 시간적 한계도 있다. 이 표를 현재 embedding model의 순위표로 사용하면 안 된다. 지금도 유효한 부분은 특정 model의 등수보다 다양한 target에서 baseline과 비용을 함께 재고, 평가 데이터의 생성 과정까지 검토하는 방법이다.
다음에 적용할 것
앞으로 retrieval 실험에서는 최소한 다음을 같이 남기려고 한다.
- query를 유형별로 나누고 각 유형의 정답 기준을 적는다.
- BM25와 단순한 exact search를 baseline으로 고정한다.
- retriever의
Recall@k와 최종 ranking의nDCG@10을 분리한다. - embedding model뿐 아니라 similarity, normalization, chunk 길이를 기록한다.
- latency, index size, reranking candidate 수를 품질 점수와 함께 비교한다.
- 새 retriever가 찾은 미판정 문서를 표본 검사해 qrels 편향을 확인한다.
BEIR를 읽고 얻은 답은 최고의 검색 model 이름이 아니었다. model 선택보다 먼저 실패를 드러내는 평가 환경을 만들어야 한다는 순서였다.
Reference
- Nandan Thakur, Nils Reimers, Andreas Rücklé, Abhishek Srivastava, Iryna Gurevych. BEIR 논문, NeurIPS Datasets and Benchmarks, 2021.
댓글