Field Log · Entry

Embedding Benchmark 읽는 법: MTEB부터 오염까지 (11/14)

MTEB와 다국어, zero-shot, reasoning, long-context benchmark를 목적별로 나누고 공개 점수에서 in-domain 평가로 좁혀 가는 구조

이번 글의 결론

Benchmark는 model의 보편적 지능을 재는 한 개의 자가 아니라, 특정 task·언어·corpus·metric을 묶은 측정 도구 모음입니다.

MTEB 평균, retrieval 평균, 한국어 retrieval, long-document retrieval은 서로 대체할 수 없습니다. 배포 조건과 가장 가까운 slice를 먼저 봅니다.

Leaderboard 점수에는 model뿐 아니라 prompt, pooling, dimension, quantization, task version, public test에 대한 반복 선택 효과가 들어갑니다.

Contamination은 exact duplicate만이 아닙니다. 같은 원천 문서, 번역본, template, synthetic teacher가 test의 의미를 미리 노출할 수 있습니다.

공개 benchmark로 shortlist를 만들고, 시간 분리된 비공개 in-domain set과 downstream RAG 평가로 최종 결정을 내려야 합니다.

앞 글에서 metric과 통계 규약을 만들었습니다. 이제 공개 benchmark를 무엇을 측정하는지, 무엇은 측정하지 않는지 읽는 법을 다룹니다.

1. Benchmark는 하나의 질문이 아니다

Model card의 average score만 보면 다음 차이가 사라집니다.

STS               두 문장의 유사도 순서를 맞추는가
classification    frozen vector에 class 정보가 있는가
clustering        label 없이 group structure가 나타나는가
retrieval         query로 relevant corpus item을 찾는가
reranking         주어진 후보의 순서를 고치는가
bitext mining     언어가 다른 대응 문장을 찾는가
instruction       task 지시를 반영해 geometry를 바꾸는가

실제 목표가 한국어 법률 RAG라면 영어 STS와 감정 분류의 gain이 평균을 올렸다는 사실은 약한 간접 증거일 뿐입니다.

2. 주요 Benchmark 지도

Benchmark	주로 답하는 질문	강점	그대로 일반화하면 안 되는 것
MTEB	여러 text embedding task에서 전반적으로 강한가	task type 통합·공통 평가	내 domain·latency·최신 data
MMTEB	매우 많은 언어와 task로 transfer되는가	500개 이상 task, 1,000개 이상 언어 범위	각 언어의 동일한 표본량·난이도
BEIR	학습하지 않은 heterogeneous retrieval로 이동하는가	18개 dataset의 zero-shot retrieval	multilingual·long document 전체
MIRACL	여러 언어의 passage retrieval이 되는가	18개 언어 monolingual retrieval	한국어의 모든 문체·domain
BRIGHT	surface match를 넘어 reasoning이 필요한가	1,398개 현실적·curated query	일반 traffic의 빈도·비용 구조
AIR-Bench	자동 구성된 다양한 IR task로 일반화하는가	heterogeneous·dynamic 구성 지향	synthetic query/qrel의 human equivalence
LongEmbed	긴 입력에서 흩어진 정보를 찾는가	2개 synthetic+4개 real-world task	context window 숫자만으로 품질 설명
ConTEB	chunk가 주변 context를 필요로 할 때 찾는가	context-aware retrieval 분리	독립 passage 검색 전체

이 표의 숫자와 범위는 각 benchmark 논문이 발표한 시점의 설명입니다. 이후 task 추가·수정으로 leaderboard 구성이 바뀔 수 있으므로 실행한 benchmark revision을 함께 저장합니다.

3. MTEB: 넓은 시작점

MTEB는 흩어져 있던 embedding 평가를 공통 interface와 여러 task type으로 묶었습니다. 장점은 model을 다음처럼 다면적으로 볼 수 있다는 점입니다.

model
  ├─ retrieval
  ├─ STS
  ├─ classification
  ├─ clustering
  ├─ pair classification
  ├─ reranking
  ├─ bitext mining
  └─ summarization-related similarity

그러나 MTEB average는 제품 목적 함수가 아닙니다.

task별 metric scale과 난이도가 다름
dataset 수가 많은 category가 평균에 더 큰 영향을 줄 수 있음
영어·다국어·code leaderboard의 범위가 다름
model별 instruction과 output dimension 조건이 다를 수 있음
public benchmark에 맞춘 model 선택이 누적됨

따라서 최소한 전체 평균 → task category → dataset → query slice 순으로 내려갑니다.

