EstevezAlvarez
Engenharia de RAG

RAG 3: contexto útil, busca híbrida e reranking

O que eu aproveitaria de Contextual Retrieval para combinar buscas e reordenar resultados, e o que revisaria antes de usar em produção.

Neste artigo

Uma frase como “o valor aumentou em relação ao ano anterior” perde utilidade quando é separada de sua entidade, período e tabela. O método contextual da Anthropic acrescenta uma explicação específica do trecho antes de indexá-lo. A ideia faz sentido, mas minha primeira pergunta seria se esses dados já existem como cabeçalhos e metadados verificáveis. Eu não pagaria para gerar o que consigo extrair com confiabilidade.

Três representações para uma comparação justa

Eu compararia o texto original, o texto com contexto extraído e o texto com contexto gerado. Na terceira variante guardaria separadamente a explicação, o modelo, o prompt, a versão do documento e seu estado de revisão. O gerador receberia apenas o conteúdo necessário do documento autorizado; não as respostas do conjunto de teste. Uma explicação inventada pode melhorar uma correspondência aparente e piorar a fidelidade.

search_text = verified_heading + "\n" + original_text
# Optional experimental variant:
contextual_search_text = generated_context + "\n" + original_text
# Citations always resolve to the original source.
cache_key = hash(document_version, chunk_id, model_version, prompt_hash)

Este é um pseudocódigo de desenho. O prefixo ajuda a buscar; não adquire autoridade documental. Ao responder, a citação precisa resolver para a passagem original e sua localização. Se o contexto gerado afirma um período ou uma entidade que a fonte não sustenta, marco o enriquecimento como inválido e preservo a possibilidade de recuperar sem esse prefixo.

Combinar sinais sem somar escalas incompatíveis

Eu manteria BM25 como referência para identificadores e termos exatos, junto com busca densa para similaridade semântica. Compararia cada recuperador separadamente antes de combiná-los. RRF combina posições; uma soma de pontuações exige calibração. Depois removeria duplicatas e testaria reranking sobre um conjunto limitado de candidatos. O orçamento de tokens e a latência fazem parte da comparação.

Eu não fixaria vinte passagens como regra universal. Mais candidatos podem aumentar a recuperação e também introduzir ruído, versões incompatíveis e custo. Ajustaria esses parâmetros no desenvolvimento e congelaria a escolha antes do teste. Para perguntas que exigem várias evidências, mediria se chegou o conjunto necessário, não apenas algum trecho relacionado.

O que eu revisaria no notebook

O cookbook descreve nove bases de código e 248 consultas. Sua função chamada pass_at_n calcula a fração de chunks de referência recuperados por consulta e depois a média: com várias referências não é um sucesso binário. Além disso, compara texto exato e mantém no denominador consultas cujas referências não conseguiu localizar. Na minha implementação eu validaria primeiro as anotações e usaria identificadores estáveis.

As reduções de falha divulgadas no artigo são relativas, dependem de sua avaliação e não equivalem à exatidão das respostas. Também não trataria preços ou nomes de modelos de uma página de 2024 como contrato atual. O critério para adotar contexto gerado seria um benefício local útil sobre o contexto extraído, sem degradar citações, permissões ou custo acordado.

Artigo de engenharia da Anthropic

Cookbook: implementação e avaliação

Baixar scripts, manifesto e documentação da revisão

Voltar ao índice do blog