Busca híbrida e reranking

Na aula 02 vimos que embeddings capturam significado. Isso é ótimo para perguntas como "como faço para cancelar minha assinatura?", onde variações de linguagem existem. Mas considere estes casos:

• Um desenvolvedor busca por NullPointerException em logs de erro.
• Um analista de segurança pesquisa pelo código CVE-2024-1234.
• Um usuário digita o nome exato de um produto: XR-7000 Pro.

O modelo de embedding vai vetorizar esses termos e buscar vizinhos no espaço semântico. O problema é que CVE-2024-1234 e CVE-2024-5678 ficam muito próximos vetorialmente, afinal, são estruturalmente similares. O sistema vai recuperar o chunk errado com alta confiança.

Busca lexical (BM25, o algoritmo clássico de ranking por frequência de termos) não tem esse problema. Ela trata CVE-2024-1234 como uma string literal e só retorna documentos que contêm exatamente aquele token. É determinística, rápida e não precisa de GPU.

A fraqueza do BM25 é o inverso: sem sinônimos, sem tolerância a variações. "Cancelar assinatura" não encontra "encerrar contrato". Para linguagem natural, ele perde feio para embeddings.

Nenhuma das duas abordagens é superior em todos os cenários. A resposta certa é executar ambas em paralelo e fundir os resultados, isso é busca híbrida.

A mecânica é simples: você dispara duas buscas em paralelo, uma vetorial, uma lexical, e cada uma retorna uma lista ranqueada de chunks. O desafio é fundir essas listas em uma só, já que os scores são incomparáveis (cosine similarity vs. BM25 score).

A técnica mais usada na prática é Reciprocal Rank Fusion (RRF). A ideia é elegante: em vez de normalizar scores (o que é frágil), você usa apenas a posição de cada documento nas listas.

A fórmula é:

RRF(doc) = Σ 1 / (k + rank_i(doc))

Onde k é uma constante (tipicamente 60) e rank_i é a posição do documento na lista i. Um documento que aparece em 3º lugar na busca vetorial e em 5º no BM25 vai ter um score RRF alto. Um documento que só aparece em uma das listas vai ter score menor.

O OpenSearch Serverless e o OpenSearch Service suportam busca híbrida com RRF nativamente, você configura o hybrid query type e define os pesos de cada sub-query. O Amazon Bedrock Knowledge Bases também expõe essa opção no console e via API.

Um parâmetro importante é o peso relativo entre busca vetorial e lexical. Não existe valor universal: depende do seu domínio. Para documentação técnica com muitos códigos e siglas, eu dou mais peso ao BM25. Para FAQ em linguagem natural, mais peso ao vetorial. Comece 50/50 e ajuste com base nos resultados de avaliação (aula 08).

Busca híbrida melhora o recall, você recupera mais chunks relevantes. Mas o ranking ainda é imperfeito. O RRF não sabe por que a pergunta foi feita; ele só sabe que um chunk apareceu bem em duas listas.

O reranker resolve isso. Ele é um cross-encoder: recebe a query e cada chunk juntos como entrada e produz um score de relevância real. Diferente do embedding (que vetoriza query e documento separadamente), o cross-encoder lê os dois ao mesmo tempo e pode capturar dependências sutis, por exemplo, que a resposta à pergunta está na terceira frase do chunk, não na primeira.

O padrão de uso é: recupere muitos candidatos (20, 50, até 100 chunks) com busca híbrida, depois passe tudo pelo reranker e fique com os top-3 ou top-5. Isso funciona porque rerankers são caros por chamada mas você os usa uma vez por query, sobre um conjunto pequeno.

Na AWS, o caminho mais direto é o Cohere Rerank disponível via Amazon Bedrock. Você passa a query e a lista de chunks, recebe de volta os índices reordenados com scores. A integração com o Knowledge Bases ainda é manual neste fluxo, você chama o reranker depois do retrieve e antes de montar o prompt.

Um detalhe importante: rerankers têm um limite de tokens por documento. Chunks muito longos (da aula 03) vão ser truncados. Se você usa chunking de 1024 tokens, verifique o limite do modelo de reranking, geralmente 512 tokens por passagem é o máximo seguro.