Reranking em RAG: quando vale a camada extra

Reranking em RAG é a etapa que reordena os documentos recuperados antes de enviá-los ao LLM, usando um modelo mais preciso (geralmente um cross-encoder) para julgar a relevância real de cada trecho em relação à pergunta. Ele existe porque a busca vetorial inicial prioriza velocidade sobre precisão e costuma trazer lixo relevante junto com o que interessa de verdade. Vale a pena adicionar quando a taxa de acerto do top-k da sua busca vetorial está abaixo do que o produto exige e você tem orçamento de latência para pagar por essa segunda passada.

Eu já vi times gastarem semanas ajustando chunking e prompt de um pipeline de RAG enquanto o problema real estava um passo atrás: a busca vetorial trazia os documentos certos, só que não nas primeiras posições. O LLM lê os top 5 ou top 8 resultados, e se o documento que realmente responde a pergunta está na posição 12, ele nunca chega lá. Reranking resolve exatamente esse tipo de falha, mas não é grátis, nem sempre necessário, e tem um custo de latência que precisa entrar na conta antes de você decidir usar.

O que é reranking em RAG e por que ele existe

Busca vetorial funciona comparando o embedding da pergunta com os embeddings dos documentos indexados, usando distância entre vetores para estimar relevância. É rápido porque cada documento foi convertido em vetor uma vez, no momento da indexação, e a comparação na hora da busca é uma operação matemática simples.

O problema é que essa velocidade tem um preço: o embedding da pergunta e o embedding do documento nunca "se olham" diretamente. Eles são calculados de forma independente e depois comparados. Isso funciona bem para separar o relevante do irrelevante, mas erra feio na hora de ordenar o que é mais relevante dentro do que já é relevante.

O reranker resolve isso processando a pergunta e cada documento candidato juntos, num único modelo, o que dá uma estimativa de relevância muito mais fina. É mais lento, então você não usa em toda a base. Usa só nos poucos candidatos que a busca vetorial já filtrou.

Quando vale a pena adicionar essa camada

Nem todo pipeline de RAG precisa de reranking. Os sinais que eu costumo procurar antes de recomendar essa camada são:

• A resposta certa está na sua base, mas o LLM ignora ou contradiz ela porque o documento certo não estava entre os primeiros resultados retornados.
• Sua base tem muitos documentos parecidos entre si (variações de um mesmo produto, versões de contrato, FAQs redundantes), o que confunde a busca vetorial na hora de diferenciar nuance.
• O custo de uma resposta errada é alto o suficiente para justificar latência extra, como em suporte técnico crítico, jurídico ou saúde.
• Você já tentou aumentar o k da busca (trazer mais documentos) e isso só piorou a coisa, porque jogou mais ruído para dentro do contexto do LLM.

Se nenhum desses sinais aparece nos seus testes, reranking é complexidade que você está adicionando sem retorno mensurável. E complexidade sem retorno mensurável é exatamente o tipo de coisa que eu evito recomendar.

Como o reranking funciona na prática

Recuperação inicial ampla

A busca vetorial traz um número maior de candidatos do que você vai efetivamente usar no prompt final, algo como 20 a 50 documentos em vez dos 5 a 8 que normalmente vão para o LLM. A ideia é dar margem para o reranker trabalhar.

Reordenação pelo modelo de reranking

Cada um desses candidatos é avaliado junto com a pergunta original por um modelo especializado em relevância, que devolve uma pontuação de quão bem aquele trecho responde à pergunta. Os candidatos são reordenados por essa pontuação, não pela distância vetorial original.

Corte final para o contexto do LLM

Só os primeiros resultados dessa nova ordenação (o top 5 ou top 8, dependendo do seu orçamento de tokens) seguem para o prompt do modelo de linguagem. O resto é descartado.

Bi-encoder vs cross-encoder: a escolha por trás do reranker

A busca vetorial padrão usa o que se chama de bi-encoder: pergunta e documento passam separadamente pelo modelo e viram vetores independentes, comparados depois por similaridade. É rápido, escala bem, e é isso que permite indexar milhões de documentos.

O reranker geralmente usa um cross-encoder: pergunta e documento entram juntos no mesmo modelo, que analisa a interação entre os dois antes de dar uma pontuação. É mais preciso porque o modelo enxerga o contexto completo, mas não escala para milhões de comparações, porque cada uma exige uma passada inteira pelo modelo.

Na prática, é por isso que ninguém usa cross-encoder para a busca inicial numa base grande. O bi-encoder filtra rápido, o cross-encoder refina devagar. Um não substitui o outro, eles resolvem etapas diferentes do mesmo problema.

