RAG na prática: como fazer seus dados conversarem com LLMs

O que é RAG

RAG, sigla para Retrieval-Augmented Generation, e uma técnica que combina busca em base de dados com geração de texto por LLMs. Em vez de depender apenas do que o modelo aprendeu no treino, o RAG busca documentos relevantes em tempo real e os injeta no contexto antes de gerar a resposta.

O problema que o RAG resolve e direto: LLMs tem data de corte de conhecimento, não sabem sobre documentos privados da sua empresa e alucinam quando não sabem uma resposta. Com RAG, o modelo tem acesso ao contexto certo antes de responder, reduzindo dramaticamente erros e informações inventadas.

A técnica foi descrita formalmente pela Meta em 2020 no artigo Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Desde então, virou padrão da industria para qualquer sistema de IA que precisa trabalhar com bases de conhecimento próprias ou atualizadas.

Como funciona

O pipeline RAG tem três etapas principais que acontecem a cada consulta do usuário. Entender cada etapa ajuda a diagnosticar problemas e otimizar a qualidade das respostas geradas pelo sistema.

1. Indexação: seus documentos (PDFs, textos, páginas web, código) são quebrados em pedaços menores chamados chunks. Cada chunk e convertido em um vetor numérico (embedding) que captura o significado semântico do texto. Esses vetores são armazenados em um banco vetorial como Chroma, Pinecone ou pgvector.

2. Recuperação: quando o usuário faz uma pergunta, ela também é convertida em embedding. O sistema busca os chunks mais similares semanticamente usando distancia cosseno ou produto escalar. Os chunks mais relevantes são selecionados como contexto.

3. Geração: o LLM recebe a pergunta original mais os chunks recuperados e gera a resposta baseada nesse contexto específico. O resultado e muito mais preciso do que perguntar diretamente ao modelo sem contexto.

Principais ferramentas e frameworks

O ecossistema RAG em Python e maduro e tem opcoes para todos os níveis de complexidade:

• LangChain: o framework mais popular para RAG. Oferece componentes prontos para loaders, splitters, embeddings, vector stores e chains. Curva de aprendizado media, mas muito bem documentado.
• LlamaIndex: focado especificamente em indexação e recuperação de documentos. Mais simples que LangChain para casos de uso RAG puro, com abstracoesde alto nível para indexar PDFs, Notion, Google Drive e muito mais.
• Haystack (deepset): framework open source com foco em produção. Modular, testavel e com boa integração com pipelines de ML existentes.
• Chroma: banco vetorial open source, roda localmente sem configuração externa. Ideal para prototipagem rápida e projetos menores sem necessidade de infraestrutura extra.
• pgvector: extensão do PostgreSQL que adiciona suporte a vetores. Se você já usa Postgres, e a opcao mais simples para produção sem novo serviço.

Para produção em escala, Pinecone e Weaviate oferecem busca vetorial gerenciada com SLA. Para uso local e prototipagem, Chroma ou FAISS (biblioteca Meta) são as escolhas mais comuns na comunidade.

Como começar: RAG mínimo em Python

A implementação mais simples de RAG usa LangChain com Chroma e qualquer LLM via Ollama (local) ou OpenAI. Você precisa de Python 3.10 ou superior instalado.

Instale as dependências necessárias:

pip install langchain langchain-community chromadb sentence-transformers ollama

Com as dependências instaladas, crie o pipeline RAG básico:

from langchain_community.vectorstores import Chroma
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.document_loaders import TextLoader

# 1. Carregar e dividir documentos
loader = TextLoader("meu_documento.txt")
docs = loader.load()

splitter = RecursiveCharacterTextSplitter(chunk_size=512, chunk_overlap=50)
chunks = splitter.split_documents(docs)

# 2. Criar embeddings e indexar
embeddings = HuggingFaceEmbeddings(model_name="all-MiniLM-L6-v2")
vectorstore = Chroma.from_documents(chunks, embeddings)

# 3. Consultar
resultados = vectorstore.similarity_search("sua pergunta aqui", k=3)
for r in resultados:
    print(r.page_content)

Esse pipeline básico já funciona para prototipagem. Para produção, adicione um LLM na etapa 3 para gerar a resposta final baseada nos chunks recuperados, em vez de apenas exibir os chunks brutos.

Exemplo prático completo

Cenário real: um chatbot que responde perguntas sobre a documentação interna da sua empresa. Os documentos ficam na sua infraestrutura, sem sair para a nuvem.

Com Ollama rodando localmente e LangChain, o pipeline completo fica assim:

