Como desenvolver
sistemas RAG

Modelos de linguagem como Claude e GPT-4 são treinados com uma fotografia do conhecimento humano até uma certa data. Isso cria três limitações críticas para aplicações empresariais: conhecimento desatualizado (o modelo não sabe o que aconteceu depois do corte de treinamento), ausência de dados privados (documentos internos, manuais, contratos, dados de clientes não fazem parte do treinamento) e alucinações (quando o modelo não sabe algo, ele frequentemente inventa uma resposta plausível).

Fine-tuning — retreinar o modelo com seus dados — é uma solução possível, mas cara, demorada e rígida. Cada vez que sua base de conhecimento muda, você precisa retreinar. Para a maioria das empresas, isso é inviável. RAG resolve todos os três problemas de forma mais elegante: você mantém o modelo genérico intacto e conecta a ele uma base de conhecimento que pode ser atualizada a qualquer momento, sem retreinamento.

O impacto prático é enorme. Um chatbot de suporte que responde com base nos seus manuais técnicos reais. Um assistente jurídico que consulta a jurisprudência mais recente do seu escritório. Uma ferramenta de análise que conhece cada relatório interno já produzido. Tudo isso se torna viável com RAG — e sem precisar de uma equipe de ML para manter.

Para entender RAG, você precisa entender embeddings. Um embedding é uma representação numérica de um texto — um vetor de centenas ou milhares de números que captura o significado semântico daquele texto. Textos com significado semelhante produzem vetores próximos no espaço matemático; textos com significados diferentes produzem vetores distantes.

É essa propriedade que torna a busca semântica possível. Quando um usuário faz uma pergunta, ela é convertida em um vetor de embedding. O sistema então busca no banco vetorial os documentos cujos vetores estão mais próximos do vetor da pergunta — ou seja, os documentos semanticamente mais relevantes para aquela consulta.

A beleza da busca vetorial é que ela funciona por significado, não por palavras exatas. Uma pergunta sobre "como cancelar minha assinatura" vai recuperar documentos que falam em "rescisão de contrato", "encerramento de plano" e "desativação de conta" — mesmo que as palavras não coincidam. Isso é fundamentalmente diferente e muito mais poderoso do que a busca por palavras-chave tradicional.

Antes de gerar embeddings, seus documentos precisam ser divididos em pedaços menores — os chunks. O tamanho e a estratégia de chunking têm impacto direto na qualidade do sistema, e é aqui que muitos projetos erram.

Chunking por tamanho fixo é o mais simples: divida o texto em blocos de N tokens com alguma sobreposição (overlap) entre os blocos consecutivos. A sobreposição garante que frases que cruzam a fronteira entre chunks não se percam. É um bom ponto de partida, mas ignora a estrutura do documento.

Chunking por separador semântico respeita a estrutura natural do texto — parágrafos, seções, tópicos. É mais complexo de implementar, mas produz chunks mais coerentes. Para documentos com estrutura clara (manuais, contratos, artigos), esse método tende a gerar resultados superiores.

Chunking hierárquico cria uma estrutura em dois níveis: chunks menores para recuperação precisa e chunks maiores (ou o documento inteiro) para contexto. Quando um chunk pequeno é recuperado, o sistema também inclui o contexto mais amplo ao redor dele — aumentando a coerência da resposta gerada.

Uma regra prática útil: o chunk precisa conter informação suficiente para ser compreendido de forma independente, mas não tão longo que dilua o sinal de relevância para a busca. Para começar, tente 512 tokens com 10% de sobreposição e ajuste a partir dos resultados que observar.

O código abaixo mostra as partes essenciais de um sistema RAG usando a API da Anthropic para geração e Chroma como banco vetorial local. É um ponto de partida funcional que você pode adaptar ao seu caso de uso:

Hybrid search (busca híbrida): combine busca vetorial (semântica) com busca por palavras-chave BM25. A busca vetorial captura similaridade semântica; o BM25 captura termos exatos — nomes próprios, siglas, códigos de produto. Juntas, as duas cobrem os casos que cada uma deixaria passar individualmente. Qdrant e Weaviate suportam isso nativamente.

Reranking: após recuperar os K chunks iniciais, passe-os por um modelo de reranking (como os da Cohere ou da Jina AI) que avalia cada chunk individualmente em relação à consulta e reordena por relevância real. Esse passo geralmente melhora a precisão de forma significativa com custo computacional baixo.

Query expansion e HyDE: reformule a pergunta do usuário antes de buscar. No HyDE (Hypothetical Document Embeddings), você pede ao LLM que escreva um documento hipotético que responderia à pergunta — e então usa o embedding desse documento hipotético para buscar. Documentos reais similares ao hipotético tendem a ser mais relevantes que os encontrados pela pergunta original.

Citação de fontes: instrua o modelo a citar quais documentos e seções usou para gerar cada parte da resposta. Isso aumenta a confiança dos usuários e permite auditoria. Passe os metadados de origem junto com cada chunk no prompt e peça explicitamente que os cite na resposta.

Chunks grandes demais ou pequenos demais. Chunks grandes demais diluem o sinal de relevância — o chunk recuperado pode ser o correto, mas a resposta para a pergunta está afogada em texto irrelevante. Chunks pequenos demais perdem contexto — a frase relevante está lá, mas sem as frases ao redor ela não faz sentido. Calibrar o tamanho do chunk é uma das alavancas de melhoria mais impactantes.

Documentos ruins entram na base. RAG não melhora documentação mal escrita — ele a amplifica. Se seus manuais internos têm informações contraditórias ou desatualizadas, o sistema vai recuperar e servir essas informações ruins com a aparência de autoridade. Cuide da qualidade dos documentos de entrada antes de construir o sistema.

Ausência de avaliação sistemática. Muitos projetos RAG são construídos, testados informalmente com algumas perguntas e então declarados "prontos". Sem um conjunto de avaliação — perguntas com respostas conhecidas para medir precisão, recall e qualidade da resposta — é impossível saber se mudanças no sistema estão melhorando ou piorando os resultados. Construa o benchmark antes de otimizar.

Contexto insuficiente no prompt. O modelo só pode gerar uma resposta tão boa quanto o contexto que recebe. Se os chunks recuperados não contêm a informação necessária — seja porque o retrieval falhou, seja porque o chunking separou informações que deveriam estar juntas — o modelo vai alucinar ou dizer que não sabe. A causa-raiz quase sempre está no retrieval, não no modelo generativo.

Avaliar RAG exige medir dois sistemas separados: o retriever e o gerador. Para o retriever, as métricas principais são recall@K (quantas das respostas corretas estavam entre os K chunks recuperados) e MRR (Mean Reciprocal Rank — quão alta na lista o chunk correto aparece). Para o gerador, avalie faithfulness (a resposta é fiel ao contexto fornecido?), relevância da resposta e corretude factual.

Frameworks como RAGAS automatizam boa parte dessa avaliação — eles usam um LLM como juiz para avaliar as respostas do seu sistema em um conjunto de perguntas de referência. É imperfeito, mas muito melhor do que não avaliar. O custo de um conjunto de avaliação bem construído se paga rapidamente em tempo economizado depurando problemas às cegas.