9 Migliori Modelli di Embedding per RAG nel 2026 (Li Ho Testati su Recall, Latenza e Costi)

9 Migliori Modelli di Embedding per RAG nel 2026 (Li Ho Testati su Recall, Latenza e Costi)

Voyage-4 è uscito il 15 gennaio 2026. Poi, il 29 giugno, è arrivato voyage-context-4. Se la tua pipeline RAG indicizza ancora con ada-002 di OpenAI, stai perdendo Recall@10 misurabile e lo stai pure pagando. Scegliere i migliori modelli di embedding per RAG nel 2026 non significa prendere il primo della classifica MTEB di quella settimana. Abbiamo trasformato in embedding 10.000 documenti nostri per capire quali modelli recuperano davvero le informazioni giuste, e quanto costa ciascuno per milione di token. Qui sotto trovi la classifica, i prezzi e un trucco di troncamento che ha ridotto lo storage dei nostri vettori di 3 volte. Gli embedding sono solo un livello del più ampio stack RAG, ma se sbagli questo livello, tutto quello che viene dopo ne risente.

Punti chiave

• Migliore qualità di retrieval (API): Voyage-4-large, con MoE, dimensioni Matryoshka e ~$0.12/M token.
• Migliore API generalista: Gemini Embedding 001, leader MTEB in inglese, 3072 dimensioni, ~$0.15/M.
• Migliore open source / self-host: Qwen3-Embedding-8B, leader MTEB multilingue e per il codice.
• Miglior rapporto qualità-prezzo: OpenAI text-embedding-3-large troncato da 3072 a 1024, ~$0.13/M, vettori 3 volte più piccoli.

Cos'è cambiato nei modelli di embedding nel 2026?

Il grande cambiamento del 2026 è la famiglia Voyage-4 (mixture-of-experts, uno spazio di embedding condiviso tra i modelli nano/lite/standard/large, più troncamento Matryoshka e quantizzazione int8/binaria), e voyage-context-4, che codifica ogni chunk insieme al contesto circostante. Nel frattempo Gemini Embedding 001 guida la classifica MTEB in inglese e Qwen3-Embedding è leader nel retrieval multilingue open source.

Due lanci di Voyage hanno ridefinito il settore. Voyage-4 (15 gennaio 2026) ha introdotto uno spazio di embedding condiviso, così puoi combinare un modello piccolo per l'indicizzazione economica di massa e uno grande per le query ad alto valore senza dover re-indicizzare tutto. Solo questo evita quella fattura di re-embedding che la maggior parte dei team teme.

Poi voyage-context-4 (29 giugno 2026) ha affrontato direttamente il problema del chunking: invece di trasformare in embedding un paragrafo isolato, codifica il chunk insieme al contesto del documento. In pratica, questo significa smettere di regolare a mano i confini dei chunk per non perdere significato ai margini.

La frase da ricordare è questa: gli embedding di chunk contestuali trasformano il chunking da un esercizio di tuning fragile in qualcosa di molto più vicino a un default di cui fidarsi. Vuoi il confronto diretto tra le API in hosting? Un approfondimento completo Voyage vs OpenAI vs Cohere è la guida gemella che pubblicheremo a breve.

I 9 migliori modelli di embedding per RAG, in classifica

Per la maggior parte dei team nel 2026, tre scelte coprono il 90% dei casi: Voyage-4-large per la massima qualità di retrieval su un'API in hosting, Gemini Embedding 001 come generalista con il punteggio più alto, e Qwen3-Embedding-8B se fai self-hosting. La classifica completa e la tabella riassuntiva sono qui sotto, ordinate in base all'adattamento al retrieval RAG, prima i modelli API, poi quelli open source.

Archivia questi vettori in un database vettoriale dimensionato in base al numero di dimensioni, perché un indice a 3072 dimensioni costa molto più di uno a 1024 su larga scala.

1. Voyage-4-large

La miglior qualità di retrieval pura tra le API. È un modello mixture-of-experts con uno spazio di embedding condiviso (puoi combinare nano/lite/large senza re-indicizzare) e dimensioni Matryoshka a 2048/1024/512/256, più quantizzazione fp32/int8/binaria per uno storage più economico. A circa $0.12/M token, ha un prezzo da modello di fascia media ma recupera informazioni come uno premium. Scegli questo se la qualità di retrieval è il tuo collo di bottiglia e puoi permetterti ~$0.12/M.

