Reranker benchmark: confronto tra i migliori 8 modelli
Abbiamo testato 8 modelli di reranking su ~145k recensioni Amazon in inglese per misurare quanto una fase di reranking migliori il recupero denso. Abbiamo recuperato i primi 100 candidati con multilingual-e5-base, li abbiamo riordinati con ciascun modello e abbiamo valutato i primi 10 risultati rispetto a 300 query, ognuna delle quali fa riferimento a dettagli concreti della recensione di origine. Il miglior reranker ha portato Hit@1 dal 62.67% al 83.00% (+20.33pp).
Risultati del benchmark dei reranker
Metriche spiegate:
ΔHit@1 / ΔHit@10 mostra il miglioramento rispetto alla baseline (nessun reranker) in punti percentuali (pp). Ad esempio, +20.33pp significa che il reranker ha migliorato Hit@1 di 20.33 punti percentuali rispetto al 62.67% della baseline.
Hit@K misura se una qualsiasi recensione con il product_id corretto compaia nei primi K risultati. La ground truth è il product_id della recensione che ha generato la query. Se una recensione diversa dello stesso prodotto finisce nei primi K, viene conteggiata come hit. Hit@1 è il test più severo: il primo risultato proviene dal prodotto giusto? Hit@10 è più tollerante: il prodotto giusto si trova da qualche parte tra i primi 10 risultati?
MRR@10 (Mean Reciprocal Rank) calcola la media di 1/rank del primo risultato corretto su tutte le query. Se il primo product_id corrispondente è al rank 1, il punteggio è 1.0. Al rank 2, è 0.5. Al rank 10, è 0.1. Questo premia i modelli che collocano il prodotto corretto il più in alto possibile.
nDCG@10 (Normalized Discounted Cumulative Gain) valuta le posizioni di tutte le recensioni corrispondenti nei primi 10, non solo la prima. Se lo stesso prodotto ha più recensioni nel set candidato e diverse finiscono nei primi 10, nDCG accredita ciascuna in base alla sua posizione. In pratica, la maggior parte dei prodotti ha solo 1-2 recensioni nei primi 100 candidati, quindi nDCG e MRR seguono un andamento simile.
Recall@10 misura la frazione di recensioni corrispondenti (stesso product_id) nei primi 10 rispetto a tutte le recensioni corrispondenti nell'intero insieme candidato (primi 100). Se un prodotto ha 3 recensioni nei primi 100 e il reranker ne colloca 2 nei primi 10, Recall@10 è 2/3 per quella query. Poiché la maggior parte dei prodotti ha poche recensioni duplicate nell'insieme candidato, Recall@10 e Hit@10 sono quasi identici in questo benchmark.
Analisi della latenza
La latenza di reranking misura il tempo impiegato da ciascun cross-encoder per valutare 100 documenti candidati rispetto alla query. Il tempo di ricerca vettoriale (~20ms) è escluso poiché rimane costante in tutte le esecuzioni ed è indipendente dal reranker.
Metriche di latenza spiegate:
Rerank è il tempo impiegato dal cross-encoder per valutare tutti i 100 documenti candidati rispetto alla query. È qui che i modelli si differenziano: un singolo forward pass è veloce, mentre la decodifica autoregressiva è lenta.
P95 è il 95 percentile della latenza totale. Alcune query hanno testi di recensioni più lunghi, il che aumenta i tempi di tokenizzazione e di valutazione. P95 mostra il caso peggiore previsto per il 95% delle query.
Risultati principali
Un modello da 149M eguaglia un modello da 1.2B
gte-reranker-modernbert-base ha 149M parametri, nemotron-rerank-1b ne ha 1.2B. Entrambi raggiungono un Hit@1 dell'83.00% in inglese. L'architettura ModernBERT è 8x più piccola e offre la stessa accuratezza complessiva.
Questo non significa che la dimensione del modello sia irrilevante. Nemotron è leggermente avanti su MRR@10 (0.8514 contro 0.8483) e Hit@10 (88.33% contro 88.00%), il che significa che classifica i documenti pertinenti leggermente meglio nell'intera top-10. Ma per la maggior parte delle applicazioni in cui conta ottenere giusto il primo risultato, il modello da 149M è sufficiente.
Il modello più grande non è il migliore
qwen3_reranker_4b ha 4B parametri e impiega oltre un secondo per query. Ottiene un Hit@1 del 77.67%, collocandosi quarto dietro a nemotron (1.2B), gte_modernbert (149M) e jina (560M). Si paga una latenza 4.5x quella di nemotron per una precisione inferiore di 5.3 punti percentuali.
L'architettura di Qwen3 utilizza la modellazione linguistica causale con un approccio logit sì/no. Il modello legge la coppia query-documento e restituisce la probabilità di “sì, questo è pertinente”. Il concetto è pulito, ma l'inferenza è costosa a causa dell'overhead della decodifica autoregressiva. I modelli SequenceClassification (gte_modernbert, bge) e l'approccio con template di prompt di nemotron elaborano la coppia in un unico forward pass, risultando fondamentalmente più veloci.
Jina offre il miglior compromesso velocità-accuratezza
jina_reranker_v3 raggiunge l'81.33% di Hit@1 a 188ms. Nemotron raggiunge l'83.00% a 243ms. Se serve una latenza totale per query inferiore a 200ms, Jina è l'unico modello della fascia alta a offrirla. Il divario di 1.67 punti percentuali potrebbe non giustificare i 55ms extra in un sistema di produzione che serve migliaia di richieste al secondo.
Un reranker peggiora i risultati
mxbai_rerank_xsmall (70M parametri) ottiene un Hit@1 del 64.67%. La baseline senza alcun reranker ottiene il 62.67%. Il miglioramento è di soli 2 punti percentuali, che rientra nel rumore per 300 query. Con 70M parametri, il modello non ha la capacità di valutare in modo affidabile la pertinenza query-documento su testi più lunghi o ricchi di sfumature.
Un reranker non è automaticamente vantaggioso. Testatelo sui dati reali prima di metterlo in produzione.
Il retriever stabilisce il tetto
Tutti i migliori reranker convergono intorno all'87-88% di Hit@10. Questo tetto deriva dal retriever. Se multilingual-e5-base non colloca il documento corretto tra i primi 100 candidati, nessun reranker può recuperarlo. Il restante 12% di query in cui ogni reranker fallisce rappresenta i casi in cui il retriever denso ha semplicemente mancato del tutto il documento pertinente.
Migliorare oltre questo tetto richiede un retriever migliore, un pool di candidati più ampio o entrambi. Abbiamo testato i primi 250 candidati e abbiamo riscontrato quasi nessun miglioramento rispetto ai primi 100, il che significa che e5_base esaurisce i candidati utili ben prima del rank 250.
Come funzionano i reranker
Un retriever denso (bi-encoder) codifica query e documenti indipendentemente in vettori. Il recupero è una ricerca di nearest-neighbor su questi vettori. È veloce perché si codifica solo la query al momento della ricerca, ma il modello non vede mai query e documento insieme, quindi può perdere segnali di pertinenza ricchi di sfumature.
Un reranker (cross-encoder) prende una coppia query-documento come unico input. Il modello esamina entrambi i testi congiuntamente, cogliendo relazioni che la codifica indipendente perde. Il costo è che è necessario eseguire il modello una volta per candidato, quindi ci si può permettere di valutare solo un insieme ristretto.
Architetture in questo benchmark
Abbiamo testato quattro diverse architetture di cross-encoder:
I modelli SequenceClassification (bge_base, bge_v2_m3, mxbai_xsmall, gte_modernbert) prendono una coppia [query, document] come input e restituiscono un singolo punteggio logit. È l'approccio più semplice e più comune.
Nemotron utilizza un formato di template di prompt: “question:{q} passage:{p}”. L'input appare come testo semplice piuttosto che come coppia strutturata, ma il modello restituisce comunque un singolo punteggio di pertinenza tramite SequenceClassification. Il pretraining del LLM (basato su Llama) gli conferisce una forte comprensione linguistica.
I reranker Qwen3 utilizzano la modellazione linguistica causale. Il modello legge la coppia e genera un giudizio sì/no. Il punteggio è log P(yes) / (P(yes) + P(no)). Ciò richiede l'intero apparato autoregressivo, il che spiega la latenza più alta.
Jina v3 utilizza una API personalizzata (model.rerank()) che gestisce internamente tokenizzazione e punteggio. L'architettura sottostante utilizza la cross-attention, ma l'interfaccia astrae i dettagli.
Metodologia del benchmark dei reranker
- GPU: NVIDIA H100 PCIe 80GB tramite Runpod
- Database vettoriale: Qdrant 1.12.0 (binario locale), distanza coseno
- Retriever: multilingual-e5-base (768-dim). Prefisso query:
"query: ", prefisso documento:"passage: " - Software: transformers 5.2.0, PyTorch 2.8.0, CUDA 12.8.1
- Dataset: sottoinsieme inglese di Amazon Reviews Multi (Kaggle).1 ~145k recensioni dopo il filtraggio per un minimo di 100 caratteri. Ogni recensione ha un product_id, il testo della recensione e una valutazione a stelle.
- Generazione delle query: Claude Sonnet 4.6 tramite OpenRouter. 300 query in inglese (5 tipi: fattuale, opinione, utilizzo, risoluzione di problemi, confronto di funzionalità). Ogni query deve fare riferimento a dettagli specifici della recensione di origine; le domande generiche (punteggio di specificità < 4/5) vengono filtrate.
- Formato documento:
"Review Title: {title}\nReview: {body}" - Pipeline: Recupera i primi 100 candidati con multilingual-e5-base, esegue il reranking con il cross-encoder e restituisce i primi 10. La baseline salta il reranking e restituisce direttamente i primi 10 del retriever.
- Ground truth: solo corrispondenza esatta del product_id. Nessun fallback alla similarità del coseno. Nessun punteggio parziale per prodotti semanticamente simili.
- Variabile controllata: Solo il modello di reranker cambia tra gli esperimenti. Retriever, numero di candidati, set di query e criteri di valutazione sono identici in tutte le esecuzioni.
- Nessun fine-tuning: Tutti i modelli sono stati valutati zero-shot con i pesi HuggingFace predefiniti.
- Latenza: Reranking (valutazione cross-encoder di 100 candidati). Misurata per singola query su GPU.
Modelli testati
Aggiungi come fonte preferitaLimitazioni
Questo benchmark utilizza un singolo retriever (multilingual-e5-base). Un retriever diverso produrrebbe insiemi di candidati diversi e potrebbe modificare la classifica dei reranker. I risultati riflettono quanto bene ciascun reranker funziona con questo specifico retriever, non la qualità del reranker isolatamente.
Abbiamo testato su recensioni di prodotto in inglese di Amazon. Le prestazioni su altri domini (articoli scientifici, documenti legali, codice) o altre lingue saranno diverse.
Il numero di candidati è fissato a 100. Alcuni reranker potrebbero classificare in modo diverso con 20 o 200 candidati. Abbiamo testato 250 candidati e abbiamo riscontrato un miglioramento trascurabile, il che suggerisce che 100 siano sufficienti per e5_base, ma altri retriever potrebbero comportarsi diversamente.
300 query rappresentano una dimensione campionaria moderata. I primi tre modelli (nemotron, gte_modernbert, jina) sono separati da meno di 2 punti percentuali. Con un set di query più ampio, queste classifiche potrebbero cambiare. Il divario tra la fascia alta e la fascia bassa (oltre 20 punti percentuali) è robusto.
Conclusione
I reranker funzionano. Il miglior modello di questo benchmark porta Hit@1 dal 62.67% al 83.00% (+20.33pp), il che significa che 20 query su 100 che in precedenza restituivano per prime il documento sbagliato ora restituiscono quello corretto. Si tratta di un guadagno significativo per un componente che aggiunge meno di 250ms di latenza.
La scoperta più utile è che la dimensione del modello non determina la qualità del reranker. gte-reranker-modernbert-base con 149M parametri eguaglia nemotron-rerank-1b con 1.2B su Hit@1. Il modello Qwen3 da 4B parametri arriva quarto. Se scegliete un reranker per un sistema di produzione, iniziate con i modelli più piccoli. Potreste non aver mai bisogno di quelli più grandi.
Per le applicazioni sensibili alla latenza, jina-reranker-v3 è l'opzione migliore sotto i 200ms. Per la massima accuratezza senza vincoli di latenza, nemotron-rerank-1b e gte-reranker-modernbert-base condividono il primo posto. Per i team con un budget limitato di GPU, gte-modernbert è il chiaro vincitore: stessa accuratezza del modello da 1.2B a una frazione dell'ingombro di memoria.
Un pattern è emerso in tutti gli esperimenti: il retriever stabilisce il tetto. Nessun reranker ha portato Hit@10 oltre l'88%, perché il restante 12% dei documenti corretti non è mai comparso tra i primi 100 candidati. Investire in un retriever migliore produrrà probabilmente guadagni maggiori rispetto a passare da uno all'altro dei primi tre reranker.
Ulteriori letture
Esplora altri benchmark di RAG, come:
- Modelli di embedding: OpenAI vs Gemini vs Cohere
- I migliori 16 modelli di embedding open source per RAG
- Il miglior database vettoriale per RAG: Qdrant vs Weaviate vs Pinecone
- Benchmark di RAG agentico: routing multi-database e generazione di query
- Modelli di embedding multimodali: Apple vs Meta vs OpenAI
- I migliori 10 modelli di embedding multilingue per 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 = {{Reranker benchmark: confronto tra i migliori 8 modelli}},
year = {2026},
month = feb,
howpublished = {\url{https://aimultiple.com/rerankers}},
note = {AIMultiple. Consultato il 26 Febbraio 2026}
}Risultati e timestamp di 17 punti dati. Scarica i dati utilizzati in questo articolo come file ZIP contenente 2 file CSV e un README.
Collegamenti di riferimento
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.