Quando uma empresa tem de meter o seu próprio conhecimento num modelo de linguagem —o seu catálogo, os seus manuais, o seu histórico de tickets— aparece quase sempre a mesma discussão: RAG, fine-tuning ou simplesmente meter tudo no contexto? A conversa costuma girar em torno da qualidade: qual responde melhor, qual alucina menos, qual é mais fácil de manter.
É a pergunta errada para começar. Na maioria dos projetos que vemos, a decisão não se quebra pela qualidade —as três podem dar uma qualidade aceitável— mas pelo custo por tarefa. E aí as três opções comportam-se de forma radicalmente diferente consoante o seu volume. Uma que parece a mais barata na demo torna-se a mais cara em produção, e vice-versa.
As três opções, numa frase de custo
Contexto longo. Mete o conhecimento relevante diretamente no prompt em cada solicitação. Zero infraestrutura, zero preparação. Mas paga esses tokens de cada vez que pergunta. É o “copiar e colar o manual inteiro” antes de cada consulta.
RAG (geração aumentada por recuperação). Em vez de mandar todo o conhecimento, um motor de busca recupera apenas os fragmentos relevantes para cada consulta e esses —e só esses— viajam no prompt. O contexto por solicitação mantém-se pequeno. Em troca, monta e mantém uma tubagem: dividir os documentos, gerar embeddings, uma base vetorial, a lógica de recuperação.
Fine-tuning. Ajusta o próprio modelo com os seus dados. Paga um custo de treino por antecipação, mas depois o conhecimento (ou o estilo, ou o formato) vive dentro do modelo, por isso o prompt de cada solicitação pode ser muito mais curto: já não é preciso reenviar instruções nem exemplos.
Onde se paga cada uma
A chave está em distinguir custo de arranque (uma vez) de custo por tarefa (cada solicitação, para sempre). É a mesma lógica do custo por tarefa: o que lhe afunda o orçamento não é o preço de tabela, é o que multiplica pelo seu volume mensal.
Contexto longo tem custo de arranque quase zero e o custo por tarefa mais alto dos três. Se arrasta 8.000 tokens de manual em cada consulta e resolve cem mil consultas por mês, pagou esse manual cem mil vezes. Barato de montar, caro de operar.
Fine-tuning inverte a divisão: custo de arranque alto (preparar o dataset, treinar, e voltar a treinar cada vez que o conhecimento muda), mas o custo por tarefa mais baixo, porque o prompt emagrece. É a opção de “pagar muito uma vez para pagar pouco muitas vezes”.
RAG fica no meio nas duas dimensões: um arranque moderado (a tubagem de recuperação) e um custo por tarefa baixo, porque só manda os fragmentos que fazem falta, não tudo. Além disso tem um custo que as outras duas não têm tão visível: cada consulta paga também a recuperação (embedding da pergunta, busca na base vetorial), embora costume ser pequeno face à poupança em tokens do modelo.
Um exemplo com números
Suponhamos uma tarefa que precisa de se apoiar numa base de conhecimento. Resposta de 300 tokens nos três casos. Preços ilustrativos de 2 $ por milhão de entrada e 12 $ por milhão de saída.
| Abordagem | Tokens de entrada por tarefa | Custo por tarefa |
|---|---|---|
| Contexto longo (manual inteiro) | 8.000 | 0,0196 $ |
| RAG (só fragmentos relevantes) | 1.500 | 0,0066 $ |
| Fine-tuning (prompt mínimo) | 500 | 0,0046 $ |
À primeira vista, fine-tuning ganha. Mas falta a outra metade. Se faz mil tarefas por mês, a diferença entre contexto longo e fine-tuning é de uns 15 $ mensais: não compensa nem de longe o custo de preparar e manter um modelo ajustado. Se faz um milhão, essa mesma diferença são uns 15.000 $ por mês —180.000 $ por ano—, e de repente o fine-tuning paga-se sozinho em semanas.
O ponto de equilíbrio não é marcado por qual opção é “melhor”, mas por quantas vezes vai repetir a tarefa.
Como decidir sem instrumentar meia equipa
Três perguntas ordenam quase todos os casos:
Qual é o seu volume? Com volumes baixos, o contexto longo ganha quase sempre: o custo por tarefa é irrelevante face ao tempo de engenharia que poupa. Não monte uma tubagem de RAG para resolver mil consultas por mês.
Com que frequência muda o conhecimento? Se a sua base muda diariamente —preços, inventário, políticas—, o fine-tuning é uma armadilha: retreinar constantemente é caro e lento. RAG brilha precisamente aqui, porque atualizar é tão simples como mudar os documentos indexados. O fine-tuning encaixa quando o que ensina é estável: um tom, um formato de saída, um jargão de domínio.
O que está a meter, conhecimento ou comportamento? RAG é para saber coisas (factos, documentos, dados que se consultam). Fine-tuning é para comportar-se de certa forma (responder com um estilo, seguir uma estrutura, falar a sua linguagem técnica). Confundi-los é o erro mais caro: tentar meter uma base de conhecimento mutável por fine-tuning, ou forçar um formato rígido à custa de esticar o prompt em cada solicitação.
E não são exclusivos. A combinação mais habitual em produção é fine-tuning para o comportamento + RAG para o conhecimento: um modelo ajustado para responder como quer, alimentado com fragmentos recuperados na hora. Paga-se o arranque do fine-tuning uma vez, mantém-se o conhecimento barato com RAG, e o prompt por tarefa fica curto dos dois lados.
Um aviso honesto
Os números deste artigo são um exemplo para ilustrar o mecanismo, não uma medição do seu caso. O ponto de equilíbrio real depende do seu volume, de quanto contexto arrasta hoje cada solicitação e de com que frequência muda o seu conhecimento. Pode estar em dez mil tarefas por mês ou em dez milhões.
O que não muda é a ordem da decisão: primeiro meça quanto lhe custa hoje uma tarefa e quantas faz, e só depois escolha arquitetura. Escolher pelo que se usa —“toda a gente faz RAG”— em vez de pelos seus números é a forma mais habitual de acabar a pagar a mais por uma arquitetura que o seu volume não justifica.
Esta peça faz parte do cluster sobre o custo por tarefa de IA, o guia que ancora tudo o resto.
Na e-ficient medimos o custo por tarefa de empresas que já têm IA em produção, incluindo quanto lhe custaria cada arquitetura no seu volume real. A auditoria inicial não tem custo e devolve um diagnóstico em 72 horas.