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
