RAG (Retrieval Augmented Generation) é a técnica que faz um modelo de IA buscar informação em uma base de conhecimento própria — seu catálogo, suas políticas, seus documentos internos — antes de gerar a resposta. Em vez de o modelo "inventar" com base no que aprendeu no treino, ele lê primeiro e responde depois. O resultado: respostas precisas, ancoradas nos seus dados, com citação de fonte.
Se você já tentou usar um chatbot de IA no atendimento e recebeu respostas genéricas, inventadas ou desatualizadas, o problema quase nunca é o modelo — é a falta de RAG.
O problema que o RAG resolve
Modelos de linguagem (ChatGPT, Claude, Llama) são treinados com dados até uma data de corte. Eles não sabem:
- O preço do seu produto de hoje
- A política de troca atualizada na semana passada
- O status do pedido de um cliente específico
- O procedimento interno para devolver um item com defeito
Sem RAG, o modelo tem três saídas ruins possíveis:
- Alucinar: inventa uma resposta plausível mas falsa. "Sim, temos o vestido X em estoque" — mas o vestido X saiu de linha mês passado.
- Recusar: diz que não sabe. Útil em alguns casos, inútil quando o cliente precisa de uma resposta real.
- Responder com base no treino: mistura informação genérica da internet com a realidade do seu negócio, gerando confusão.
RAG resolve os três. O modelo passa a responder sempre com base em um texto real que veio da sua base. Se a informação não está lá, ele diz que não sabe — ou pede para um humano.
Como funciona (por dentro)
O fluxo de RAG tem cinco etapas. Mesmo que você não vá implementar, entender o fluxo ajuda a avaliar fornecedores e cobrar o que importa.
[PERGUNTA DO CLIENTE]
|
v
+-----------------------+
| 1. EMBEDDING DA | Transforma a pergunta em um vetor numérico
| PERGUNTA | que representa o "significado" dela.
+-----------------------+
|
v
+-----------------------+
| 2. BUSCA VETORIAL | Compara o vetor da pergunta com os vetores
| NA BASE | dos seus documentos e acha os K trechos
| | mais relevantes (top 5, top 10...).
+-----------------------+
|
v
+-----------------------+
| 3. RERANKING | Reordena os trechos por relevância real
| (opcional) | usando um modelo mais sofisticado.
+-----------------------+
|
v
+-----------------------+
| 4. MONTAGEM DO | Junta a pergunta original + os trechos
| PROMPT | recuperados em um único prompt.
+-----------------------+
|
v
+-----------------------+
| 5. GERAÇÃO DA | O LLM lê o prompt e gera a resposta
| RESPOSTA | ancorada nos trechos. Com citação.
+-----------------------+
|
v
[RESPOSTA AO CLIENTE]
O ponto crítico é o passo 2: a busca vetorial. Ela é o que diferencia RAG de "prompt engineering" comum. Sem uma busca boa, o modelo recebe documentos irrelevantes e responde mal — a famosa expressão garbage in, garbage out. O paper original de Lewis et al. (2020) já definia esse pipeline; o que mudou desde então foi a qualidade dos embeddings e dos retrievers. Documentação oficial do Qdrant cobre os parâmetros de busca que mais afetam a qualidade.
O que é embedding, na prática
Embedding é uma lista de números (tipicamente 768, 1024 ou 1536 dimensões) que representa o significado de um texto. "Reembolso de produto com defeito" e "devolução de mercadoria avariada" têm embeddings parecidos, mesmo usando palavras diferentes. É isso que permite a busca por significado, não por palavra-chave exata.
Quando vale a pena (e quando não vale)
RAG não é bala de prata. Antes de implementar, avalie se o seu caso de uso se encaixa.
Vale a pena quando
- A base de conhecimento é grande e muda com frequência: catálogo de produtos, políticas internas, manuais, FAQs que se atualizam semanalmente.
- O cliente faz perguntas específicas e a resposta precisa ser exata: "qual o prazo de entrega para o CEP 04101-000?", "esse produto tem na cor azul tamanho 38?".
- Você precisa de rastreabilidade: toda resposta vem com a fonte do documento original. Auditoria e confiança dependem disso.
- O time de atendimento está afogado em perguntas repetitivas: 60-80% das perguntas de um SAC típico são respondíveis com a base certa.
Não vale a pena quando
- A base de conhecimento é minúscula: se você tem 10 documentos e eles cabem inteiros no contexto do modelo, RAG é over-engineering. Prompt simples resolve.
- As perguntas são todas genéricas e a resposta não precisa ser específica: "qual o horário da loja?" não precisa de RAG, precisa de uma resposta fixa.
- Você não tem processo para manter a base atualizada: RAG com base velha gera respostas erradas com confiança alta. Pior do que não ter.
- A latência precisa ser sub-segundo em escala massiva: RAG adiciona latência (busca + rerank + geração). Para WhatsApp em horário de pico, planeje capacidade.
Stack recomendado em 2026
Não existe stack único. A escolha depende do tamanho da base, do orçamento e da equipe. Mas o padrão de mercado em 2026 é claro:
| Componente | Opção gratuita/open-source | Opção gerenciada (paga) |
|---|---|---|
| Embedding | bge-m3, nomic-embed-text, gte-Qwen2 (via Ollama) | OpenAI text-embedding-3-small, Voyage AI, Cohere |
| Banco vetorial | Qdrant, Weaviate, Milvus, Chroma | Qdrant Cloud, Pinecone, Turbopuffer |
| Reranker | bge-reranker-v2-m3, cohere-rerank-3 self-hosted | Cohere Rerank 3.5, Jina Rerank |
| LLM gerador | Llama 3.3 70B, Qwen 2.5 72B, Mistral Large (via Ollama ou vLLM) | Claude Sonnet 4, GPT-4o, Gemini 2.5 |
| Orquestração | LangChain, LlamaIndex, Haystack | AWS Bedrock Knowledge Bases, Azure AI Search, Vertex AI Search |
| Avaliação | Ragas, DeepEval, Phoenix | LangSmith, Langfuse Cloud |
A regra prática: comece com o mínimo (Qdrant + bge-m3 + Claude ou GPT-4o via API) e adicione rerank e orquestração só quando a busca simples não estiver boa o suficiente. Mais componentes não significa melhor resultado — significa mais coisa para dar errado. Para uma visão aplicada em cloud, vale ler a documentação de Knowledge Bases do Amazon Bedrock, que cobre os mesmos blocos em modo gerenciado.
Case Agendai: RAG para catálogo de produtos
Um cliente nosso — rede de moda com 12 lojas e 4.000 SKUs — atendia cerca de 800 mensagens por dia no WhatsApp. A equipe de 4 atendentes respondia em média 3 minutos por mensagem, e o principal motivo de tempo perdido era ir até o sistema de estoque conferir preço, tamanho e disponibilidade.
Implementamos RAG em três etapas:
- Indexamos o catálogo completo (nome, descrição técnica, atributos, preço, status por loja) em um Qdrant self-hosted, com atualização noturna.
- Indexamos as 200 perguntas mais frequentes (política de troca, prazo de entrega, formas de pagamento) com embeddings separados e prioridade alta.
- Conectamos ao agente de atendimento que já tinha: o RAG virou uma "ferramenta" que o agente consulta antes de responder.
Resultado depois de 60 dias:
- 68% das perguntas de estoque e preço passaram a ser respondidas em menos de 8 segundos, sem intervenção humana.
- Tempo médio de resposta do time caiu de 3 min para 1 min 12s (as perguntas que sobraram eram mais complexas).
- Taxa de "o sistema não respondeu corretamente" medida em revisão semanal ficou em 4,2% — casos em que a busca vetorial puxou o produto errado.
Nada disso seria possível com prompt engineering puro. O modelo precisava olhar o catálogo atualizado para responder com precisão. RAG é o que faz isso de forma confiável e auditável.
Perguntas frequentes
RAG é a mesma coisa que fine-tuning? Não. Fine-tuning ajusta os pesos do modelo (retreina com seus dados). RAG deixa o modelo como está e só dá a ele acesso a uma base externa na hora de responder. RAG é mais barato, mais rápido de atualizar e mais fácil de auditar. Fine-tuning faz sentido quando você precisa que o modelo aprenda um estilo ou mude comportamento, não quando precisa de conhecimento atualizado.
Preciso de GPU para rodar RAG? Para a parte de embedding e busca vetorial, não — CPU serve. Para gerar as respostas com um LLM open-source (Llama, Qwen, Mistral), sim, GPU ajuda. Mas dá para usar APIs de LLM pago (OpenAI, Anthropic, Google) e manter tudo o resto self-hosted, o que é o caminho mais comum em produção.
Quanto custa uma implementação de RAG para PME? Em 2026, uma implementação enxuta (Qdrant self-hosted + embeddings locais + API de LLM) custa entre R$ 800 e R$ 3.000/mês em infraestrutura para uma base de até 500 mil documentos. O custo maior é de implementação e manutenção da base, não de infraestrutura.
Como sei se o RAG está respondendo bem? Você precisa de um pipeline de avaliação. O mínimo viável: pegue 100 perguntas reais, rode o RAG, avalie manualmente se a resposta está correta e a fonte está certa. Ferramentas como Ragas e DeepEval automatizam isso, mas nenhuma substitui revisão humana periódica.
RAG funciona para qualquer idioma?
Sim, desde que o embedding e o LLM sejam multilíngues. Modelos como bge-m3 e Claude Sonnet 4 têm português brasileiro de qualidade. O cuidado maior é com a base: documentos mal escritos, com gírias regionais ou abreviações geram embeddings piores. Padronização ajuda.
Recomendamos também: IA que conhece seus produtos e clientes: como funciona na prática e Agentes de IA no varejo: o que são e o que realmente fazem.
A Agendai implementa RAG e agentes de atendimento treinados com a base de conhecimento do seu negócio. Catálogo, políticas, histórico — tudo indexado, auditável e respondendo em segundos. Fale com a gente.