Reranking em RAG: o que é e quando usar

Reranking é a etapa opcional de um pipeline de RAG que pega os documentos já recuperados por busca vetorial (ou híbrida) e os reordena por relevância real em relação à pergunta, usando um modelo mais preciso e mais lento do que o retriever inicial. Ele entra depois da [busca híbrida](/artigo/busca-hibrida-em-rag-como-funciona) ou da busca vetorial e antes de os documentos virarem contexto para o LLM.

O que é reranking

Um reranker recebe uma consulta e uma lista de documentos candidatos e devolve uma pontuação de relevância para cada par consulta-documento, permitindo reordená-los do mais para o menos relevante. Segundo a documentação da Cohere, o modelo de rerank funciona exatamente assim: ele é usado tipicamente depois de uma primeira etapa de busca (lexical ou semântica) que já reduziu o universo de documentos a um número gerenciável, como os 100 primeiros resultados.

Isso o diferencia do retriever que gerou os [embeddings](/artigo/embeddings-o-que-sao-como-funcionam-ia) originais: o reranker não indexa nada previamente e não precisa escalar para milhões de documentos — ele só avalia, sob demanda, o pequeno lote que a etapa anterior já filtrou.

Por que a busca vetorial sozinha não basta

A similaridade de cosseno entre embeddings é uma aproximação: ela mede o quão perto dois vetores estão no espaço, não o quão bem um trecho responde a uma pergunta específica. Erros de [chunking](/artigo/chunking-rag-como-dividir-documentos-corretamente), embeddings genéricos ou perguntas ambíguas fazem com que documentos textualmente parecidos, mas irrelevantes, apareçam entre os primeiros colocados — e documentos relevantes, mas com vocabulário diferente do da pergunta, fiquem de fora do topo.

Bi-encoder vs cross-encoder: a diferença que importa

Os modelos de embeddings usados na busca vetorial são bi-encoders: segundo a documentação oficial do Sentence Transformers, um bi-encoder processa a pergunta e cada documento separadamente, gerando um vetor para cada um, que depois são comparados por similaridade de cosseno — por isso podem ser pré-calculados e indexados. Um cross-encoder, usado no reranking, faz o oposto: recebe a pergunta e o documento juntos, em uma única passada pela rede, e produz diretamente uma pontuação de relevância para aquele par.

• Bi-encoder: rápido, escalável, indexável — mas mede similaridade aproximada.
• Cross-encoder: mais preciso porque compara pergunta e documento em conjunto — mas não gera vetores reaproveitáveis e não escala para bases grandes.
• Por isso cross-encoders são usados para reranking de um lote pequeno, nunca para buscar em toda a base.

A documentação do Sentence Transformers resume o motivo de usar os dois em conjunto: cross-encoders atingem desempenho melhor que bi-encoders, mas não escalam bem para conjuntos de dados grandes — daí o pipeline em duas etapas.

Como funciona o pipeline de duas etapas

Tanto a documentação da Pinecone quanto a do Sentence Transformers descrevem o mesmo desenho de pipeline:

• 1. Um retriever rápido (busca vetorial, BM25 ou híbrida) recupera um lote maior de candidatos — normalmente entre 20 e 100 documentos.
• 2. O reranker (cross-encoder) avalia a pergunta junto com cada um desses candidatos e atribui uma pontuação de relevância a cada par.
• 3. Os documentos são reordenados por essa pontuação, e só os 3 a 10 primeiros seguem como contexto para o LLM.

A lógica, segundo a Pinecone, é que retrievers são rápidos e rerankers são lentos: por isso a busca ampla fica a cargo do retriever, e o reranker só refina um recorte pequeno — trocando um pouco de latência por relevância bem maior.

Principais rerankers disponíveis hoje

Existem opções hospedadas (API paga) e opções open source que rodam localmente:

• Cohere Rerank — API hospedada; segundo a documentação da Cohere, aceita até 1.000 documentos por requisição e trunca documentos longos conforme o parâmetro max_tokens_per_doc.
• Voyage AI Rerank — API hospedada; a Voyage AI é a provedora de embeddings recomendada pela Anthropic (que não oferece modelo de embeddings próprio), e também disponibiliza rerankers pelo método rerank() do cliente Python.
• Cross-encoders open source (ex.: família ms-marco-MiniLM) — rodam localmente via biblioteca Sentence Transformers, sem custo por chamada de API, ao preço de rodar a inferência na própria infraestrutura.
• Google Cloud Vertex AI Ranking e integrações via LangChain — o LangChain documenta um ContextualCompressionRetriever com suporte a reranker da Cohere, cross-encoder e Vertex AI, entre outros.

Exemplo prático com Sentence Transformers

Um cross-encoder open source pode ser usado localmente para reranking sem depender de uma API paga:

from sentence_transformers import CrossEncoder

# Modelo leve, adequado para reranking em produção
model = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-6-v2")

query = "como funciona a criptografia AES?"
documentos = [
    "AES é um algoritmo de criptografia simétrica que opera em blocos de 128 bits.",
    "RSA é um algoritmo de criptografia assimétrica baseado em fatoração de primos.",
    "O Wi-Fi 7 introduz canais de até 320 MHz de largura de banda.",
]

# O cross-encoder avalia cada par (query, documento) junto
pares = [(query, doc) for doc in documentos]
scores = model.predict(pares)

# Reordena os documentos pela pontuação de relevância, do maior para o menor
ranked = sorted(zip(documentos, scores), key=lambda x: x[1], reverse=True)
for doc, score in ranked:
    print(f"{score:.3f} - {doc}")

Na prática, esse lote de "documentos" viria dos resultados já recuperados pelo banco de dados vetorial ou pela busca híbrida — o reranker nunca substitui essa etapa, apenas refina o que ela já trouxe.

Custo e latência: quando vale a pena

Reranking sempre adiciona latência e, no caso de APIs hospedadas, custo por chamada — porque cada par pergunta-documento exige uma passada completa pelo modelo, diferente da comparação por cosseno entre vetores já indexados, que é praticamente instantânea. Por isso o padrão observado nas próprias documentações de Cohere e Pinecone é aplicar o reranker só sobre um lote pequeno (dezenas de candidatos), nunca sobre a base inteira.

O caso da Contextual Retrieval, da Anthropic

Em seu método de Contextual Retrieval, a Anthropic reporta que combinar embeddings contextuais com BM25 contextual reduziu em 49% a taxa de falhas de recuperação em relação a um RAG tradicional — e que adicionar reranking a essa combinação levou essa redução a 67%. A própria Anthropic descreve o reranking como uma técnica de filtragem comum para garantir que só os trechos mais relevantes cheguem ao modelo, o que também reduz custo e latência do lado da geração, já que o LLM processa menos texto.

Quando não vale a pena usar reranking

• Bases pequenas (poucas dezenas de documentos), em que o retriever já cobre praticamente todo o universo de respostas possíveis.
• Aplicações com orçamento de latência muito apertado, em que cada milissegundo importa mais do que um ganho incremental de precisão.
• Protótipos e provas de conceito, em que a complexidade extra de operar mais um modelo ainda não se justifica.
• Casos em que o problema real está na qualidade dos embeddings ou do chunking — reranking refina o que já foi recuperado, mas não resgata documentos que o retriever nem trouxe para a lista de candidatos.

Onde o reranking falha

Reranking tem um teto: se o documento certo nunca entrou na lista de candidatos recuperada na primeira etapa, o cross-encoder não tem como recuperá-lo — ele só reordena o que já chegou até ele. Cross-encoders hospedados também truncam documentos muito longos para caber na janela de contexto do modelo (a Cohere documenta isso via o parâmetro max_tokens_per_doc), o que pode cortar justamente o trecho relevante de um documento extenso. E, como qualquer modelo adicional no pipeline, ele é mais um ponto de falha e de custo operacional a monitorar.