RAG (Retrieval-Augmented Generation)

Modelos de linguagem de grande escala (LLMs) têm dois problemas estruturais para uso em aplicações de produção: o conhecimento deles congela na data de corte do treinamento (não sabem o que aconteceu depois), e eles alucinam — geram informações que soam corretas mas são inventadas. Para perguntas sobre documentos específicos da empresa, políticas internas, dados atualizados ou conhecimento de domínio especializado que não estava nos dados de treinamento, um LLM sem ancoragem em fontes reais é um sistema que produz respostas plausíveis mas não verificáveis.

RAG (Retrieval-Augmented Generation) é uma arquitetura que resolve esses problemas combinando recuperação de informação com geração de texto: antes de gerar a resposta, o sistema busca os documentos mais relevantes para a pergunta em uma base de conhecimento externa e inclui esse conteúdo no contexto do LLM. O modelo não precisa "saber" a resposta de memória — ele a sintetiza a partir de documentos reais que o sistema recuperou.

É a diferença entre perguntar a alguém "o que você sabe sobre X?" (memória) e dar a essa pessoa um conjunto de documentos relevantes e pedir que responda com base neles (recuperação + síntese).

Fase de indexação (offline):

1. Coleta de documentos: reunir o corpus de conhecimento — PDFs, páginas web, documentos Word, artigos, transcrições, bases de dados. Cada documento que o sistema deverá ser capaz de citar como fonte.

2. Chunking (fragmentação): dividir documentos em fragmentos menores (chunks) de tamanho apropriado — tipicamente 256 a 1024 tokens. O tamanho afeta a granularidade da recuperação: chunks pequenos são mais precisos mas perdem contexto; chunks grandes têm mais contexto mas podem trazer informação irrelevante.

3. Geração de embeddings: para cada chunk, gerar um vetor denso (embedding) usando um modelo de embedding (OpenAI text-embedding-ada-002, Cohere Embed, modelos open source como BGE, E5). O embedding é uma representação numérica do significado semântico do chunk — chunks com significado similar têm vetores próximos no espaço.

4. Armazenamento em vector database: armazenar os chunks e seus embeddings em banco de dados otimizado para busca por similaridade vetorial (Pinecone, Weaviate, Qdrant, Chroma, pgvector para PostgreSQL). O vector database permite encontrar rapidamente os chunks semanticamente mais próximos de uma query.

Fase de recuperação e geração (online, por consulta):

1. Embedding da pergunta: a pergunta do usuário é transformada em embedding com o mesmo modelo usado na indexação.

2. Busca por similaridade: o vector database retorna os K chunks mais semanticamente similares à pergunta (cosine similarity ou distância euclidiana no espaço de embeddings).

3. Construção do prompt aumentado: os chunks recuperados são incluídos no contexto do prompt enviado ao LLM. "Com base nos seguintes documentos: [chunks], responda à pergunta: [pergunta]."

4. Geração: o LLM gera resposta baseada no contexto fornecido — idealmente citando as fontes dos documentos recuperados.

A qualidade do sistema RAG depende de múltiplos componentes, cada um com impacto significativo no resultado final.

Qualidade do chunking: uma estratégia de chunking ruim — tamanho inapropriado, quebra no meio de frases ou parágrafos semanticamente coesos — degrada a qualidade da recuperação. Técnicas avançadas incluem chunking semântico (dividir em fronteiras de parágrafo ou seção), parent-child chunking (indexar chunks pequenos para recuperação precisa, mas incluir o documento pai no contexto), e overlap entre chunks (para não perder contexto nas bordas).

Qualidade do modelo de embedding: o embedding captura quão bem o significado semântico. Modelos de embedding diferentes têm performance diferente dependendo do domínio e idioma. Para português, modelos multilinguais (mE5, BGE-M3) frequentemente superam modelos anglófonos.

Estratégia de retrieval: busca por similaridade vetorial pura (dense retrieval) pode perder resultados relevantes que têm palavras-chave distintas. Híbrido com busca por palavras-chave (BM25) frequentemente melhora o recall. Re-ranking com modelo de cross-encoder depois do retrieval inicial melhora a relevância dos resultados.

