Benchmark di Open Source Embedding Models per RAG

NVIDIA Llama-Embed-Nemotron-8B guida in accuratezza. Sul costo, EmbeddingGemma-300m di Google costa circa 4x in meno rispetto a Nemotron a fronte di una piccola perdita di accuratezza.

Risultati del benchmark di open source embedding models

Metriche spiegate

nDCG@3: Guadagno cumulativo scontato normalizzato al cutoff 3. Con un solo documento rilevante per query, è 1 / log2(rank + 1) quando il documento gold rientra nei primi 3, e 0 altrimenti. Il rank 1 ottiene 1.000, il rank 2 ottiene 0.631 e il rank 3 ottiene 0.500. Utilizziamo nDCG@3 come metrica primaria perché le pipeline di produzione RAG alimentano i primi 3-5 chunk al LLM, e il bias di primacy fa sì che il rank 1 conti in modo sproporzionato.

nDCG@10: Stessa formula con cutoff 10.

Recall@10: Frazione di query in cui il documento gold compare nei primi 10.

MRR@10: Mean reciprocal rank al cutoff 10. Il rank 1 ottiene 1.000, il rank 2 ottiene 0.500 e il rank 10 ottiene 0.100. Intento simile a nDCG@3 ma con una penalità di rank più ripida.

Top-1 hit: Frazione di query in cui il documento gold rilevante è l'unico risultato in cima. La metrica più rigorosa e quella più vicina a un flusso di lavoro di lookup senza LLM.

Risultati nDCG@3 per dominio

La classifica AVG nasconde inversioni di dominio. Harrier vince CUAD ma è settimo su TechQA. SFR-2 è secondo su TechQA ma solo quarto su CUAD. KaLM-12B è quinto su MedRAG e nono su TechQA. nDCG@3 per dominio:

BM25 è competitivo su MedRAG (0.7862, battendo PubMedBERT e il Granite multilingue) e debole su CUAD (0.5844, dove 11 dei 14 dense models lo superano). I contratti legali contengono linguaggio denso di entità che premia la corrispondenza lessicale. Sugli abstract medici, i migliori dense models (Nemotron 0.9629, SFR-2 0.9620, jina-v5 0.9523) superano BM25 di 0.17–0.18 punti assoluti di nDCG@3.

Gli intervalli di confidenza bootstrap al 95% per cella (model, domain), compreso un pareggio a quattro su MedRAG in cima e una sovrapposizione Harrier-Nemotron su CUAD che la classifica puntuale appiattisce, sono riportati nella sezione metodologia del benchmark.

Costo per milione di token

Il costo self-hosted è ammortizzato sulla GPU: tariffa oraria divisa per i token processati all'ora. Il pod utilizzato era un H100 80GB SXM5 di RunPod community-cloud a $2,99/ora. Il tempo wall-clock per model attraverso il passaggio con 551 query e 3 corpora (~46.2M token totali) produce le seguenti stime di $/1M token:

La formula:

GPU $/ora = $2,99 (tariffa del pod RunPod community H100 80GB SXM5 che abbiamo usato). wall_seconds = tempo wall-clock totale di ciascun model nel passaggio con 551 query e 3 corpora. total_tokens ≈ 46.22M (somma di 3 corpora + 551 query, conteggio caratteri ÷ 4 euristica).

Esempio svolto, Nemotron-8B: ($2,99 / 3600) × (1247.8 × 1.000.000 / 46.220.000) = $0,0224 per 1M tokens.

