Modeli di embedding open source Benchmark per RAG
Abbiamo valutato 14 modelli di embedding open source, ospitati autonomamente su un singolo H100, attraverso oltre 500 query di recupero curate manualmente che spaziano da contratti legali, note tecniche di supporto clienti e abstract medici. NVIDIA Llama-Embed-Nemotron-8B è leader in termini di accuratezza. Per quanto riguarda i costi, EmbeddingGemma-300m di Google gira circa 4 volte più economico di Nemotron, a fronte di una piccola perdita di accuratezza.
Risultati del benchmark sui modelli di embedding open source
Spiegazione delle metriche
nDCG@3: Guadagno cumulativo scontato normalizzato al cutoff 3. Con un documento rilevante per query, è 1 / log2(rank + 1) quando il documento gold si posiziona tra i 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 principale perché le pipeline di produzione RAG inviano i primi 3-5 chunk all'LLM, e il bias di primazia rende il rank 1 sproporzionatamente importante.
nDCG@10: Stessa formula con cutoff 10.
Recall@10: Frazione di query in cui il documento gold appare tra i primi 10.
MRR@10: Reciproco medio del rank al cutoff 10. Il gold al rank 1 ottiene 1.000, il rank 2 ottiene 0.500 e il rank 10 ottiene 0.100. Intenzione simile a nDCG@3 ma con una penalità di rank più ripida.
Top-1 hit: Frazione di query in cui il documento rilevante gold è l'unico risultato principale. La metrica più rigorosa e quella più vicina a un flusso di lavoro di ricerca senza LLM.
Risultati nDCG@3 per dominio
La classificazione AVG nasconde inversioni di dominio. Harrier vince su CUAD ma si piazza settimo su TechQA. SFR-2 si classifica 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 multilingua Granite) 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 a 0.18 punti assoluti nDCG@3.
Gli intervalli di confidenza bootstrap al 95% per cella (modello, dominio), inclusi un pareggio a quattro vie su MedRAG in cima e una sovrapposizione Harrier-Nemotron su CUAD che la classificazione basata sulla stima puntuale appiattisce, sono riportati nella sezione metodologia del benchmark.
Costo per milione di token
Il costo ospitato autonomamente è ammortizzato sulla GPU: il tasso orario diviso per i token elaborati all'ora. Il pod utilizzato era un RunPod community-cloud H100 80GB SXM5 a $2.99/ora. Il tempo reale per modello attraverso il passaggio di 551 query e 3 corpus (circa 46.2M token totali) produce le seguenti stime di $/1M token:
La formula:
GPU $/ora = $2.99 (il tasso del pod RunPod community H100 80GB SXM5 che abbiamo utilizzato). wall_seconds = tempo reale totale di ciascun modello attraverso il passaggio di 551 query e 3 corpus. total_tokens ≈ 46.22M (somma di 3 corpus + 551 query, euristica char-count ÷ 4).
Esempio risolto, Nemotron-8B: ($2.99 / 3600) × (1247.8 × 1.000.000 / 46.220.000) = $0.0224 per 1M token.
Cinque modelli guidano il loro livello di costo (nessun'altra riga costa meno e ottiene un punteggio più alto): Granite-278m-multilingual alla base della scala dei costi, poi Granite-small-r2, EmbeddingGemma-300m, jina-v5-text-small e Nemotron-8B in cima alla scala della qualità. Gli endpoint variano di 13 volte in termini di costo ($0.0017/M a $0.0224/M) e 0.23 nDCG@3 assoluti (0.6952 a 0.9249).
Specialisti di dominio vs generalisti
PubMedBERT, ottimizzato su coppie titolo-abstract di PubMed, è il "giusto strumento" ovvio per il recupero RAG medico su PubMed. Ottiene nDCG@3 = 0.7084 su MedRAG, che è inferiore alla baseline lessicale BM25 (0.7862) sullo stesso corpus. I moderni generalisti open source lo superano di 0.22 a 0.25 punti assoluti nel suo dominio di dati di addestramento:
Il motivo per cui lo specialista performa peggio è l'età e la ricetta. PubMedBERT è un BERT da 110M parametri del 2022 con pooling medio simmetrico e nessun prefisso di istruzione. I generalisti 2024-2026 sono costruiti su backbones più grandi, prefissi asimmetrici per query e documenti e obiettivi di recupero ottimizzati per le istruzioni. Il divario architetturale conta più della corrispondenza del dominio: un fine-tune di 4 anni non può tenere il passo con un recuperatore ottimizzato per le istruzioni di ultima generazione, anche sul proprio corpus di addestramento.
La regola per l'acquirente è testare uno specialista di dominio contro un generalista moderno 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 dal benchmark di embedding open source
Il vantaggio di Nemotron-8B su TechQA è statisticamente separato dal secondo posto
Nemotron-8B AVG nDCG@3 = 0.9249. Per dominio si posiziona a 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). Gli IC bootstrap sono chiaramente separati. La base Llama-3.1 da 8B, ottimizzata per il recupero con un prefisso lato query Instruct: …\nQuery: … e un prefisso simmetrico lato documento, guida un vantaggio assoluto di 0.04 nDCG@3 sulla riga successiva sui carichi di lavoro di supporto a documenti lunghi.
I due domini in cui Nemotron vince nettamente (TechQA, MedRAG) sono i corpus di documenti lunghi in cui l'asimmetria del prefisso delle istruzioni conta di più. CUAD è l'unico dominio in cui non è leader: Microsoft Harrier-oss-v1-0.6b (0.8720) supera Nemotron (0.8602) sui contratti legali nonostante sia 13 volte più piccolo, sebbene gli IC si sovrappongano e il vantaggio non sia statisticamente separato a questa dimensione del campione.
Un modello Microsoft Harrier da 0.6B supera tutti i modelli open sotto i 7B parametri
Microsoft Harrier-oss-v1-0.6b (rilasciato nel 2026-04 con una base Qwen3-0.6B e una licenza MIT) si posiziona ad AVG nDCG@3 = 0.8911, quarto in assoluto. Supera i 12B Tencent KaLM-Gemma3 (0.8057, licenza community Tencent), i 7B Salesforce SFR-Embedding-2_R su CUAD (0.8421 contro Harrier 0.8720) e EmbeddingGemma-300m di Google (0.8706). In un confronto sulla stessa architettura, Harrier-0.6b (0.8911) si posiziona 0.074 nDCG@3 sopra Qwen3-Embedding-0.6B (0.8168), costruito sulla stessa base Qwen3-0.6B. Il corpus di addestramento e la ricetta delle istruzioni hanno guidato il divario, non il numero di parametri.
Per gli acquirenti, Harrier è la riga open source più alta che viene 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 scala AVG, ma tutti e tre sono solo per ricerca o non commerciali.
Un embedder specialista medico perde contro BM25
NeuML's PubMedBERT-base-embeddings è stato ottimizzato su coppie titolo-abstract di PubMed. È il "giusto strumento" ovvio 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 posizionano 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 da 110M parametri del 2022, con pooling medio simmetrico e nessun prefisso di istruzione. Il campo generalista 2024-2026 è costruito su backbones più grandi, prefissi asimmetrici per query e documenti e obiettivi di recupero ottimizzati per le istruzioni. Su query MedRAG che includono già vocabolario medico, la corrispondenza lessicale di BM25 è naturalmente forte e la specializzazione di PubMedBERT non aggiunge nulla sopra di essa.
La conclusione pratica non è scegliere un embedder specialista solo per nome. Valutalo sulle tue query prima di impegnarti.
Snowflake Arctic oscilla di 0.32 nDCG@3 tra i domini
Snowflake snowflake-arctic-embed-l-v2.0 (568M, Apache-2.0, derivato bge-m3-retromae, multilingua) 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 lista oscillano meno: SFR-2 varia da 0.8421 a 0.9620 (gap 0.12), Nemotron varia da 0.8602 a 0.9629 (gap 0.10), Harrier varia 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 recupero verticale, i dati di addestramento di dominio contano più del numero di parametri o della lunghezza del contesto.
Aggiungi come fonte preferitaCome funziona l'inferenza di embedding open source
I modelli di embedding open source vengono eseguiti in due backend in questo benchmark: sentence-transformers (12 modelli) e vLLM (4 modelli). La divisione non riguarda la qualità; riguarda l'efficienza runtime sui modelli da 8B e superiori, dove il ciclo di inferenza Python predefinito di sentence-transformers è troppo lento per essere fattibile.
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 usano il pooling CLS; i modelli derivati da LLM (Llama, Mistral, Qwen3, Gemma3 base) usano il pooling dell'ultimo token; i modelli multilingua spesso usano il pooling medio. La scheda HuggingFace per ogni modello è la fonte di verità su quale combinazione di prefisso e pooling è corretta.
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 prefisso asimmetrico osservati:
- Instruct + Query/Documento: SFR-2, KaLM-Gemma3, Nemotron-8B, Qwen3-Embedding
- encode_query / encode_document integrati: 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:
- Pooling CLS: trio Granite r2, Snowflake Arctic
- Pooling ultimo token: Nemotron, KaLM-Gemma3, SFR-2, jina-v5, Qwen3-Embedding, Harrier
- Pooling medio: EmbeddingGemma, Granite-multilingua, Conan, PubMedBERT, GIST
Utilizzare la ricetta sbagliata degrada silenziosamente la qualità del recupero senza bloccare. Qualsiasi benchmark di embedder open source dovrebbe includere un pavimento di sanità mentale (Recall@10 inferiore a 0.5 su tutti i domini per qualsiasi modello è un segnale di allarme per una configurazione errata, non un risultato).
Metodologia del benchmark sui modelli di embedding open source
Sono stati valutati tre domini di recupero: 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 sui modelli di embedding in inglese: Protocollo-A generazione query a consenso 3-LLM (pool di scrittori rotante, valutatore fisso, due validatori non scrittori per tentativo), fissaggio del corpus tramite hash SHA-256, whitelist per dominio di token vietati alle entità per prevenire scorciatoie lessicali BM25, accordo inter-valutatore Cohen's κ riportato per coppia di validatori, classifiche baseline BM25 sintetizzate dal campo bm25_rank_at_target già presente in ogni query JSON (equivalente Pyserini). Metrica principale nDCG@3 (realistico RAG, ciò che i sistemi di produzione RAG consumano); metriche secondarie nDCG@10, Recall@10, Recall@100, MRR@10, Top-1 hit.
Specifiche specifiche per 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
- Dispatch per modello: percorso principale scheda modello HF. ST per 12 modelli, vLLM per Nemotron-8B, KaLM-Gemma3-12B, jina-v5-text-small.
- Chunking per modello: truncation a livello di caratteri a
max_seq_length x 4caratteri per token, quindi il tokenizer del modello tronca alla sua effettiva lunghezza massima della sequenza.
- Recupero asimmetrico: ogni modello che lo supporta ottiene il prefisso query e documento documentato sulla scheda HF. Nessun prefisso è l'impostazione predefinita documentata per alcuni.
- Normalizzazione L2: applicata uniformemente post-pooling. Alcuni modelli lo fanno internamente. Rinegonizziamo per garantire la parità nella lista.
- Chiave cache embedding: include prefisso + task + prompt_name + max_seq + backend, così uno scambio di prefisso a metà esecuzione non può caricare silenziosamente embedding obsoleti.
- Protocollo statistico: 10K ricampionamenti bootstrap per cella (modello, dominio, metrica), percentile 95% CI, seed=2026.
Modelli testati
Ordinati per classifica AVG nDCG@3. Colonna Backend: ST = sentence-transformers, vLLM = vLLM 0.19.
Risultati intervalli di confidenza bootstrap al 95%
La classifica completa sopra è una singola esecuzione per cella (modello, dominio). La varianza di inizializzazione del modello tra sessioni non è misurata. Per catturare la varianza a livello di query all'interno dell'esecuzione, ricampioniamo il vettore di rank per query per ogni cella (modello, dominio) 10.000 volte con sostituzione (metodo percentile, seed=2026, dimensioni campione CUAD n=246, TechQA n=151, MedRAG n=154). IC bootstrap 95% per dominio su nDCG@3:
Gli IC cambiano quali inversioni i dati supportano. 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 è chiaramente 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) sono entro gli IC reciproci e formano un pareggio statistico a quattro vie. L'inversione PubMedBERT-sotto-BM25 su MedRAG (0.7084 [0.641, 0.772] contro BM25 0.7862) è al margine di sovrapposizione. La tendenza centrale colloca chiaramente lo specialista sotto BM25, ma è necessario un passaggio di 3 esecuzioni tra sessioni per risolverlo come separato piuttosto che sovrapposto.
Limitazioni
Singola esecuzione per cella (modello, dominio). La tabella IC bootstrap sopra cattura la varianza a livello di query all'interno dell'esecuzione (10K ricampionamenti, metodo percentile, seed=2026), ma la varianza di inizializzazione del modello tra sessioni non è misurata. È previsto un passaggio di 3 esecuzioni a mezzanotte per la v2.1. I legami più stretti emersi dalla tabella IC (ad esempio, il pareggio a quattro vie su MedRAG in cima, la sovrapposizione Harrier-Nemotron su CUAD, l'inversione marginale PubMedBERT-vs-BM25) beneficerebbero maggiormente del passaggio multi-esecuzione.
Confondimento della lunghezza del contesto per modello. I modelli con finestre di contesto di 512 token (Granite-278m-multilingua, PubMedBERT, Conan, GIST) vedono solo i primi ~2K caratteri di ogni documento. I modelli con contesto da 8K o 32K (Nemotron, KaLM-12B, jina-v5, Harrier, Granite r2 inglese) vedono l'intero documento. Questo favorisce i modelli a lungo contesto su TechQA (note tecniche lunghe) e MedRAG (abstract lunghi).
Rischio di contaminazione dei dati di addestramento MedRAG. Diversi dei modelli valutati sono stati addestrati su dati derivati da PubMed (PubMedBERT per definizione, forse Granite-278m-multilingua, forse base Qwen3). Alcuni aumenti di nDCG@3 su MedRAG potrebbero riflettere la sovrapposizione dei dati di addestramento piuttosto che la qualità del recupero.
Conan-v1 è addestrato in cinese. Includerlo su domini solo in inglese è un dato istruttivo sulla discrepanza linguistica piuttosto che un confronto diretto sulla qualità del recupero in inglese. Ci aspettiamo una performance inferiore rispetto ai pari addestrati in inglese e questo è ciò che mostrano i dati.
Conclusione
NVIDIA Llama-Embed-Nemotron-8B è leader con AVG nDCG@3 = 0.9249 con vittorie statisticamente separate su TechQA e MedRAG. La scelta open source più alta sotto una licenza senza restrizioni (MIT) è Microsoft Harrier-oss-v1-0.6b con AVG 0.8911. EmbeddingGemma-300m di Google gira a circa 4 volte il costo inferiore per un piccolo impatto sull'accuratezza.
Ulteriori letture
Esplora altri benchmark RAG, come:
- I primi 10 modelli di embedding multilingua per RAG
- Modelli di embedding: OpenAI vs Gemini vs Voyage
- I migliori database vettoriali per RAG: Qdrant vs Weaviate vs Pinecone
- Benchmark Reranker: Confronto dei primi 8 modelli
- Modelli di embedding multimodali: Apple vs Meta vs OpenAI
- RAG ibrido: Migliorare l'accuratezza RAG
- RAG grafico vs RAG vettoriale
Cita questo benchmark
Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.
@misc{sar2026,
author = {Sarı, Ekrem},
title = {{Modeli di embedding open source Benchmark per RAG}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/open-source-embedding-models}},
note = {AIMultiple. Consultato il 3 Luglio 2026}
}
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.