임베딩 모델 고르는 법: 평가와 트레이드오프

임베딩 모델 고르는 법: 평가와 트레이드오프 (How to Choose an Embedding Model: Evaluation & Tradeoffs)

벡터 검색의 세계에 막 발을 들인 초보든, 오랫동안 일해 온 베테랑이든, 최고의 검색 품질을 얻으려면 어떤 임베딩 모델을 골라야 하는지 고민해 본 적이 있을 거예요. MTEB 같은 공개 벤치마크가 후보를 좁히는 데 도움을 주지만, 그 벤치마크에 쓰인 데이터셋이 여러분의 도메인 특화 데이터를 대표하는 경우는 드물어요. 게다가 검색 품질이 유일한 요구사항인 것도 아니죠. 예를 들어 최고의 모델 중 일부는 검색에는 놀랍도록 정확하지만, 높은 리소스 사용량이나 예산 제약 때문에 실행할 여유가 없을 수 있어요.

이 글은 주로 밀집 텍스트 임베딩 모델을 중심으로 다루지만, 대부분의 고려 사항은 희소·멀티벡터 표현과 다른 모달리티에도 동일하게 적용돼요.

최적의 임베딩 모델을 고르는 것은 다중 목적 최적화 문제예요. 모든 경우에 들어맞는 만능 해법은 없고, 아마 앞으로도 없을 거예요. 이 글에서는 이 문제를 실용적으로 접근하는 방법과, 모델 선택에서 프로덕션 실행까지 나아가는 방법에 대한 지침을 드릴게요.

출처: 공식문서

평가: 벡터 검색의 성배

측정하지 않는 것은 개선할 수 없어요. 뻔한 말이지만 검색에도 그대로 적용돼요. 검색 품질은 실행 중인 시스템에서뿐 아니라, 가장 중요한 결정 — 어떤 임베딩 모델을 쓸지 —을 내리기 전에도 측정할 수 있고 측정해야 합니다.

모델이 말하는 언어 파악하기

임베딩 모델은 특정 언어를 염두에 두고 훈련돼요. 평가할 때는 데이터에 있거나 앞으로 생길 것으로 예상되는 언어를 모두 지원하는지 따져 봐야 해요. 데이터가 균일하지 않다면 여러 언어에 걸친 텍스트를 제대로 임베딩할 수 있는 다국어 모델이 필요할 수 있어요. 오픈소스 모델을 쓴다면 보통 Hugging Face Hub에 문서화되어 있어요. 예를 들어 데모에서 인기 있는 all-MiniLM-L6-v2는 영어 데이터로만 훈련됐기 때문에, 다른 언어 데이터가 있다면 좋은 선택이 아니에요.

하지만 언어만이 전부는 아니에요. 모델이 입력 데이터를 어떻게 다루는지도 중요하죠. 놀랍게도 이 점은 자주 간과돼요. 텍스트 임베딩 모델은 특정 토크나이저를 써서 입력 데이터를 조각으로 나눈 다음, 각 토큰에 특정 입력 벡터 표현을 할당하는 모든 Transformer 마법을 시작해요.

An example of tokenization with WordPiece tokenizer

이런 내부 동작의 결과 중 하나는, 모델이 자신의 토크나이저가 훈련된 내용만 이해할 수 있다는 거예요(네, 토크나이저도 훈련 가능한 컴포넌트랍니다). 결과적으로 훈련 중에 본 적 없는 문자는 모두 특별한 UNK 토큰으로 대체돼요. 소셜 미디어 데이터를 분석한다면, 다음 예제처럼 실제로는 모순되는 두 문장이 검색에서 완벽한 매치가 되는 걸 보고 놀랄 수 있어요.

Tokenization: The weather today is so 🌧️ vs The weather today is so 🌞

억양이 붙은 문자나, 목표 언어에서 지배적인 다른 알파벳 등에도 같은 일이 벌어질 수 있어요. 하지만 그런 경우라면 애초에 그런 모델을 쓰면 안 돼요. 어차피 그 언어를 지원하지 않으니까요. 토크나이제이션이 임베딩 품질에 미치는 영향은 많은 사람이 생각하는 것보다 커요. 토크나이제이션의 영향이 궁금하다면 DeepLearning.AI와 함께 만든 Retrieval Optimization: From Tokenization to Vector Quantization 코스를 추천해요. 가격이나 날짜 같은 숫자 데이터를 의미론적 검색 엔진이 왜 제대로 처리하지 못하는지, 그리고 그걸 어떻게 해결할 수 있는지 여전히 궁금하다면 특히 유용하실 거예요.

