Modelli di Embedding: OpenAI vs Gemini vs Voyage

Abbiamo valutato 15 modelli di embedding di testo 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 nel nostro benchmark.

Risultati del benchmark dei modelli di embedding

Metriche spiegate

nDCG@3: Guadagno cumulativo scontato normalizzato con cutoff 3. Con un documento rilevante per query, è 1 / log2(posizione + 1) quando il documento d'oro rientra nei primi 3, e 0 altrimenti. Posizione 1 ottiene 1.000, posizione 2 ottiene 0.631, posizione 3 ottiene 0.500. Usiamo nDCG@3 come metrica principale perché le pipeline RAG in produzione passano 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 tra i primi 10.

MRR@10: Rango reciproco medio con cutoff 10. L'oro in posizione 1 ottiene 1.000, posizione 2 ottiene 0.500, e 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 d'oro è il singolo risultato migliore. 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 dominio legale è l'unico in cui lo specialista voyage-law-2 vince; i suoi dati di addestramento ottimizzati per CUAD ripagano con +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. Livello base BM25: 0.5844.

Assistenza clienti (TechQA, 151 query, 28.000 note tecniche IBM): Il divario tra voyage-4-lite e il modello successivo è di 0.018. gemini-embedding-001 scende al 7° posto (0.8856), 0.045 dietro il suo fratello più recente su TechQA, anche se vince negli altri due domini. Livello base BM25: 0.6097.

Sanità (MedRAG-PubMed, 154 query, 50.000 abstract): La sanità è il cluster più compatto nel 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 superiore. Livello base 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 basandosi su un solo dominio classificherà male sugli altri.

Gli intervalli di confidenza bootstrap al 95% per modello per ogni cella di dominio, più i quattro pareggi a coppie che le classifiche basate su stime 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, aggiornato al 23-04-2026. I prezzi Voyage provengono dalla pagina dei prezzi diretti di Voyage. I modelli serviti da OpenRouter usano lo snapshot del catalogo OpenRouter dello stesso giorno. I token di query e documento hanno lo stesso prezzo per tutti i fornitori testati. BM25 è tracciato a $0.001/M per la resa grafica con asse logaritmico. Il vero costo di self-hosting è $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 piattaforme RAG orientate al risparmio, 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 livello di prezzo.

• Per RAG aziendale orientato alla qualità, voyage-3.5 tramite l'SDK diretto di Voyage rappresenta il miglior punto di Pareto. Si scambia un'integrazione API aggiuntiva (rispetto a uno stack solo OpenRouter) per un modello marginalmente migliore dell'ammiraglia di Voyage a metà prezzo. L'istinto di "scegliere sempre il più nuovo e il più grande" è sbagliato all'interno del catalogo Voyage.

• Per implementazioni OSS / self-hostable / on-premise, qwen3-embedding-8b vince. È l'embedder non banale più economico nel nostro benchmark a $0.010/M, eguaglia o supera ogni altra famiglia di encoder OSS che abbiamo testato ed è distribuito 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 dei 3 domini, anche se voyage-3.5 è 2-3x più economico di ognuna di esse.

Risultati chiave del benchmark di embedding

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

voyage-3.5 raggiunge una media di 0.9429 nDCG@3 nei domini legale, assistenza clienti e sanità. L'ammiraglia voyage-4-large raggiunge una media di 0.9416 a $0.12 per 1M token, 2x il prezzo di $0.06 di voyage-3.5. L'ammiraglia vince su TechQA di 0.002 e vince su MedRAG di 0.032. Perde su CUAD di 0.037 (0.8730 vs 0.9102), abbastanza perché la sua media sui 3 domini scenda sotto voyage-3.5. All'interno della gamma Voyage, il modello di fascia media più vecchio è la scelta generica migliore. L'ammiraglia giustifica il suo premium solo sulla sanità.

