Você tem um LLM excelente, mas ele não sabe nada sobre os seus documentos. Pedir para ele responder sobre a documentação interna da empresa, os contratos do cliente ou o histórico de atendimento resulta em uma das duas coisas: alucinação ou resposta vaga demais para ser útil.
Não é falha do modelo. É falta de contexto.
Trabalhei com esse problema em produção numa fintech, e a abordagem que funciona na maioria dos casos tem nome: RAG, que significa Retrieval-Augmented Generation. Em vez de treinar o modelo nos seus dados, você conecta ele a uma base de documentos que pode ser consultada em tempo real. O resultado é um sistema que responde com base nos seus dados, não nos dados de pré-treino do modelo.
Neste artigo, você vai entender como RAG funciona na prática, quando ele resolve o problema e o que observar para saber se está funcionando bem antes de colocar em produção.
O que é RAG e por que funciona
RAG é uma arquitetura que conecta dois componentes: um sistema de busca e um modelo de linguagem. Quando você faz uma pergunta, o sistema primeiro recupera os trechos de documentos mais relevantes para aquela pergunta, e então passa esses trechos junto com a pergunta para o modelo gerar a resposta.
O modelo não precisa “saber” nada de antemão. Ele recebe o contexto no momento da consulta e usa aquele contexto para responder. Isso resolve o problema de conhecimento desatualizado ou específico sem precisar retreinar nem fazer fine-tuning no modelo.
A vantagem prática é enorme: você pode atualizar os documentos da base sem tocar no modelo. Novos contratos, nova documentação técnica, atualizações de política interna, tudo entra na base e fica disponível imediatamente.
RAG versus fine-tuning: quando usar cada um
Essa confusão aparece toda vez que alguém começa a trabalhar com LLMs em produção. Os dois parecem resolver o mesmo problema, mas não resolvem.
Fine-tuning muda os pesos do modelo. Você está ensinando o modelo a se comportar diferente, a adotar um estilo específico de resposta, a usar um vocabulário particular. Fine-tuning faz sentido quando você quer mudar o jeito que o modelo escreve ou raciocina, não quando quer que ele conheça seus documentos.
RAG não toca no modelo. Você está adicionando contexto na hora da consulta. Faz sentido quando o objetivo é que o modelo responda com base em informações específicas e atualizáveis. Para a maioria dos casos de uso reais, como documentação interna, base de conhecimento, suporte técnico e análise de contratos, RAG é a escolha correta.
Para aprofundar essa decisão com mais critérios, o artigo sobre fine-tuning versus prompt engineering cobre os cenários de forma mais detalhada.
Como um sistema RAG funciona na prática
O pipeline tem etapas bem definidas, e entender cada uma ajuda a identificar onde está o problema quando o sistema não performa bem.
Ingestão e divisão dos documentos
Primeiro você carrega os documentos. Podem ser PDFs, arquivos de texto, páginas HTML, planilhas, qualquer fonte de informação estruturada ou semiestruturada. Depois divide esses documentos em pedaços menores, o que é chamado de chunking.
O tamanho dos pedaços importa mais do que parece. Pedaços muito pequenos perdem contexto: a frase relevante pode estar no final de um chunk e a explicação no início do próximo. Pedaços muito grandes diluem a informação e dificultam a busca por trechos específicos. Para documentação técnica, pedaços entre 500 e 1000 palavras com sobreposição de 100 a 200 palavras costumam funcionar bem.
Embeddings e armazenamento vetorial
Cada pedaço de documento é convertido em um vetor numérico por um modelo de embedding. Esse vetor captura o significado semântico do texto de uma forma que permite comparar documentos por similaridade de conteúdo, não apenas por palavras em comum.
Os vetores são armazenados em um banco vetorial. Quando você faz uma pergunta, ela também é convertida em vetor e o sistema busca os vetores de documentos mais próximos matematicamente do vetor da pergunta. Esses são os trechos mais semanticamente relevantes para a sua pergunta.
Recuperação e geração da resposta
Os trechos recuperados são passados para o modelo junto com a pergunta original. O modelo lê o contexto fornecido e gera uma resposta baseada naquelas informações. Você pode instruir o modelo a responder apenas com base nos documentos fornecidos e a admitir quando a informação não está disponível.
O que observar para saber se o RAG está funcionando
Essa é a parte que a maioria dos tutoriais pula, e é onde os projetos costumam falhar silenciosamente.
Um sistema RAG pode parecer funcionar bem em demos e falhar em produção por razões que não são visíveis sem monitoramento. As métricas que importam:
- Relevância dos trechos recuperados: os chunks que o sistema retorna são realmente pertinentes à pergunta? Avalie isso manualmente com um conjunto de perguntas representativo antes de colocar em produção
- Fidelidade da resposta: a resposta gerada está baseada no que foi recuperado ou o modelo está completando com informação que não estava nos documentos? Uma forma de checar é pedir ao modelo que cite a fonte de cada afirmação
- Taxa de “não sei”: quando a informação não está na base, o sistema admite ou inventa? Teste com perguntas que você sabe que não têm resposta nos documentos
Para monitoramento em produção com LLMs, o artigo sobre como monitorar custo e latência de LLMs cobre o que observar depois que o sistema está no ar.
Problemas comuns e o que fazer em cada caso
Respostas vagas ou incorretas com frequência
Quase sempre é problema de chunking. Revise o tamanho dos pedaços e a sobreposição entre eles. Teste com perguntas que têm resposta clara nos documentos e veja se os chunks recuperados contêm a informação necessária. Se os chunks certos não estão sendo recuperados, o problema está na busca ou no embedding.
Modelo responde com informações fora dos documentos
Adicione instrução explícita no prompt do sistema: o modelo deve responder exclusivamente com base nos documentos fornecidos e deve dizer claramente quando a informação não está disponível. Modelos bem instruídos seguem esse tipo de restrição de forma confiável.
Busca retorna trechos irrelevantes
Busca puramente semântica tem pontos cegos, especialmente para termos técnicos específicos ou nomes próprios. Considerar busca híbrida, que combina similaridade vetorial com busca por palavras-chave, resolve a maioria desses casos. Filtrar por metadados antes de buscar, como data, categoria ou autor do documento, também ajuda quando a base é heterogênea.
Quando RAG não é suficiente
RAG funciona muito bem para busca de informação pontual e respostas baseadas em trechos específicos. Tem limitações reais que vale conhecer antes de adotar:
- Perguntas que exigem raciocínio sobre o documento inteiro, como sumarização completa ou análise de tendências ao longo de todo um relatório, não funcionam bem com recuperação de trechos. O modelo recebe pedaços, não a visão global
- Documentos altamente estruturados como contratos e planilhas financeiras às vezes precisam de parsing estruturado antes de entrar na base vetorial para preservar a hierarquia da informação
- Bases que mudam com muita frequência precisam de estratégia de reindexação eficiente para não gerar lag entre a atualização do documento e a disponibilidade na busca
Para casos mais complexos onde o RAG sozinho não resolve, arquiteturas com agentes que podem combinar busca, raciocínio e múltiplas fontes fazem sentido. O artigo sobre LangGraph na prática cobre como estruturar esse tipo de sistema.
Dúvidas comuns sobre RAG
Preciso de um banco vetorial dedicado ou serve um banco comum?
Para volumes pequenos, extensões vetoriais de bancos convencionais funcionam bem. Para volumes maiores ou quando a latência de busca importa, bancos vetoriais dedicados oferecem índices otimizados para esse tipo de operação. A escolha depende do volume de documentos e da frequência de consultas esperada, não do tema do projeto.
Qual modelo de embedding usar?
Para texto em português, vale testar modelos treinados em dados multilíngues ou com boa cobertura de português antes de assumir que um modelo em inglês vai funcionar bem. A qualidade do embedding afeta diretamente a qualidade da busca. Teste com um conjunto de perguntas representativo antes de escolher.
RAG garante que o modelo não vai alucinar?
Não garante, mas reduz significativamente quando implementado com boas instruções de sistema. O modelo pode ainda completar informações que não estão nos documentos se as instruções não forem claras o suficiente. Testar com perguntas fora da base é a única forma de medir isso com confiança.
É possível usar RAG com dados sensíveis?
Sim, mas a escolha da infraestrutura importa. Se os dados não podem sair da empresa, você precisa de modelo de embedding e LLM que rodem em ambiente próprio ou em provedor com garantias contratuais de privacidade. O artigo sobre o que acontece com seus dados quando você usa uma API de LLM cobre esse aspecto com mais detalhe.
Conclusão e próximo passo
RAG na prática é uma das abordagens mais eficientes para conectar LLMs a dados específicos sem custo de retreinamento. O conceito é direto, a implementação tem etapas bem definidas e os pontos de falha são conhecidos e corrigíveis. O que separa um sistema RAG que funciona em demo de um que funciona em produção é a atenção às métricas de qualidade desde o início.
Se você quer avançar com isso, o próximo passo prático é:
- Escolher um conjunto pequeno de documentos que você conhece bem e montar o pipeline básico
- Criar um conjunto de perguntas com resposta conhecida para avaliar a qualidade da recuperação
- Testar com perguntas fora da base para medir a taxa de alucinação antes de escalar
Para entender como avaliar as respostas do LLM de forma sistemática em produção, o artigo sobre como avaliar respostas de LLM em produção cobre os métodos que funcionam além do “pareceu bom”.