Reranking em RAG: como melhorar a relevância das respostas

O que é reranking em RAG?

Reranking é a reordenação de resultados recuperados com base em uma avaliação adicional de relevância.

Em um sistema de RAG, a busca inicial pode retornar 20, 50 ou mais chunks candidatos.

O reranker recebe a pergunta e esses trechos, atribui uma nova pontuação a cada par e coloca os resultados mais promissores no topo.

A documentação de reranking da Cohere descreve justamente esse uso como uma camada aplicada depois de um mecanismo de busca existente. A lógica também aparece em serviços de busca corporativa: o semantic ranker do Azure AI Search funciona como uma segunda etapa sobre um conjunto inicial de resultados.

O reranker não escreve a resposta e não substitui o mecanismo de recuperação. Ele melhora a ordem dos candidatos para que o gerador receba evidências mais úteis.

Essa distinção evita um erro frequente: esperar que a segunda etapa encontre informações que nunca foram recuperadas na primeira.

Por que a primeira recuperação nem sempre basta

A recuperação inicial costuma priorizar velocidade. Em uma busca vetorial, a pergunta e os documentos são representados por embeddings, e o sistema procura vetores próximos.

É uma forma eficiente de vasculhar uma coleção grande, mas comprime o significado de cada texto em uma representação fixa.

Dois trechos podem parecer semanticamente próximos e ainda cumprir papéis diferentes. Imagine a pergunta “como cancelar uma assinatura anual sem multa?”.

A busca pode priorizar uma página geral sobre cancelamento, enquanto uma cláusula específica sobre renovação antecipada aparece em posição inferior. Para responder com segurança, a cláusula pode ser o trecho decisivo.

Termos ambíguos, documentos repetidos, chunks sem contexto e consultas longas também confundem a ordem inicial.

Combinar palavras-chave com busca semântica ajuda a ampliar a cobertura.

Ainda assim, uma recuperação abrangente tende a trazer ruído. O reranking existe para fazer uma seleção mais fina dentro desse conjunto menor.

Como funciona o pipeline com reranking

Um pipeline com reranking geralmente segue quatro movimentos:

1. Recuperar candidatos: busca lexical, vetorial ou híbrida encontra um conjunto relativamente amplo de chunks.
2. Reavaliar os pares: o reranker analisa a pergunta junto de cada candidato e produz novas pontuações.
3. Selecionar o contexto: apenas os melhores trechos, após filtros de diversidade e permissões, seguem adiante.
4. Gerar a resposta: o modelo recebe a pergunta, as instruções e o contexto final, podendo incluir fontes ou citações.

Essa arquitetura separa duas necessidades que entram em conflito. A primeira etapa precisa pesquisar rapidamente uma base extensa.

A segunda pode usar um modelo mais caro porque examina dezenas de candidatos, não milhões de documentos.

A documentação da Elastic sobre semantic reranking apresenta a mesma ideia de reordenar resultados produzidos por uma etapa anterior.

Ranking e reranking: qual é a diferença?

Ranking é o ato geral de ordenar resultados. Um mecanismo de busca já faz ranking quando calcula BM25, similaridade vetorial ou uma combinação de sinais.

Reranking é uma nova ordenação aplicada sobre a lista que já passou por essa primeira seleção.

Aspecto	Recuperação e ranking inicial	Reranking
Escala	Base inteira ou grande índice	Lista curta de candidatos
Objetivo	Boa cobertura com baixa latência	Melhor precisão nas primeiras posições
Sinais comuns	Palavras-chave, filtros e similaridade vetorial	Interação detalhada entre consulta e trecho
Custo por item	Baixo	Geralmente maior
Falha que não resolve	—	Documento relevante ausente dos candidatos

Portanto, não é uma disputa entre as etapas. Elas são complementares. Um bom recuperador aumenta a chance de o conteúdo certo entrar na lista; um bom reranker melhora sua posição para que ele não seja cortado antes da geração.

Principais tipos de reranker

“Reranker” não identifica uma única tecnologia. Existem opções com níveis diferentes de qualidade, custo e controle.

• Cross-encoder: processa consulta e documento juntos. Essa interação detalhada costuma produzir bons sinais de relevância, mas exige uma inferência para cada par.
• Late interaction: mantém representações mais granulares de consulta e documento e calcula interações posteriormente. Busca equilibrar qualidade e eficiência.
• LLM como avaliador: um modelo de linguagem atribui notas ou ordena vários resultados seguindo critérios escritos. É flexível, porém pode custar mais, variar entre execuções e exigir proteção contra conteúdo malicioso nos documentos.
• Regras e sinais de negócio: data, autoridade da fonte, idioma, disponibilidade e permissões podem ajustar a ordem. Muitas aplicações combinam esses sinais com uma pontuação semântica.

O trabalho “Passage Re-ranking with BERT”, de Rodrigo Nogueira e Kyunghyun Cho, ajudou a consolidar o uso de modelos BERT em uma arquitetura de duas etapas para reordenação de passagens.

