Benchmark sui reranker: i migliori 8 modelli a confronto

Abbiamo benchmarkato 8 modelli di reranker su ~145k recensioni Amazon in inglese per misurare quanto uno stadio di reranking migliori il retrieval 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, ciascuna delle quali fa riferimento a dettagli concreti della recensione di origine. Il miglior reranker ha portato Hit@1 da 62.67% a 83.00% (+20.33pp).

Risultati del benchmark sui reranker

Metriche spiegate:

ΔHit@1 / ΔHit@10 mostra il miglioramento rispetto alla baseline (senza 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 appare nei primi K risultati. La verità a terra è il product_id della recensione che ha generato la query. Se una recensione diversa dello stesso prodotto compare tra i primi K, conta come un hit. Hit@1 è il test più rigoroso: il primo risultato proviene dal prodotto giusto? Hit@10 è più permissivo: il prodotto giusto è da qualche parte tra i primi 10 risultati?

MRR@10 (Mean Reciprocal Rank) media il valore 1/rank del primo risultato corretto su tutte le query. Se il primo product_id corrispondente è in posizione 1, il punteggio è 1.0. In posizione 2, è 0.5. In posizione 10, è 0.1. Questo premia i modelli che posizionano 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 nell'insieme dei candidati e diverse finiscono tra i primi 10, nDCG assegna un credito a ciascuna in base alla sua posizione. In pratica, la maggior parte dei prodotti ha solo 1-2 recensioni tra i primi 100 candidati, quindi nDCG e MRR sono strettamente correlati.

Recall@10 misura la frazione di recensioni corrispondenti (stesso product_id) nei primi 10 rispetto a tutte le recensioni corrispondenti nell'intero insieme dei candidati (primi 100). Se un prodotto ha 3 recensioni tra i primi 100 e il reranker ne posiziona 2 tra i primi 10, Recall@10 è 2/3 per quella query. Poiché la maggior parte dei prodotti ha poche recensioni duplicate nell'insieme dei candidati, Recall@10 e Hit@10 sono quasi identici in questo benchmark.

Scomposizione della latenza

La latenza del reranking misura il tempo necessario a 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 necessario al cross-encoder per valutare tutti i 100 documenti candidati rispetto alla query. È qui che i modelli differiscono: un singolo passaggio in avanti è 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 valutazione. P95 mostra il caso peggiore che ci si dovrebbe aspettare 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 83.00% di Hit@1 sull'inglese. L'architettura ModernBERT è 8x più piccola e offre la stessa accuratezza di primo livello.

Ciò non significa che la dimensione del modello sia irrilevante. nemotron è leggermente superiore in MRR@10 (0.8514 vs 0.8483) e Hit@10 (88.33% vs 88.00%), il che significa che classifica i documenti pertinenti un po' meglio nell'intera top-10. Ma per la maggior parte delle applicazioni in cui ciò che conta è ottenere il primo risultato corretto, 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. Raggiunge 77.67% di Hit@1, piazzandosi quarto dietro a nemotron (1.2B), gte_modernbert (149M) e jina (560M). Paghi 4.5x la latenza di nemotron per 5.3 punti percentuali in meno di accuratezza.

I reranker qwen3 usano la modellazione del linguaggio causale con un approccio di logit sì/no. Il modello legge la coppia query-documento e produce la probabilità di “sì, questo è pertinente.” L'idea è concettualmente pulita, ma l'inferenza è costosa a causa del sovraccarico della decodifica autoregressiva. I modelli SequenceClassification (gte_modernbert, bge) e l'approccio con template di prompt di nemotron elaborano la coppia in un unico passaggio in avanti, il che è fondamentalmente più veloce.

Jina offre il miglior compromesso velocità-accuratezza

jina_reranker_v3 raggiunge 81.33% di Hit@1 a 188ms. nemotron raggiunge 83.00% a 243ms. Se hai bisogno di una latenza totale per query inferiore a 200ms, Jina è l'unico modello di fascia alta a offrirlo. Il divario di 1.67 punti percentuali potrebbe non giustificare gli ulteriori 55ms in un sistema di produzione che serve migliaia di richieste al secondo.

Un reranker peggiora i risultati

mxbai_rerank_xsmall (70M param) ottiene 64.67% di Hit@1. La baseline senza alcun reranker ottiene 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 giudicare in modo affidabile la pertinenza query-documento su testi più lunghi o più sfumati.

Un reranker non è automaticamente vantaggioso. Testalo sui tuoi dati reali prima di metterlo in produzione.

Il retriever fissa il tetto

Tutti i migliori reranker convergono intorno a 87-88% di Hit@10. Questo tetto deriva dal retriever. Se multilingual-e5-base non posiziona il documento corretto tra i primi 100 candidati, nessun reranker può recuperarlo. Il restante 12% delle 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 insieme di candidati più ampio o entrambi. Abbiamo testato i primi 250 candidati e non abbiamo riscontrato quasi alcun miglioramento rispetto ai primi 100, il che significa che e5_base esaurisce i suoi candidati utili ben prima della posizione 250.

Come funzionano i reranker

Un retriever denso (bi-encoder) codifica query e documenti indipendentemente in vettori. Il retrieval è una ricerca dei vicini più prossimi su questi vettori. Questo è veloce perché si codifica solo la query al momento della ricerca, ma il modello non vede mai la query e il documento insieme, quindi può perdere segnali di pertinenza sfumati.

Un reranker (cross-encoder) prende una coppia query-documento come unico input. Il modello presta attenzione congiuntamente a entrambi i testi, cogliendo relazioni che la codifica indipendente manca. Il costo è che devi eseguire il modello una volta per candidato, quindi puoi permetterti di valutare solo un piccolo insieme.

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 producono un singolo punteggio logit. Questo è l'approccio più semplice e comune.

Nemotron utilizza un formato di template di prompt: “question:{q} passage:{p}”. L'input sembra testo semplice piuttosto che una coppia strutturata, ma il modello produce comunque un singolo punteggio di pertinenza attraverso SequenceClassification. Il pre-addestramento LLM (basato su Llama) gli conferisce una forte comprensione del linguaggio.

I reranker Qwen3 usano la modellazione del linguaggio causale. Il modello legge la coppia e genera un giudizio sì/no. Il punteggio è log P(sì) / (P(sì) + P(no)). Ciò richiede l'intero meccanismo autoregressivo, il che spiega la latenza più elevata.

Jina v3 utilizza un'API personalizzata (model.rerank()) che gestisce internamente tokenizzazione e punteggio. L'architettura sottostante utilizza l'attenzione incrociata, ma l'interfaccia astrae i dettagli.

Metodologia del benchmark sui reranker

• GPU: NVIDIA H100 PCIe 80GB via Runpod
• Database vettoriale: Qdrant 1.12.0 (locale binario), 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).¹ ~145k recensioni dopo filtraggio per almeno 100 caratteri. Ogni recensione ha un product_id, un testo e una valutazione a stelle.
• Generazione delle query: Claude Sonnet 4.6 via 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: recupero dei primi 100 candidati con multilingual-e5-base, reranking con cross-encoder, restituzione dei primi 10. La baseline salta il reranking e restituisce direttamente i primi 10 del retriever.
• Verità a terra: solo corrispondenza esatta del product_id. Nessun ripiego sulla similarità coseno. Nessun credito 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 valutati zero-shot con pesi HuggingFace predefiniti.
• Latenza: reranking (valutazione del cross-encoder di 100 candidati). Misurata per query su GPU.