Cinque models guidano la loro fascia di costo (nessun'altra riga costa meno e ottiene un punteggio più alto): Granite-278m-multilingual in fondo alla scala dei costi, poi Granite-small-r2, EmbeddingGemma-300m, jina-v5-text-small e Nemotron-8B in cima alla scala della qualità. Gli estremi coprono 13x di costo (da $0,0017/M a $0,0224/M) e 0.23 nDCG@3 assoluti (da 0.6952 a 0.9249).

Specialisti di dominio vs generalisti

PubMedBERT, fine-tuned su coppie titolo-abstract di PubMed, è il ovvio "strumento giusto" per il retrieval medicale RAG su PubMed. Ottiene nDCG@3 = 0.7084 su MedRAG, che è sotto la baseline lessicale BM25 (0.7862) sullo stesso corpus. I generalisti open source moderni lo superano di 0.22–0.25 punti assoluti nel dominio dei suoi dati di addestramento:

Il motivo per cui lo specialista sottoperforma è l'età e la ricetta. PubMedBERT è un BERT da 110M parametri del 2022 con mean pooling simmetrico e nessun prefisso di istruzione. I generalisti 2024-2026 sono costruiti su backbone più grandi, prefissi asimmetrici per query e documenti e obiettivi di retrieval instruction-tuned. Il divario architetturale conta più della corrispondenza di dominio: un fine-tune di 4 anni non può tenere il passo di un retriever instruction-tuned di generazione attuale, nemmeno sul corpus di addestramento del fine-tune stesso.

La regola per il buyer è testare uno specialista di dominio contro un generalista moderno su query rappresentative prima di distribuirlo. L'assunto che "lo specialista vincerà nel suo dominio" non è più sicuro per gli open source embedding models nel 2026.

Risultati dal benchmark di open source embedding

Il vantaggio di Nemotron-8B su TechQA è statisticamente separato dal secondo posto

Nemotron-8B nDCG@3 AVG = 0.9249. Per dominio ottiene 0.8602 su CUAD, 0.9515 su TechQA e 0.9629 su MedRAG. Il risultato TechQA (0.9515 0.923, 0.977) non si sovrappone al secondo classificato SFR-Embedding-2_R (0.9109 0.869, 0.949). I CI bootstrap sono nettamente separati. La base 8B Llama-3.1, instruction-tuned per il retrieval con un prefisso lato query Instruct: …\nQuery: … e un prefisso simmetrico lato documento, determina un vantaggio assoluto di 0.04 nDCG@3 sulla riga successiva nei carichi di lavoro di supporto a documenti lunghi.

I due domini in cui Nemotron vince nettamente (TechQA, MedRAG) sono i corpora di documenti lunghi dove l'asimmetria dei prefissi di istruzione conta di più. CUAD è l'unico dominio in cui non è in testa: Harrier-oss-v1-0.6b di Microsoft (0.8720) supera Nemotron (0.8602) sui contratti legali pur essendo 13x più piccolo, sebbene i CI si sovrappongano e il vantaggio non sia statisticamente separato a questa dimensione del campione.

Un 0.6B model Harrier di Microsoft supera ogni open model sotto i 7B parametri

Microsoft Harrier-oss-v1-0.6b (rilasciato 2026-04 con base Qwen3-0.6B e licenza MIT) ottiene nDCG@3 AVG = 0.8911, quarto in assoluto. Supera il 12B KaLM-Gemma3 di Tencent (0.8057, licenza community Tencent), il 7B SFR-Embedding-2_R di Salesforce su CUAD (0.8421 vs Harrier 0.8720), e EmbeddingGemma-300m di Google (0.8706). In un confronto a parità di architettura, Harrier-0.6b (0.8911) è 0.074 nDCG@3 sopra Qwen3-Embedding-0.6B (0.8168), costruito sulla identica base Qwen3-0.6B. Il corpus di addestramento e la ricetta di istruzione hanno determinato il divario, non il numero di parametri.

Per i buyer, Harrier è la riga open source con il ranking più alto a essere distribuita con una licenza adatta all'uso commerciale senza restrizioni. SFR-2 (CC-BY-NC), Nemotron (NSCL-v1) e jina-v5 (CC-BY-NC) lo superano nella scala AVG, ma tutti e tre sono solo per ricerca o non commerciali.

Un embedder medico specialista perde contro BM25

PubMedBERT-base-embeddings di NeuML è stato fine-tuned su coppie titolo-abstract di PubMed. È l'ovvio "strumento giusto" per un benchmark RAG medico su PubMed. Ottiene nDCG@3 = 0.7084 su MedRAG, che è 0.078 assoluti sotto la baseline lessicale BM25 (0.7862) sullo stesso corpus. I migliori generalisti open source su MedRAG si collocano molto al di sopra di entrambi: Nemotron-8B 0.9629, SFR-Embedding-2_R 0.9620, Harrier-oss 0.9605, jina-v5 0.9523, KaLM-Gemma3-12B 0.9453.

Questa è l'inversione che dovrebbe cambiare il modo in cui un buyer sceglie uno specialista di dominio. PubMedBERT è un BERT da 110M parametri del 2022, con mean pooling simmetrico e nessun prefisso di istruzione. Il campo generalista 2024-2026 è costruito su backbone più grandi, prefissi asimmetrici per query e documenti e obiettivi di retrieval instruction-tuned. Sulle query MedRAG che includono già vocabolario medico, la corrispondenza lessicale di BM25 è naturalmente forte, e la specializzazione di PubMedBERT non aggiunge nulla al di sopra.

La conclusione pratica è non scegliere un embedder specialista solo per nome. Effettua un benchmark sulle tue query prima di impegnarti.

Snowflake Arctic oscilla di 0.32 nDCG@3 tra i domini

Snowflake-arctic-embed-l-v2.0 (568M, Apache-2.0, derivato bge-m3-retromae, multilingue) ottiene nDCG@3 = 0.5846 sui contratti legali CUAD e 0.9053 sugli abstract medici MedRAG. Lo stesso model, stessa ricetta, stesso formato di query, con un'oscillazione di 0.32 punti tra due domini. Altri models nella gamma oscillano meno: SFR-2 va da 0.8421 a 0.9620 (gap 0.12), Nemotron va da 0.8602 a 0.9629 (gap 0.10), Harrier va da 0.8408 a 0.9605 (gap 0.12).

Il meccanismo è la composizione dei dati di addestramento. Arctic è stato ottimizzato su BEIR, MIRACL e CLEF; i contratti legali non sono rappresentati. Per un carico di lavoro di retrieval verticale, i dati di addestramento di dominio contano più del numero di parametri o della lunghezza del contesto.

Come funziona l'inference di embedding open source

Gli open source embedding models vengono eseguiti in due backend in questo benchmark: sentence-transformers (12 models) e vLLM (4 models). La divisione non riguarda la qualità, ma l'efficienza a runtime sui model da 8B in su, dove il loop di inference Python predefinito di sentence-transformers è troppo lento per essere gestibile.

La ricetta per model conta più della scelta del backend. I retrieval models moderni usano prefissi asimmetrici: il lato query è avvolto in un prompt in stile Instruct (Instruct: Given a question, retrieve passages...\nQuery: <text>) mentre il lato documento è semplice. Il tipo di pooling varia: i model derivati da BERT usano CLS pooling; i model derivati da LLM (Llama, Mistral, Qwen3, base Gemma3) usano last-token pooling; i model multilingue usano spesso mean pooling. La scheda HuggingFace di ciascun model è la fonte di verità per quale combinazione di prefisso e pooling sia corretta.

Livello backend:

• vLLM: Nemotron-8B, KaLM-Gemma3-12B, jina-v5-text-small
• sentence-transformers: Qwen3-0.6B, EmbeddingGemma-300m, Granite trio, SFR-2, Conan-v1, PubMedBERT, GIST, Snowflake Arctic, Microsoft Harrier

Pattern di prefissi asimmetrici osservati:

• Instruct + Query/Document: SFR-2, KaLM-Gemma3, Nemotron-8B, Qwen3-Embedding
• Built-in encode_query / encode_document: EmbeddingGemma, KaLM-Gemma3, Nemotron-8B
• task / prompt_name (parametro sentence-transformers): jina-v5, Snowflake Arctic, Harrier
• Nessun prefisso (simmetrico): Granite trio, Conan, PubMedBERT, GIST

Tipo di pooling per architettura di base:

• CLS pooling: Granite r2 trio, Snowflake Arctic
• Last-token pooling: Nemotron, KaLM-Gemma3, SFR-2, jina-v5, Qwen3-Embedding, Harrier
• Mean pooling: EmbeddingGemma, Granite-multilingual, Conan, PubMedBERT, GIST

Usare la ricetta sbagliata degrada silenziosamente la qualità del retrieval senza crash. Qualsiasi benchmark di embedder open source dovrebbe includere una soglia di sanity (Recall@10 sotto 0.5 in tutti i domini per qualsiasi model è un campanello d'allarme per una configurazione errata, non un risultato).

Non perderti i nostri benchmark e approfondimenti basati sui dati. Il pulsante apre Google; selezionare AIMultiple conferma che desideri vedere AIMultiple più spesso nei risultati di ricerca di Google.

Aggiungi come fonte preferita

Metodologia del benchmark di open source embedding models

Sono stati valutati tre domini di retrieval: contratti legali CUAD (246 query, 509 contratti), note tecniche di supporto clienti TechQA (151 query, 28000 note tecniche IBM), abstract sanitari MedRAG-PubMed (154 query, 50000 abstract). Totale 551 query.

La metodologia di costruzione del dataset è condivisa con il nostro precedente benchmark di embedding models inglese: generazione di query per consenso Protocol-A con 3-LLM (pool di writer rotante, scorer fisso, due validatori non writer per tentativo), pinning del corpus tramite hash SHA-256, whitelist di token entità vietati per dominio per prevenire scorciatoie lessicali di BM25, accordo inter-valutatore Cohen’s κ riportato per coppia di validatori, rank di baseline BM25 sintetizzati dal campo bm25_rank_at_target già presente in ogni JSON di query (equivalente a Pyserini). Metrica primaria nDCG@3 (realistica per RAG, ciò che consumano i sistemi RAG di produzione); metriche secondarie nDCG@10, Recall@10, Recall@100, MRR@10, Top-1 hit.

Specifiche open source:

• GPU: 1 x NVIDIA H100 80GB SXM5 tramite RunPod community cloud
• Template pod: runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404
• Stack: PyTorch 2.10.0+cu128, vLLM 0.19.1, transformers 5.6.2, sentence-transformers 5.4.1
• Dispatch per model: scheda model HF percorso primario. ST per 12 models, vLLM per Nemotron-8B, KaLM-Gemma3-12B, jina-v5-text-small.
• Chunking per model: troncamento a livello di carattere a max_seq_length x 4 caratteri per token, poi il tokenizer del model tronca alla sua effettiva lunghezza massima di sequenza.
• Retrieval asimmetrico: ogni model che lo supporta riceve il prefisso di query e documento documentato sulla scheda HF. Nessun prefisso è il default documentato per alcuni.
• Normalizzazione L2: applicata uniformemente dopo il pooling. Alcuni models lo fanno internamente. Rinomizziamo per garantire parità su tutta la gamma.
• Chiave cache embedding: include prefisso + task + prompt_name + max_seq + backend, in modo che un cambio di prefisso a metà esecuzione non possa caricare silenziosamente embedding obsoleti.
• Protocollo statistico: 10K ricampionamenti bootstrap per cella (model, domain, metric), CI percentile 95%, seed=2026.

Models testati

Ordinati per rank nDCG@3 AVG. Colonna backend: ST = sentence-transformers, vLLM = vLLM 0.19.

Risultati degli intervalli di confidenza bootstrap al 95%

La classifica completa sopra è single-run per cella (model, domain). La varianza model-init cross-session non è misurata. Per catturare la varianza a livello di query all'interno di una run, ricampioniamo il vettore di rank per query per ogni cella (model, domain) 10.000 volte con rimpiazzo (metodo percentile, seed=2026, dimensioni campionarie CUAD n=246, TechQA n=151, MedRAG n=154). CI bootstrap al 95% per dominio su nDCG@3:

I CI cambiano le inversioni supportate dai dati. Su CUAD, Harrier (0.8720, [0.836, 0.906]) e Nemotron (0.8602, [0.821, 0.897]) si sovrappongono, quindi il vantaggio di Harrier su CUAD non è nettamente separato a questa dimensione campionaria. Su TechQA, Nemotron (0.9515, [0.923, 0.977]) e SFR-2 (0.9109, [0.869, 0.949]) non si sovrappongono, quindi il vantaggio di Nemotron su TechQA è statisticamente separato. Su MedRAG, i primi quattro (Nemotron 0.9629, SFR-2 0.9620, Harrier 0.9605, jina-v5 0.9523) sono dentro i CI l'uno dell'altro e formano un pareggio statistico a quattro. L'inversione PubMedBERT sotto BM25 su MedRAG (0.7084 [0.641, 0.772] vs BM25 0.7862) è al margine della sovrapposizione. La tendenza centrale colloca chiaramente lo specialista sotto BM25, ma è necessario un passaggio cross-session a 3 run per stabilire se è separato piuttosto che sovrapposto.

Limitazioni

Singola run per cella (model, domain). La tabella CI bootstrap sopra cattura la varianza a livello di query all'interno della run (10K ricampionamenti, metodo percentile, seed=2026), ma la varianza model-init cross-session non è misurata. È previsto un passaggio cross-midnight a 3 run per v2.1. I pareggi più stretti emersi dalla tabella CI (ad es. il pareggio a quattro su MedRAG in cima, la sovrapposizione Harrier-Nemotron su CUAD, l'inversione marginale PubMedBERT-vs-BM25) trarrebbero il massimo beneficio dal passaggio multi-run.

Confondimento della lunghezza di contesto per model. I models con finestre di contesto da 512 token (Granite-278m-multilingual, PubMedBERT, Conan, GIST) vedono solo i primi ~2K caratteri di ogni documento. I models con contesto 8K o 32K (Nemotron, KaLM-12B, jina-v5, Harrier, Granite r2 english) vedono l'intero documento. Ciò favorisce i model a contesto lungo su TechQA (note tecniche lunghe) e MedRAG (abstract lunghi).

Rischio di contaminazione dei dati di addestramento MedRAG. Diversi dei models valutati sono stati addestrati su dati derivati da PubMed (PubMedBERT per definizione, forse Granite-278m-multilingual, forse base Qwen3). Parte dell'incremento di nDCG@3 su MedRAG potrebbe riflettere la sovrapposizione dei dati di addestramento piuttosto che la qualità del retrieval.

Conan-v1 è addestrato in cinese. Includerlo su domini solo inglesi è un punto dati istruttivo sul mismatch linguistico piuttosto che un confronto equo sulla qualità del retrieval in inglese. Ci aspettiamo una sottoperformance rispetto ai pari addestrati in inglese ed è ciò che mostrano i dati.

Ulteriori letture

Esplora altri benchmark RAG, come:

• I migliori 10 Multilingual Embedding Models per RAG
• Embedding Models: OpenAI vs Gemini vs Voyage
• I migliori Vector Database per RAG: Qdrant vs Weaviate vs Pinecone
• Reranker Benchmark: I migliori 8 Models a confronto
• Multimodal Embedding Models: Apple vs Meta vs OpenAI

Cita questo benchmark

Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Benchmark di Open Source Embedding Models per RAG}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/open-source-embedding-models}},
  note   = {AIMultiple. Consultato il 10 Agosto 2026}
}

Registro delle modifiche

4 aggiornamenti

Tutte4Generale3Metodologia1

1. 202625 Apr

   Il benchmark Top-K di 16 modelli sulle recensioni Amazon è stato sostituito con uno di 14 modelli con nDCG@3 e costi su CUAD, TechQA e MedRAG.

2. 8 Gen

   Aggiunta la sezione Licenza e uso commerciale alla panoramica dei modelli di embedding open source.

3. 6 Gen

   Il benchmark è stato ampliato per includere cinque modelli open source aggiuntivi.

4. 6 Gen

   Aggiornati hardware, dimensione del batch e precisione nella configurazione di valutazione.

Ekrem Sarı

Ricercatore IA

Segui

Ekrem è un Ricercatore IA e Data Scientist presso AIMultiple. Progetta ed esegue benchmark pratici per sistemi di IA e LLM.

Visualizza il profilo completo

Sii il primo a commentare

Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento