Por que a Busca de Similaridade Ingênua Destruirá Seu Agente RAG (E O Que Fazer em Vez Disso)

A maioria das implementações de RAG que vejo em produção usa busca de similaridade ingênua: incorpora a consulta, encontra os vetores mais próximos, os coloca no contexto, gera. Funciona em demonstrações. Falha em produção.

Veja por que — e aqui está o padrão que eu adotei após rodar agentes autônomos 24/7.

O Problema Com RAG Ingênuo

Considere o que a similaridade do cosseno realmente mede: ela encontra pedaços cuja direção de incorporação é semelhante à direção de incorporação da sua consulta. Isso parece bom até você perceber:

1. Desajustes de palavras-chave. Se um usuário pergunta "qual é nossa política de reembolso?" mas seus documentos dizem "política de devolução," a similaridade do cosseno pode classificar um documento completamente irrelevante sobre "atualizações de política" mais alto porque aconteceu de compartilhar tokens comuns no espaço de incorporação.

2. Sem diversidade. Você pode facilmente obter 5 pedaços quase idênticos da mesma seção do documento — todos pontuando 0.87 — quando você precisava de 5 diferentes perspectivas sobre o tópico.

3. Sem ponderação de frescor. Um documento de política de 2 anos atrás e um de semana passada classificam-se identicamente.

4. Alucinação silenciosa. Quando a recuperação retorna resultados de baixa qualidade, o LLM não diz "não consegui encontrar isso" — ele alucina. E você não saberá até que alguém reclame.

A pior parte: suas avaliações provavelmente parecem boas. RAGAS pode pontuar 0.8 no seu conjunto de testes. Então a produção chega e os casos extremos te matam.

O Padrão Que Realmente Funciona

Aqui está o que eu uso para agentes de produção. Você não precisa de tudo isso — comece com busca híbrida, adicione o resto à medida que seu uso cresce.

Nível 1: Busca Híbrida (Densa + Esparsa)

Isso é inegociável para qualquer sistema de produção. Vetores densos capturam similaridade semântica; BM25 captura correspondências exatas de palavras-chave. Nenhum deles sozinho é suficiente.

A combinação via Reciprocal Rank Fusion (RRF):

def hybrid_retrieve(query, k=10, final_k=5, rrf_k=60):
    query_vec = embed(query)
    dense_results = vector_store.similarity_search(query_vec, k=k)
    sparse_results = bm25_index.search(query, k=k)

    scores = {}
    for rank, result in enumerate(dense_results):
        scores.setdefault(result['id'], {'data': result, 'rrf': 0})
        scores[result['id']]['rrf'] += 0.7 * (1.0 / (rrf_k + rank + 1))

    for rank, result in enumerate(sparse_results):
        scores.setdefault(result['id'], {'data': result, 'rrf': 0})
        scores[result['id']]['rrf'] += 0.3 * (1.0 / (rrf_k + rank + 1))

    ranked = sorted(scores.values(), key=lambda x: x['rrf'], reverse=True)
    return ranked[:final_k]

A divisão 70/30 densa/esparsa funciona bem para a maioria dos domínios. Ajuste para esparsa (40/60) para conteúdo técnico com terminologia exata como códigos de produtos ou nomes de API.

Nível 2: Compressão Contextual

Uma vez que você recupera seus pedaços, não apenas os coloque todos no contexto. Peça ao LLM para extrair apenas as partes relevantes:

def compress_chunk(query, chunk_text, llm):