Prompt engineering vs fine-tuning: quando treinar um modelo e quando não treinar

Prompt engineering resolve a maioria dos casos que parecem pedir fine-tuning, porque o problema costuma estar na instrução mal formulada, não no modelo. Fine-tuning só compensa quando o padrão exigido não cabe no prompt, quando o estilo precisa ficar nos pesos ou quando o volume de requisições justifica um modelo menor. A decisão é técnica e tem critérios concretos, que eu detalho abaixo com os números que uso em produção.

Toda vez que alguém me diz que precisa fazer fine-tuning, a minha primeira pergunta é a mesma: você já tentou resolver com prompt engineering? Na maioria das vezes a resposta é não, e na maioria das vezes um prompt bem estruturado teria resolvido. Não é que fine-tuning seja ruim, é que a escolha entre os dois costuma ser feita antes de testar o caminho mais simples, e fine-tuning tem custos reais que as pessoas subestimam até precisar pagar por eles.

Trabalhei com essa escolha em contexto de produção numa fintech, e aprendi da forma mais cara possível o que cada caminho cobra. Neste artigo você vai entender quando cada abordagem faz sentido, quais critérios distinguem de verdade um caso do outro, quantos exemplos cada uma pede e como evitar o ciclo de fine-tuning que consome semanas e não entrega o que prometeu na reunião de kickoff.

O que prompt engineering e fine-tuning fazem de verdade?

Prompt engineering é o trabalho de estruturar as instruções que você passa para o modelo para obter respostas melhores e mais consistentes. Isso inclui o contexto de sistema, exemplos do comportamento esperado, o formato de saída, a cadeia de raciocínio e as restrições explícitas. O modelo não muda em nada nesse processo. O que muda é a qualidade do que você comunica a ele, e essa qualidade costuma ser o gargalo real.

Fine-tuning ajusta os pesos do modelo com exemplos do seu domínio. O modelo aprende padrões que você não consegue comunicar de forma eficiente pelo prompt, e ao final você tem uma versão especializada no que treinou. A diferença fundamental cabe numa frase: prompt engineering muda a comunicação com o modelo, fine-tuning muda o modelo em si. Essa distinção define custo, prazo e manutenção de tudo que vem depois.

Por que prompt engineering resolve mais do que parece?

Modelos como Claude, GPT e Gemini foram treinados em volumes de dados que a maioria das empresas nunca vai superar com fine-tuning. A capacidade de seguir instruções complexas, adotar estilos específicos e raciocinar sobre problemas do domínio já está nos pesos. O problema quase sempre é que a instrução chegou mal formulada, com contexto insuficiente ou com o formato de saída deixado em aberto para o modelo adivinhar.

Antes de concluir que o prompt não resolve, vale conferir se você já tentou incluir de três a cinco exemplos do comportamento esperado no próprio prompt, pedir que o modelo explique o raciocínio antes da resposta final, especificar o formato de saída com estrutura, tamanho e campos obrigatórios, adicionar restrições negativas sobre o que ele não deve fazer e reduzir a aleatoriedade da geração nas tarefas que precisam de consistência. São cinco ajustes baratos, e eu raramente vejo os cinco aplicados juntos.

Testar com três exemplos e concluir que prompt não funciona é o erro mais comum nessa avaliação. Boa parte do que parece falha de prompt é falta de iteração suficiente, e iteração aqui significa medir cada versão contra o mesmo conjunto de casos. O artigo sobre prompt engineering na prática mostra como escrever instruções que o modelo realmente segue, e é por ali que eu começo em qualquer projeto novo.

Quando o prompt realmente não resolve?

Existem casos genuínos em que fine-tuning é a resposta certa, e reconhecê-los evita o erro inverso, que é iterar prompt para sempre quando o problema pede outra solução. O primeiro é volume de exemplos que não cabe no prompt: se você precisa de cinquenta exemplos para o modelo seguir o padrão de forma consistente, o custo por requisição sobe, a latência aumenta e o contexto cheio de exemplos começa a criar interferência entre eles.

O segundo caso é estilo muito específico e consistente. Quando o modelo precisa escrever no dialeto técnico de um setor nichado, no formato de documentos jurídicos ou no padrão de comunicação interna de uma empresa, fine-tuning aprende esse padrão de forma mais estável do que qualquer instrução. O estilo que está no prompt pode ser deslocado por contexto conflitante na mesma conversa. O estilo que está nos pesos é bem mais difícil de quebrar.

