Modelli di embedding: OpenAI vs Gemini vs Voyage

Abbiamo eseguito benchmark su 15 modelli di embedding di testo in inglese e su 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 il livello medio-alto al prezzo più basso nel nostro benchmark.

Risultati del benchmark dei modelli di embedding

Spiegazione delle metriche

nDCG@3: Guadagno cumulativo scontato normalizzato al cutoff 3. Con un documento rilevante per query, è 1 / log2(rank + 1) quando il documento gold si posiziona tra i primi 3, e 0 altrimenti. Rank 1 ottiene 1.000, rank 2 ottiene 0.631, rank 3 ottiene 0.500. Utilizziamo nDCG@3 come metrica principale perché le pipeline di produzione RAG inviano i primi 3-5 chunk al LLM, e il bias di primazia rende il rank 1 sproporzionatamente importante.

nDCG@10: Stessa formula con cutoff 10.

Recall@10: Frazione di query in cui il documento gold appare tra i primi 10.

MRR@10: Reciproco medio del rank al cutoff 10. Gold al rank 1 ottiene 1.000, rank 2 ottiene 0.500, e rank 10 ottiene 0.100. Intento simile a nDCG@3 ma con una penalità di rank più ripida.

Top-1 hit: Frazione di query in cui il documento rilevante per il gold è l'unico risultato principale. La metrica più rigorosa 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 per CUAD si 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. Soglia BM25: 0.5844.

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

Sanità (MedRAG-PubMed, 154 query, 50.000 abstract): La sanità è il cluster più stretto nel nostro benchmark (14 modelli ottengono un punteggio superiore a 0.88) perché il vocabolario medico è denso di parole chiave, il che spinge la maggior parte delle query nel cluster principale. Soglia 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 ribaltoni a livello di dominio giustificano la formulazione della media a 3 domini: nessun singolo dominio è un proxy equo per "quale modello è il migliore", e un acquirente che sceglie in base a un dominio si classificherà erroneamente negli altri.

Gli intervalli di confidenza bootstrap al 95% per modello per ogni cella di dominio, più le quattro parità a coppie che le stime puntuali dei ranking nascondono, sono dettagliati nella sezione metodologia.

Accuratezza vs prezzo: Costo per 1M di token

Spiegazione delle metriche

Prezzo per 1M di token di input è il prezzo di listino per l'embedding di 1M di token di input, al 2026-04-23. I prezzi di Voyage provengono dalla pagina dei prezzi diretti di Voyage. I modelli serviti da OpenRouter utilizzano l'istantanea del catalogo OpenRouter dello stesso giorno. I token di query e documento sono prezzati allo stesso tasso per ogni fornitore testato. BM25 è tracciato a $0.001/M per il rendering in scala logaritmica. Il vero costo self-host è $0.

Media nDCG@3 a 3 domini è la media non ponderata di nDCG@3 per dominio attraverso i tre corpus. Ogni dominio contribuisce in egual misura 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-50 volte 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 prezzo.

• Per il RAG aziendale orientato alla qualità, voyage-3.5 tramite l'SDK diretto di Voyage prende il punto Pareto superiore. Si sacrifica 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 all'interno del catalogo di Voyage.

• Per le distribuzioni OSS / self-hostable / on-prem, qwen3-embedding-8b vince. È l'embedder non banale più economico nel nostro benchmark a $0.010/M, eguaglia o batte ogni altra famiglia di encoder OSS che abbiamo testato ed è fornito 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 a 3 domini, anche se voyage-3.5 è 2-3 volte più economico di ognuno di essi.

Principali risultati del benchmark di embedding

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

voyage-3.5 media 0.9429 nDCG@3 tra legale, assistenza clienti e sanità. Il flagship voyage-4-large media 0.9416 a $0.12 per 1M di token, 2 volte il prezzo di voyage-3.5 a $0.06. Il flagship vince TechQA di 0.002 e vince MedRAG di 0.032. Perde CUAD di 0.037 (0.8730 vs 0.9102), abbastanza da far sì che la sua media a 3 domini sia inferiore a voyage-3.5. All'interno della linea di Voyage, il modello di fascia media più vecchio è la scelta migliore per uso generale. Il flagship guadagna il suo premio solo sulla sanità.