Hoje há modelos especializados e APIs prontas, mas o princípio de limitar a análise mais cara a um conjunto candidato continua central.

Cross-encoder ou embeddings: o que muda?

Na recuperação vetorial tradicional, cada documento pode ter seu embedding calculado antes da consulta.

Quando a pergunta chega, o sistema gera apenas seu vetor e consulta um banco de dados vetorial. Essa pré-computação torna a busca escalável.

O cross-encoder não separa as entradas. Ele lê pergunta e trecho juntos, permitindo que a atenção do modelo compare termos, negações, relações e detalhes específicos.

O preço é perder a pré-computação: cada candidato precisa ser avaliado em relação à pergunta atual.

Por isso, embeddings funcionam bem para gerar candidatos, enquanto cross-encoders são comuns na reordenação.

Usar um cross-encoder para comparar uma consulta com todo o acervo seria caro; aplicá-lo aos primeiros 30 ou 50 resultados pode ser viável.

O melhor desenho depende de volume, infraestrutura e tempo de resposta esperado.

Como escolher candidatos e top-k

Duas decisões influenciam diretamente o resultado. A primeira é a profundidade de reranking: quantos candidatos serão reavaliados.

A segunda é o top-k final: quantos chunks entrarão no contexto do modelo.

Uma lista candidata muito pequena reduz custo, mas pode esconder o documento correto na posição seguinte.

Uma lista grande aumenta a chance de cobertura, porém adiciona inferência e latência. No final, enviar chunks demais ao gerador também não é garantia de qualidade.

Conteúdo redundante ou contraditório pode diluir a evidência central e consumir a janela de contexto.

Não existe um número universal. Comece com um intervalo coerente com o seu acervo e teste. Por exemplo, recupere algumas dezenas, reordene e envie poucos trechos bem classificados.

Depois compare alternativas com consultas reais. Também vale limitar documentos repetidos e preservar diversidade quando uma resposta exige mais de uma fonte.

Quando o reranking traz mais valor

O reranking tende a ser mais útil quando as primeiras posições ainda contêm ruído, mas a lista ampla já inclui os documentos corretos. Alguns cenários recorrentes são:

• bases técnicas com produtos, versões e conceitos parecidos;
• centrais de atendimento com políticas gerais e exceções específicas;
• pesquisa jurídica ou regulatória em que uma cláusula muda a interpretação;
• catálogos com consultas longas e vários requisitos;
• busca corporativa com documentos duplicados ou vocabulários diferentes;
• assistentes que precisam citar a fonte mais diretamente relacionada à afirmação.

O benefício pode ser menor em bases pequenas e bem estruturadas, consultas simples ou aplicações em que o ranking inicial já atende ao objetivo.

Antes de adicionar outra camada, analise exemplos de falha. Se o problema for conteúdo desatualizado, filtros de permissão ou chunks sem informação suficiente, a correção está em outra parte do sistema.

Custos, latência e limitações

Reranking não é uma melhoria gratuita. Cada consulta passa por processamento adicional.

O impacto depende do modelo, do tamanho dos chunks, da quantidade de candidatos, do uso de serviço externo ou infraestrutura própria e da possibilidade de agrupar avaliações.

Também há limites qualitativos. Um reranker treinado em textos gerais pode entender mal siglas de um domínio especializado. Documentos excessivamente longos podem ser truncados.

Uma consulta vaga pode produzir uma ordem aparentemente confiante, mas pouco útil. E nenhum modelo recupera o que não entrou na lista candidata.

Em aplicações sensíveis, considere ainda privacidade e residência dos dados antes de enviar documentos a uma API. Regras de acesso devem ser aplicadas antes do reranking, não depois.

Um trecho proibido não deve entrar no conjunto só porque seria descartado na etapa final.

Como implementar reranking em RAG

Uma implementação segura começa com um baseline, isto é, o pipeline atual medido sem reranker.

Em seguida, registre para cada consulta os candidatos, suas pontuações iniciais, a nova ordem, os chunks enviados ao modelo e a resposta produzida. Sem esse rastro, fica difícil explicar por que a qualidade mudou.

1. Monte um conjunto de perguntas reais, incluindo casos fáceis, ambíguos e difíceis.
2. Verifique se a recuperação ampla contém uma evidência adequada para cada pergunta.
3. Escolha um reranker compatível com idioma, domínio e limite de tamanho dos textos.
4. Teste diferentes profundidades de candidatos e quantidades finais de chunks.
5. Registre latência por etapa, custo por consulta e alterações na resposta.
6. Faça implantação gradual e mantenha uma forma simples de desativar a camada.

Filtros determinísticos, como tenant, idioma e validade do documento, devem reduzir o universo antes da inferência. Depois do reranking, você pode aplicar deduplicação e diversidade.

Por fim, organize o contexto com rótulos claros de fonte. Esse cuidado faz parte da engenharia de contexto: não basta escolher bons trechos; é preciso apresentá-los ao modelo de forma previsível.

Como avaliar a qualidade do reranking

