1. What fine-tuning actually is
A pretrained LLM already "knows" an enormous amount from its training data. Fine-tuning doesn't add more knowledge to that base — it keeps training the model's weights on a smaller, curated dataset so it changes how it behaves: the format it answers in, the tone it uses, which tasks it's better calibrated for, or how strictly it follows a schema.
That distinction is the single most common source of confusion: people reach for fine-tuning to "teach the model facts" (a new product catalog, this week's news, internal docs) when that's exactly the job retrieval-augmented generation (RAG) is built for. Fine-tuning is a behavior lever, not a knowledge database.
2. How it works: full fine-tuning vs. LoRA/QLoRA
There are two very different cost profiles here:
| Approach | What changes | Cost profile |
|---|
| Full fine-tuning | Every weight in the model gets updated during training. | Needs the same order of magnitude of compute/memory as pretraining a model of that size — realistically out of reach outside a well-funded lab for anything beyond small models. |
| LoRA (Low-Rank Adaptation) | The original weights stay frozen; small "adapter" matrices are trained alongside them and injected into specific layers (commonly attention layers). | Orders of magnitude cheaper — the insight is that the update a model needs for a new task usually lives in a low-dimensional subspace, so you don't need full-rank matrices to represent it. |
| QLoRA | LoRA on top of a quantized (lower-precision) copy of the base model. | Pushes memory requirements down further — this is what makes fine-tuning a 20B+ model feasible on a single consumer-grade GPU. |
In practice, LoRA/QLoRA-family methods can match or come close to full fine-tuning quality on many tasks while training a tiny fraction of the parameters — which is why they've become the default rather than the exception.
3. RLHF, DPO and friends — teaching preference, not just format
Supervised fine-tuning (SFT) — training on example input/output pairs — teaches a model to imitate a dataset. But a lot of what makes a model "feel" well-behaved (helpful, honest, refusing the right things) comes from a further step: teaching it to prefer some outputs over others.
- RLHF (Reinforcement Learning from Human Feedback): humans rank multiple model outputs for the same prompt, that ranking data trains a separate reward model, and then the LLM is further trained with reinforcement learning to produce outputs the reward model scores highly.
- DPO (Direct Preference Optimization): a newer, simpler alternative that skips training a separate reward model — it optimizes directly on the preference pairs (chosen output vs. rejected output), which is cheaper and more stable to train than full RLHF, at the cost of some of RLHF's flexibility.
This is the step that turns a raw next-token predictor into something that behaves like an assistant — it's a large part of why two models with similar base pretraining can feel very different to talk to.
4. Prompting vs. RAG vs. fine-tuning: the actual decision tree
The order below is the practical consensus, not a personal opinion — and it matters because each step up adds real cost and maintenance burden:
1. Start with prompt engineering. No training data, no infrastructure, no lead time. Most "the model doesn't do X" problems are actually "the prompt doesn't ask for X clearly enough" problems.
2. Add RAG when the gap is knowledge. If the model doesn't know something — proprietary data, information newer than its training cutoff, your internal docs — retrieval solves that without touching the model's weights at all.
3. Reach for fine-tuning when the gap is behavior. If the model already knows the right answer but keeps giving it in the wrong format, tone, or structure — and better prompting and examples in-context can't fix it reliably at scale — that's when updating weights earns its cost.
In production, these three aren't mutually exclusive: a common pattern is a model fine-tuned to reliably output one specific format/tone, fed by RAG for current facts, wrapped in a well-engineered system prompt that handles instructions and edge cases.
5. The real trade-offs nobody puts on the landing page
- Maintenance debt: a fine-tuned model is now a specific artifact you own. When the base model improves, you don't get that improvement for free — you have to re-run the fine-tune on the new base, re-validate it, and redeploy it.
- Data quality is the actual bottleneck. A few hundred sloppy examples can make a fine-tuned model worse than the base model at the very task you were trying to improve — curation matters more than volume.
- Catastrophic forgetting: aggressive fine-tuning on a narrow dataset can degrade the model's general capabilities outside that narrow task — this is one of the reasons LoRA-style approaches (which touch far fewer parameters) are often preferred, they tend to be gentler on everything else the model can do.
- It doesn't fix hallucination on facts it never had. Fine-tuning can make a model confidently wrong in a new format — it's not a substitute for giving the model actual access to the information via RAG or tools.
6. A concrete example
Say a support team wants a model that always replies in a strict JSON schema with a specific set of fields, in a specific tone, even for messy or ambiguous tickets. Prompting alone can get close but occasionally drifts — extra fields appear, tone slips, formatting breaks on edge cases. RAG doesn't help here at all, because the problem isn't missing knowledge — the model already knows how to help with the ticket. This is the textbook case for fine-tuning: a curated set of a few hundred to a few thousand example tickets paired with the exact desired output, trained with LoRA on top of a capable base model, produces a model that holds the format reliably — while RAG (fed by a live knowledge base) stays in the loop for anything that requires current account or product facts.
Takeaway
Fine-tuning changes how a model behaves, not what it knows. Reach for it last, after prompting and RAG have been tried, and budget for the fact that it's an artifact you now have to maintain — not a one-time fix.
1. O que fine-tuning realmente é
Um LLM pré-treinado já "sabe" uma quantidade enorme de coisas vindas dos dados de treinamento. Fine-tuning não adiciona mais conhecimento a essa base — ele continua treinando os pesos do modelo num conjunto de dados menor e curado, pra mudar como ele se comporta: o formato em que responde, o tom que usa, pra quais tarefas ele fica melhor calibrado, ou o quão rigorosamente ele segue um schema.
Essa distinção é a fonte de confusão mais comum: as pessoas recorrem a fine-tuning pra "ensinar fatos ao modelo" (um catálogo de produtos novo, notícias da semana, documentação interna) quando essa é exatamente a função da retrieval-augmented generation (RAG). Fine-tuning é uma alavanca de comportamento, não um banco de dados de conhecimento.
2. Como funciona: fine-tuning completo vs. LoRA/QLoRA
Existem dois perfis de custo bem diferentes aqui:
| Abordagem | O que muda | Perfil de custo |
|---|
| Fine-tuning completo | Todo peso do modelo é atualizado durante o treino. | Precisa de uma ordem de grandeza de compute/memória parecida com pré-treinar um modelo desse tamanho — na prática, fora de alcance fora de um laboratório bem financiado pra qualquer coisa além de modelos pequenos. |
| LoRA (Low-Rank Adaptation) | Os pesos originais ficam congelados; pequenas matrizes "adaptadoras" são treinadas junto e injetadas em camadas específicas (geralmente camadas de atenção). | Ordens de grandeza mais barato — a sacada é que a atualização que um modelo precisa pra uma tarefa nova geralmente vive num subespaço de baixa dimensão, então você não precisa de matrizes de rank completo pra representá-la. |
| QLoRA | LoRA em cima de uma cópia quantizada (precisão reduzida) do modelo base. | Reduz ainda mais os requisitos de memória — é o que torna viável fazer fine-tuning de um modelo de 20B+ numa única GPU de consumidor. |
Na prática, métodos da família LoRA/QLoRA conseguem igualar ou chegar perto da qualidade do fine-tuning completo em muitas tarefas treinando uma fração minúscula dos parâmetros — por isso viraram o padrão em vez da exceção.
3. RLHF, DPO e companhia — ensinando preferência, não só formato
Fine-tuning supervisionado (SFT) — treinar em pares de exemplo entrada/saída — ensina um modelo a imitar um dataset. Mas boa parte do que faz um modelo "parecer" bem-comportado (útil, honesto, recusando as coisas certas) vem de um passo a mais: ensinar ele a preferir algumas saídas em vez de outras.
- RLHF (Reinforcement Learning from Human Feedback): humanos ranqueiam múltiplas saídas do modelo pro mesmo prompt, esses dados de ranqueamento treinam um modelo de recompensa separado, e depois o LLM é treinado mais um pouco com reinforcement learning pra produzir saídas que o modelo de recompensa pontua bem.
- DPO (Direct Preference Optimization): uma alternativa mais nova e simples que pula treinar um modelo de recompensa separado — otimiza direto sobre os pares de preferência (saída escolhida vs. saída rejeitada), o que é mais barato e mais estável de treinar que o RLHF completo, ao custo de parte da flexibilidade do RLHF.
Esse é o passo que transforma um previsor cru de próximo token em algo que se comporta como um assistente — é boa parte do motivo pelo qual dois modelos com pré-treino base parecido podem parecer muito diferentes na hora de conversar.
4. Prompting vs. RAG vs. fine-tuning: a árvore de decisão de verdade
A ordem abaixo é o consenso prático, não uma opinião pessoal — e importa porque cada degrau a mais adiciona custo real e carga de manutenção:
1. Comece com prompt engineering. Sem dado de treino, sem infraestrutura, sem tempo de preparação. A maioria dos problemas de "o modelo não faz X" na verdade é "o prompt não pede X com clareza suficiente".
2. Adicione RAG quando a lacuna é de conhecimento. Se o modelo não sabe algo — dado proprietário, informação mais nova que o corte de treinamento dele, sua documentação interna — retrieval resolve isso sem tocar nos pesos do modelo.
3. Recorra a fine-tuning quando a lacuna é de comportamento. Se o modelo já sabe a resposta certa mas continua entregando no formato, tom ou estrutura errados — e prompting melhor e exemplos no próprio contexto não resolvem isso de forma confiável em escala — é aí que atualizar os pesos compensa o custo.
Em produção, essas três coisas não são mutuamente exclusivas: um padrão comum é um modelo com fine-tuning pra manter um formato/tom específico de forma confiável, alimentado por RAG pra fatos atuais, envolto num system prompt bem construído que cuida de instruções e casos extremos.
5. Os trade-offs reais que ninguém coloca na landing page
- Dívida de manutenção: um modelo com fine-tuning agora é um artefato específico que você é dono. Quando o modelo base melhora, você não ganha essa melhoria de graça — precisa rodar o fine-tune de novo em cima da nova base, revalidar e reimplantar.
- Qualidade do dado é o gargalo de verdade. Algumas centenas de exemplos malfeitos podem deixar um modelo com fine-tuning pior que o modelo base na mesma tarefa que você queria melhorar — curadoria importa mais que volume.
- Esquecimento catastrófico: fine-tuning agressivo num dataset estreito pode degradar as capacidades gerais do modelo fora dessa tarefa estreita — esse é um dos motivos pelos quais abordagens estilo LoRA (que tocam muito menos parâmetros) costumam ser preferidas, elas tendem a ser mais suaves com o resto do que o modelo sabe fazer.
- Não resolve alucinação sobre fatos que ele nunca teve. Fine-tuning pode deixar um modelo errado com confiança num formato novo — não substitui dar ao modelo acesso de verdade à informação via RAG ou ferramentas.
6. Um exemplo concreto
Digamos que um time de suporte quer um modelo que sempre responda num schema JSON rígido, com um conjunto específico de campos, num tom específico, mesmo pra tickets bagunçados ou ambíguos. Só prompting consegue chegar perto mas às vezes escorrega — campos extras aparecem, o tom foge do combinado, a formatação quebra em casos extremos. RAG não ajuda nada aqui, porque o problema não é falta de conhecimento — o modelo já sabe como ajudar com o ticket. Esse é o caso de livro-texto pra fine-tuning: um conjunto curado de algumas centenas a alguns milhares de tickets de exemplo pareados com a saída exata desejada, treinado com LoRA em cima de um modelo base capaz, produz um modelo que mantém o formato de forma confiável — enquanto o RAG (alimentado por uma base de conhecimento viva) continua no circuito pra qualquer coisa que exija fatos atuais de conta ou produto.
Resumo
Fine-tuning muda como um modelo se comporta, não o que ele sabe. Recorra a ele por último, depois de tentar prompting e RAG, e já conte com o fato de que é um artefato que você vai precisar manter — não um conserto de uma vez só.