O terceiro é custo e latência em escala. Um modelo menor com fine-tuning pode substituir um modelo grande com prompt longo em tarefas bem definidas, e quando você processa milhões de requisições por dia a economia é expressiva. O quarto é conhecimento estável que não está na web e exige alta precisão, como vocabulário interno e estrutura de dados proprietária. Para conhecimento que muda com frequência, RAG é quase sempre melhor que fine-tuning.

Quantos exemplos cada abordagem pede?

Esse é o número que mais muda a decisão, então vale ter a régua à mão. A OpenAI aceita fine-tuning supervisionado com um mínimo de 10 exemplos, relata ganhos a partir de 50 a 100 e recomenda começar com 50 demonstrações bem feitas antes de ampliar. Na minha prática, para colocar um modelo treinado em produção com alguma estabilidade, eu peço pelo menos 500 exemplos revisados, porque abaixo disso o comportamento oscila entre um ciclo e outro.

A tabela deixa claro por que eu começo pelo prompt em qualquer projeto: o custo de errar é de minutos, não de semanas. O detalhe que mais importa está na última linha, porque modelo base muda com frequência e cada troca reabre o ciclo de fine-tuning inteiro, enquanto o prompt costuma sobreviver à troca com pequenos ajustes. A fonte oficial com a orientação de quantidade está no guia de fine-tuning supervisionado da OpenAI.

Quais custos do fine-tuning as pessoas subestimam?

Fine-tuning parece mais simples do que é quando você só enxerga a etapa de treinamento. Dados de qualidade são a parte mais cara: você precisa de centenas ou milhares de exemplos bem anotados e revisados, e coletar esses exemplos de fontes reais, anotar corretamente e limpar o ruído leva tempo e dinheiro que raramente estão no orçamento inicial. Na minha experiência, coleta e limpeza são 60% do trabalho real, e a maioria planeja como se fossem 10%.

O primeiro ciclo quase nunca acerta, então você vai passar por várias iterações de treinamento e avaliação antes de chegar num modelo satisfatório, e cada ciclo tem custo de processamento e, mais importante, custo de tempo da equipe para avaliar os resultados. Manutenção é permanente: quando o comportamento desejado muda, você refaz. Um prompt você atualiza em minutos, um modelo treinado exige novo ciclo, e essa dívida técnica fica invisível enquanto o projeto está estável.

Avaliação rigorosa é obrigatória e costuma ser a etapa mais ignorada. Como você sabe que o modelo treinado é melhor que o modelo base com bom prompt? Você precisa de benchmark com exemplos de teste separados dos de treinamento, métricas definidas antes do treinamento e comparação sistemática entre as duas abordagens. Sem isso, o que você tem é confiança sem evidência, e confiança sem evidência em produção custa caro na primeira semana com usuário real.

O que avaliar antes de decidir?

A decisão fica mais clara quando você tem respostas concretas para quatro perguntas. Qual é a métrica de sucesso, taxa de acerto em classificação, qualidade medida por avaliadores humanos ou cobertura de casos esperados? Sem métrica definida não dá para comparar as duas abordagens de forma honesta. Quantos exemplos você tem com qualidade suficiente para treinar? Menos de algumas centenas raramente produz fine-tuning que supera um bom prompt.

Com que frequência o comportamento esperado vai mudar? Se muda todo mês, o custo de manutenção do modelo treinado pode superar o ganho em poucos ciclos. Qual é o volume de requisições esperado? Em volumes baixos, o custo do prompt longo raramente justifica o investimento em fine-tuning, e em volumes altos a conta precisa ser feita com o modelo menor mantendo a qualidade do maior, não só com o preço por token na planilha.

Qual é o impacto de tomar a decisão errada?

Escolher fine-tuning quando prompt resolve tem consequências concretas: ciclos de treinamento que consomem semanas, dados que precisam ser coletados e anotados, benchmarks construídos do zero, e no final muitas vezes o resultado não é melhor do que o prompt bem iterado teria entregado em dois dias. Eu já vi projeto de três meses terminar com um modelo treinado que perdia para o modelo base com cinco exemplos no prompt.

Escolher prompt quando fine-tuning era necessário tem um custo diferente: inconsistência em produção, prompts que crescem sem controle até ocupar boa parte da janela de contexto, requisições caras que poderiam ter sido feitas por um modelo menor e mais barato. Nos dois casos o custo aparece depois, não durante a decisão, e é por isso que a decisão precisa de critério explícito e não de preferência de quem está no projeto.

Que checklist usar para decidir entre os dois?