4. MMTEB: 언어 수와 언어별 증거는 다르다

ICLR 2025의 MMTEB는 MTEB를 500개가 넘는 quality-controlled task와 1,000개가 넘는 언어 범위로 확장했습니다. 저자들은 계산 비용을 낮추면서 model ordering을 보존하기 위한 task downsampling과 retrieval hard-negative sampling도 다뤘습니다.

큰 coverage는 중요한 진전이지만 다음 문장은 서로 다릅니다.

"1,000+ languages are represented"
≠ "all languages have equally deep retrieval evaluation"
≠ "Korean domain retrieval is solved"

한국어 model을 고를 때는 다음을 별도로 냅니다.

Slice	예시
Native Korean	원래 한국어로 작성된 query·document
Translated Korean	번역 benchmark
Cross-lingual	한국어 query → 영어 document
Mixed script	한글+영문 product·API·법령 번호
Domain	법률·의료·commerce·사내 약어
Length	짧은 FAQ·긴 규정·표가 포함된 문서

번역 dataset만으로 native 표현과 조사 생략, 높임말, 외래어 표기의 실패를 추론하지 않습니다.

5. BEIR: Zero-shot Retrieval의 고전적 기준

BEIR는 서로 다른 domain·query style·corpus를 모아, 한 retrieval model이 학습 domain 밖에서도 작동하는지 평가했습니다. Dense model만이 아니라 BM25와 reranker를 포함한 retrieval system 비교에도 널리 쓰입니다.

읽을 때 확인할 것:

dense-only인지, BM25+dense fusion인지
first-stage retrieval인지 reranked result인지
title과 body를 어떻게 이어 붙였는지
query/document prefix를 사용했는지
nDCG@10 외 Recall@100도 보고했는지
supervised training source가 평가 corpus와 겹치는지

같은 BEIR average라도 preprocessing과 system boundary가 다르면 model-only 비교가 아닙니다.

6. MIRACL: Multilingual Retrieval을 좁혀 본다

MIRACL은 18개 언어의 monolingual retrieval dataset을 제공했습니다. 다국어 평균과 언어별 점수를 모두 볼 수 있다는 장점이 있습니다.

하지만 macro average는 traffic distribution과 다릅니다.

research macro:
  score = mean(score_language)

production weighted:
  score = Σ traffic_share_language × utility_language

저자원 언어를 동일 가중하는 연구 목적과, 실제 요청 비율을 가중하는 운영 목적을 둘 다 보고하면 평균 하나가 숨기는 trade-off가 드러납니다.

7. BRIGHT: Reasoning-intensive Retrieval

ICLR 2025의 BRIGHT는 economics, psychology, mathematics, coding 등에서 문서 relevance를 판단하려면 query의 조건과 논리를 해석해야 하는 1,398개 query를 구성했습니다. 논문은 당시 MTEB 선두 model의 점수가 BRIGHT에서는 크게 낮아졌고, query reasoning을 추가하면 개선될 수 있다고 보고했습니다.

여기서 얻을 결론은 “모든 검색 전에 LLM reasoning을 생성하라”가 아닙니다.

BRIGHT가 검증하는 것:
  surface similarity가 부족한 hard-query capability

추가로 검증해야 하는 것:
  일반 traffic 비율, hallucinated expansion, latency, cost

Easy factual query와 hard compositional query를 분리해 reasoning route의 효과를 측정합니다.

8. AIR-Bench: 자동화와 Dynamic Evaluation

AIR-Bench는 다양한 domain과 task의 retrieval benchmark를 자동으로 생성하는 framework를 제안했습니다. 논문이 강조한 방향은 heterogeneous, domain-specialized, dynamic evaluation입니다.

자동 생성은 coverage와 갱신 속도를 높이지만 새로운 검증 층이 필요합니다.

query가 실제 user intent처럼 자연스러운가
positive가 query를 충분히 답하는가
hard negative가 실제로 negative인가
generator 표현 습관을 model이 shortcut으로 쓰지 않는가
judge model과 embedding model의 계보가 가까운가
synthetic와 human-authored subset의 순위가 일치하는가

Synthetic benchmark는 나쁘다는 뜻이 아니라 synthetic provenance를 metric의 일부로 기록해야 한다는 뜻입니다.

9. LongEmbed와 ConTEB: 길이와 문맥을 분리한다

LongEmbed는 두 synthetic task와 네 real-world task로, 길이가 달라지고 target information이 흩어진 retrieval을 평가했습니다. ConTEB는 chunk 자체만으로는 모호하고 주변 문맥이 있어야 의미가 정해지는 retrieval을 겨냥합니다.

