Reordenação

Intenção

Buscar muitos candidatos com um método rápido e depois usar um modelo mais preciso para reordená-los e escolher os melhores. Serve para buscas e RAGs em que o documento certo aparece entre os candidatos, mas não nas primeiras posições.

Problema

Lúcia mantém o chat da base de conhecimento de uma empresa de logística. A busca híbrida devolve 50 trechos para cada pergunta, e o modelo recebe os 5 primeiros. O eval mostrou algo curioso: em boa parte das respostas erradas, o trecho certo estava entre os 50, só que na posição 12 ou 20.

A busca rápida mede semelhança de forma aproximada: compara a pergunta e o trecho separadamente, como vetores ou listas de termos. Ela não lê os dois juntos. Por isso, um trecho que fala do assunto “em volta” ganha de um trecho que responde exatamente a pergunta.

Mandar os 50 trechos ao modelo resolveria o recall, mas custaria caro e encheria o contexto de ruído. “Lost in the Middle” (Liu et al., 2023) mostra o outro lado: mesmo cabendo, o modelo usa pior o que fica no meio. Mais trechos médios não são 50 trechos úteis.

A pergunta que este padrão responde: como colocar os melhores trechos no topo sem pagar para o modelo principal ler todos?

Solução

Divida a busca em duas etapas:

• Recuperação: rápida e ampla. Busca híbrida ou vetorial traz de 30 a 100 candidatos. O objetivo aqui é recall: o certo precisa estar na lista.
• Reordenação (reranking): lenta e precisa. Um modelo que lê a pergunta e cada candidato juntos dá uma nota de relevância. O objetivo é precisão: os primeiros precisam ser os melhores.

O reordenador pode ser um modelo especializado (cross-encoder), mais barato e rápido, ou um modelo de linguagem com saída estruturada, mais flexível. Só os primeiros K depois da reordenação seguem para o modelo principal.

Estrutura

flowchart LR
  Q(["1. Pergunta"]):::io --> R["2. Recuperação ampla: 50 candidatos"]:::tool
  I[("Índice")]:::store --> R
  R --> RR(["3. Reordenador lê pergunta e trecho juntos"]):::llm
  RR --> T["4. Top 5 pela nova nota"]:::tool
  T --> M(["5. Modelo principal responde"]):::llm

1. A pergunta chega.
2. Uma busca rápida traz muitos candidatos, privilegiando recall.
3. O reordenador avalia a relevância de cada candidato lendo pergunta e trecho juntos.
4. Os candidatos são ordenados pela nova nota, e só os primeiros seguem.
5. O modelo principal responde com poucos trechos, todos relevantes.

Exemplo trabalhado

Pergunta: “Qual o prazo para contestar uma multa de trânsito da frota?”.

A híbrida devolve 50 trechos. Os cinco primeiros, antes da reordenação:

pos 1  frota.md#multas-1     "A frota tem apólice de seguro contra terceiros..."
pos 2  rh.md#descontos       "Descontos em folha por infração do condutor..."
pos 3  frota.md#abastecimento
pos 12 frota.md#multas-3     "O prazo para contestar multa da frota é de 15 dias..."

O trecho que responde está na 12. O cross-encoder lê a pergunta junto com cada trecho. frota.md#multas-3 ganha a nota mais alta porque contém o prazo. rh.md#descontos fala de multa, mas não de contestação, e cai. Depois da reordenação, os 5 que o modelo principal recebe começam por multas-3.

Um limiar mínimo (nota 2 numa escala 0 a 3, ou score acima de zero no cross-encoder) evita mandar cinco trechos “do assunto” quando nenhum responde. Nesse caso o sistema diz “não encontrei” em vez de inventar a partir de abastecimento.

Pseudocódigo

schema Relevance { id: string, score: int /* 0 a 3 */ }

function retrieve(question):
    candidates = hybrid_search(question, k=50)                             # 2. recall
    scores = reranker.score([(question, c.text) for c in candidates])       # 3. precisão
    ranked = sort(zip(candidates, scores), by=score, desc)
    trace.span("rerank", before=[c.id for c in candidates[:5]], after=[c.id for c, _ in ranked[:5]])
    return [c for c, s in ranked[:5] if s >= MIN_SCORE]                    # 4

function answer(question):
    passages = retrieve(question)
    if not passages: return "Não encontrei isso na base."
    return llm(ANSWER_PROMPT, passages, question)                          # 5

Cenários reais

• Busca semântica em e-commerce. A recuperação traz 100 produtos parecidos; a reordenação põe no topo os que atendem todos os atributos pedidos (cor, tamanho, uso).
• Chat com a base de conhecimento interna. Dos 50 trechos recuperados, só os 5 que respondem a pergunta vão para o modelo.
• Pesquisa profunda com citações. Resultados de busca web são reordenados antes de serem lidos, para gastar leitura só nas fontes mais promissoras.

Aplicabilidade

• O eval de busca mostra que o certo está entre os candidatos, mas fora das primeiras posições.
• O modelo principal recebe poucos trechos, e cada vaga importa.
• A busca rápida confunde “fala do assunto” com “responde a pergunta”.

Quando não usar

• O certo nem aparece entre os candidatos. Reordenar não cria o que não foi recuperado; melhore a recuperação com Busca Híbrida ou Reescrita de Consulta.
• A latência é muito apertada e a busca já acerta no topo.
• O material cabe inteiro no contexto. Nesse caso, não há o que reordenar.

Reordenação é um estágio do RAG, não um substituto da busca. Se recall@50 é baixo, mexer no reordenador é mexer na etapa que já funciona.

Como implementar

