MTEB 리더보드 1위 모델을 골랐는데도 실제 검색 품질이 기대에 한참 못 미친 경험, 혹시 있으신가요? 저도 처음 RAG 파이프라인을 구축할 때 같은 실수를 했습니다. 임베딩 모델은 벤치마크 순위가 전부가 아니라 서비스 데이터와 검색 패턴에 맞는 선택이 훨씬 중요합니다. 이 글에서는 MTEB 벤치마크를 어떻게 읽어야 하는지, 그리고 실제 모델들 사이에서 어떤 기준으로 골라야 하는지를 경험을 섞어 풀어드립니다.
MTEB 벤치마크, 평균 점수만 보면 반드시 실패합니다
임베딩 모델의 성능을 비교할 때 업계 표준으로 쓰이는 도구는 MTEB(Massive Text Embedding Benchmark)입니다. 여기서 MTEB란 분류, 군집화, 검색, 재순위화 등 56개 이상의 NLP 태스크를 한꺼번에 돌려서 모델의 전반적인 표현 능력을 수치화하는 종합 평가 프레임워크를 의미합니다(출처: Hugging Face MTEB Leaderboard).
처음에 저도 리더보드의 'Average' 열만 보고 모델을 골랐습니다. 그런데 막상 내부 기술 문서 검색에 붙여보니 체감 품질이 생각보다 훨씬 떨어지더군요. 나중에 알고 보니 그 모델은 STS(의미적 유사도) 항목에서 두각을 나타낸 모델이었고, 실제 검색 품질을 결정하는 Retrieval 항목의 NDCG@10 점수는 중위권에 머물러 있었습니다. 여기서 NDCG@10이란 상위 10개 검색 결과 안에 얼마나 적절한 문서가 잘 배치되어 있는지를 측정하는 지표로, 숫자가 높을수록 사용자가 원하는 답이 앞에 뜬다는 의미입니다.
RAG나 엔터프라이즈 검색 엔진을 만드는 목적이라면 MTEB에서 봐야 할 항목은 명확합니다. Retrieval 점수가 1순위, 그다음이 Reranking 점수입니다. 나머지 분류나 군집화 점수가 높다고 해서 검색이 잘 된다는 보장은 없습니다. 저는 이 사실을 실패를 통해 배웠는데, 이 글을 읽는 분들은 그 과정을 건너뛰셨으면 합니다.
그렇다고 Retrieval 점수가 가장 높은 모델을 무조건 선택하는 것도 맞지 않는다고 생각합니다. MTEB의 평가 데이터셋 자체가 영어 중심으로 구성되어 있어서, 한국어 서비스에 그대로 적용하면 벤치마크와 실제 서비스 품질 사이에 꽤 큰 괴리가 생길 수 있습니다. 한국어 특화 평가가 별도로 필요한 이유가 여기 있습니다.
- MTEB Average 점수: 모델의 범용 표현 능력을 보여주지만, 검색 품질과 직결되지 않는 경우가 많습니다
- Retrieval NDCG@10: 실제 검색 엔진 품질과 가장 직접적으로 연결되는 핵심 지표입니다
- Reranking MAP: 후보 문서를 얼마나 올바른 순서로 재배열하는지 측정하며, 2단계 검색 구조에서 중요합니다
- 한국어 서비스라면 MTEB 점수 외에 반드시 자체 한국어 데이터셋으로 별도 검증이 필요합니다
모델 선택과 하이브리드 검색, 이 두 가지를 동시에 잡아야 합니다
모델 선택 기준을 두고 의견이 엇갈리는 편입니다. OpenAI의 text-embedding-3-large를 쓰면 된다고 보는 분들도 있는데, 저는 상황에 따라 오픈소스 모델이 훨씬 유리하다고 생각합니다. 특히 온프레미스 환경이나 개인정보가 포함된 데이터를 다루는 경우라면 외부 API로 데이터를 내보내는 순간 보안 규제에 걸릴 수 있습니다.
제가 직접 써봤는데, BAAI에서 공개한 BGE-M3는 솔직히 예상 밖이었습니다. 오픈소스인데도 한국어, 영어, 중국어를 포함한 100개 이상의 언어에서 준수한 성능을 내고, 무엇보다 단일 모델 안에서 밀집 검색(Dense Retrieval)과 희소 검색(Sparse Retrieval)을 동시에 처리할 수 있습니다. 여기서 밀집 검색이란 텍스트 전체의 의미를 압축한 벡터로 유사도를 비교하는 방식이고, 희소 검색은 BM25처럼 단어 빈도를 기반으로 매칭하는 방식입니다. BGE-M3는 이 두 가지를 하나의 모델에서 모두 뽑아낼 수 있습니다(출처: BAAI FlagEmbedding GitHub).
Cohere Embed v3 Multilingual과 Multilingual-E5-Large-Instruct를 써보면서 또 하나 배운 것이 있습니다. 비대칭 검색(Asymmetric Retrieval) 환경에서 입력 타입을 구분하지 않으면 벡터 공간이 왜곡된다는 점입니다. 비대칭 검색이란 짧은 사용자 질문으로 긴 문서를 찾아야 하는 상황을 말합니다. 예를 들어 "로그인 토큰 만료 시간 설정 방법"이라는 두 줄짜리 질문으로 수십 페이지짜리 아키텍처 문서를 찾아야 하는 경우입니다. 이럴 때 쿼리와 문서에 각각 다른 프리픽스 프롬프트를 붙여주지 않으면 실제로 유사도가 뒤틀립니다. 제 경험상 이건 설정 하나 차이인데 결과 품질 차이는 상당히 큽니다.
그리고 모델을 잘 골랐다 해도 하이브리드 검색(Hybrid Search) 파이프라인을 빠뜨리면 반드시 구멍이 생깁니다. 밀집 임베딩 벡터는 문맥 이해에서 강하지만, 에러 코드나 제품 일련번호처럼 정확한 문자열 매칭이 필요한 케이스에서는 BM25 키워드 검색보다 약합니다. 저는 이 문제를 처음 만났을 때 꽤 당황했습니다. 사용자가 특정 에러 코드를 그대로 붙여넣고 검색했는데 관련 문서가 상위에 안 뜨는 상황이었습니다. BM25와 Dense Vector를 RRF(Reciprocal Rank Fusion) 방식으로 결합하고 나서야 해결됐습니다. RRF란 각기 다른 검색 방식의 순위를 하나로 합산해서 최종 순위를 재조합하는 앙상블 기법입니다.
마지막으로 리랭커(Cross-Encoder Reranker) 도입을 권장하는 시각도 있는데, 개인적으로는 이게 선택이 아니라 필수에 가깝다고 봅니다. 1차 벡터 검색으로 상위 50~100개를 빠르게 추려낸 뒤, BGE-Reranker 같은 교차 인코더 모델로 질의와 문서를 동시에 정밀 분석해서 최종 3~5개만 LLM에 넘기는 구조가 실제로 응답 정확도를 가장 크게 끌어올렸습니다.
자주 묻는 질문
Q. MTEB 리더보드 1위 모델을 쓰면 무조건 검색 품질이 좋아지나요?
A. 그렇지 않습니다. MTEB 종합 1위 모델이라도 Retrieval 항목의 NDCG@10 점수가 낮으면 실제 검색 체감 품질은 기대에 못 미칩니다. 특히 한국어 서비스라면 MTEB 점수 자체가 한국어 환경을 충분히 반영하지 못하므로, 자체 데이터셋으로 A/B 검증을 별도로 거치는 것을 권장합니다.
Q. OpenAI 임베딩 API 대신 BGE-M3 같은 오픈소스를 써야 하는 상황이 있나요?
A. 개인정보나 사내 기밀 문서를 다루는 온프레미스 환경이라면 외부 API로 텍스트를 전송하는 것 자체가 보안 이슈가 될 수 있습니다. BGE-M3는 Apache 2.0 라이선스의 오픈소스 모델로, GPU 서버에 올려두면 외부 전송 없이 임베딩 처리가 가능합니다. 다만 GPU 인프라 운영 비용과 관리 부담은 별도로 고려해야 합니다.
Q. 하이브리드 검색을 꼭 써야 하나요? 벡터 검색만으로는 부족한가요?
A. 벡터 검색만으로도 많은 경우 잘 작동하지만, 에러 코드·제품 모델명·정확한 수치처럼 완전 일치가 중요한 쿼리에서는 Dense 벡터 검색이 BM25보다 취약합니다. BM25와 Dense Vector를 RRF로 결합하는 하이브리드 검색이 이 맹점을 메워주기 때문에, 다양한 유형의 쿼리를 받는 서비스라면 사실상 필수에 가깝습니다.
Q. 리랭커를 추가하면 검색 속도가 너무 느려지지 않나요?
A. 리랭커는 1차 벡터 검색에서 추려진 상위 50~100개 문서에만 적용하기 때문에 전체 문서에 돌리는 것과는 차원이 다릅니다. 대부분의 실서비스에서는 이 정도 문서 수라면 리랭킹 추가 지연이 수백 밀리초 수준에 그칩니다. 품질 향상 폭에 비하면 감수할 만한 레이턴시라고 봅니다.
결론
임베딩 모델 하나를 잘 고르는 것보다, 모델 선택 → 하이브리드 검색 파이프라인 → 리랭커까지 이어지는 전체 아키텍처를 제대로 설계하는 것이 시맨틱 검색 품질을 좌우합니다. 저는 이 세 단계를 순서대로 갖추고 나서야 사용자 피드백이 확실히 달라지는 걸 느꼈습니다.
첫 번째로 할 일은 MTEB 리더보드에서 Retrieval NDCG@10 점수를 기준으로 후보군을 좁히는 것입니다. 그 다음에는 자사 서비스의 도메인 데이터로 소규모라도 직접 A/B 테스트를 돌려보는 것이 가장 정확한 판단 근거가 됩니다. 벤치마크는 출발점일 뿐이고, 실제 데이터로 검증한 결과가 가장 믿을 만합니다.
참고: 출처: Hugging Face MTEB Leaderboard / 출처: BAAI FlagEmbedding GitHub
'엔터프라이즈 AI 시스템 아키텍처 및 LLM 평가 실무' 카테고리의 다른 글
| RAG 청킹 전략 (청크 크기, 검색 정확도, Parent-Child) (0) | 2026.08.17 |
|---|
