Modelli di embedding: OpenAI vs Gemini vs Voyage

Abbiamo confrontato 15 modelli di embedding testuale in inglese e una baseline BM25 su oltre 500 query curate manualmente in tre domini di recupero: contratti legali (CUAD), assistenza clienti (IBM TechQA) e sanità (MedRAG PubMed).

Voyage-3.5 si classifica primo in assoluto. Perplexity Embed V1 0.6b raggiunge la fascia medio-alta al prezzo più basso del nostro benchmark.

Risultati del benchmark dei modelli di embedding

Metriche spiegate

nDCG@3: Guadagno cumulativo scontato normalizzato al cutoff 3. Con un documento rilevante per query, vale 1 / log2(rango + 1) quando il documento gold rientra nei primi 3, e 0 altrimenti. Il rango 1 ottiene 1.000, il rango 2 ottiene 0.631, il rango 3 ottiene 0.500. Usiamo nDCG@3 come metrica primaria perché le pipeline RAG di produzione alimentano i primi 3-5 chunk all'LLM e il bias di primazia fa sì che il rango 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: Rango reciproco medio al cutoff 10. Il gold 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 penalizzazione di rango più ripida.

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

nDCG@3 per dominio

Legale (CUAD, 246 query, 509 contratti): Il legale è l'unico dominio in cui lo specialista voyage-law-2 vince; i suoi dati di addestramento tarati su CUAD fruttano +0.040 nDCG@3 rispetto a voyage-4-large. openai/text-embedding-3-large si classifica 11 con 0.6430, sotto sei modelli più economici. Pavimento BM25: 0.5844.

Assistenza clienti (TechQA, 151 query, 28.000 IBM note tecniche): Il divario da voyage-4-lite al modello successivo è 0.018. gemini-embedding-001 scende al 7 (0.8856), 0.045 dietro al suo gemello più recente su TechQA anche se vince negli altri due domini. Pavimento BM25: 0.6097.

Sanità (MedRAG-PubMed, 154 query, 50.000 abstract): La sanità è il cluster più compatto del nostro benchmark (14 modelli superano 0.88) perché il vocabolario medico è denso di parole chiave, il che spinge la maggior parte delle query nel cluster di testa. Pavimento BM25: 0.7862, entro 0.02 dal modello denso più debole. gemini-embedding-001 batte anche gemini-embedding-2-preview con il suo margine più ampio qui (+0.013).

I ribaltamenti a livello di dominio giustificano l'impostazione della media su 3 domini: nessun singolo dominio è un proxy equo per "quale modello è il migliore" e un acquirente che sceglie in base a un solo dominio classificherà male gli altri.

Gli intervalli di confidenza bootstrap al 95% per ogni modello e cella di dominio, più i quattro pareggi a coppie che le classifiche a stima puntuale nascondono, sono dettagliati nella sezione metodologia.

Accuratezza vs prezzo: costo per 1M token

Metriche spiegate

Prezzo per 1M token di input è il prezzo di listino per l'embedding di 1M token di input, a partire dal 2026-04-23. I prezzi Voyage provengono dalla pagina dei prezzi diretta di Voyage. I modelli serviti da OpenRouter usano l'istantanea del catalogo OpenRouter dello stesso giorno. I token di query e documento hanno lo stesso prezzo per ogni fornitore testato. BM25 è tracciato a $0.001/M per il rendering sull'asse logaritmico. Il vero costo self-hosted è $0.

nDCG@3 medio sui 3 domini è la media non ponderata dell'nDCG@3 per dominio sui tre corpora. Ogni dominio contribuisce equamente alla media indipendentemente dal numero di query.

