Alguém decide "treinar minha própria IA" antes de testar um prompt melhor ou de dar mais contexto ao modelo. Gasta dias configurando GPU, organizando dataset, e no fim o resultado sai pior que uma instrução bem escrita — o modelo ficou mais caro e não ficou mais certo. O erro mais caro em fine-tuning quase nunca é técnico. É decidir fazer fine-tune quando o problema era outra coisa.

O erro oposto existe, custa menos, mas existe: empilhar instrução sobre instrução num prompt gigante tentando produzir tom e formato consistentes em escala — exatamente o problema que fine-tune resolve bem. Os dois erros compartilham o mesmo diagnóstico: pular a pergunta que decide qual caminho é o certo.

Três perguntas decidem antes de qualquer conta de GPU

Existe uma árvore de decisão de três perguntas, e ela resolve a maioria dos casos antes de qualquer GPU alugada. Primeira: o comportamento muda só com instrução melhor? Se sim, é prompt engineering — custo quase zero, resultado em minutos. Segunda: o modelo precisa de conhecimento ou dado que ele não tem? Se sim, é RAG — injeta contexto externo sem retreinar nada, mantém o conhecimento atualizável, mas não muda o comportamento do modelo. Terceira, e só se as duas primeiras não resolveram: o modelo precisa de tom, formato ou estilo consistente em escala, ou rodar barato numa versão pequena? Aí sim entra fine-tune — muda o comportamento, mas trava o modelo num estilo fixo e custa mais para manter em dia.

A régua prática que separa "vale tentar" de "nem começa": fine-tune faz sentido a partir de 200 exemplos de qualidade. Menos de 100 é caminho certo para overfitting — o modelo decora os exemplos em vez de generalizar, e nesse caso nem vale tentar.

Um sistema real resolveu isso com busca, não com treino

O Research Brain, meu sistema que transforma notas, links e vídeos numa base de conhecimento com busca semântica, rodando 100% em modelos locais, é a segunda pergunta da árvore na prática. O problema nunca foi "o modelo se comporta errado"; foi "o modelo não conhece o conteúdo que eu acumulei". Isso apontou direto para RAG — ChromaDB guardando os vetores, sentence-transformers gerando os embeddings — e não para fine-tune.

LEIA TAMBÉM · Caso realRAG entra quando você consegue apontar o que o grep está perdendoRAG é uma engrenagem cara de manter. Só justifica quando você mostra três coisas que o grep está perdendo. No MemSearch a falha era variação de vocabulário sobre 200 lições; outros corpora têm outras falhas.

A lição generaliza: fine-tune não ensina fato novo de forma confiável — ensina comportamento. Quem quer que o modelo "saiba" algo que não sabia antes quase sempre quer RAG, não quer retreinar os pesos do modelo.

LoRA e QLoRA tornam o treino viável fora de um data center

Fine-tuning completo retreina todos os pesos do modelo — precisa de tanta VRAM quanto o próprio modelo ocupa, o que deixa qualquer coisa acima de 7B fora do alcance de hardware de consumidor. LoRA contorna isso: congela os pesos originais e adiciona pequenas matrizes "adaptadoras" — cerca de 1% do total de pesos — treinando só elas. O resultado é um arquivo de adaptador pequeno que se combina com o modelo base na hora de rodar.

QLoRA soma quantização de 4 bits ao modelo congelado, o que corta cerca de 75% da VRAM que LoRA puro ainda exige. Na prática: dá para fazer fine-tune de um modelo de 7B em menos de 10GB de VRAM, ou de um 70B numa única GPU de 24GB usando Unsloth. A troca é sempre a mesma — menos VRAM, mais tempo de treino, um adaptador pequeno em vez de um modelo novo inteiro.

O dataset quebra o resultado antes do treino sequer terminar

A parte técnica do fine-tune raramente é o que estraga o resultado. É o dataset. Um template malformado — ChatML incorreto, por exemplo — faz o modelo treinar em cima de token de lixo: o treino roda do início ao fim, conclui sem erro, e o resultado fica quebrado mesmo assim. Quantidade não compensa: 200 exemplos limpos e diversos superam 2.000 exemplos ruidosos.

Unsloth Studio, lançado em março de 2026, importa dados, treina e exporta numa interface local, sem escrever uma linha de Python. A ferramenta roda de 2 a 5 vezes mais rápido e usa de 50% a 80% menos VRAM que implementações padrão. O custo real de rodar isso: um fine-tune de um modelo de 8B com cerca de 1.000 exemplos sai entre US$1 e US$3 numa GPU alugada (RunPod, RTX 4090), ou sai de graça — e mais devagar — no tier gratuito do Google Colab. Contra esse número, um template errado é o que de fato encarece o processo: refazer um treino de US$2 por causa de um dataset malformado duplica o custo da sessão.

A pergunta nunca é "fine-tune é bom?" — é qual das três perguntas da árvore alguém tem na mão de verdade. Antes de configurar qualquer GPU, testar um prompt melhor. Se não resolver, tentar RAG. Só quando as duas respostas forem "sim, e ainda não resolveu" o fine-tune entra na mesa — e a essa altura, a maior parte do custo que as pessoas gastam em GPU e dataset já era evitável antes de começar.