Benchmark dei modelli di embedding open source per RAG

NVIDIA Llama-Embed-Nemotron-8B è leader in accuratezza. Sul fronte dei costi, Google EmbeddingGemma-300m costa circa 4x in meno di Nemotron a fronte di una piccola perdita di accuratezza.

Risultati del benchmark dei modelli di embedding open source

Metriche spiegate

nDCG@3: Guadagno cumulativo scontato normalizzato con cutoff 3. Con un solo documento rilevante per query, vale 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. Usiamo nDCG@3 come metrica primaria perché le pipeline RAG in produzione alimentano il LLM con le prime 3-5 porzioni e il bias di primazia 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 con cutoff 10. Il documento gold al rank 1 ottiene 1.000, al rank 2 ottiene 0.500 e al 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 rilevante gold è il singolo primo risultato. È la metrica più restrittiva e quella più vicina a un flusso di ricerca senza LLM.

Risultati nDCG@3 per dominio

La classifica AVG nasconde inversioni di dominio. Harrier vince su CUAD ma si colloca 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, superando PubMedBERT e il Granite multilingue) e debole su CUAD (0.5844, dove 11 modelli densi su 14 lo superano). I contratti legali contengono un linguaggio denso di entità che premia la corrispondenza lessicale. Sugli abstract medici, i migliori modelli densi (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 95% per cella (modello, dominio), inclusi un pareggio a quattro su MedRAG in testa e una sovrapposizione Harrier-Nemotron su CUAD che la classifica puntuale appiattisce, sono riportati nella sezione della metodologia del benchmark.

Costo per milione di token

Il costo self-hosted è ammortizzato sulla GPU: tariffa oraria divisa per i token elaborati all'ora. Il pod che abbiamo usato era un RunPod community-cloud H100 80GB SXM5 a $2.99/ora. Il tempo di esecuzione per modello nel passaggio su 551 query e 3 corpora (~46.2M token totali) produce le seguenti stime di $/1M token:

La formula:

GPU $/hr = $2.99 (tariffa RunPod community H100 80GB SXM5 del pod che abbiamo usato). wall_seconds = tempo di esecuzione totale di ciascun modello nel passaggio su 551 query e 3 corpora. total_tokens ≈ 46.22M (somma dei 3 corpora + 551 query, euristica conteggio caratteri ÷ 4).

Esempio concreto, Nemotron-8B: ($2.99 / 3600) × (1247,8 × 1.000.000 / 46.220.000) = $0.0224 per 1M token.

Cinque modelli 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 presentano una differenza di costo di 13x (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, perfezionato tramite fine-tuning su coppie titolo-abstract di PubMed, è l'ovvio “strumento giusto” per il retrieval RAG medico su PubMed. Ottiene un nDCG@3 = 0.7084 su MedRAG, inferiore alla baseline lessicale BM25 (0.7862) sullo stesso corpus. I generalisti open source moderni lo superano di 0.22-0.25 punti assoluti sul dominio dei dati di addestramento:

Il motivo per cui lo specialista rende meno è l'età e la ricetta. PubMedBERT è un BERT del 2022 da 110M parametri con mean pooling simmetrico e senza prefisso di istruzione. I generalisti 2024-2026 sono costruiti su backbones più grandi, prefissi asimmetrici per query e documenti e obiettivi di retrieval ottimizzati tramite instruction tuning. 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, persino sul corpus di addestramento del fine-tune stesso.

La regola per chi acquista è testare uno specialista di dominio contro un generalista moderno su query rappresentative prima di metterlo in produzione. L'ipotesi che “lo specialista vincerà nel suo dominio” non è più sicura per i modelli di embedding open source nel 2026.

Risultati dal benchmark di embedding open source

Il vantaggio su TechQA di Nemotron-8B è 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 con il secondo classificato SFR-Embedding-2_R (0.9109 0.869, 0.949). Gli intervalli di confidenza 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 nDCG@3 di 0.04 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 in cui l'asimmetria dei prefissi di istruzione conta di più. CUAD è l'unico dominio in cui non è in testa: il modello Microsoft Harrier-oss-v1-0.6b (0.8720) supera Nemotron (0.8602) sui contratti legali pur essendo 13x più piccolo, sebbene gli intervalli di confidenza si sovrappongano e il vantaggio non sia statisticamente separato a questa dimensione del campione.

Un modello Harrier 0.6B di Microsoft supera ogni modello aperto con meno di 7B parametri

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

Per chi acquista, Harrier è la riga open source con la posizione più alta che viene 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 classifica AVG, ma tutti e tre sono solo per la ricerca o non commerciali.

Un embedder specialista in campo medico perde contro BM25

Il modello PubMedBERT-base-embeddings di NeuML è stato sottoposto a fine-tuning 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 in valore assoluto 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 acquirente sceglie uno specialista di dominio. PubMedBERT è un BERT del 2022 da 110M parametri, con mean pooling simmetrico e nessun prefisso di istruzione. Il campo dei generalisti dal 2024 al 2026 è costruito su backbones 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 di essa.

La conclusione pratica è di non scegliere un embedder specialista solo in base al nome. Sottoponilo a benchmark sulle tue query prima di impegnarti.

Snowflake Arctic oscilla di 0.32 nDCG@3 tra i domini

Il modello di 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. Stesso modello, stessa ricetta, stesso formato di query, con un'oscillazione di 0.32 punti tra due domini. Altri modelli nella gamma oscillano meno: SFR-2 passa da 0.8421 a 0.9620 (gap 0.12), Nemotron passa da 0.8602 a 0.9629 (gap 0.10), Harrier passa 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

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

La ricetta per modello conta più della scelta del backend. I moderni modelli di retrieval usano prefissi asimmetrici: il lato query è racchiuso 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 modelli derivati da BERT usano il CLS pooling; i modelli derivati da LLM (Llama, Mistral, Qwen3, base Gemma3) usano il last-token pooling; i modelli multilingue usano spesso il mean pooling. La scheda HuggingFace di ogni modello è la fonte di verità per capire quale combinazione di prefisso e pooling è corretta.

Fascia di 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
• encode_query / encode_document integrati: EmbeddingGemma, KaLM-Gemma3, Nemotron-8B
• task / prompt_name (parametro di sentence-transformers): jina-v5, Snowflake Arctic, Harrier
• Nessun prefisso (simmetrico): Granite trio, Conan-v1, 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-v1, PubMedBERT, GIST

Usare la ricetta sbagliata degrada silenziosamente la qualità del retrieval senza causare crash. Qualsiasi benchmark di embedder open source dovrebbe includere una soglia di controllo (Recall@10 inferiore a 0.5 in tutti i domini per qualsiasi modello è 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 dei modelli di embedding open source

Sono stati valutati tre domini di retrieval: contratti legali CUAD (246 query, 509 contratti), note tecniche di assistenza 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 modelli di embedding in inglese: generazione di query tramite consenso Protocol-A con 3 LLM (pool di redattori rotante, scorer fisso, due validatori non redattori per tentativo), blocco dei corpus tramite hash SHA-256, whitelist di token per dominio con entità vietate 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 della query (equivalente a Pyserini). Metrica primaria nDCG@3 (realistica per RAG, ciò che i sistemi RAG in produzione consumano); metriche secondarie nDCG@10, Recall@10, Recall@100, MRR@10, Top-1 hit.

Specifiche per i modelli open source:

• GPU: 1 x NVIDIA H100 80GB SXM5 tramite RunPod community cloud
• Pod template: 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 modello: percorso primario dalla model card HF. ST per 12 modelli, vLLM per Nemotron-8B, KaLM-Gemma3-12B, jina-v5-text-small.
• Chunking per modello: troncamento a livello di carattere a max_seq_length x 4 caratteri per token, poi il tokenizer del modello tronca alla sua lunghezza massima effettiva di sequenza.
• Retrieval asimmetrico: ogni modello che lo supporta riceve il prefisso di query e documento documentato nella scheda HF. Nessun prefisso è il default documentato per alcuni.
• Normalizzazione L2: applicata uniformemente dopo il pooling. Alcuni modelli la eseguono internamente. Noi la riapplichiamo per garantire parità in tutta la selezione.
• Chiave della cache di embedding: include prefisso + task + prompt_name + max_seq + backend, in modo che una sostituzione di prefisso durante l'esecuzione non possa caricare in silenzio embedding obsoleti.
• Protocollo statistico: 10K ricampionamenti bootstrap per cella (modello, dominio, metrica), intervallo di confidenza percentile 95%, seed=2026.

Modelli testati

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

Risultati degli intervalli di confidenza bootstrap 95%

La classifica completa sopra è a esecuzione singola per cella (modello, dominio). La varianza di inizializzazione del modello tra sessioni non viene misurata. Per catturare la varianza a livello di query all'interno della stessa esecuzione, ricampioniamo il vettore dei rank per ogni cella (modello, dominio) 10.000 volte con replacement (metodo percentile, seed=2026, dimensioni del campione CUAD n=246, TechQA n=151, MedRAG n=154). Intervallo di confidenza bootstrap 95% per dominio su nDCG@3:

Gli intervalli di confidenza 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 del campione. 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) rientrano l'uno negli intervalli di confidenza 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 serve un passaggio su 3 esecuzioni cross-sessione per stabilirla come separata piuttosto che sovrapposta.

Limitazioni

Esecuzione singola per cella (modello, dominio). La tabella degli intervalli di confidenza bootstrap sopra cattura la varianza a livello di query all'interno della stessa esecuzione (10K ricampionamenti, metodo percentile, seed=2026), ma la varianza di inizializzazione del modello tra sessioni non viene misurata. È previsto un passaggio su 3 esecuzioni cross-midnight per la v2.1. I pareggi più stretti emersi dalla tabella degli intervalli di confidenza (ad es. il pareggio a quattro su MedRAG in testa, la sovrapposizione Harrier-Nemotron su CUAD, l'inversione marginale PubMedBERT-vs-BM25) beneficerebbero maggiormente del passaggio multi-esecuzione.

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

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

Conan-v1 è addestrato sul cinese. Includerlo su domini esclusivamente in inglese è un punto dati istruttivo sul disallineamento linguistico piuttosto che un confronto equo sulla qualità del retrieval in inglese. Ci aspettiamo prestazioni inferiori rispetto ai modelli pari addestrati in inglese ed è ciò che mostrano i dati.

Ulteriori letture

Esplora altri benchmark RAG, come ad esempio:

• I migliori 10 modelli di embedding multilingue per RAG
• Modelli di embedding: OpenAI vs Gemini vs Voyage
• I migliori database vettoriali per RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark dei reranker: i migliori 8 modelli a confronto
• Modelli di embedding multimodali: Apple vs Meta vs OpenAI
• Hybrid RAG: aumentare l'accuratezza del RAG
• Graph RAG vs Vector RAG

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 dei modelli di embedding open source per RAG}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/open-source-embedding-models}},
  note   = {AIMultiple. Consultato il 10 Agosto 2026}
}

Ekrem Sarı

Ricercatore AI

Segui

Ekrem è Ricercatore AI e analista di dati presso AIMultiple. Progetta ed esegue benchmark pratici per sistemi di AI 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