Toda vez que alguém me pergunta quanto custa construir um sistema RAG, dou a mesma resposta e vejo a cara da pessoa murchar: é pouco, se você sabe o que está fazendo. E é bastante, se não sabe.
Eu sei que não é uma resposta satisfatória. Quem pergunta de custo quer um número. Algo que caiba numa linha do orçamento, que dê pra levar pro financeiro e defender. Então aqui vão números reais de um projeto de verdade, um chatbot com RAG pra uma empresa canadense de e-commerce num setor regulado, em que trabalhei em 2025. Depois explico por que esses números enganam se você ler do jeito errado.
Os números do projeto
O caso de uso era suporte ao cliente. A empresa recebia uns 20 tickets por dia no HelpScout, a maioria repetida: status de pedido, disponibilidade de produto, dúvida de frete e as mesmas perguntas regulatórias que todo cliente daquela categoria faz. O time gastava horas em tickets que, no fundo, tinham sempre as mesmas cinco respostas. O objetivo era tirar os repetidos da fila pra que os atendentes pudessem cuidar dos casos que precisavam mesmo de uma pessoa.
O chatbot entrou no ar em junho de 2025. Nos três meses seguintes, a média semanal de tickets no HelpScout ficou cerca de 40% abaixo da dos três meses anteriores. Numa amostra de uma semana em julho, o registro de perguntas sem resposta indicava o bot respondendo de 18 a 19 perguntas por dia sem passar pra um humano, contra uma média de uns 20 tickets por dia antes do lançamento. Esse segundo número é estimativa minha, não uma taxa de desvio medida, e "respondeu sem passar pra um humano" não é o mesmo que "respondeu certo". Os dois números também contam coisas diferentes: a maioria das perguntas no chat eram dúvidas simples de produto ou status de pedido, muitas de gente que nunca teria aberto um ticket, e quem mandava e-mail direto pro suporte nem passava pelo bot. A cobertura cresceu com trabalho no conteúdo: toda semana, as perguntas sem resposta do registro viravam entradas novas na base. A página do projeto tem o quadro completo.
Isto é o que custava pra rodar, por mês:
| Componente | Custo mensal |
|---|---|
| n8n numa instância compartilhada da Vultr | ~US$6 |
| Pinecone (dois índices, plano starter) | US$0 |
| API do Claude (geração das respostas) | ~US$5 |
| API da OpenAI (embeddings) | ~US$5 |
| Integração com o HelpScout | US$0 (conta que já existia) |
| Total mensal de infra + API | US$16 |
Valores em dólar, com preços de 2025. É só o custo de operação: não inclui o desenvolvimento, o tempo de manutenção nem o plano do HelpScout que a loja já pagava.
O desenvolvimento foi um contrato de consultoria com preço fechado. Não vou publicar esse valor aqui porque ele muda conforme o escopo e o cliente, e um número solto numa página pública ia confundir mais gente do que ajudar. Se quiser a faixa, é na Intro Call que a gente conversa sobre isso.
Ou seja, o custo de operação fica na casa das poucas dezenas de dólares por mês, contra um desvio de tickets que poupava à empresa várias horas de atendente por dia. A conta fechou praticamente no dia em que ligamos o sistema.
Por que esse número engana
Olhando a tabela, dá pra concluir que RAG é praticamente de graça. Uma instância compartilhada na Vultr, o plano gratuito do Pinecone, algumas chamadas de API e pronto. Pra quem já orçou software corporativo, esses números parecem erro de digitação.
Não são. Mas a tabela esconde três coisas.
- A infraestrutura é barata porque o desenho absorveu a complexidade. Rodar n8n no plano mais barato da Vultr funciona quando você planejou pra instância cair e construiu o sistema de um jeito que uma queda não custe dado de cliente. Quando você não fez isso, é um desastre. A "economia" de rodar numa máquina de US$6 em vez de uma de US$60 só existe se a sua arquitetura aguenta as falhas da máquina de US$6. Quase todo mundo pula essa parte e recebe a conta das consequências depois.
- A API é barata porque a busca é boa. A coisa mais cara que você pode fazer com um LLM é perguntar sem dar o contexto certo. O modelo preenche o buraco com tokens, e você paga por token. Busca boa significa mandar menos tokens, receber respostas melhores e pagar menos. Busca ruim significa pagar mais por respostas piores. A diferença entre uma conta de API de US$50 por mês e uma de US$500, no mesmo volume, quase sempre está na qualidade do que você recupera.
- O plano gratuito do Pinecone bastou porque o conteúdo era pequeno e bem cuidado. Algumas centenas de artigos de base de conhecimento bem escritos, descrições de produto limpas e textos regulatórios revisados pela pessoa de compliance do cliente. Indexado uma vez, atualizado de vez em quando. Se você aponta um sistema RAG pra cinco anos de páginas bagunçadas no Confluence, estoura o plano gratuito de qualquer banco vetorial no primeiro fim de semana, e ainda recebe respostas piores. O custo de operação acompanha a qualidade do conteúdo que você dá pro sistema.
Então a equação de custo de verdade fica assim:
Custo total = infraestrutura + uso de API + (trabalho pra que esses dois não pesem)
Pra onde o dinheiro vai num projeto RAG
- Preparar o conteúdo. É o maior custo isolado na maioria dos projetos, e o que as pessoas mais subestimam. Sua documentação quase certamente não está num estado em que um modelo de embeddings consiga fazer algo útil com ela. Tem página contradizendo página. Política velha convivendo com a nova. Jargão interno que não bate com o que o cliente pergunta. Alguém precisa ler tudo, decidir o que vale, reescrever o que está ambíguo e quebrar ou juntar documentos até que os trechos gerados sejam de fato encontráveis. No projeto canadense, isso foram semanas de trabalho com a pessoa responsável pelo conteúdo do cliente. É trabalho editorial, e é ele que decide se vale a pena construir o resto.
- Desenhar a busca. O que é recuperado e quando? Quantos trechos? Como eles são reordenados? Se você usa busca híbrida (vetor + palavra-chave), se filtra por metadados, se tem índices separados pra tipos diferentes de documento. Isoladas, essas decisões parecem pequenas. Somadas, viram a diferença entre um sistema que acerta 90% das perguntas e um que acerta 60% e inventa o resto com toda a confiança. É aqui que mora a maior parte do valor de engenharia de um projeto RAG, e é por essa parte que um consultor de sistemas RAG está sendo pago.
- Prompt e limites. O que o modelo deve fazer com o que recuperou. Como lidar com pergunta que ele não sabe responder. Como citar a fonte. Como recusar o que está fora do escopo. No e-commerce regulado, isso levou tempo de verdade: havia perguntas em que a resposta tinha que trazer um aviso ou mandar o cliente pra um atendente. Colocar essas regras no prompt e conferir em centenas de casos de teste é trabalho de verdade.
- Estrutura de avaliação. Como você sabe que o sistema está funcionando? "Na demo pareceu bom" não conta. Tem que medir contra um conjunto de teste separado, com teste de regressão sempre que você muda o prompt ou troca o modelo. Sem isso, você não tem como saber se a última mudança melhorou ou piorou as coisas. E não tem uma resposta que se sustente quando o cliente pergunta por que o sistema respondeu errado uma pergunta específica.
- Manutenção e desvio. Um sistema RAG precisa ser alimentado. Produto novo, política nova, regulação nova. Resposta antiga fica velha. Alguém precisa acompanhar as métricas, atualizar o conteúdo, testar o prompt de novo e perceber quando a busca começa a puxar a coisa errada porque o conteúdo mudou por baixo dela. É o custo que ninguém coloca no orçamento inicial e que todo mundo descobre seis meses depois.
Números aproximados pra um projeto assim
Um diagnóstico pago pra descobrir se RAG é mesmo a resposta pro seu problema: quatro dígitos baixos, normalmente de uma a duas semanas. Às vezes a resposta é "não, você não precisa de RAG, precisa de uma página de FAQ melhor e de três ajustes de processo", e esse é um resultado pelo qual o cliente deveria pagar feliz.
Um projeto completo como o do e-commerce canadense: cinco dígitos baixos a médios, conforme a complexidade, as integrações e quanto do trabalho de conteúdo o cliente consegue fazer internamente e quanto fica comigo.
Manutenção contínua: normalmente um contrato fracionado, de algumas horas a alguns dias por mês, dependendo de quanto o conteúdo muda e de quanto está em jogo.
Infraestrutura e API, com o sistema pronto: em geral uma ou duas ordens de grandeza abaixo do custo de construção. A maioria dos clientes se surpreende. Eles esperavam que o custo de operação fosse o principal. Não é, a menos que você pule o trabalho de desenho que mantém esse custo pequeno.
Quando RAG é a resposta errada
Se o seu caso se resolve com uma boa barra de busca e uma página de FAQ bem escrita, RAG é exagero. Se o seu conteúdo é pequeno e estável o bastante pra fine-tuning funcionar melhor, RAG é a ferramenta errada.
Os clientes que mais tiraram valor de RAG tinham três coisas em comum: muita pergunta repetida chegando; uma base de conhecimento que valia a pena ter de qualquer jeito; e um time disposto a manter o sistema depois da entrega. Se faltam duas dessas três, a conta não fecha, por mais barata que seja a infraestrutura.
O que a pergunta sobre custo quer saber de verdade
Quando alguém pergunta quanto custa RAG, geralmente quer saber "como eu sei se isso vale a pena?". O número da infraestrutura é a metade fácil. A metade difícil é saber se o caso de uso justifica o trabalho de conteúdo, o desenho da busca, a estrutura de avaliação e o compromisso de manutenção.
O projeto do e-commerce canadense se pagou em meses. A manutenção é contínua e modesta. O custo total de um ano, incluindo a construção, foi uma fração do que uma única contratação a mais no suporte teria custado no mesmo período, e o sistema cresce sem o custo crescer na mesma proporção.
Mas deu certo porque o caso de uso era o certo. O conteúdo dava pra ser construído. O time se comprometeu com a manutenção. O número no fim da fatura foi consequência dessas decisões, e não o ponto de partida delas.
Se você está tentando descobrir se RAG é a resposta pro seu problema e quanto custaria no seu caso, é pra isso que serve o diagnóstico pago da consultoria de sistemas RAG. Você recebe um escopo por escrito, um orçamento que se sustenta e uma resposta honesta sobre construir ou não. Marque uma Intro Call.
Qual é o seu volume de suporte neste trimestre?