Anthropic Contextual Retrieval

01 · O PROBLEMA

Por que o RAG tradicional falha em achar a informação certa

Para ser útil num contexto específico, um modelo de IA costuma precisar de acesso a conhecimento de fundo. A solução usual é o RAG: recuperar informação relevante de uma base e acrescentá-la ao prompt do usuário.

O artigo da Anthropic aponta o limite dessa abordagem: o RAG tradicional remove contexto ao codificar a informação, e isso muitas vezes faz o sistema deixar de recuperar o que estava na base.

Antes de montar qualquer pipeline, vale lembrar a alternativa mais simples: se a base tem menos de 200 mil tokens, o artigo diz que dá para colocá-la inteira no prompt, sem RAG.

02 · RAG TRADICIONAL

Embeddings, busca lexical e fusão

O RAG tradicional começa quebrando a base em trechos de no máximo algumas centenas de tokens. Um modelo de embeddings converte cada trecho num vetor que codifica significado, e os vetores ficam num banco vetorial que permite busca por similaridade semântica.

Embeddings captam relações semânticas, mas podem perder correspondências exatas. Por isso entra a busca lexical: BM25 é uma função de ranking baseada em correspondência de palavras e frases, especialmente eficaz para consultas com identificadores únicos ou termos técnicos. Numa busca por um código de erro específico, um embedding pode achar conteúdo sobre códigos de erro em geral e deixar passar o trecho exato.

Na sequência, os resultados das duas buscas são combinados e deduplicados com técnicas de fusão de ranking, e os melhores K trechos são adicionados ao prompt para gerar a resposta.

03 · A IDEIA

Dar de volta a cada trecho o contexto que ele perdeu

O defeito está no próprio trecho. Num exemplo do artigo, um trecho sozinho não diz a qual empresa nem a qual período se refere, o que dificulta recuperar a informação certa e usá-la bem.

O método, chamado Contextual Retrieval, tem duas subtécnicas: Contextual Embeddings e Contextual BM25. Ele antepõe um contexto específico a cada trecho antes de gerar os embeddings e antes de montar o índice BM25.

No exemplo do artigo, o trecho transformado começa dizendo que vem de um documento da SEC sobre o desempenho da ACME no segundo trimestre de 2023.

O artigo observa que anotar à mão milhares ou até milhões de trechos seria trabalho demais, e por isso usa um modelo. O prompt entrega o documento inteiro e o trecho a ser situado e pede um contexto conciso que explique o trecho à luz do documento. O resultado, geralmente de 50 a 100 tokens, é anteposto ao trecho antes dos embeddings e do índice BM25.

O artigo também registra o que não funcionou: acrescentar resumos genéricos do documento aos trechos deu ganhos muito limitados.

04 · CUSTO E CACHE

Indexação com prompt caching

Gerar um contexto por trecho tem um custo: o prompt entrega o documento inteiro junto com cada trecho. O diagrama mostra o caminho de indexação e onde o cache de prompt entra.

1. A base é quebrada em trechos curtos, e um trecho isolado pode não dizer a qual empresa nem a qual período se refere.

2. Para cada trecho, o gerador de contexto envia a um modelo o documento inteiro e o trecho, e recebe de volta um contexto conciso que situa o trecho no documento.

3. O documento inteiro é carregado no cache de prompt uma vez e depois apenas referenciado, em vez de reenviado a cada trecho.

4. O contexto é anteposto ao trecho, e o texto resultante alimenta tanto o modelo de embeddings quanto o índice lexical.

5. Os dois índices passam a guardar o trecho já contextualizado.

O artigo diz que o prompt caching reduz a latência em mais de 2x e o custo em até 90%. Com as premissas do texto (trechos de 800 tokens, documentos de 8 mil tokens, 50 tokens de instrução e 100 tokens de contexto por trecho), o custo único de gerar os trechos contextualizados é de 1,02 dólar por milhão de tokens de documento.

05 · RESULTADOS

O que cada camada ganha

A métrica do artigo é 1 menos recall@20: a fração de documentos relevantes que não aparece entre os 20 primeiros trechos recuperados.

O artigo relata que contextualizar melhorou o desempenho em toda combinação de embedding e fonte avaliada, que Voyage e Gemini tiveram os melhores embeddings entre os testados, e que passar 20 trechos ao modelo foi mais eficaz do que passar 10 ou 5.

O resumo do artigo é que o método pode reduzir as falhas de recuperação em 49% e, combinado com reranking, em 67%.

06 · RERANKING E CONSULTA

Do índice à resposta, com um filtro final

O último passo é o reranking. A recuperação inicial traz os candidatos potencialmente relevantes (no experimento, os 150 primeiros); um modelo de reranking dá nota a cada trecho e seleciona os K melhores (20 no experimento). Os testes usaram o reranker da Cohere.

1. A pergunta do usuário chega ao serviço de busca.

2. O serviço consulta o índice vetorial, por similaridade semântica, e o índice lexical, por correspondência de palavras.

3. Os resultados das duas buscas são combinados e deduplicados com técnicas de fusão de ranking.

4. Um modelo de reranking dá nota a cada candidato; no experimento, partiu-se de 150 candidatos e ficaram 20.

5. Os trechos escolhidos são adicionados ao prompt do modelo gerador, que escreve a resposta.

O reranking não é de graça: como acrescenta um passo em tempo de execução, adiciona um pouco de latência. Há um trade-off entre rerankear mais trechos, para melhor desempenho, e menos, para menor latência e custo.

Os próprios autores deixam o ajuste para quem implanta: recomendam experimentar configurações no seu caso de uso, sugerem testar o número de trechos e notam que prompts de contextualização sob medida para o domínio podem dar resultados ainda melhores.