1. 임베딩 모델이란?
임베딩 모델(Embedding Model)은 텍스트를 고정 길이의 숫자 벡터로 변환하는 모델입니다. "서울은 대한민국의 수도입니다"라는 문장이 [0.12, -0.87, 0.45, ...]처럼 수백~수천 개의 숫자로 바뀌는 것입니다. 의미가 유사한 문장은 벡터 공간에서 가까운 위치에 놓이고, 의미가 다른 문장은 멀리 놓입니다. 이 성질을 이용해 벡터 DB에서 질문과 가장 유사한 문서 청크를 검색합니다.
RAG 파이프라인에서 임베딩 모델은 두 곳에서 사용됩니다.
[인덱싱 단계]
문서 청크 → 임베딩 모델 → 벡터 → 벡터 DB 저장
[검색 단계]
사용자 질문 → 임베딩 모델 → 벡터 → 벡터 DB에서 유사 벡터 검색
인덱싱과 검색 모두 반드시 동일한 임베딩 모델을 사용해야 합니다. 서로 다른 모델로 생성한 벡터는 서로 다른 공간에 존재하기 때문에 유사도 비교가 의미 없어집니다.
2. 임베딩 모델 선택 시 고려해야 할 핵심 속성
2.1. 임베딩 차원 (Dimension)
벡터를 구성하는 숫자의 개수입니다. 차원이 높을수록 의미를 더 세밀하게 표현할 수 있지만, 그만큼 저장 공간과 검색 연산 비용이 늘어납니다.
| 차원 범위 | 특징 |
| 256~512 | 빠른 검색, 저비용, 간단한 도메인에 적합 |
| 768~1,024 | 범용적, 품질과 비용의 균형 |
| 1,536~3,072 | 높은 표현력, 복잡한 의미 구분 가능, 비용 높음 |
최근에는 Matryoshka Representation Learning(MRL) 기법을 적용한 모델이 늘고 있습니다. 3,072차원으로 생성한 벡터를 512차원으로 잘라도 품질 손실이 크지 않아, 필요에 따라 차원을 줄여 비용을 최적화할 수 있습니다. OpenAI text-embedding-3 시리즈와 Cohere Embed가 이 기법을 지원합니다.
2.2. 최대 입력 토큰 (Context Window)
모델이 한 번에 처리할 수 있는 최대 토큰 수입니다. 이 상한을 넘는 텍스트는 잘려서 뒷부분 내용이 임베딩에 반영되지 않습니다. 긴 문서를 처리하는 RAG 시스템일수록 이 값이 중요합니다.
2.3. 다국어 지원 여부
영어 중심으로 학습된 모델은 한국어 텍스트의 의미 관계를 정확히 포착하지 못할 수 있습니다. 한국어 서비스라면 다국어 지원 여부를 반드시 확인해야 합니다. 이상적인 다국어 모델은 "서울"과 "Seoul"의 벡터가 가깝게 놓이는 크로스 링구얼(Cross-lingual) 정렬이 잘 되어 있습니다.
2.4. API 방식 vs 자체 호스팅
| 구분 | API 방식 | 자체 호스팅 |
| 장점 | 인프라 관리 불필요, 빠른 시작 | 데이터 외부 전송 없음, 대규모 시 저비용 |
| 단점 | 데이터 외부 전송, 호출 비용 누적 | GPU 인프라 필요, 운영 부담 |
| 적합한 경우 | 초기 개발, 소~중규모 트래픽 | 보안 민감 데이터, 월 1,500만 토큰 이상 |
2.5. 검색 속도 (Latency)
임베딩 모델의 차원 수와 모델 크기는 검색 응답 속도에 직접 영향을 줍니다. 실시간 챗봇처럼 응답 속도가 중요한 서비스라면 차원이 작고 경량인 모델이 유리합니다. 반면 배치 처리 위주의 오프라인 인덱싱 파이프라인이라면 속도보다 품질을 우선할 수 있습니다.
응답 속도 우선 → 소형 모델 (all-MiniLM-L6-v2, voyage-4-lite)
품질 우선 → 대형 모델 (E5-mistral-7b, NV-Embed-v2)
2.6 도메인 특화 여부
임베딩 모델은 학습 데이터의 도메인에 따라 성능 편차가 큽니다. 일반 텍스트에서 높은 MTEB 점수를 기록한 모델도 의료·법률·금융·코드처럼 전문 용어가 많은 도메인에서는 성능이 크게 떨어질 수 있습니다.
- 일반 도메인: OpenAI, Cohere, BGE-M3 등 범용 모델로 충분합니다.
- 코드 검색: text-embedding-3-large는 코드에서도 무난하지만, Voyage AI의 voyage-code-3 같은 코드 특화 모델이 더 높은 성능을 발휘합니다.
- 의료·법률: 전문 용어로 파인튜닝된 도메인 특화 모델이 유리하며, 없다면 범용 대형 모델 중 MTEB 점수가 높은 것을 선택하고 반드시 자체 데이터로 검증해야 합니다.
2.7 모델 업데이트 정책
API 기반 모델은 제공사가 모델을 업데이트할 때 벡터 공간이 변경될 수 있습니다. 이 경우 기존에 저장된 모든 벡터를 새 모델로 전체 재인덱싱해야 합니다. 문서가 수백만 건에 달하는 시스템에서는 재인덱싱 비용과 다운타임이 상당합니다.
- API 방식 사용 시 제공사의 모델 버전 관리 정책을 반드시 확인해야 합니다.
- OpenAI는 모델명에 버전을 명시(text-embedding-3-small)하여 기존 버전을 유지할 수 있습니다.
- 자체 호스팅 오픈소스 모델은 업데이트 시점을 직접 통제할 수 있다는 장점이 있습니다.
2.8 벡터 DB 호환성
사용 중인 벡터 DB에 따라 특정 임베딩 모델과의 네이티브 연동 지원 여부가 달라집니다.
| 벡터 DB | 네이티브 지원 임베딩 |
| Pinecone | OpenAI, Cohere, Voyage AI |
| Weaviate | OpenAI, Cohere, Hugging Face 모델 |
| Qdrant | 모델 무관 (벡터 직접 입력) |
| pgvector | 모델 무관 (벡터 직접 입력) |
네이티브 지원 모델을 사용하면 별도의 임베딩 호출 코드 없이 DB가 자동으로 임베딩을 생성해주므로 파이프라인 구성이 단순해집니다. 단, 이 편의성에 종속되면 나중에 모델 교체가 어려워질 수 있습니다.
3. 주요 임베딩 모델 종류
3.1 OpenAI text-embedding-3 시리즈
API 기반 임베딩 모델 중 가장 널리 사용되는 모델입니다. 현재 주력은 text-embedding-3-small과 text-embedding-3-large 두 가지입니다.
모델 차원 최대 토큰 가격
| 모델 | 차원 | 최대 토큰 | 가격 |
| text-embedding-3-small | 1,536 | 8,191 | $0.02 / 100만 토큰 |
| text-embedding-3-large | 3,072 | 8,191 | $0.13 / 100만 토큰 |
특징
MRL을 지원하여 API 호출 시 dimensions 파라미터로 차원을 줄일 수 있습니다. text-embedding-3-large를 1,024차원으로 줄이면 text-embedding-3-small 전체 차원보다 검색 품질이 높으면서도 저장 공간은 절약됩니다. 한국어를 포함한 다국어를 지원하며, LangChain·LlamaIndex 등 주요 프레임워크와의 연동이 간편합니다.
장점
- 별도 인프라 없이 API 호출만으로 즉시 사용 가능합니다.
- 다국어 지원으로 한국어 RAG에도 바로 적용할 수 있습니다.
- 차원 축소 기능으로 비용과 품질을 탄력적으로 조정할 수 있습니다.
단점
- 텍스트가 OpenAI 서버로 전송되므로 보안이 엄격한 환경에서는 사용이 제한될 수 있습니다.
- text-embedding-3-large는 small 대비 MTEB 점수 차이가 2.34점에 불과한데 가격은 6.5배입니다.
- 모델 업데이트 시 벡터 공간이 바뀌면 전체 재인덱싱이 필요합니다.
3.2 Cohere Embed
Cohere에서 제공하는 API 기반 임베딩 모델로, 검색 시나리오에 특화된 설계가 특징입니다.
| 모델 | 차원 | 최대 토큰 | 가격 |
| Cohere Embed v4 | 1,024 | 512 | $0.12 / 100만 토큰 |
특징
가장 큰 차별점은 input_type 파라미터입니다. 문서를 임베딩할 때는 "search_document", 질문을 임베딩할 때는 "search_query"로 지정합니다. 모델이 입력의 용도를 알고 있으므로 질문 벡터와 문서 벡터가 검색에 더 유리한 공간에 배치됩니다. 또한 Cohere는 리랭킹 모델(Rerank)도 함께 제공하므로, 임베딩 검색과 리랭킹을 하나의 API 제공자에서 일관되게 사용할 수 있습니다.
2026년 출시된 Embed v4는 텍스트와 이미지를 동일한 벡터 공간에 임베딩하는 멀티모달 기능을 지원합니다.
장점
- 질문·문서를 용도에 따라 다르게 임베딩하여 검색 정밀도가 높습니다.
- 100개 이상 언어를 지원하여 다국어 환경에 적합합니다.
- Rerank 모델과 함께 쓰면 엔드투엔드 검색 파이프라인을 단일 API로 구성할 수 있습니다.
단점
- 최대 입력 토큰이 512로 OpenAI 대비 짧아, 긴 청크 처리 시 주의가 필요합니다.
- 데이터가 외부로 전송됩니다.
3.3 Sentence-BERT(SBERT) 계열
BERT를 문장 유사도 비교에 최적화하여 재학습시킨 오픈소스 모델군입니다. sentence-transformers 라이브러리를 통해 로컬에서 실행할 수 있습니다.
원래 BERT는 두 문장의 유사도를 구하려면 두 문장을 함께 모델에 입력해야 했습니다. 문서 1만 건 중 가장 유사한 것을 찾으려면 1만 번 쌍으로 묶어 모델을 통과시켜야 했습니다. SBERT는 각 문장을 독립적인 벡터로 변환하도록 재학습시켜 이 문제를 해결했습니다.
| 모델 | 차원 | 최대 토큰 | 다국어 | 특징 |
| all-MiniLM-L6-v2 | 384 | 256 | X | CPU 실행 가능, 초경량 |
| all-mpnet-base-v2 | 768 | 384 | X | SBERT 계열 중 고품질 |
| paraphrase-multilingual-mpnet-base-v2 | 768 | 128 | O | 50개 이상 언어 지원 |
장점
- 완전한 오픈소스로 데이터가 외부로 전송되지 않습니다.
- all-MiniLM-L6-v2는 CPU에서도 실행 가능해 GPU 없이 시작할 수 있습니다.
- API 비용이 전혀 없습니다.
단점
- 최대 입력 토큰이 128~384로 짧아, 청크 크기 설정에 제약이 생깁니다.
- 영어 전용 모델은 한국어 성능이 떨어집니다.
- 고성능 모델일수록 GPU 인프라가 필요합니다.
3.4 BGE (BAAI General Embedding)
중국의 BAAI(Beijing Academy of Artificial Intelligence)에서 개발한 오픈소스 임베딩 모델입니다. 공개 당시 MTEB 리더보드 상위권을 차지하며 주목받았습니다.
| 모델 | 차원 | 최대 토큰 | 다국어 |
| bge-large-en-v1.5 | 1,024 | 512 | X |
| bge-m3 | 1,024 | 8,192 | O (100개 이상) |
특징
bge-m3는 세 가지 검색 방식을 하나의 모델에서 지원합니다.
Dense Retrieval → 벡터 유사도 기반 시맨틱 검색
Sparse Retrieval → BM25 유사 키워드 검색
Multi-Vector → 토큰 단위 세밀한 매칭 (ColBERT 방식)
하이브리드 검색을 단일 모델로 처리할 수 있다는 점이 가장 큰 강점입니다. 또한 최대 8,192 토큰을 지원해 긴 문서도 처리할 수 있습니다. 2026년 기준 100개 이상의 언어를 지원하도록 확장되었습니다.
장점
- bge-m3 하나로 Dense + Sparse + Multi-Vector 검색을 모두 커버합니다.
- 오픈소스이며 자체 서버에서 실행할 수 있습니다.
- 8,192 토큰의 긴 컨텍스트 윈도우를 지원합니다.
단점
- bge-large 계열은 검색 시 질문 앞에 지시문("Represent this sentence:")을 붙여야 합니다.
- 고성능 모델은 GPU 메모리를 상당히 차지합니다.
3.5 E5 (Microsoft)
Microsoft에서 개발한 오픈소스 임베딩 모델입니다. 질문과 문서에 각각 "query:", "passage:" 접두사를 붙이는 지시문 기반 설계가 특징입니다.
| 모델 | 차원 | 최대 토큰 | 다국어 |
| e5-large-v2 | 1,024 | 512 | X |
| multilingual-e5-large | 1,024 | 512 | O |
| e5-mistral-7b-instruct | 4,096 | 32,768 | O |
특징
e5-mistral-7b-instruct는 기존 BERT 기반이 아닌 Mistral 7B LLM을 백본으로 사용합니다. 대규모 언어 모델의 풍부한 언어 이해력을 임베딩에 활용하는 방식으로, MTEB 리더보드에서 높은 성능을 기록했습니다. 단, 모델 크기가 크고 추론 속도가 느린 것이 단점입니다.
장점
- multilingual-e5-large는 한국어를 포함한 다국어에서 안정적인 성능을 보입니다.
- 오픈소스로 자체 호스팅이 가능합니다.
단점
- 지시문 접두사를 빠트리면 성능이 크게 저하됩니다.
- e5-mistral-7b-instruct는 추론 속도가 느리고 GPU 메모리 요구량이 높습니다.
3.6 GTE (Alibaba)
Alibaba에서 개발한 오픈소스 임베딩 모델입니다. 지시문 없이도 높은 성능을 내는 것이 특징입니다.
| 모델 | 차원 | 최대 토큰 | 다국어 |
| gte-large-en-v1.5 | 1,024 | 8,192 | X |
| gte-Qwen2-7B-instruct | 3,584 | 32,768 | O |
gte-Qwen2 시리즈는 E5-mistral과 마찬가지로 LLM(Qwen2)을 백본으로 활용합니다. MTEB 리더보드에서 최상위권 성능을 기록하고 있습니다.
3.7 NV-Embed (NVIDIA)
NVIDIA에서 개발한 오픈소스 임베딩 모델입니다. NV-Embed-v2는 2025~2026년 기준 MTEB 영어 리더보드에서 전체 1위를 기록한 모델입니다. LLM 기반 임베딩과 지시문 학습을 결합한 방식으로 설계되었습니다. 단, NVIDIA GPU 환경에서의 추론에 최적화되어 있어 환경 구성 부담이 있습니다.
3.8 Voyage AI
검색 특화 임베딩 모델을 제공하는 API 서비스입니다.
| 모델 | 차원 | 최대 토큰 | 가격 |
| voyage-4-large | 1,024 | 32,000 | $0.18 / 100만 토큰 |
| voyage-4 | 1,024 | 32,000 | $0.12 / 100만 토큰 |
| voyage-4-lite | 512 | 32,000 | $0.03 / 100만 토큰 |
RAG의 검색(Retrieval) 성능에 특화하여 최적화된 모델입니다. voyage-4-large는 MTEB 검색 특화 벤치마크에서 상위권 성능을 기록하고 있으며, 32,000 토큰의 긴 컨텍스트 윈도우가 강점입니다. MoE(Mixture of Experts) 아키텍처를 적용해 서빙 비용을 40%까지 절감했습니다.
4. 비용 비교
4.1 API 방식 비용
| 모델 | 가격 (100만 토큰 당) | 특이사항 |
| text-embedding-3-small | $0.02 | 가장 저렴한 API |
| Gemini Embedding | $0.025 | 무료 티어 존재 |
| voyage-4-lite | $0.03 | 검색 특화, 저가형 |
| Cohere Embed v4 | $0.12 | 멀티모달 지원 |
| text-embedding-3-large | $0.13 | small 대비 6.5배 |
| voyage-4-large | $0.18 | 검색 특화 프리미엄 |
100만 토큰은 약 70만 단어 분량입니다. 중간 규모 문서 코퍼스를 인덱싱하는 데 드는 비용은 API 방식 기준 대부분 수 달러 이내입니다.
4.2 자체 호스팅 비용
| 규모 | 적합한 방식 | 근거 |
| 월 1,500만 토큰 미만 | API 방식 | 인프라 비용 대비 API가 저렴 |
| 월 1,500만 토큰 이상 | 자체 호스팅 고려 | 손익분기점 진입 |
| 보안 민감 데이터 | 자체 호스팅 필수 | 데이터 외부 전송 불가 |
자체 호스팅의 경우, BGE-M3를 A100 스팟 인스턴스에서 실행하면 100만 토큰당 약 $0.001 수준으로 OpenAI text-embedding-3-small 대비 약 20배 저렴합니다.
4.3 차원 축소로 비용 최적화
MRL을 지원하는 모델은 차원을 줄여 저장 및 검색 비용을 절감할 수 있습니다.
text-embedding-3-large (3,072차원) 기준:
- 3,072차원: 최고 품질, 최대 저장 비용
- 1,024차원: 품질 손실 미미, 저장 비용 66% 절감
- 512차원: 적당한 품질, 저장 비용 83% 절감
실무 권장: 1,024차원으로 시작 → 품질 부족 시 증가
5. 모델별 장단점 비교 요약
| 모델 | 검색 품질 | 다국어 | 비용 | 데이터 보안 | 구현 난이도 |
| OpenAI text-embedding-3-small | 보통 | O | 낮음 | 낮음 | ⭐ 쉬움 |
| OpenAI text-embedding-3-large | 높음 | O | 보통 | 낮음 | ⭐ 쉬움 |
| Cohere Embed v4 | 높음 | O | 보통 | 낮음 | ⭐⭐ 보통 |
| all-MiniLM-L6-v2 | 낮음~보통 | X | 무료 | 높음 | ⭐ 쉬움 |
| BGE-M3 | 높음 | O | 무료 | 높음 | ⭐⭐⭐ 높음 |
| E5-mistral-7b | 매우 높음 | O | 무료 | 높음 | ⭐⭐⭐⭐ 매우 높음 |
| NV-Embed-v2 | 최고 | X | 무료 | 높음 | ⭐⭐⭐⭐ 매우 높음 |
| Voyage AI voyage-4 | 매우 높음 | 제한적 | 보통 | 낮음 | ⭐⭐ 보통 |
6. 용도별·상황별 임베딩 모델 선택 기준
6.1 빠른 프로토타이핑 / 초기 개발
추천: text-embedding-3-small
인프라 없이 API 호출만으로 즉시 시작할 수 있습니다. 비용이 낮고 LangChain·LlamaIndex와 연동이 간단합니다. 성능이 부족하면 나중에 large로 교체하거나 오픈소스 모델로 전환합니다.
6.2 한국어 서비스
추천: text-embedding-3-small 또는 multilingual-e5-large 또는 BGE-M3
세 모델 모두 한국어를 지원합니다. API 방식을 선호한다면 text-embedding-3-small이 가장 간편합니다. 자체 호스팅이 가능하다면 BGE-M3가 한국어 품질과 긴 컨텍스트 지원 면에서 유리합니다.
6.3 보안 민감 데이터 (의료, 금융, 법률)
추천: BGE-M3 또는 E5-mistral-7b (자체 호스팅)
데이터가 외부로 전송되면 안 되는 환경에서는 오픈소스 모델을 자체 서버에서 운영해야 합니다. BGE-M3는 성능과 다국어 지원을 모두 갖추고 있으며, 더 높은 품질이 필요하다면 E5-mistral-7b를 검토합니다.
6.4 대규모 운영 (비용 최적화 필요)
추천: BGE-M3 (자체 호스팅) 또는 text-embedding-3-small (API, 월 1,500만 토큰 미만)
월 1,500만 토큰 이하라면 API가 자체 호스팅보다 경제적입니다. 이를 초과한다면 오픈소스 자체 호스팅의 손익분기점이 넘어 비용 절감 효과가 커집니다.
6.5 검색 품질 최우선
추천: Voyage AI voyage-4-large 또는 NV-Embed-v2
API로 간단하게 최고 품질을 원한다면 voyage-4-large가 검색 특화 벤치마크에서 가장 안정적입니다. 자체 호스팅 환경에서 절대 성능을 원한다면 NV-Embed-v2를 선택합니다.
6.6 멀티모달 문서 (텍스트 + 이미지 혼합)
추천: Cohere Embed v4
텍스트와 이미지를 동일한 벡터 공간에 임베딩하여 이미지가 포함된 문서 검색이 가능합니다. 슬라이드 자료, 카탈로그, 이미지가 많은 매뉴얼 등에 적합합니다.
6.7 하이브리드 검색을 단일 모델로 처리
추천: BGE-M3
Dense + Sparse + Multi-Vector 검색을 하나의 모델로 처리합니다. 별도의 BM25 인덱스 없이도 키워드 검색과 시맨틱 검색을 결합한 하이브리드 검색이 가능합니다.
7. 상황별 모델 선택 요약표
| 상황 | 추천 모델 | 이유 |
| 빠른 프로토타이핑 | text-embedding-3-small | 간편한 API, 낮은 비용 |
| 한국어 서비스 (API) | text-embedding-3-small | 다국어 지원, 간편 연동 |
| 한국어 서비스 (자체 호스팅) | BGE-M3 | 한국어 품질 + 긴 컨텍스트 |
| 보안 민감 데이터 | BGE-M3 / E5-mistral-7b | 자체 호스팅, 데이터 외부 전송 없음 |
| 비용 최우선 | all-MiniLM-L6-v2 | 무료 오픈소스, CPU 실행 가능 |
| 검색 품질 최우선 | voyage-4-large / NV-Embed-v2 | 검색 특화 최고 성능 |
| 멀티모달 문서 | Cohere Embed v4 | 텍스트 + 이미지 동시 임베딩 |
| 하이브리드 검색 단일화 | BGE-M3 | Dense + Sparse 동시 지원 |
8. 실무 적용 순서
임베딩 모델을 선택하는 실무적인 접근 순서는 다음과 같습니다.
(MTEB 점수는 참고 지표일 뿐입니다. 최종 판단은 반드시 자체 도메인 데이터로 직접 측정하여 내리는 것이 가장 신뢰할 수 있습니다.)
1단계: text-embedding-3-small로 빠르게 프로토타입 구성
↓ 검색 품질 측정 (RAGAS, DeepEval 등 활용)
↓ 품질 부족 또는 비용/보안 이슈가 있다면
2단계: 요구 사항에 따라 분기
├─ 품질 향상 필요 + API 유지 → text-embedding-3-large 또는 voyage-4
├─ 보안/비용 이슈 → BGE-M3 자체 호스팅
└─ 한국어 품질 부족 → multilingual-e5-large 또는 BGE-M3
↓ 최종 결정 전
3단계: 자체 데이터로 A/B 테스트
→ 후보 모델 2~3개를 동일 질문 셋으로 Recall@10, MRR 비교
→ 수치로 최종 모델 결정
9. 핵심 요약
좋은 임베딩 모델은 "MTEB 점수가 가장 높은 모델"이 아니라 "우리 서비스의 데이터와 제약 조건에 가장 잘 맞는 모델"입니다. text-embedding-3-small로 시작해 품질을 측정한 뒤, 필요에 따라 단계적으로 고도화하는 접근이 가장 현실적입니다.
| 항목 | 핵심 내용 |
| 임베딩 모델의 역할 | 텍스트 → 벡터 변환, 의미적 유사도 기반 검색의 토대 |
| 선택 시 핵심 속성 | 차원, 최대 토큰, 다국어 지원, API vs 자체 호스팅, 검색 속도, 도메인 특화, 모델 업데이트 정책, 벡터 DB 호환성 |
| 범용 시작 모델 | text-embedding-3-small |
| 한국어 + 자체 호스팅 | BGE-M3 |
| 검색 품질 최고 | voyage-4-large (API), NV-Embed-v2 (자체 호스팅) |
| 비용 최저 | all-MiniLM-L6-v2 (무료), text-embedding-3-small ($0.02/100만 토큰) |
| 성능 벤치마크 기준 | MTEB — Retrieval 범주 점수 우선 확인 |
| 자체 호스팅 손익분기점 | 월 1,500만 토큰 전후 |
| 최종 결정 기준 | MTEB가 아닌 자체 데이터 실험 결과 |
10. 참고 자료
- https://huggingface.co/spaces/mteb/leaderboard
- https://awesomeagents.ai/leaderboards/embedding-model-leaderboard-mteb-march-2026/
- https://app.ailog.fr/en/blog/guides/choosing-embedding-models
- https://pecollective.com/tools/text-embedding-models-compared/
- https://pecollective.com/tools/best-embedding-models/
- https://futureagi.com/blog/best-embedding-models-2025/
- https://www.grizzlypeaksoftware.com/library/embedding-model-comparison-openai-vs-cohere-vs-open-source-we1f6fgu
- https://checkthat.ai/answers/what-are-the-best-embedding-models
- https://wikidocs.net/293578

'IT > AI' 카테고리의 다른 글
| Windows에 Qdrant 설치하기 (0) | 2026.07.07 |
|---|---|
| LLM 오케스트레이션이란? 개념부터 파이프라인 패턴 및 선택기준까지 완벽 가이드 (0) | 2026.07.06 |
| RAG 검색 최적화 전략이란? 하이브리드 검색·리랭킹·HyDE 종류별 장단점과 문서 유형별 적용 가이드 (0) | 2026.06.24 |
| RAG 문서 청킹 전략 완벽 가이드 (0) | 2026.06.22 |
| RAG 완전 정복: 벡터DB 데이터 조회 파이프라인 전체 프로세스 상세 가이드 (0) | 2026.06.07 |
댓글