Quando você precisa que um LLM se comporte de forma específica para o seu negócio, existem basicamente duas abordagens principais: dizer ao modelo o que fazer (prompt engineering) ou ensiná-lo diretamente através de exemplos (fine-tuning).
A maioria das empresas que está começando com IA não precisa de fine-tuning. Mas existem casos específicos onde prompt engineering não é suficiente — e escolher a abordagem errada vai custar tempo, dinheiro e resultado.
Este artigo explica as duas abordagens com honestidade, incluindo quando cada uma faz sentido e quando não faz.
O que é Prompt Engineering
Prompt engineering é o conjunto de técnicas para instruir um LLM via texto — no próprio contexto da requisição — a se comportar da forma desejada.
Inclui:
- System prompts (instruções de comportamento no início da conversa)
- Few-shot prompting (exemplos de input/output incluídos no prompt)
- Chain-of-thought (instruir o modelo a “pensar passo a passo”)
- Técnicas de estruturação da saída (pedir JSON, markdown, tabelas)
- Instruções de persona e tom de voz
O modelo base não muda. Você muda o contexto que ele recebe.
Analogia: É como dar instruções detalhadas a um funcionário experiente antes de cada tarefa. Ele já tem as habilidades — você está direcionando como aplicá-las.
O que é Fine-tuning
Fine-tuning é um processo de treinamento adicional que modifica os pesos do modelo usando um conjunto de dados específico. Após o fine-tuning, o modelo “incorporou” os padrões dos seus dados de treinamento.
Você prepara exemplos no formato {input: ..., output: ...}, rodas o processo de fine-tuning (que pode levar horas ou dias), e o resultado é um modelo diferente do original — mais especializado para os padrões que você ensinou.
Analogia: É como um treinamento intensivo que muda as habilidades do funcionário de forma permanente. Após o treinamento, ele executa certas tarefas de forma diferente — sem precisar ser instruído toda vez.
A comparação direta
| Critério | Prompt Engineering | Fine-tuning |
|---|---|---|
| Custo inicial | Baixo (seu tempo) | Alto (computação de treinamento) |
| Tempo para implementar | Horas a dias | Dias a semanas |
| Custo por requisição | Normal (tokens do prompt) | Menor por req. se prompt muito longo |
| Atualizável | Imediatamente | Requer re-treinamento |
| Dados necessários | Poucos exemplos | Centenas a milhares de exemplos |
| Transparência | Alta (você vê as instruções) | Baixa (comportamento emergente) |
| Ideal para | Comportamento, tom, formato | Padrões específicos de linguagem/domínio |
| Limitação principal | Janela de contexto, consistência | Custo de dados, custo de manutenção |
Quando Prompt Engineering é suficiente (a maioria dos casos)
Ajuste de tom e personalidade
Você quer que o assistente seja mais formal, use termos específicos do seu setor, evite certas expressões, ou mantenha uma persona específica.
Prompt engineering resolve isso com um system prompt bem construído. Não há motivo para fine-tuning aqui.
System: Você é o assistente da [Empresa].
Comunique-se sempre em português formal.
Use os termos técnicos do setor financeiro adequadamente.
Nunca use gírias ou expressões coloquiais.
Quando não souber a resposta, diga claramente em vez de especular.Seguir um formato de saída
Você precisa que o modelo sempre retorne JSON, sempre estruture a resposta com seções específicas, ou sempre siga um template de resposta.
Few-shot examples no prompt resolvem isso com alta confiabilidade para modelos modernos como GPT-4o e Claude 3.5.
Incorporar conhecimento específico da empresa (RAG é melhor)
Se o objetivo é que o modelo “conheça” seus produtos, processos, clientes ou documentação — RAG é a abordagem certa, não fine-tuning.
Fine-tuning não é uma boa forma de injetar conhecimento factual. O modelo pode “aprender” os padrões do seu texto, mas os fatos são armazenados de forma difusa nos pesos — o que leva a alucinações sofisticadas, onde o modelo parece saber mas erra nos detalhes.
Tarefas de raciocínio geral
Análise, síntese, extração, classificação, tradução — para essas tarefas, um LLM de fronteira com prompt bem construído geralmente supera um fine-tuning de modelo menor ou em modelo base.
Quando Fine-tuning faz sentido
Padrão de linguagem muito específico que prompt não captura
Quando o estilo é tão particular que um prompt não consegue descrever adequadamente — terminologia proprietária, abreviações internas específicas, um estilo de escrita que só quem está no setor entende — fine-tuning pode capturar esses padrões implícitos.
Exemplo real: Uma empresa médica precisava que o modelo transcrevesse laudos usando terminologia anatômica e clínica muito específica, com abreviações internas não-padronizadas. Um prompt descrevendo tudo ficou imenso, inconsistente, e caro. Fine-tuning com 2.000 laudos de exemplo resolveu.
Redução de custo em produção de alto volume
Se você está processando milhões de requisições por dia e cada requisição carrega um system prompt longo (500-1000 tokens), o custo desses tokens de sistema acumula de forma significativa.
Fine-tuning pode “embutir” o comportamento no modelo, eliminando (ou reduzindo) o system prompt e cortando o custo por requisição.
Quando isso faz sentido: Volume muito alto (> 100k requisições/dia), system prompt longo, tarefa bem definida e estável.
Tarefa muito específica com dados próprios abundantes
Classificação com taxonomia proprietária que nenhum modelo público conhece. Extração de campos específicos de documentos com formato único da sua empresa. Geração de texto em formato que não existe no treinamento base.
Se você tem centenas de exemplos de alta qualidade e a tarefa não muda frequentemente, fine-tuning pode oferecer precisão superior ao prompt engineering.
Consistência extrema em produção
Para aplicações onde a variabilidade do modelo é inaceitável — um modelo fine-tuned em muitos exemplos pode ser mais consistente do que um modelo base com prompt.
Os custos reais do fine-tuning (que ninguém fala)
Custo de preparação dos dados
Fine-tuning precisa de dados de alta qualidade. Para um fine-tuning básico, você precisa de 200-500 exemplos mínimos; para resultados bons, 1.000-10.000 exemplos.
Preparar esses dados — criar pares input/output, revisar qualidade, garantir diversidade dos exemplos — leva tempo considerável. Se cada exemplo leva 10 minutos para preparar, 1.000 exemplos são 167 horas de trabalho humano.
Custo de treinamento
Para modelos de fronteira como GPT-4o, o custo de fine-tuning é cobrado por token de treinamento. Para 1.000 exemplos de tamanho médio, o custo pode variar de algumas centenas a alguns milhares de dólares.
Para modelos open-source como Llama ou Mistral rodando na sua infraestrutura, o custo é computacional — instâncias GPU que podem custar dezenas a centenas de dólares por hora de treinamento.
Custo de avaliação e iteração
O primeiro fine-tuning raramente é o melhor. Você vai avaliar, identificar falhas, ajustar os dados, re-treinar. Planeje 3-5 iterações antes de atingir a qualidade desejada.
Custo de manutenção
O negócio muda. Os requisitos mudam. O modelo fine-tuned ficará desatualizado. Re-treinamento periódico é uma realidade — com todos os custos associados.
Regra prática: Fine-tuning faz sentido quando o ganho de qualidade ou a redução de custo operacional superem esses custos em 12-18 meses.
O fluxo de decisão
Você precisa que o modelo se comporte diferente?
│
├── É sobre CONHECIMENTO específico da empresa?
│ └── → Use RAG. Não fine-tuning.
│
├── É sobre TOM, FORMATO ou ESTILO?
│ └── → Tente prompt engineering primeiro.
│ Se não conseguir com prompt, avalie fine-tuning.
│
├── É sobre uma TAREFA MUITO ESPECÍFICA com dados abundantes?
│ └── → Fine-tuning é candidato. Calcule o custo total.
│
└── É sobre REDUÇÃO DE CUSTO em alto volume?
└── → Calcule: economia em tokens > custo de fine-tuning?
Se sim, fine-tuning faz sentido.Combinando as abordagens
Na prática, as melhores soluções frequentemente combinam as duas:
- RAG para conhecimento específico da empresa
- Prompt engineering para comportamento e formato
- Fine-tuning para terminologia específica ou consistência em alta escala
Exemplo: Um modelo fine-tuned no vocabulário específico do setor jurídico, com RAG sobre a legislação relevante, e um system prompt que define o formato das respostas e o nível de formalidade desejado.
Cada camada resolve uma dimensão diferente do problema.
Por onde começar
1. Comece sempre com prompt engineering. É mais rápido, mais barato, e mais fácil de ajustar. Para a maioria dos casos de uso empresariais, você não vai precisar ir além.
2. Meça a qualidade antes de mudar de abordagem. Se o prompt engineering não está funcionando, identifique especificamente onde ele falha. Isso vai guiar se fine-tuning resolve ou se o problema é outro (qualidade dos dados, complexidade da tarefa, etc.).
3. Se for para fine-tuning, comece com poucos exemplos de alta qualidade. 100 exemplos muito bem curados geralmente superam 1.000 exemplos mediocres. Qualidade dos dados de treinamento é tudo.
4. Avalie em dados que o modelo não viu. A métrica que importa não é o desempenho nos dados de treinamento — é o desempenho em dados novos, do mundo real.
Se você está avaliando qual abordagem faz sentido para o seu caso específico e quer uma opinião técnica honesta, fale com a gente. Já implementamos ambas as abordagens em contextos variados e sabemos onde cada uma entrega (e onde decepcionan).
Prompt engineering resolve 80% dos casos com 20% do esforço. Fine-tuning resolve casos específicos que prompt não consegue — mas com custo e complexidade proporcionais. Escolha com base no problema, não na sofisticação percebida da solução.