O problema que RAG resolve
LLMs têm duas limitações fundamentais:
- Cutoff de treinamento: o modelo só sabe o que estava no training data até a data em que foi treinado. Qualquer coisa posterior é invisível para ele.
- Alucinação: quando questionado sobre algo fora do training data (ou dentro mas raro), o modelo inventa uma resposta plausível. Nem sempre é possível distinguir de uma resposta real.
Fine-tuning (retreinar o modelo com dados específicos) resolve parcialmente, mas é caro, demorado e precisa ser refeito sempre que os dados mudam. Para aplicações onde o conhecimento muda (manual de produto atualizado semanalmente, jurisprudência nova, catálogo dinâmico), fine-tuning é inviável.
RAG resolve esses problemas injetando informação relevante no momento da pergunta: em vez de ensinar o modelo, você dá a ele o material necessário toda vez que for responder.
Como funciona passo a passo
Fase de preparação (offline)
- Ingestão: coletar todos os documentos que formam a base de conhecimento (PDFs, wikis, páginas HTML, bancos, etc.)
- Chunking: dividir cada documento em pedaços menores de tamanho manejável (300-800 tokens)
- Embedding: converter cada chunk em um vetor numérico de alta dimensionalidade usando um embedding model. Chunks semanticamente próximos ficam próximos no espaço vetorial
- Indexação: armazenar os vetores em um banco de dados vetorial (Pinecone, Weaviate, Chroma, Qdrant, Milvus)
Fase de resposta (em tempo real)
- Query: usuário envia pergunta em texto
- Embedding da query: a pergunta é convertida no mesmo espaço vetorial
- Retrieval: o banco de dados retorna os N chunks mais similares semanticamente à pergunta
- (Opcional) Reranking: um modelo secundário reordena os chunks recuperados por relevância real à pergunta
- Prompt augmentation: os chunks selecionados são inseridos no prompt como contexto, junto com a pergunta original
- Geração: o LLM gera a resposta usando o contexto recuperado
- (Opcional) Citação: a resposta inclui referências aos chunks usados, para auditoria
Componentes críticos — e decisões em cada um
Embedding model
Converte texto em vetores. Afeta profundamente a qualidade do retrieval. Opções principais:
- OpenAI text-embedding-3-large: altíssima qualidade, inglês excelente, PT-BR bom
- Cohere Embed Multilingual v3: forte em multilingue
- Voyage AI: novato promissor, foco em qualidade
- BGE (BAAI), E5 (Microsoft): open-source, rodando localmente
- sentence-transformers: biblioteca com dezenas de modelos open-source
Vector database
Armazena e busca vetores. Decisão depende de escala, latência e custo:
- Pinecone: managed, simples, escalável. Popular para MVPs e médio porte
- Weaviate: open-source com versão managed, mais features
- Qdrant: open-source, Rust, alta performance
- Chroma: simples, local-first, ótimo para desenvolvimento
- pgvector (PostgreSQL): se você já tem Postgres, adiciona funcionalidade vetorial sem nova infra
- Milvus: open-source, pensado para grandes escalas (bilhões de vetores)
Chunking strategy
Talvez a decisão mais subestimada. Opções:
- Fixed-size: dividir a cada N tokens. Simples, frequentemente quebra contexto
- Sentence-based: respeitar fronteiras de frase. Melhor preservação semântica
- Paragraph-based: dividir por parágrafo. Bom para documentos estruturados
- Semantic chunking: usar embeddings para decidir onde cortar baseado em similaridade. Mais caro, mais preciso
- Recursive: tenta dividir por hierarquia (H1 → H2 → parágrafo → frase). Bom para conteúdo web
Retrieval
Estratégia de recuperação:
- Top-k puro: N chunks mais similares. Simples mas pode retornar duplicatas
- MMR (Maximal Marginal Relevance): balanceia similaridade e diversidade
- Hybrid search: combina vetor (semântico) com BM25 (keyword). Captura consultas tanto por conceito quanto por termos específicos
- Reranking: recuperar muito (top-20), rerrankear para top-3-5. Melhora qualidade em 20-40% segundo pesquisas
RAG vs Fine-tuning — quando escolher
| Situação | Use RAG | Use Fine-tuning |
|---|---|---|
| Conhecimento muda frequentemente | ✓ | ✗ |
| Precisa citar fontes | ✓ | ✗ |
| Base é grande (>1000 docs) | ✓ | Caro |
| Você precisa mudar comportamento/estilo do modelo | ✗ | ✓ |
| Latência é crítica (<200ms) | Possível com cuidado | ✓ |
| Dados sensíveis que não podem entrar no modelo | ✓ (contexto efêmero) | ✗ |
| Custo inicial baixo | ✓ | ✗ (fine-tuning é caro) |
Frequentemente a resposta correta é ambos: fine-tuning para ensinar o estilo e RAG para fornecer conhecimento atualizado.
Casos de uso em marketing
Chatbot de suporte com documentação
Usuário pergunta; RAG recupera seções do manual; modelo responde citando fonte. Usado em SaaS para reduzir volume de tickets. Resultado típico: 40-60% de deflexão de tickets simples.
Assistente interno para vendas (sales enablement)
Vendedor digita pergunta sobre produto/preço/case; assistente responde com trecho de proposta anterior, playbook ou one-pager. Reduz fricção e acelera pitch.
Qualificação automatizada de leads
RAG acessa ICP (ideal customer profile), casos similares, propostas passadas; modelo analisa lead novo e retorna score + razão, com citação dos dados que usou.
Content assistant para marketing
Equipe de conteúdo pergunta: "quais dados temos sobre X?"; RAG acessa pesquisas internas, relatórios, posts anteriores; modelo responde com síntese e links. Evita duplicação e aproveita research já feito.
Análise de feedback e reviews em escala
Grande volume de comentários/reviews é embeddado; modelo consulta semanticamente ("quais as principais reclamações sobre entrega?") e retorna síntese com exemplos citados.
Limitações reais
- Qualidade limitada pela base: RAG não inventa conhecimento — se a base é ruim ou incompleta, as respostas serão ruins
- Latência maior que LLM puro: pipeline tem múltiplos passos (embedding da query, retrieval, reranking, geração). Tipicamente 1-5 segundos por resposta
- Custo por query: cada pergunta usa tokens do LLM + chamadas ao vector DB + embedding. Escalável mas não gratuito
- Alucinações persistem: modelo pode misturar contexto recuperado com conhecimento pré-treinado; sempre valide
- Perguntas fora da base: RAG pode errar feio quando a pergunta não tem resposta nos documentos — confiar cegamente é perigoso
Evolução: agentic RAG e GraphRAG
Arquiteturas mais recentes vão além do retrieval simples:
- Agentic RAG: o modelo decide ativamente quais queries fazer, refina sua própria busca, combina resultados de múltiplas fontes. Pesquisa OpenAI 2024 mostra melhora significativa em tarefas complexas
- GraphRAG (Microsoft Research): constrói um grafo de conhecimento sobre a base antes de indexar. Permite respostas que exigem "conectar os pontos" entre documentos separados
- Long-context RAG: com modelos de contexto largo (Gemini 1.5 Pro com 2M tokens, Claude 3.5 com 200k), estratégia híbrida — retrieval para filtragem inicial, contexto inteiro para análise profunda
Para empresas que querem avaliar se RAG faz sentido no seu cenário — e implementar de forma que funcione em produção, não só em demo — nossa consultoria de marketing digital cobre o diagnóstico técnico-estratégico completo.
Ver também Prompt Engineering, fundamental para construir os prompts que compõem o pipeline RAG.