from langchain_community.llms import Ollama
from langchain.chains import RetrievalQA

# Usando o vectorstore criado no exemplo anterior
retriever = vectorstore.as_retriever(search_kwargs={"k": 4})

# LLM local via Ollama
llm = Ollama(model="llama4:scout")

# Chain que conecta recuperação e geração
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=retriever,
    return_source_documents=True
)

resposta = qa_chain.invoke("Como funciona o processo de onboarding?")
print(resposta["result"])
print("Fontes:", [d.metadata for d in resposta["source_documents"]])

O resultado inclui a resposta gerada pelo LLM e as fontes exatas usadas para gerar ela. Isso permite auditoria e identificação rápida de respostas baseadas em documentos desatualizados ou incorretos na base.

Comparação com alternativas

RAG não e a única forma de levar conhecimento externo para um LLM. Entender quando usar cada abordagem poupa tempo e custo:

• RAG vs fine-tuning: fine-tuning requer dados de treino e GPU cara; atualizar o conhecimento exige novo treino. RAG atualiza a base de dados sem retreinar o modelo. Para conhecimento que muda, RAG ganha sem discussão.
• RAG vs context stuffing: jogar todos os documentos no contexto do LLM e simples mas caro (muito tokens) e impreciso (muita informação irrelevante). RAG seleciona apenas o relevante.
• RAG vs busca semântica pura: busca semântica retorna documentos; RAG retorna uma resposta sintetizada. Para casos onde o usuário precisa de uma resposta direta (não um documento), RAG e superior.
• RAG vs GraphRAG: GraphRAG (Microsoft) usa grafos de conhecimento em vez de vetores. Mais preciso para dados relacionais complexos, mas muito mais difícil de implementar e manter.

Para a maioria dos casos de uso corporativos, RAG tradicional com vector store e o ponto de partida correto. GraphRAG faz sentido apenas quando as relações entre entidades são críticas para as respostas.

Pontos positivos e limitações

RAG resolveu vários problemas críticos dos LLMs, mas criou novos desafios que você vai encontrar em produção:

• Conhecimento atualizado: adicionar novos documentos a base não requer retreinamento do modelo, apenas reindexação
• Citação de fontes: o sistema pode indicar exatamente qual documento gerou cada parte da resposta
• Privacidade: documentos ficam na sua infraestrutura, o LLM só ve os chunks relevantes por consulta
• Custo controlado: o contexto enviado ao LLM e limitado aos chunks recuperados, não o documento inteiro

As limitações reais que você vai encontrar em produção:

• Qualidade de recuperação depende muito da qualidade dos embeddings e do tamanho dos chunks
• Perguntas que exigem raciocínio sobre múltiplos documentos são difíceis para RAG básico
• Latência aumenta: embedding da query mais busca vetorial mais geração adiciona 200 a 500ms tipicamente
• Manutenção da base vetorial (atualizações, deleções, sincronização) e responsabilidade sua

Casos de uso reais

RAG funciona excepcionalmente bem em categorias específicas de problemas corporativos e de desenvolvimento:

• Chatbot de suporte técnico: indexar documentação, FAQs e histórico de tickets. O assistente responde perguntas dos clientes citando a fonte exata da resposta gerada.
• Assistente jurídico: indexar contratos, legislação e precedentes. Advogados consultam rapidamente sem ler centenas de páginas, com indicação do paragrafo exato relevante.
• Onboarding de novos colaboradores: indexar wikis, runbooks e políticas internas. Novos membros da equipe tiram duvidas sem sobrecarregar colegas seniors com perguntas repetidas.
• Análise de codebase: indexar código-fonte e documentação técnica. Desenvolvedores consultam em linguagem natural sobre como funciona determinada parte do sistema.

Dicas e boas práticas

Vale a pena?

Se você tem uma base de conhecimento que um LLM precisa consultar para dar respostas precisas, RAG não e opcional - e o padrão correto. A alternativa (fine-tuning ou context stuffing) e mais cara, menos flexível e mais difícil de manter ao longo do tempo.

A curva de aprendizado inicial pode assustar, mas com LangChain ou LlamaIndex você tem um pipeline básico funcional em menos de 50 linhas de Python. A partir dai, e questão de iterar sobre a qualidade dos chunks, dos embeddings e da recuperação.

O próximo passo: escolha um documento que você precisaria consultar frequentemente (documentação, políticas internas, base de conhecimento), siga o exemplo prático acima e veja a diferença em produção. A maioria dos times que implementa RAG nunca volta para perguntas diretas ao LLM sem contexto.