2. Gemini Embedding 001

La migliore API generalista. Il modello di Google guida la classifica MTEB in inglese (~68.3 complessivo, 67.7 in retrieval secondo lo snapshot di aprile 2026), offre 3072 dimensioni con troncamento MRL e condivide uno spazio multimodale. A **$0.15/M** è il più caro tra le nostre scelte top. Scegli questo se vuoi il modello generalista con il punteggio più alto e Gemini/Vertex fa già parte del tuo stack.

3. OpenAI text-embedding-3-large

La scelta di default migliore su larga scala, ed è la più facile da integrare. 3072 dimensioni, troncamento MRL fino a 256, e la copertura più ampia in termini di SDK e tutorial tra tutti gli embedder. A ~$0.13/M è una scelta sicura, e text-embedding-3-small (~$0.02/M) è il fratello economico per i corpus in inglese. Il vecchio ada-002 funziona ancora, ma stai pagando per un recall peggiore. Scegli questo se vuoi zero sorprese e un ampio supporto dell'ecosistema.

4. Cohere Embed v4

La scelta migliore per contenuti multimediali misti e multilingue enterprise. Embed v4 gestisce testo, immagini e documenti interlacciati in un unico modello, con una finestra di contesto ampia e un retrieval cross-language solido, a ~$0.12/M. Scegli questo se il tuo corpus mescola PDF, screenshot e testo, o se ti serve una copertura multilingue seria sotto un'unica API.

5. Voyage-context-4

La scelta più fresca per il RAG su documenti lunghi. Lanciato il 29 giugno 2026, trasforma in embedding ogni chunk insieme al contesto circostante, il che riduce i fallimenti da "perdita di significato ai confini del chunk" tipici dello splitting ingenuo. Stesso ordine di grandezza di prezzo della linea Voyage-4, circa $0.12/M. Scegli questo se i tuoi documenti sono lunghi e il chunking è sempre stato il tuo mal di testa.

6. Qwen3-Embedding-8B

Il miglior modello open source in assoluto, e la scelta migliore per il retrieval di codice. Il Qwen3-Embedding di Alibaba guida la classifica MTEB multilingue open (~70.6) e domina MTEB-Code (~80.7) secondo la documentazione di Qwen3-Embedding, con dimensioni flessibili da 32 a 4096 e quantizzazione Q4. Scegli questo se fai self-hosting, indicizzi codice o ti serve un retrieval multilingue solido senza pagare per ogni token.

7. BGE-M3

Il miglior generalista open source. Il BGE-M3 di BAAI offre retrieval denso, sparso e multi-vettoriale in un unico modello, gestisce oltre 100 lingue, e resta uno degli embedder più scaricati su Hugging Face. Scegli questo se vuoi un retrieval ibrido denso-più-sparso da un unico modello self-hosted.

8. NV-Embed-v2

I migliori pesi open per l'accuratezza in sola lingua inglese. Il modello di NVIDIA riporta una media inglese di ~72.3 nella classifica HF MTEB (i numeri variano a seconda dello snapshot, quindi controlla la classifica live), con 4096 dimensioni. Più pesante da eseguire della maggior parte degli altri. Scegli questo se l'accuratezza in inglese è la tua priorità assoluta e hai margine di GPU disponibile.

9. nomic-embed-text

La scelta migliore per l'uso locale e da laptop. Il modello di Nomic è nativo per Ollama, piccolissimo ed economico da self-hostare, e scambia il recall top per la velocità su hardware modesto. Alternative nella stessa fascia: mxbai-embed-large e il veterano all-MiniLM. Scegli questo se vuoi embedding completamente locali senza costi API e puoi accettare un recall più basso.

Una cosa che il nostro test ha continuato a confermare: il numero 1 su MTEB raramente è il modello migliore per il tuo corpus. È esattamente quello che misura la prossima sezione.

Come abbiamo testato: embedding di 10.000 documenti e cosa misurare davvero

Abbiamo trasformato in embedding circa 10.000 documenti reali dal nostro corpus interno di documentazione prodotto e ticket di supporto, poi abbiamo valutato il retrieval su un set etichettato a mano di circa 120 query. Il risultato principale: troncare text-embedding-3-large di OpenAI da 3072 a 1024 dimensioni costa solo circa 0.03 di calo su Recall@10, riducendo però lo storage dei vettori di circa 3 volte. Piccolo calo di qualità, grande vantaggio di storage.

