Key Takeaways
- RAG = upload de documentos + recuperação + resposta do LLM local. Não requer treinamento.
- Cinco etapas: (1) Carregar documentos, (2) dividir em fragmentos de 500–1.000 tokens, (3) gerar embeddings, (4) armazenar em banco de dados vetorial, (5) recuperar ao fazer consultas.
- Melhor modelo de embedding: nomic-embed-text (137M, funciona localmente, vetores de 768 dimensões).
- Melhor banco de dados vetorial: Chroma (simples, integrado) para <1M documentos; Qdrant (distribuído) para produção.
- Em abril de 2026, o RAG local é mais rápido e econômico que as APIs na nuvem. A qualidade depende da precisão de recuperação e do prompt engineering.
Como o RAG funciona passo a passo?
- 1Ingestão de documentos: Carregar PDFs, arquivos de texto ou páginas web.
- 2Chunking: Dividir os documentos em fragmentos de 500–1.000 tokens (sobreposição de 20% para evitar cortes de contexto).
- 3Embedding: Converter cada fragmento em um vetor (768–1.536 dimensões) usando um modelo de embedding local.
- 4Armazenamento: Salvar os vetores em um banco de dados vetorial (Chroma, Qdrant, Milvus) com metadados (nome do documento, página, timestamp).
- 5Tempo de consulta: Converter a pergunta do usuário em um embedding e buscar no banco de dados vetorial os K fragmentos mais similares (k=5–10).
- 6Montagem de contexto: Combinar os fragmentos recuperados em um prompt com instruções para o LLM local.
- 7Geração: O LLM local gera a resposta com base no contexto recuperado.
- 8Atribuição: Retornar de quais documentos veio a resposta.
Qual é a estratégia de chunking ideal?
A estratégia de chunking determina a qualidade da recuperação. Chunking ruim = informação relevante dividida entre fragmentos, a recuperação falha.
Chunking semântico (recomendado): Dividir por sentenças ou parágrafos, preservando o significado. Exemplo: cada parágrafo = 1 fragmento.
Chunking de tamanho fixo: 500 tokens por fragmento, 20% de sobreposição. Simples mas pode dividir sentenças.
Chunking recursivo: Primeiro por parágrafos, depois por sentenças se forem grandes demais. Preserva a hierarquia.
Em abril de 2026, o chunking semântico com fragmentos de 500–1.000 tokens e 20% de sobreposição é ideal para a maioria dos casos de uso.
# Python: exemplo de chunking semântico
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=1000,
chunk_overlap=200, # 20% de sobreposição
separators=["\n\n", "\n", ".", " "] # Dividir por parágrafo, depois por sentença
)
chunks = splitter.split_documents(documents)
print(f"Criados {len(chunks)} fragmentos")Qual banco de dados vetorial usar?
| Banco de dados | Tipo | Capacidade | Esforço de configuração | Ideal para |
|---|---|---|---|---|
| Chroma | Integrado | <1M docs | pip install | Prototipagem, RAG pequeno |
| Qdrant | Distribuído | Ilimitada | Docker ou nuvem | Produção, escalável |
| Milvus | Distribuído | Ilimitada | Complexo | Empresa, grande escala |
| Weaviate | Grafo + Vetor | Ilimitada | Docker | Consultas complexas, relações |
| Pinecone (nuvem) | Gerenciado | Ilimitada | Chave API | Sem servidor, sem manutenção |
Qual modelo de embedding escolher?
| Modelo | Dimensões do vetor | Velocidade | Qualidade | Recomendação |
|---|---|---|---|---|
| nomic-embed-text (local) | — | Rápida | Excelente | Melhor para RAG local |
| bge-m3 (local) | — | Rápida | Excelente | Suporte multilíngue |
| OpenAI text-embedding-3 (nuvem) | — | Muito rápida | Melhor da classe | Abordagem híbrida |
| Cohere (nuvem) | — | Rápida | Excelente | RAG na nuvem de produção |
Como otimizar a qualidade de recuperação?
A qualidade de recuperação determina o sucesso do RAG. Boa recuperação = boas respostas. Má recuperação = alucinações.
- Seleção de Top K: Recuperar k=5–10 fragmentos. K maior = mais contexto (mais lento), K menor = menos distrações.
- Limiar de similaridade: Filtrar resultados por pontuação mínima de similaridade (ex: >0,75). Evita fragmentos pouco relevantes.
- Reranking: Usar um reranker (cross-encoder) para reclassificar os fragmentos por relevância. Pequena melhoria de precisão.
- Busca híbrida: Combinar busca semântica (embeddings) com busca por palavras-chave BM25. Captura documentos com palavras-chave exatas.
- Expansão de consulta: Ampliar a consulta do usuário com sinônimos ou termos relacionados. Melhora o recall.
Como avaliar a qualidade do RAG?
A qualidade do RAG tem duas dimensões: (1) qualidade de recuperação (obtivemos fragmentos relevantes?), e (2) qualidade de geração (o LLM respondeu bem?).
Avaliação de recuperação: Criar consultas de teste com documentos corretos conhecidos. Medir precisão (quantos recuperados são relevantes?) e recall (obtivemos todos os documentos relevantes?).
Avaliação de geração: Executar o LLM sobre os fragmentos recuperados e pontuar manualmente as respostas (escala 0–5) por exatidão e completude.
Em abril de 2026, ferramentas de avaliação automatizada (como Ragas) podem medir métricas de recuperação e geração automaticamente.
Padrões RAG em produção
Para serviços em produção, use estes padrões:
- Cache: Armazenar em cache os embeddings de documentos consultados frequentemente para evitar recalculá-los.
- Indexação incremental: Adicionar novos documentos sem reindexar tudo. Qdrant e Milvus suportam isso.
- Monitoramento: Rastrear latência de recuperação, taxa de acertos no cache e feedback dos usuários sobre a qualidade das respostas.
- Fallback: Se a recuperação falhar (sem fragmentos relevantes), responder com "Não tenho informações sobre isso" em vez de alucinar.
- Versionamento: Manter versões dos documentos para registros de auditoria. Armazenar qual versão foi usada para cada resposta.
Erros comuns na implementação de RAG local
- Chunking incorreto de documentos. Fragmentos muito pequenos = ruído na recuperação. Poucos fragmentos grandes = informação dividida. Testar tamanhos de fragmento empiricamente.
- Não avaliar a recuperação. Construir RAG sem testar se a recuperação funciona é como construir um carro sem testar o motor. Sempre medir precisão/recall.
- Usar embeddings genéricos para documentos de domínio específico. Documentos jurídicos, médicos ou técnicos podem precisar de embeddings ajustados. Considerar modelos de domínio específico.
- Esquecer a frequência de atualização. Se os documentos mudam semanalmente, o banco de dados vetorial fica desatualizado. Construir um pipeline para re-embeddings e atualizações.
- Esperar que o RAG substitua o fine-tuning. RAG é injeção de contexto. Fine-tuning é adaptação do modelo. Para melhores resultados, combinar ambos.
Perguntas frequentes sobre RAG local
Quantos documentos o RAG local consegue gerenciar?
O Chroma gerencia entre 100K e 1M documentos em hardware de consumo. O Qdrant escala para bilhões com configuração distribuída. Acima de 1M, use Qdrant ou Milvus.
Qual latência devo esperar?
Consulta de embedding (nomic-embed-text em CPU): 50–200ms. Recuperação (Chroma em disco): 10–50ms. Geração do LLM: 2–10 segundos (depende do tamanho do modelo). Total: 2–10 segundos por consulta.
O RAG consegue lidar com atualizações de documentos em tempo real?
Sim. Adicione novos documentos ao banco de dados vetorial dinamicamente. A latência de indexação é de 100–500ms por documento, portanto as atualizações em tempo real são viáveis.
O RAG local é mais econômico que as APIs na nuvem?
Sim. Sem custo por token, sem chamadas de API a serviços externos. Configuração única de embeddings e depois consultas gratuitas.
Posso usar embeddings na nuvem com LLMs locais?
Sim. Use embeddings da OpenAI, Cohere ou outros serviços na nuvem para indexação e depois LLMs locais para geração. Abordagem híbrida.
Fontes
- Documentação do LlamaIndex — docs.llamaindex.ai
- Guia RAG do LangChain — python.langchain.com/docs/use_cases/question_answering
- Documentação do Chroma — docs.trychroma.com
- Motor de busca vetorial Qdrant — qdrant.tech
- Artigo RAG (Lewis et al.) — arxiv.org/abs/2005.11401