임베딩 모델 선택과 평가 — Cosine·Recall@k·MRR·nDCG 실전 기준

RAG를 구축할 때 MTEB 순위가 높은 임베딩 모델을 선택했는데 실제 사내 문서 검색은 나아지지 않는 경우가 있습니다. 공개 벤치마크는 좋은 출발점이지만, 언어·문서 길이·도메인 용어·질의 형태·지연시간이 다른 환경의 결과까지 보장하지 않습니다.

임베딩 모델 선택은 후보 압축 → 도메인 평가 세트 → 검색 지표 → 비용·지연시간 → 운영 안정성 순서로 진행하는 것이 좋습니다. 벡터 차원이나 평균 점수 하나만 보고 결정하면 색인 비용은 늘고 관련 문서는 여전히 놓칠 수 있습니다.

핵심 요약

• 공개 리더보드는 후보를 줄이는 도구이며 최종 선택은 자체 질문·문서로 해야 합니다.
• 질의와 문서에 서로 다른 Prefix를 요구하는 모델은 인코딩 규칙을 정확히 지켜야 합니다.
• Recall@k는 후보 포함 여부, MRR은 첫 관련 문서 위치, nDCG는 등급별 관련도와 순서를 봅니다.
• Cosine·Dot Product는 모델 학습 방식과 정규화 설정에 맞춰 선택합니다.
• 품질과 함께 인코딩 속도, 벡터 크기, 색인 시간, P95 검색 지연을 측정합니다.

1. 먼저 사용 조건을 고정한다

조건확인 질문

언어	한국어 단일인가, 한영 혼합·다국어인가
문서	FAQ, 기술 문서, 코드, 표, 계약서 중 무엇인가
질의	짧은 키워드인가, 자연어 질문인가
규모	Chunk 수와 일일 갱신량은 얼마인가
인프라	CPU·GPU, 메모리, 허용 P95는 얼마인가
라이선스	상업 이용과 재배포 조건을 만족하는가

2. Cosine과 Dot Product

Cosine Similarity는 두 벡터의 방향 유사도를 보고 크기의 영향을 제거합니다.

cosine(a, b) = (a · b) / (||a|| × ||b||)

벡터를 L2 정규화하면 Dot Product와 Cosine의 순위가 같아질 수 있습니다. 그러나 모든 모델과 데이터베이스 설정이 자동 정규화를 수행하는 것은 아닙니다. 모델 카드의 권장 Similarity, 임베딩 생성 시 정규화, Vector DB의 거리 함수를 세 곳에서 일치시켜야 합니다.

Euclidean·Manhattan도 사용할 수 있지만, 어떤 거리를 쓰든 공개 점수보다 해당 모델이 어떤 목적 함수로 학습됐는지와 실제 검색 평가가 중요합니다.

3. 검색 지표를 해석하는 법

Recall@k

관련 문서가 상위 k개 후보 안에 얼마나 포함됐는지 봅니다. Reranker나 LLM에 넘길 후보를 만드는 단계에서는 가장 먼저 확인할 지표입니다.

MRR@k

각 질문에서 첫 번째 관련 문서 순위의 역수를 평균합니다. 정답 문서 하나를 빠르게 보여주는 FAQ·헬프센터에 유용합니다.

nDCG@k

관련도를 0·1만이 아니라 매우 관련·부분 관련처럼 여러 등급으로 라벨링하고, 관련 문서가 위에 배치될수록 높은 점수를 줍니다. 여러 근거 문서의 순서가 중요한 RAG에 적합합니다.

Precision@k

상위 k개 중 관련 문서의 비율입니다. LLM Context가 작아 불필요한 Chunk를 거의 넣을 수 없을 때 중요합니다.

4. 평가 세트 만드는 방법

1. 실제 검색 로그와 업무 담당자 질문에서 100~500개를 먼저 표본화합니다.
2. 짧은 키워드, 자연어 의역, 코드·버전, 다중 조건 질문으로 나눕니다.
3. 질문마다 관련 Chunk ID와 0~3 관련도 등급을 기록합니다.
4. 질문 작성자가 정답 문구를 그대로 복사하지 않도록 합니다.
5. 평가용과 튜닝용 질문을 분리해 과적합을 줄입니다.
6. 판정이 어려운 사례는 두 명 이상이 검토하고 불일치를 남깁니다.

Sentence Transformers의 InformationRetrievalEvaluator는 queries, corpus, relevant_docs를 받아 MRR, nDCG, Recall, Precision 등을 계산할 수 있습니다.

from sentence_transformers.evaluation import InformationRetrievalEvaluator

evaluator = InformationRetrievalEvaluator(
    queries=queries,
    corpus=corpus,
    relevant_docs=relevant_docs,
    mrr_at_k=[10],
    ndcg_at_k=[10],
    precision_recall_at_k=[5, 10, 20],
)
score = evaluator(model)

5. 품질 외에 기록할 비용

• 문서 1,000개와 질의 1개당 인코딩 시간
• 벡터 차원 × 원소 바이트 × 전체 Chunk 수의 원본 저장량
• ANN 인덱스 구축 시간과 추가 메모리
• 동시 질의에서 P50·P95 검색 지연시간
• GPU·CPU 사용률과 시간당 처리량
• 모델 로딩 시간, 최대 입력 길이, 배치 크기

차원이 큰 모델이 항상 더 정확하지는 않습니다. 품질 차이가 작다면 더 작은 벡터가 색인 메모리와 검색 지연, 백업 비용에서 유리할 수 있습니다.

6. 비교 실험에서 자주 틀리는 부분

• 모델별 권장 query/document Prefix를 빼먹음
• Chunking이나 Top-k를 동시에 바꿔 원인을 구분하지 못함
• 한 모델만 정규화하고 다른 모델은 원시 벡터를 사용함
• 공개 MTEB 평균을 한국어 사내 문서 성능으로 해석함
• 중복 Chunk를 그대로 두어 지표를 부풀림
• 색인 재구축과 모델 라이선스 비용을 누락함

7. 최종 선택표

항목가중치 예시측정값

Recall@20	35%	도메인 평가 세트
nDCG@10	25%	등급 라벨
P95 검색 지연	15%	목표 동시성
색인 크기	10%	실제 Chunk 규모 환산
다국어·긴 문서	10%	질문 유형별 점수
라이선스·운영성	5%	배포 조건

가중치는 예시입니다. 고객지원은 첫 정답 순위, 조사형 RAG는 Recall, 모바일 온디바이스는 크기와 지연시간에 더 큰 비중을 둘 수 있습니다.

공식 자료

• Sentence Transformers Similarity
• Information Retrieval Evaluator
• MTEB 공식 저장소

정리: 좋은 임베딩 모델은 리더보드 1위 모델이 아니라 우리 질문에서 관련 문서를 안정적으로 찾고, 허용 비용과 지연시간 안에서 운영되는 모델입니다. 모델·거리 함수·정규화·Prefix를 고정한 뒤 도메인 Recall과 nDCG로 결정하세요.