Benchmark di Reranker: confronto tra gli 8 migliori modelli

aggiornato il Feb 26, 2026

Abbiamo testato 8 modelli di reranking su circa 145.000 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 faceva riferimento a dettagli concreti della recensione originale. Il miglior modello di reranking ha aumentato Hit@1 dal 62,67% all'83,00% (+20,33 pp).

Risultati del benchmark di Reranker

Loading Chart

Spiegazione delle metriche :

ΔHit@1 / ΔHit@10 mostra il miglioramento rispetto al valore di riferimento (senza riordinamento) in punti percentuali (pp). Ad esempio, +20,33 pp significa che il riordinamento ha migliorato Hit@1 di 20,33 punti percentuali rispetto al valore di riferimento del 62,67%.

Hit@K misura se una qualsiasi recensione con il product_id corretto compare tra i primi K risultati. Il valore di riferimento è il product_id della recensione che ha generato la query. Se una recensione diversa dello stesso prodotto compare tra i primi K risultati, viene considerata un hit. Hit@1 è il test più rigoroso: il primo risultato corrisponde al prodotto corretto? Hit@10 è meno restrittivo: il prodotto corretto è presente 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 si trova al rank 1, il punteggio è 1.0. Al rank 2, è 0.5. Al rank 10, è 0.1. Questo premia i modelli che posizionano il prodotto corretto il più in alto possibile.

nDCG@10 (Normalized Discounted Cumulative Gain) valuta la posizione di tutte le recensioni corrispondenti nella top 10, non solo della prima. Se lo stesso prodotto ha più recensioni nel set di candidati e diverse si posizionano nella top 10, nDCG attribuisce un punteggio 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 molto simili.

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

Analisi della latenza

La latenza di riordinamento misura il tempo impiegato da ciascun cross-encoder per assegnare un punteggio a 100 documenti candidati rispetto alla query. Il tempo di ricerca vettoriale (~20 ms) è escluso poiché rimane costante in tutte le esecuzioni ed è indipendente dal reranker.

Spiegazione delle metriche di latenza :

La fase di rerank è il momento in cui il cross-encoder valuta 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 rappresenta il 95° percentile della latenza totale. Alcune query presentano testi di recensione più lunghi, il che aumenta i tempi di tokenizzazione e di assegnazione del punteggio. P95 indica il caso peggiore che ci si può aspettare per il 95% delle query.

Principali risultati

Un modello 149M corrisponde a un modello 1.2B

gte-reranker-modernbert-base ha 149 milioni di parametri, nemotron-rerank-1b ne ha 1,2 miliardi. Entrambi raggiungono l'83,00% di Hit@1 sulla lingua inglese. L'architettura ModernBERT è 8 volte più piccola e offre la stessa accuratezza di alto livello.

Ciò non significa che la dimensione del modello sia irrilevante. Nemotron è leggermente superiore in termini di 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 ciò che conta è ottenere il primo risultato corretto, il modello da 149 milioni di parole è sufficiente.

Il modello più grande non è il migliore

qwen3_reranker_4b ha 4 miliardi di parametri e impiega più di un secondo per query. Raggiunge il 77,67% di Hit@1, posizionandosi al quarto posto dietro nemotron (1,2 miliardi), gte_modernbert (149 milioni) e jina (560 milioni). Si paga una latenza 4,5 volte superiore a quella di nemotron per un'accuratezza 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 è rilevante". Concettualmente è pulito, ma l'inferenza è costosa a causa del sovraccarico di decodifica autoregressiva. I modelli SequenceClassification (gte_modernbert, bge) e l'approccio prompt-template di nemotron elaborano la coppia in un singolo passaggio in avanti, che è fondamentalmente più veloce.

Jina offre il miglior compromesso tra velocità e precisione