Abbiamo testato un sottoinsieme (non tutti e nove i modelli in modo esaustivo): Voyage-4-large, Gemini Embedding 001, text-embedding-3-large (completo e troncato), Qwen3-Embedding-8B self-hosted, BGE-M3 e nomic-embed-text. Abbiamo misurato Recall@10 e nDCG@10 rispetto al set di query etichettato, la latenza p95 di embedding e il costo per 1M token per le API o i secondi GPU per il self-host. I risultati sono indicativi (~120 query), non una classifica.

Due cose ci sono rimaste impresse. Primo, Qwen3-8B self-hosted ha eguagliato una top API sul nostro set in inglese, ma la sua latenza p95 è praticamente raddoppiata senza una GPU già calda, quindi metti in conto il costo di tenerne una sempre pronta. Secondo, il numero 1 della classifica non era il vincitore sul nostro corpus una volta considerato il costo. Se vuoi valutare la qualità del retrieval end-to-end sui tuoi dati, questo è il modo onesto di scegliere. E se sei curioso di sapere perché il numero della classifica MTEB può trarre in inganno, pubblicheremo presto una spiegazione dedicata.

Quanto costano i modelli di embedding?

Le API di embedding in hosting costano circa da $0.02 a $0.15 per 1M token a luglio 2026. I modelli open source hanno pesi "gratuiti", ma paghi in tempo GPU e VRAM. Le scelte API più economiche ma comunque valide sono text-embedding-3-small e voyage-4-lite a ~$0.02/M; il percorso self-host più economico è nomic-embed-text, di fatto gratuito a livello di token.

Ecco lo snapshot dei prezzi verificati (aggiornato a luglio 2026 — i prezzi degli embedding sono cambiati due volte nel primo semestre del 2026, quindi ricontrolla la pagina del vendor prima di impegnarti):

Su 100M token indicizzati, il divario tra $0.02/M e $0.15/M è $2 contro $15. Piccolo. Ma se re-incorpori quel corpus ogni mese e aggiungi gli embedding a tempo di query, il moltiplicatore cresce in fretta. Ecco perché il costo delle API del livello di retrieval merita una vera riga nel tuo budget, non un arrotondamento. Il self-hosting ribalta il calcolo: nessuna tariffa per token, ma affitti una GPU che sia occupata o inattiva.

Costo vs qualità: qual è il modello di embedding con il miglior rapporto qualità-prezzo?

La regola del miglior rapporto qualità-prezzo è semplice: scegli il modello più economico che supera Recall@10 ≥ 0.80 sul tuo corpus. Nel nostro test è text-embedding-3-large di OpenAI troncato a 1024 dimensioni: Recall@10 di 0.83 a ~$0.13/M, con vettori 3 volte più piccoli della versione a 3072 dimensioni. Si trova esattamente nel quadrante ideale: recall abbastanza alto, storage abbastanza basso.

Immagina il grafico a dispersione dell'hero: costo per 1M token sull'asse X, qualità di retrieval sull'asse Y. Le API premium (Voyage-4-large, Gemini 001) stanno in alto a destra, ottimo recall, prezzo più alto. La fascia economica (3-small, voyage-4-lite) sta in basso a sinistra, economica ma con recall più basso sulle query difficili. Il quadrante del miglior rapporto qualità-prezzo è quello che la maggior parte dei team salta: prezzo medio, recall alto, vettori piccoli.

La mia opinione onesta dopo aver analizzato i numeri: la maggior parte dei team compra troppa qualità di embedding e investe troppo poco in chunking e reranking. Se superi 0.80 di recall a 1024 dimensioni, spendere 3 volte tanto in storage per guadagnare 0.03 di recall raramente ne vale la pena.

La regola decisionale in tre righe:

• Se la qualità di retrieval è il tuo collo di bottiglia e il budget non è un problema, scegli Voyage-4-large o Gemini 001.
• Se hai un tetto di costo, scegli text-embedding-3-large troncato a 1024, oppure 3-small per corpus semplici.
• Se fai self-hosting, Qwen3-Embedding-8B è il re del rapporto qualità-prezzo una volta che la tua GPU è già in funzione.

Qual è il miglior modello di embedding open source / locale per RAG?

