Reranking: reordenar o resultado da busca

Um escritório tem dez mil pareceres arquivados e alguém precisa achar aquele que sustenta uma tese específica. A busca por palavra-chave devolve trinta candidatos, e a peça certa está entre eles — só que na posição onze. Quem lê a lista desiste na quinta.

Esse é o problema do reranking, e ele é diferente do problema de busca. A busca já funcionou: a resposta entrou na lista. O que falhou foi a ordem.

Por que a busca rápida não resolve sozinha

Métodos de busca rápida, como BM25 ou vetores de embedding, existem para rodar em cima do acervo inteiro. Eles são bons nisso e ruins em outra coisa: dizer qual dos candidatos da lista curta é o correto. BM25 ordena por palavras compartilhadas, e a peça certa muitas vezes usa palavras diferentes para dizer a mesma coisa.

O número do experimento oficial mostra o tamanho do problema. Sobre 3.565 passagens de decisões judiciais, a busca rápida colocou a passagem correta dentro da lista de 30 candidatos em 100% das 40 consultas — e em primeiro lugar em apenas 5% delas. A informação estava lá. A ordem é que não servia.

A tentação seguinte é pedir ao LLM que ordene a lista inteira. Isso traz três problemas: você precisa inventar uma escala de notas e pedir ao modelo que a aplique igual a todos os candidatos, chamadas repetidas podem dar notas diferentes para o mesmo par, e geração de texto custa tempo e dinheiro numa tarefa que precisa de um número só.

O desenho das perguntas

O reranking com o Jev é uma pergunta de sim ou não por par. A consulta e um candidato entram no state; um Noul devolve a probabilidade de aquele candidato ser o que responde. Essa probabilidade é a nota pela qual o código ordena.

from typesafe_sdk import Noul, NoulCriteria, TypeSafeClient

e_a_fonte_citada = Noul(
    instructions=(
        "O trecho da consulta vem de uma decisão judicial e foi escrito ao redor de uma "
        "citação que foi removida. O candidato pode ser a decisão citada, ou seja, ele "
        "estabelece a tese específica que a consulta invoca naquele ponto?"
    ),
    criteria=NoulCriteria(
        true="O candidato afirma ou estabelece a regra, o padrão ou o entendimento específico que a consulta atribui à citação removida.",
        false="O candidato apenas trata de tema parecido; não fornece a tese específica em que a consulta se apoia.",
    ),
)

with TypeSafeClient() as client:
    notas = {}
    for candidato in lista_curta:
        resposta = client.system_one(
            state={"consulta": trecho, "candidato": candidato},
            questions={"e_a_fonte_citada": e_a_fonte_citada},
        )
        notas[candidato] = resposta.answers["e_a_fonte_citada"].noul

reordenada = sorted(lista_curta, key=lambda c: notas[c], reverse=True)

Duas decisões de projeto merecem atenção. Primeiro, os critérios true e false fazem o trabalho pesado: eles definem a diferença entre “trata do mesmo assunto” e “estabelece a tese invocada”, que é justamente onde a busca por palavra-chave erra. Segundo, cada par é avaliado isoladamente, então as notas são comparáveis entre candidatos — e o código pode ordenar sem depender de o modelo ter visto a lista toda.

O que o experimento oficial mediu

O cookbook usa o CLERC, um conjunto de recuperação jurídica com decisões judiciais dos Estados Unidos. São 3.565 passagens reunidas de 170 registros, 40 consultas avaliadas e listas curtas de 30 candidatos montadas pelo BM25. Os números publicados pela TypeSafe:

O custo também está publicado: 1.200 chamadas, 1.536.002 tokens de entrada e 25.200 de saída, US$ 0,0645 no total. O experimento declara rodar no jev-1.12.

Vale ler esses números com a honestidade que o próprio cookbook usa. Dezoito por cento de acerto no primeiro lugar não é um sistema resolvido — é mais que o triplo do ponto de partida numa tarefa jurídica difícil, com citações removidas de propósito. E o cookbook avisa que fez uma pergunta por par para ficar didático: uma aplicação real agruparia várias perguntas sobre o mesmo par na mesma chamada, como mostra a receita de perguntas paralelas.

O que muda em português

O conjunto do experimento é em inglês, e isso importa para calibrar expectativa. A mecânica é idêntica em português: o state carrega consulta e candidato, o critério descreve a fronteira, o Noul devolve a nota. O que você não pode transportar é o número: 18% no CLERC não prevê o seu acerto em pareceres brasileiros.

Nossa experiência em português com decisões parecidas foi consistente no ponto que mais importa aqui — o modelo separou bem o que parece do que é. Nos cinco testes de 18 de setembro de 2026, uma mensagem que ameaçava registrar reclamação no Procon subiu o risco de abandono para 3,13 de 5, enquanto a pergunta sobre cancelamento ficou em 0,17: reclamar não é cancelar. É a mesma distinção fina que um bom critério de reranking precisa fazer.

Onde isso quebra

• O reranking não salva busca ruim. Ele só reordena o que entrou na lista. Se a busca rápida não trouxe a passagem correta, nenhuma pergunta recupera.
• Uma chamada por par custa em escala. Mil e duzentas chamadas foram centavos, mas cem mil pares por dia é outra conversa. A saída é filtrar a lista curta antes e agrupar perguntas por par.
• State grande. Passagens longas no state pioram a acurácia, conforme os limites declarados. Corte o candidato ao trecho relevante em vez de mandar o documento inteiro.
• Conteúdo adversarial. Um candidato escrito para parecer a resposta pode mover a nota, e a documentação lista isso entre os modos de falha conhecidos.

Quando o documento é único e você quer achar a linha certa dentro dele, o desenho muda: em vez de uma chamada por candidato, uma chamada com todas as linhas como opções. É a receita de busca linha a linha. O índice completo está em receitas.