Voyage ha preso il primo posto in tutti e tre i domini e ha spazzato il top-2 su CUAD e TechQA. Su MedRAG, gemini-embedding-001 è entrato in 2° posto (0.9814, dietro ai 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 il top-2 in un singolo dominio.

Un modello Gemini legacy batte il suo sibling "preview" più recente in 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) che 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 comporta un aumento di prezzo del 33% ($0.20 vs $0.15 per 1M di token di input). La formulazione "aggiornamento multimodale più recente" di Gemini 2 non regge nel recupero di testo in inglese su corpus legali o sanitari.

Per i carichi di lavoro RAG su quei due domini oggi, gemini-embedding-001 è la scelta corretta di Gemini. Il ribaltone su MedRAG (001 al 2°, 2-preview al 3°) è abbastanza grande che un acquirente che si affida al modello "più recente" perde qualità misurabile.

OpenAI text-embedding-3-large è di fascia media in ambito legale e assistenza clienti

openai/text-embedding-3-large si classifica 11° su 15 modelli densi su CUAD a 0.6430 nDCG@3. Otto modelli strettamente più economici lo battono sui contratti legali: entrambi i flagship della serie Voyage 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 mette in un cluster top stretto (differenza dal 2° all'11°: 0.05 nDCG@3). Sul legale il divario è ampio e costoso.

A $0.13 per 1M di token di input è 32 volte più costoso di pplx-embed-v1-0.6b. I team che si affidano a OpenAI perché "è la scelta sicura" stanno pagando un premio che i dati a 3 domini non giustificano.

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

perplexity/pplx-embed-v1-0.6b a $0.004 per 1M di token media 0.8604 nDCG@3 attraverso i 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 modello top-10 più economico successivo è qwen/qwen3-embedding-8b a $0.010 (2.5 volte di più), anch'esso servito tramite OpenRouter.

Per le piattaforme RAG orientate al costo in cui l'embedding è una voce di spesa significativa, pplx-0.6b è la scelta chiara. Il divario di 30-50 volte rispetto ai prezzi flagship non acquista nulla nella qualità del recupero, essenzialmente su 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 è entro 0.15 di 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 design (nomi di farmaci, nomi di malattie, termini di disegno dello studio, simboli genici), e quei token trasportano la maggior parte del segnale di recupero. Un classificatore in stile Lucene li corrisponde direttamente senza bisogno di contesto semantico.

Un reranker sopra BM25 è un'alternativa plausibile ed economica a un embedder denso premium per corpus densi di parole chiave: il divario di recupero che BM25 lascia (0.2 nDCG@3 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 è 0.33, su TechQA 0.36, su MedRAG 0.20. La densità del vocabolario del dominio è il singolo determinante più grande di quanto aiutino gli embedding densi.

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. Eseguendoli entrambi contro i generalisti su CUAD, TechQA e MedRAG si 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 alza nDCG@3 su CUAD e lo abbassa negli altri due domini.

Un team legale che esegue 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 specialisti di dominio non sono aggiornamenti plug-and-play per il recupero generico. Un'unica raccomandazione di "miglior modello" tra le industrie sbaglia in almeno una direzione.

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

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

Aggiungi come fonte preferita

Come è stata valutata la pipeline di recupero di 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 top-k per quella query. Con un documento gold per query e rilevanza binaria, il valutatore verifica se il gold appare tra i top-k e a quale rank. Quel rank alimenta nDCG@3 (il nostro principale), nDCG@10 (per compatibilità BEIR/MTEB), Recall@10 e Top-1 hit rate.

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 ("passa semplicemente il testo") degrada silenziosamente la qualità del recupero di 0.05-0.45 nDCG@10. La nostra lineup si divide in quattro modi:

Perché nDCG@3 come principale. Le pipeline di produzione RAG inviano i primi 3-5 chunk al LLM, non i primi 10. Il bias di primazia nei LLM a contesto lungo rende il rank 1 più importante del rank 3, e ogni distrattore che si posiziona sopra il gold nel contesto LLM è un candidato per confabulazione. I reranker appiattirebbero questo effetto, ma la maggior parte delle pipeline di produzione RAG gira senza uno per motivi di costo e latenza, quindi il rank dell'embedder È il rank finale.

Su MedRAG, Recall@10 ha raggiunto il soffitto di 1.000 per tre modelli Voyage e per qwen3-8b; nDCG@3 ha preservato una diffusione di 0.10 sulle stesse query. nDCG@10 mantiene la comparabilità BEIR ma ammorbidisce le differenze in cima alla lista che contano operativamente.

Metodologia del benchmark dei modelli di embedding

Corpora (selezione del dominio + perché)

Abbiamo scelto tre domini che stressano diverse proprietà di recupero e che coprono i tre RAG aziendali più comuni. Ogni corpus è fissato con SHA256, quindi qualsiasi lettore può riprodurre la cella esatta che abbiamo eseguito.

PM209 (manuali di produzione) è stato eliminato: solo 209 documenti, troppo piccoli per prevenire il problema dell'shortcut di entità BM25 a 150 query.

Generazione di query: protocollo di consenso 3-LLM

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

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

1. Scrittore abbozza 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. Scorer (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 circa uno a cinque documenti candidati nel corpus, non migliaia o esattamente uno).
3. Controllo hard-negative: Prendiamo i 19 documenti distrattori top BM25 più il target ed eseguiamo un cancello Jaccard quasi-duplicato (>0.5 → rifiuta l'intera query come verità di base ambigua).
4. Validatori (2 modelli, mai incluso lo scrittore) scelgono indipendentemente il documento target dal set mescolato di 20 candidati. Entrambi i validatori devono essere d'accordo sullo slot target esatto o la query viene scartata. "Nessuna delle precedenti" e "risposte multiple corrette" sono risposte valide del validatore e scartano anche la query.
5. Cohen's kappa calcolato per ogni coppia di validatori. Ogni query aveva esattamente 2 valutatori (i non-scrittori dal pool di 3 modelli), quindi le 3 possibili coppie escluse dallo scrittore ci danno 3 valori kappa separati per dominio. Li riportiamo individualmente e come media ponderata 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 n è un riepilogo descrittivo, non una statistica inferenziale. Condensa i tre kappa per coppia in un numero ponderato di quante query ha giudicato ciascuna coppia; non è essa stessa un valore kappa per un dataset raggruppato, e il CI su di esso dovrebbe essere calcolato tramite ricampionamento bootstrap a livello di query (rimandato alla v2.1).

Abbiamo usato Cohen's kappa (non Fleiss' kappa o alpha di Krippendorff) perché ogni query aveva esattamente 2 valutatori: la cornice 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'alpha di Krippendorff darebbe un numero singolo ma mescolerebbe le tre coppie insieme e nasconderebbe la varianza a livello di coppia.

CUAD specificamente: claude × qwen raggiunge κ=0.974 mentre claude × gemini e gemini × qwen si aggirano intorno a κ=0.86, il che isola Gemini-3-flash-preview come il giudice più rumoroso sui contratti legali. Quella informazione è un segnale metodologico che vale la pena evidenziare, non mediare via.

Abbiamo promosso un dominio alla produzione dopo che la media kappa ponderata n ha superato 0.85. Tutti e tre l'hanno superato. Lo 0.986 di MedRAG è effettivamente al soffitto: le due disaccordi su 156 tentativi erano su target medici ambigui in cui entrambi i validatori erano internamente coerenti ma uno ha scelto un abstract correlato ma non gold.

Set di regole di anonimizzazione delle entità R9 (per dominio)

R9 è un vincolo rigido al momento della generazione della query. Senza di essa, BM25 sale sopra 0.97 nDCG@10 perché le entità nominate agiscono come scorciatoie di parole chiave perfette; gli embedding densi non hanno un 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. Vietare tutte le entità nominate: nomi di parti, nomi di stati USA, personale, importi monetari in dollari esatti, nomi di prodotti specifici. Forzare l'univocità descrittiva: industria + ruolo + era temporale + intervallo monetario + ambito geografico. Il soffitto BM25 è sceso da 0.97 a 0.591 dopo l'attuazione di R9.
• TechQA Opzione X. Nomi di prodotti IBM consentiti (sono il segnale di recupero primario per un sysadmin) SE la query contiene anche un ancoraggio descrittivo secondario non prodotto (classe di sintomi, famiglia di codici di errore, era di versione, contesto di distribuzione). Nomi di clienti, stati USA, personale ancora vietati. Soffitto BM25: 0.664.
• MedRAG medico-allentato + sicuro dalle allucinazioni. Nomi di farmaci, termini di malattia, anatomia, simboli genici mantenuti verbatim dalla fonte perché sostituire le etichette di classe di farmaci rischia allucinazioni farmacologiche ("p-chloroamphetamine" è un rilasciatore di serotonina di classe amfetamina, ma le traduzioni di etichette LLM di farmaci più rari falliscono silenziosamente). La query deve contenere ≥2 ancoraggi non farmaco in modo che la corrispondenza di parole chiave del solo nome del farmaco non porti il risultato. Soffitto BM25: 0.809 (proprietà strutturale del dominio, non un difetto metodologico).

Query di esempio

Per ogni esempio, la query è il testo che inviamo al modello di embedding. Il documento gold è l'unico elemento nel corpus (su 509 contratti CUAD, 28.000 technotes TechQA o 50.000 abstract PubMed) che effettivamente risponde alla query. Il compito di recupero è: embeddare la query, calcolare la similarità coseno contro ogni documento nel corpus e classificarli. Se il documento gold si posiziona al rank 1 la query ottiene 1.000 su nDCG@3; rank 2 ottiene 0.631; rank 3 ottiene 0.500; sotto top-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 USA per la scoperta di farmaci 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 o geografie oltre due token di paese; il segnale di recupero è industria + temporale + struttura milestone.

TechQA (assistenza clienti)

Query:

Documento gold (1 di 28.000 IBM technotes): swg1IY43185, che documenta esattamente quel bug WebSEAL e nomina la patch che lo risolve. Il nome del prodotto IBM (WebSEAL) è consentito nella nostra variante TechQA R9, ma il discriminatore è il pattern comportamentale del bug e l'ancoraggio dell'ordine di richiesta, non il nome del prodotto da solo.

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-vs-farmaco è il segnale di recupero, ma la query aggiunge popolazione di pazienti + durata del trattamento + cornice di eventi avversi in modo che una corrispondenza BM25 del solo nome del farmaco non porti 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 dove A > B).

