문서 QA용 임베딩 모델, 뭘 기준으로 골라야 하나?

결론부터: 벤치마크 점수 하나로 고르면 안 된다. 검색 품질(Recall@K, NDCG@10)과 운영 비용(지연시간, 토큰당 단가)을 같이 봐야 하고, 최종 판단은 내 문서로 만든 골든셋에서 나와야 한다. 2026년 기준 공개 leaderboard 수치는 출발점일 뿐, 코퍼스가 다르면 순위가 뒤집힌다.

  • 임베딩 모델 비교는 Recall@10, MRR, NDCG@10, p95 latency, 비용/백만 토큰을 함께 본다 futureagi
  • Recall@50로 후보를 넓게 고르고 reranker 이후 NDCG@10/Recall@10으로 최종 선택하는 흐름이 실무적으로 쓰인다
  • 자체 데이터 200~500개 query-document pair, hard negative 포함해서 평가해야 모델 차이가 드러난다 openlayer
  • 벤치마크 1위 점수의 모델이라도 latency 예산을 못 맞추면 실사용에서는 탈락 후보가 된다
  • 문서 유형(코퍼스)이 바뀌면 같은 모델도 성능이 크게 흔들린다

흔한 함정은 이거다. MTEB나 리더보드 상위 모델을 보고 "이게 점수가 제일 높으니 이걸로 붙이자"고 바로 결정하는 것. 실제로는 그 점수가 나온 벤치마크 조건(코퍼스, 언어, chunk 크기)이 내 서비스와 다르면 큰 의미가 없다. 2026년 clinical retrieval 벤치마크는 임베딩 모델 10개와 BM25를 포함해 13개 설정을 3개 의료 코퍼스에서, 294개 실험 조건으로 비교했는데, 모델 차이보다 코퍼스 특성·세팅 차이가 성능에 더 크게 작용했다는 결과가 나왔다 JMIR. "모델 A가 좋다"보다 "내 문서 유형에서 어떤 조건일 때 강한가"를 따져야 하는 이유다.

벤치마크 점수가 높은 모델을 그대로 붙이면 왜 느려지나?

점수가 높다고 서비스에 맞는 선택인 건 아니다. Google Embeddings 2(GE2)는 4개 공개/사내 과제에서 BEIR avg nDCG@10 0.638, IT-RAG-Bench nDCG@10 0.282로 가장 높은 점수를 냈지만, median latency가 231.6ms로 가장 빠른 로컬 모델보다 약 14배 느렸다 arXiv. 같은 연구에서 mE5-large는 이탈리아 RAG 과제에서 GE2와 nDCG 차이가 0.003 이내였는데 응답 속도는 31ms로 sub-100ms SLA에 훨씬 적합했다. 응답 지연 목표가 명확한 서비스라면, 점수 손실을 조금 감수하고 저지연 모델을 고르는 게 합리적일 수 있다.

다국어·장문 문서라면 뭘 더 확인해야 하나?

언어 범위와 최대 토큰 길이가 갈림길이 된다. 2026년 공개 leaderboard 요약에서 Qwen3-Embedding-8B는 전체 점수 70.6, retrieval 57.8로 정리됐고, Voyage-3는 retrieval 56.2, text-embedding-3-large는 retrieval 55.4로 소개됐다 ailog. multilingual 쪽에서는 Gemini Embedding 001의 XOR-Retrieve가 90.42로 cross-lingual retrieval 강점이 부각됐다 airbyte. 장문 문서를 다룬다면 최대 토큰 길이도 봐야 하는데, Qwen3-Embedding-8B는 32,768토큰, Voyage-3-large는 32,000토큰까지 지원하는 반면 text-embedding-3-large는 8,191토큰으로 상대적으로 짧다 aipromptshub. 다만 긴 context window가 있어도 chunking·rerank 설계가 같이 안 되면 그 장점이 그대로 검색 품질로 이어지지는 않는다.

벡터 차원이 클수록 무조건 유리한가?

아니다. 차원이 클수록 정확도가 오를 여지는 있지만 저장소·인덱스 비용도 같이 늘어난다. text-embedding-3-large는 3072차원, Voyage 계열 일부는 1536~2048차원, Qwen3-Embedding-8B는 4096차원으로 정리되는데, 이 차이가 그대로 운영비 차이로 이어진다. 정확도 우선이면 고차원, 비용·지연 우선이면 차원 압축이나 더 작은 모델을 쓰는 식으로 목적별로 나눠서 판단하는 게 낫다.

오해 바로잡기: 리더보드 순위가 곧 내 서비스 순위다?

아니다. 이게 이 글에서 가장 강조하고 싶은 지점이다. 공개 벤치마크는 특정 코퍼스, 특정 언어, 특정 query 길이 조건에서 나온 결과다. 실제로 2026년 웹 검색 벤치마크 Q2D-Web은 190M개 웹 문서와 69,721개의 agent-reformulated 쿼리, 10개 언어를 포함해 만들어졌는데, 여기서 pplx-embed-v1-4b가 Combined Recall@1000 69.11을 기록했다 alphasignal. 이건 사용자 원문 질의보다 재작성된 검색 질의가 성능에 더 크게 작용할 수 있다는 걸 보여준다. 벤치마크 점수는 "이 조건에서는 이랬다"는 참고치이지, 내 문서 QA 시스템에서의 결과를 보장하지 않는다.

운영·비용은 실제로 뭘 재야 하나?

API 단가만 보고 결정하면 나중에 놀란다. 2026년 요약 기준 voyage-3-large는 약 $0.18/1M tokens, text-embedding-3-large는 약 $0.13/1M tokens, Cohere Embed v4는 약 $0.10/1M tokens로 정리된다 ailog. Qwen3-Embedding-8B는 오픈소스라 API 비용은 표기상 없지만, 실제로는 GPU·서빙 인프라 비용이 별도로 든다. self-hosting을 고려한다면 추론 비용, 서빙 지연, 운영 인건비까지 합쳐서 비교해야 API 단가 비교보다 현실적인 그림이 나온다. 결정 전에는 자체 골든셋(200~500개 query-document pair, hard negative 포함)으로 동일한 파이프라인에서 k=1, 5, 10 cutoff로 Recall/NDCG를 재고, 그 옆에 latency와 토큰당 비용을 나란히 기록해두는 게 실무적으로 가장 안전하다.

핵심 정리

  • 임베딩 모델 선택은 검색 품질(Recall@K, NDCG@10)과 운영 비용(latency, 토큰당 단가)을 같이 봐야 판단이 선다
  • 리더보드 점수는 특정 코퍼스·언어 조건의 결과이지, 내 문서 QA 성능을 보장하지 않는다
  • 다국어·장문 문서는 언어 범위와 최대 토큰 길이를 따로 확인해야 하고, chunking·rerank 설계가 같이 필요하다
  • API 단가만 비교하지 말고 self-hosting 시 GPU·서빙 비용까지 포함해 계산해야 한다
  • 최종 결정은 자체 골든셋 + 동일 평가 파이프라인 + 비용/지연 로그로 확인한 뒤 내려야 한다