Modelli di embedding: OpenAI vs Gemini vs Voyage

Abbiamo confrontato 15 modelli di embedding testuali 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 è al primo posto 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 con cutoff 3. Con un solo documento rilevante per query, vale 1 / log2(rank + 1) quando il documento gold si classifica nella top 3, e 0 altrimenti. La posizione 1 ottiene 1.000, la posizione 2 ottiene 0.631, la posizione 3 ottiene 0.500. Usiamo nDCG@3 come metrica primaria perché le pipeline RAG di produzione forniscono all'LLM i primi 3-5 chunk, 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 gold appare nella top 10.

MRR@10: Rank reciproco medio con cutoff 10. Il gold in posizione 1 ottiene 1.000, in posizione 2 ottiene 0.500 e in posizione 10 ottiene 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-gold è il singolo risultato in cima. La metrica più severa e quella più vicina a un flusso di lavoro di ricerca 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 ottimizzati su CUAD ripagano con +0.040 nDCG@3 rispetto a voyage-4-large. openai/text-embedding-3-large si classifica 11° a 0.6430, sotto sei modelli più economici. Livello minimo BM25: 0.5844.

Assistenza clienti (TechQA, 151 query, 28.000 note tecniche IBM): Il divario da voyage-4-lite al modello successivo è 0.018. gemini-embedding-001 scende al 7° posto (0.8856), 0.045 dietro il suo gemello più recente su TechQA anche se vince negli altri due domini. Livello minimo 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. Livello minimo BM25: 0.7862, entro 0.02 dal modello denso più debole. gemini-embedding-001 batte anche gemini-embedding-2-preview con il 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 commetterà errori di classificazione sugli altri.

Gli intervalli di confidenza bootstrap al 95% per ciascuna cella di dominio, più i quattro pareggi a coppie che le classifiche puntuali 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, alla data del 2026-04-23. I prezzi Voyage provengono dalla pagina prezzi diretta di Voyage. I modelli serviti tramite OpenRouter usano lo snapshot del catalogo OpenRouter dello stesso giorno. I token di query e di documento hanno lo stesso prezzo per ogni vendor testato. BM25 è tracciato a $0,001/M per la resa su asse logaritmico. Il vero costo self-hosted è $0.

Media nDCG@3 su 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 ammiraglia commerciale e offre il 92% della qualità di voyage-3.5 (0.8604 / 0.9429). Nessun altro modello nel nostro benchmark compete al suo prezzo.
• Per la RAG aziendale orientata alla qualità, voyage-3.5 tramite l'SDK diretto Voyage conquista il punto Pareto migliore. Si scambia un'integrazione API aggiuntiva (rispetto a uno stack solo OpenRouter) per un modello leggermente migliore rispetto all'ammiraglia di Voyage a metà prezzo. L'istinto di "scegliere sempre il più nuovo e grande" è sbagliato all'interno del catalogo Voyage.
• Per distribuzioni OSS / self-hostable / on-premise, qwen3-embedding-8b vince. È l'embedder non banale più economico del nostro benchmark a $0,010/M, eguaglia o supera ogni altra famiglia di encoder OSS testata e viene fornito con pesi self-hostable.
• Le ammiraglie premium (openai-3-large, gemini-2-preview, voyage-4-large, gemini-001) perdono tutte contro voyage-3.5 sulla media a 3 domini, anche se voyage-3.5 è 2-3x più economico di qualsiasi di esse.

Risultati chiave dal benchmark degli embedding

voyage-3.5 vince la media a 3 domini e batte l'ammiraglia voyage-4-large a metà prezzo

voyage-3.5 ha una media di 0.9429 nDCG@3 tra legale, assistenza clienti e sanità. L'ammiraglia voyage-4-large ha una media di 0.9416 a $0,12 per 1M token, 2x il prezzo di $0,06 di voyage-3.5. L'ammiraglia vince TechQA di 0.002 e MedRAG di 0.032. Perde CUAD di 0.037 (0.8730 vs 0.9102), abbastanza perché la sua media su 3 domini scenda sotto voyage-3.5. Nella gamma Voyage, il modello di fascia media più vecchio è la scelta generalista migliore. L'ammiraglia guadagna il suo premium solo in sanità.