Modelli testati

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

Limitazioni

Questo benchmark utilizza un unico retriever (multilingual-e5-base). Un retriever diverso produrrebbe insiemi di candidati diversi e potrebbe modificare la classifica dei reranker. I risultati riflettono quanto bene ogni reranker funziona con questo specifico retriever, non la qualità del reranker in isolamento.

Abbiamo testato su recensioni di prodotti Amazon in inglese. Le prestazioni su altri domini (articoli scientifici, documenti legali, codice) o su altre lingue saranno diverse.

Il numero di candidati è fissato a 100. Alcuni reranker potrebbero classificare diversamente con 20 o 200 candidati. Abbiamo testato 250 candidati e abbiamo riscontrato un miglioramento trascurabile, il che suggerisce che 100 è sufficiente per e5_base, ma altri retriever potrebbero comportarsi diversamente.

300 query rappresentano una dimensione del campione moderata. I primi tre modelli (nemotron, gte_modernbert, jina) sono separati da meno di 2 punti percentuali. Con un insieme di query più ampio, queste classifiche potrebbero cambiare. Il divario tra il livello superiore e quello inferiore (20+ punti percentuali) è robusto.

Ulteriori letture

Esplora altri benchmark RAG, come:

• Modelli di embedding: OpenAI vs Gemini vs Cohere
• I migliori 16 modelli di embedding open source per RAG
• I migliori database vettoriali per RAG: Qdrant vs Weaviate vs Pinecone
• Benchmark RAG agentico: routing multi-database e generazione di query
• Modelli di embedding multimodali: Apple vs Meta vs OpenAI
• RAG ibrido: aumentare l'accuratezza del RAG
• 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  = {{Benchmark sui reranker: i migliori 8 modelli a confronto}},
  year   = {2026},
  month  = feb,
  howpublished    = {\url{https://aimultiple.com/rerankers}},
  note   = {AIMultiple. Consultato il 26 Febbraio 2026}
}

Collegamenti di riferimento

1.

Amazon Reviews Multi | Kaggle

Ekrem Sarı

Ricercatore AI

Segui

Ekrem è Ricercatore AI e analista di dati presso AIMultiple. Progetta ed esegue benchmark pratici per sistemi di AI 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