Prompt de síntese: como o LLM é instruído a usar os documentos recuperados — se deve citar fontes, o que fazer quando os documentos são contraditórios, se deve admitir quando a pergunta não pode ser respondida com os documentos disponíveis.

Uma confusão comum é quando usar RAG vs fine-tuning para customizar LLMs para casos de uso específicos.

RAG é preferível quando:

• O conhecimento é específico, atualizado com frequência ou volumoso demais para o contexto
• É necessário citar fontes e verificar a origem das informações
• O conhecimento inclui documentos proprietários que não devem ir para treinamento
• O caso de uso é perguntas sobre documentos ou bases de conhecimento específicas

Fine-tuning é preferível quando:

• É necessário adaptar o estilo, tom ou formato de resposta do modelo
• Há tarefas específicas onde o modelo base tem desempenho sistematicamente ruim
• O conhecimento é estável e pode ser incorporado nos parâmetros do modelo
• A latência de RAG (retrieval + geração) é inaceitável para o caso de uso

Combinação: RAG + fine-tuning pode ser poderosa — fine-tune para comportamento e estilo, RAG para conhecimento atualizado.

Chatbot de suporte a documentos internos: o modelo responde perguntas sobre manual de processos, políticas de RH, documentação técnica. A empresa controla o corpus; as respostas citam os documentos fonte.

Assistente de análise jurídica: recuperar cláusulas relevantes de contratos ou legislação para auxiliar análise de casos específicos. RAG sobre base de documentos jurídicos evita alucinação de artigos de lei inexistentes.

Suporte ao cliente com knowledge base: em vez de apenas regras de resposta, o agente de suporte recupera documentação técnica, FAQs e histórico de casos similares para responder questões complexas.

Pesquisa em base de literatura técnica: recuperar artigos científicos relevantes para uma pergunta de pesquisa, sintetizar o estado da arte com citações.

Assistente de vendas com base de produtos: o representante pergunta "qual produto se encaixa para cliente com necessidade X?" — o sistema recupera fichas de produtos, casos de uso e comparações relevantes.

Avaliar RAG é mais complexo do que avaliar modelos de ML clássicos, porque há dois componentes a avaliar: o retrieval e a geração.

Métricas de retrieval:

• Precision@K: dos K documentos recuperados, qual fração é relevante para a pergunta?
• Recall@K: dos documentos relevantes que existem na base, qual fração está nos K recuperados?

Métricas de geração:

• Fidelidade: a resposta é consistente com os documentos recuperados? (mede alucinação pós-retrieval)
• Relevância: a resposta responde à pergunta do usuário?
• Completude: a resposta cobre os aspectos importantes da pergunta?

Frameworks como RAGAS e TruLens automatizam parte dessa avaliação, usando LLMs para julgar a qualidade de respostas — "LLM-as-judge".

RAG é provavelmente a arquitetura de IA com maior impacto prático imediato para empresas que têm documentos proprietários que precisam estar acessíveis de forma inteligente — manuais de processo, políticas, base de conhecimento de suporte, documentação técnica. O caso de uso de "chatbot que responde sobre os documentos da empresa" que seria ficção científica há três anos é implementável hoje por um engenheiro de software em dias, não meses.

O investimento técnico é acessível: LangChain ou LlamaIndex como framework de RAG, um vector database (Chroma ou pgvector para começar, Pinecone ou Weaviate para produção), e API de um LLM. O desafio real não é técnico — é de qualidade de dados: documentos bem organizados, atualizados e sem ruído produzem sistemas RAG que funcionam; documentos desorganizados, desatualizados e inconsistentes produzem sistemas que confundem mais do que ajudam.

Para PMEs, o caso de uso mais acessível é um assistente interno que responde sobre políticas, processos e documentação da empresa — reduzindo o volume de perguntas repetitivas que chegam a times de RH, TI e operações, com as respostas ancoradas em documentos reais que podem ser atualizados sem retreinar o modelo.