Fine-tuning

docs.scrimba.com

Fine-tuning significa pegar um modelo já existente e continuar treinando-o com seus próprios exemplos, para que seu comportamento padrão se desloque na direção do que você quer. Este capítulo mostra, na prática, o que isso muda, para que serve e quando vale mais a pena recorrer a ele do que a um prompt ou a uma busca por recuperação.

O que o treinamento realmente faz

Para entender o que o fine-tuning muda, ajuda saber de onde um modelo vem. Um modelo é construído em duas grandes etapas.

A primeira é o pré-treinamento: o modelo lê uma quantidade enorme de texto e aprende a prever o próximo token, repetidas vezes, até que gramática, fatos e padrões de raciocínio se instalem nele como efeito colateral. O resultado é um modelo base, fluente mas sem direção. Ele vai continuar seu texto de bom grado, mas não foi ensinado a ser um assistente útil que responde perguntas.

A segunda etapa é o pós-treinamento: o modelo base é treinado ainda mais com exemplos selecionados de boas respostas, junto com feedback humano sobre quais respostas são melhores. É isso que transforma um previsor de texto bruto no assistente que segue instruções com o qual você realmente conversa. O modelo que você chama por uma API já passou pelas duas etapas.

As duas etapas funcionam pelo mesmo mecanismo: mostrar exemplos ao modelo e ajustar seus números internos, seus parâmetros ou pesos, para que suas previsões se aproximem cada vez mais desses exemplos. Treinamento é prática de previsão que deixa o modelo permanentemente mudado.

JunoO que o treinamento realmente faz Um modelo é construído em duas etapas. No pré-treinamento, ele prevê o próximo token em quantidades enormes de texto, produzindo um modelo base fluente mas sem foco. Depois, o pós-treinamento o treina com boas respostas selecionadas e feedback humano, transformando-o em um assistente útil. As duas etapas funcionam do mesmo jeito: ajustando os pesos internos do modelo para que suas previsões correspondam aos exemplos mostrados a ele.

Um modelo chega até você depois de duas etapas de treinamento, e conhecer o formato de cada uma diz o que o fine-tuning pode mudar.

O pré-treinamento vem primeiro: o modelo lê uma pilha enorme de texto e faz um único exercício, prever o próximo token, bilhões de vezes. Gramática, conhecimento de mundo e padrões de raciocínio se fixam nos pesos como efeito colateral. O resultado é um modelo base, fluente para continuar texto, mas ainda não um assistente. Ele não sabe que deve responder a uma pergunta em vez de simplesmente estendê-la.

O pós-treinamento é a segunda etapa, e é essa que o fine-tuning imita. O modelo base é treinado ainda mais com exemplos selecionados de boas respostas, mais sinais de preferência humana sobre qual resposta é melhor. É isso que produz o comportamento de seguir instruções que você chama por uma API.

As duas etapas rodam o mesmo ciclo: alimentar o modelo com um exemplo, comparar sua previsão com o alvo e ajustar os pesos para reduzir a diferença. O fine-tuning é esse mesmo ciclo, limitado aos seus exemplos e executado depois que as duas etapas do provedor já terminaram. O treinamento muda o comportamento editando pesos, não adicionando uma tabela de consulta, e essa diferença é o motivo pelo qual o fine-tuning é bom para algumas tarefas e ruim para outras.

JunoO que o treinamento realmente faz Duas etapas levam um modelo até você: o pré-treinamento fixa a previsão do próximo token em um modelo base fluente, e o pós-treinamento o transforma em assistente com exemplos selecionados e dados de preferência. As duas rodam o mesmo ciclo, alimentar um exemplo, ajustar os pesos na direção dele, e o fine-tuning é esse ciclo limitado aos seus dados. Ele edita pesos, não adiciona uma tabela de consulta, e é por isso que ele muda comportamento bem, mas armazena fatos mal.

Um modelo chega até você depois de duas etapas de treinamento, e é na fronteira entre elas que o fine-tuning vive.

O pré-treinamento é a etapa cara, feita uma única vez por modelo: corpora de texto enormes, o objetivo único de prever o próximo token, e os pesos (os números ajustáveis do modelo) absorvendo gramática, conhecimento e raciocínio como subproduto. O resultado é um modelo base, fluente mas não direcionado para ser útil. O pós-treinamento então alinha esse modelo base para se tornar um assistente, usando demonstrações selecionadas e dados de preferência humana. No momento em que você chama um modelo por API, as duas já foram feitas.

O fine-tuning é uma continuação do pós-treinamento, limitado aos seus dados e executado sobre um modelo já alinhado. O mecanismo é idêntico: apresentar um exemplo, medir a distância entre a previsão e o alvo, ajustar os pesos para reduzir essa distância. A consequência que importa na prática é que o fine-tuning move os mesmos parâmetros globais que sustentam tudo o mais. Você não está anexando um módulo, está cutucando uma superfície compartilhada, e é por isso que um fine-tune pode melhorar sua tarefa alvo e, silenciosamente, degradar uma capacidade não relacionada ao mesmo tempo.

Essa característica de superfície compartilhada é a base de todos os modos de falha que aparecem mais adiante neste capítulo: overfitting, esquecimento, drift. O fine-tuning remodela comportamento, ele nunca instala um banco de fatos. Tendo isso em mente, você vai recorrer a ele pelos motivos certos e vai deixá-lo de lado pelos motivos errados.

JunoO que o treinamento realmente faz O pré-treinamento é o esforço pesado feito uma vez por modelo, que fixa a previsão do próximo token em um modelo base; o pós-treinamento o alinha para se tornar um assistente; e o fine-tuning continua essa segunda etapa com os seus dados. É sempre o mesmo ciclo: apresentar um exemplo, ajustar os pesos na direção dele. O detalhe é que você está cutucando parâmetros globais compartilhados, não encaixando um módulo, então um fine-tune pode melhorar sua tarefa e prejudicar outra não relacionada na mesma execução, e é daí que vêm o overfitting e o esquecimento.

O que é fine-tuning

Fine-tuning é uma versão pequena e direcionada dessa segunda etapa, executada por você. Você pega um modelo já treinado e continua treinando-o com um conjunto dos seus próprios exemplos, cada um sendo uma entrada combinada com a saída que você gostaria que ele produzisse. Depois de exemplos suficientes, os pesos do modelo se deslocam de modo que esse tipo de resposta se torne o padrão, sem que você precise pedir isso no prompt a cada vez.

A distinção real em relação a prompting e RAG está em onde a mudança acontece. Prompting e RAG deixam o modelo congelado e o direcionam por meio do contexto que você fornece no momento da chamada. Fine-tuning muda o próprio modelo, então o novo comportamento fica incorporado e aparece mesmo com um prompt curto. Você não está dando instruções melhores em tempo de execução; você está entregando um modelo que já tende naturalmente para o que você quer.

Na prática, você entrega ao provedor um arquivo de conversas de exemplo, ele executa um trabalho de treinamento e devolve um novo id de modelo. Você chama esse id exatamente como qualquer outro modelo, exceto que suas respostas agora refletem aquilo com que você treinou. Fine-tuning move o comportamento para dentro do modelo; prompting e RAG direcionam um modelo congelado.

JunoO que é fine-tuning Fine-tuning é uma versão pequena do pós-treinamento que você mesmo executa: continuar treinando um modelo existente com seus próprios exemplos de entrada e saída até que o comportamento que você quer se torne o padrão dele. Diferente de prompting e RAG, que direcionam um modelo congelado por meio do contexto, o fine-tuning muda os pesos do modelo, então o comportamento fica incorporado e aparece até com um prompt curto. Você entrega um arquivo de exemplos e recebe de volta um novo id de modelo que você chama como qualquer outro.

Fine-tuning é pós-treinamento limitado a uma tarefa e executado por você. Você parte de um modelo já treinado e continua treinando-o com exemplos, cada um sendo uma entrada combinada com a saída que você gostaria que ele tivesse produzido. Alimente-o com exemplos suficientes e os pesos se estabilizam de modo que essa resposta se torne o padrão, sem nenhuma instrução no prompt pedindo por ela.

A linha que importa é onde o direcionamento acontece. Prompting e RAG deixam os pesos congelados e moldam o comportamento por meio do contexto fornecido no momento da chamada, então toda chamada carrega as instruções. Fine-tuning edita os pesos uma vez, de antemão, então o comportamento vai embutido no id do modelo e sobrevive a um prompt curto. Direcionamento em tempo de execução versus comportamento embutido: essa é a troca que você está fazendo.

O fluxo de trabalho é concreto. Você monta um arquivo de conversas de exemplo, inicia um trabalho de treinamento e o provedor retorna um novo id de modelo. Você chama esse id como qualquer outro modelo.

# Cada exemplo é uma conversa exatamente no formato que você envia em tempo de execução,
# terminando com a saída que você quer que o modelo aprenda.
training_examples = [
    {"messages": [
        {"role": "system", "content": "Classifique a urgência do chamado como baixa, média ou alta."},
        {"role": "user", "content": "Fui cobrado duas vezes esta semana e preciso resolver isso hoje."},
        {"role": "assistant", "content": "alta"},
    ]},
    {"messages": [
        {"role": "system", "content": "Classifique a urgência do chamado como baixa, média ou alta."},
        {"role": "user", "content": "Existe alguma configuração de modo escuro?"},
        {"role": "assistant", "content": "baixa"},
    ]},
    # ... de centenas a milhares mais, cobrindo toda a variedade de entradas que você espera
]
# O formato das mensagens e a API do trabalho de treinamento variam por provedor; a ideia é a mesma.

JunoO que é fine-tuning Fine-tuning é pós-treinamento limitado à sua tarefa: continuar treinando um modelo com exemplos de entrada e saída até que o comportamento que você quer se torne o padrão. Prompting e RAG direcionam um modelo congelado por meio do contexto a cada chamada; fine-tuning edita os pesos uma única vez, de modo que o comportamento fica embutido no id do modelo. Você monta um arquivo de conversas de exemplo, executa um trabalho de treinamento e chama o id retornado como qualquer outro modelo.

Fine-tuning é pós-treinamento continuado em um conjunto de dados que você controla, produzindo um modelo derivado atrás de um novo id. Cada exemplo de treinamento é uma entrada combinada com uma saída-alvo, e o trabalho ajusta os pesos até que suas respostas-alvo se tornem o padrão do modelo. O comportamento vai embutido nos pesos, então um prompt curto já basta para evocá-lo.

Compare isso com precisão em relação às alternativas, porque a diferença é operacional, não filosófica. Prompting e RAG mantêm os pesos congelados e injetam comportamento por meio do contexto (o texto que o modelo lê no momento da chamada), o que significa que você pode mudar o comportamento editando uma string e reimplantando em segundos. Fine-tuning embute o comportamento nos pesos, o que significa que mudá-lo exige uma nova rodada de treinamento, uma passagem de avaliação e a reimplantação de um novo id de modelo. Direcionamento em tempo de execução é editável em segundos; um fine-tune só é editável por meio de um ciclo de treinamento.

# Um modelo com fine-tuning é apenas outro id; o formato da chamada não muda.
response = client.chat.completions.create(
    model="sua-org/classificador-urgencia-v1",  # fixe este valor; trate-o como parte do seu contrato
    messages=[
        {"role": "system", "content": "Classifique a urgência do chamado como baixa, média ou alta."},
        {"role": "user", "content": "O botão de exportar não faz nada quando eu clico nele."},
    ],
)
# response.choices[0].message.content -> "baixa"  (apenas o rótulo, o comportamento que você treinou)
# O formato de chamada mostrado é no estilo do SDK da OpenAI; varia por provedor.

Essa assimetria de custo é o que você precisa internalizar antes de se comprometer com isso. Um id com fine-tuning é um artefato versionado: você é responsável pelo seu ciclo de vida, pelas suas avaliações e por retreiná-lo cada vez que o comportamento desejado mudar. Fixe o id, versione-o e reserve orçamento para o fato de que cada mudança no que ele aprendeu é mais um trabalho de treinamento, não apenas mais um commit.

JunoO que é fine-tuning Fine-tuning é pós-treinamento continuado com os seus dados, gerando um modelo derivado atrás de um novo id cujo comportamento vive nos pesos. O contraste com prompting e RAG é operacional: direcionamento em tempo de execução é uma string editável que você reimplanta em segundos; um fine-tune é um artefato versionado que você só muda por meio de uma rodada de treinamento, uma avaliação e uma reimplantação. Fixe o id, trate-o como um contrato e reserve orçamento para o fato de que cada mudança de comportamento é mais um trabalho de treinamento.

Para que serve e para que não serve

Fine-tuning ganha seu lugar quando você precisa de um comportamento consistente que um prompt tem dificuldade de fixar: um formato de saída preciso todas as vezes, um tom ou estilo específico, ou uma tarefa restrita como classificação feita de forma confiável em milhares de chamadas. Também pode tornar as chamadas mais baratas e rápidas, porque o comportamento que você teria que detalhar em um prompt longo fica embutido no modelo, então seus prompts ficam mais curtos.

Onde ele falha é no conhecimento. Fine-tuning é fraco para ensinar fatos novos a um modelo, e ainda pior para fatos que mudam. Os exemplos de treinamento se misturam em padrões gerais em vez de ficarem armazenados como entradas exatas e consultáveis, então um modelo com fine-tuning continua inventando detalhes e continua ficando desatualizado no instante em que sua informação é atualizada. Retreinar cada vez que um preço ou uma política muda é lento e caro. Quando o problema é "o modelo não sabe X", a resposta é quase sempre RAG, não fine-tuning.

A regra prática: faça fine-tuning para mudar a forma, não para adicionar fatos. Ensine o modelo a responder, e deixe a recuperação de informação cuidar do conteúdo da resposta.

JunoPara que serve e para que não serve Fine-tuning é bom para comportamento consistente: um formato de saída fixo, um tom específico ou uma tarefa restrita feita de forma confiável, e pode encurtar prompts para que as chamadas custem menos. É ruim para conhecimento: não armazena fatos de forma confiável, fica desatualizado quando eles mudam, e é caro retreinar. A regra é fazer fine-tuning para mudar a forma, não para adicionar fatos, e deixar o RAG cuidar dos fatos.

Fine-tuning se paga para forma: um formato de saída preciso em toda chamada, um tom fixo ou estilo próprio, ou uma tarefa restrita como classificação mantida estável em milhares de requisições. O ganho se acumula quando apenas o prompting continua oscilando, o modelo respeita o formato na maior parte do tempo, mas não de forma confiável o suficiente para ser interpretado depois. Embutir o comportamento faz com que o formato deixe de ser algo que você só espera que aconteça em cada chamada.

Também encurta os prompts, e em escala isso é uma economia real. Se hoje você precisa detalhar o formato e alguns exemplos em cada requisição, esses tokens de instrução são cobrados em todas as chamadas. Incorpore-os aos pesos e o prompt por chamada diminui. Vale a pena fazer a conta: um fine-tune tem um custo de treinamento fixo, pago uma única vez, enquanto um prompt longo tem um custo por chamada, pago para sempre, então encurtar o prompt se paga quando o volume de chamadas é alto o suficiente para que os tokens economizados superem a conta do treinamento.

Onde ele falha é no conhecimento. Os exemplos de treinamento se misturam em padrões gerais, não em entradas exatas e recuperáveis, então um modelo com fine-tuning continua inventando detalhes e continua ficando desatualizado no instante em que um preço ou uma política mudam. Atualizar um fato significa outra rodada de treinamento. Faça fine-tuning para a forma, use RAG para os fatos, e combine os dois. O padrão forte é usar os dois ao mesmo tempo: ajuste o modelo para seu formato e tom, depois recupere fatos atuais em tempo de execução e deixe o modelo ajustado dar forma a eles.

Antes de sequer pensar em fine-tuning, confirme que o prompting de fato falhou. "Falhou" significa uma instrução clara com alguns exemplos bem escolhidos, testada em entradas variadas, ainda abaixo da taxa desejada, não que seu primeiro prompt de uma linha pareceu insuficiente. Se você não fez esse teste, ainda não está pronto para fazer fine-tuning.

JunoPara que serve e para que não serve Fine-tuning é para forma: um formato de saída fixo, um tom definido, uma tarefa restrita mantida estável, além de prompts mais curtos que economizam tokens em toda chamada. A conta de custo é treinamento fixo pago uma vez versus tokens de prompt pagos para sempre, então encurtar o prompt se paga em alto volume. É fraco para fatos, que se misturam em padrões e ficam desatualizados, então combine um modelo ajustado com RAG: forma vem dos pesos, fatos vêm da recuperação. E prove que o prompting de fato falhou, um prompt real com exemplos testado em entradas variadas, antes de subir esse degrau.

Fine-tuning é confiável para forma e não confiável para fatos, e os motivos são mecânicos. Forma, formato de saída, tom, convenções de tarefa, é uma regularidade comportamental que os pesos conseguem absorver ao longo de muitos exemplos. Fatos são discretos e mutáveis, e os pesos os armazenam com perda, como padrões misturados, não como linhas recuperáveis, então um modelo ajustado continua confabulando e continua ficando desatualizado no instante em que o fato subjacente muda.

Indo além do resumo, os riscos reais são as formas pelas quais um fine-tune se degrada. Overfitting é o modelo memorizando seu conjunto de treinamento, incluindo suas peculiaridades, em vez de aprender o comportamento geral, então ele acerta seus exemplos e falha em entradas diferentes. Esquecimento catastrófico é o outro lado da moeda: treinar intensamente em uma tarefa restrita pode corroer capacidades gerais não relacionadas que o modelo base tinha, porque você está movendo pesos compartilhados, então seu classificador fica mais afiado enquanto seu raciocínio em qualquer outra coisa fica mais embotado. Drift de distribuição é o lento: um modelo ajustado com a distribuição de entradas do trimestre passado se degrada conforme o tráfego real se distancia do que ele viu, e a degradação é silenciosa até você medi-la.

Duas consequências definem como você deve conduzir isso na prática. Primeiro, você não pode lançar um fine-tune por intuição; precisa de um conjunto de avaliação, um lote reservado de entradas com respostas conhecidas como corretas, pontuado antes e depois, para provar que a tarefa alvo melhorou e, não menos importante, que a capacidade geral não regrediu. Segundo, cada mudança no comportamento desejado é outro trabalho completo: recuratar os dados, retreinar, reavaliar, reimplantar um novo id. Esse atrito operacional é o motivo pelo qual existem métodos eficientes em parâmetros, formas de fazer fine-tuning treinando um pequeno conjunto de pesos adicionados em vez do modelo inteiro, mais baratos para executar e armazenar, embora a decisão de fazer ou não fine-tuning permaneça a mesma. De qualquer forma, prove que o fine-tune não regrediu antes de colocá-lo em produção.

JunoPara que serve e para que não serve Forma se absorve nos pesos, fatos não: um fine-tune continua confabulando e ficando desatualizado, então mantenha os fatos na recuperação. Os riscos são overfitting (memorizar seu conjunto, falhar em entradas novas), esquecimento catastrófico (treinamento restrito corroendo capacidade não relacionada, já que os pesos são compartilhados) e drift de distribuição conforme o tráfego real se afasta dos seus dados de treinamento. Então condicione todo fine-tune a uma avaliação reservada, pontuada antes e depois, para provar que não houve regressão, e reserve orçamento para o fato de que cada mudança de comportamento é um ciclo completo de retreino-avaliação-reimplantação, que é exatamente o motivo pelo qual existem métodos eficientes em parâmetros.

Prompt, RAG ou fine-tuning?

Na maioria das vezes você não começa por aqui. As três técnicas formam uma escada, do mais barato e rápido de mudar para o mais custoso:

1. Prompting. Sempre tente isso primeiro. É instantâneo de iterar, não custa nada extra, e um prompt claro com alguns exemplos resolve mais do que as pessoas esperam. Se você ainda não fez o prompt funcionar, não está pronto para fazer fine-tuning.
2. RAG. Recorra a isso quando a lacuna é de conhecimento: o modelo precisa de fatos que não tem, ou que mudam com o tempo. RAG fornece esses fatos no momento da pergunta sem tocar no modelo.
3. Fine-tuning. Recorra a isso quando a lacuna é de comportamento, não de conhecimento, e o prompting não consegue deixá-lo consistente o suficiente, ou quando seus prompts cresceram tanto que embutir as instruções no modelo é mais barato e mais rápido em escala.

Elas não são mutuamente exclusivas, e os sistemas mais fortes combinam as três: ajuste um modelo para seu formato e tom, depois use RAG para alimentá-lo com fatos atuais em tempo de execução. Comportamento vem do treinamento, conhecimento vem da recuperação.

Então, um teste rápido antes de fazer fine-tuning. Você consegue chegar lá com um prompt melhor? Então faça isso. A lacuna é de conhecimento faltando? Então é RAG.

Suba a escada; fine-tuning é o último degrau, não o primeiro. Só quando o prompt já está certo, os fatos já estão disponíveis, e o modelo ainda não se comporta de forma consistente o suficiente, é que o fine-tuning se torna a ferramenta certa.

JunoPrompt, RAG ou fine-tuning? Trate as três como uma escada: prompt primeiro, porque é instantâneo e barato, adicione RAG quando o modelo estiver sem conhecimento, e faça fine-tuning só quando a lacuna for de comportamento que o prompting não consegue deixar consistente, ou para encurtar prompts longos em escala. Elas se combinam bem: fine-tuning para a forma, RAG para os fatos. Fine-tuning é o último degrau ao qual você recorre, não o primeiro.

As três técnicas formam uma escada, ordenada por quão rápido e barato é mudá-las, e você sobe a partir de baixo.

1. Prompting. Primeiro, sempre. Você itera em segundos sem custo extra de treinamento, e uma instrução clara com alguns exemplos cobre mais terreno do que as pessoas esperam. Até que um prompt de verdade tenha sido testado e ficado abaixo do esperado, os degraus mais altos são prematuros.
2. RAG. Quando a lacuna é de conhecimento, fatos que o modelo não tem ou que mudam com o tempo, a recuperação de informação os fornece no momento da pergunta e deixa os pesos intocados. Atualizar um fato é atualizar sua fonte, não retreinar.
3. Fine-tuning. Quando a lacuna é de comportamento que o prompting não consegue fixar, ou quando os prompts cresceram o suficiente para que embutir instruções nos pesos seja mais barato em escala.

O diagnóstico que coloca você no degrau certo é nomear a lacuna. Um formato ou tom errado é uma lacuna de comportamento, então use prompt e depois fine-tuning. Um fato ausente ou desatualizado é uma lacuna de conhecimento, então recupere a informação. Interprete a lacuna errada e você vai fazer fine-tuning para resolver um problema de conhecimento e ver isso ficar desatualizado, ou vai encher um prompt com fatos que uma etapa de recuperação deveria ter buscado.

Elas não são mutuamente exclusivas, e o padrão combinado é o que você deve buscar em produção: fine-tuning para a forma, RAG para os fatos, juntos. Um modelo ajustado ao seu formato e tom, alimentado com fatos atuais em tempo de execução, dá a você forma consistente e conteúdo atualizado ao mesmo tempo, coisa que nenhuma das duas técnicas entregaria isoladamente.

Se você pode fazer fine-tuning ou não depende do modelo. Provedores fechados oferecem fine-tuning gerenciado dos próprios modelos; um modelo de pesos abertos você pode ajustar por conta própria, nos seus próprios termos, o que é um dos motivos para recorrer a pesos abertos (Modelos abertos e fechados).

JunoPrompt, RAG ou fine-tuning? Suba a escada a partir do degrau mais barato: prompt primeiro, adicione RAG quando a lacuna for de conhecimento, faça fine-tuning só quando ela for de comportamento que o prompting não consegue fixar ou para encurtar prompts em escala. O diagnóstico é nomear a lacuna, formato ou tom significa comportamento, um fato ausente ou desatualizado significa recuperação de informação. A jogada de produção é usar as duas juntas: fine-tuning para a forma, RAG para os fatos, de modo que você obtenha forma consistente e conteúdo atualizado ao mesmo tempo.

A escada, prompt, depois RAG, depois fine-tuning, é ordenada pelo custo de iteração: quão rápido e barato é mudar o comportamento depois de já estar em produção. Um prompt é uma string que você edita e reimplanta em segundos. Uma fonte de recuperação é dados que você atualiza sem tocar no modelo. Um fine-tune é uma rodada de treinamento, uma passagem de avaliação e um novo id de modelo. Subir nessa ordem significa que você só paga o custo de iteração mais alto quando os degraus mais baratos comprovadamente não conseguem alcançar o objetivo.

A habilidade real está em diagnosticar a lacuna corretamente, porque o modo de falha é escolher a ferramenta que não resolve o problema. Uma lacuna de comportamento (forma errada, tom errado, aderência inconsistente à tarefa) é o que prompting e depois fine-tuning corrigem. Uma lacuna de conhecimento (um fato que o modelo não tem, ou um que muda) é o que a recuperação de informação corrige, e fazer fine-tuning para uma lacuna de conhecimento é o erro clássico e caro: você treina os fatos, eles ficam desatualizados na próxima atualização, e você não consegue citá-los.

Coloque a assimetria operacional ao lado do diagnóstico. O custo recorrente do RAG é a qualidade e a latência da recuperação em cada chamada, pago para sempre, mas ajustável em tempo real. O custo recorrente do fine-tuning é uma nova execução a cada mudança no comportamento aprendido, mais o risco de regressão que cada execução traz.

Então a arquitetura combinada não é um meio-termo, é o design correto: embuta a forma nos pesos, mantenha os fatos na recuperação, e versione cada um de forma independente. A forma muda raramente e tolera um ciclo de atualização lento; os fatos mudam constantemente e exigem um ciclo rápido. Separá-los permite que cada um se mova no seu próprio ritmo, e permite reavaliar o modelo ajustado sem reindexar seu corpus, ou atualizar o corpus sem reexecutar um trabalho de treinamento.

JunoPrompt, RAG ou fine-tuning? A escada é ordenada pelo custo de iteração: um prompt se edita em segundos, uma fonte se atualiza sem tocar no modelo, um fine-tune é um ciclo completo de treino-avaliação-reimplantação. Diagnostique a lacuna antes de escolher, comportamento vai para prompting e depois fine-tuning, conhecimento vai para recuperação de informação, e fazer fine-tuning para uma lacuna de conhecimento é o erro caro que entrega fatos desatualizados e não citáveis. A arquitetura de produção os separa de propósito: embuta a forma nos pesos, mantenha os fatos na recuperação, versione cada um de forma independente, de modo que a forma possa mudar lentamente e os fatos possam mudar rápido.

Na prática

Os dados de fine-tuning não têm nada de exótico. Cada exemplo é uma conversa curta exatamente no formato que você envia em tempo de execução, terminando com a resposta que você gostaria que o modelo tivesse dado:

# Mostramos apenas alguns exemplos aqui; um conjunto de dados real tem de centenas a milhares de exemplos,
# cobrindo toda a variedade de entradas que você espera em tempo de execução.
training_examples = [
    {"messages": [
        {"role": "system", "content": "Classifique a urgência do chamado como baixa, média ou alta."},
        {"role": "user", "content": "Fui cobrado duas vezes esta semana e preciso resolver isso hoje."},
        {"role": "assistant", "content": "alta"},
    ]},
    {"messages": [
        {"role": "system", "content": "Classifique a urgência do chamado como baixa, média ou alta."},
        {"role": "user", "content": "Existe alguma configuração de modo escuro?"},
        {"role": "assistant", "content": "baixa"},
    ]},
    # ...
]

Você salva isso em um arquivo, inicia um trabalho de treinamento com o provedor e espera terminar. O que volta é um novo id de modelo, que você então chama exatamente como qualquer outro modelo:

# O modelo com fine-tuning é apenas outro id; todo o resto permanece igual.
response = client.chat.completions.create(
    model="sua-org/classificador-urgencia-v1",
    messages=[
        {"role": "system", "content": "Classifique a urgência do chamado como baixa, média ou alta."},
        {"role": "user", "content": "O botão de exportar não faz nada quando eu clico nele."},
    ],
)
# response.choices[0].message.content -> "baixa"  (apenas o rótulo, o comportamento que você treinou)

O ganho é que o comportamento agora vive no modelo. As instruções podem ser mais curtas, o formato se mantém consistente em milhares de chamadas, e você não precisou aumentar o prompt para chegar lá. O custo é tudo em volta disso: você precisa de um conjunto de dados de qualidade, uma rodada de treinamento e um novo trabalho cada vez que quiser mudar o que ele aprendeu, e é exatamente por isso que isso fica na base da escada. Envie exemplos, receba um id de modelo, chame-o como qualquer outro.

JunoNa prática Os dados de fine-tuning são conversas de exemplo terminando na resposta que você quer, algumas centenas ou alguns milhares deles. Você envia o arquivo, executa um trabalho de treinamento e recebe de volta um novo id de modelo que você chama como qualquer outro. O comportamento fica então embutido, então os prompts ficam mais curtos e o formato permanece consistente, ao custo de construir o conjunto de dados e reexecutar o trabalho sempre que ele precisar mudar.

O fluxo de trabalho é enviar, treinar, chamar, mas a parte que decide se isso funciona é o conjunto de dados, não o trabalho em si. Qualidade e abrangência importam mais do que quantidade bruta. Algumas centenas de exemplos limpos e consistentes que cobrem toda a variedade real de entradas vencem milhares de exemplos ruidosos ou contraditórios, porque o modelo aprende qualquer regularidade que realmente exista nos dados, incluindo os erros.

Divida seus dados antes de treinar. Reserve uma parte que o modelo nunca vê durante o treinamento, o conjunto de validação, e verifique a precisão nele em vez de nos exemplos com os quais ele treinou. Um modelo pode pontuar quase perfeitamente em dados que já viu enquanto tem um desempenho ruim em qualquer coisa nova, então o número obtido com dados reservados é o que diz se o comportamento generaliza.

# Reserve uma parte que o trabalho de treinamento nunca vê, para medir o desempenho real.
split = int(len(training_examples) * 0.8)
train_set = training_examples[:split]        # o trabalho treina com estes
validation_set = training_examples[split:]   # você pontua o resultado com estes
# O provedor retorna um novo id de modelo; você o chama como qualquer outro modelo.
# A API do trabalho e o tratamento da divisão variam por provedor; alguns aceitam o arquivo de validação diretamente.

Duas decisões de julgamento ficam acima da parte mecânica. Primeiro, confirme que o prompting de fato falhou antes de gastar uma rodada de treinamento: uma instrução real com alguns exemplos, testada em entradas variadas, não seu primeiro rascunho tosco. Segundo, pese o custo com cuidado. Um fine-tune tem um custo de treinamento fixo, pago uma vez, contra o custo por chamada de um prompt longo, pago para sempre, então encurtar o prompt só se paga quando o volume de chamadas faz os tokens economizados valerem o trabalho de treinamento. E lembre-se do padrão combinado: um modelo ajustado para a forma, RAG para os fatos que ele não deveria tentar memorizar.

JunoNa prática O trabalho é enviar-treinar-chamar, mas o conjunto de dados decide o resultado: algumas centenas de exemplos limpos e variados vencem milhares de exemplos ruidosos, já que o modelo aprende o que realmente está nos dados. Reserve uma parte para validação e pontue nela, não nos exemplos de treinamento, ou um modelo que memorizou vai parecer melhor do que realmente é. Confirme primeiro que o prompting realmente falhou, pese o custo de treinamento fixo contra os tokens de prompt pagos para sempre, e combine o modelo ajustado com RAG para que ele cuide da forma enquanto a recuperação cuida dos fatos.

O pipeline é enviar, treinar, avaliar, implantar, e a engenharia está no conjunto de dados e no conjunto de avaliação, não na chamada de treinamento. A disciplina de duas divisões sustenta isso. Um conjunto de validação, reservado do treinamento, diz se o comportamento generalizou em vez de ter sido memorizado. Um conjunto de avaliação separado e reservado, pontuado antes e depois, é o que prova que o fine-tune ajudou sua tarefa alvo sem regredir a capacidade geral, a verificação de esquecimento catastrófico da seção anterior, agora concreta.

# Três divisões distintas: treine com uma, ajuste decisões com outra, julgue com uma terceira.
train_set      = examples[:8000]        # o trabalho treina com estes
validation_set = examples[8000:9000]    # observe overfitting durante a execução
eval_set       = examples[9000:]        # pontuado ANTES e DEPOIS para provar que não houve regressão

# Pontue o modelo base e o fine-tune no MESMO eval_set, depois compare.
base_score = run_eval(base_model_id, eval_set)
tuned_score = run_eval(fine_tuned_id, eval_set)
# Coloque em produção apenas se tuned_score superar o base na tarefa alvo E se manter nas verificações de capacidade geral.
# A pontuação de avaliação e a API de treinamento variam por provedor; a disciplina não.

A qualidade do conjunto de dados é onde overfitting e drift se ganham ou se perdem. Um conjunto de dados restrito ou peculiar treina um modelo que memoriza as idiossincrasias do seu conjunto e falha em entradas diferentes, então a cobertura da distribuição real de entradas importa mais do que a quantidade, e você reavalia conforme o tráfego de produção se afasta do que você usou no treinamento. Avaliações desatualizadas são como um modelo em drift silencioso passa pela revisão e falha com os usuários.

A realidade operacional para a qual você deve se planejar é que cada mudança no comportamento aprendido é uma execução completa nova, não uma edição. Recurar, retreinar, reavaliar, reimplantar um novo id fixado, a cada vez. Esse custo recorrente, mais o risco de regressão em cada execução, é o motivo para manter os fatos em RAG, onde eles se atualizam em tempo real, reservar o fine-tuning para comportamento que muda lentamente, e tratar cada id ajustado como um artefato versionado ao qual você pode voltar quando uma nova execução regride.

JunoNa prática O pipeline é enviar-treinar-avaliar-implantar, e o trabalho está nas divisões dos dados, não na chamada: um conjunto de validação pega memorização, um conjunto de avaliação reservado, pontuado antes e depois, prova que não houve regressão. A cobertura do conjunto de dados sobre a distribuição real de entradas é como você vence overfitting e drift, então reavalie conforme o tráfego se afasta dos seus dados de treinamento. E planeje-se para o custo recorrente, cada mudança de comportamento é um ciclo completo de retreino-avaliação-reimplantação, motivo pelo qual os fatos pertencem ao RAG e cada id ajustado é um artefato versionado ao qual você pode voltar.

Essa é a última das formas de moldar o que um modelo sabe e como ele responde, todas elas deixando-o prevendo texto em uma mesa que você mesmo arrumou. Os próximos capítulos dão a ele a capacidade de agir: em Uso de ferramentas, o modelo chama suas próprias funções, e depois passa a executá-las em um loop como um agente.