Voyage ha conquistato il primo posto in tutti e tre i domini e ha dominato i primi 2 su CUAD e TechQA. Su MedRAG, gemini-embedding-001 è entrato al 2° posto (0.9814, dietro a 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.

Un modello Gemini legacy batte il suo fratello "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) che su MedRAG (0.9814 vs 0.9685). Il modello più recente vince solo su TechQA (0.9301 vs 0.8856), un divario di 0.04 che comporta un aumento di prezzo del 33% ($0.20 vs $0.15 per 1M token di input). L'inquadramento come "aggiornamento multimodale più recente" di Gemini 2 non regge nel recupero di testo in inglese su corpora legali o sanitari.

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

OpenAI text-embedding-3-large è di fascia media nel dominio 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: 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 superiore compatto (intervallo dal 2° all'11° posto: 0.05 nDCG@3). Sul dominio 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 perché "è la scelta sicura" stanno pagando un premium che i dati sui 3 domini non giustificano.

pplx-embed-v1-0.6b raggiunge il livello superiore a un trentesimo del prezzo di ammiraglie comparabili

perplexity/pplx-embed-v1-0.6b a $0.004 per 1M token raggiunge 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 formazione. 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 prossimo modello della top-10 più economico è qwen/qwen3-embedding-8b a $0.010 (2.5x in più), anch'esso servito tramite OpenRouter.

Per piattaforme RAG orientate al risparmio dove l'embedding è una voce di costo materiale, pplx-0.6b è la scelta chiara. Il divario di 30-50x rispetto ai prezzi delle ammiraglie non porta alcun beneficio in termini di qualità del 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). Il motivo è strutturale: le query mediche sono dense di parole chiave per progettazione (nomi di farmaci, nomi di malattie, termini di disegno degli studi, simboli genetici), 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 al livello superiore su MedRAG) è il tipo di divario che un reranker Cohere o Voyage può colmare. Su CUAD il divario da BM25 al miglior modello denso è di 0.33, su TechQA di 0.36, su MedRAG di 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. Solo l'enfasi dei dati di addestramento differisce. Testarli entrambi contro i generalisti su CUAD, TechQA e MedRAG isola l'effetto dell'addestramento legale.

Su CUAD, voyage-law-2 si classifica 1° 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 abbassa sugli altri due domini.

Un team legale che distribuisce 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 assistenza 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 aggiornamenti diretti per il recupero generico. Una singola raccomandazione del "miglior modello" tra i settori sbaglia in almeno una direzione.

Quando scegliere voyage-law-2: recupero di contratti su corpora legali commerciali che assomigliano strutturalmente a CUAD. Quando no: qualsiasi altra cosa in questo benchmark. voyage-3.5 costa $0.06/M, si attesta 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 della query e ogni vettore di documento, quindi ordiniamo i top-k per quella query. Con un documento d'oro per query e rilevanza binaria, il valutatore verifica se l'oro compare nei top-k e a quale posizione. Quella posizione alimenta nDCG@3 (la nostra metrica principale), nDCG@10 (per comparabilità BEIR/MTEB), Recall@10 e 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 trasformazione, 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 formazione si divide in quattro modi:

Perché nDCG@3 come metrica principale. Le pipeline RAG in produzione passano i primi 3-5 chunk all'LLM, 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 distrattore che atterra sopra l'oro nel contesto dell'LLM è un candidato per la confabulazione. I reranker appiattirebbero questo effetto, ma la maggior parte dei RAG in produzione funziona 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 preservato una dispersione di 0.10 sulle stesse query. nDCG@10 mantiene la comparabilità BEIR ma attenua le differenze in cima alla lista che contano operativamente.

Scopri altri nostri benchmark e approfondimenti basati sui dati nella Ricerca Google.

Aggiungi come fonte preferita

Metodologia del benchmark dei modelli di embedding

Corpora (selezione del dominio e motivazione)

Abbiamo scelto tre domini che stressano diverse proprietà di recupero 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 prevenire il problema della scorciatoia delle entità 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 obiettivo 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 degli LLM, abbiamo revisionato a campione circa il 25% dell'insieme di query accettate a mano (revisione dell'autore sulla naturalezza della query, allineamento con il documento obiettivo e conformità R9, indipendente dal voto del validatore).

Ogni query ha superato la seguente pipeline prima di entrare nell'insieme di produzione:

1. Scrittore redige una singola query basata su 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 corrispondenza di nomi) e unique_referent tra 3-5 (gli ancoraggi descrittivi devono identificare circa da uno a cinque documenti candidati nel corpus, non migliaia o esattamente uno).
3. Verifica hard-negative: Prendiamo i primi 19 documenti distrattori BM25 più l'obiettivo ed eseguiamo un controllo Jaccard quasi-duplicati (>0.5 → rifiuta l'intera query come verità di base ambigua).
4. Validatori (2 modelli, mai includendo lo scrittore) scelgono indipendentemente il documento obiettivo dall'insieme mescolato di 20 candidati. Entrambi i validatori devono concordare sull'esatto slot obiettivo o la query viene scartata. "Nessuno dei precedenti" e "risposte corrette multiple" sono risposte valide del validatore e scartano anch'esse la query.
5. Kappa di Cohen 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 individualmente e come media ponderata per n.

