임베딩 모델 선택은 검색 품질을 좌우하는 가장 기본적인 결정입니다. 같은 벡터 DB를 써도 임베딩 모델이 다르면 결과가 크게 달라집니다.
문서 검색, RAG, 추천, 의미 기반 분류를 만든다면 임베딩 모델은 “대충 되는 것"이 아니라 “데이터와 언어에 맞는 것"을 골라야 합니다. Qdrant, pgvector, Supabase AI & Vectors, OpenAI File Search 같은 시스템에서는 특히 중요합니다.
왜 중요한가 #
임베딩 모델은 검색 시스템의 표현력을 결정합니다. 좋은 모델을 써도 chunk 전략이 망가지면 품질이 떨어지고, 반대로 chunk가 괜찮아도 임베딩이 약하면 검색이 흔들립니다.
- 짧은 문장 검색과 긴 문서 검색은 요구가 다릅니다.
- 한국어와 영어 혼합 데이터는 multilingual 성능이 중요합니다.
- 저비용 모델은 빠르지만 의미 분해 능력이 부족할 수 있습니다.
빠른 시작 #
임베딩 모델을 고를 때는 아래 순서로 보면 됩니다.
- 데이터 언어를 확인합니다.
- 검색 시나리오를 정합니다.
- latency와 비용 상한을 정합니다.
- 후보 모델 2개에서 4개를 정합니다.
- 오프라인 평가셋으로 비교합니다.
|
|
주로 비교하는 기준은 다음과 같습니다.
- dimension size
- multilingual performance
- retrieval quality
- inference cost
- throughput and latency
성능/비용 트레이드오프 #
| 기준 | 높은 품질 | 낮은 비용 |
|---|---|---|
| 모델 크기 | 대체로 유리합니다 | 대체로 불리합니다 |
| 차원 수 | 표현력이 좋아질 수 있습니다 | 저장 비용이 늘 수 있습니다 |
| 언어 범위 | multilingual에 유리합니다 | 단일 언어에 최적일 수 있습니다 |
| 속도 | 보통 느립니다 | 보통 빠릅니다 |
임베딩은 무조건 비싼 모델이 답이 아닙니다. 검색 대상이 짧은 FAQ인지, 긴 문서인지, 코드인지에 따라 적정선이 달라집니다.
체크리스트 #
- 데이터 언어와 도메인을 먼저 분류합니다.
- chunk 길이와 overlap을 모델에 맞춥니다.
- cosine similarity 기준을 통일합니다.
- offline eval set을 먼저 만듭니다.
- 비용과 latency를 production 기준으로 계산합니다.
- reranking과 함께 봤을 때의 최종 품질을 비교합니다.
결론 #
임베딩 모델 선택은 “좋은 모델 찾기"가 아니라 “내 데이터에 맞는 모델 찾기"입니다. 검색 품질과 비용을 동시에 보려면 모델 자체보다 평가 데이터와 운영 지표를 먼저 잡아야 합니다.
RAG나 Hybrid Search를 운영한다면 임베딩 모델, chunk 전략, reranking을 한 묶음으로 관리하는 편이 효율적입니다.