토크나이저가 목표 언어를 지원하는지 어떻게 알 수 있을까요? 오픈소스 모델이라면 아주 간단해요. 모델 없이 토크나이저만 돌려서 산출되는 토큰을 눈으로 확인하면 돼요. 상용 모델은 조금 더 어려울 수 있는데, OpenAI나 Cohere 같은 회사는 투명하게 토크나이저를 오픈소스로 공개하고 있어요. 최악의 경우, 의심되는 토큰 일부를 수정해 보고 원문과 수정문 사이의 유사도가 어떻게 변하는지 관찰하면 돼요.

Creating vectors for accented and non-accented letters

만들어진 표현이 벡터 공간에서 서로 아주 멀다면, 일부 미지원 문자가 UNK 토큰으로 대체돼서 모델이 입력 데이터를 제대로 임베딩하지 못하고 있다는 신호일 수 있어요.

고려해야 할 체크리스트

그렇다고 평가가 입력 토큰에만 초점을 맞추는 건 아니에요. 무엇보다 먼저 특정 모델이 우리가 쓰려는 작업을 얼마나 잘 처리하는지 측정해야 합니다. 벡터 임베딩은 다목적 도구라서, 어떤 모델은 **의미론적 유사도(semantic similarity)**에, 어떤 것은 **검색(retrieval)**이나 **질문 답변(question answering)**에 더 적합할 수 있어요. 여러분이 풀려는 문제의 본질을 아는 사람은 여러분 자신뿐이에요. 적합한 임베딩 모델을 고를 때 작업 유형만 고려하면 되는 건 아닙니다.

시퀀스 길이(Sequence length) – 임베딩 모델은 한 번에 처리할 수 있는 입력 크기에 제한이 있어요. 문서가 얼마나 길고 몇 토큰을 담는지 확인해 보세요. 오픈소스 모델이라면 Hugging Face Hub의 모델 카드에서 최대 시퀀스 길이를 확인할 수 있어요. 상용 모델은 프로바이더에게 직접 물어보는 게 좋아요.
모델 크기(Model size) – 큰 모델은 파라미터가 더 많고 메모리를 더 요구해요. 추론 시간은 모델 아키텍처와 하드웨어에도 의존하죠. 어떤 모델은 GPU에서만 효과적으로 돌아가고, 어떤 모델은 CPU에서도 잘 돌아가요.
최적화 지원(Optimization support) – 모든 모델이 모든 최적화 기법과 호환되는 건 아니에요. 예를 들어 Binary Quantization과 Matryoshka 임베딩은 특정 모델 특성을 요구해요.

이 목록이 완전한 것은 아니에요. 고려할 게 훨씬 더 많을 수 있지만, 감은 잡으셨을 거예요.

그래서 여러분이 정말 풀려는 작업을 정확히 정의하고, 시스템이 처리할 데이터를 직접 다뤄 보며, 그 데이터에 대한 ground truth 데이터셋을 구축해야 해요. 그래야 정보에 기반한 결정을 내릴 수 있으니까요.

Ground Truth 데이터셋 구축

데이터셋의 모습은 평가하려는 작업에 따라 달라져요. 의미론적 유사도를 말하는 거라면, 유사도를 나타내는 점수가 붙은 텍스트 쌍이 필요해요.

의미론적 유사도 작업의 데이터셋은 이렇게 생겼을 수 있어요.

[
  {
    "text1": "I love this movie, it's fantastic",
    "text2": "This film is amazing, I really enjoyed it",
    "similarity_score": 0.92
  },
  {
    "text1": "The weather is nice today",
    "text2": "I need to buy groceries",
    "similarity_score": 0.12
  }
]

대부분의 Qdrant 사용자는 보통 검색 시스템을 단독으로 구축하거나, 대형 언어 모델과 결합해 Retrieval Augmented Generation을 구축해요. 검색을 할 때는 의미론적 유사도보다 약간 다른 구조의 golden 데이터셋이 필요합니다. 검색의 문제는 주어진 쿼리에 대해 가장 관련성 높은 K개의 문서를 찾는 거예요. 따라서 쿼리 집합과, 각 쿼리에 대해 받으리라 기대하는 문서 집합이 필요해요. 관련성을 다른 세분화 수준에서 정의하는 방법도 세 가지가 있어요.

