Benchmark di modelli di embedding open source per RAG
Abbiamo testato 14 modelli di embedding open source, auto-ospitati su una singola H100, su oltre 500 query di recupero curate manualmente che spaziano tra contratti legali, note tecniche di assistenza clienti e abstract medici. NVIDIA Llama-Embed-Nemotron-8B primeggia in accuratezza. In termini di costo, Google’s EmbeddingGemma-300m costa circa 4x 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 al cutoff 3. Con un documento rilevante per query, è 1 / log2(posizione + 1) quando il documento d'oro rientra nei primi 3, e 0 altrimenti. La posizione 1 ottiene 1.000, la posizione 2 ottiene 0.631 e la posizione 3 ottiene 0.500. Utilizziamo nDCG@3 come metrica principale perché le pipeline RAG in produzione forniscono i primi 3-5 chunk all'LLM, e il bias di primazia fa sì che la posizione 1 conti in modo sproporzionato.
nDCG@10: stessa formula con cutoff 10.
Recall@10: frazione di query in cui il documento d'oro compare nei primi 10.
MRR@10: reciprocal rank medio al cutoff 10. Il documento d'oro in posizione 1 ottiene 1.000, in posizione 2 0.500 e in posizione 10 0.100. Intento simile a nDCG@3 ma con una penalità di posizione più ripida.
Top-1 hit: frazione di query in cui il documento rilevante è il singolo miglior risultato. La metrica più severa e quella più vicina a un flusso di lavoro senza LLM.
Risultati nDCG@3 per dominio
La classifica media nasconde inversioni di dominio. Harrier vince su CUAD ma si classifica 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 Granite multilingue) e debole su CUAD (0.5844, dove 11 dei 14 modelli densi 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 al 95% per cella (modello, dominio), inclusi un pareggio a quattro vie in cima a MedRAG e una sovrapposizione Harrier-Nemotron su CUAD che la classifica basata su stime puntuali appiattisce, sono riportati nella sezione sulla metodologia del benchmark.
Costo per milione di token
Il costo auto-ospitato è ammortizzato sulla GPU: la tariffa oraria divisa per i token elaborati all'ora. Il pod utilizzato era un RunPod community-cloud H100 80GB SXM5 a $2.99/ora. Il tempo totale per modello attraverso il passaggio a 551 query e 3 corpus (~46.2M token totali) produce le seguenti stime in $/1M token:
La formula:
GPU $/ora = $2.99 (tariffa RunPod community H100 80GB SXM5 del pod utilizzato). wall_seconds = tempo totale di esecuzione di ciascun modello attraverso il passaggio a 551 query e 3 corpus. total_tokens ≈ 46.22M (somma dei 3 corpus + 551 query, conteggio dei caratteri ÷ 4 euristica).
Esempio pratico, Nemotron-8B: ($2.99 / 3600) × (1247.8 × 1,000,000 / 46,220,000) = $0.0224 per 1M token.
Cinque modelli sono al vertice della propria fascia di costo (nessun'altra riga costa meno e ottiene un punteggio più alto): Granite-278m-multilingue 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 un fattore 13x in termini di costo ($0.0017/M a $0.0224/M) e 0.23 punti assoluti di nDCG@3 (0.6952 a 0.9249).
Specialisti di dominio vs generalisti
PubMedBERT, addestrato su coppie titolo-abstract di PubMed, è lo strumento "giusto" ovvio per il recupero RAG medico su PubMed. Ottiene nDCG@3 = 0.7084 su MedRAG, inferiore alla baseline lessicale BM25 (0.7862) sullo stesso corpus. I moderni generalisti open source lo superano di 0.22–0.25 punti assoluti nel suo dominio di addestramento:
Il motivo per cui lo specialista ha prestazioni inferiori è l'età e la ricetta. PubMedBERT è un BERT del 2022 con 110M parametri, pooling medio simmetrico e nessun prefisso di istruzione. I generalisti 2024-2026 sono costruiti su backbone più grandi, prefissi asimmetrici per query e documento e obiettivi di recupero tarati su istruzioni. Il divario architetturale conta più della corrispondenza di dominio: un fine-tuning di 4 anni fa non può tenere il passo con un retriever della generazione attuale tarato su istruzioni, persino sul corpus di addestramento del fine-tuning stesso.
La regola per l'acquirente è testare uno specialista di dominio contro un moderno generalista su query rappresentative prima di distribuirlo. L'assunzione che "lo specialista vincerà nel suo dominio" non è più sicura per i modelli di embedding open source nel 2026.
Risultati del benchmark dei modelli di embedding open source
Il vantaggio di Nemotron-8B su TechQA è statisticamente separato dal secondo posto
Nemotron-8B nDCG@3 medio = 0.9249. Per dominio si attesta a 0.8602 su CUAD, 0.9515 su TechQA e 0.9629 su MedRAG. Il risultato su TechQA (0.9515 0.923, 0.977) non si sovrappone al 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, tarata su istruzioni per il recupero con un prefisso query-side Instruct: …\nQuery: … e un prefisso documento simmetrico, produce un vantaggio di 0.04 punti assoluti di nDCG@3 sulla riga successiva in carichi di lavoro su documenti lunghi.
I due domini dove 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: Microsoft Harrier-oss-v1-0.6b (0.8720) supera Nemotron (0.8602) nei contratti legali nonostante sia 13x più piccolo, sebbene gli intervalli di confidenza si sovrappongano e il vantaggio non sia statisticamente separato a questa dimensione del campione.
Un modello 0.6B Microsoft Harrier supera tutti i modelli open sotto i 7B parametri
Microsoft Harrier-oss-v1-0.6b (rilasciato ad aprile 04 2026 con base Qwen3-0.6B e licenza MIT) si attesta a un nDCG@3 medio = 0.8911, quarto in assoluto. Supera il 12B Tencent KaLM-Gemma3 (0.8057, licenza comunitaria Tencent), l'7B Salesforce SFR-Embedding-2_R su CUAD (0.8421 vs Harrier 0.8720) e l'Google EmbeddingGemma-300m (0.8706). In un confronto a parità di architettura, Harrier-0.6b (0.8911) si colloca 0.074 punti di nDCG@3 sopra Qwen3-Embedding-0.6B (0.8168), costruito sulla stessa base Qwen3-0.6B. Il corpus di addestramento e la ricetta di istruzione hanno determinato il divario, non il numero di parametri.
Per gli acquirenti, Harrier è la riga open source con il punteggio più alto fornita 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 media, ma tutte e tre sono solo per ricerca o non commerciali.
Un embedder specialista medico perde contro BM25
PubMedBERT-base-embeddings di NeuML è stato addestrato su coppie titolo-abstract di PubMed. È lo strumento "giusto" ovvio per un benchmark RAG medico su PubMed. Ottiene nDCG@3 = 0.7084 su MedRAG, che è 0.078 punti assoluti al di sotto della baseline lessicale BM25 (0.7862) sullo stesso corpus. I migliori generalisti open source su MedRAG sono ben 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 con 110M parametri, pooling medio simmetrico e nessun prefisso di istruzione. Il campo dei generalisti dal 2024 al 2026 è costruito su backbone più grandi, prefissi asimmetrici per query e documento e obiettivi di recupero tarati su istruzioni. Su query MedRAG che già includono vocabolario medico, la corrispondenza lessicale di BM25 è naturalmente forte e la specializzazione di PubMedBERT non aggiunge nulla.
La conclusione pratica non è scegliere un embedder specialista solo in base al nome. Valutalo sulle tue query prima di impegnarti.
Snowflake Arctic oscilla di 0.32 nDCG@3 tra i domini
snowflake-arctic-embed-l-v2.0 di Snowflake (568M, Apache-2.0, derivato bge-m3-retromae, multilingue) ottiene nDCG@3 = 0.5846 su contratti legali CUAD e 0.9053 su abstract medici MedRAG. Lo 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 va da 0.8421 a 0.9620 (differenza 0.12), Nemotron da 0.8602 a 0.9629 (differenza 0.10), Harrier da 0.8408 a 0.9605 (differenza 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 recupero verticale, i dati di addestramento di dominio contano più del numero di parametri o della lunghezza del contesto.
Come funziona l'inferenza dei modelli di embedding open source
I modelli di embedding open source vengono eseguiti su due backend in questo benchmark: sentence-transformers (12 modelli) e vLLM (4 modelli). La divisione non riguarda la qualità; riguarda l'efficienza di esecuzione su modelli da 8B e oltre, dove il ciclo di inferenza Python predefinito di sentence-transformers è troppo lento per essere gestibile.
La ricetta per modello conta più della scelta del backend. I moderni modelli di recupero utilizzano 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 modelli derivati da BERT utilizzano il CLS pooling; i modelli derivati da LLM (Llama, Mistral, Qwen3, Gemma3) utilizzano il last-token pooling; i modelli multilingue spesso utilizzano il mean pooling. La scheda HuggingFace di ciascun modello è la fonte autorevole per la combinazione corretta di prefisso e pooling.
Livello backend:
- vLLM: Nemotron-8B, KaLM-Gemma3-12B, jina-v5-text-small
- sentence-transformers: Qwen3-0.6B, EmbeddingGemma-300m, trio Granite, SFR-2, Conan-v1, PubMedBERT, GIST, Snowflake Arctic, Microsoft Harrier
Pattern di prefissi asimmetrici osservati:
- Instruct + Query/Documento: SFR-2, KaLM-Gemma3, Nemotron-8B, Qwen3-Embedding
- encode_query / encode_document incorporati: EmbeddingGemma, KaLM-Gemma3, Nemotron-8B
- task / prompt_name (parametro sentence-transformers): jina-v5, Snowflake Arctic, Harrier
- Nessun prefisso (simmetrico): trio Granite, Conan, PubMedBERT, GIST
Tipo di pooling per architettura di base:
- CLS pooling: trio Granite r2, Snowflake Arctic
- Last-token pooling: Nemotron, KaLM-Gemma3, SFR-2, jina-v5, Qwen3-Embedding, Harrier
- Mean pooling: EmbeddingGemma, Granite-multilingue, Conan, PubMedBERT, GIST
L'uso di una ricetta sbagliata degrada silenziosamente la qualità del recupero senza generare errori. Qualsiasi benchmark di embedder open source dovrebbe includere un limite di sanità (Recall@10 inferiore a 0.5 in tutti i domini per un qualsiasi modello è un campanello d'allarme per una configurazione errata, non un risultato).
Aggiungi come fonte preferitaMetodologia del benchmark dei modelli di embedding open source
Sono stati valutati tre domini di recupero: 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 dei modelli di embedding in inglese: generazione di query tramite consenso Protocol-A 3-LLM (pool di scrittori ruotante, valutatore fisso, due validatori non scrittori per tentativo), fissaggio del corpus con hash SHA-256, whitelist di token vietati per dominio per impedire scorciatoie lessicali BM25, accordo inter-valutatore di Cohen κ riportato per coppia di validatori, ranking di baseline BM25 sintetizzati dal campo bm25_rank_at_target già presente in ogni query JSON (equivalente a Pyserini). Metrica principale 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 cloud community RunPod
- Modello 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
- Invio per modello: percorso primario della scheda modello 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 4caratteri per token, quindi il tokenizzatore del modello tronca alla sua lunghezza massima effettiva della sequenza.
- Recupero asimmetrico: ogni modello che lo supporta riceve il prefisso per query e documento documentato nella scheda HF. Nessun prefisso è l'impostazione predefinita per alcuni.
- Normalizzazione L2: applicata uniformemente dopo il pooling. Alcuni modelli lo fanno internamente. Rinormalizziamo per garantire la parità nell'intera gamma.
- Chiave della cache degli embedding: include prefisso + task + prompt_name + max_seq + backend, in modo che uno scambio di prefisso a metà esecuzione non possa caricare silenziosamente embedding obsoleti.
- Protocollo statistico: 10K ricampionamenti bootstrap per cella (modello, dominio, metrica), CI percentile al 95%, seed=2026.
Modelli testati
Ordinati per posizione media nDCG@3. Colonna Backend: ST = sentence-transformers, vLLM = vLLM 0.19.
Risultati degli intervalli di confidenza bootstrap al 95%
La classifica completa sopra è a singola esecuzione per cella (modello, dominio). La varianza di inizializzazione cross-sessione non è misurata. Per catturare la varianza a livello di query all'interno di una esecuzione, ricampioniamo il vettore dei ranghi per query per ogni cella (modello, dominio) 10.000 volte con reinserimento (metodo percentile, seed=2026, dimensioni campione CUAD n=246, TechQA n=151, MedRAG n=154). Intervalli di confidenza bootstrap al 95% per dominio per nDCG@3:
Gli IC cambiano effettivamente quali inversioni supportano i 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) rientrano negli IC degli altri e formano un pareggio statistico a quattro vie. L'inversione di PubMedBERT al di sotto di BM25 su MedRAG (0.7084 [0.641, 0.772] vs BM25 0.7862) è al limite della sovrapposizione. La tendenza centrale colloca chiaramente lo specialista al di sotto di BM25, ma un passaggio a 3 esecuzioni cross-sessione è necessario per stabilire se la separazione è netta o sovrapposta.
Limitazioni
Esecuzione singola per cella (modello, dominio). La tabella CI bootstrap sopra cattura la varianza a livello di query all'interno di una esecuzione (10K ricampionamenti, metodo percentile, seed=2026), ma la varianza di inizializzazione cross-sessione non è misurata. Un passaggio a 3 esecuzioni cross-midnight è previsto per la v2.1. I legami più stretti emersi dalla tabella CI (ad esempio, il pareggio a quattro vie in cima a MedRAG, la sovrapposizione Harrier-Nemotron su CUAD, l'inversione marginale PubMedBERT-vs-BM25) beneficerebbero maggiormente del passaggio multi-esecuzione.
Confondente della lunghezza del contesto per modello. I modelli con finestre di contesto di 512 token (Granite-278m-multilingue, PubMedBERT, Conan, GIST) vedono solo i primi ~2K caratteri di ciascun documento. I modelli con contesto di 8K o 32K (Nemotron, KaLM-12B, jina-v5, Harrier, Granite r2 english) vedono il documento completo. Ciò favorisce i modelli a contesto lungo su TechQA (note tecniche lunghe) e MedRAG (abstract lunghi).
Rischio di contaminazione dei dati di addestramento MedRAG. Diversi modelli valutati sono stati addestrati su dati derivati da PubMed (PubMedBERT per definizione, forse Granite-278m-multilingue, forse la base Qwen3). Parte dell'incremento di nDCG@3 su MedRAG potrebbe riflettere una sovrapposizione dei dati di addestramento piuttosto che la qualità del recupero.
Conan-v1 è addestrato sul cinese. Includerlo su domini solo in inglese è un dato istruttivo sulla mancata corrispondenza linguistica più che un confronto equo sulla qualità del recupero in inglese. Ci aspettiamo prestazioni inferiori rispetto ai modelli addestrati in inglese, ed è quanto mostrano i dati.
Conclusione
NVIDIA Llama-Embed-Nemotron-8B guida con un nDCG@3 medio = 0.9249 e vittorie statisticamente separate su TechQA e MedRAG. La scelta open source con il punteggio più alto sotto licenza senza restrizioni (MIT) è Microsoft Harrier-oss-v1-0.6b con nDCG@3 medio = 0.8911. Google EmbeddingGemma-300m costa circa 4x meno a fronte di una piccola perdita di accuratezza.
Approfondimenti
Esplora altri benchmark RAG, come:
- Top 10 modelli di embedding multilingue per RAG
- Modelli di embedding: OpenAI vs Gemini vs Voyage
- Top database vettoriali per RAG: Qdrant vs Weaviate vs Pinecone
- Benchmark di reranker: confronto tra i migliori 8 modelli
- Modelli di embedding multimodali: Apple vs Meta vs OpenAI
- RAG ibrido: migliorare 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 di modelli di embedding open source per RAG}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/open-source-embedding-models}},
note = {AIMultiple. Consultato il 3 Luglio 2026}
}Risultati e timestamp di 15 punti dati. Scarica i dati utilizzati in questo articolo come file ZIP contenente un file CSV e un README.
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.