Sistemas RAG não são mágica, você só precisa fazer o trabalho.

“`html

O RAG não está te decepcionando. Você está decepcionando o RAG.

Dois meses atrás, alguém me enviou seu “assistente de IA movido a RAG” e perguntou por que ele continuava alucinado.
Eles me contaram com orgulho que usaram “embeddings de última geração” e “um potente banco de dados vetorial”.
Aconteceu que eles estavam dividindo PDFs de 40 páginas em pedaços de 200 caracteres e armazenando-os sem metadados.
A recuperação era basicamente uma roleta com etapas extras.

Isso acontece com frequência. As pessoas tratam o RAG como uma caixa de verificação: “Sim, adicionamos RAG para que não alucine.”
Não é assim que isso funciona. A geração aumentada por recuperação não é um remédio mágico.
É um pipeline muito exigente que pune a preguiça em cada passo: ingestão, recuperação e prompting.

Eu construo sistemas de agentes o dia todo, e vou te dizer a mesma coisa que digo às equipes de produto:
se sua recuperação é ruim, seu “agente” é apenas um autocomplete caro com boas vibrações.

O que RAG realmente é (não a versão do LinkedIn)

RAG é simples no papel:

• Você armazena seus próprios dados em algum lugar (geralmente um DB vetorial).
• Você incorpora consultas de usuários e documentos em vetores.
• Você puxa as informações mais próximas e as fornece ao modelo.

É isso. O truque todo é: “Dar ao modelo contexto relevante no momento certo.”
O problema é que cada uma dessas palavras esconde uma bagunça:

• “Relevante” – depende da sua tarefa, usuário e nível de detalhe.
• “Contexto” – que formato, quanto, que metadados, qual fonte?
• “Momento certo” – você recupera uma vez, várias vezes ou em um loop?

Então, quando alguém me diz “construímos RAG com Pinecone e OpenAI,” é como dizer
“construímos um carro com metal e gasolina.” Legal. Ele vira? Para? Explode?

Os três lugares onde as pessoas costumam errar em RAG

Vamos passar pelas feridas auto-infligidas mais comuns que vejo ao depurar os sistemas de outras pessoas.

1. Dividindo como um maníaco

Se seus pedaços estiverem errados, tudo a montante sofre. A maioria das pessoas ou:

• Faz pedaços muito pequenos: o modelo vê fragmentos sem contexto, ou
• Faz pedaços muito grandes: você armazena metade de um capítulo e depois não consegue encaixar o suficiente no contexto.

Recentemente, vi uma equipe dividir um documento de política de 120 páginas em pedaços de tamanho fixo de 256 tokens.
Sem sobreposição, sem respeito por títulos, nada. Quando registramos a recuperação para a consulta:
“Qual é nossa política de reembolso para contratos anuais empresariais?” nós obtivemos:

• Um pedaço com “reembolsos” mas para contas de consumidor
• Outro pedaço sobre “contratos empresariais” mas em uma seção diferente
• Nada que realmente descrevesse a junção desses dois

Então o modelo os uniu e inventou confiantemente uma política híbrida que não existia.
Isso não é “alucinação”. Isso é você alimentando-o com peças de quebra-cabeça desalinhadas.

Padrão melhor:

• Divida por estrutura sempre que possível: seções, títulos, grupos de itens.
• Adicione sobreposição (como 10–20%) para que as fronteiras não cortem o significado pela metade.
• Armazene metadados: título da seção, tipo do documento, data, versão, fonte.

Ferramentas como langchain-text-splitters ou llama-index podem ajudar, mas não vão pensar por você.
Você ainda precisa decidir o que é uma “unidade de significado” em seu domínio.

2. “Apenas use embeddings” como estratégia de recuperação

Outro favorito: as pessoas enfiam tudo em um banco de dados vetorial e acham que está feito.
Sem filtros. Sem backup de palavras-chave. Sem reclassificação. Depois elas reclamam que embeddings “não funcionam para código”
ou “não funcionam para tickets de suporte”.

Eu trabalhei em um assistente de suporte onde testamos diferentes configurações em 500 tickets reais do Zendesk.
A recuperação apenas com embeddings (OpenAI text-embedding-3-large, top-k=5) nos deu o artigo certo entre os top 5 cerca de 62% do tempo.
Adicionar uma simples pesquisa baseada em termos (BM25) e depois reclassificar com um cross-encoder aumentou isso para 84%.
Mesmo conteúdo. Mesmo modelo. Apenas uma lógica de recuperação melhor.

Você não precisa de uma pilha sofisticada para fazer isso:

• Use um índice híbrido (a maioria dos backends de busca modernos suporta isso: Elastic, OpenSearch, Vespa, etc.).
• Filtre por metadados primeiro: produto, versão, idioma.
• Reclassifique seus 20–50 principais candidatos com um cross-encoder ou um passo de LLM “escolha os 5 melhores”.

E pelo amor de tudo que é sã, registre suas consultas e documentos recuperados.
Não fique apenas olhando para uma pontuação de relevância agregada. Veja exemplos reais onde falha.

3. Promptando como se o modelo fosse psíquico

Seu prompt é parte do sistema RAG. Se o modelo não entender como usar o contexto,
ele ignorará tudo e inventará coisas.

Bons prompts de RAG fazem algumas coisas maçantes mas críticas:

“““html

• Explique qual é o contexto e de onde ele veio.
• Diga ao modelo para citar ou referenciar itens no contexto, não seu próprio treinamento.
• Defina o que fazer quando a resposta não está no contexto (dizer “Não sei”).
• Forneça regras de formatação explícitas (como esquemas JSON ou marcadores).

Aqui está uma versão simplificada de um prompt de sistema que enviamos para produção em janeiro de 2025 para um chatbot de conformidade:

• “Você responde perguntas apenas usando os documentos fornecidos.”
• “Se você não puder responder a partir deles, diga que não sabe e sugira qual documento pode ajudar.”
• “Sempre cite o título do documento e o ID da seção entre parênteses.”

Essa única mudança reduziu as respostas de “nonsense confiante” em cerca de 40% em nossas avaliações manuais.
Mesma pilha de recuperação. Apenas melhores instruções.

RAG mais agentes: onde fica divertido e frágil

Os agentes tornam isso mais interessante porque agora você não está apenas respondendo a uma pergunta.
Você está orquestrando múltiplos passos: buscar, ler, decidir, agir, talvez buscar novamente.

As pessoas continuam conectando ferramentas como:

• Ferramenta 1: “search_kb(query) → top 5 docs”
• Ferramenta 2: “call_api(payload) → result”

…e então esperando que o agente saiba magicamente quando buscar novamente ou refinar a consulta.
Spoiler: ele não sabe. Ele apenas segue padrões.

Duas correções simples melhoram bastante as configurações de agente + RAG:

• Expose incerteza. Deixe o agente ver as pontuações de recuperação, não apenas texto bruto.
• Dê a ele uma ferramenta “refine_search”. Uma ferramenta cujo propósito é literalmente: “reescrever a consulta se os resultados não forem bons.”

Quando adicionamos ambos em um sistema de assistente de CRM no final de 2024, o sucesso da tarefa em consultas de múltiplos saltos
(como “Encontre todas as contas onde violamos o SLA nos últimos 90 dias e resuma os padrões”)
saltou de 47% para 71%. Mesmo modelo. Mesmo documentos. Melhor ferramentas para o agente em torno do RAG.

Pare de adivinhar. Comece a avaliar.

A principal diferença entre equipes que fazem o RAG funcionar e equipes que não fazem é chata:
as boas equipes avaliam. Constantemente.

No mínimo, você quer:

• Avaliações de recuperação: Para um conjunto de consultas, conseguimos recuperar algo que realmente contém a resposta?
  Anote de 50 a 100 exemplos manualmente. Sim, manualmente. Você está construindo um sistema, não vibrações.
• Avaliações de qualidade de resposta: A resposta final está correta, fundamentada no contexto e completa?
  Você pode usar outro modelo como juiz, mas verifique com humanos.
• Verificações de alucinação: A resposta incluiu afirmações não suportadas pelo contexto?

Não persiga o “perfeito.” Persiga “sabemos exatamente como e onde falha.”
Uma vez que você tenha isso, consertar o RAG se torna trabalho de engenharia em vez de bruxaria.

Perguntas Frequentes

Quantos fragmentos devo recuperar para cada consulta?

Comece com 5–10 e meça. Se seus fragmentos forem menores (como 200–400 tokens), você pode ir mais alto.
Fique de olho na sua janela de contexto: você quer espaço para instruções e a consulta do usuário, não apenas uma parede de texto recuperado.

Qual modelo de embedding e banco de dados vetor devo usar?

Use algo chato e bem suportado primeiro. O text-embedding-3-small da OpenAI ou
o embed-english-v3.0 da Cohere são bons para a maioria dos aplicativos.
Para armazenamento, qualquer coisa que possa fazer pesquisa vetorial + filtros de metadados + pesquisa híbrida (Elastic, Weaviate, Qdrant, etc.) é boa o suficiente.
Sua lógica de recuperação é muito mais importante do que o logotipo na caixa.

Posso pular o RAG e apenas ajustar o modelo nos meus documentos?

Você pode, mas para a maioria dos casos de negócios, é uma troca ruim. O ajuste fino é estático e doloroso de atualizar.
O RAG permite que você mude as respostas atualizando documentos, não pesos.
Eu só recomendo ajuste fino para estilo, formatação ou quando seu domínio é extremamente nichado e relativamente estável.

“`

🕒 Published: April 5, 2026