Un singolo esecuzione per cella (modello, dominio). Un livello di varianza cross-sessione a 3 esecuzioni è rimandato alla v2.1 per motivi di costo. Le chiamate API di embedding all'interno della sessione sono deterministiche entro alcune parti per milione di differenza coseno, verificate su controllo a campione; il CI 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 di matrice denso di embedding normalizzati L2. Questo è esatto, non approssimato, quindi i pareggi di rank sono veri pareggi di modello e non artefatti ANN.

Regola di chunking per modello: modelli 512-ctx chunkano 512+64 overlap; modelli 8K-20K-ctx chunkano al contesto senza overlap; modelli 32K+-ctx ingeriscono il documento completo quando si adatta (il 9% a coda lunga di CUAD supera ogni finestra di contesto non-Nemotron e ricade sul chunking; l'equità cross-modello è 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 sotto l'esempio di codice documentato di OpenRouter contro 0.91 sotto il formato Vertex AI di Google. Vedi "Come è stata valutata la pipeline di recupero di embedding" sopra per la tabella per famiglia.

Framework di valutazione: ranx come motore metrico principale; output in stile trec_eval compatibile con le sottomissioni alla classifica MTEB. CI bootstrap calcolato da scripts/bootstrap_ci.py sugli array metrici per query salvati al passaggio di valutazione.

Modelli testati

I prezzi sono 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% calcolati tramite 10.000 ricampionamenti del vettore metrico per query (metodo percentile, seed=2026). Le larghezze CI di 0.03-0.07 a queste dimensioni di campione (n=154-246) significano che i divari di stima puntuale inferiori a ~0.03 sono entro il rumore e dovrebbero essere trattati come pareggi. Ordinati per media nDCG@3 a 3 domini:

Quattro pareggi statistici in cui i ranking di stima puntuale non sono significativi al 95% CI:

Limitazioni

Revisione umana da parte di un autore: Un autore ha revisionato a campione circa il 25% delle query finali accettate per naturalezza, allineamento del target 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
• Top Database Vettoriale per RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark Reranker: Top 8 Modelli Confrontati
• Modelli di Embedding Multimodali: Apple vs Meta vs OpenAI
• RAG Ibrido: Migliorare l'Accuratezza RAG
• RAG Grafico vs RAG Vettoriale

Cita questo benchmark

Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.

@misc{sar2026,
  author = {Sarı, Ekrem},
  title  = {{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