Voyage ha conquistato il primo posto in tutti e tre i domini e ha occupato i primi due posti su CUAD e TechQA. Su MedRAG, gemini-embedding-001 è entrato al 2° posto (0.9814, dietro lo 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 la top 2 in nessun singolo dominio.

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

google/gemini-embedding-001 (rilasciato 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 che arriva con un aumento di prezzo del 33% ($0,20 vs $0,15 per 1M token di input). L'inquadramento di "aggiornamento multimodale più recente" di Gemini 2 non regge nel recupero testuale in inglese sui 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 2°, 2-preview al 3°) è abbastanza grande 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 nei contratti legali: entrambe le ammiraglie 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. L'ammiraglia di OpenAI è 9° su TechQA (0.8581) e 11° su MedRAG (0.9296). La sanità la colloca in un cluster di testa compatto (spread dal 2° all'11°: 0.05 nDCG@3). Sul 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 OpenAI di default perché "è la scelta sicura" pagano un premium che i dati sui 3 domini non giustificano.

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

perplexity/pplx-embed-v1-0.6b a $0,004 per 1M token ha 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 nella lineup. 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 dove l'embedding è una voce di costo rilevante, pplx-0.6b è la scelta chiara. Il divario di 30-50x rispetto ai prezzi delle ammiraglie non acquista nulla in termini di 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à dense) 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). Il motivo è 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 ed 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 Cohere o Voyage può chiudere. 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 aiutano gli embedding densi.

Specialisti di dominio vs generalisti tra i vendor

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

Su CUAD, voyage-law-2 si classifica 1° a 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° a 0.9020, 0.064 dietro voyage-4-large e 0.063 dietro voyage-3.5. Su MedRAG, si classifica 6° a 0.9409, 0.045 dietro voyage-4-large e 0.041 dietro gemini-embedding-001. L'addestramento legale aumenta nDCG@3 su CUAD e lo riduce sugli altri due domini.

Un team legale che rilascia un 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 da voyage-4-large su MedRAG e 0.064 su TechQA. I modelli di embedding specializzati per dominio non sono migliorie drop-in per il recupero generico. Una singola raccomandazione di "modello migliore" tra i settori sbaglia in almeno una direzione.

Quando scegliere voyage-law-2: recupero di contratti su corpora legali commerciali che somigliano strutturalmente a CUAD. Quando non sceglierlo: qualsiasi altra cosa in questo benchmark. voyage-3.5 costa $0,06/M, si posiziona 0.0024 sotto voyage-law-2 su CUAD e lo supera sia su TechQA sia su MedRAG.

Come è stata valutata la pipeline di recupero degli embedding

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

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

Perché nDCG@3 come primaria. Le pipeline RAG di produzione forniscono all'LLM i primi 3-5 chunk, non i primi 10. Il bias di primazia negli LLM a contesto lungo fa sì che la posizione 1 conti più della posizione 3, e ogni distractor 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 gira senza per motivi di costo e latenza, quindi la posizione dell'embedder È la posizione finale.

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

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 dei domini + perché)

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

PM209 (manuali di produzione) è stato scartato: solo 209 documenti, troppo pochi per prevenire il problema di scorciatoia entità di BM25 con 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 valuta mai il proprio target di recupero, quindi l'auto-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 dell'LLM, abbiamo revisionato a campione circa il 25% del set di query accettate a mano (revisione dell'autore su naturalezza della query, allineamento del documento target e conformità R9, indipendentemente dal voto dei validatori).

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

1. Writer redige una singola query ancorata a un documento campionato casualmente. Il Writer 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. Scorer (fisso: Claude Sonnet 4.6) valuta la query con una rubrica di specificità. Abbiamo richiesto semantic_bridge ≥ 4 (la query deve descrivere semanticamente ciò che il documento afferma, non solo corrispondenza di nomi) 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: Preleviamo i primi 19 documenti distrattori BM25 più il target ed eseguiamo un gate di quasi-duplicazione Jaccard (>0.5 → rifiuta l'intera query come ground truth ambigua).
4. Validatori (2 modelli, mai inclusi lo scrittore) scelgono indipendentemente il documento target dal set mescolato di 20 candidati. Entrambi i validatori devono concordare sullo slot target esatto altrimenti la query viene scartata. "Nessuna delle precedenti" e "risposte corrette multiple" sono risposte valide dei validatori e scartano anch'esse la query.
5. Kappa di Cohen calcolato per coppia di validatori. Ogni query aveva esattamente 2 valutatori (i non scrittori del pool di 3 modelli), quindi le 3 possibili coppie escluso lo scrittore ci danno 3 valori kappa separati per dominio. Li riportiamo individualmente e come media ponderata per n.

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

La media ponderata per n è un riepilogo descrittivo, 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 suo CI dovrebbe essere calcolato tramite ricampionamento bootstrap a livello di query (rinviato alla v2.1).

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

Nello specifico 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 la kappa media ponderata per n ha superato 0.85. Tutti e tre l'hanno superata. Lo 0.986 di MedRAG è praticamente il tetto: i due disaccordi su 156 tentativi riguardavano target medici ambigui in cui entrambi i validatori erano internamente coerenti ma uno ha scelto un abstract correlato ma non gold.

Regole di anonimizzazione delle entità R9 (per dominio)

R9 è un vincolo rigido in fase di generazione delle query. Senza di esso, BM25 sale sopra 0.97 nDCG@10 perché le entità denominate fungono da scorciatoie perfette per le parole chiave; gli embedding densi non hanno alcun margine semantico da misurare. La regola è adattata per dominio in modo che gli ancoraggi che trasportano realmente il segnale di recupero in quel dominio rimangano utilizzabili:

• CUAD rigoroso. Vieta tutte le entità denominate: nomi di parte, nomi di stati USA, personale, importi monetari in dollari esatti, nomi di prodotti specifici. Forza l'unicità descrittiva: settore + ruolo + era temporale + intervallo monetario + 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 principale per un amministratore di sistema) SE la query contiene anche un ancoraggio descrittivo secondario non di prodotto (classe di sintomo, famiglia di codici di errore, era di versione, contesto di distribuzione). I nomi dei clienti, gli stati USA e il personale rimangono vietati. Tetto BM25: 0.664.
• MedRAG medico-attenuato + sicuro contro le allucinazioni. Nomi di farmaci, termini di malattia, anatomia, simboli genici mantenuti alla lettera dalla fonte perché sostituire le etichette di classe dei farmaci rischia allucinazioni farmacologiche ("p-chloroamphetamine" è un releaser di serotonina della classe delle anfetamine, ma le traduzioni delle etichette di farmaci più rari da parte dell'LLM falliscono silenziosamente). La query deve contenere ≥2 ancoraggi non farmacologici affinché la corrispondenza di parole chiave del solo nome del farmaco non determini il risultato. Tetto BM25: 0.809 (proprietà strutturale del dominio, non un difetto metodologico).

Esempi di query

Per ogni esempio, la query è il testo che forniamo al modello di embedding. Il documento gold è il singolo 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 classifica al 1° posto la query ottiene 1.000 su nDCG@3; al 2° ottiene 0.631; al 3° ottiene 0.500; sotto la top 3 ottiene 0.

CUAD (legale)

Query:

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

TechQA (assistenza clienti)

Query:

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

MedRAG (sanità)

Query:

Documento gold (1 dei 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 in modo che una corrispondenza BM25 del solo nome del farmaco non arrivi al target da sola.

Protocollo statistico

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

Singola esecuzione per cella (modello, dominio). Uno strato di varianza cross-sessione a 3 esecuzioni è rinviato alla v2.1 per motivi di costo. Le chiamate API di embedding intra-sessione sono deterministiche entro poche parti per milione di differenza coseno, verificato su spot-check; il bootstrap CI cattura quindi il rumore a livello di query che è la fonte di varianza dominante con n=150-246.

Indicizzazione e punteggio

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

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

L'invocazione di recupero asimmetrico per modello è il singolo dettaglio metodologico di maggior impatto e merita una sezione dedicata. È il motivo per cui gemini-embedding-2-preview ottiene 0.46 nDCG@10 secondo il codice di esempio documentato di OpenRouter contro 0.91 nel formato Vertex IA di Google. Vedi "Come è stata valutata la pipeline di recupero degli 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. Bootstrap CI calcolato da scripts/bootstrap_ci.py sugli array metrici per query salvati al passaggio di valutazione.

Modelli testati

I prezzi si intendono al 2026-04-23 dal catalogo OpenRouter e dalla pagina prezzi diretta Voyage.

nDCG@3 per modello con CI bootstrap al 95%

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

Quattro pareggi statistici in cui le classifiche puntuali non sono significative al 95% CI:

Limitazioni

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

Ulteriori letture

Esplora altri benchmark RAG, come ad esempio:

• Migliori 10 modelli di embedding multilingue per RAG
• Migliori 16 modelli di embedding open source per RAG
• Miglior database vettoriale per RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark dei reranker: confronto dei migliori 8 modelli
• Modelli di embedding multimodali: Apple vs Meta vs OpenAI

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}
}

Registro delle modifiche

4 aggiornamenti

1. 202624 Apr

   Sostituito il benchmark con 15 modelli e una baseline BM25 testati su corpora legali, di assistenza clienti e sanitari.

2. 202525 Nov

   Aggiunta la sezione Potenziali ragioni dietro le differenze di performance del modello di embedding.

3. 18 Lug

   Aggiornata la sezione Conclusione con nuove raccomandazioni sui modelli.

4. 10 Lug

   Sostituito Google con Gemini nell'introduzione.

Ekrem Sarı

Ricercatore IA

Segui

Ekrem è un Ricercatore IA e Data Scientist presso AIMultiple. Progetta ed esegue benchmark pratici per sistemi di IA 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