jina_reranker_v3 raggiunge l'81,33% di Hit@1 a 188 ms. nemotron raggiunge l'83,00% a 243 ms. Se hai bisogno di una latenza totale inferiore a 200 ms per query, Jina è l'unico modello di fascia alta che la garantisce. La differenza di 1,67 punti percentuali potrebbe non giustificare i 55 ms aggiuntivi in un sistema di produzione che gestisce migliaia di richieste al secondo.

Un solo strumento di riordinamento peggiora i risultati

mxbai_rerank_xsmall (70 milioni di parametri) ottiene un punteggio di Hit@1 del 64,67%. Il modello di base senza alcun algoritmo di reranking ottiene un punteggio del 62,67%. Il miglioramento è di soli 2 punti percentuali, il che rientra nel margine di errore per 300 query. Con 70 milioni di parametri, il modello non è in grado di valutare in modo affidabile la pertinenza query-documento su testi più lunghi o più complessi.

Un algoritmo di riordinamento non è automaticamente vantaggioso. Testalo sui tuoi dati reali prima di implementarlo.

Il retriever stabilisce il soffitto

Tutti i migliori algoritmi di reranking convergono intorno all'87-88% di Hit@10. Questo limite massimo è determinato dall'algoritmo di recupero. Se multilingual-e5-base non inserisce il documento corretto tra i primi 100 candidati, nessun algoritmo di reranking è in grado di recuperarlo. Il restante 12% delle query in cui ogni algoritmo di reranking fallisce rappresenta i casi in cui l'algoritmo di recupero denso ha semplicemente mancato del tutto il documento pertinente.

Per superare questo limite è necessario un sistema di recupero dati migliore, un pool 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 di raggiungere la posizione 250.

Come funzionano i sistemi di riordinamento

Un recuperatore denso (bi-encoder) codifica query e documenti in modo indipendente in vettori. Il recupero avviene tramite una ricerca del vicino più prossimo su questi vettori. Questo metodo è veloce perché la query viene codificata solo al momento della ricerca, ma il modello non visualizza mai query e documento insieme, quindi può perdere segnali di rilevanza più sottili.

Un reranker (o cross-encoder) prende in input una coppia query-documento. Il modello elabora entrambi i testi congiuntamente, individuando le relazioni che una codifica indipendente non riesce a rilevare. Lo svantaggio è che è necessario eseguire il modello una volta per ogni candidato, quindi ci si può permettere di valutare solo un numero limitato di candidati.

Architetture in questo benchmark

Abbiamo testato quattro diverse architetture cross-encoder:

I modelli di classificazione delle sequenze (bge_base, bge_v2_m3, mxbai_xsmall, gte_modernbert) prendono in input una coppia [query, documento] e restituiscono un singolo punteggio logit. Questo è l'approccio più semplice e comune.

Nemotron utilizza un formato di prompt template: “domanda:{q} passaggio:{p}”. L'input appare come testo semplice piuttosto che come una coppia strutturata, ma il modello restituisce comunque un singolo punteggio di rilevanza tramite SequenceClassification. Il pre-addestramento LLM (basato su Llama) gli conferisce una solida comprensione del linguaggio.

I reranker Qwen3 utilizzano la modellazione causale del linguaggio. 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 la tokenizzazione e l'assegnazione dei punteggi. L'architettura sottostante si basa sull'attenzione incrociata, ma l'interfaccia ne astrae i dettagli.

Metodologia di benchmark Reranker

