RAG (Retrieval-Augmented Generation) é a forma mais prática de conectar um modelo de linguagem aos documentos internos da sua empresa — sem precisar retreinar o modelo. A infraestrutura para RAG é mais simples do que parece, mas tem armadilhas que custam caro se ignoradas. Este guia cobre tudo.
A Adentro projeta e implanta pipelines de RAG em cloud privada com seus dados permanecendo no Brasil.
O que é RAG e como funciona
RAG resolve um problema fundamental dos LLMs: eles só sabem o que estava no dataset de treinamento (com corte em determinada data) e não têm acesso aos documentos internos da sua empresa.
O fluxo de um sistema RAG tem três etapas:
- Indexação (offline): seus documentos são fragmentados em chunks, convertidos em vetores (embeddings) por um modelo especializado, e armazenados em um banco de dados vetorial
- Recuperação (online): quando o usuário faz uma pergunta, ela é convertida no mesmo espaço vetorial e os chunks mais semanticamente similares são recuperados do banco vetorial
- Geração (online): o LLM recebe a pergunta + os chunks relevantes como contexto e gera uma resposta fundamentada nos seus documentos
O resultado: um chatbot que responde com base nos seus manuais, contratos, políticas internas e knowledge base — sem treinamento adicional e com atualização em tempo real quando novos documentos são indexados.
A stack de RAG: quatro componentes
1. Modelo de embeddings
Converte texto em vetores densos que capturam o significado semântico. Diferente do LLM (que gera texto), o modelo de embeddings é pequeno e rápido.
- bge-m3 (BAAI): multilingual (incluindo português), 568M parâmetros, 1024 dimensões. Melhor opção para português em 2026.
- e5-large-v2: inglês, 335M parâmetros. Excelente para documentos em inglês.
- nomic-embed-text: open-source, 137M parâmetros, bom custo-benefício.
- OpenAI text-embedding-3-large: via API, sem necessidade de GPU — opção para volumes baixos.
VRAM necessária para embeddings locais: 1–3 GB. Pode rodar em CPU com latência aceitável para volumes baixos (até ~100 documentos/minuto).
2. Banco de dados vetorial
Armazena e indexa os vetores para busca por similaridade rápida. Veja comparativo detalhado na seção seguinte.
3. LLM (modelo de linguagem)
Gera a resposta final com base na pergunta + chunks recuperados. O LLM em RAG não precisa ter conhecimento sobre seus documentos — ele só precisa ser bom em seguir instruções e sintetizar informações do contexto.
Para RAG em português: Llama 3.1 8B ou Llama 3.3 70B (ambos multilinguais), Qwen 2.5 (excelente em português), ou Mistral 7B. Modelos via API (GPT-4o, Claude Sonnet) também funcionam — útil para começar sem GPU.
4. Orquestrador / pipeline
Conecta os componentes e gerencia o fluxo de dados. Opções populares:
- LangChain / LangGraph: framework mais usado, grande ecossistema, às vezes verboso
- LlamaIndex: especializado em RAG, com abstrações de alto nível para chunking, indexação e retrieval
- Haystack: foco em produção, bom suporte a pipelines complexos
- Implementação própria: para casos simples, 50–200 linhas de Python com a biblioteca do banco vetorial + API do LLM
Banco de dados vetorial: qual escolher
| Banco | Melhor para | Infra | Licença |
|---|---|---|---|
| pgvector | Já usa PostgreSQL, volumes até ~1M vetores | Extensão PostgreSQL | Open source |
| Qdrant | Alta performance, filtros ricos, produção | Docker / managed | Apache 2.0 |
| Weaviate | Multi-modal (texto + imagem), GraphQL | Docker / managed | BSD-3 |
| Chroma | Prototipagem rápida, in-memory | Embutido / servidor | Apache 2.0 |
| Milvus | Escala bilhões de vetores, Kubernetes | Kubernetes | Apache 2.0 |
Recomendação para começar: se você já usa PostgreSQL, adicione pgvector — zero infraestrutura nova, gerencia vetores junto com o resto dos dados. Para volumes maiores (1M+ vetores) ou necessidade de filtros complexos, migre para Qdrant.
Como dimensionar para o seu volume
Estimando o tamanho do banco vetorial
Cada vetor de 1024 dimensões em float32 ocupa ~4 KB. Para um corpus de documentos:
- 1.000 documentos (avg 5 páginas each, chunk size 512 tokens) → ~20.000 chunks → ~80 MB de vetores
- 100.000 documentos → ~2.000.000 chunks → ~8 GB de vetores
- 1.000.000 documentos → ~20.000.000 chunks → ~80 GB de vetores
Para pgvector e Qdrant, o índice HNSW requer adicionalmente ~1–2× o tamanho dos vetores em RAM para performance de busca em milissegundos.
Latência do pipeline RAG
- Embedding da query: 10–50 ms (GPU) ou 50–200 ms (CPU)
- Busca vetorial (top-k=5): 1–10 ms para <1M vetores
- Geração LLM (500 tokens): 2–15 s (depende do modelo e GPU)
O LLM domina a latência total. Para respostas abaixo de 3 segundos, use modelos 7B quantizados ou acesse LLMs via API.
Exemplos de infraestrutura por porte
RAG pequeno — equipe de até 30 usuários, corpus < 10.000 docs
- 1 servidor: CPU moderna (16 cores), 64 GB RAM, 1× RTX 4090 (24 GB VRAM)
- PostgreSQL + pgvector para o banco vetorial
- bge-m3 para embeddings (CPU ou GPU compartilhada)
- Llama 3.1 8B Q4 ou Qwen 2.5 14B Q4 como LLM
- Throughput: 5–10 perguntas/minuto, latência ~4–8 s
RAG médio — até 200 usuários, corpus 10.000–500.000 docs
- 2 servidores separados: (1) servidor de embeddings + banco vetorial, (2) servidor LLM
- Servidor de embeddings: CPU 32 cores, 128 GB RAM, Qdrant, bge-m3 em GPU pequena (T4 ou L4)
- Servidor LLM: 2× L40S 48 GB, Llama 3.3 70B Q4 com vLLM
- Throughput: 50–100 perguntas/minuto, latência ~2–5 s
Perguntas frequentes
RAG ou fine-tuning: qual escolher?
RAG para conhecimento que muda frequentemente (documentos internos atualizados, base de dados de produtos) ou quando o volume de informação não cabe no contexto do modelo. Fine-tuning para adaptar o estilo de escrita, terminologia técnica específica do domínio ou comportamentos que o modelo precisa internalizar — não apenas recuperar. Na prática, a maioria das empresas começa com RAG (mais simples e barato) e adiciona fine-tuning depois, se necessário.
Posso fazer RAG com documentos em PDF, Word e planilhas?
Sim. A etapa de parsing de documentos é separada do pipeline RAG propriamente dito. Ferramentas como Unstructured.io, PyMuPDF (PDF), python-docx (Word) e openpyxl (Excel) extraem o texto. Para PDFs com imagens ou formulários scaneados, adicione OCR (Tesseract, AWS Textract, Google Document AI). O texto extraído vai para o pipeline de chunking e embedding normalmente.
Como garantir que o modelo não invente informações que não estão nos documentos?
Isso é chamado de “hallucination em RAG” e é mitigado por: (1) prompt que instrui o modelo a responder “não encontrei informação sobre isso nos documentos” quando os chunks não têm a resposta; (2) citação de fontes — forçar o modelo a indicar qual chunk embasou cada afirmação; (3) verificação de resposta (LLM-as-judge) — um segundo LLM verifica se a resposta é suportada pelos chunks; (4) ajuste do parâmetro de temperatura para 0 ou próximo de 0 em casos que requerem factualidade.
Qual o chunk size ideal para RAG?
Não existe um valor único. Chunks pequenos (128–256 tokens) recuperam trechos mais precisos mas podem perder contexto. Chunks grandes (512–1024 tokens) têm mais contexto mas podem diluir a relevância semântica. O padrão mais adotado é 512 tokens com overlap de 50–100 tokens entre chunks adjacentes (para não perder informações que atravessam a fronteira do chunk). Para documentos muito estruturados (manuais com seções claras), chunk por seção semântica é mais eficiente que tamanho fixo.
RAG funciona bem com documentos em português?
Sim, desde que você use um modelo de embeddings que suporte português. O bge-m3 (BAAI) e o multilingual-e5-large têm excelente performance em português. Modelos de embeddings treinados apenas em inglês (e5-base-v2, all-MiniLM) funcionam parcialmente mas com qualidade de retrieval reduzida. Para o LLM, Llama 3, Qwen 2.5 e Mistral têm boa performance em português sem necessidade de modelos específicos.