Avalie separadamente a recuperação e a resposta final. Se você medir apenas se o texto “parece melhor”, não saberá qual etapa contribuiu para o resultado.

• Recall@k: verifica se ao menos um documento relevante aparece entre os k candidatos. É especialmente útil para a primeira recuperação.
• Precision@k: indica a proporção de resultados relevantes nas primeiras posições.
• MRR: valoriza a posição do primeiro resultado relevante.
• nDCG: considera diferentes graus de relevância e dá mais peso às posições superiores.
• Qualidade da resposta: avalia correção, completude, apoio nas fontes e ausência de afirmações sem evidência.
• Operação: mede percentis de latência, custo por consulta, taxa de erros e estabilidade.

Faça comparações lado a lado entre o baseline e as variantes. Use julgamentos humanos para uma amostra representativa e automatize o que puder com critérios claros.

Um programa de evals em IA deve incluir perguntas novas, casos adversos e regressões de versões anteriores. O objetivo não é provar que o reranker é bom, mas descobrir em quais segmentos ele ajuda ou atrapalha.

Erros comuns ao adicionar um reranker

• Pular o baseline: sem números anteriores, qualquer percepção de melhora fica frágil.
• Usar poucos candidatos: o reranker recebe uma lista limpa, mas que talvez não contenha a resposta.
• Reranquear chunks ruins: trechos cortados no meio de uma ideia continuam incompletos, mesmo no primeiro lugar.
• Ignorar o idioma e o domínio: o modelo pode interpretar mal termos especializados ou consultas em português.
• Otimizar só relevância: um pequeno ganho pode não compensar o aumento de tempo e custo.
• Enviar dados sem filtros: segurança e permissão não podem depender da pontuação semântica.
• Confiar em uma única métrica: ranking melhor não garante automaticamente uma resposta mais fiel.

Outro erro é alterar recuperação, prompt, modelo gerador e reranker ao mesmo tempo. Faça mudanças controladas. Assim, quando uma métrica variar, você terá evidência sobre a causa provável.

Checklist prático

• A evidência correta aparece na lista candidata?
• Os chunks preservam título, seção e contexto necessário?
• O reranker funciona bem em português e no seu domínio?
• Há filtros de permissão antes da reordenação?
• A profundidade de candidatos foi testada, não apenas escolhida por hábito?
• Resultados duplicados são controlados?
• Qualidade, latência e custo são comparados com o baseline?
• As consultas de avaliação representam uso real?
• Há monitoramento de regressão e um caminho de rollback?

Se várias respostas forem negativas, vale corrigir a fundação antes de contratar uma API ou hospedar outro modelo.

Reranking funciona melhor como refinamento de um pipeline observável, não como remendo para uma recuperação desconhecida.

Perguntas frequentes

Reranking é obrigatório em todo RAG?

Não. Bases pequenas, consultas simples ou uma recuperação inicial muito precisa podem funcionar bem sem essa etapa. A decisão deve vir de avaliações que mostrem ruído nas primeiras posições e ganho suficiente após a reordenação.

Um reranker substitui a busca vetorial?

Normalmente, não. A busca vetorial, lexical ou híbrida recupera candidatos em escala. O reranker trabalha sobre essa lista reduzida e melhora sua ordem. As duas etapas têm funções complementares.

Quantos documentos devo reranquear?

Não há um valor universal. A quantidade depende do recall da busca, da latência permitida, do tamanho dos chunks e do custo do modelo. Teste algumas faixas no mesmo conjunto de consultas e observe quando o ganho começa a estabilizar.

Reranking reduz alucinações?

Pode reduzir respostas sem apoio quando coloca evidências melhores no contexto, mas não elimina alucinações. Prompt, modelo gerador, qualidade das fontes, tratamento de conflitos e política para responder “não sei” continuam importantes.

Posso usar um LLM como reranker?

Sim. Um LLM pode pontuar pares ou ordenar uma lista conforme critérios. A abordagem oferece flexibilidade, mas costuma exigir mais tempo, custo, testes de consistência e defesa contra instruções maliciosas presentes nos documentos.

Como saber se o reranking melhorou o sistema?

Compare baseline e variante com as mesmas perguntas. Meça a posição dos documentos relevantes, a qualidade e fidelidade das respostas, a latência e o custo. Avalie também segmentos separadamente, pois o ganho médio pode esconder piora em um tipo de consulta.

Conclusão

O reranking em RAG cria uma segunda oportunidade para colocar a evidência certa no topo.

A recuperação inicial mantém velocidade e cobertura; a reordenação investe mais processamento em uma lista curta. Quando o documento correto já está entre os candidatos, essa combinação pode melhorar contexto, citações e precisão.

O ganho, porém, precisa ser demonstrado. Comece por consultas reais, mantenha um baseline, teste profundidade e top-k, acompanhe latência e avalie a resposta final.

Se a recuperação não encontra a informação ou os chunks não preservam sentido, corrija esses pontos primeiro. Um reranker bem medido é uma camada de precisão; sem avaliação, é apenas mais uma camada de complexidade.