GPU: NVIDIA H100 PCIe 80GB tramite Runpod
Database vettoriale: Qdrant 1.12.0 (binario locale), distanza coseno
Retriever: multilingual-e5-base (768-dim). Query prefix: "query: " , document prefix: "passage: "
Software: transformers 5.2.0, PyTorch 2.8.0, CUDA 12.8.1
Set di dati: sottoinsieme in lingua inglese di Amazon Reviews Multi (Kaggle). ¹ 145.000 recensioni dopo aver filtrato per un minimo di 100 caratteri. Ogni recensione ha un ID prodotto, il testo della recensione e una valutazione in stelle.
Generazione di query: Claude Sonnet 4.6 tramite OpenRouter. 300 query in inglese (5 tipi: fattuali, di opinione, di utilizzo, di risoluzione dei problemi, di confronto delle caratteristiche). Ogni query deve fare riferimento a dettagli specifici dalla sua revisione della fonte; le domande generiche (punteggio di specificità < 4/5) vengono filtrate.
Formato del documento: "Review Title: {title}\nReview: {body}"
Pipeline: Recupera i primi 100 candidati con multilingual-e5-base, riordina con cross-encoder, restituisci i primi 10. La versione di base salta il riordino e restituisce direttamente i primi 10 risultati del retriever.
Verità assoluta: solo corrispondenza esatta dell'ID prodotto. Nessun fallback basato sulla similarità del coseno. Nessun credito parziale per prodotti semanticamente simili.
Variabile controllata: solo il modello di reranking cambia tra gli esperimenti. Il sistema di recupero, il numero di candidati, il set di query e i criteri di valutazione sono identici in tutte le esecuzioni.
Nessuna messa a punto: tutti i modelli sono stati valutati zero-shot con i pesi predefiniti di HuggingFace.
Latenza: Riordinamento (punteggio cross-encoder di 100 candidati). Misurata per query su GPU.

Modelli testati

Limitazioni

Questo benchmark utilizza un singolo retriever (multilingual-e5-base). Un retriever diverso produrrebbe set di candidati diversi e potrebbe modificare le classifiche del reranker. I risultati riflettono l'efficacia di ciascun reranker con questo specifico retriever, non la qualità del reranker in sé.

Abbiamo effettuato i test su recensioni di prodotti in inglese provenienti da Amazon. Le prestazioni su altri domini (articoli scientifici, documenti legali, codice) o in altre lingue potrebbero variare.

Il numero di candidati è fisso a 100. Alcuni algoritmi di riordinamento potrebbero ottenere risultati diversi 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 algoritmi di recupero 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 set di query più ampio, queste classifiche potrebbero cambiare. Il divario tra la fascia più alta e quella più bassa (oltre 20 punti percentuali) è consistente.

Conclusione

Gli algoritmi di reranking funzionano. Il modello migliore in questo benchmark porta Hit@1 dal 62,67% all'83,00% (+20,33 pp), il che significa che 20 query su 100 che in precedenza restituivano prima il documento sbagliato ora restituiscono quello corretto. Si tratta di un miglioramento significativo per un componente che aggiunge meno di 250 ms di latenza.

La scoperta più utile è che la dimensione del modello non determina la qualità del reranker. gte-reranker-modernbert-base con 149 milioni di parametri eguaglia nemotron-rerank-1b con 1,2 miliardi di parametri su Hit@1. Il modello Qwen3 con 4 miliardi di parametri si classifica al quarto posto. Se stai scegliendo un reranker per un sistema di produzione, inizia con i modelli più piccoli. Potresti non aver mai bisogno di quelli più grandi.

Per le applicazioni sensibili alla latenza, jina-reranker-v3 è l'opzione migliore con tempi di risposta inferiori a 200 ms. Per la massima precisione senza vincoli di latenza, nemotron-rerank-1b e gte-reranker-modernbert-base condividono il primo posto. Per i team con un budget limitato alle GPU, gte-modernbert è il vincitore indiscusso: stessa precisione del modello 1.2B con un consumo di memoria nettamente inferiore.

Un modello ricorrente in tutti gli esperimenti è stato il seguente: il sistema di recupero dei risultati stabilisce il limite massimo. Nessun sistema di riordinamento ha spinto Hit@10 oltre l'88%, perché il restante 12% dei documenti corretti non è mai comparso tra i primi 100 candidati. Investire in un sistema di recupero dei risultati migliore probabilmente porterà a risultati migliori rispetto al passaggio tra i primi tre sistemi di riordinamento.

Per approfondire

Esplora altri parametri di riferimento RAG, come ad esempio:

Collegamenti di riferimento

✏️ Amazon Reviews Multi | Kaggle

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