O Que Um Sistema RAG Realmente Custa: Números de Um Build em Produção
Toda vez que alguém me pergunta quanto custa construir um sistema RAG, dou a mesma resposta e vejo seu rosto desanimar. É bem simples: não é muito, se você souber o que está fazendo. E é bastante, se você não souber.
Eu sei, esta não é uma resposta satisfatória. Pessoas que fazem a pergunta sobre custo querem um número. Algo que possam facilmente colocar em uma linha de orçamento. Algo que possam levar de volta para seu CFO e defender. Então neste post vou te dar números reais de um build verdadeiro, um chatbot com retrieval-augmented para uma empresa de ecommerce canadense regulamentada em que trabalhei em 2025, e depois vou explicar por que esses números são enganosos se você os ler da forma errada.
Os números do build
O caso de uso era suporte ao cliente. A empresa estava processando aproximadamente 20 tickets HelpScout por dia, a maioria deles repetitiva: status de pedido, disponibilidade de produtos, perguntas sobre envio, as mesmas perguntas regulatórias que cada cliente em sua categoria faz. O time estava gastando horas em tickets que tinham as mesmas cinco respostas por trás deles. O objetivo era desviar os repetitivos para que os agentes humanos pudessem focar nos casos que realmente precisavam de uma pessoa.
Depois do build, o chatbot estava lidando com 18 a 19 desses tickets por dia. Um ou dois por dia ainda precisavam de um humano. Isso é uma taxa de desvio de >90% em um problema que a empresa estava pagando para funcionários assalariados resolverem.
Aqui está o que custava para rodar, por mês:
| Componente | Custo mensal | |---|---| | n8n em uma instância compartilhada Vultr | ~$6 | | Supabase (vector store + Postgres) | $0 (camada gratuita) | | Claude API (geração de respostas) | ~$5 mensais | | OpenAI API (embeddings) | ~$5 mensais | | Integração HelpScout | $0 (conta existente) | | Total mensal de infra + API | $16 |
O custo do build foi um contrato de consultoria de preço fixo. Não vou publicar esse número aqui porque varia de acordo com escopo e cliente, e colocar uma figura única em uma página pública enganaria mais pessoas do que ajudaria. Se quer o intervalo, é na discovery call que conversamos sobre isso.
Então o custo de execução está em algum lugar nos baixos dois dígitos por mês contra uma taxa de desvio que economizava múltiplas horas de tempo de agente humano por dia da empresa. A economia unitária funcionou aproximadamente no dia em que ligamos o sistema.
Por que o número é enganoso
Lendo a tabela acima, você poderia concluir que RAG é essencialmente gratuito. Uma instância compartilhada no Vultr, uma camada gratuita do Supabase, algumas chamadas de API, pronto. Se você já precificou software empresarial, esses números parecem um erro de digitação.
Eles não são. Mas a tabela está escondendo três coisas.
- O custo de infraestrutura é baixo porque o design absorveu a complexidade. Rodar n8n no tier mais barato do Vultr é bom quando você planejou para a instância falhar e construiu o sistema para que uma falha não custem dados do cliente. É um desastre quando você não fez. A "economia" de rodar em uma box de $6 vs. uma de $60 existe apenas se sua arquitetura consegue tolerar os modos de falha da box de $6. A maioria das pessoas pula essa parte e recebe uma conta pelas consequências depois.
- Os custos de API são baixos porque o retrieval é bom. A coisa mais cara que você pode fazer com um LLM é fazer uma pergunta sem dar a ele o contexto certo. O modelo preenche a lacuna com tokens, e você paga por tokens. Um bom retrieval significa que você envia menos tokens, obtém melhores respostas e paga menos. Um retrieval ruim significa que você paga mais por respostas piores. A diferença entre uma conta de API de $50/mês e uma de $500/mês no mesmo volume é quase sempre a qualidade do que você está recuperando.
- A camada gratuita do Supabase foi o suficiente porque o corpus era pequeno e bem curado. Algumas centenas de artigos de base de conhecimento bem escritos, descrições de produtos limpas, e cópia regulatória revisada pela pessoa de conformidade do cliente. Incorporado uma vez, atualizado raramente. Se você apontar um sistema RAG para cinco anos de páginas Confluence desorganizadas, você vai sair da camada gratuita de qualquer vector store no primeiro fim de semana, e você vai obter respostas piores também. O custo de rodar o sistema acompanha a qualidade do corpus que você aponta para ele.
Então a equação real de custo parece assim:
Custo total = infraestrutura + uso de API + (trabalho para fazer esses dois não importarem)
Para onde o dinheiro realmente vai em um build RAG
- Preparação do corpus. O maior custo único em a maioria dos builds, e aquele que as pessoas mais consistentemente subestimam. Sua documentação existente quase certamente não está em um estado onde um modelo de embedding pode fazer trabalho útil com ela. Páginas se contradizem. Políticas antigas convivem com as novas. Jargão interno não mapeia para o que os clientes realmente perguntam. Alguém tem que ler através dela, decidir o que é autoritativo, reescrever as partes ambíguas, e dividir ou mesclar documentos até que os chunks que um modelo de embedding produz sejam realmente recuperáveis. No build canadense, isso foi semanas de trabalho com o lead de conteúdo do cliente. É trabalho editorial, e é a parte que determina se o resto do sistema vale a pena construir.
- Design de retrieval. O que é recuperado quando? Quantos chunks? Como são re-ranqueados. Se você usa busca híbrida (vetor + palavra-chave), se filtra por metadados, se tem índices separados para diferentes tipos de documento. Essas decisões parecem pequenas isoladamente. Elas se compõem na diferença entre um sistema que responde 90% das consultas corretamente e um que responde 60% e alucinatoriamente preconiza o resto. A maioria do valor de engenharia em um build RAG vive aqui.
- Design de prompt e guardrails. O que o modelo é instruído a fazer com o que recupera. Como lida com perguntas que não consegue responder. Como cita fontes. Como recusa responder coisas fora de seu escopo. Para o cliente de ecommerce regulamentado, isso levou tempo sério. Havia perguntas específicas onde a resposta tinha que incluir um aviso ou redirecionar para um agente humano. Construir essas regras no prompt e verificá-las em centenas de casos de teste é trabalho real.
- Infraestrutura de avaliação. Como você sabe que o sistema está funcionando? Não "parece bom na demo." Medição real contra um conjunto de teste retido, com testes de regressão quando você muda o prompt ou troca o modelo. Sem isso, você não tem como dizer se sua última mudança melhorou ou piorou as coisas. Você também não tem uma resposta defensável quando o cliente pergunta por que o sistema deu uma má resposta para uma pergunta específica.
- Manutenção e drift. Um sistema RAG não é um projeto. É um ativo que precisa ser alimentado. Novos produtos, novas políticas, novas regulamentações. Respostas antigas ficam obsoletas. O sistema precisa de alguém que assista as métricas, atualize o corpus, reteste o prompt, e pegue quando o retrieval começar a puxar as coisas erradas porque o corpus se deslocou sob ele. Este é o custo que ninguém inclui em seu orçamento inicial e que todos descobrem seis meses depois.
Números aproximados para um build como este
Um engagement de discovery para descobrir se RAG é sequer a resposta certa para seu problema: quatro dígitos baixos, pagos, geralmente uma a duas semanas. Às vezes a resposta é "não, você não precisa de RAG, você precisa de uma melhor página de FAQ e três correções de workflow" e esse é um resultado que o cliente deveria estar feliz em pagar.
Um build completo para um caso de uso como o do ecommerce canadense: cinco dígitos baixos a médios dependendo da complexidade, integrações, e quanto do trabalho de corpus o cliente consegue fazer internamente vs. quanto eu faço.
Manutenção contínua: tipicamente um engagement fracionário, de algumas horas por mês a alguns dias, dependendo de quanto o corpus muda e quanto as apostas são altas.
Custos de infraestrutura e API, uma vez que o sistema está construído: geralmente um a dois ordens de magnitude menores do que o custo do build. A maioria dos clientes fica surpresa com isso. Eles esperavam que o custo de execução dominasse. Não domina, a menos que você pule o trabalho de design que mantém o custo de execução pequeno.
Quando RAG é a resposta errada
Se seu caso de uso pode ser resolvido com uma barra de busca boa e uma página de FAQ bem escrita, RAG é excessivo. Se seu corpus é pequeno e estável o suficiente para que fine-tuning funcionaria melhor, RAG é a ferramenta errada.
Os clientes que vi obter mais valor de RAG compartilham três coisas: um problema de consulta repetitiva, de alto volume; uma base de conhecimento que vale a pena investir independentemente; e um time que é sério sobre manutenção após o build. Se dois desses três estão faltando, a matemática não funciona não importa o quão barata a infraestrutura é.
O que a pergunta de custo realmente está perguntando
Quando alguém pergunta quanto RAG custa, o que geralmente significa é "como sei se isto vale a pena?" O número de infraestrutura é a metade fácil. A metade difícil é se o caso de uso justifica o trabalho de corpus, o design de retrieval, a infraestrutura de avaliação, e o compromisso de manutenção.
O build de ecommerce canadense se pagou em meses. A manutenção é contínua e modesta. Custo total ao longo de um ano, incluindo o build, foi uma fração do que uma única contratação adicional de suporte teria custado no mesmo período, e o sistema escala sem aumentos de custo proporcionais.
Mas funcionou porque o caso de uso era certo. O corpus era construível. O time se comprometeu com manutenção. O número no final da fatura foi o resultado dessas decisões, não a entrada para elas.
Se você está tentando descobrir se RAG é a resposta certa para seu problema e quanto custaria realmente em sua situação específica, é para isso que uma discovery call paga é feita. Você recebe um escopo escrito, um orçamento defensável, e uma resposta honesta sobre se deve construir isto ou não.
Qual é seu volume de suporte este trimestre?