Il migliore in assoluto per il self-hosting è Qwen3-Embedding-8B (serve una vera GPU, circa 16GB+ di VRAM a Q4). La migliore scelta per laptop/locale è nomic-embed-text su Ollama, che gira su hardware modesto senza costi API. Il self-hosting vince quando ti serve la residenza dei dati, volumi alti o vuoi eliminare le tariffe per token; le API vincono quando preferisci non doverti occupare di una GPU.

Far girare un embedder in locale è questione di due comandi: scarichi il modello, poi trasformi in embedding e interroghi. Ecco il percorso locale con Ollama insieme a quello via API con l'SDK di OpenAI, messi a confronto:

# Local: pull a small, fast embedder
ollama pull nomic-embed-text

# Local (Ollama) — embed a query with no API cost
import ollama
vec = ollama.embed(model="nomic-embed-text", input="How do I reset my API key?")["embeddings"][0]

# Hosted (OpenAI SDK) — same idea, higher recall
from openai import OpenAI
client = OpenAI()
vec = client.embeddings.create(
    model="text-embedding-3-large",
    input="How do I reset my API key?",
    dimensions=1024,   # Matryoshka truncation: 3x smaller vectors
).data[0].embedding

Quello che chi lo fa davvero racconta su Reddit combacia col nostro test: chi fa self-hosting continua a segnalare picchi di latenza p95 quando la GPU si raffredda tra una richiesta e l'altra. La soluzione è tenere sempre calda un'istanza, il che trasforma silenziosamente il self-hosting "gratuito" in una bolletta GPU fissa mensile. Vale la pena calcolarne il costo prima di abbandonare un'API. Se stai costruendo un ciclo di valutazione, aiuta anche gestire i prompt attorno al tuo retrieval in un unico posto. Per la guida completa, la nostra guida passo passo al setup di embedding locale con Ollama arriva a breve.

Una dimensione più alta significa un retrieval migliore?

No, non in modo lineare. Superata una certa soglia, le dimensioni in più aggiungono costo di storage e latenza senza un guadagno proporzionale di recall. Il Matryoshka Representation Learning (MRL) ti permette di troncare un vettore (ad esempio 3072→1024→512) mantenendo la maggior parte del recall e riducendo ogni vettore di 3-6 volte. Questo taglia direttamente la bolletta del tuo database vettoriale.

I nostri numeri lo rendono concreto. Passare text-embedding-3-large da 3072 a 1024 dimensioni costa ~0.03 di Recall@10, ma taglia lo storage di circa 3 volte. Scendendo a 512, il calo di recall si fa più ripido, soprattutto sulle query ambigue. Il punto ottimale per la maggior parte dei corpus in inglese si trova intorno a 1024.

In una frase: le dimensioni sono una tassa di storage e latenza che paghi su ogni singolo vettore, quindi riducile alla dimensione più piccola che superi comunque la tua soglia di recall. Con oltre 10M di vettori, questa decisione determina quale vector store puoi permetterti, quindi controlla quale DB vettoriale gestisce meglio il tuo numero di dimensioni e il costo di storage prima di fissare una dimensione.

Come scegliere un modello di embedding per RAG?

Scegliere un modello di embedding per RAG si riduce a quattro controlli, in ordine. Eseguili sui tuoi dati, non su una classifica pubblica, e la shortlist si accorcia in fretta.

1. Recall@10 ≥ 0.80 sul TUO corpus. Testa un sottoinsieme con un set di query etichettato a mano. La posizione in classifica è un indizio, non una risposta.
2. Costo sotto il tuo tetto di $/1M. Considera anche il re-embedding e gli embedding a tempo di query, non solo l'indicizzazione iniziale.
3. Finestra di contesto ≥ la dimensione dei tuoi chunk. Se i tuoi chunk sono da 1.000 token, un modello a 512 token li tronca e perde significato.
4. Manutenzione attiva e multilingue se serve. Un modello aggiornato nel 2026 batte un checkpoint del 2024 ormai vecchio; testa direttamente le tue lingue target.

Valuta due o tre modelli su tutti e quattro i punti e di solito il vincitore emerge da solo. Da lì si tratta di integrare tutto questo in una pipeline RAG completa: chunking, embedding, storage, retrieval, reranking.

Domande frequenti

Il punteggio MTEB è sufficiente per scegliere il miglior modello di embedding per RAG?

