Benchmark dei modelli di embedding open source per RAG

Abbiamo confrontato 14 modelli di embedding open-source, ospitati su un singolo H100, con oltre 500 query di recupero curate manualmente, che spaziavano da contratti legali a note tecniche di assistenza clienti e abstract medici. Llama-Embed-Nemotron-8B si è dimostrato superiore in termini di accuratezza. Per quanto riguarda i costi, EmbeddingGemma-300m di Google risulta circa 4 volte più economico di Nemotron, a scapito di una leggera perdita di accuratezza.

Risultati del benchmark dei 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 principale si trova tra i primi 3, e 0 altrimenti. Il rango 1 ha un punteggio di 1,000, il rango 2 di 0,631 e il rango 3 di 0,500. Utilizziamo nDCG@3 come metrica principale perché le pipeline RAG di produzione alimentano il LLM con i primi 3-5 blocchi, e il bias di priorità fa sì che il rango 1 abbia un'importanza sproporzionata.

nDCG@10: Stessa formula con cutoff 10.

Recall@10: Frazione di query in cui il documento principale compare tra i primi 10 risultati.

MRR@10: Rango reciproco medio al cutoff 10. L'oro al rango 1 ottiene 1,000, il rango 2 ottiene 0,500 e il rango 10 ottiene 0,100. Intento simile a nDCG@3 ma con una penalità di rango più elevata.

Risultato migliore: Frazione di query in cui il documento rilevante è il primo risultato assoluto. La metrica più rigorosa e quella più vicina a un flusso di lavoro di ricerca senza LLM.

Risultati nDCG@3 per dominio

La classifica AVG nasconde le 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, superando PubMedBERT e il multilingue Granite) e debole su CUAD (0,5844, dove 11 dei 14 modelli densi lo superano in classifica). 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 nDCG@3.

Gli intervalli di confidenza bootstrap al 95% per ciascuna cella (modello, dominio), inclusi un pareggio a quattro vie MedRAG in cima e una sovrapposizione Harrier-Nemotron CUAD che la classificazione della stima puntuale appiattisce, sono riportati nella sezione sulla metodologia di riferimento .

Costo per milione di token

Il costo dell'hosting autonomo è ammortizzato sulla GPU: la tariffa oraria divisa per i token elaborati all'ora. Il pod che abbiamo utilizzato era un RunPod community-cloud H100 80GB SXM5 a $2,99/ora . Il tempo effettivo di esecuzione per modello su 551 query, 3 passaggi del corpus (~46,2 milioni di token in totale) fornisce le seguenti stime di $/1 milione di token:

La formula:

GPU $/ora = $2,99 (la tariffa della community RunPod H100 80GB SXM5 del pod che abbiamo utilizzato). wall_seconds = tempo totale di esecuzione di ciascun modello sui 551 passaggi di query e 3 corpus. total_tokens ≈ 46,22 milioni (somma di 3 corpus + 551 query, conteggio caratteri ÷ 4 euristica).

Esempio pratico, Nemotron-8B: (2,99 $ / 3600) × (1247,8 × 1.000.000 / 46.220.000) = 0,0224 $ per 1 milione di token .

