Contextual Retrieval: como reduzir falhas de RAG em até 67%

Resposta atômica: Contextual Retrieval é técnica publicada pela Anthropic que adiciona contexto ao chunk antes de gerar embeddings e BM25 index. Reduz falhas de retrieval em 49%. Combinado com reranker no top-20, a redução chega a 67%. Aplicável a RAG em produção sem mudar modelo principal — é melhoria na ingestão, não no LLM.

O problema com RAG tradicional

Pipeline RAG padrão:

1. Chunka documento em pedaços de N tokens
2. Gera embedding de cada chunk
3. Indexa em vector DB
4. Em query, busca top-K por similaridade
5. Passa contexto para LLM gerar resposta

O problema: chunks são lidos fora de contexto. Um chunk diz "o limite anual é R$ 30k". Sem contexto, embedding não captura: limite de quê? Para qual plano? Em qual ano?

Resultado: chunks relevantes não são recuperados, ou irrelevantes são recuperados, e o LLM responde mal — não porque é ruim, mas porque o contexto está errado.

A solução: enriquecer chunks no momento da ingestão

Contextual Retrieval adiciona um passo:

chunk_original: "O limite anual é R$ 30k para a categoria sênior."

[contextualizar com LLM antes de indexar]

chunk_contextualizado: "[Política de viagem 2026 — categoria sênior]
O limite anual é R$ 30k para a categoria sênior."

A contextualização é gerada por LLM lendo o documento inteiro e produzindo, para cada chunk, uma frase de contexto que precede o chunk original.

Em seguida:

• Embedding é gerado do chunk contextualizado
• BM25 index é construído sobre o chunk contextualizado

Resultado: tanto busca dense quanto sparse capturam significado completo do trecho.

Os números

Da pesquisa publicada:

• Contextual Embeddings sozinho: reduz failed retrieval em ~35%
• Contextual BM25 sozinho: reduz failed retrieval em ~32%
• Ambos combinados (Contextual Retrieval): reduz em ~49%
• Combinado com reranking de top-20: reduz em ~67%

Para RAG em produção com volume material, redução de 67% em falhas de retrieval é mudança de patamar — sai de "às vezes erra" para "raramente erra".

Reranking como segunda etapa

Reranking é técnica complementar:

1. Retrieve inicial busca top-150 chunks (rápido, recall alto)
2. Reranker (modelo separado, cross-encoder) reorganiza os 150 pela relevância exata
3. Top-20 reranked vai para LLM

A diferença de qualidade entre retriever (bi-encoder) e reranker (cross-encoder) é grande: reranker compara query × chunk diretamente, capturando nuance que embeddings perdem.

Trade-off: reranker adiciona latência (50-200ms tipicamente) e custo. Para queries críticas, vale. Para volume alto com low-stakes, pode pular.

Quando aplicar

Contextual Retrieval é recomendado quando:

• Documentos têm contexto que muda significado dos chunks (políticas, contratos, papers)
• Chunks são curtos (sub-500 tokens)
• Custo de ingestão é aceitável (não é freshness sub-segundo)

Pode não valer quando:

• Chunks já são self-contained (FAQ entries, definições de glossário)
• Ingestão precisa ser instantânea (notícias, chat)
• Budget de inferência na ingestão é apertado

Implementação prática

# 1. Chunk
chunks = chunk_document(doc, size=400)

# 2. Gerar contexto via LLM (com prompt caching)
context_prompt = """
Documento completo:
{full_document}

Para o chunk abaixo, gere frase curta de contexto que precede:
{chunk}
"""

contextualized = []
for chunk in chunks:
    context = llm.complete(
        context_prompt.format(full_document=doc, chunk=chunk),
        cache_control={"type": "ephemeral"},
    )
    contextualized.append(f"[{context}]\n{chunk}")

# 3. Embed e indexar
embeddings = embedder.embed_batch(contextualized)
vector_db.upsert(embeddings, contextualized)
bm25_index.build(contextualized)

Prompt caching é crítico — o documento completo aparece em cada chunk processado. Sem caching, o custo explode.

Pegadinhas

1. Contexto muito longo dilui o chunk. Mantenha contexto em 1-2 frases.

2. LLM hallucina contexto. Em documentos longos, pode inventar atributos. Use temperature 0 e prompt restritivo.

3. Re-ingestão é cara. Mudou template de contexto? Tem que re-processar tudo. Versione o template.

4. Reranker top-K limit. Reranker tipicamente lida bem com top-100, mal com top-1000.

A leitura estratégica

RAG está saindo da fase "qualquer chunking + qualquer embedder serve" para "engenharia de retrieval importa tanto quanto engenharia de prompt".

Times que tratam retrieval como problema engenheirado terão produtos com qualidade audível superior. Em SaaS B2B onde a precisão de resposta é critério de compra, é vantagem competitiva real.

Roteiro de adoção

1. Estabeleça baseline — mensure retrieval failure rate em queries reais
2. Adicione contextual embeddings — mede ganho
3. Adicione contextual BM25 — mede ganho composto
4. Adicione reranker no top-20 — mede ganho final
5. Eval contínuo — golden dataset, métricas, regression gate

Cada passo isolado é melhoria mensurável. Cumulativo, é mudança de patamar.

Próximo passo

Para times com RAG em produção e qualidade de retrieval como bottleneck — discovery técnico cobre auditoria do pipeline atual, implementação de contextual retrieval, escolha de reranker e setup de eval.

Fontes citadas

1. Contextual Retrieval in AI Systems — Anthropic · acessado em 2026-05-19
2. Rerankers and Two-Stage Retrieval — Pinecone · acessado em 2026-05-19
3. Hybrid search — Pinecone Docs · acessado em 2026-05-19