Antes de considerar fine-tuning, eu passo por cinco perguntas na ordem. O problema pode ser descrito em texto de forma clara? Se sim, começo pelo prompt. Já testei variações de prompt com exemplos few-shot e ainda não funcionou? Se não fiz isso, não avanço. Tenho pelo menos 500 exemplos de alta qualidade bem anotados? Menos do que isso e o resultado vai ser instável. O problema real é custo ou latência em escala? Se for, calculo o retorno antes de começar.

A quinta pergunta é a que mais gente pula: tenho capacidade de manter o modelo quando o base evoluir? Se não, a dívida técnica acumula rápido e o modelo treinado vira legado em poucos meses. Na minha experiência, mais de 80% dos casos travam na primeira ou na segunda pergunta, o que significa que a maioria das conversas sobre fine-tuning termina com um prompt melhor e nenhum treinamento, e isso é um bom resultado.

Quais são os erros mais comuns nessa escolha?

Tentar fine-tuning antes de esgotar o prompt é o mais frequente: o modelo errou em alguns casos e a pessoa vai direto para "precisa treinar" sem ter testado variações de instrução, formato ou exemplos. Usar fine-tuning como substituto de validação é o segundo: você pode treinar um modelo para se comportar de um jeito e ele ainda vai errar em casos extremos, porque validação de saída é camada separada, sempre, com ou sem treinamento.

Ignorar a qualidade dos dados de treino é o terceiro, e um conjunto com mil exemplos ruins produz um modelo pior que o base. Não avaliar em distribuição real é o quarto: testar só no conjunto de validação que você mesmo gerou não é avaliação suficiente, o modelo precisa ser testado com dados que ele nunca viu, de preferência vindos de produção. Para acompanhar se o modelo treinado continua bem depois do deploy, o artigo sobre quando retreinar um modelo de IA cobre os sinais de degradação.

Quais são as dúvidas mais comuns sobre prompt engineering e fine-tuning?

Fine-tuning garante respostas mais consistentes do que prompt?

Depende do que você treinou e de como avaliou. Fine-tuning bem feito com dados de qualidade pode melhorar a consistência para padrões específicos, e fine-tuning com dados ruidosos pode criar inconsistências novas que não existiam no modelo base. Prompt bem estruturado com temperatura baixa já oferece consistência razoável para a maioria dos casos. Testar os dois com a mesma métrica é a única forma de saber qual é melhor para o seu caso.

Posso fazer fine-tuning e prompt engineering ao mesmo tempo?

Sim, e em muitos casos é o que faz sentido. Um modelo treinado ainda recebe instruções no prompt: o fine-tuning ensina o padrão base, e o prompt define o comportamento específico de cada requisição, como formato de saída e restrições daquele contexto. As duas técnicas não são mutuamente exclusivas, e o erro é achar que treinar dispensa escrever bem a instrução, porque não dispensa em nenhum caso que eu tenha visto em produção.

Quanto tempo leva para ver resultado com fine-tuning?

Depende do provedor e do volume de dados. Alguns entregam o modelo treinado em horas, outros levam dias, e isso é a parte previsível do prazo. O tempo mais longo costuma ser a coleta e a anotação dos dados de treinamento, não o treinamento em si, e essa etapa não aparece em nenhuma tabela de preço do provedor. Se o projeto tem prazo de duas semanas, prompt engineering entrega dentro dele e fine-tuning quase nunca.

Fine-tuning funciona para qualquer tipo de tarefa?

Funciona melhor para tarefas com padrões claros e exemplos suficientes, como classificação, extração em formato fixo e geração num estilo bem definido. Para raciocínio complexo, tarefas abertas ou domínios onde o "correto" é difícil de definir com exemplos, fine-tuning tem retorno menor, e a própria OpenAI orienta repensar a tarefa ou o prompt antes de adicionar mais dados quando 50 exemplos não movem nada.

Por onde começar hoje?

Prompt engineering versus fine-tuning não é escolha ideológica, é decisão técnica com critérios concretos: volume de exemplos necessário, frequência de mudança no comportamento esperado, escala de requisições e qualidade dos dados disponíveis. Comece pelo prompt, itere com rigor antes de concluir que não resolve, e só se depois da iteração você ainda tiver problema de consistência em escala, avalie fine-tuning com dados reais e um benchmark separado.

O próximo passo prático cabe numa semana: monte um conjunto de vinte a trinta casos de teste representativos do seu problema, itere o prompt de forma sistemática medindo o resultado em cada versão e documente o que mudou entre versões e o impacto por categoria de caso. Para avaliar se o modelo está entregando o que deveria em produção, o artigo sobre LLM como juiz mostra como estruturar essa medição além do achismo.