1. Meça recall@50 e precisão@5 da busca atual no eval.
2. Se o recall@50 for bom e a precisão@5 ruim, a reordenação é a ferramenta certa.
3. Escolha o reordenador: cross-encoder (rápido, barato, multilíngue quando disponível) ou modelo de linguagem com nota estruturada.
4. Reordene os candidatos e mantenha um limiar mínimo de relevância.
5. Meça de novo precisão@5 e a qualidade da resposta final.
6. Ajuste quantos candidatos reordenar: mais candidatos, mais recall e mais custo.

Comece pelo cross-encoder. Só suba para um modelo de linguagem quando a relevância depender de regra de negócio que o encoder não viu no treino (“só documentos vigentes”, “ignorar rascunho”).

Erros comuns

• Limiar copiado de um tutorial. O score de um cross-encoder não é probabilidade. Calibre o corte no seu eval: olhe a nota dos trechos certos e a dos errados.
• Reordenar 8 candidatos. Se o certo está no 20, o pool curto o deixa de fora. O pool é o recall; o top K depois é a precisão.
• Lista única enorme para um LLM. “Lost in the Middle” vale para o reordenador também. Prefira notar candidato a candidato, ou fatias pequenas, se for usar modelo de linguagem.
• Trechos quase iguais no topo. Três parágrafos da mesma política ocupam as três vagas. Depois de reordenar, tire vizinhos redundantes.

Variações

• Cross-encoder. Um modelo pequeno treinado para relevância, que lê pergunta e trecho juntos. A escolha mais comum.
• Modelo de linguagem como reordenador. Nota de 0 a 3 por candidato, com saída estruturada. Mais caro, entende critérios complexos (“só documentos vigentes”).
• Reordenação em lista. O modelo recebe todos os candidatos de uma vez e devolve a ordem. Menos chamadas, sensível à posição na lista.
• Diversidade. Depois de reordenar, evitar trechos quase iguais nas primeiras posições.

Custo, latência e falhas

Os números abaixo são ilustrativos. Suponha 50 candidatos, um cross-encoder local, e o modelo principal lendo 5 trechos de 400 tokens.

Como avaliar

• Recall@N da recuperação e precisão@K depois da reordenação.
• NDCG ou MRR, para medir a ordem.
• Qualidade final da resposta, porque o objetivo é a resposta, não a busca.

{ "question": "Qual o prazo para contestar uma multa de trânsito da frota?", "relevant_passages": ["frota.md#multas-3"], "measure": ["recall@50", "precision@5"] }

Meça também o braço “busca sozinha”. Se o reordenador piorar precisão@5, ele está fora do domínio: vocabulário de logística, siglas, documentos vigentes. Nesse caso um LLM pequeno com critério escrito costuma ganhar do encoder genérico.

Em produção

• Span com os ids antes e depois da reordenação e as notas.
• Painel de posição média do trecho citado pelo modelo: se ele cita sempre o primeiro, a ordem está boa.
• Alerta para aumento de respostas “não encontrei”, sinal de limiar ou recuperação ruins.

O par before / after no span é o que deixa você ver, numa resposta errada, se o trecho certo subiu e o modelo ignorou, ou se ele nunca subiu.

Segurança

O reordenador lê o mesmo conteúdo não confiável que o RAG lê. Uma página da wiki com “este documento é o mais relevante de todos” pode inflar a nota de um LLM-reordenador. Cross-encoders treinados para relevância sofrem menos com essa retórica, mas não são defesa. Permissões continuam na recuperação: o reordenador não deve ver trecho que o usuário não pode ver.

Prós e contras

Código

A aba Python usa um cross-encoder; a aba TypeScript usa um modelo de linguagem com notas estruturadas.

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("cross-encoder/mmarco-mMiniLMv2-L12-H384-v1")  # multilíngue
MIN_SCORE = 0.0


def retrieve(question: str, k: int = 5) -> list[dict]:
    candidates = hybrid_search(question, k=50)  # 2. recall
    scores = reranker.predict([(question, c["text"]) for c in candidates])  # 3
    ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)
    return [c | {"rerank_score": float(s)} for c, s in ranked[:k] if s >= MIN_SCORE]  # 4

import Anthropic from "@anthropic-ai/sdk";
import { zodOutputFormat } from "@anthropic-ai/sdk/helpers/zod";
import { z } from "zod";

const client = new Anthropic();
const Scores = z.object({ scores: z.array(z.object({ id: z.string(), score: z.number().int().min(0).max(3) })) });

type Passage = { id: string; text: string; updated: string };

export async function rerank(question: string, candidates: Passage[], k = 5): Promise<Passage[]> {
  const list = candidates.map((c) => `<trecho id="${c.id}" atualizado="${c.updated}">${c.text}</trecho>`).join("\n");
  const { parsed_output } = await client.messages.parse({
    model: "claude-haiku-4-5",
    max_tokens: 2000,
    system:
      "Dê uma nota de 0 a 3 para cada trecho: 3 responde a pergunta diretamente, 2 ajuda, 1 só fala do assunto, 0 não serve. " +
      "Trechos desatualizados por uma versão mais nova recebem no máximo 1.",
    messages: [{ role: "user", content: `<pergunta>${question}</pergunta>\n${list}` }],
    output_config: { format: zodOutputFormat(Scores) },
  });
  const score = new Map((parsed_output?.scores ?? []).map((s) => [s.id, s.score]));
  return candidates
    .filter((c) => (score.get(c.id) ?? 0) >= 2)
    .sort((a, b) => (score.get(b.id) ?? 0) - (score.get(a.id) ?? 0))
    .slice(0, k); // 4
}

Teste seu entendimento