Fine-tuning vs. RAG: Quando Cada Um Tem ROI Real em Produção

Fine-tuning vs. RAG

Já vimos como reduzir o custo de inferência usando modelos open-weight como Qwen 3.5 no artigo Reduzindo o custo em produção: Qwen 3.5 na AWS vs APIs Comerciais. Mas quando você tem o custo base sob controle, enfrenta outro problema: como dar ao modelo conhecimento específico da sua empresa.

Aqui, quase todo mundo pula direto para o RAG (Retrieval-Augmented Generation) porque o fine-tuning tem fama de ser caro e complexo. Hoje vamos ver por que essa ideia está desatualizada. Esqueça os tutoriais de código por um momento. Vamos falar de números, latência e o custo real de operar isso em produção.

A Armadilha de Sempre Usar RAG

RAG se tornou o padrão. Você tem um problema de conhecimento e joga um banco de dados vetorial por cima. Funciona bem, mas não é a única opção. Treinar modelos open-weight em plataformas como AWS SageMaker ou Google Vertex AI hoje é muito mais acessível. A pergunta correta não é qual tecnologia está na moda, mas qual faz sentido financeiro e operacional para o seu tráfego.

Para Onde Vai o Orçamento

Fazer RAG significa que você paga o tempo todo. Cada vez que seus dados mudam, você precisa gerar embeddings. Você paga o banco de dados vetorial todos os meses. E o maior custo oculto: cada request inclui milhares de tokens de contexto recuperado. Isso dispara o consumo de input tokens. Se você usa um modelo proprietário ou muito pesado, a fatura no final do mês dói.

O fine-tuning funciona diferente. Você paga o cómputo GPU adiantado para treinar o modelo. Depois paga o hosting do endpoint. A vantagem? Como o modelo já memorizou a informação, seus prompts são curtos. Você economiza milhões de input tokens a longo prazo. Com alto volume de consultas, o fine-tuning fica mais barato.

Latência: TTFT e TPOT

Se você mede o tempo até o primeiro token (TTFT), o RAG é naturalmente mais lento. Você precisa vetorizar a consulta, buscar no banco de dados, extrair os chunks, montar um prompt gigante, enviar ao LLM e esperar a resposta. O fine-tuning pula essas passagens — o request chega e o modelo responde diretamente.

Se você mede os tokens por segundo (TPOT), um modelo open-weight ajustado como Qwen 3.5 ou Qwen 3.6 produz palavras muito mais rápido que um modelo proprietário grande conectado a um sistema RAG, como os modelos comerciais da OpenAI ou Claude.

Quando Usar Cada Abordagem

Aqui está um guia rápido para tomar a decisão.

Fine-tuning: se você tem volume e previsibilidade. Se faz classificação massiva, gera JSONs estruturados ou tem muito tráfego sobre um domínio de conhecimento estático, o fine-tuning vence. A baixa latência e a economia em tokens justificam o custo de treinamento. Também é sua melhor opção se você tem SLAs de latência que não suportam o atraso de uma busca vetorial.

RAG: se seus dados mudam todos os dias. Se é uma base de suporte ao cliente que é atualizada constantemente, retreinar o modelo diariamente destruiria seu orçamento. O RAG também é obrigatório se por compliance você precisa mostrar de qual documento exato saiu a resposta.

Combine os dois: se você tem os recursos. Você pode fazer fine-tuning para que o modelo aprenda sobre sua empresa, sua estrutura interna, seus produtos e sua forma de se comunicar, e usar o RAG apenas para buscar dados dinâmicos como preços ou estoque. Você obtém a máxima precisão possível, embora exija maior maturidade na sua equipe de engenharia.

Como Aplicar Esse Modelo Mental

Para levar essa teoria a produção sem queimar o orçamento, recomendo uma abordagem iterativa:

Meça sua baseline de RAG: Isole o custo do seu banco de dados vetorial (Pinecone, pgvector) some o gasto mensal de input tokens que você consome ao injetar contexto.
Compare contra o real: Calcule o custo de subir um endpoint dedicado no AWS SageMaker ou Google Vertex AI para um modelo open-weight como Qwen 3.5 ou Qwen 3.6. Se seu gasto em tokens supera o custo da infraestrutura fixa, você tem o caso de negócio justificado para o fine-tuning.
Meça o impacto do TTFT: Faça testes de carga para medir o Time To First Token. Se seu sistema RAG atual atrasa a resposta e afeta a retenção de usuários, o fine-tuning se torna uma necessidade operacional, não apenas financeira.
Implemente um LLM Router: Se você vai pela rota híbrida, dê ao modelo uma tool para consultar o RAG apenas quando precisar de dados que não memorizou. Se a consulta é sobre conhecimento interno, responda diretamente. Assim você obtém precisão e flexibilidade, mas paga o preço em complexidade arquitetônica. Avalie se seu caso de uso justifica manter ambos os sistemas vivos.

Conclusão

Não assuma que o RAG é o único caminho válido só porque é o mais repetido na indústria de hoje. Tampouco assuma que o fine-tuning é um luxo reservado a gigantes tecnológicos. Em ambientes de produção reais, a viabilidade de um sistema generativo é medida em dólares por milhão de tokens e em milissegundos de latência.

Cruze seus próprios números. Compare o custo mensal da sua infraestrutura vetorial e os input tokens que você queima injetando contexto contra o preço fixo de subir uma instância na AWS e treinar um modelo open-weight altamente otimizado. É muito provável que você descubra que o fine-tuning, ou uma abordagem híbrida orientada por ferramentas (tools), faz muito mais sentido financeiro e operacional para o seu tráfego.

Se você quiser se aprofundar nos números duros de subir esses modelos na nuvem, confira a análise de Qwen 3.5 na AWS vs APIs Comerciais e comece a otimizar sua arquitetura hoje mesmo.