이진 관련성(Binary relevancy) – 문서가 관련 있거나 없거나.
서수 관련성(Ordinal relevancy) – 문서가 더 또는 덜 관련 있을 수 있음(랭킹).
점수가 있는 관련성(Relevancy with a score) – 문서가 관련성을 나타내는 점수를 가질 수 있음.

[
  {
    "query": "How do vector databases work?",
    "relevant_documents": [
      {
        "id": "doc_123",
        "text": "Vector databases store and index vector embeddings...",
        "relevance": 3  // Highly relevant (scale 0-3)
      },
      {
        "id": "doc_456",
        "text": "The architecture of modern vector search engines...",
        "relevance": 2  // Moderately relevant
      }
    ]
  },
  {
    "query": "Python code example for Qdrant",
    "relevant_documents": [
      {
        "id": "doc_789",
        "text": "```python\nfrom qdrant_client import QdrantClient\n...",
        "relevance": 3  // Highly relevant
      }
    ]
  }
]

데이터셋이 준비되면 precision@k, MRR, NDCG 같은 평가 메트릭 중 하나로 모델들을 평가하기 시작할 수 있어요. 이를 도와주는 ranx 같은 기존 라이브러리도 있어요. 여러 모델에 평가 과정을 돌려 보는 것은 그 모델들이 여러분의 데이터에서 어떻게 동작하는지 감을 잡는 좋은 방법이에요. 이렇게 하면 독점 모델까지도 테스트할 수 있어요. 다만 최적 모델을 고를 때 고려해야 할 것은 이것뿐만이 아니에요.

평가 데이터셋을 구축하는 걸 두려워하지 마세요. 보기보다 복잡하지 않고 정말 중요한 단계예요! 모델 성능을 파악하려면 수백만 개의 샘플이 필요하지 않아요. 잘 선별된 수백 개의 예제면 좋은 출발점이 돼요. 수십 개도 없는 것보다 훨씬 낫죠!

컴퓨팅 리소스 제약

도메인에 가장 잘 맞는 임베딩 모델을 찾았다고 해서 그 모델을 쓸 수 있다는 뜻은 아니에요. 소프트웨어 프로젝트는 고립돼 있지 않아서 더 큰 그림을 고려해야 합니다. 예를 들어 선택지를 제한하는 예산 제약이 있을 수 있어요. 실용성의 문제이기도 하죠. 정확도가 1% 더 높은 모델이 있는데 10배 더 느리고 10배 더 많은 리소스를 먹는다면, 정말 그만한 가치가 있을까요?

어떤 경우에는 목적지에 도달하는 것보다 여정을 즐기는 게 더 중요하지만, 검색에는 그 말이 통하지 않아요. 거기까지 데려다 준 수단이 단순하고 빠를수록 더 좋죠.

처리량, 지연 시간, 비용

프로덕션용 임베딩 모델을 고를 때 세 가지 중요한 운영 요소를 고려해야 해요.

처리량(Throughput) – 초당 몇 개의 임베딩을 생성할 수 있나요? 이는 시스템이 부하를 처리하는 능력에 직접 영향을 줘요. 일반적으로 큰 모델일수록 처리량이 낮아서, 데이터 유입이나 트래픽이 많은 시기에 병목이 될 수 있어요.
지연 시간(Latency) – 단일 임베딩을 얼마나 빨리 얻을 수 있나요? 검색하며 입력하는(search-as-you-type) 실시간 앱이나 인터랙티브 챗봇 같은 경우 저지연이 핵심이에요. 큰 모델의 양자화 버전은 상당한 지연 시간 개선을 제공할 수 있어요.
비용(Cost) – 여기에는 인프라 비용(CPU/GPU 리소스, 메모리)과 API 기반 모델의 토큰당·요청당 요금이 모두 포함돼요. 예를 들어 직접 모델을 돌리면 초기 비용은 높지만, 일부 SaaS 모델보다 요청당 비용이 낮을 수 있어요.

올바른 균형은 구체적인 사용 사례에 따라 달라져요. 뉴스 추천 시스템은 대량의 기사를 실시간으로 처리하느라 처리량을 우선시할 수 있고, 웹사이트 검색은 실시간 결과 때문에 지연 시간을 우선시할 수 있어요. 마찬가지로 LLM으로 응답을 생성하는 챗봇은 비용 효율을 우선시할 수 있는데, LLM은 자주 느리고 검색이 가장 시간이 걸리는 부분은 아니기 때문이에요.

모든 측면의 균형 맞추기

