O reranker mentiroso

Capítulo 3 — O reranker mentiroso

No jargão técnico do RAG, existe uma figura-chave, pouco glamourosa e pouco contada: o reranker. Imagine a pesquisa empresarial como a entrada de uma discoteca. O banco de vetores é o porteiro: olha rapidamente para a multidão e deixa entrar trinta candidatos que, à primeira vista, se parecem com o que você procura. O reranker é o segurança interno: pega esses trinta, olha-os com calma, seleciona cinco — aqueles que o LLM realmente lerá para construir a resposta — e devolve os outros vinte e cinco. É uma função pequena, mas enorme: se ele errar, todos erram. Se o segurança não souber ler rostos, o local se encherá das pessoas erradas e ninguém entenderá por que a noite foi mal.

Em 2025, vários serviços em nuvem apareceram no mercado que ofereciam rerankers como APIs. Você envia uma pergunta e uma lista de documentos, eles retornam pontuações. Conveniente, escalável, sem GPUs para comprar, sem modelos para baixar. Um famoso provedor europeu de modelos — sem mencionar nomes, mas você sabe quais nomes estamos evitando — expôs um modelo promissor da família Qwen, com quatro bilhões de parâmetros, rotulado como "Reranker". O preço era razoável, a latência aceitável. Qualquer um, naquele momento histórico, o teria escolhido. Muitos o escolheram.

A menos que as pontuações estivessem incorretas. Não "ligeiramente" incorretas, como pode acontecer com qualquer modelo: incorretas estruturalmente. Documentos obviamente relevantes recebiam 0.2, documentos fora do tema recebiam 0.8. As primeiras suspeitas, como sempre nesses casos, foram direcionadas aos suspeitos habituais: o modelo de embedding, o chunking, a formulação da consulta, o pré-processamento dos documentos. Semanas de investigações em pistas erradas. Somente comparando sistematicamente as respostas do reranker em nuvem com as de um reranker local de referência — a mesma entrada, os mesmos documentos, pontuações lado a lado em uma planilha Excel — a verdade desconfortável emergiu: o modelo exposto via API estava quebrado. Talvez um erro de deploy, talvez uma versão errada carregada por engano, talvez um bug na serialização das pontuações. O provedor nunca admitiu formalmente. O problema, no entanto, simplesmente desapareceu um dia, após uma atualização silenciosa e nenhuma alteração nas notas.

O ponto desta história não é "os serviços de nuvem erram" — todos erram, até os modelos locais erram. O ponto é mais sutil: em um RAG sério, o reranker é uma peça que você precisa poder olhar por dentro. Se for uma caixa preta paga, e se suas saídas são números que parecem plausíveis mesmo quando são aleatórios — e as pontuações de um reranker parecem sempre plausíveis, porque são números entre zero e um com algumas casas decimais —, você não tem como entender o que está errado no seu sistema. E como o reranker está "para o final" do pipeline, seu erro contamina toda avaliação a montante: parece lenta a pesquisa, errada a consulta, pobres os embeddings. Na realidade, é o segurança que não sabe ler os rostos, e você está questionando o vidro da porta.

A escolha contracorrente de algumas equipes, nestes meses — em vez de avançar para mais nuvem, voltar atrás — foi trazer o reranker para casa. Um modelo de código aberto da família BGE, não gigantesco, executado em GPU local (inclusive em Apple Silicon, com algumas cautelas nos drivers). Mais trabalho de gerenciamento, é verdade. Mas a possibilidade de fazer experimentos controlados, de entender quando ele erra, de comparar versões, de manter um histórico. E — não menos importante — de não enviar para a API uma fração de centavo por cada pesquisa de usuário. Fração que, multiplicada por dezenas de milhares de consultas por mês, rapidamente deixa de ser uma fração e se torna uma rubrica orçamentária.

Quando um componente é tão crítico que seu mau funcionamento corrompe toda a sua capacidade de medir o resto, delegá-lo a uma caixa preta não é eficiência. É um ato de fé. E os atos de fé, em produção, são pagos com juros compostos.