• Per le piattaforme RAG orientate al costo, pplx-embed-v1-0.6b è la scelta chiara. A $0.004/M è 30-50x più economico di qualsiasi flagship commerciale e offre il 92% della qualità di voyage-3.5 (0.8604 / 0.9429). Nessun altro modello nel nostro benchmark compete al suo livello di prezzo.
• Per RAG aziendale orientato alla qualità, voyage-3.5 tramite l'SDK diretto di Voyage conquista il punto di Pareto più alto. Si paga un'integrazione API in più (rispetto a uno stack solo OpenRouter) per un modello marginalmente migliore rispetto al flagship di Voyage a metà prezzo. L'istinto di "scegliere sempre il più nuovo e grande" è sbagliato nel catalogo di Voyage.
• Per implementazioni OSS / self-hostable / on-prem, vince qwen3-embedding-8b. È il più economico embedder non banale nel nostro benchmark a $0.010/M, eguaglia o supera ogni altra famiglia di encoder OSS testata e viene distribuito con pesi self-hostable.
• I flagship premium (openai-3-large, gemini-2-preview, voyage-4-large, gemini-001) perdono tutti contro voyage-3.5 sulla media dei 3 domini, anche se voyage-3.5 è 2-3x più economico di ciascuno di essi.

Risultati chiave del benchmark di embedding

voyage-3.5 vince la media sui 3 domini e batte il flagship voyage-4-large a metà prezzo

voyage-3.5 registra una media di 0.9429 nDCG@3 tra legale, assistenza clienti e sanità. Il flagship voyage-4-large registra una media di 0.9416 a $0.12 per 1M token, pari a 2x il prezzo di $0.06 di voyage-3.5. Il flagship vince TechQA di 0.002 e vince MedRAG di 0.032. Perde CUAD di 0.037 (0.8730 vs 0.9102), abbastanza perché la sua media sui 3 domini sia inferiore a voyage-3.5. Nella gamma di Voyage, il modello di fascia media più vecchio è la scelta migliore per uso generale. Il flagship guadagna il suo premio solo nella sanità.

Voyage ha conquistato il primo posto in tutti e tre i domini e ha dominato i primi due posti su CUAD e TechQA. Su MedRAG, gemini-embedding-001 è entrato al 2nd posto (0.9814, dietro il 0.9855 di voyage-4-large), davanti a ogni altro modello Voyage. gemini-001 raggiunge anche il terzo posto su CUAD. Nessun altro modello non Voyage raggiunge i primi 2 in alcun dominio singolo.

Un modello Gemini legacy batte il suo gemello “preview” più recente su due domini su tre

google/gemini-embedding-001 (rilasciato a giugno 2025) supera google/gemini-embedding-2-preview sia su CUAD (0.8980 vs 0.8958) sia su MedRAG (0.9814 vs 0.9685). Il modello più recente vince solo TechQA (0.9301 vs 0.8856), un divario di 0.04 accompagnato da un aumento di prezzo del 33% ($0.20 vs $0.15 per 1M token di input). L'inquadramento "aggiornamento multimodale più recente" di Gemini 2 non regge nel recupero di testo in inglese su corpora legali o sanitari.

Per i carichi di lavoro RAG su quei due domini oggi, gemini-embedding-001 è la scelta Gemini corretta. Il ribaltamento su MedRAG (001 al 2nd, 2-preview al 3rd) è abbastanza ampio che un acquirente che sceglie di default il modello "più recente" perde qualità misurabile.

OpenAI text-embedding-3-large è di fascia media nel legale e nell'assistenza clienti

