Sistemas RAG quebram com dados reais: o culpado é o retrieval, não o modelo

Um pipeline RAG parece mágica: carregou documentos, particionou em chunks, gerou embeddings, conectou um banco de dados vetorial. Faz uma pergunta — o modelo responde com confiança e em detalhes. Mostra para o cliente, ele fica impressionado. Mas depois o teste real com perguntas reais começa, e descobre-se que o sistema erra metade delas.

O Gargalo do RAG

Em perguntas reais, o sistema frequentemente responde incorretamente. Encontra o documento errado por completo, ou encontra o documento correto mas extrai o chunk de texto errado, ou não recupera nada relevante e o modelo alucina com confiança. Parece que o problema está no modelo. Na verdade, a recuperação é culpada.

GPT-4 e Claude respondem perfeitamente se recebem o contexto correto. Se o contexto está errado — alucinação é garantida, não importa quão bom seja o modelo. O modelo responde apenas tão bem quanto o contexto fornecido a ele.

O problema não está nos modelos. O problema está na recuperação — em como procuramos por chunks de documentos relevantes do seu banco de dados. Este é o gargalo por onde passa todo o pipeline RAG. Se a recuperação der ao modelo o contexto errado, tudo mais é tempo e dinheiro desperdiçados.

"O modelo responde apenas tão bem quanto o contexto fornecido a ele."

Quando a Recuperação Falha

A recuperação pode falhar por dezenas de razões. Aqui estão as mais comuns:

• Particionamento muito grande ou muito pequeno. Um chunk de 512 palavras pode capturar contexto vizinho em vez da peça necessária. Uma pergunta sobre política de devolução, o chunk contém descrição de tabela de tamanhos
• Embeddings gerados para dados em inglês, mas a pergunta está em russo. A distância semântica entre o vetor da pergunta e os vetores dos documentos é enorme, sem correspondências
• A pergunta é reformulada de tal forma que o vetor de seu embedding não corresponde aos vetores no banco de dados. Você procura por "devolver pedido", documentos contêm "devolução de produto" — semântica diferente
• Documento relevante encontrado em 8º lugar em 10, mas o modelo recebeu apenas os 5 primeiros resultados. O contexto necessário simplesmente não cai dentro da janela de visibilidade
• Índice preenchido com duplicatas e ruído. Muitos chunks irrelevantes empurram a informação correta para fora dos resultados

Cada um desses problemas leva ao mesmo resultado: o modelo alucina em vez de fornecer a resposta correta.

O Custo da Recuperação

Otimizar a recuperação não é um hobby para entusiastas. É trabalho real: uma ou duas semanas gastas por um desenvolvedor em análise revelarão que o sistema está 30-40% abaixo da precisão esperada. O motivo não é o modelo, mas que a recuperação está procurando incorretamente. Em projetos reais, essa é uma perda enorme: tempo gasto em RAG, dinheiro gasto em infraestrutura, e o sistema não funciona porque os vetores dos documentos não correspondem aos vetores das perguntas.

O Que Isso Significa

RAG funciona apenas se a recuperação funciona. Sem ela, até mesmo o melhor modelo estará errado. Isso significa que antes de lançar RAG em produção, você precisa investir tempo sério em otimizar a busca, testar em dados reais, e depois melhorar iterativamente o pipeline de recuperação.