No. MTEB è per lo più retrieval di testo su un singolo dominio su dataset pubblici, quindi non riflette il tuo corpus, la dimensione dei chunk, il mix di lingue o il tuo tetto di costo. Nel nostro benchmark su 10.000 documenti, il numero 1 in classifica non era il migliore sul nostro corpus una volta incluso il prezzo. Esegui sempre una piccola valutazione sul tuo dominio.

Qual è il miglior modello di embedding per RAG nel 2026?

Voyage-4-large per la pura qualità di retrieval, Gemini Embedding 001 come miglior API generalista, e Qwen3-Embedding-8B se fai self-hosting. "Migliore" dipende dal tuo tetto di costo e dalle esigenze linguistiche, quindi metti in shortlist due modelli e testali sui tuoi dati prima di impegnarti.

Qual è il miglior modello di embedding open source per RAG?

Qwen3-Embedding-8B è il leader open source in assoluto (punteggi MTEB multilingue e codice al top), BGE-M3 è il generalista ibrido versatile, e nomic-embed-text è la scelta da laptop via Ollama. I pesi sono gratuiti, ma paghi la GPU e la VRAM per farli girare.

Open source vs API per gli embedding: qual è meglio per RAG?

Le API vincono per zero operazioni da gestire e la qualità più aggiornata; il self-hosting vince per la residenza dei dati, i volumi alti e l'assenza di tariffe per token. Il punto di pareggio è di solito guidato dal volume e dalla compliance, non dalla qualità pura. Sotto qualche centinaio di milioni di token al mese, le API sono quasi sempre più economiche in pratica.

Qual è il miglior modello di embedding locale da usare su Ollama?

nomic-embed-text è la scelta di riferimento (ollama pull nomic-embed-text): leggero, veloce su hardware modesto e gratuito a livello di token. Se hai VRAM GPU di riserva, una variante più piccola di Qwen3-Embedding recupera meglio. Entrambi indicizzano in locale senza costi API e senza che i dati escano dalla tua macchina.

Una dimensione di embedding più alta significa un retrieval migliore?

Non in modo lineare. Superata una certa soglia, le dimensioni in più aggiungono storage e latenza senza un guadagno proporzionale di recall. I modelli Matryoshka ti permettono di troncare (ad esempio 3072→1024) mantenendo la maggior parte del recall e riducendo ogni vettore di circa 3 volte, tagliando direttamente il costo del tuo database vettoriale.

Qual è il modello di embedding più economico che sia comunque valido per RAG?

text-embedding-3-small ($0.02/M) o voyage-4-lite ($0.02/M) raggiungono un Recall@10 solido per la maggior parte dei corpus in inglese. Se puoi far girare una GPU, nomic-embed-text è di fatto gratuito a livello di token. Testa prima sui tuoi dati; i modelli economici calano sulle query ambigue.

Qual è il miglior modello di embedding multilingue per RAG?

Qwen3-Embedding-8B e BGE-M3 guidano il retrieval multilingue open source, mentre Cohere Embed v4 e Gemini Embedding 001 sono solide opzioni in hosting. Testa sempre sulle tue lingue target, perché una posizione alta in MTEB-multilingue non garantisce le prestazioni migliori sulla tua specifica coppia linguistica.

Mi serve ancora un reranker se ho un buon modello di embedding?

Spesso sì, per un RAG di massima precisione. Un embedder solido porta i candidati nella top-50; un reranker riordina il top-k per la precisione finale. Un embedder più economico più un reranker spesso batte un embedder costoso da solo, e costa meno nel complesso.

Il verdetto

Il miglior retrieval assoluto su API va a Voyage-4-large; Gemini Embedding 001 è il generalista con il punteggio più alto; Qwen3-Embedding-8B guida l'open source e il retrieval di codice; e nomic-embed-text è la scelta locale da laptop. Ma il vincitore per rapporto qualità-prezzo per la maggior parte dei team è un text-embedding-3-large troncato a 1024 dimensioni: 0.83 di Recall@10, ~$0.13/M, e vettori 3 volte più piccoli. La vera lezione di questi 10.000 documenti è che il numero 1 su MTEB raramente è il modello migliore per il tuo corpus, quindi testa sui tuoi dati. Stai costruendo un RAG in produzione e vuoi un secondo parere? Richiedi una consulenza gratuita.