두 failure는 같지 않습니다.

long-input failure:
  relevant token이 멀리 있어 pooling에서 희석됨

context-dependence failure:
  chunk 안 정보만으로 무엇을 가리키는지 결정 불가

32K tokens supported라는 model card 문구는 tokenizer가 입력을 받는다는 뜻이지, 긴 문서의 모든 위치에서 retrieval quality가 유지된다는 보장이 아닙니다.

10. Aggregate Score가 만드는 착시

Micro와 Macro

macro = task별 score를 같은 가중치로 평균
micro = 모든 example을 합쳐 계산하거나 sample 수로 가중

둘은 “큰 dataset을 더 중요하게 볼지”에 대해 다른 답을 냅니다.

Category Mix

Retrieval 제품이 classification·STS까지 포함한 전체 평균으로 model을 고르면 목적과 가중치가 어긋납니다.

Ceiling와 Variance

이미 모든 model이 비슷한 easy task는 평균에는 들어가지만 구분력은 작습니다. 반대로 query 수가 작은 hard task의 큰 차이는 confidence interval이 넓을 수 있습니다.

Missing Result

일부 model이 context length, modality, API 제한 때문에 특정 task를 실행하지 못했을 때 평균에서 제외하는 규약이 순위를 바꿀 수 있습니다.

11. Instruction과 Prompt도 평가 대상이다

Instruction-tuned embedding은 task prompt에 따라 공간이 달라집니다.

query prompt A: "Represent this sentence for searching relevant passages:"
query prompt B: "Represent the Korean legal question for retrieving controlling clauses:"

공정성에는 두 관점이 있습니다.

Protocol	장점	단점
공식 recommended prompt	각 model의 최선 사용법	prompt engineering 양이 다름
공통 prompt	input text 통제	model별 training contract 위반 가능
prompt sweep	sensitivity 확인	test tuning 위험·비용 증가

권장 보고는 공식 prompt를 primary로, 사전에 고정한 작은 dev set의 prompt sensitivity를 secondary로 두는 방식입니다. Test set을 보며 prompt를 고르지 않습니다.

12. Contamination의 네 단계

1) Exact Contamination

Train에 test query/document pair가 그대로 들어갑니다. Hash·normalized exact match로 일부를 찾을 수 있습니다.

2) Source Contamination

문자열은 달라도 같은 Wikipedia revision, QA source, forum thread, product catalog에서 파생됐습니다.

3) Semantic·Translation Contamination

Paraphrase나 번역본, 같은 답을 묻는 변형 query가 train에 있습니다. Embedding nearest-neighbor와 entity·answer overlap audit가 필요합니다.

4) Process Contamination

Public test 결과를 반복 확인하며 checkpoint, prompt, data mix를 선택합니다. Test row가 직접 train에 없어도 leaderboard에 대한 반복 적응으로 generalization estimate가 낙관적이 됩니다.

clean test data alone
  does not guarantee
clean model-selection process

13. Synthetic Teacher가 만드는 계보 문제

LLM이 query와 positive를 생성하고 또 다른 LLM이 relevance를 relabel하는 학습법이 흔해졌습니다. 평가 dataset도 유사한 generator family로 만들어졌다면 표현 선호가 맞아떨어질 수 있습니다.

Audit 질문:

Train generator와 eval generator는 무엇인가?
Prompt template과 seed가 공개됐는가?
원천 corpus snapshot이 겹치는가?
Human-authored query subset에서도 gain이 유지되는가?
다른 judge family로 qrel을 재검증했는가?

Teacher 계보가 같다는 사실만으로 contamination이라고 단정할 수는 없지만, 독립성에 대한 위험 신호로 기록합니다.

14. Version Drift와 재현성

Leaderboard는 살아 있는 software와 dataset 위에 있습니다.

task가 supersede되거나 수정됨
corpus·qrel 오류가 고쳐짐
metric implementation이 바뀜
model revision이 같은 이름 아래 갱신됨
remote-code dependency가 달라짐
API model이 server-side update됨

따라서 점수 행에는 다음 identity가 필요합니다.

benchmark_run:
  benchmark: mteb
  package_version: "pinned"
  task_names: ["..."]
  task_revisions: {task_a: "..."}
  model_id: "org/model"
  model_revision: "commit-or-version"
  trust_remote_code_revision: "..."
  prompts_sha256: "..."
  output_dimension: 768
  normalize: true
  precision: float32
  code_commit: "..."
  run_date: 2026-07-20

