RAG não é um chatbot que lê PDF

Quando uma empresa diz que quer “um chatbot que lê nossos PDFs”, o pedido parece simples: subir arquivos, conectar um modelo e responder perguntas. Na prática, o que determina se a solução funciona quase nunca está no modelo — está em tudo o que acontece antes dele responder.

RAG (Retrieval-Augmented Generation) é uma arquitetura de recuperação de informação combinada com geração de texto. Tratar isso como “upload de documentos” é o caminho mais rápido para uma solução que soa bem em demonstração e falha no uso real.

1. O que realmente acontece em uma solução RAG

Entre a pergunta do usuário e a resposta existe uma cadeia: interpretação da pergunta, busca na base, seleção dos trechos, montagem do contexto, geração e validação. Cada etapa pode degradar o resultado sem gerar erro visível.

O sintoma clássico é uma resposta fluente, bem escrita e incompleta. Ela não parece um bug — parece uma resposta. Por isso o desenho do produto precisa incluir como identificar quando o sistema respondeu com base insuficiente.

2. Chunking muda o que o sistema consegue recuperar

Documentos precisam ser divididos em trechos para serem indexados. Essa divisão define o que é recuperável. Trechos muito pequenos perdem contexto e separam uma regra da sua exceção; trechos muito grandes trazem ruído e diluem a busca.

Em documentos normativos, técnicos ou contratuais, a estrutura importa: itens, subitens, tabelas e listas carregam significado. Ignorar a hierarquia do documento costuma ser a causa raiz de respostas que “esquecem” uma condição importante.

3. Recuperação relevante não significa recuperação completa

Uma busca vetorial retorna trechos semanticamente próximos da pergunta. Isso não garante que todos os trechos necessários para responder foram recuperados. Relevância e completude são coisas diferentes.

Perguntas que dependem de condições, prazos ou exceções normalmente exigem mais de um trecho. Uma estratégia útil é verificar, antes de gerar, se o contexto recuperado contém os elementos mínimos para responder — e, se não contiver, buscar novamente ou assumir a limitação.

4. O modelo só responde com a qualidade do contexto que recebe

Trocar o modelo raramente resolve um problema de recuperação. Se o trecho certo não chegou ao contexto, nenhum modelo vai adivinhá-lo — e os melhores modelos tendem a preencher lacunas com texto plausível, o que piora o diagnóstico.

Também faz parte do produto definir o formato da resposta: se deve citar a origem, em que nível de detalhe, e o que fazer quando fontes divergem entre si.

5. Guardrails e negativa segura também fazem parte do produto

Em domínios sensíveis, saber não responder é requisito, não limitação. Regras claras de negativa segura — responder apenas com base na fonte, indicar quando a informação não está disponível, encaminhar para uma pessoa quando necessário — evitam o pior cenário: uma resposta errada e confiante.

Isso precisa ser escrito como comportamento esperado, com critérios de aceite, e não deixado a cargo de instruções genéricas no prompt.

6. Como avaliar um RAG na prática

Avaliação por impressão não escala. O mínimo viável é um conjunto de perguntas reais com respostas esperadas, revisado por quem conhece o domínio, e a separação de duas medidas: a recuperação trouxe os trechos certos? e a resposta usou corretamente o que foi trazido?

Vale incluir também perguntas fora do escopo, para verificar se o sistema recusa quando deve, e casos com exceções, que são os que mais revelam falhas de chunking.

Conclusão

Um bom RAG é um sistema de recuperação e geração, não um LLM com documentos anexados. A maior parte do ganho de qualidade vem de decisões de produto: como o conteúdo é estruturado, o que é recuperado, o que é considerado contexto suficiente e o que o sistema faz quando não sabe.

Se você busca uma introdução à arquitetura e aos seus componentes, consulte o guia O que é RAG? Entenda Retrieval-Augmented Generation.

Texto autoral, baseado em aprendizados de projetos reais, com informações sensíveis removidas.