Cinque modelli sono in testa alla loro fascia di costo (nessun'altra riga ha un costo inferiore e un punteggio superiore): Granite-278m-multilingual in fondo alla scala dei costi, seguito da Granite-small-r2, EmbeddingGemma-300m, jina-v5-text-small e Nemotron-8B in cima alla scala della qualità. Gli estremi coprono un intervallo di 13 volte in termini di costo (da $0,0017/M a $0,0224/M) e 0,23 nDCG@3 assoluto (da 0,6952 a 0,9249).

Specialisti di settore vs. generalisti

PubMedBERT, ottimizzato sulle coppie titolo-abstract di PubMed, è ovviamente lo strumento "giusto" per il recupero di informazioni mediche RAG su PubMed. Ottiene un punteggio nDCG@3 = 0,7084 su MedRAG, che è inferiore al valore di riferimento lessicale di BM25 (0,7862) sullo stesso corpus. I moderni motori di ricerca generalisti open-source lo superano di 0,22-0,25 punti assoluti sul suo dominio di dati di addestramento:

Il motivo per cui lo specialista non raggiunge prestazioni ottimali risiede nell'età e nella formulazione. PubMedBERT è un BERT del 2022 con 110 milioni di parametri, pooling medio simmetrico e nessun prefisso di istruzione. I modelli generalisti del periodo 2024-2026 sono costruiti su architetture più robuste, prefissi asimmetrici per query e documenti e obiettivi di recupero ottimizzati per le istruzioni. Il divario architetturale è più importante della corrispondenza di dominio: un fine-tuning di 4 anni non può tenere il passo con un retriever ottimizzato per le istruzioni di ultima generazione, nemmeno sul corpus di training dello stesso fine-tuning.

La regola per gli acquirenti è quella di testare uno specialista di dominio contro un generalista moderno su query rappresentative prima di implementarlo. L'assunto che "lo specialista vincerà nel suo dominio" non è più valido per i modelli di embedding open source nel 2026.

Risultati del benchmark di integrazione open-source

Il vantaggio di Nemotron-8B in termini di TechQA è statisticamente significativo rispetto al secondo classificato.

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 intervalli di confidenza bootstrap sono nettamente separati. La base 8B Llama-3.1, ottimizzata per il recupero con un prefisso lato query Instruct: …\nQuery: … e un prefisso simmetrico lato documento, genera un vantaggio assoluto di 0,04 nDCG@3 sulla riga successiva nei carichi di lavoro di supporto per documenti lunghi.

I due ambiti in cui Nemotron vince nettamente (TechQA, MedRAG) sono i corpus di documenti lunghi in cui l'asimmetria dei prefissi delle istruzioni è più importante. CUAD è l'unico ambito in cui non è in testa: Harrier-oss-v1-0.6b (0,8720) di Microsoft supera Nemotron (0,8602) nei contratti legali nonostante sia 13 volte più piccolo, anche se gli intervalli di confidenza si sovrappongono e il vantaggio non è statisticamente separato con questa dimensione del campione.

Un modello Harrier da 0,6 miliardi di unità (991259_1895) supera ogni modello aperto con 7 miliardi di parametri.

Microsoft Harrier-oss-v1-0.6b (rilasciato il 2026-04 con una base Qwen3-0.6B e una licenza MIT) si posiziona a un valore medio nDCG@3 = 0,8911 , quarto in assoluto. Supera il 12B Tencent KaLM-Gemma3 (0,8057, Tencent licenza community), il 7B Salesforce SFR-Embedding-2_R su CUAD (0,8421 contro Harrier 0,8720) e l'EmbeddingGemma-300m di Google (0,8706). In un confronto a parità di 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 divario è stato determinato dal corpus di addestramento e dalla ricetta di istruzioni, non dal numero di parametri.

Per gli acquirenti, Harrier è il progetto open-source con il punteggio più alto, distribuito 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 destinati esclusivamente alla ricerca o non sono destinati all'uso commerciale.

Un embedder specializzato in ambito medico perde contro BM25

L'algoritmo PubMedBERT-base-embeddings di NeuML è stato ottimizzato su coppie titolo-abstract di PubMed. È ovviamente lo strumento "giusto" per un benchmark RAG medico su PubMed. Ottiene un punteggio nDCG@3 = 0,7084 su MedRAG , che è 0,078 in assoluto inferiore al valore di riferimento lessicale di BM25 (0,7862) sullo stesso corpus. I migliori algoritmi 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 del 2022 con 110 milioni di parametri, con pooling medio simmetrico e senza prefisso di istruzione. Il campo generalista 2024-2026 è costruito su backbone più grandi, prefissi asimmetrici per query e documenti e obiettivi di recupero ottimizzati per le istruzioni. Nelle query MedRAG che includono già il vocabolario medico, la corrispondenza lessicale di BM25 è naturalmente forte e la specializzazione di PubMedBERT non aggiunge nulla di ulteriore.

In pratica, il consiglio è di non scegliere un servizio di embedding specializzato solo in base al nome. Valutatelo in base alle vostre esigenze specifiche prima di prendere una decisione.

Snowflake Arctic oscilla 0,32 nDCG@3 attraverso i domini

Il modello snowflake-arctic-embed-l-v2.0 (568M, Apache-2.0, derivato da bge-m3-retromae, multilingue) di Snowflake ottiene un punteggio nDCG@3 = 0,5846 sui contratti legali CUAD e 0,9053 sugli abstract medici MedRAG. Lo stesso modello, la stessa ricetta, lo stesso formato di query, con una variazione di 0,32 punti tra i due domini. Altri modelli nella lista presentano una variazione minore: 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 si basa sulla 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 del dominio sono più importanti del numero di parametri o della lunghezza del contesto.

To get up to date on enterprise AI and software, follow us:

Cem Dilmegani

Principal Analyst

Segui

Come funziona l'inferenza di embedding open source

In questo benchmark, i modelli di embedding open-source vengono eseguiti su due backend: sentence-transformers (12 modelli) e vLLM (4 modelli). La distinzione non riguarda la qualità, bensì l'efficienza di runtime sui modelli da 8 byte in su, dove il ciclo di inferenza Python predefinito di sentence-transformers è troppo lento per essere gestibile.

La ricetta specifica per ogni modello è più importante della scelta del backend. I moderni modelli di recupero utilizzano 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 utilizzano il pooling CLS; i modelli derivati da LLM (Llama, Mistral, Qwen3, Gemma3 base) utilizzano il pooling dell'ultimo token; i modelli multilingue spesso utilizzano il pooling medio. La scheda HuggingFace per ogni modello è la fonte di verità per la combinazione corretta di prefisso e pooling.

Livello backend:

• vLLM: Nemotron-8B, KaLM-Gemma3-12B, jina-v5-testo-piccolo
• trasformatori di frasi: Qwen3-0.6B, EmbeddingGemma-300m, Granite trio, SFR-2, Conan-v1, PubMedBERT, GIST, Snowflake Arctic, Microsoft Harrier

Sono stati osservati schemi di prefissi asimmetrici:

• Istruzioni + Interrogazione/Documentazione: SFR-2, KaLM-Gemma3, Nemotron-8B, Qwen3-Embedding
• Funzioni integrate encode_query / encode_document: EmbeddingGemma, KaLM-Gemma3, Nemotron-8B
• task / prompt_name (parametro sentence-transformers): jina-v5, Snowflake Arctic, Harrier
• Nessun prefisso (simmetrico): Trio di granito, Conan, PubMedBERT, GIST

Tipologia di pooling in base all'architettura di base:

• CLS pooling: trio Granite r2, Snowflake Arctic
• Ultimo pool di token: Nemotron, KaLM-Gemma3, SFR-2, jina-v5, Qwen3-Embedding, Harrier
• Media aggregata: EmbeddingGemma, Granite-multilingual, Conan, PubMedBERT, GIST

L'utilizzo di una ricetta errata degrada silenziosamente la qualità del recupero senza causare arresti anomali. Qualsiasi benchmark di embedder open-source dovrebbe includere un valore minimo accettabile (un Recall@10 inferiore a 0,5 su tutti i domini per qualsiasi modello è un segnale di allarme di una configurazione errata, non un risultato).

Metodologia di benchmark per modelli di integrazione open source

Sono stati valutati tre domini di ricerca: contratti legali CUAD (246 query, 509 contratti), note tecniche di assistenza clienti TechQA (151 query, 28000 note tecniche), 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 di consenso Protocol-A 3-LLM (pool di scrittori a rotazione, scorer fisso, due validatori non scrittori per tentativo), blocco del corpus tramite hash SHA-256, whitelist di token bannati per entità di dominio per prevenire scorciatoie lessicali BM25, accordo inter-rater κ di Cohen riportato per coppia di validatori, ranghi di base BM25 sintetizzati dal campo bm25_rank_at_target già presente in ogni JSON di query (equivalente 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 specifiche per l'open source:

• GPU: 1 x NVIDIA H100 80GB SXM5 tramite RunPod community cloud

• 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

• Gestione per modello: percorso primario della scheda modello HF. ST per 12 modelli, vLLM per Nemotron-8B, KaLM-Gemma3-12B, jina-v5-text-small.

• Suddivisione in blocchi per modello: troncamento a livello di carattere a max_seq_length x 4 caratteri 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 di query e di documento documentato da HF-card. Per alcuni, l'impostazione predefinita documentata è l'assenza di prefisso.

• Normalizzazione L2: applicata uniformemente dopo il pooling. Alcuni modelli lo fanno internamente. Noi eseguiamo una nuova normalizzazione per garantire la parità tra i dati.

• Chiave della cache di incorporamento: include prefisso + attività + prompt_name + max_seq + backend, in modo che uno scambio di prefisso a metà esecuzione non possa caricare silenziosamente incorporamenti obsoleti.

• Protocollo statistico: 10.000 ricampionamenti bootstrap per cella (modello, dominio, metrica), intervallo di confidenza al 95% per i percentili, seed=2026.

Modelli testati

Ordinato in base al rango medio nDCG@3. Colonna di backend: ST = sentence-transformers, vLLM = vLLM 0.19.

Risultati degli intervalli di confidenza bootstrap al 95%

La classifica completa sopra riportata è per singola esecuzione 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 di un'esecuzione, ricampioniamo il vettore di rango per query per ogni cella (modello, dominio) 10.000 volte con reimmissione (metodo percentile, seed=2026, dimensioni del campione CUAD n=246, TechQA n=151, MedRAG n=154). Intervallo di confidenza bootstrap al 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 con 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 all'interno dei rispettivi intervalli di confidenza e formano un pareggio statistico a quattro. L'inversione PubMedBERT-below-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 è necessario un passaggio cross-session a 3 run per risolverlo come separato piuttosto che sovrapposto.

Limitazioni

Esecuzione singola per cella (modello, dominio). La tabella CI bootstrap sopra riportata cattura la varianza a livello di query all'interno dell'esecuzione (10.000 ricampionamenti, metodo percentile, seed=2026), ma la varianza di inizializzazione del modello tra sessioni diverse non viene misurata. Per la versione 2.1 è previsto un passaggio cross-midnight a 3 esecuzioni. I legami più stretti evidenziati dalla tabella CI (ad esempio, il legame a quattro vie MedRAG in alto, la sovrapposizione Harrier-Nemotron CUAD, l'inversione marginale PubMedBERT-vs-BM25) trarrebbero maggior beneficio dal passaggio multi-esecuzione.

Confusione tra contesto e lunghezza per modello. I modelli con finestre di contesto da 512 token (Granite-278m-multilingual, 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 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 di MedRAG. Diversi modelli valutati sono stati addestrati su dati derivati da PubMed (PubMedBERT per definizione, possibilmente Granite-278m-multilingual, possibilmente base Qwen3). Alcuni miglioramenti di MedRAG nDCG@3 potrebbero riflettere la sovrapposizione dei dati di addestramento piuttosto che la qualità del recupero.

Conan-v1 è stato addestrato in cinese. Includerlo in domini esclusivamente in inglese fornisce un dato utile sulla discrepanza linguistica, piuttosto che un confronto diretto equo sulla qualità del recupero di informazioni in inglese. Ci aspettiamo prestazioni inferiori rispetto ai modelli addestrati in inglese, ed è proprio ciò che mostrano i dati.

Per approfondire

Esplora altri parametri di riferimento RAG, come ad esempio:

• I 10 migliori modelli di embedding multilingue per RAG
• Modelli di incorporamento: OpenAI vs Gemini vs Voyage
• Principale database vettoriale per RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark di Reranker: confronto tra gli 8 migliori modelli
• Modelli di embedding multimodali: Apple vs Meta vs OpenAI
• RAG ibrido: miglioramento della precisione del RAG
• Grafico RAG vs Vettore RAG

Ekrem Sarı

Ricercatore di intelligenza artificiale

Segui

Ekrem è un ricercatore di intelligenza artificiale presso AIMultiple, specializzato in automazione intelligente, GPU, agenti di intelligenza artificiale e framework RAG.

Visualizza il profilo completo

Sii il primo a commentare

Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento