A tese desta página: fine-tuning ensina comportamento. Fatos são recuperação. Confundir os dois é a origem de praticamente todo o desperdício que existe neste assunto e o pedido que mais aparece ("queremos treinar o modelo com a nossa base de conhecimento") é exatamente essa confusão, formulada com clareza. A base de conhecimento é um índice. O que fine-tuning pode ensinar é como responder a partir dela.
O que fine-tuning NÃO resolve
não injeta fatos de forma confiável: ele aprende a distribuição, não a tabela
não atualiza nada: mudou um preço, é rodada nova não existe UPDATE em peso
não cita fonte: o que virou peso perdeu a proveniência para sempre
não conserta um modelo ruim para a tarefa: piora um pouco tudo o mais
Onde ele é a resposta certa
formato rígido e consistente que o prompt não sustenta a longo prazo
tom e voz específicos, difíceis de descrever e fáceis de exemplificar
tarefa estreita em que um modelo pequeno passa a bater um grande
economia de prompt: mover 5 mil tokens de instrução para dentro dos pesos
Explore cada etapa →
A matemática, num só lugar
As 4 contas que decidem tudo e a terceira é a que costuma faltar. Clique em qualquer uma para pular direto para a etapa que a explica.
Honestidade, antes de começar: as quatro calculadoras rodam contas de verdade sobre o Llama 3 8B as mesmas dimensões da primeira página da série, para que os números sejam conferíveis contra a literatura. A conta de LoRA e a de memória de treino são exatas dadas as dimensões. O intervalo de confiança é o de Wilson, que é o correto para amostra pequena. Os preços são parâmetro editável e variam muito por provedor. E há uma estimativa deliberadamente grosseira: quantas passagens um fato precisa para grudar nos pesos usamos 8, que é ordem de grandeza plausível e não um número medido. Ela só aparece na etapa 4, e serve para comparar ordens de grandeza, não para orçar.
Antes de qualquer conta, a pergunta que decide o resto: o que exatamente precisa mudar? A árvore abaixo tem três perguntas e resolve a grande maioria dos casos reais quase sempre num degrau bem antes do fine-tuning.
A árvore de decisão
Por que a ordem importa tanto
Cada degrau custa cerca de uma ordem de grandeza mais que o anterior não em dólares de computação, que são baratos, mas em tempo de gente e em dívida permanente. Um prompt você edita em produção; um conjunto de dados você mantém para sempre. Subir um degrau sem provar que o anterior não resolve é o erro caro deste assunto.
O degrau que todo mundo pula
Entre few-shot e fine-tuning existe um degrau que quase ninguém tenta: melhorar o prompt com os exemplos que você já coletou para o fine-tuning. Se você tem 500 exemplos revisados, tem material para escrever um prompt muito melhor do que o atual e para descobrir que o problema era ambiguidade na instrução, não falta de treino. Sai de graça e responde a pergunta antes de gastar.
Full fine-tune reescreve todos os pesos: os 8 bilhões saem do treino diferentes do que entraram. LoRA faz outra coisa congela o modelo inteiro e acrescenta, ao lado de cada matriz, duas matrizes finas cujo produto é somado à original. Você treina só as duas finas.
A calculadora de LoRA · Llama 3 8B
Treináveis
Fração do modelo
Fórmula · parâmetros de um adapter
W' = W + (α/r)·BA · P = L · Σmr(d_inm + d_outm)
W é a matriz original, congelada. B é [d_out × r] e A é [r × d_in]: o produto tem a forma de W, mas posto no máximo r. α/r é uma escala que mantém o efeito comparável quando você muda o rank. O ponto: os parâmetros crescem linearmente com r, enquanto a matriz original tem d_in × d_out. Com r = 16 numa matriz 4096×4096, você troca 16,8 milhões de parâmetros por 131 mil 0,8% deles.
A memória de treino, que é o argumento de verdade
Escolhendo o rank: comece em 8 ou 16 e só suba se a avaliação mostrar que faltou capacidade. Rank alto num conjunto pequeno é a receita para decorar: o adapter tem graus de liberdade de sobra para memorizar os exemplos em vez de extrair a regra. E o sinal disso não é loss de treino ruim é loss de treino excelente com desempenho pior no conjunto de teste. Que é a etapa 5, e é por isso que ela existe.
A pergunta "quantos exemplos eu preciso?" tem uma resposta menor do que quase todo mundo espera, e uma condição maior. Centenas a poucos milhares resolvem a maior parte dos casos de comportamento desde que cada um esteja certo. O ruído é aprendido com exatamente a mesma fidelidade que o sinal.
O custo da rodada
Qualidade do conjunto
O número que choca: repare no custo de computação que a calculadora devolve. Para um conjunto de mil exemplos, ele costuma sair em dezenas de dólares. Isso significa que a computação nunca foi o gargalo o gargalo é montar e revisar os mil exemplos, que custa semanas de uma pessoa que entende do assunto. Toda vez que alguém diz "fine-tuning é caro", está falando disto, e está certo. Só não é sobre GPU.
o formato, e a checagem que ninguém faz
// Um objeto por linha. O que o modelo aprende é a produzir a// ÚLTIMA mensagem dado tudo o que veio antes inclusive o system.
{"messages": [
{"role": "system", "content": "Você é o triador de chamados da Acme."},
{"role": "user", "content": "não consigo emitir a nota do pedido 8812"},
{"role": "assistant", "content": "{\"fila\":\"fiscal\",\"prioridade\":2}"}
]}
// ARMADILHA: se o system aqui for diferente do que você usa em// produção, você treinou um comportamento que nunca vai disparar.// O system do treino tem que ser byte a byte o de produção.
import json, hashlib
from collections import Counter
linhas = [json.loads(l) for l inopen("treino.jsonl")]
# 1. Duplicatas exatas: inflam o conjunto e viram memorização
h = [hashlib.sha256(json.dumps(x, sort_keys=True).encode()).hexdigest()
for x in linhas]
print("duplicatas:", len(h) - len(set(h)))
# 2. System inconsistente: o erro silencioso mais comum
systems = Counter(x["messages"][0]["content"] for x in linhas
if x["messages"][0]["role"] == "system")
print("variantes de system:", len(systems)) # tem que ser 1# 3. Vazamento treino/teste: o que transforma avaliação em teatro
teste = {json.loads(l)["messages"][1]["content"]
for l inopen("teste.jsonl")}
treino = {x["messages"][1]["content"] for x in linhas}
print("vazamento:", len(teste & treino)) # tem que ser 0
O modelo não guarda o que você mostrou. Ele guarda uma regularidade extraída daquilo e a diferença entre as duas coisas é toda a diferença entre um fine-tuning que funciona e um que decora. Quando ele decora, o sinal é loss de treino excelente e desempenho pior no que importa.
O que fica, o que generaliza e o que se perde
Mas a pergunta prática não é sobre teoria de aprendizado é sobre orçamento. Se você quer que o modelo saiba N fatos, quanto custa cada caminho?
Ensinar contra recuperar
Honestidade · o número 8 é um chute educado
A conta acima assume que um fato precisa de ~8 passagens para grudar nos pesos. Esse número não foi medido: é ordem de grandeza plausível a partir do que se sabe sobre frequência e memorização. A comparação continua valendo mesmo se ele estiver errado por um fator de 3 porque a diferença entre os dois caminhos não é de fator, é de natureza: um fato indexado se atualiza com um upsert, um fato treinado exige rodada nova. Nenhum ajuste desse número muda a conclusão.
A questão em aberto
A curva que relaciona frequência no treino e probabilidade de memorização é um assunto de pesquisa ativo, e é o que separa "visto uma vez" de "visto mil vezes". Ela merecia uma página própria com dados reais e não teria como ser honesta aqui, desenhada à mão. Por isso ela não aparece: uma curva plausível e inventada seria pior do que não ter curva nenhuma.
Armadilha de produção: o esquecimento é gradual e silencioso, não catastrófico e visível. O modelo ajustado para triagem de chamados continua conversando normalmente só ficou um pouco pior em raciocínio longo, um pouco pior em código, um pouco pior em outra língua. Nada disso aparece no conjunto de teste da sua tarefa, porque ele só mede a sua tarefa. Se o modelo faz mais de uma coisa em produção, o conjunto de teste precisa cobrir as outras também inclusive as que você não mudou de propósito.
Esta é a etapa que costuma não existir. Roda-se o treino, olha-se meia dúzia de saídas, alguém diz "ficou melhor" e vai para produção. O problema não é a falta de rigor: é que "melhor" tem uma largura, e ela é bem maior do que a intuição sugere.
Por que Wilson e não o intervalo normal que todo mundo usa (p ± z√(p(1−p)/n))? Porque com amostra pequena ou acerto perto de 100%, o normal produz limites fora de [0,1] ele diria que o desempenho verdadeiro pode ser 104%. Wilson não faz isso, e é o que se deve usar num conjunto de teste de 50 exemplos, que é o tamanho real da maioria deles.
A conclusão que dói: arraste o conjunto para 50 exemplos com 80% de acerto e olhe a largura passa de 10 pontos para cada lado. Um modelo que mede 80% ali pode estar realmente em 68% ou em 89%, e a versão anterior que mediu 76% pode estar melhor que ele. Com 50 exemplos você não consegue provar nenhuma melhoria menor que ~15 pontos. Para separar 80% de 85% com confiança, a estatística pede cerca de 900 exemplos e essa é a razão real pela qual "avaliamos e melhorou" quase sempre significa "olhamos e gostamos".
O treino é o dia mais fácil. Ele tem começo, meio e fim, e alguém comemora quando termina. Depois começa a parte que dura: versionar, rotear, registrar e voltar atrás e é aqui que LoRA ganha de full fine-tune mesmo quando a memória não é problema.
O que precisa existir depois do treino
Vários adapters sobre a mesma base
modelo base (pago uma vez)adapters
A pergunta que chega depois do incidente: "qual versão do modelo gerou esta resposta?". Se o log de cada resposta não carrega o identificador do adapter e o da base, não existe investigação possível só reconstrução por memória. Registre os dois em toda resposta, desde a primeira. Custa dois campos, e é a diferença entre depurar e adivinhar.
O caminho inteiro
No fim: fine-tuning é uma ferramenta boa para um problema estreito fazer o modelo se comportar de um jeito que você não consegue descrever mas consegue exemplificar. Para tudo o mais existe um degrau mais barato, mais rápido de mudar e mais fácil de auditar. A pergunta que resolve a maioria dos casos não é técnica: é "o que exatamente precisa mudar?". Se a resposta contém a palavra "saber", quase sempre é recuperação. Se contém "responder assim", talvez seja fine-tuning e mesmo aí, monte o conjunto de teste antes da primeira rodada.