API pronta ou reranker próprio: o trade-off de custo e controle

Você tem duas rotas principais para adicionar reranking. A primeira é usar uma API de reranking pronta, como a documentação oficial do Cohere Rerank descreve. É rápido de integrar e não exige infraestrutura própria, mas cada chamada tem custo por token processado e seus dados passam por um serviço externo.

A segunda é hospedar um modelo de cross-encoder você mesmo, geralmente open source, rodando na sua própria infraestrutura. Isso reduz o custo por request em escala e mantém os dados dentro do seu ambiente, o que pesa bastante se você trabalha com informação sensível, tema que eu já detalhei quando falei sobre o que avaliar antes de mandar dados para uma API externa.

A escolha entre as duas não é sobre qual é "melhor" de forma abstrata. É sobre volume de requisições, sensibilidade dos dados e se você já tem capacidade de infraestrutura ociosa para hospedar mais um modelo.

O que acontece quando você pula essa etapa

Sem reranking, o LLM recebe o que a busca vetorial trouxe, na ordem que a busca vetorial trouxe. Se o documento certo está na posição 3, funciona bem. Se está na posição 15, o modelo nunca vê aquele trecho e improvisa uma resposta com o que tem em mãos, muitas vezes misturando informação de documentos parecidos mas errados.

O efeito colateral mais chato é que isso parece um problema de alucinação do LLM, quando na verdade é um problema de recuperação. Times gastam tempo ajustando prompt e temperatura quando o defeito real está upstream, na etapa de busca. Já vi esse padrão se repetir bastante, e no final das contas o diagnóstico certo economiza semanas de ajuste no lugar errado.

Como medir se o reranking está funcionando

Reranking sem métrica de validação é só mais uma camada de complexidade no pipeline. Antes de colocar em produção, eu recomendo acompanhar pelo menos três coisas:

• Precisão do top-k antes e depois: pegue um conjunto de perguntas com resposta conhecida e meça quantas vezes o documento correto aparece entre os primeiros resultados, com e sem reranking.
• Qualidade da resposta final: use avaliação humana em amostra ou LLM como juiz para avaliar as respostas em produção, comparando a taxa de respostas corretas antes e depois de adicionar a camada.
• Latência e custo adicional: cada chamada de reranking soma tempo de resposta e, se for via API paga, custo por request. Isso precisa aparecer no seu painel de monitoramento, não só a qualidade.

Se a precisão do top-k não melhora de forma mensurável, o reranking não está pagando o preço que está cobrando em latência. Aí talvez o problema esteja em outro lugar, como o modelo de embedding usado na indexação ou a estratégia de divisão dos documentos.

Perguntas frequentes

Reranking deixa o RAG mais lento?

Sim, adiciona uma etapa extra de processamento entre a busca vetorial e o envio ao LLM, o que soma alguns milissegundos a algumas centenas de milissegundos dependendo do modelo e do número de candidatos avaliados. Para aplicações com restrição forte de latência, isso precisa ser testado antes de ir para produção.

Qual o custo de usar reranking?

Depende da rota escolhida. APIs pagas cobram por documento avaliado em cada busca, enquanto um modelo próprio hospedado tem custo fixo de infraestrutura mas escala melhor em volume alto. O cálculo certo é custo por request multiplicado pelo volume esperado de buscas.

Dá para fazer reranking sem pagar por API externa?

Sim, existem modelos de cross-encoder open source que rodam na sua própria infraestrutura, sem depender de um serviço pago por chamada. A troca é que você assume a responsabilidade de hospedar, atualizar e monitorar esse modelo.

Reranking substitui um bom chunking dos documentos?

Não. Se os documentos estão mal divididos, misturando assuntos diferentes num mesmo trecho, o reranking não conserta isso, só reordena o que já foi recuperado. Chunking ruim continua sendo chunking ruim depois do reranking.

Reranking em RAG é uma ferramenta de precisão, não um upgrade automático que todo pipeline precisa. Funciona assim: você mede a taxa de acerto do top-k que já tem, decide se o ganho justifica a latência extra, e só então adiciona a camada. Sem essa medição antes e depois, você não tem como saber se está resolvendo o problema ou só adicionando mais uma peça no sistema.

Se você já tem um pipeline de RAG rodando e desconfia que o problema está na ordenação dos resultados, o próximo passo é rodar um teste comparativo antes de decidir por reranking:

• Monte um conjunto de 30 a 50 perguntas com resposta conhecida na sua base.
• Meça a posição do documento correto no top-k atual, sem reranking.
• Se a maioria das respostas certas está fora do top 5, teste reranking nesse mesmo conjunto antes de colocar em produção.