이 모든 고려 사항을 거치고 나면, 평가한 각 모델을 모든 조건 아래에서 정리한 표가 있어야 해요. 이제부터는 일이 어려워지고 답이 더 이상 명확하지 않아요.

이런 비교 테이블의 예를 들어 볼게요.

Model	Precision@10	MRR	Inference Time	Memory Usage	Cost	Multilingual	Max Sequence Length
expensive-proprietary-saas-only	0.92	0.87	API-dependent	N/A	$0.25/M tokens	Probably, yet undocumented	8192
cheaper-proprietary-multilingual	0.89	0.84	API-dependent	N/A	$0.01/M tokens	Yes (94 languages)	4096
open-source-gpu-required	0.88	0.83	120ms	15GB	Self-hosted	English	1024
open-source-on-cpu	0.85	0.79	30ms	120MB	Self-hosted	English	512

결정 과정은 여러분의 구체적인 요구사항이 이끌어야 해요. 예산에 쪼들리는 조직은 자체 호스팅 쪽으로 기울 수 있고, 인프라 관리가 싫은 조직은 API 기반 솔루션을 선호할 수 있어요. 어쩌면 여러분의 프로젝트가 최고 정확도를 요구하지 않아서, 더 작은 모델로 충분할지도 모르죠.

Fast, precise, cheap - pick two

이 결정이 한 번으로 끝나야 한다는 법은 없어요. 애플리케이션이 발전하면서 임베딩 모델 선택을 다시 검토해야 할 수도 있죠. Qdrant의 아키텍처는 필요할 때 다른 모델로 마이그레이션하기 비교적 쉽게 만들어 줘요. 네임드 벡터(Named vectors)는 여러 모델을 가진 시스템을 만들고 쿼리에 따라 그 사이를 전환하거나, 하이브리드 검색을 구축해 서로 다른 모델이나 더 복잡한 검색 파이프라인의 장점을 활용하게 해 줍니다.

적절한 임베딩 모델을 고르는 것은 벡터 검색 시스템에서 가장 중요한 설계 결정 중 하나지만, 그저 여러 레버 중 하나에 불과해요. 메모리 사용량은 양자화나 Matryoshka 임베딩 같은 기법으로 줄일 수 있는 경우가 많고, 검색 품질은 더 큰 임베딩 모델로 바꾸기보다 하이브리드 검색이나 리랭킹으로 더 좋아질 수 있어요. 핵심은 이래요. 임베딩 모델이 매우 중요하긴 하지만, 비용, 검색 품질, 지연 시간, 처리량은 검색 파이프라인과 시스템 전체의 속성이라는 점이죠.

임베딩 모델을 어디에 호스팅할지도 중요한 결정이에요. 인프라 관리를 직접 하고 싶지 않고, 처리하는 데이터를 원래 형태 그대로 보내는 걸 선호한다면? Qdrant에 딱 맞는 게 있어요!

로컬 소싱 임베딩

고른 임베딩 모델을 검색 엔진에 최대한 가까이에서 돌릴 수 있다면 얼마나 좋을까요? 네트워크 지연 시간은 가장 큰 적 중 하나일 수 있고, 수백만 개의 벡터를 네트워크로 전송하는 것은 먼 위치에서 하면 더 오래 걸릴 수 있어요. 게다가 일부 클라우드 프로바이더는 데이터 전송에 요금을 부과하므로, 지연 시간뿐 아니라 비용 문제도 있죠. 마지막으로 임베딩 모델을 온프레미스로 돌리려면 전문성과 리소스가 필요한데, 핵심 사업에 집중하고 싶다면 그런 건 피하고 싶을 거예요.

Architecture diagram with Qdrant Cloud Inference

Qdrant의 Cloud Inference는 벡터 데이터베이스가 실행되고 있는 클러스터 옆에서 임베딩 모델을 돌릴 수 있게 해 줘서 이 문제들을 해결해요. 모델 추론을 걱정하지 않고, 가진 데이터에서 잘 작동하는 검색만 쓰고 싶은 사람에게 완벽한 솔루션이죠. 더 자세한 내용은 Cloud Inference 문서를 확인해 보세요.

더 알아보기 (Learn more)

Hybrid Search 아티클 — 여러 모델을 활용하는 검색 파이프라인
Late Interaction 아티클 — 토크나이제이션·임베딩 모델 내부 이해
MTEB 리더보드
Cloud Inference 문서
Retrieval Optimization 코스 (DeepLearning.AI)