Kappa di Cohen 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 numero ponderato per quante query ogni coppia ha giudicato; non è di per sé un valore kappa per un dataset aggregato, e l'IC su di esso 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'alfa 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 qualsiasi concordano, non se un panel di 3 valutatori è coeso. L'alfa di Krippendorff darebbe un singolo numero ma mescolerebbe le tre coppie insieme e nasconderebbe la varianza a livello di coppia.

CUAD nello specifico: 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. 0.986 di MedRAG è effettivamente al tetto: i due disaccordi su 156 tentativi riguardavano obiettivi medicalmente ambigui in cui entrambi i validatori erano internamente coerenti ma uno ha scelto un abstract correlato ma non d'oro.

Regole di anonimizzazione delle entità R9 (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à nominate fungono da scorciatoie perfette per parole chiave; gli embedding densi non hanno alcun vantaggio semantico da misurare. La regola è adattata per dominio in modo che gli ancoraggi che effettivamente trasportano il segnale di recupero in quel dominio rimangano utilizzabili:

• CUAD rigoroso. Vieta tutte le entità nominate: nomi delle parti, nomi degli stati USA, personale, importi monetari in dollari esatti, nomi di prodotti specifici. Forza l'unicità descrittiva: settore + ruolo + epoca temporale + intervallo monetario + ambito geografico. Il tetto BM25 è sceso da 0.97 a 0.591 dopo l'applicazione di R9.
• TechQA Opzione X. Nomi di prodotto IBM 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 sintomo, famiglia di codici di errore, epoca di versione, contesto di distribuzione). Nomi dei clienti, stati USA, personale ancora vietati. Tetto BM25: 0.664.
• MedRAG medical-relaxed + a prova di allucinazione. Nomi di farmaci, termini di malattie, anatomia, simboli genetici mantenuti testuali dalla fonte perché sostituire le etichette delle classi di farmaci rischia allucinazioni farmacologiche ("p-cloroanfetamina" è un rilasciatore di serotonina della classe delle anfetamine, ma le traduzioni delle etichette degli LLM di farmaci più rari falliscono silenziosamente). La query deve contenere ≥2 ancoraggi non farmacologici in modo che la corrispondenza per puro nome del farmaco non porti il risultato da sola. Tetto BM25: 0.809 (proprietà strutturale del dominio, non un difetto metodologico).

Query di esempio

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

CUAD (legale)

Query:

Documento d'oro (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 per 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 e geografie oltre a due token di paese; il segnale di recupero è settore + temporale + struttura milestone.

TechQA (assistenza clienti)

Query:

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

MedRAG (sanità)

Query:

Documento d'oro (1 di 50.000 abstract PubMed): PMID:231299, una sperimentazione clinica che confronta i tassi di abbandono per reazione avversa 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 per puro nome del farmaco non porti all'obiettivo da sola.

Protocollo statistico

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

Esecuzione singola 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 all'interno della sessione sono deterministiche entro poche parti per milione di differenza coseno, verificato su controlli a campione; l'IC bootstrap cattura quindi il rumore a livello di query che è la fonte di varianza dominante a n=150-246.

Indicizzazione e scoring

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 posizione sono veri pareggi del modello e non artefatti ANN.

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

L'invocazione del recupero asimmetrico per modello è il dettaglio metodologico di maggior impatto e merita una sezione dedicata. È il motivo per cui gemini-embedding-2-preview ottiene 0.46 nDCG@10 con l'esempio 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 di metriche principale; output compatibile con trec_eval e con le submission della leaderboard MTEB. IC bootstrap calcolato da scripts/bootstrap_ci.py sugli array di metriche per query salvati al passaggio di valutazione.

Modelli testati

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

nDCG@3 per modello con IC bootstrap al 95%

Intervalli di confidenza bootstrap al 95% calcolati tramite 10.000 ricampionamenti del vettore delle metriche per query (metodo percentile, seed=2026). Ampiezze IC di 0.03-0.07 a queste dimensioni del campione (n=154-246) significano che i divari nelle stime puntuali sotto ~0.03 sono all'interno del rumore e dovrebbero essere trattati come pareggi. Ordinati per media nDCG@3 su 3 domini:

Quattro pareggi statistici in cui le classifiche delle stime puntuali non sono significative all'IC 95%:

Limitazioni

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

Ulteriori letture

Esplora altri benchmark RAG, come:

• Top 10 Modelli di Embedding Multilingue per RAG
• Top 16 Modelli di Embedding Open Source per RAG
• Migliori Database Vettoriali per RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark Reranker: Top 8 Modelli a Confronto
• Modelli di Embedding Multimodali: Apple vs Meta vs OpenAI
• RAG Ibrido: Potenziare 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 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. I commenti vengono lasciati nella loro lingua originale.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento