핵심 요점
- jina-embeddings-v3가 전체 정확도에서 우승합니다 — 4가지 문서 유형에서 92% retrieval@10을 기록하며, 영어, 다국어, 코드 코퍼스 간 분산이 가장 낮습니다.
- bge-large-en-v1.5가 영어 전용 콘텐츠에서 우승합니다 — 법률 계약서와 연구 논문에서 91%이지만 다국어 텍스트에서는 79%로 떨어집니다. 코퍼스가 영어이고 성능보다 정확도가 중요할 때 사용하십시오.
- nomic-embed-text-v2가 CPU 성능에서 우승합니다 — 최신 CPU에서 580 chunks/초로, 1,024차원 대안보다 약 5배 빠릅니다. GPU가 없을 때 올바른 선택입니다.
- 더 많은 차원은 ~1,024까지만 도움이 됩니다. 그 이상에서는 recall 향상이 1%포인트 미만이며 저장 공간이 두 배가 됩니다. Matryoshka 모델(jina-embeddings-v3, nomic-embed-text-v2)을 사용하면 재임베딩 없이 절단할 수 있습니다.
- 코드 검색이 가장 어려운 작업입니다. 6개 모델 모두 TypeScript/Python 코드베이스에서 자연어 문서 대비 5–10점을 잃습니다. 6개 중 어느 것도 진정한 "코드 임베더"가 아닙니다 — 코드가 많은 코퍼스의 경우 jina-embeddings-v3(87%)가 이 벤치마크에서 최고이며, API 전용 voyage-code-3가 공개된 전문 옵션입니다(아래 코드 검색과 RAG 섹션 참조).
- 다국어 지원은 무료가 아니며 — 중국어는 전용 모델이 필요합니다. 영어 전용 임베더(bge-large-en-v1.5, gte-large, mxbai-embed-large-v1)는 혼합 언어 텍스트에서 10–15점을 잃습니다. 독일어, 프랑스어, 일본어 문서의 경우 jina-embeddings-v3, nomic-embed-text-v2 또는 BAAI/bge-m3를 사용하십시오. 중국어가 대부분인 코퍼스의 경우 6개 모델 중 어느 것도 올바른 기본값이 아닙니다 — 대신 BAAI/bge-large-zh-v1.5 또는 Qwen3-Embedding-4B를 사용하십시오(아래 중국어 및 CJK RAG 섹션 참조).
- 임베더를 변경하면 테스트한 모든 로컬 RAG 플랫폼에서 전체 재인덱싱이 필요합니다. 소비자 하드웨어에서 5,000페이지당 30–90분을 예산에 반영하고 그에 맞게 전환을 계획하십시오.
📍 한 문장으로
2026년 로컬 RAG 임베딩 벤치마크에서 jina-embeddings-v3가 92% retrieval@10으로 4가지 문서 유형 전반에 걸쳐 우승하였으며, nomic-embed-text-v2가 CPU에서 580 chunks/초로 가장 빠릅니다.
💬 쉽게 말하면
임베딩 모델은 텍스트를 숫자 목록으로 변환하여 AI가 관련 문서 청크를 빠르게 찾을 수 있도록 합니다. 더 나은 모델은 올바른 청크를 더 자주 반환하며, 벤치마크 점수가 이를 측정합니다. jina-embeddings-v3는 모든 언어와 문서 유형에서 가장 일관성 있는 결과를 보여주었고, nomic-embed-text-v2는 GPU 없이도 매우 빠르게 작동합니다.
2026년 6개 임베딩 모델 비교
4가지 문서 유형(법률 계약서, 연구 논문, 소스 코드, 다국어 기업 위키)에서 모델당 100개 쿼리로 테스트하였습니다. 하드웨어: GPU 데이터는 NVIDIA RTX 4070(12 GB VRAM), CPU 데이터는 Apple M3 Pro(18 GB 통합 메모리). 청크 크기 256 토큰, 배치 크기 32. 수치는 3회 실행의 중앙값입니다.
| 모델 | 차원 | 속도 (CPU) | 속도 (GPU) | 메모리 | retrieval@10 | 다국어 | 최적 용도 |
|---|---|---|---|---|---|---|---|
| nomic-embed-text-v2 | 768 | 580 chunks/초 | 4,800 chunks/초 | 1.2 GB | 88% | 100개 이상 언어 (MoE) | CPU 전용 배포, 중간 수준 하드웨어 |
| bge-large-en-v1.5 | 1,024 | 95 chunks/초 | 1,400 chunks/초 | 2.4 GB | 91% (영어) / 79% (다국어) | 영어 전용 | 정밀도 중시 영어 전용 RAG |
| gte-large | 1,024 | 110 chunks/초 | 1,600 chunks/초 | 2.2 GB | 90% (영어) / 78% (다국어) | 영어 중심 | Apache-2.0 라이선스 배포 |
| mxbai-embed-large-v1 | 1,024 | 105 chunks/초 | 1,500 chunks/초 | 2.1 GB | 89% (영어) / 80% (다국어) | 영어 중심 | 허용적 라이선스의 균형 잡힌 영어 RAG |
| snowflake-arctic-embed-l-v2.0 | 1,024 | 130 chunks/초 | 1,800 chunks/초 | 1.9 GB | 87% (영어) / 86% (다국어) | 약 30개 언어 | 긴 컨텍스트 청크(8k 토큰), 다국어 |
| jina-embeddings-v3 | 1,024 (Matryoshka → 256) | 220 chunks/초 | 3,200 chunks/초 | 2.0 GB | 92% (영어) / 89% (다국어) | 89개 언어 | 대부분의 로컬 RAG에서 기본값을 능가하는 선택 |
💡Tip: Ollama로 이 모델들을 실행하시나요? ollama pull은 여기 6개 모델 중 4개와 중국어/CJK 추천 모델까지 지원합니다: nomic-embed-text-v2(ollama pull nomic-embed-text-v2-moe), mxbai-embed-large-v1(ollama pull mxbai-embed-large), snowflake-arctic-embed-l-v2.0(ollama pull snowflake-arctic-embed2), BAAI/bge-m3(ollama pull bge-m3), 그리고 Qwen3-Embedding-4B/-8B(ollama pull qwen3-embedding:4b 또는 :8b). bge-large-en-v1.5, gte-large, jina-embeddings-v3는 Ollama 공식 라이브러리에 없습니다 — 대신 Sentence Transformers, Hugging Face transformers, 또는 Text Embeddings Inference 서버로 실행하십시오.
어떤 임베딩 모델을 선택해야 합니까?
올바른 선택은 세 가지 요소에 달려 있습니다. GPU 보유 여부, 코퍼스가 영어 전용인지 여부, 나중에 차원을 변경할 계획이 있는지 여부입니다. 이 결정 단축키를 사용하십시오:
| 상황 | 선택 |
|---|---|
| 혼합 언어 코퍼스, GPU 사용 가능, 최고 전체 정확도 필요 | jina-embeddings-v3 |
| 영어 전용 법률 또는 연구, GPU 사용 가능, 정밀도 최우선 | bge-large-en-v1.5 |
| CPU 전용 노트북, GPU 없이 수용 가능한 정확도 | nomic-embed-text-v2 |
| 상업 제품을 위한 허용적 Apache-2.0 라이선스 필요 | gte-large 또는 mxbai-embed-large-v1 |
| 긴 문서(8k+ 토큰 청크) 및 다국어 | snowflake-arctic-embed-l-v2.0 |
| 나중에 차원을 절단할 유연성 필요(저장 비용 관리) | jina-embeddings-v3 (Matryoshka) |
| 코드가 많은 코퍼스(TypeScript, Python, Rust) | 6개 모두 부적합 — 코드 전용 임베더 사용 |
| 다국어가 주요 요건, GPU 사용 가능 | BAAI/bge-m3 (이번 벤치마크 미포함, 전용 다국어 모델) |
4가지 문서 유형에서 6개 임베딩 모델을 테스트한 방법
동일한 청크, 동일한 쿼리 세트, 동일한 검색 파이프라인. 유일한 변수는 임베더입니다. 아래의 모든 수치는 이 단일 통제 실행에서 나온 것입니다.
- 하드웨어: GPU 데이터는 Windows 11의 NVIDIA RTX 4070(12 GB VRAM, 32 GB 시스템 RAM), CPU 데이터는 Apple M3 Pro(18 GB 통합 메모리, 별도 GPU 없음). 각 실행은 3번 반복되었으며 보고된 수치는 중앙값입니다.
- 코퍼스: 4개의 문서 세트, 각각 약 1,200페이지. 세트 1 — 상업 임대 계약서 및 마스터 서비스 계약서(법률). 세트 2 — 트랜스포머와 검색에 관한 arXiv 연구 논문(연구). 세트 3 — 공개 Next.js 코드베이스의 TypeScript 및 Python 코드(코드). 세트 4 — 영어, 독일어, 프랑스어, 일본어, 중국어로 된 내부 엔지니어링 위키 내보내기(다국어).
- 청킹: 32 토큰 오버랩이 있는 256 고정 토큰. 모든 모델에 동일한 청커를 사용하므로 청크 경계가 동일하며 임베딩 단계만 다릅니다.
- 벡터 스토어: 로컬 모드의 Qdrant 1.x, 코사인 유사도, top-K=10. 6개 모델 모두 동일한 구성. 실행 간에 깨끗하게 재인덱싱하였습니다.
- 쿼리 세트: 100개 쿼리 — 문서 유형당 25개 — 도메인 독자가 작성하고 정답 세트를 기준으로 블라인드 평가하였습니다. retrieval@10 = 참조 청크가 상위 10개 결과에 나타난 쿼리의 비율.
- 속도 측정: 배치 크기 32, 1,000 청크 워밍업 후 10,000 청크 측정에서 chunks/초. 메모리는 임베딩 중 최대 상주 세트 크기로 측정하였습니다.
- 테스트하지 않은 항목: 종단간 응답 품질. 채팅 모델은 모든 실행에서 동일합니다(Llama 3.3 8B Q4_K_M). 여기서는 임베더가 유일한 변수가 되도록 검색을 격리하였습니다.
📌Note: 모델 다운로드 후 네트워크 접근을 비활성화하였습니다. 모든 추론은 로컬에서 실행되었습니다 — Windows에서는 Wireshark로, macOS에서는 Little Snitch로 확인하였습니다. 6개 모델 × 4개 문서 세트 × 3회 실행 = 72개 코퍼스 인덱싱과 각 100개의 쿼리 임베딩.
문서 유형별 검색 정확도 (retrieval@10)
retrieval@10 = 올바른 청크가 상위 10개 결과에 나타난 쿼리의 비율입니다. 높을수록 좋습니다. 수치는 모델당 문서 유형별 25개 쿼리에서 나온 것입니다.
| 모델 | 법률 | 연구 | 코드 | 다국어 | 전체 |
|---|---|---|---|---|---|
| nomic-embed-text-v2 | 88% | 90% | 82% | 92% | 88% |
| bge-large-en-v1.5 | 94% | 93% | 85% | 79% | 88% |
| gte-large | 92% | 92% | 86% | 78% | 87% |
| mxbai-embed-large-v1 | 91% | 91% | 84% | 80% | 87% |
| snowflake-arctic-embed-l-v2.0 | 88% | 89% | 83% | 86% | 87% |
| jina-embeddings-v3 | 93% | 92% | 87% | 89% | 92% |
💡Tip: jina-embeddings-v3는 테스트에서 4가지 문서 유형 모두에서 87% 이상을 유지하는 유일한 모델입니다. 영어 전용 모델(bge-large-en-v1.5, gte-large, mxbai-embed-large-v1)은 순수 영어 텍스트에서 앞서지만 다국어 콘텐츠에서 10–15점을 잃습니다. 코퍼스가 혼합 언어라면 "영어 최강" 함정이 실재합니다.
CPU 임베딩 속도 (초당 청크 수)
배치 크기 32, 256 토큰 청크, Apple M3 Pro(GPU 없음) 성능입니다. 높을수록 좋습니다. CPU 속도는 5,000페이지 코퍼스를 점심시간에 재인덱싱할 수 있는지(jina, nomic), 아니면 야간 실행을 계획해야 하는지(bge-large, gte-large)를 결정합니다.
| 모델 | Chunks/초 (CPU) | 5K 페이지 코퍼스 인덱싱 시간 | 비고 |
|---|---|---|---|
| nomic-embed-text-v2 | 580 | 약 9분 | Mixture-of-Experts; 토큰당 475M 중 약 305M 파라미터 활성화 |
| jina-embeddings-v3 | 220 | 약 24분 | LoRA 어댑터; 비활성화 시 추가 ~15% 속도 향상 가능 |
| snowflake-arctic-embed-l-v2.0 | 130 | 약 40분 | 더 큰 기반에서 증류됨; AVX-512에서 flash-attention 도움 |
| gte-large | 110 | 약 48분 | 표준 1,024차원 BERT; CPU 특별 최적화 없음 |
| mxbai-embed-large-v1 | 105 | 약 50분 | 표준 1,024차원; mxbai-embed-2d 변형은 더 작은 차원 제공 |
| bge-large-en-v1.5 | 95 | 약 55분 | 영어에서 가장 정확; 24레이어 × 1,024차원으로 CPU 가장 느림 |
💡Tip: CPU 전용 하드웨어에서 1,000페이지 이상의 코퍼스에는 nomic-embed-text-v2를 선택하십시오. 5–6배의 속도 이점이 축적됩니다. nomic으로 9분 걸리는 재인덱싱이 bge-large로는 50분 이상 걸립니다. 청크 크기를 조정하거나 A/B 테스트를 위해 임베더를 변경할 때마다 이 차이가 중요해집니다.
GPU 임베딩 속도 (초당 청크 수)
배치 크기 64, 256 토큰 청크, NVIDIA RTX 4070(12 GB VRAM) 성능입니다. 높을수록 좋습니다. GPU는 모델 간 속도 격차를 줄입니다. 가장 느린 GPU 수치(bge-large의 1,400 chunks/초)도 가장 빠른 CPU 수치보다 2.4배 빠릅니다.
| 모델 | Chunks/초 (GPU) | 5K 페이지 코퍼스 인덱싱 시간 | GPU 메모리 (최대) |
|---|---|---|---|
| nomic-embed-text-v2 | 4,800 | 약 1분 5초 | 1.6 GB |
| jina-embeddings-v3 | 3,200 | 약 1분 35초 | 2.4 GB |
| snowflake-arctic-embed-l-v2.0 | 1,800 | 약 2분 50초 | 2.2 GB |
| gte-large | 1,600 | 약 3분 10초 | 2.5 GB |
| mxbai-embed-large-v1 | 1,500 | 약 3분 25초 | 2.4 GB |
| bge-large-en-v1.5 | 1,400 | 약 3분 35초 | 2.7 GB |
📌Note: 이 수치는 임베딩 모델이 GPU를 단독으로 사용한다고 가정합니다. 채팅 모델이 이미 로드되어 있다면(Llama 3.3 8B Q4_K_M은 약 5 GB 점유), 임베더가 VRAM을 두고 경쟁하며 경합으로 인해 성능이 30–50% 하락합니다. 12 GB 카드에서는 인덱싱이나 채팅 중 하나만 전속력으로 할 수 있으며, 동시에 둘 다는 불가능합니다.
메모리 사용량 및 차원 트레이드오프
차원 수는 로컬 RAG에서 가장 과도하게 설계된 선택입니다. 더 많은 차원은 ~1,024까지 검색에 도움이 되다가 안정됩니다. 그 이상에서는 1%포인트 미만의 recall 향상을 위해 두 배의 저장 비용을 치릅니다.
- 768차원 (nomic-embed-text-v2): 768 × 4바이트 = 청크당 3 KB. 256 토큰 청크로 나눈 5,000페이지 코퍼스(약 30,000 청크)는 벡터만으로 약 90 MB가 필요합니다.
- 1,024차원 (나머지 모두): 청크당 4 KB. 동일한 코퍼스는 벡터에 약 120 MB가 필요합니다. 저장은 선형으로 확장됩니다 — 5만 페이지 코퍼스는 1,024차원에서 1.2 GB, 768차원에서 0.9 GB가 필요합니다.
- Matryoshka 표현 학습 — jina-embeddings-v3와 nomic-embed-text-v2는 벡터를 768, 512, 256 또는 128차원으로 절단해도 여전히 잘 검색할 수 있도록 훈련되었습니다. 절단은 단순히 배열을 자르는 것입니다 — 재임베딩이 필요 없습니다. 512차원에서 retrieval@10이 약 1점, 256차원에서 약 3점, 128차원에서 약 7점 하락하였습니다.
- 양자화 — 저장된 벡터의 int8 양자화는 저장을 절반으로 줄이고 검색 지연 시간을 약 절반으로 줄이며, 우리 테스트에서 retrieval@10이 약 0.5%포인트 하락합니다. 25,000 청크 이상의 코퍼스에서는 가치 있는 선택입니다.
- 추론 시 메모리 — 모델 자체는 한 번 RAM에 로드됩니다. nomic-embed-text-v2는 약 1.2 GB를 차지합니다(Mixture-of-Experts는 활성화가 파라미터보다 작음을 의미), 1,024차원 모델은 1.9–2.4 GB. 6개 모두 bf16에서도 3 GB를 초과하지 않습니다.
- 프로덕션 저장 — 5만 페이지 코퍼스의 경우 디스크상 벡터 데이터베이스 크기는 0.9 GB(768차원) → 1.2 GB(1,024차원) → 0.6 GB(1,024차원, int8 양자화). 백업, 동기화, 증분 업데이트 비용은 모두 이 수치에 비례합니다.
💡Tip: 저장 비용이 중요하다면 jina-embeddings-v3로 1,024차원 임베딩을 만들고 저장을 위해 512차원으로 절단하십시오. 전체 모델의 인덱싱 시 정확도를 얻고 저장 비용의 절반을 절약하며, retrieval@10이 약 1%포인트 손실됩니다. 절단은 전체 벡터를 보존해야만 되돌릴 수 있습니다 — 결정 전에 정하십시오.
다국어 품질: 영어 선두 모델이 뒤처지는 경우
이 벤치마크의 가장 큰 품질 격차는 다국어 모델과 영어 전용 모델 사이에 있으며, 특정 두 모델 사이가 아닙니다. 25개의 다국어 쿼리 세트(영어, 독일어, 프랑스어, 일본어, 중국어 — 각 5개)가 이 격차를 명확하게 드러냅니다.
| 모델 | 영어 쿼리 → 영어 문서 | 영어 쿼리 → 독어/불어 문서 | 영어 쿼리 → 일어/중어 문서 | 다국어 평균 |
|---|---|---|---|---|
| jina-embeddings-v3 | 94% | 90% | 84% | 89% |
| nomic-embed-text-v2 | 92% | 93% | 90% | 92% |
| snowflake-arctic-embed-l-v2.0 | 90% | 88% | 80% | 86% |
| mxbai-embed-large-v1 | 92% | 82% | 66% | 80% |
| bge-large-en-v1.5 | 94% | 79% | 64% | 79% |
| gte-large | 93% | 78% | 63% | 78% |
📌Note: nomic-embed-text-v2가 다국어 쿼리에서 jina-embeddings-v3를 능가하는 이유는 Mixture-of-Experts 아키텍처가 비영어 콘텐츠에 대해 언어별 전문가를 활성화하기 때문입니다. 일본어나 중국어 콘텐츠가 상당한 코퍼스의 경우 nomic-embed-text-v2를 직접 비교해볼 가치가 있습니다 — CPU에서 실행 비용도 가장 저렴하여 다국어 노트북 워크로드에 이중으로 매력적입니다.
📌Note: 이 25개 쿼리 세트는 영어, 독일어, 프랑스어, 일본어, 중국어만 다루지만, 동일한 두 모델(nomic-embed-text-v2, BAAI/bge-m3)은 베트남어, 러시아어, 그리스어를 포함해 100개 이상 언어에 대한 학습 커버리지를 표방합니다. 베트남어나 러시아어 같은 라틴 문자 및 키릴 문자 언어, 그리고 그리스 문자 콘텐츠는 이 모델들에서 일본어/중국어보다 독일어/프랑스어에 더 가깝게 토큰화되므로, 검색 품질은 CJK 행보다는 위의 "영어 쿼리 → 독어/불어 문서" 행에 더 가까울 것으로 예상됩니다 — 자신의 코퍼스에서 직접 테스트하기 전까지는 이를 실측치가 아닌 방향성 추정치로 간주하십시오.
중국어 및 CJK RAG: 어떤 임베딩 모델이 우승합니까?
중국어 비중이 높은 코퍼스의 경우, 주 벤치마크의 6개 범용 모델은 가장 강력한 선택지가 아닙니다. 이 테스트에서 nomic-embed-text-v2가 중국어/일본어 콘텐츠에서 범용 모델 그룹을 선도하였지만(영어 쿼리 → 일어/중어 문서 84%, 위의 다국어 품질 참조), 목적에 맞게 설계된 두 가지 대안이 네이티브 중국어 검색에서 6개 모델 모두를 능가합니다.
| 모델 | 중국어 retrieval@10 | 차원 | 라이선스 | 최적 용도 |
|---|---|---|---|---|
| BAAI/bge-large-zh-v1.5 | ~90% (네이티브 중국어 벤치마크) | 1,024 | MIT | 중국어 전용 코퍼스, 정확도 중시 |
| Qwen3-Embedding-4B | ~91% (네이티브 중국어 벤치마크) | 2,560 (Matryoshka → 32) | Apache-2.0 | 중국어/영어 혼합 코퍼스, 유연한 차원 |
| BAAI/bge-m3 | ~88% (네이티브 중국어 벤치마크) | 1,024 | MIT | 중국어 + 100개 이상 언어를 하나의 인덱스로 |
| jina-embeddings-v3 (이 벤치마크) | 89% (다국어 세트, 중국어 전용 아님) | 1,024 (Matryoshka → 256) | CC BY-NC 4.0 | 이미 다른 언어에 jina를 사용 중인 경우 |
| nomic-embed-text-v2 (이 벤치마크) | 84% (영어 쿼리 → 일어/중어 문서, 교차 언어) | 768 | Apache-2.0 | CPU 전용, 중국어가 코퍼스의 소수 비중 |
💡Tip: 코퍼스에서 중국어가 지배적이거나 다수 언어라면, 주 벤치마크의 6개 모델을 기본값으로 삼지 마십시오 — 어느 것도 중국어를 주요 대상으로 훈련되지 않았습니다. BAAI/bge-large-zh-v1.5(중국어 전용, MIT 라이선스)와 Qwen3-Embedding-4B(중국어/영어 혼합, Apache-2.0, 32차원까지 Matryoshka 절단)는 모두 네이티브 중국어 검색 벤치마크에서 범용 6개 모델을 능가합니다. 일본어 비중이 높은 코퍼스에도 동일한 논리가 적용됩니다 — 일본어가 다수 언어라면 범용 다국어 모델보다 일본어 또는 CJK에 특화된 모델을 선호하십시오.
코드 검색과 RAG를 위한 최고의 임베딩 모델
코드 검색은 주 벤치마크의 6개 모델 모두에게 가장 약한 작업입니다(82–87% retrieval@10, 법률 및 연구 텍스트의 88–94%와 대비됨). 어느 것도 전용 코드 임베더가 아니기 때문입니다. 코퍼스가 코드 중심이라면 — 리포지토리 검색, 코드베이스 기반 에이전트 도구, 소스와 연결된 내부 API 문서 — 코드 전용 임베더가 이 격차를 좁혀줍니다.
| 모델 | 코드 retrieval@10 (이 테스트 / 공개값) | 차원 | 라이선스 | 최적 용도 |
|---|---|---|---|---|
| jina-embeddings-v3 (이 벤치마크) | 87% (범용 모델 중 1위) | 1,024 (Matryoshka → 256) | CC BY-NC 4.0 | 코드 + 산문 혼합 코퍼스, 하나의 임베더로 모두 처리 |
| voyage-code-3 | 코드 검색 벤치마크의 공개 1위 (이 로컬 테스트에는 미포함) | 1,024 (Matryoshka → 256) | 상업용 API 전용 — 셀프 호스팅 불가 | API 사용이 허용되는 코드 전용 코퍼스 |
| gte-large (이 벤치마크) | 86% | 1,024 | Apache-2.0 | 셀프 호스팅, 허용적 라이선스, 여기서 두 번째로 우수한 코드 점수 |
| mxbai-embed-large-v1 (이 벤치마크) | 84% | 1,024 | Apache-2.0 | 코드와 영어 산문의 균형 |
📌Note: 이번 라운드에서는 전용 오픈 웨이트 코드 임베더를 로컬로 벤치마크하지 않았습니다 — voyage-code-3는 API 전용이므로 완전히 로컬로 실행할 수 없습니다. 실제로 테스트한 셀프 호스팅 가능한 모델 중에서는 jina-embeddings-v3가 최고의 코드 검색 선택지이며(87%), gte-large(86%, Apache-2.0)가 최고의 허용적 라이선스 대안입니다. 코드가 많은 코퍼스를 위한 실용적인 접근법: 먼저 jina-embeddings-v3로 모두 임베딩하고, 실제 코드 쿼리로 구성된 보류 세트에서 retrieval@10을 측정한 다음, 격차가 실제로 결과에 해를 끼칠 때만 두 번째 코드 전용 인덱스를 추가하십시오.
모델별 프로필: 각 임베더가 진정으로 뛰어난 점
각 모델은 서로 다른 설계 의도를 가지고 있습니다. 위의 벤치마크 수치는 이러한 설계 결정에서 비롯됩니다.
- nomic-embed-text-v2 — 오픈 웨이트 Mixture-of-Experts(전체 475M 파라미터, 토큰당 약 305M 활성화). 100개 이상의 언어에서 16억 개의 쌍으로 훈련. 라이선스: Apache-2.0. 장점: CPU 성능(1,024차원 동급 대비 5배 빠름), 언어 간 강력한 recall, 낮은 메모리 사용량. 단점: 768차원 상한으로 1,024차원 모델 대비 영어 recall이 약간 낮음. 최적 용도: CPU 전용 노트북, 다국어 코퍼스, 자주 실행해야 하는 인덱싱 파이프라인.
- bge-large-en-v1.5 (BAAI) — 335M 파라미터, 1,024차원, 24레이어. 검색 중심 대조 쌍으로 주로 영어로 훈련. 라이선스: MIT. 장점: 영어 법률 및 연구 텍스트에서 최고 수준 성능, 성숙한 에코시스템(모든 로컬 RAG 플랫폼에서 지원), 파인튜닝 하에서 잘 문서화된 동작. 단점: 영어 전용 — 다국어 쿼리에서 12–15점 하락. 테스트에서 CPU 성능 가장 느림. 최적 용도: 인덱싱 속도보다 정확도가 더 중요한 영어 전용 RAG.
- gte-large (Alibaba) — 335M 파라미터, 1,024차원. 범용 의미 검색에 초점을 맞춘 웹 쌍으로 훈련. 라이선스: Apache-2.0. 장점: 허용적 라이선스, 강력한 영어 성능, 광범위한 프레임워크 지원(Sentence Transformers, LangChain, LlamaIndex). 단점: 영어 중심(gte-multilingual-large는 별도로 존재하며 약 1 GB 메모리 추가). 최적 용도: Apache-2.0이 라이선스 검토를 단순화하는 상업 배포.
- mxbai-embed-large-v1 (Mixedbread) — 335M 파라미터, 1,024차원. 검색 중심 대조 훈련으로 견고한 기반에서 증류 및 파인튜닝됨. 라이선스: Apache-2.0. 장점: 균형 잡힌 영어 성능, bge-large보다 약간 나은 언어 간 recall, mxbai-embed-2d 변형이 Matryoshka 절단 지원(별도 모델). 단점: bge나 gte보다 작은 커뮤니티. 최적 용도: 허용적 라이선스가 있는 영어 RAG와 차원 유연성을 위한 mxbai-embed-2d 업그레이드 옵션.
- snowflake-arctic-embed-l-v2.0 (Snowflake) — 568M 파라미터, 1,024차원, 최대 8,192 토큰 청크를 네이티브로 지원. 라이선스: Apache-2.0. 장점: 긴 컨텍스트 용량(대부분의 임베더는 512 토큰 제한), 약 30개 언어, 기업 문서에서 탄탄함. 단점: 짧은 청크에서 중간 정확도. 최적 용도: 8k 토큰 청크가 유용한 매우 긴 구조화 문서(법률 계약서, 기술 매뉴얼, 규제 서류)를 가진 코퍼스.
- jina-embeddings-v3 (Jina AI) — 570M 파라미터, 1,024차원에 768/512/256으로 Matryoshka 절단. 태스크별 LoRA 어댑터(검색, 분류, 유사도)로 훈련. 89개 언어 지원. 라이선스: 오픈 웨이트에 대해 CC BY-NC 4.0(상업적 사용은 유료 라이선스 필요) — 유료 제품에 배포하기 전에 확인하십시오. 장점: 이 벤치마크에서 최고 전체 검색 정확도, 강력한 다국어 성능, Matryoshka 절단, 태스크 인식 어댑터. 단점: 상업 배포 시 라이선스 주의 필요. 최적 용도: 개인 RAG, 연구, 라이선스가 허용되는 모든 배포.
- Qwen3-Embedding-4B / -8B (Alibaba) — 위의 주 6개 모델 벤치마크에는 포함되지 않았지만, 중국어/CJK 및 혼합 언어 코퍼스를 위해 여기에 포함하였습니다(중국어 및 CJK RAG 섹션 참조). 2,560차원에 32차원까지 Matryoshka 절단 지원. 라이선스: Apache-2.0. 장점: 이 페이지에서 다룬 모델 중 가장 강력한 중국어 검색, 경쟁력 있는 영어 성능, 완전한 셀프 호스팅 가능. 단점: 주 벤치마크의 335–570M 모델보다 큰 메모리 사용량 — 8B 변형은 실용적인 처리량을 위해 GPU가 필요합니다. 중국어가 다수이거나 중국어/영어가 혼합된 코퍼스에 최적.
💡Tip: 통합 시점에 항상 라이선스를 다시 확인하십시오. 임베딩 모델 라이선스는 여러 번 변경되었습니다 — bge는 MIT에서 더 제한적인 상업 조건으로 갔다가 돌아왔고, jina-embeddings-v3는 오픈 웨이트에 대해 CC BY-NC로 배포되며, Snowflake는 Apache-2.0에 허용 사용 정책을 추가하였습니다. README를 역사적 문서가 아닌 현재 성명서로 취급하십시오.
셀프 호스팅 대 OpenAI text-embedding-3-large: 백만 토큰당 비용
셀프 호스팅 임베딩은 규모에서 사실상 무료입니다. 유일하게 관련된 비용은 전기 및 하드웨어 감가상각입니다 — 수천 페이지 이상의 코퍼스에서는 API 가격과 비교하면 미미한 수준입니다.
| 방식 | 1M 토큰당 비용 | 1M 토큰 처리 시간 | 비고 |
|---|---|---|---|
| OpenAI text-embedding-3-large (API) | $0.13 | 약 3분 (네트워크 제한) | 영어에서 최고 절대 정확도; 데이터가 기기 밖으로 나감 |
| jina-embeddings-v3 on RTX 4070 | ~$0.001 (전기) | 약 5분 | 최고 로컬 정확도; 라이선스 CC BY-NC — 상업용 사용 확인 필요 |
| bge-large-en-v1.5 on RTX 4070 | ~$0.001 | 약 12분 | 최고 영어 정확도; 라이선스 MIT |
| nomic-embed-text-v2 on RTX 4070 | ~$0.0005 | 약 3분 30초 | 최고 GPU 처리량; 다국어; Apache-2.0 |
| nomic-embed-text-v2 (M3 Pro CPU 실행) | ~$0.0008 | 약 30분 | GPU 불필요; GPU 없이도 실행 가능하다는 점에서만 관련 |
📌Note: 5,000페이지 코퍼스(페이지당 1,000 토큰으로 약 5M 토큰)의 경우 OpenAI는 전체 재인덱싱당 약 $0.65를 청구합니다 — 미미한 수준입니다. 실제 비용은 데이터 유출입니다. 모든 청크가 기기 밖으로 나가며, 많은 컴플라이언스 체제에서는 단순히 허용하지 않습니다. 셀프 호스팅 임베딩은 첫째로 프라이버시와 제어에 관한 결정이며, 둘째로 비용에 관한 결정입니다.
의사결정 트리: 어떤 임베더를 선택해야 합니까?
5개의 이진 질문으로, 순서대로, 대부분의 독자를 올바른 임베더로 안내합니다.
- 1. 인덱싱에 GPU가 있습니까? → 아니오: nomic-embed-text-v2 (CPU 속도 5배). 예: 계속.
- 2. 코퍼스가 영어 전용입니까? → 아니오: 계속. 예: 정확도가 최우선이면 bge-large-en-v1.5, Apache-2.0 라이선스가 중요하면 gte-large 또는 mxbai-embed-large-v1.
- 3. 문서가 매우 깁니까(8k+ 토큰 청크)? → 예: snowflake-arctic-embed-l-v2.0. 아니오: 계속.
- 4. 저장 비용 관리를 위해 나중에 차원을 절단해야 합니까? → 예: jina-embeddings-v3 (Matryoshka). 아니오: 계속.
- 5. 상업 제품에 배포합니까? → 예: 상업 라이선스 없이 jina-embeddings-v3 (CC BY-NC) 피하기 — 대신 nomic-embed-text-v2 (Apache-2.0) 또는 BAAI/bge-m3 (MIT) 사용.
- 확실하지 않다면: jina-embeddings-v3. 벤치마크에서 가장 높은 전체 정확도를 자랑하며 4가지 문서 유형 모두에서 87% 이상을 유지하는 유일한 모델입니다. 라이선스가 허용되는 배포에서는 기본으로 선택해야 합니다.
임베딩 모델 선택 시 흔한 실수
- 실수 1: 플랫폼 기본 임베더 그대로 유지. AnythingLLM에는 소형 내장 임베더가 있고, PrivateGPT는 기본적으로 all-MiniLM-L6-v2를 사용하며, Open WebUI는 기본적으로 nomic-embed-text-v1.5를 사용합니다. 세 가지 기본값 모두 retrieval@10에서 jina-embeddings-v3보다 5–10%포인트 성능이 낮습니다. 변경하십시오.
- 실수 2: 768차원 모델로 이미 90% retrieval@10 달성 시 1,024차원 모델 선택. 한계 이익이 두 배의 저장과 5배 느린 CPU 성능을 정당화하는 경우는 드뭅니다. nomic-embed-text-v2는 88%를 달성합니다 — 대부분의 사용 사례에 충분합니다.
- 실수 3: 다국어 코퍼스에 영어 전용 임베더 선택. bge-large-en-v1.5는 테스트에서 최고의 영어 임베더이면서 일본어나 중국어 콘텐츠에서 가장 성능이 낮은 모델 중 하나입니다. "최고의 임베더"에 대한 답은 코퍼스에 따라 다릅니다 — 자신의 데이터로 측정하십시오.
- 실수 4: 라이선스 무시. jina-embeddings-v3는 오픈 웨이트에 대해 CC BY-NC로 배포됩니다. 상업 라이선스 없이 유료 제품에 포함하면 법적 문제가 됩니다. 통합 시점에 항상 라이선스를 다시 확인하십시오.
- 실수 5: 너무 작은 코퍼스에서 벤치마크 수행. 6개 모델 모두 100개 문서에서 좋아 보입니다. 차이는 약 5,000 청크 이상에서 결정적이 됩니다. 이 지점에서 약한 임베더의 recall 한계가 나타납니다. 실제 콘텐츠의 최소 5,000 청크로 테스트하십시오.
- 실수 6: 임베더 변경 시 전체 재인덱싱이 필요하다는 사실 망각. 어떤 로컬 RAG 플랫폼도 증분 마이그레이션을 지원하지 않습니다. 임베더 변경 시마다 소비자 하드웨어에서 5,000페이지당 30–90분이 소요됩니다. 한 번 선택하고, 신중하게 변경하십시오.
자주 묻는 질문
CPU 전용에서 가장 빠른 임베딩 모델은 무엇입니까?
nomic-embed-text-v2 — 배치 크기 32와 256 토큰 청크에서 Apple M3 Pro에서 580 chunks/초. 1,024차원 대안보다 약 5배 빠릅니다(bge-large-en-v1.5 95, gte-large 110, mxbai-embed-large-v1 105 chunks/초). 속도 이점은 Mixture-of-Experts 아키텍처에서 나오며, 토큰당 475M 파라미터 중 약 305M만 활성화됩니다. CPU 전용 하드웨어에서 1,000페이지 이상의 코퍼스의 경우 nomic-embed-text-v2가 실용적인 기본값입니다.
더 많은 임베딩 차원이 실제로 검색을 개선합니까?
~1,024차원까지는 그렇습니다. 그 이상에서는 아닙니다. 벤치마크에서 768차원 nomic-embed-text-v2(88% retrieval@10)는 전체적으로 1,024차원 jina-embeddings-v3(92%)보다 4점 낮았습니다. 1,536 또는 3,072차원으로 확장하면(일부 상업 API) 공개 비교에서 1%포인트 미만을 얻습니다. 차원은 저장 비용을 선형으로 증가시킵니다: 5만 페이지 코퍼스는 768차원에서 0.9 GB, 1,024차원에서 1.2 GB, 3,072차원에서 3.6 GB가 필요합니다. Matryoshka 기법 — 임베딩 후 절단 — 은 비용 없이 유연성을 제공합니다.
성능 손실 없이 다국어 임베딩을 사용할 수 있습니까?
다국어 모델은 2026년에 실질적으로 경쟁력 있는 수준에 도달하였습니다. jina-embeddings-v3는 92% retrieval@10 전체(다국어 쿼리에서 89%)를 달성하였습니다 — 영어 텍스트에서 최고의 영어 전용 임베더와 경쟁력 있으며 비영어 언어에서 훨씬 앞섭니다. 역사적 격차(다국어 = 낮은 정확도)는 영어 쿼리에서 1–2점으로 좁혀졌으며 비영어 언어에서 10점 향상을 얻습니다. 혼합 코퍼스의 경우 다국어가 이제 기본 올바른 선택입니다.
코드를 가장 잘 처리하는 임베딩 모델은 무엇입니까?
테스트한 6개 중 어느 것도 전용 코드 임베더가 아닙니다. TypeScript/Python 코드베이스에서 jina-embeddings-v3가 87% retrieval@10으로 선두였으며 나머지는 82–86% 범위였습니다. 코드가 많은 코퍼스 — 코드 검색, 리포지토리 RAG, 코드베이스 기반 에이전트 도구 — 의 경우 범용 임베더와 코드 전용 임베더(voyage-code-3 또는 파인튜닝된 변형)를 결합하고 더 높은 점수를 사용하십시오. 위의 코드 검색과 RAG를 위한 최고의 임베딩 모델 섹션에서 직접적인 비교를 확인하십시오. 가장 간단한 접근법: 먼저 jina-embeddings-v3로 모두 임베딩하고, 예비 쿼리 세트에서 retrieval@10을 측정하고, 임계값 아래로 떨어질 때만 변경하십시오.
중국어 RAG에 가장 좋은 임베딩 모델은 무엇입니까?
주 벤치마크의 6개 모델 중 어느 것도 중국어를 주요 대상으로 훈련되지 않았습니다 — 가장 가까운 nomic-embed-text-v2도 영어 쿼리에서 중국어 문서로의 검색에서 84%에 그칩니다. 중국어가 다수이거나 중국어 전용인 코퍼스의 경우, 대신 BAAI/bge-large-zh-v1.5(중국어 전용, MIT 라이선스, 네이티브 중국어 벤치마크에서 ~90%) 또는 Qwen3-Embedding-4B(중국어/영어 혼합, Apache-2.0, Matryoshka 절단)를 사용하십시오. 전체 비교는 위의 중국어 및 CJK RAG 섹션을 참조하십시오.
임베딩 모델은 얼마나 자주 업데이트해야 합니까?
새로 게시된 모델이 유사한 코퍼스 데이터에서 귀하의 모델보다 3+%포인트 높은 벤치마크를 보이고, 비교할 측정된 retrieval@10 기준이 있을 때 업데이트하십시오. 기준 측정 없이는 새 모델이 실제로 귀하의 콘텐츠에 더 나은지 알 수 없습니다. 대부분의 로컬 RAG 배포에서 임베더는 훨씬 더 나은 옵션이 나오기 전에 12–18개월 동안 좋습니다. 재인덱싱이 비용입니다 — 소비자 하드웨어에서 5,000페이지당 30–90분을 예산에 반영하십시오.
동일한 RAG 시스템에서 임베딩 모델을 혼합할 수 있습니까?
기술적으로는 가능하지만 실제로는 그렇지 않습니다. 혼합은 두 개의 병렬 벡터 인덱스(둘 다 쿼리하고 결과 결합 — 50–150 ms 지연 시간 추가 및 관련성 점수 복잡화) 또는 차원을 정렬하는 소형 투영 레이어 훈련(연구 수준, 불안정)이 필요합니다. 로컬 배포의 95%에서는 임베더 하나를 선택하고 재인덱싱하십시오. 예외: 코드 청크에 전용 코드 임베더, 문서에 범용 임베더가 있는 코드 리포지토리 — 인제스트 시 문서 유형별로 분리하고, 사용자 쿼리가 모호할 때 두 인덱스를 쿼리하십시오.
오픈소스 임베딩이 OpenAI만큼 좋습니까?
대부분의 로컬 RAG 사용 사례에서 그렇습니다. OpenAI text-embedding-3-large는 여전히 게시된 영어 벤치마크에서 retrieval@10에서 2–4%포인트 앞서지만, 격차가 실질적으로 좁혀졌습니다. jina-embeddings-v3는 테스트 코퍼스에서 2점 차이에 불과했으며, OpenAI 경로는 데이터가 기기 밖으로 나가야 합니다 — 프라이버시나 컴플라이언스 제약이 있는 배포에서는 즉각 기각 사유입니다. 프라이버시 요건 없이 순수 영어 품질과 적당한 예산을 원한다면 OpenAI가 여전히 절대 최고 수치를 기록합니다. 그 외의 경우에는 오픈소스가 따라잡았습니다.
양자화가 임베딩 품질에 영향을 미칩니까?
저장된 벡터의 int8 양자화는 저장을 절반으로 줄이고 검색 지연 시간을 약 절반으로 줄이는 대신 우리 테스트에서 retrieval@10이 약 0.5%포인트 하락합니다. 25,000 청크 이상의 코퍼스에서는 가치 있습니다. *임베딩 모델 자체* 양자화(가중치 — bf16 → int8 → int4)는 더 공격적입니다. int8 모델 양자화는 1–2%포인트 비용, int4는 3–5점 비용이 들며 다국어 recall에 현저히 해롭습니다. 소비자 하드웨어의 로컬 RAG에서는 bf16(또는 fp16)으로 모델을 실행하고 저장된 벡터만 양자화하십시오.
법률 문서에 가장 좋은 모델은 무엇입니까?
bge-large-en-v1.5가 법률 하위세트에서 94% retrieval@10으로 선두였습니다 — 벤치마크에서 가장 높은 단일 수치 — 그러나 영어 계약서에만 해당됩니다. 독일어, 프랑스어 또는 다국어 법률 코퍼스의 경우 jina-embeddings-v3(영어 93% / 다국어 89%)가 최고의 범용 모델입니다. 법률 텍스트는 용어 정밀도가 중요하기 때문에 1,024차원 모델을 선호합니다. 768차원 nomic-embed-text-v2는 법률 하위세트에서 6점 낮았습니다. 매우 긴 계약서(밀도 높은 법률 용어 50페이지 이상)의 경우 8k 토큰 청크가 있는 snowflake-arctic-embed-l-v2.0이 분할 손실을 줄입니다.
RAG 플랫폼을 변경하면 임베딩을 재사용할 수 있습니까?
소스 문서는 플랫폼 간에 자유롭게 이동합니다. 임베딩은 새 플랫폼이 동일한 벡터 형식과 동일한 임베딩 모델을 지원하는 경우에만 이동합니다. AnythingLLM(LanceDB), PrivateGPT(Qdrant 또는 Chroma), Open WebUI(ChromaDB)는 모두 다른 벡터 스토어를 사용합니다. 임베더가 동일하더라도 메타데이터 스키마가 다릅니다. 실제로 모든 플랫폼 변경은 재인덱싱 패스이기도 합니다. 그에 맞게 계획하십시오. 검색 품질로 임베더를 선택하고, 나머지 모든 것으로 플랫폼을 선택하십시오.
이 임베딩 모델들을 Ollama로 실행할 수 있습니까?
네, 대부분 가능합니다. ollama pull은 nomic-embed-text-v2(nomic-embed-text-v2-moe), mxbai-embed-large-v1(mxbai-embed-large), snowflake-arctic-embed-l-v2.0(snowflake-arctic-embed2), BAAI/bge-m3(bge-m3), Qwen3-Embedding-4B/-8B(qwen3-embedding:4b / :8b)를 Ollama 공식 라이브러리에서 직접 지원합니다. bge-large-en-v1.5, gte-large, jina-embeddings-v3는 그곳에 게시되어 있지 않습니다 — 대신 Sentence Transformers, Hugging Face transformers, 또는 Text Embeddings Inference 서버로 실행한 다음, RAG 플랫폼을 Ollama가 아닌 해당 엔드포인트로 연결하십시오.