openai/text-embedding-3-large si classifica 11 su 15 modelli densi su CUAD con 0.6430 nDCG@3. Otto modelli strettamente più economici lo battono sui contratti legali: entrambi i flagship Voyage serie 4 da $0.12, voyage-3.5 a metà prezzo, voyage-4-lite a 1/6 del prezzo, entrambe le varianti di embedding Qwen3, intfloat/e5-large-v2 a 1/13 del prezzo e perplexity/pplx-embed-v1-0.6b (0.8031) a 1/32 del prezzo. Il flagship di OpenAI è 9 su TechQA (0.8581) e 11 su MedRAG (0.9296). La sanità lo colloca in un cluster di testa compatto (ampiezza dal 2nd all'11: 0.05 nDCG@3). Nel legale il divario è ampio e costoso.

A $0.13 per 1M token di input è 32x più costoso di pplx-embed-v1-0.6b. I team che scelgono di default OpenAI perché "è la scelta sicura" pagano un premio che i dati sui 3 domini non giustificano.

pplx-embed-v1-0.6b raggiunge la fascia alta a un trentesimo del prezzo dei flagship comparabili

perplexity/pplx-embed-v1-0.6b a $0.004 per 1M token registra una media di 0.8604 nDCG@3 nei tre domini, dietro solo ai quattro modelli Voyage, alle due varianti Gemini e a qwen/qwen3-embedding-8b. Batte ogni modello OpenAI e OSS in gamma. Batte anche openai/text-embedding-3-large di 0.16 nDCG@3 su CUAD, perde di 0.012 su TechQA (0.8457 vs 0.8581) e vince di 0.003 su MedRAG. Il successivo modello top-10 più economico è qwen/qwen3-embedding-8b a $0.010 (2.5x in più), anch'esso servito tramite OpenRouter.

Per le piattaforme RAG orientate al costo in cui l'embedding è una voce di costo rilevante, pplx-0.6b è la scelta ovvia. Il divario di 30-50x rispetto ai prezzi dei flagship non apporta nulla alla qualità di recupero, essenzialmente in questi tre domini.

BM25 è entro 0.02 dal modello denso più debole sugli abstract medici

Su MedRAG-PubMed, BM25 ottiene 0.7862 nDCG@3 contro baai/bge-m3 (modalità densa) a 0.8038, un divario di 0.02. La ricerca lessicale arriva entro 0.15 da sette dei quindici modelli densi su questo corpus (bge-m3, e5-base-v2, openai-3-small, e5-large-v2, openai-3-large, pplx-0.6b, qwen3-4b). La ragione è strutturale: le query mediche sono dense di parole chiave per progettazione (nomi di farmaci, nomi di malattie, termini di disegno dello studio, simboli genici), e quei token trasportano la maggior parte del segnale di recupero. Uno scorer in stile Lucene li abbina direttamente senza bisogno di contesto semantico.

Un reranker sopra BM25 è un'alternativa plausibile e più economica a un embedder denso premium per corpora densi di parole chiave: il divario di recupero che BM25 lascia (0.2 nDCG@3 rispetto alla fascia alta su MedRAG) è il tipo di divario che un reranker di Cohere o Voyage può colmare. Su CUAD il divario da BM25 al miglior modello denso è 0.33, su TechQA 0.36, su MedRAG 0.20. La densità del vocabolario di dominio è il singolo fattore determinante di quanto gli embedding densi aiutino.

Specialisti di dominio vs generalisti tra i fornitori

Voyage prezza voyage-law-2 a $0.12/M, identico a voyage-4-large. I due modelli condividono fornitore, tokenizer, SDK e schema di invocazione asimmetrico. Differisce solo l'enfasi dei dati di addestramento. Eseguirli entrambi contro i generalisti su CUAD, TechQA e MedRAG isola l'effetto dell'addestramento legale.

Su CUAD, voyage-law-2 si classifica 1st con 0.9126: 0.0024 sopra voyage-3.5, 0.0146 sopra gemini-embedding-001, 0.040 sopra voyage-4-large, 0.097 sopra qwen3-embedding-8b e 0.270 sopra openai/text-embedding-3-large (0.6430). Su TechQA, voyage-law-2 si classifica 4 con 0.9020, 0.064 dietro voyage-4-large e 0.063 dietro voyage-3.5. Su MedRAG, si classifica 6 con 0.9409, 0.045 dietro voyage-4-large e 0.041 dietro gemini-embedding-001. L'addestramento legale aumenta l'nDCG@3 su CUAD e lo riduce sugli altri due domini.

Un team legale che mette in produzione il recupero in stile CUAD su openai/text-embedding-3-large opera a 0.6430 nDCG@3 contro voyage-law-2 a 0.9126, un divario di 0.27. Un team sanitario o di supporto che sceglie voyage-law-2 perché si è classificato primo su CUAD perde 0.045 rispetto a voyage-4-large su MedRAG e 0.064 su TechQA. I modelli di embedding specializzati per dominio non sono sostituzioni immediate per il recupero generico. Una singola raccomandazione di "modello migliore" tra settori sbaglia in almeno una direzione.

Quando scegliere voyage-law-2: recupero di contratto su corpora legali commerciali che assomigliano strutturalmente a CUAD. Quando non farlo: qualsiasi altra cosa in questo benchmark. voyage-3.5 costa $0.06/M, si colloca 0.0024 sotto voyage-law-2 su CUAD e lo supera sia su TechQA che su MedRAG.

Come è stata valutata la pipeline di recupero con embedding

Ogni modello codifica un vettore di query e N vettori di documento tramite un bi-encoder. Calcoliamo la similarità coseno tra il vettore di query e ogni vettore di documento, quindi ordiniamo i primi k per quella query. Con un documento gold per query e rilevanza binaria, il valutatore verifica se il gold compare nei primi k e a quale rango. Quel rango alimenta nDCG@3 (la nostra metrica primaria), nDCG@10 (per comparabilità BEIR/MTEB), Recall@10 e il tasso Top-1 hit.

Gli encoder di query e documento non sono sempre la stessa funzione. Alcuni modelli sono addestrati in modo asimmetrico: il lato query applica una trasformata, il lato documento ne applica un'altra. Invocare quei modelli in modo simmetrico ("basta passare il testo") degrada silenziosamente la qualità del recupero di 0.05-0.45 nDCG@10. La nostra gamma si divide in quattro modalità:

Perché nDCG@3 come metrica primaria. Le pipeline RAG di produzione alimentano i primi 3-5 chunk all'LLM, non i primi 10. Il bias di primazia negli LLM a contesto lungo fa sì che il rango 1 conti più del rango 3, e ogni distrattore che finisce sopra il gold nel contesto dell'LLM è un candidato alla confabulazione. I reranker appiattirebbero questo effetto, ma la maggior parte dei RAG di produzione ne fa a meno per motivi di costo e latenza, quindi il rango dell'embedder È il rango finale.

Su MedRAG, Recall@10 ha raggiunto il tetto di 1.000 per tre modelli Voyage e per qwen3-8b; nDCG@3 ha mantenuto un divario di 0.10 sulle stesse query. nDCG@10 mantiene la comparabilità BEIR ma attenua le differenze in cima alla lista che contano dal punto di vista operativo.

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

Corpora (selezione del dominio e perché)

Abbiamo scelto tre domini che sollecitano proprietà di recupero diverse e che coprono i tre RAG aziendali più comuni. Ogni corpus è bloccato con SHA256, così qualsiasi lettore può riprodurre l'esatta cella che abbiamo eseguito.

PM209 (manuali di produzione) è stato scartato: solo 209 documenti, troppo pochi per evitare il problema della scorciatoia entitaria di BM25 a 150 query.

Generazione delle query: protocollo di consenso a 3 LLM

Le nostre query sono generate da LLM con separazione scrittore-validatore: l'LLM che redige una query non giudica mai il proprio target di recupero, quindi il self-bias è strutturalmente escluso. Solo i due validatori non scrittori, vedendo i 20 candidati mescolati senza alcun indizio su quale fosse il documento di ancoraggio dello scrittore, decidono l'accettazione. Oltre al consenso degli LLM, abbiamo rivisto a campione circa il 25% del set di query accettate a mano (revisione dell'autore su naturalezza della query, allineamento al documento target e conformità R9, indipendente dal voto dei validatori).

Ogni query ha superato la seguente pipeline prima di entrare nel set di produzione:

1. Scrittore redige una singola query ancorata a un documento campionato casualmente. Lo scrittore ruota tra Claude Sonnet 4.6, Qwen3.6-plus e Gemini 3 Flash preview in modo che nessun singolo modello domini l'impronta linguistica.
2. Valutatore (fisso: Claude Sonnet 4.6) valuta la query su una rubrica di specificità. Abbiamo richiesto semantic_bridge ≥ 4 (la query deve descrivere semanticamente ciò che il documento afferma, non solo corrispondere al nome) e unique_referent in 3-5 (gli ancoraggi descrittivi devono identificare all'incirca da uno a cinque documenti candidati nel corpus, non migliaia o esattamente uno).
3. Controllo hard-negative: estraiamo i 19 documenti distrattori BM25 top più il target ed eseguiamo un gate Jaccard di quasi duplicati (>0.5 → rifiutare l'intera query come verità di base ambigua).
4. Validatori (2 modelli, mai incluso lo scrittore) scelgono indipendentemente il documento target dal set di 20 candidati mescolati. Entrambi i validatori devono concordare sullo slot target esatto o la query viene scartata. "Nessuno dei precedenti" e "risposte corrette multiple" sono risposte valide dei validatori e scartano anch'esse la query.
5. Cohen’s kappa calcolato per coppia di validatori. Ogni query aveva esattamente 2 valutatori (i non-scrittori dal pool di 3 modelli), quindi le 3 possibili coppie che escludono lo scrittore ci danno 3 valori kappa separati per dominio. Li riportiamo singolarmente e come media ponderata per n.

Cohen's kappa per coppia con accordo osservato po e atteso per caso pe, calcolato sulle query accettate più tutti i rifiuti consensus_fail in cui entrambi i validatori hanno raggiunto una decisione. Le celle mostrano n / po / pe / κ:

La media ponderata per n è una sintesi descrittiva, non una statistica inferenziale. Condensa i tre kappa per coppia in un unico numero ponderato per quante query ha giudicato ciascuna coppia; non è di per sé un valore kappa per un dataset aggregato, e il relativo intervallo di confidenza dovrebbe essere calcolato tramite ricampionamento bootstrap a livello di query (rinviato alla v2.1).

Abbiamo usato il kappa di Cohen (non il kappa di Fleiss o l'alpha di Krippendorff) perché ogni query aveva esattamente 2 valutatori: l'inquadramento naturale qui sono 3 calcoli di Cohen a coppie, poiché vogliamo sapere se due modelli specifici concordano, non se un panel di 3 valutatori è coerente. L'alpha di Krippendorff darebbe un unico numero ma mescolerebbe le tre coppie nascondendo la varianza a livello di coppia.

Nello specifico di CUAD: Claude × Qwen raggiunge κ=0.974 mentre Claude × Gemini e Gemini × Qwen si attestano intorno a κ=0.86, il che isola Gemini-3-flash-preview come il giudice più rumoroso sui contratti legali. Questa informazione è un segnale metodologico che vale la pena far emergere, non mediare via.

Abbiamo promosso un dominio alla produzione dopo che il kappa medio ponderato per n ha superato 0.85. Tutti e tre lo hanno superato. Il valore di MedRAG di 0.986 è di fatto a tetto: i due disaccordi su 156 tentativi riguardavano target medicalmente ambigui in cui entrambi i validatori erano internamente coerenti ma uno ha scelto un abstract correlato ma non gold.

Regole R9 di anonimizzazione delle entità (per dominio)

R9 è un vincolo rigido al momento della generazione delle query. Senza di esso, BM25 sale sopra 0.97 nDCG@10 perché le entità denominate agiscono come perfette scorciatoie di parole chiave; gli embedding densi non hanno alcun vantaggio semantico da misurare. La regola è adattata per dominio affinché gli ancoraggi che trasportano davvero il segnale di recupero in quel dominio restino utilizzabili:

• CUAD rigoroso. Vieta tutte le entità denominate: nomi di parti, nomi di stati statunitensi, personale, importi monetari in dollari esatti, nomi di prodotto specifici. Impone unicità descrittiva: settore + ruolo + epoca temporale + fascia monetaria + ambito geografico. Il tetto BM25 è sceso da 0.97 a 0.591 dopo l'applicazione di R9.
• TechQA Opzione X. I nomi di prodotto IBM sono consentiti (sono il segnale di recupero primario per un amministratore di sistema) SE la query contiene anche un ancoraggio descrittivo secondario non di prodotto (classe di sintomi, famiglia di codici di errore, epoca di versione, contesto di distribuzione). I nomi dei clienti, gli stati USA e il personale restano vietati. Tetto BM25: 0.664.
• MedRAG medicale-allentato + sicuro contro le allucinazioni. Nomi di farmaci, termini di malattia, anatomia e simboli genici sono mantenuti verbatim dalla fonte perché sostituire le etichette di classe farmacologica rischia allucinazioni farmacologiche ("p-chloroamphetamine" è un rilasciante di serotonina della classe delle anfetamine, ma le traduzioni di etichette di farmaci rari da parte di LLM falliscono silenziosamente). La query deve contenere ≥2 ancoraggi non farmacologici affinché la pura corrispondenza per parola chiave del nome del farmaco non determini il risultato. Tetto BM25: 0.809 (proprietà strutturale del dominio, non un difetto metodologico).

Query di esempio

Per ogni esempio, la query è il testo che forniamo al modello di embedding. Il documento gold è l'unico elemento nel corpus (tra 509 contratti CUAD, 28.000 note tecniche TechQA o 50.000 abstract PubMed) che risponde effettivamente alla query. Il compito di recupero è: incorporare la query, calcolare la similarità coseno rispetto a ogni documento del corpus e classificarli. Se il documento gold si colloca al rango 1, la query ottiene 1.000 su nDCG@3; il rango 2 ottiene 0.631; il rango 3 ottiene 0.500; sotto i primi 3 ottiene 0.

CUAD (legale)

Query:

Documento gold (1 di 509 contratti CUAD): ANIXABIOSCIENCESINC_06_09_2020-EX-10.1-COLLABORATION AGREEMENT. È una collaborazione del 2020 tra un'azienda tedesca e una biotech statunitense per la scoperta di farmaci contro il COVID-19; il contratto specifica un pagamento milestone dovuto quando il primo paziente entra nella Fase I di una sperimentazione clinica. La query non contiene nomi di parti, importi monetari né geografie oltre due token di paese; il segnale di recupero è settore + temporale + struttura milestone.

TechQA (assistenza clienti)

Query:

Documento gold (1 di 28.000 IBM note tecniche): swg1IY43185, che documenta esattamente quel bug WebSEAL e indica la patch che lo risolve. Il nome di prodotto IBM (WebSEAL) è consentito nella nostra variante TechQA R9, ma il discriminatore è il pattern comportamentale del bug e l'ancoraggio di ordinamento delle richieste, non il solo nome del prodotto.

MedRAG (sanità)

Query:

Documento gold (1 di 50.000 abstract PubMed): PMID:231299, una sperimentazione clinica che confronta i tassi di abbandono per reazioni avverse tra cefradina e pivmecillinam in donne in gravidanza con infezioni del tratto urinario. I nomi dei farmaci sono mantenuti perché il confronto farmaco-contro-farmaco è il segnale di recupero, ma la query aggiunge popolazione di pazienti + durata del trattamento + inquadramento degli eventi avversi affinché una pura corrispondenza BM25 sul nome del farmaco non centri il target da sola.

Protocollo statistico

Gli intervalli di confidenza bootstrap al 95% utilizzano 10.000 ricampionamenti, metodo percentile, seed=2026 sul vettore metrico per query. Bootstrap appaiato sugli stessi indici di query per la significatività a coppie tra modello A e modello B (l'affermazione richiede ≥95% dei ricampionamenti con A > B).

Esecuzione singola per cella (modello, dominio). Un livello di varianza cross-sessione a 3 esecuzioni è rinviato alla v2.1 per motivi di costo. Le chiamate API di embedding all'interno della sessione sono deterministiche entro una differenza di coseno di poche parti per milione, verificata con controlli a campione; l'intervallo di confidenza bootstrap cattura quindi il rumore a livello di query, che è la fonte di varianza dominante a n=150-246.

Indicizzazione e punteggio

Nessun database vettoriale. Ogni modello codifica ogni documento del corpus una volta; la similarità coseno è calcolata direttamente in NumPy come prodotto matriciale denso di embedding normalizzati L2. Questo è esatto, non approssimato, quindi i pareggi di rango sono veri pareggi di modello e non artefatti ANN.

Regola di suddivisione in chunk per modello: i modelli con contesto da 512 suddividono con overlap 512+64; i modelli con contesto 8K-20K suddividono fino al contesto senza overlap; i modelli con contesto 32K+ acquisiscono l'intero documento quando ci sta (la coda lunga del 9% di CUAD supera ogni finestra di contesto non-Nemotron e ripiega sulla suddivisione; l'equità tra i modelli è preservata applicando la stessa politica per dimensione di contesto a ogni modello).

L'invocazione di recupero asimmetrico per modello è il singolo dettaglio metodologico più impattante e merita una sezione dedicata. È il motivo per cui gemini-embedding-2-preview ottiene 0.46 nDCG@10 con il campione di codice documentato di OpenRouter contro 0.91 con il formato Vertex IA di Google. Vedi "Come è stata valutata la pipeline di recupero con embedding" sopra per la tabella per famiglia.

Framework di valutazione: ranx come motore metrico primario; output in stile trec_eval compatibile con le submission della leaderboard MTEB. Intervallo di confidenza bootstrap calcolato da scripts/bootstrap_ci.py sugli array metrici per query salvati al passaggio di valutazione.

Modelli testati

I prezzi sono aggiornati al 2026-04-23 dal catalogo OpenRouter e dalla pagina dei prezzi diretta di Voyage.

nDCG@3 per modello con CI bootstrap al 95%

Gli intervalli di confidenza bootstrap al 95% sono calcolati tramite 10.000 ricampionamenti del vettore metrico per query (metodo percentile, seed=2026). Ampiezze di CI di 0.03-0.07 a queste dimensioni campionarie (n=154-246) significano che i divari nelle stime puntuali sotto ~0.03 sono entro il rumore e vanno trattati come pareggi. Ordinati per nDCG@3 medio sui 3 domini:

Quattro pareggi statistici in cui le classifiche a stima puntuale non sono significative al CI del 95%:

Limitazioni

Revisione umana di un autore: Un autore ha rivisto a campione circa il 25% delle query finali accettate per naturalezza, allineamento al target e conformità R9.

Ulteriori letture

Esplora altri benchmark RAG, come:

• I migliori 10 modelli di embedding multilingue per RAG
• I migliori 16 modelli di embedding open source per RAG
• I migliori database vettoriali per RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark dei reranker: confronto tra i migliori 8 modelli
• Modelli di embedding multimodali: Apple vs Meta vs OpenAI
• RAG ibrida: 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  = {{Modelli di embedding: OpenAI vs Gemini vs Voyage}},
  year   = {2026},
  month  = apr,
  howpublished    = {\url{https://aimultiple.com/embedding-models}},
  note   = {AIMultiple. Consultato il 25 Aprile 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