M3-Embedding 논문을 읽었다. 논문에서 모델은 M3-Embedding으로 표기하며, 공개 구현에서는 흔히 BGE-M3로 부른다.
처음에는 “Dense, Sparse, Multi-vector를 하나의 model로 모두 지원한다”는 기능 목록에 관심이 갔다. 읽고 나서는 기능의 개수보다 세 점수의 역할을 어떻게 나눴는지, 그리고 benchmark가 어떤 학습 데이터와 candidate budget에서 나온 결과인지가 더 중요하게 보였다.
특히 두 결과가 같이 남았다.
MIRACL에서는 Dense 69.2 > Sparse 53.9, 결합 70.4, 세 방식 결합 71.5
MLDR에서는 Sparse 62.2 > Dense 52.5, 결합 64.8, 세 방식 결합 65.0
같은 모델 안에서도 dataset이 바뀌면 Dense와 Sparse의 순서가 뒤집혔다. 결합은 두 dataset에서 모두 개별 방식보다 높았지만, 개선 폭과 계산 경로는 같지 않았다.
요약본
무엇을 만들었나
BGE-M3는 하나의 encoder에서 세 retrieval 기능을 제공하는 multilingual embedding model이다.
- Dense는 문장 또는 문서 전체를 하나의 vector로 표현한다.
- Sparse는 token별 중요도를 학습하고, query와 document에 같이 나타난 token의 weight로 점수를 계산한다.
- Multi-vector는 token vector를 보존하고 late interaction으로 세밀하게 비교한다.
100개가 넘는 언어와 최대 8,192 token 입력을 목표로 해 multilinguality, multi-functionality, multi-granularity의 세 M을 이름에 담았다.
어떻게 만들었나
XLM-RoBERTa 계열 encoder를 여러 단계로 pre-training·fine-tuning했다. dense, sparse, multi-vector 점수를 합친 값을 teacher signal로 사용하는 self-knowledge distillation을 적용했고, 길이가 비슷한 sample을 묶고 긴 batch를 다시 나눠 처리하는 batching으로 긴 입력 학습 비용을 줄였다.
왜 이렇게 만들었나
Dense는 semantic matching에 강하지만 exact term signal을 잃을 수 있다. Sparse는 lexical matching과 inverted index를 이용할 수 있지만 표현 차이에 약하다. Multi-vector는 token-level interaction이 세밀하지만 비싸다. 논문은 하나를 선택하기보다 한 encoder가 세 표현을 함께 학습하고 필요에 따라 결합하도록 만들었다.
결과는 무엇이었나
MIRACL에서는 Dense가 Sparse보다 높았고, MLDR long-document retrieval에서는 Sparse가 Dense보다 약 9.7점 높았다. 두 경우 모두 Dense+Sparse가 각 단일 방식보다 높았다. Multi-vector까지 사용한 All이 가장 높은 평균을 냈다.
하지만 이 결과를 “BGE-M3 Hybrid가 모든 검색의 정답”으로 읽으면 안 된다. MIRACL은 fine-tuning data에 포함됐고, MLDR은 논문이 만든 long-document data의 held-out test다. 결합 방식마다 후보 수와 reranking 비용도 다르다.
무엇이 하나의 모델 안에 들어갔나
Dense는 전체를 한 vector로 줄인다
query와 passage를 encoder에 넣은 뒤 [CLS] hidden state를 정규화해 각각 하나의 vector로 사용한다. 두 vector의 inner product가 Dense score다.
query → normalized CLS vector ┐
├─ inner product → dense score
passage → normalized CLS vector ┘
corpus document는 미리 vector로 만들 수 있어 approximate nearest neighbor index로 후보를 빠르게 찾을 수 있다. 대신 긴 문서의 여러 세부 사실을 하나의 vector에 압축해야 한다.
Sparse는 BM25가 아니다
논문의 lexical 또는 Sparse 기능은 각 token hidden state를 하나의 weight로 변환한다. 같은 token이 여러 번 나오면 최대 weight를 남기고, query와 passage에 함께 존재하는 token weight의 곱을 더해 점수를 만든다.
sparse score = Σ(query와 passage에 함께 있는 token의 query weight × passage weight)
겉으로는 inverted index를 사용할 수 있는 lexical retrieval이지만 BM25와 계산 방식이 다르다.
BM25 → term frequency, document frequency, document length를 수식으로 반영
M3 Sparse → neural encoder가 문맥에 따라 token weight를 학습
따라서 논문의 Sparse 62.2를 “BM25 62.2”로 읽으면 안 된다. learned sparse가 Dense보다 높았다는 결과다.
Multi-vector는 모든 문서를 처음부터 비교하지 않았다
Multi-vector는 query와 passage의 token embedding을 보존한다. 각 query token마다 가장 가까운 passage token을 찾고 그 점수를 합치는 ColBERT 계열 late interaction을 사용한다.
세밀하지만 corpus 전체에 바로 적용하기에는 비용이 크다. MIRACL 실험에서는 Dense가 찾은 상위 200개를 Multi-vector로 다시 정렬했다. 즉 Multi-vec 결과는 독립적인 1차 검색 index의 결과가 아니라 Dense candidate에 의존하는 reranking 결과다.
이 구분이 중요했다. 표에 Dense, Sparse, Multi-vec가 같은 열로 있어도 실제 실행 단계는 같지 않다.
어떻게 세 기능을 같이 학습했나
Self-knowledge distillation
dense, sparse, multi-vector는 같은 positive를 높이고 negative를 낮추도록 각각 InfoNCE loss를 가진다. 문제는 한 encoder를 공유하면서 서로 원하는 표현이 충돌할 수 있다는 점이다.
논문은 세 relevance score의 가중합을 teacher score로 만들었다. 이 통합 score의 확률 분포를 각 기능이 따라가도록 학습했다. 외부 Cross-Encoder teacher가 아니라 모델 자신의 서로 다른 retrieval 기능을 합친 신호를 teacher로 썼기 때문에 self-knowledge distillation이라고 부른다.
MIRACL ablation에서 distillation의 영향은 다음과 같았다.
| 방식 | distillation 없음 | distillation 사용 |
|---|---|---|
| Dense | 68.7 | 69.2 |
| Sparse | 36.7 | 53.9 |
| Multi-vector | 69.3 | 70.5 |
Sparse의 증가 폭이 가장 컸다. 하나의 모델에 head 세 개를 붙인 것만으로 같은 성능이 생긴 것이 아니라, 서로 다른 score를 teacher로 삼은 학습이 특히 Sparse 품질에 크게 관여했다.
긴 입력을 위한 batching
긴 sequence를 그대로 섞으면 padding과 activation memory가 커지고 batch size가 작아진다. 논문은 다음 방법을 조합했다.
- 길이가 비슷한 데이터를 같은 group에서 sampling한다.
- 긴 mini-batch를 sub-batch로 나눠 encoding한다.
- gradient checkpointing으로 중간 activation memory를 줄인다.
- 여러 GPU의 embedding을 공유해 in-batch negative 수를 늘린다.
논문의 설정에서 8,192 token 입력의 device당 최대 batch size는 split-batch 없이 6, 적용 후 130이었다. 이 수치는 해당 A800 환경과 구현의 결과다. 모든 환경에서 같은 처리량을 보장하는 수치는 아니지만, 긴 입력 지원이 positional length 하나를 늘리는 일로 끝나지 않는다는 점은 분명했다.
왜 세 방식을 결합했나
retrieval 단계의 통합 score는 다음 구조다.
final score
= w1 × dense score
+ w2 × sparse score
+ w3 × multi-vector score
weight는 downstream scenario에 따라 달라진다. 논문도 모든 dataset에 하나의 값을 사용하지 않았다.
MIRACL 실행 경로
Dense → top 1,000 from Faiss
Sparse → top 1,000 from Lucene
Dense+Sparse→ 두 후보 집합의 union을 1 대 0.3으로 재정렬
All → Dense top 200을 Dense, Sparse, Multi-vector 순서로 1 대 0.3 대 1로 재정렬
여기서 Dense+Sparse는 단일 retriever보다 후보 budget이 커질 수 있다. Dense 1,000개와 Sparse 1,000개의 union이기 때문이다. All은 Dense top 200만 Multi-vector로 다시 본다. 결과 차이는 score 결합뿐 아니라 candidate source와 candidate count의 차이도 포함한다.
“세 점수를 합쳤더니 71.5”라고만 적으면 실행 구조를 놓치게 된다.
결과를 어떻게 읽었나
MIRACL에서는 Dense가 중심이었다
MIRACL 개발셋의 평균 nDCG@10은 다음과 같다.
| 방식 | nDCG@10 |
|---|---|
| BM25, XLM-R tokenizer | 31.9 |
| M3 Sparse | 53.9 |
| M3 Dense | 69.2 |
| M3 Multi-vector | 70.5 |
| M3 Dense + Sparse | 70.4 |
| M3 All | 71.5 |
Dense가 Sparse보다 15.3점 높았다. Dense+Sparse는 Dense보다 1.2점, All은 Dense보다 2.3점 높았다. 결합은 좋아졌지만 이 dataset에서 중심 retriever는 Dense였다.
한국어만 보면 Dense 69.9, Sparse 61.5, Dense+Sparse 71.2, All 72.1이었다. 한국어에서도 결합이 높았지만 이 값 역시 사내 한국어 문서에 대한 zero-shot 결과가 아니다.
가장 중요한 조건은 학습 데이터다. 논문의 multilingual fine-tuning data에는 MIRACL과 Mr. TyDi가 포함됐다. 따라서 표 1의 MIRACL 결과를 “MIRACL을 보지 않은 모델의 일반화 성능”으로 해석할 수 없다. BEIR의 zero-shot 결과와 같은 종류의 증거가 아니다.
MLDR에서는 Sparse가 Dense보다 높았다
multilingual long-document retrieval dataset인 MLDR test 결과는 다음과 같다.
| 방식 | nDCG@10 |
|---|---|
| BM25, XLM-R tokenizer | 53.6 |
| M3 Dense | 52.5 |
| M3 Sparse | 62.2 |
| M3 Multi-vector | 57.6 |
| M3 Dense + Sparse | 64.8 |
| M3 All | 65.0 |
이 데이터에서는 Sparse가 Dense보다 9.7점 높았고, Dense+Sparse가 Sparse보다 2.6점 높았다. 긴 문서의 특정 term signal을 하나의 [CLS] vector보다 sparse token weight가 더 잘 보존했을 가능성을 생각할 수 있다.
하지만 MLDR도 사내 long-document 일반화의 증거로 바로 쓸 수 없다. 논문은 Wikipedia, Wudao, mC4의 긴 문서에서 학습·개발·시험 split을 직접 만들고, 같은 성격의 synthetic question data를 fine-tuning에 사용했다. held-out test이지만 unknown domain zero-shot 평가와는 다르다.
강한 BM25 analyzer를 넣으면 해석이 달라졌다
부록의 tokenizer 비교가 가장 인상적이었다.
| 방식 | MIRACL | MKQA | MLDR |
|---|---|---|---|
| BM25, XLM-R tokenizer | 31.9 | 39.9 | 53.6 |
| BM25, Lucene analyzer | 38.5 | 40.9 | 64.1 |
| M3 Sparse, XLM-R tokenizer | 53.9 | 45.3 | 62.2 |
MLDR에서 Lucene analyzer를 사용한 BM25는 64.1로 M3 Sparse 62.2보다 높았고, Dense+Sparse 64.8에 0.7점 차이까지 접근했다.
논문 본표의 BM25는 M3와 vocabulary와 latency 조건을 맞추기 위해 XLM-R tokenizer를 사용했다. 공정한 통제 실험이라는 이유는 이해된다. 그러나 실제 서비스를 고르는 사람에게는 잘 설정한 lexical baseline이 더 중요하다. main table의 BM25 한 줄만 보고 learned sparse의 우위를 일반화하면 안 된다.
이 결과로 내 생각이 바뀌었다.
BM25의
k1,b나 embedding model을 바꾸기 전에 tokenizer와 analyzer가 실제로 만든 term부터 확인해야 한다.
Cross-lingual에서는 Sparse의 역할이 작아졌다
MKQA는 여러 언어의 query로 영어 passage를 찾는 cross-lingual retrieval이다. 평균 Recall@100은 Dense 75.1, Sparse 45.3, Dense+Sparse 75.3, All 75.5였다.
query와 passage의 언어가 다르면 같은 token이 존재해야 점수를 얻는 Sparse 방식이 불리하다. 논문도 두 언어 사이에 공통 term이 적기 때문이라고 설명한다. 이 결과는 Sparse를 무조건 결합할 필요가 없다는 반례다.
그럼 어떤 경우에 쓰면 좋을까
BGE-M3가 좋은 후보가 되는 경우
- 같은 encoder로 Dense와 learned sparse를 함께 실험하고 싶을 때
- 여러 언어의 같은-language document search가 필요할 때
- 짧은 query부터 긴 document까지 하나의 model family로 다루고 싶을 때
- Dense와 Sparse의 candidate overlap과 결합 효과를 빠르게 비교할 때
- 상위 소수 후보에만 Multi-vector reranking을 적용할 때
- 별도 sparse model과 dense model을 각각 운영하기 전에 강한 통합 후보가 필요할 때
하나의 encoder가 세 출력을 제공하므로 모델 차이보다 retrieval function 차이에 집중하기 좋다. 사내 평가의 실험 후보로는 매력적이다.
먼저 다른 경로를 봐야 하는 경우
- 정확한 품번·LOT·W/O 조회에서는 exact field나 registry가 먼저다.
- query와 document 언어가 다른 검색에서는 Sparse overlap이 작아질 수 있어 Dense 중심 평가가 먼저다.
- CPU·memory·latency budget이 매우 작다면 Multi-vector와 8K encoding 비용을 감당할 이유를 먼저 증명해야 한다.
- corpus가 작고 lexical signal이 강하면 잘 설정한 BM25가 요구 품질을 이미 만족할 수 있다.
- 최신 재고·WIP·납기 계산에는 embedding보다 API·SQL이 맞다.
- 표의 row·column 관계가 핵심이면 text embedding 전에 구조화 parsing과 field search가 필요하다.
과연 이것이 정답일까
내 답은 강한 후보이지 정답은 아니다.
BGE-M3가 해결한 것은 “한 모델에서 여러 retrieval score를 만들 수 있는가”와 “그 기능들을 함께 학습하면 성능이 오르는가”이다. 사내 MES에서 어떤 경로가 이기는지는 답하지 않는다.
일반화를 막는 조건도 있다.
- MIRACL은 fine-tuning data에 포함됐다.
- MLDR은 논문이 구성한 long-document data와 가까운 조건에서 학습·평가됐다.
- Hybrid는 단일 retriever와 candidate budget이 같지 않을 수 있다.
- Multi-vector는 Dense top 200에 의존하는 reranker다.
- 최대 8,192 token 지원은 그 길이의 모든 정보를 손실 없이 검색한다는 뜻이 아니다.
- 100개 이상 언어 지원은 언어별 품질이 같다는 뜻이 아니며, 저자도 이를 limitation으로 적었다.
모델이 세 기능을 제공해도 exact lookup, metadata filter, access control, freshness, table structure는 따로 설계해야 한다.
이것보다 더 좋은 것은 무엇일까
하나의 모델 이름으로 답할 수 없었다. 실패 종류마다 더 나은 선택이 달라진다.
| 목표 | 먼저 비교할 대상 | 왜 더 나을 수 있나 |
|---|---|---|
| 식별자 exact hit | keyword field / registry | 한 글자 차이를 semantic similarity로 뭉개지 않는다. |
| 낮은 비용의 lexical search | 언어별 analyzer를 적용한 BM25 | model inference 없이 강한 baseline을 만들 수 있다. |
| domain 표현 차이 | 사내 relevance data로 학습한 Dense·Sparse | 공개 Wikipedia와 다른 업무 어휘를 직접 학습한다. |
| 후보 순서 개선 | Cross-Encoder reranker | candidate를 query와 함께 읽어 더 세밀하게 비교한다. |
| token-level matching | ColBERT 계열 late interaction | 하나의 [CLS]에 모두 압축하지 않는다. |
| fusion 안정성 | RRF 또는 validation으로 조정한 score fusion | score scale과 query 유형에 따른 가중치 문제를 줄일 수 있다. |
| 구조화·실시간 질문 | SQL / API / metric layer | 최신성과 정확한 field 조건을 문서 유사도에 맡기지 않는다. |
BGE-M3보다 무조건 좋은 방식 목록이 아니다. 사내 query 유형별로 실패를 더 직접 고치는 후보 목록이다.
예를 들어 Dense candidate Recall@100은 충분한데 top-10 순서만 나쁘다면 retriever를 바꾸기보다 Cross-Encoder가 맞을 수 있다. 반대로 정답이 candidate에 없으면 reranker가 아니라 Sparse나 다른 Dense candidate source를 추가해야 한다.
새로 배운 것
Sparse라는 이름만으로 BM25를 뜻하지 않는다
이 논문을 읽으며 가장 먼저 바로잡은 부분이다. M3 Sparse는 inverted index를 사용할 수 있지만 term weight는 neural model이 학습한다. BM25, learned sparse, exact lookup은 모두 term을 다뤄도 서로 다른 방식이다.
Hybrid 성능에는 candidate budget이 섞인다
Dense top 1,000과 Sparse top 1,000의 union을 재정렬하면 후보 수 자체가 늘 수 있다. 결합 점수의 효과와 candidate recall 증가를 나눠 보려면 같은 최종 candidate 수, union 크기, overlap을 같이 기록해야 한다.
긴 context 지원과 긴 문서 검색 품질은 다르다
8,192 token을 입력할 수 있어도 Dense는 전체를 하나의 vector로 압축한다. MLDR에서 Sparse가 Dense보다 높았다는 결과는 입력 가능 길이만 보고 long-document retrieval이 해결됐다고 말할 수 없음을 보여줬다.
Tokenizer도 retrieval model의 일부다
MLDR BM25가 tokenizer 변경만으로 53.6에서 64.1로 올라갔다. 한국어에서는 형태소 분석, compound 분해, user dictionary, 품번 보존 방식이 점수 함수만큼 중요할 수 있다. 앞으로 “BM25와 BGE-M3를 비교했다”가 아니라 analyzer와 field mapping까지 함께 적어야 한다.
Benchmark를 보기 전에 training data를 봐야 한다
MIRACL 69.2라는 점수만 보면 multilingual generalization처럼 보일 수 있다. training data 표를 보면 MIRACL 자체가 fine-tuning에 포함돼 있다. 모델 표의 숫자를 읽기 전에 train/dev/test의 관계부터 확인해야 한다.
느낀 점
BGE-M3의 가장 큰 장점은 높은 숫자보다 비교 가능한 세 retrieval 기능을 한 encoder에 넣었다는 점이라고 느꼈다. Dense와 Sparse를 별도 model로 구성하면 어느 차이가 architecture 때문이고 어느 차이가 training data 때문인지 분리하기 어렵다. 같은 backbone에서 세 score를 제공하면 적어도 실험 출발점은 단순해진다.
반대로 하나의 model이라는 표현이 운영까지 단순하게 만들어 주는 것은 아니다. Dense index와 sparse index가 따로 필요하고, Multi-vector reranking에는 token embedding과 추가 연산이 필요하다. candidate merge, score weight, top-N, latency budget도 정해야 한다. model artifact는 하나여도 retrieval system은 하나의 함수가 아니었다.
Sparse가 Dense보다 높았던 MLDR 결과도 인상적이었지만, 부록의 Lucene BM25 64.1을 보고 판단을 다시 멈췄다. 새로운 model이 강해 보여도 baseline의 tokenizer가 약하면 개선 폭을 과대평가할 수 있다. 논문 본표보다 부록이 실제 도입 판단에 더 중요했던 사례였다.
이 논문을 읽고 남은 질문은 “BGE-M3를 쓸까?”가 아니다.
우리 query에서 Dense만 찾은 정답, Sparse만 찾은 정답, exact lookup만 찾아야 하는 정답은 각각 무엇인가?
이 분해가 있어야 세 기능을 모두 켤 이유와 끌 이유를 설명할 수 있다.
이 논문의 한계
- MIRACL이 fine-tuning data에 포함돼 있어 해당 결과는 zero-shot 일반화 평가가 아니다.
- 저자들이 만든 MLDR와 synthetic long-document training data는 실제 기업 문서와 분포가 다를 수 있다.
- 언어별 학습 데이터가 불균형하며 100개 이상 언어의 품질 차이를 충분히 분석하지 않았다.
- 8,192 token 처리에는 큰 training·inference 비용이 붙고, 그보다 긴 문서는 별도 전략이 필요하다.
- Dense+Sparse와 단일 retriever의 candidate budget이 동일하지 않다.
- Multi-vector 결과는 Dense 후보 품질에 의존한다.
- benchmark는 access control, freshness, metadata filter, exact identifier 같은 운영 요구를 평가하지 않는다.
MES에 적용한다면 다음에 확인할 것
- Exact, analyzer를 적용한 BM25, M3 Sparse, M3 Dense를 각각 독립 baseline으로 만든다.
- 품번·메뉴·절차·장애 증상별로 각 retriever만 찾은 정답을 기록한다.
- Dense와 Sparse의 top-k overlap, union size,
Recall@k를 측정한다. - 같은 최종 candidate budget에서 score fusion과 rank fusion을 비교한다.
- Multi-vector는 Dense top-N을 바꾸며
nDCG@10증가와 p95 latency를 함께 잰다. - 8K 문서 전체 입력과 의미 단위 chunking을 같은 corpus에서 비교한다.
- 한국어 analyzer·사용자 사전·exact field를 고정하지 말고 실험 축으로 둔다.
- 공개 benchmark 결과와 사내 평가 결과를 별도 표로 관리한다.
BGE-M3는 Dense와 Sparse 중 하나를 고르라는 답 대신, 같은 query에서 세 관점을 비교할 수 있는 좋은 실험 도구를 제공했다. 채택 여부는 기능 수가 아니라 사내 실패 query를 실제로 줄였는지로 결정해야 한다.
Reference
- Jianlv Chen, Shitao Xiao, Peitian Zhang, Kun Luo, Defu Lian, Zheng Liu. M3-Embedding 논문. arXiv 2402.03216 v5, 2025.
댓글