Benchmark de Reranker: Top 8 Modelos Comparados
Fizemos benchmark de 8 modelos de reranker em ~145k avaliações da Amazon em inglês para medir o quanto uma etapa de re-ranqueamento melhora a recuperação densa. Recuperamos os top-100 candidatos com multilingual-e5-base, re-ranqueamos com cada modelo e avaliamos os top-10 resultados contra 300 consultas, cada uma referenciando detalhes concretos da avaliação original. O melhor reranker elevou o Hit@1 de 62.67% para 83.00% (+20.33pp).
Resultados do benchmark de reranker
Métricas explicadas:
ΔHit@1 / ΔHit@10 mostra a melhoria em relação à linha de base (sem reranker) em pontos percentuais (pp). Por exemplo, +20.33pp significa que o reranker melhorou o Hit@1 em 20.33 pontos percentuais comparado com a linha de base de 62.67%.
Hit@K mede se alguma avaliação com o product_id correto aparece nos resultados top-K. A referência é o product_id da avaliação que gerou a consulta. Se uma avaliação diferente do mesmo produto aparecer nos top-K, isso conta como acerto. Hit@1 é o teste mais rigoroso: o primeiro resultado é do produto certo? Hit@10 é mais tolerante: o produto certo está em algum lugar entre os primeiros 10 resultados?
MRR@10 (Mean Reciprocal Rank) calcula a média de 1/posição do primeiro resultado correto em todas as consultas. Se o primeiro product_id correspondente estiver na posição 1, a pontuação é 1.0. Na posição 2, é 0.5. Na posição 10, é 0.1. Isso recompensa modelos que posicionam o produto correto o mais alto possível.
nDCG@10 (Normalized Discounted Cumulative Gain) avalia as posições de todas as avaliações correspondentes nos top-10, não apenas a primeira. Se o mesmo produto tiver várias avaliações no conjunto de candidatos e várias ficarem entre os top-10, o nDCG pontua cada uma com base na posição. Na prática, a maioria dos produtos tem apenas 1-2 avaliações nos top-100 candidatos, então nDCG e MRR acompanham de perto.
Recall@10 mede a fração de avaliações correspondentes (mesmo product_id) nos top-10 em relação a todas as avaliações correspondentes no conjunto completo de candidatos (top-100). Se um produto tiver 3 avaliações nos top-100 e o reranker colocar 2 delas nos top-10, o Recall@10 é de 2/3 para essa consulta. Como a maioria dos produtos tem poucas avaliações duplicadas no conjunto de candidatos, o Recall@10 e o Hit@10 são quase idênticos neste benchmark.
Detalhamento da latência
A latência de re-ranqueamento mede o tempo que cada cross-encoder leva para pontuar 100 documentos candidatos em relação à consulta. O tempo da busca vetorial (~20ms) é excluído, pois permanece constante em todas as execuções e é independente do reranker.
Métricas de latência explicadas:
Rerank é o tempo para o cross-encoder pontuar todos os 100 documentos candidatos em relação à consulta. É aqui que os modelos se diferenciam: uma única passada forward é rápida, enquanto a decodificação autoregressiva é lenta.
P95 é o 95 percentil da latência total. Algumas consultas têm textos de avaliação mais longos, o que aumenta o tempo de tokenização e pontuação. O P95 mostra o pior caso que se deve esperar para 95% das consultas.
Principais conclusões
Um modelo de 149M equipara-se a um modelo de 1.2B
gte-reranker-modernbert-base possui 149M parâmetros, nemotron-rerank-1b possui 1.2B. Ambos atingem 83.00% de Hit@1 em inglês. A arquitetura ModernBERT é 8x menor e oferece a mesma precisão de alto nível.
Isso não significa que o tamanho do modelo seja irrelevante. O nemotron fica um pouco à frente em MRR@10 (0.8514 vs 0.8483) e Hit@10 (88.33% vs 88.00%), o que significa que ele classifica os documentos relevantes ligeiramente melhor ao longo dos top-10. Mas para a maioria das aplicações em que acertar o primeiro resultado é o que importa, o modelo de 149M é suficiente.
O maior modelo não é o melhor
qwen3_reranker_4b possui 4B parâmetros e leva mais de um segundo por consulta. Ele atinge 77.67% de Hit@1, ficando em quarto lugar, atrás do nemotron (1.2B), gte_modernbert (149M) e jina (560M). Você paga 4.5x a latência do nemotron por 5.3 pontos percentuais a menos de precisão.
A arquitetura do qwen3 usa modelagem de linguagem causal com uma abordagem de logit sim/não. O modelo lê o par consulta-documento e gera a probabilidade de “sim, isso é relevante”. Conceitualmente, isso é limpo, mas a inferência é cara devido à sobrecarga da decodificação autoregressiva. Os modelos SequenceClassification (gte_modernbert, bge) e a abordagem de template de prompt do nemotron processam o par em uma única passada forward, o que é fundamentalmente mais rápido.
Jina oferece o melhor equilíbrio entre velocidade e precisão
jina_reranker_v3 atinge 81.33% de Hit@1 a 188ms. O nemotron atinge 83.00% a 243ms. Se você precisa de latência total abaixo de 200ms por consulta, o Jina é o único modelo no escalão superior que oferece isso. A diferença de 1.67 pontos percentuais pode não justificar os 55ms extras em um sistema de produção que atende milhares de requisições por segundo.
Um reranker piora os resultados
mxbai_rerank_xsmall (70M parâmetros) obtém 64.67% de Hit@1. A linha de base sem nenhum reranker obtém 62.67%. A melhoria é de apenas 2 pontos percentuais, o que está dentro do ruído para 300 consultas. Com 70M parâmetros, o modelo não tem capacidade para julgar com confiabilidade a relevância consulta-documento em textos mais longos ou com mais nuances.
Um reranker não é automaticamente benéfico. Teste-o com seus dados reais antes de implantar.
O recuperador define o teto
Todos os principais rerankers convergem em torno de 87-88% de Hit@10. Esse teto vem do recuperador. Se o multilingual-e5-base não coloca o documento correto entre os top-100 candidatos, nenhum reranker pode recuperá-lo. Os 12% restantes de consultas em que todos os rerankers falham representam casos em que o recuperador denso simplesmente não encontrou o documento relevante.
Melhorar além desse teto requer um recuperador melhor, um conjunto maior de candidatos, ou ambos. Testamos top-250 candidatos e encontramos quase nenhuma melhoria em relação aos top-100, o que significa que o e5_base esgota seus candidatos úteis bem antes da posição 250.
Como funcionam os rerankers
Um recuperador denso (bi-encoder) codifica consultas e documentos independentemente em vetores. A recuperação é uma busca de vizinho mais próximo sobre esses vetores. Isso é rápido porque você codifica apenas a consulta no momento da busca, mas o modelo nunca vê a consulta e o documento juntos, então pode perder sinais sutis de relevância.
Um reranker (cross-encoder) recebe um par consulta-documento como uma única entrada. O modelo atende a ambos os textos conjuntamente, capturando relações que a codificação independente perde. O custo é que você deve executar o modelo uma vez por candidato, portanto, você só pode se dar ao luxo de pontuar um pequeno conjunto.
Arquiteturas neste benchmark
Testamos quatro arquiteturas diferentes de cross-encoder:
Modelos SequenceClassification (bge_base, bge_v2_m3, mxbai_xsmall, gte_modernbert) recebem um par [query, document] como entrada e geram uma única pontuação logit. Esta é a abordagem mais simples e comum.
O Nemotron usa um formato de template de prompt: “question:{q} passage:{p}”. A entrada parece texto simples em vez de um par estruturado, mas o modelo ainda gera uma única pontuação de relevância por meio de SequenceClassification. O pré-treinamento LLM (baseado no Llama) confere a ele um forte entendimento de linguagem.
Os rerankers Qwen3 usam modelagem de linguagem causal. O modelo lê o par e gera um julgamento sim/não. A pontuação é log P(sim) / (P(sim) + P(não)). Isso exige todo o maquinário autoregressivo, o que explica a latência mais alta.
O Jina v3 usa uma API personalizada (model.rerank()) que trata da tokenização e da pontuação internamente. A arquitetura subjacente usa atenção cruzada, mas a interface abstrai os detalhes.
Metodologia do benchmark de reranker
- GPU: NVIDIA H100 PCIe 80GB via Runpod
- Banco de dados vetorial: Qdrant 1.12.0 (binário local), distância cosseno
- Recuperador: multilingual-e5-base (768-dim). Prefixo da consulta:
"query: ", prefixo do documento:"passage: " - Software: transformers 5.2.0, PyTorch 2.8.0, CUDA 12.8.1
- Dataset: Subconjunto em inglês do Amazon Reviews Multi (Kaggle).1 ~145k avaliações após filtragem para mínimo de 100 caracteres. Cada avaliação possui um product_id, texto da avaliação e classificação por estrelas.
- Geração de consultas: Claude Sonnet 4.6 via OpenRouter. 300 consultas em inglês (5 tipos: factual, opinião, uso, resolução de problemas, comparação de recursos). Cada consulta deve fazer referência a detalhes específicos de sua avaliação de origem; perguntas genéricas (pontuação de especificidade < 4/5) são filtradas.
- Formato do documento:
"Review Title: {title}\nReview: {body}" - Pipeline: Recuperar os top-100 candidatos com multilingual-e5-base, re-ranquear com cross-encoder, retornar os top-10. A linha de base pula o re-ranqueamento e retorna os top-10 do recuperador diretamente.
- Referência: correspondência exata do product_id apenas. Sem fallback por similaridade cosseno. Sem crédito parcial para produtos semanticamente semelhantes.
- Variável controlada: Apenas o modelo reranker muda entre os experimentos. Recuperador, contagem de candidatos, conjunto de consultas e critérios de avaliação são idênticos em todas as execuções.
- Sem fine-tuning: Todos os modelos avaliados em zero-shot com pesos padrão do HuggingFace.
- Latência: Re-ranqueamento (pontuação do cross-encoder de 100 candidatos). Medida por consulta na GPU.
Modelos testados
Adicionar como fonte preferencialLimitações
Este benchmark utiliza um único recuperador (multilingual-e5-base). Um recuperador diferente produziria conjuntos de candidatos diferentes e poderia alterar as classificações dos rerankers. Os resultados refletem o quão bem cada reranker funciona com este recuperador específico, não a qualidade do reranker isoladamente.
Testamos em avaliações de produtos da Amazon em inglês. O desempenho em outros domínios (artigos científicos, documentos jurídicos, código) ou outros idiomas será diferente.
O número de candidatos é fixado em 100. Alguns rerankers podem classificar de forma diferente com 20 ou 200 candidatos. Testamos 250 candidatos e encontramos melhoria insignificante, sugerindo que 100 é suficiente para o e5_base, mas outros recuperadores podem se comportar de maneira diferente.
300 consultas é um tamanho de amostra moderado. Os três principais modelos (nemotron, gte_modernbert, jina) estão separados por menos de 2 pontos percentuais. Com um conjunto de consultas maior, essas classificações podem mudar. A diferença entre o escalão superior e o escalão inferior (20+ pontos percentuais) é robusta.
Conclusão
Rerankers funcionam. O melhor modelo neste benchmark eleva o Hit@1 de 62.67% para 83.00% (+20.33pp), o que significa que 20 de cada 100 consultas que antes retornavam o documento errado primeiro agora retornam o correto. Esse é um ganho significativo para um componente que adiciona menos de 250ms de latência.
A conclusão mais útil é que o tamanho do modelo não determina a qualidade do reranker. O gte-reranker-modernbert-base com 149M parâmetros se iguala ao nemotron-rerank-1b com 1.2B no Hit@1. O modelo Qwen3 de 4B parâmetros fica em quarto lugar. Se você está escolhendo um reranker para um sistema de produção, comece com os modelos menores. Você pode nunca precisar dos maiores.
Para aplicações sensíveis à latência, o jina-reranker-v3 é a opção mais forte abaixo de 200ms. Para máxima precisão sem restrição de latência, o nemotron-rerank-1b e o gte-reranker-modernbert-base dividem o primeiro lugar. Para equipes com orçamento de GPU, o gte-modernbert é o vencedor claro: mesma precisão do modelo de 1.2B por uma fração da pegada de memória.
Um padrão se manteve em todos os experimentos: o recuperador define o teto. Nenhum reranker elevou o Hit@10 acima de 88%, porque os 12% restantes dos documentos corretos nunca apareceram entre os top-100 candidatos. Investir em um recuperador melhor provavelmente trará ganhos maiores do que alternar entre os três principais rerankers.
Leitura adicional
Explore outros benchmarks de RAG, como:
- Modelos de Embedding: OpenAI vs Gemini vs Cohere
- Top 16 Modelos de Embedding Open Source para RAG
- Top Banco de Dados Vetorial para RAG: Qdrant vs Weaviate vs Pinecone
- Benchmark de RAG agêntico: roteamento multibanco de dados e geração de consultas
- Modelos de Embedding Multimodal: Apple vs Meta vs OpenAI
- RAG Híbrido: Aumentando a Precisão do RAG
- Top 10 Modelos de Embedding Multilíngue para RAG
Cite este benchmark
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{Benchmark de Reranker: Top 8 Modelos Comparados}},
year = {2026},
month = feb,
howpublished = {\url{https://aimultiple.com/rerankers}},
note = {AIMultiple. Acessado em 26 Fevereiro 2026}
}Resultados e carimbos de data/hora de 9 pontos de dados. Baixe os dados utilizados neste artigo como um arquivo ZIP contendo um arquivo CSV e um README.
Links de referência
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.