Reclassificação
Por que isso importa
Em profundidade
A reclassificação existe porque recuperação rápida e recuperação precisa são problemas diferentes. A primeira etapa de um pipeline de RAG ou busca semântica precisa peneirar milhões de chunks em milissegundos, portanto depende de métodos aproximados: um modelo bi-encoder de Embedding converte a consulta e cada documento em vetores de forma independente, ou o BM25 pontua a sobreposição de palavras-chave sem compreensão alguma do significado. Esses métodos geralmente colocam o documento certo em algum lugar entre os 50 primeiros, mas a ordenação dentro desses 50 é ruidosa. Um reclassificador pega esse conjunto de candidatos e aplica um modelo que seria lento demais para executar contra o corpus inteiro — em geral um cross-encoder que lê a consulta e um documento juntos —, reordenando a lista para que os chunks realmente relevantes subam ao topo. O top-k final, muitas vezes apenas 3 a 10 chunks, é o que se monta no prompt.
Bi-Encoders vs. Cross-Encoders
A diferença de desempenho entre as duas etapas vem da arquitetura. Um bi-encoder produz um vetor por texto: a consulta é convertida em embedding uma vez, cada documento também uma vez (geralmente offline, com antecedência), e a relevância é apenas a Similaridade de Cosseno entre dois pontos. Isso é extremamente rápido com índices aproximados de vizinhos mais próximos, mas o modelo nunca vê a consulta e o documento juntos, portanto não consegue modelar como palavras específicas de um interagem com palavras específicas do outro. Um cross-encoder faz o oposto: a consulta e um único documento candidato são concatenados e passados por um Transformer como uma só entrada, e o modelo produz diretamente uma pontuação de relevância. Como cada token pode prestar atenção a todos os tokens dos dois textos, ele capta nuances — negação, restrições exatas, formulações em vários saltos — que a similaridade de embeddings perde rotineiramente.
O problema é o custo. Pontuar 50 candidatos significa 50 passagens forward separadas, e os pares não podem ser pré-calculados porque a consulta só é conhecida no momento da solicitação. É por isso que cross-encoders nunca são executados sobre um corpus inteiro de milhões de documentos e que a divisão em duas etapas existe: o trabalho do bi-encoder é recall (colocar os documentos certos no conjunto de candidatos), e o do cross-encoder é precisão (colocá-los na ordem certa).
Reclassificadores na Prática
Há duas formas comuns de acrescentar um reclassificador. APIs hospedadas, como Cohere Rerank da Cohere e o endpoint de rerank da Voyage AI, recebem uma consulta mais uma lista de documentos em uma única solicitação e devolvem pontuações — nenhuma infraestrutura para operar, mas uma chamada de rede extra e preço por solicitação. Modelos de pesos abertos, liderados pela família bge-reranker da BAAI e pelos reclassificadores da Jina AI, estão disponíveis no Hugging Face e podem rodar em uma única GPU ou até em CPU para conjuntos pequenos de candidatos, mantendo os dados internamente e os custos previsíveis.
O padrão de integração é o mesmo nos dois casos: recupere um conjunto generoso de candidatos (top 20 a 100, muitas vezes por busca híbrida em um Banco de dados vetorial mais BM25), reclassifique-o, mantenha os 3 a 10 primeiros e descarte o restante. Algumas equipes pulam completamente o modelo dedicado e instruem um Modelo de linguagem grande a ranquear candidatos em zero-shot; isso funciona, e reclassificadores listwise baseados em LLM podem ser fortes, mas um cross-encoder criado para a tarefa costuma ser de uma a duas ordens de magnitude mais barato por consulta.
Ele Não Conserta uma Recuperação Ruim
Um equívoco comum é achar que acrescentar um reclassificador resgatará um pipeline de busca fraco. Não resgatará, porque a reclassificação apenas reordena o que a primeira etapa já retornou: se o chunk relevante nunca entrou no conjunto de candidatos, o reclassificador nunca o vê, e nenhuma pontuação precisa o trará de volta. A primeira etapa estabelece um teto rígido de recall para tudo o que vem depois. Isso tem uma consequência prática para depuração: quando a qualidade da recuperação de ponta a ponta é ruim, meça as etapas separadamente. Verifique se o chunk certo aparece em algum lugar entre os 50 primeiros (um problema de recuperação — corrija embeddings, divisão em chunks ou acrescente busca híbrida) ou se aparece, mas fica baixo demais (um problema de reclassificação). Equipes que ignoram essa distinção muitas vezes passam semanas ajustando um reclassificador para ganhos que sempre estiveram limitados pela primeira etapa.
O Orçamento de Latência
Reclassificação é uma troca: melhor ordenação por Latência e custo adicionais. Um cross-encoder auto-hospedado pontuando 50 pares de consulta e documento geralmente acrescenta de dezenas a algumas centenas de milissegundos, conforme o tamanho do modelo e o comprimento do documento; uma API hospedada soma a isso uma viagem de ida e volta pela rede. Os controles são diretos: reclassifique menos candidatos (top 20 em vez de top 100), trunque os documentos antes de pontuar, use um modelo menor ou armazene em cache as pontuações de consultas repetidas.
Se a troca vale a pena depende da aplicação. Para um assistente voltado ao usuário em que as respostas já levam segundos para ser geradas, 100 a 300 ms extras costumam ser invisíveis, e o ganho de relevância reduz diretamente a Alucinação causada por contexto fora do assunto. Para busca no estilo autocomplete ou serviços internos com QPS alto, equipes muitas vezes reservam a reclassificação para consultas que parecem difíceis — longas, ambíguas ou com baixa confiança na primeira etapa — e deixam as fáceis passarem direto. O padrão pragmático em sistemas de recuperação de produção é: sempre reclassifique, a menos que consiga provar que não pode pagar o custo.