API model이 revision을 제공하지 않으면 날짜·region·request parameter와 raw output checksum sample을 남깁니다.

15. Benchmark Card Template

benchmark_card:
  purpose: "Korean policy RAG candidate model selection"
  task_type: retrieval
  languages: [ko, en, ko-en]
  corpus:
    source: internal-policy
    snapshot: 2026-07-01
    unit: heading-aware-chunk
    hidden: true
  queries:
    origin: anonymized-human-traffic
    temporal_split: "after training cutoff"
    count: 2400
  qrels:
    scale: [0, 1, 2, 3]
    annotators_per_query: 2
    adjudication: true
  metrics:
    primary: recall_at_50
    secondary: [ndcg_at_10, mrr_at_10, complete_evidence_at_50]
  slices: [language, length, query_type, policy_version, negation]
  contamination_audit:
    exact: true
    source: true
    semantic_sample: true
  statistics:
    paired_bootstrap: 10000
  frozen_until: 2026-10-01

이 card는 dataset 설명뿐 아니라 어떤 선택을 위해 어떤 통계로 쓰는지까지 포함합니다.

16. 공개와 비공개 평가를 두 층으로 운영한다

public suite
  → broad transfer·regression·논문 비교
  → 3–5개 shortlist

private in-domain suite
  → 한국어·시간 분리·실제 corpus·critical slice
  → 1–2개 finalist

shadow / online
  → latency·cost·downstream utility·feedback
  → release decision

Private set도 영원히 깨끗하지 않습니다. 팀이 결과를 반복 보며 개선하면 사실상 dev set이 됩니다. 주기적으로 새로운 temporal holdout을 만들고 기존 set은 regression suite로 이동합니다.

17. Leaderboard를 읽는 순서

내가 필요한 task·언어·modality row만 고릅니다.
Model size가 아니라 실제 encoder memory와 license를 확인합니다.
Prompt·pooling·dimension·quantization 조건을 맞춥니다.
Missing task와 aggregate 규약을 확인합니다.
Training data·synthetic teacher·benchmark overlap disclosure를 읽습니다.
Exact evaluation인지 ANN system인지 구분합니다.
같은 hardware에서 throughput·latency를 다시 잽니다.
비공개 in-domain set으로 후보를 재순위화합니다.

18. 실패 사례

전체 평균 1위만 도입

한국어 retrieval row와 vector dimension이 열세인데 classification 평균이 순위를 끌어올렸을 수 있습니다.

Test를 Prompt Dev로 사용

Leaderboard를 보며 instruction을 반복 수정하면 최종 score는 unbiased test가 아닙니다.

Benchmark Corpus를 그대로 Negative Mining

평가 corpus의 unlabeled document라도 query와 결합해 hard negative를 만들면 test structure가 학습에 들어갈 수 있습니다.

API 이름만 기록

Silent update 뒤 같은 실험을 재현할 수 없습니다.

ANN 설정이 다른 결과 비교

한 model은 exact, 다른 model은 aggressive quantized ANN이면 representation 비교가 아닙니다.

19. 연구 Report 최소 표

항목	Baseline	Challenger
Model revision	고정	고정
Prompt/pooling	기록	기록
Dimension/dtype	768/fp32	768/fp32
Public retrieval suite	score+CI	score+CI
Korean in-domain	score+CI	score+CI
Long/context slice	score+CI	score+CI
Exact Recall@50	값	값
ANN Recall@50	값	값
p95 latency/QPS	값	값
Downstream answer utility	값	값
Contamination note	공개	공개

“점수가 더 높다”가 아니라 같은 조건에서 어느 slice가 얼마나 변했고 비용은 얼마인가를 보여 줍니다.

20. Checklist

스스로 확인하기

MTEB 전체 평균이 retrieval 제품의 목적 함수가 될 수 없는 이유는 무엇인가?
MMTEB가 1,000개 이상 언어를 포함한다는 사실이 한국어 domain 성능을 보장하지 않는 이유는 무엇인가?
Exact duplicate가 없어도 process contamination이 생기는 과정은 무엇인가?
LongEmbed failure와 context-dependent chunk failure는 어떻게 다른가?
Private test set이 시간이 지나 dev set처럼 변하는 이유와 대응 방법은 무엇인가?

다음 글에서는 Matryoshka dimension, quantization, HNSW·IVF·DiskANN을 한 Pareto frontier에서 평가하고 안전한 re-index 전략을 만듭니다.