Ajuste fino

docs.scrimba.com

Ajuste fino significa pegar um modelo existente e continuar treinando-o com seus próprios exemplos, para que seu comportamento padrão mude na direção que você deseja. Este capítulo apresenta uma visão prática do que isso muda, para o que é bom, e quando usá-lo em vez de um prompt ou recuperação.

O que o treinamento realmente faz

Para ver o que o ajuste fino muda, é útil saber de onde um modelo vem. Um modelo é construído em dois estágios amplos.

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

O segundo estágio é pós-treinamento: o modelo base é treinado ainda mais em exemplos curados de boas respostas, junto com feedback humano sobre quais respostas são melhores. Isso transforma um preditor de texto bruto no assistente que segue instruções com o qual você realmente interage. O modelo que você chama de uma API já passou pelos dois.

Ambos os estágios funcionam pelo mesmo mecanismo: mostre exemplos ao modelo e ajuste seus números internos, seus parâmetros ou pesos, para que suas previsões se aproximem desses exemplos. Treinamento é prática de previsão que deixa o modelo permanentemente alterado.

JunoO que o treinamento realmente faz Um modelo é construído em dois estágios. Pré-treinamento o faz prever o próximo token em enormes quantidades de texto, produzindo um modelo base fluente mas sem foco. Pós-treinamento então o treina em respostas boas curadas e feedback humano, transformando-o em um assistente útil. Ambos funcionam da mesma forma: ajustando os pesos internos do modelo para que suas previsões correspondam aos exemplos que ele vê.

Um modelo chega até você após dois estágios de treinamento, e conhecer a forma de cada um diz o que o ajuste fino pode mover.

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

Pós-treinamento é o segundo estágio, e é aquele que o ajuste fino imita. O modelo base é treinado ainda mais em exemplos curados de boas respostas mais sinais de preferência humana sobre qual resposta é melhor. Isso é o que produz o comportamento de seguir instruções que você chama de uma API.

Ambos os estágios executam o mesmo loop: forneça ao modelo um exemplo, compare sua previsão ao alvo, e ajuste os pesos para fechar a lacuna. Ajuste fino é esse mesmo loop, reduzido em escala para seus exemplos e executado após os dois estágios do provedor. O treinamento altera o comportamento editando pesos, não adicionando uma tabela de consulta, e essa distinção é toda a razão pela qual o ajuste fino é bom para alguns trabalhos e ruim para outros.

JunoO que o treinamento realmente faz Dois estágios levam um modelo até você: pré-treinamento treina previsão do próximo token em um modelo base fluente, depois pós-treinamento o molda em um assistente com exemplos curados e dados de preferência. Ambos executam o mesmo loop: forneça um exemplo, ajuste os pesos em sua direção, e o ajuste fino é esse loop reduzido em escopo para seus dados. Ele edita pesos, não adiciona uma tabela de consulta, é por isso que muda o comportamento bem e armazena fatos mal.

Um modelo chega após dois estágios de treinamento, e o limite entre eles é onde o ajuste fino vive.

Pré-treinamento é o estágio caro, uma vez por modelo: enormes corpora de texto, o objetivo único de previsão do próximo token, e os pesos (os números ajustáveis do modelo) absorvendo gramática, conhecimento e raciocínio como um subproduto. A saída é um modelo base, fluente mas não dirigido a ser útil. Pós-treinamento então alinha esse modelo base em um assistente usando demonstrações curadas e dados de preferência humana. Quando você chama um modelo de API, ambos já foram executados.

Ajuste fino é uma continuação do pós-treinamento, reduzido em escopo para seus dados e executado em cima de um modelo já alinhado. O mecanismo é idêntico: apresente um exemplo, meça o quão longe a previsão fica do alvo, ajuste pesos para reduzir essa lacuna. A consequência que importa operacionalmente é que o ajuste fino move os mesmos parâmetros globais que mantêm tudo o mais. Você não está anexando um módulo, está empurrando uma superfície compartilhada, é por isso que um ajuste fino pode melhorar sua tarefa alvo e silenciosamente degradar uma capacidade não relacionada ao mesmo tempo.

Essa propriedade de superfície compartilhada configura todo modo de falha mais tarde neste capítulo: overfitting, esquecimento, drift. Ajuste fino reformula comportamento, nunca instala um armazenamento de fatos. Mantenha isso em mente e você irá alcançá-lo pelas razões certas e evitá-lo pelas erradas.

JunoO que o treinamento realmente faz Pré-treinamento é o peso pesado uma vez por modelo que treina previsão do próximo token em um modelo base, pós-treinamento o alinha em um assistente, e ajuste fino continua esse segundo estágio em seus dados. Mesmo loop toda vez: apresente um exemplo, ajuste pesos em sua direção. O pega é que você está empurrando parâmetros globais compartilhados, não aparafusando um módulo, então um ajuste fino pode elevar sua tarefa e erodir uma não relacionada na mesma execução, é daí que vêm overfitting e esquecimento.

O que é ajuste fino

Ajuste fino é uma versão pequena e direcionada daquele segundo estágio, executada por você. Você pega um modelo que já está treinado e continua treinando-o em um conjunto de seus próprios exemplos, cada um uma entrada emparelhada com a saída que você deseja que ele produza. Após exemplos suficientes, os pesos do modelo mudam para que esse tipo de resposta se torne seu padrão, sem você pedir por isso no prompt toda vez.

A distinção real do prompting e RAG é onde a mudança vive. Prompting e RAG deixam o modelo congelado e o direcionam através do contexto que você fornece no momento da chamada. Ajuste fino muda o próprio modelo, então o novo comportamento está incorporado e aparece mesmo com um prompt curto. Você não está dando melhores instruções em tempo de execução; está enviando um modelo que já se inclina na direção que você quer.

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

JunoO que é ajuste fino Ajuste fino é uma versão pequena de pós-treinamento que você executa: continuar treinando um modelo existente em seus próprios exemplos entrada-saída até que o comportamento que você deseja se torne seu padrão. Diferentemente de prompting e RAG, que direcionam um modelo congelado através de contexto, o ajuste fino muda os pesos do modelo, então o comportamento está incorporado e aparece mesmo com um prompt curto. Você fornece um arquivo de exemplos e obtém de volta um novo id de modelo que você chama como qualquer outro.

Ajuste fino é pós-treinamento reduzido em escopo para uma tarefa e executado por você. Você começa de um modelo já treinado e continua treinando-o em exemplos, cada um uma entrada emparelhada com a saída que você deseja ter produzido. Alimente-o com o suficiente deles e os pesos se assentam para que essa resposta se torne o padrão, sem instrução no prompt pedindo por isso.

A linha que importa é onde o direcionamento vive. Prompting e RAG deixam os pesos congelados e formam o comportamento através de contexto fornecido no tempo de chamada, então cada chamada carrega as instruções. Ajuste fino edita os pesos uma vez, de antemão, para que o comportamento seja enviado dentro do id do modelo e sobreviva a um prompt curto. Direcionamento em tempo de execução versus comportamento incorporado: esse é o trade-off 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 na forma exata 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 ticket como baixa, média ou alta."},
        {"role": "user", "content": "Fui cobrado duas vezes esta semana e preciso que seja corrigido hoje."},
        {"role": "assistant", "content": "alta"},
    ]},
    {"messages": [
        {"role": "system", "content": "Classifique a urgência do ticket como baixa, média ou alta."},
        {"role": "user", "content": "Existe uma configuração de modo escuro em algum lugar?"},
        {"role": "assistant", "content": "baixa"},
    ]},
    # ... centenas a milhares a mais, cobrindo a gama completa de entradas que você espera
]
# A forma da mensagem e a API do trabalho de treinamento variam por provedor; a ideia é a mesma.

JunoO que é ajuste fino Ajuste fino é pós-treinamento reduzido em escopo para sua tarefa: continuar treinando um modelo em exemplos entrada-saída até que o comportamento que você deseja seja o padrão. Prompting e RAG direcionam um modelo congelado através de contexto a cada chamada, ajuste fino edita os pesos uma vez para que o comportamento esteja dentro do id do modelo. Você constrói um arquivo de conversas de exemplo, executa um trabalho de treinamento, e chama o id retornado como qualquer outro modelo.

Ajuste fino é 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 emparelhada com uma saída alvo, e o trabalho empurra os pesos até que suas respostas alvo se tornem o padrão do modelo. O comportamento é enviado nos pesos, então um prompt curto é suficiente para evocá-lo.

Configure-o contra as alternativas com precisão, porque a diferença é operacional, não filosófica. Prompting e RAG mantêm os pesos congelados e injetam comportamento através do contexto (o texto que o modelo lê no tempo de chamada), o que significa que você pode mudar comportamento editando uma string e reimplantando em segundos. Ajuste fino incorpora comportamento nos pesos, o que significa que alterá-lo requer uma execução de treinamento nova, uma passagem de eval, e uma reimplantação de um novo id de modelo. Direcionamento em tempo de execução é editável em segundos, um ajuste fino é editável apenas em um ciclo de treinamento.

# Um modelo ajustado fino é outro id; a forma da chamada é inalterada.
response = client.chat.completions.create(
    model="your-org/urgency-classifier-v1",  # fixe isto; trate-o como parte de seu contrato
    messages=[
        {"role": "system", "content": "Classifique a urgência do ticket como baixa, média ou alta."},
        {"role": "user", "content": "O botão de exportação não faz nada quando eu clico nele."},
    ],
)
# response.choices[0].message.content -> "baixa"  (apenas o rótulo, o comportamento que você treinou)
# A forma da chamada mostrada é estilo OpenAI-SDK; varia por provedor.

Essa assimetria de custo é o que você precisa internalizar antes de se comprometer. Um id ajustado fino é um artefato versionado: você possui seu ciclo de vida, suas avaliações, e seu re-treinamento toda vez que o comportamento desejado se move. Fixe o id, versione-o, e orçamente para o fato de que cada mudança no que ele aprendeu é outro trabalho, não outro commit.

JunoO que é ajuste fino Ajuste fino é pós-treinamento continuado em seus dados, produzindo 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 ajuste fino é um artefato versionado que você muda apenas através de uma execução de treinamento, uma passagem de eval, e uma reimplantação. Fixe o id, trate-o como um contrato, e orçamente para o fato de que cada mudança de comportamento é outro trabalho.

Para o que é bom, e para o que não é

Ajuste fino ganha seu lugar quando você precisa de um comportamento consistente que um prompt tem dificuldade de fixar: um formato de saída preciso toda vez, um tom ou estilo de marca específico, ou uma tarefa estreita como classificação feita confiável em milhares de chamadas. Também pode tornar as chamadas mais baratas e rápidas, porque o comportamento que você teria que soletrar em um prompt longo está incorporado no modelo, então seus prompts ficam mais curtos.

Onde ele falha é no conhecimento. Ajuste fino é ruim em ensinar um modelo novos fatos, e pior em fatos que mudam. Exemplos de treinamento se misturam em padrões gerais em vez de serem armazenados como entradas exatas e consultáveis, então um modelo ajustado fino ainda inventa detalhes e ainda fica obsoleto no momento em que suas informações são atualizadas. Re-treinar toda vez que um preço ou política muda é lento e caro. Quando o problema é "o modelo não sabe X", a resposta é quase sempre RAG, não ajuste fino.

A regra de ouro: ajuste fino para mudar a forma, não para adicionar fatos. Ensine ao modelo como responder, e deixe a recuperação lidar com o que responder.

JunoPara o que é bom, e para o que não é Ajuste fino é bom para comportamento consistente: um formato de saída fixo, um tom específico, ou uma tarefa estreita feita confiável, e pode encurtar prompts para que as chamadas custem menos. É ruim para conhecimento: não armazena fatos confiável, fica obsoleto quando mudam, e é caro re-treinar. A regra é ajuste fino para mudar a forma, não para adicionar fatos, e deixe RAG lidar com os fatos.

Ajuste fino compensa para forma: uma forma de saída precisa a cada chamada, um tom ou estilo de marca fixo, ou uma tarefa estreita como classificação mantida estável em milhares de requisições. A vitória se compõe quando prompting sozinho continua variando, o modelo honra o formato a maior parte do tempo mas não confiável o suficiente para analisar downstream. Incorpore o comportamento e o formato para de ser algo que você espera a cada chamada.

Também encurta prompts, e em escala isso é uma alavanca de custo real. Se você atualmente soletra o formato e alguns exemplos em cada requisição, esses tokens de instrução são faturados a cada única chamada. Dobre-os nos pesos e o prompt por chamada encolhe. A aritmética vale a pena fazer: um ajuste fino tem um custo de treinamento fixo pago uma vez, enquanto um prompt longo tem um custo por chamada pago para sempre, então a economia de prompts compensa quando o volume de chamadas é alto o suficiente para que os tokens salvos ultrapassem a conta de treinamento.

Onde ele falha é no conhecimento. Exemplos de treinamento se misturam em padrões gerais, não entradas exatas recuperáveis, então um modelo ajustado fino ainda inventa detalhes e ainda fica obsoleto no momento em que um preço ou política muda. Atualizar um fato significa outra execução de treinamento. Ajuste fino para forma, use RAG para fatos, e combine-os. O padrão forte é ambos ao mesmo tempo: ajuste fino o modelo para seu formato e tom, então recupere fatos atuais em tempo de execução e deixe o modelo ajustado fraseá-los.

Antes de você subir ao ajuste fino, confirme que prompting realmente falhou. "Falhou" significa uma instrução clara com alguns exemplos bem escolhidos, testados em entradas variadas, ainda erra a taxa alvo, não que seu primeiro prompt de uma linha pareceu estranho. Se você não executou esse teste, você não está pronto para ajuste fino.

JunoPara o que é bom, e para o que não é Ajuste fino é para forma: uma forma de saída fixa, um tom definido, uma tarefa estreita mantida estável, mais prompts mais curtos que economizam tokens a cada chamada. A matemática de custo é treinamento fixo uma vez versus tokens de prompt pagos para sempre, então a economia de prompts compensa em alto volume. É ruim para fatos, que se misturam em padrões e ficam obsoletos, então emparelhe um modelo ajustado com RAG: forma dos pesos, fatos da recuperação. E prove que prompting realmente falhou, um prompt real com exemplos testados em entradas variadas, antes de você subir.

Ajuste fino é confiável para forma e não confiável para fatos, e as razões são mecânicas. Forma, forma de saída, tom, convenções de tarefa, é uma regularidade comportamental que os pesos podem absorver em muitos exemplos. Fatos são discretos e mutáveis, e os pesos os armazenam com perda como padrões mesclados, não como linhas recuperáveis, então um modelo ajustado ainda confabula e ainda fica obsoleto no instante em que o fato subjacente se move.

Vá além do título e os riscos reais são as formas que um ajuste fino 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 tropeça em entradas que diferem. Esquecimento catastrófico é o oposto: treinar forte em uma tarefa estreita pode erodir habilidade geral não relacionada que o modelo base tinha, porque você está movendo pesos compartilhados, então seu classificador fica mais nítido enquanto seu raciocínio em tudo mais fica mais opaco. Drift de distribuição é o lento: um modelo ajustado na distribuição de entrada do trimestre passado decai conforme o tráfego real se afasta do que ele viu, e a degradação é silenciosa até você medir.

Duas consequências formam como você realmente executa isso. Primeiro, você não pode enviar um ajuste fino baseado em intuição; você precisa de um conjunto de eval, um lote isolado de entradas com respostas conhecidas-boas, pontuado antes e depois, para provar que o alvo melhorou e, não menos importante, que habilidade geral não regrediu. Segundo, cada mudança para comportamento desejado é outro trabalho completo: re-curar dados, re-treinar, re-eval, reimplantar um novo id. Esse arrasto operacional é por que métodos eficientes em parâmetros existem, formas de ajuste fino treinando um pequeno conjunto de pesos adicionados em vez de todo o modelo, mais barato de executar e armazenar, embora a decisão se ajuste fino seja inalterada por eles. De qualquer forma, prove que o ajuste fino não regrediu antes de você enviá-lo.

JunoPara o que é bom, e para o que não é Forma é absorvida em pesos, fatos não são: um ajuste fino ainda confabula e fica obsoleto, então mantenha fatos em recuperação. Os riscos são overfitting (memorizando seu conjunto, tropeçando em novas entradas), esquecimento catastrófico (treinamento estreito erosionando habilidade não relacionada pois os pesos são compartilhados), e drift de distribuição conforme o tráfego real se afasta de seus dados de treinamento. Então feche cada ajuste fino em uma eval isolada pontuada antes e depois para provar nenhuma regressão, e orçamente para o fato de que cada mudança de comportamento é um ciclo completo de re-treinar-eval-reimplantar, que é toda a razão que métodos eficientes em parâmetros existem.

Prompt, RAG, ou ajuste fino?

Na maioria das vezes você não começa aqui. As três técnicas formam uma escada, mais barata e rápida de mudar primeiro:

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

Eles não são exclusivos, e os sistemas mais fortes os combinam: ajuste fino um modelo para seu formato e tom, então use RAG para alimentá-lo com fatos atuais em tempo de execução. Comportamento do treinamento, conhecimento da recuperação.

Então um teste rápido antes de você ajustar fino. Você consegue chegar lá com um prompt melhor? Então faça isso. É a lacuna conhecimento faltando? Então é RAG.

Suba a escada; ajuste fino é o último degrau, não o primeiro. Apenas quando o prompt já está correto, os fatos já estão disponíveis, e o modelo ainda não se comportará consistentemente o suficiente é que o ajuste fino se torna a ferramenta que se encaixa.

JunoPrompt, RAG, ou ajuste fino? Trate os três como uma escada: prompt primeiro porque é instantâneo e barato, adicione RAG quando o modelo está faltando conhecimento, e ajuste fino apenas quando a lacuna é comportamento que prompting não consegue deixar consistente, ou para encurtar prompts longos em escala. Eles se combinam bem: ajuste fino para forma, use RAG para fatos. Ajuste fino é o último degrau que você alcança, não o primeiro.

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

1. Prompting. Primeiro, sempre. Você itera em segundos sem custo de treinamento extra, e uma instrução clara com alguns exemplos cobre mais terreno do que as pessoas esperam. Até que um prompt real tenha sido testado e falhado, os degraus mais altos são prematuros.
2. RAG. Quando a lacuna é conhecimento, fatos que o modelo carece ou que mudam com o tempo, a recuperação os fornece no tempo da pergunta e deixa os pesos sozinhos. Atualizar um fato é atualizar sua fonte, não re-treinar.
3. Ajuste fino. Quando a lacuna é comportamento que prompting não consegue fixar, ou quando prompts cresceram longos o suficiente que incorporar instruções nos pesos é mais barato em escala.

O diagnóstico que o coloca no degrau correto é nomear a lacuna. Um formato ou tom errado é uma lacuna de comportamento, então prompt, depois ajuste fino. Um fato faltando ou desatualizado é uma lacuna de conhecimento, então recupere. Mal interprete a lacuna e você ajustará fino para consertar um problema de conhecimento e o verá ficar obsoleto, ou colocará fatos em um prompt que uma etapa de recuperação deveria ter buscado.

Eles não são exclusivos, e o padrão combinado é aquele que você alcança em produção: ajuste fino para forma, RAG para fatos, juntos. Um modelo ajustado para seu formato e tom, alimentado com fatos atuais em tempo de execução, oferece forma consistente e conteúdo fresco ao mesmo tempo, nem qual a outra técnica entregaria sozinha.

Se você consegue ajustar fino depende do modelo. Provedores fechados oferecem ajuste fino gerenciado de seus próprios modelos; um modelo de peso aberto você pode ajustar fino você mesmo em seus próprios termos, que é uma das razões para alcançar pesos abertos (Modelos abertos e fechados).

JunoPrompt, RAG, ou ajuste fino? Suba a escada do degrau mais barato: prompt primeiro, adicione RAG quando a lacuna é conhecimento, ajuste fino apenas quando é comportamento que prompting não consegue fixar ou para encurtar prompts em escala. O diagnóstico é nomear a lacuna, formato ou tom significa comportamento, um fato faltando ou obsoleto significa recuperação. O movimento de produção é ambos juntos: ajuste fino para forma, RAG para fatos, para que você obtenha forma consistente e conteúdo fresco ao mesmo tempo.

A escada, prompt depois RAG depois ajuste fino, é ordenada por custo de iteração: quão rápido e barato é mudar comportamento uma vez enviado. 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 ajuste fino é uma execução de treinamento, uma passagem de eval, 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.

A habilidade real é diagnosticar a lacuna corretamente, porque o modo de falha é escolher a ferramenta que não a aborda. Uma lacuna de comportamento (forma errada, tom errado, aderência inconsistente a tarefa) é o que prompting e depois ajuste fino consertam. Uma lacuna de conhecimento (um fato que o modelo carece, ou um que muda) é o que a recuperação conserta, e ajustar fino uma lacuna de conhecimento é o erro clássico caro: você treina fatos, eles ficam obsoletos pela próxima atualização, e você não consegue citá-los.

Mantenha a assimetria operacional ao lado do diagnóstico. O custo recorrente de RAG é qualidade e latência de recuperação a cada chamada, pago para sempre mas ajustável ao vivo. O custo recorrente de ajuste fino é uma re-execução a cada mudança no comportamento aprendido, mais o risco de regressão que cada execução carrega.

Então a arquitetura combinada não é um compromisso, é o design: ajuste fino forma nos pesos, mantenha fatos em recuperação, e versione cada um independentemente. Forma muda raramente e tolera um ciclo de atualização lento; fatos mudam constantemente e demandam um rápido. Dividir os deixa cada um se mover em seu próprio ritmo, e deixa você re-eval o modelo ajustado sem re-indexar seu corpus, ou refrescar o corpus sem re-executar um trabalho de treinamento.

JunoPrompt, RAG, ou ajuste fino? A escada é ordenada por custo de iteração: um prompt edita em segundos, uma fonte atualiza sem o modelo, um ajuste fino é um trem-eval-reimplanta completo. Diagnostique a lacuna antes de você escolher, comportamento vai para prompting depois ajuste fino, conhecimento vai para recuperação, e ajuste fino uma lacuna de conhecimento é o erro custoso que envia fatos obsoletos e não-citáveis. A arquitetura de produção a divide propositalmente: ajuste fino forma nos pesos, mantenha fatos em recuperação, versione cada um independentemente para que forma possa se mover lentamente e fatos possam se mover rápido.

Na prática

Dados de ajuste fino não são nada exótico. Cada exemplo é uma conversa curta na forma exata que você envia em tempo de execução, terminando com a resposta que você deseja que o modelo tivesse dado:

# Alguns mostrados aqui; um conjunto de dados real é centenas a milhares de exemplos,
# cobrindo a gama completa de entradas que você espera em tempo de execução.
training_examples = [
    {"messages": [
        {"role": "system", "content": "Classifique a urgência do ticket como baixa, média ou alta."},
        {"role": "user", "content": "Fui cobrado duas vezes esta semana e preciso que seja corrigido hoje."},
        {"role": "assistant", "content": "alta"},
    ]},
    {"messages": [
        {"role": "system", "content": "Classifique a urgência do ticket como baixa, média ou alta."},
        {"role": "user", "content": "Existe uma configuração de modo escuro em algum lugar?"},
        {"role": "assistant", "content": "baixa"},
    ]},
    # ...
]

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

# O modelo ajustado fino é outro id; tudo mais é inalterado.
response = client.chat.completions.create(
    model="your-org/urgency-classifier-v1",
    messages=[
        {"role": "system", "content": "Classifique a urgência do ticket como baixa, média ou alta."},
        {"role": "user", "content": "O botão de exportação não faz nada quando eu clico nele."},
    ],
)
# response.choices[0].message.content -> "baixa"  (apenas o rótulo, o comportamento que você treinou)

A vitória é que o comportamento agora vive no modelo. As instruções podem ser mais curtas, o formato se mantém em milhares de chamadas, e você não teve que crescer o prompt para chegar lá. O custo é tudo em volta: você precisa de um conjunto de dados de qualidade, uma execução de treinamento, e um trabalho fresco cada vez que você quer mudar o que aprendeu, que é exatamente por que isso senta no fundo da escada. Faça upload de exemplos, obtenha um id de modelo, chame-o como qualquer outro.

JunoNa prática Dados de ajuste fino são conversas de exemplo terminando na resposta que você quer, algumas centenas a alguns milhares delas. Você faz upload do arquivo, executa um trabalho de treinamento, e obtém de volta um novo id de modelo que você chama como qualquer outro. O comportamento está então incorporado, então prompts ficam mais curtos e o formato permanece consistente, ao custo de construir o conjunto de dados e re-executar o trabalho sempre que precisar mudar.

O fluxo de trabalho é fazer upload, treinar, chamar, mas a parte que decide se funciona é o conjunto de dados, não o trabalho. Qualidade e cobertura importam mais do que contagem bruta. Centenas de exemplos limpos e consistentes que cobrem a gama real de entradas batem milhares de confusos ou contraditórios, porque o modelo aprende qualquer regularidade realmente nos dados, incluindo os erros.

Divida seus dados antes de treinar. Reserve uma fatia que o modelo nunca vê durante o treinamento, o conjunto de validação, e verifique sua acurácia lá em vez de nos exemplos em que treinou. Um modelo pode marcar quase perfeitamente em dados que já viu enquanto faz mal em qualquer coisa nova, então o número isolado é o que diz se o comportamento generaliza.

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

Dois julgamentos repousam no topo da mecânica. Primeiro, confirme que prompting realmente falhou antes de gastar uma execução de treinamento: uma instrução real com alguns exemplos, testada em entradas variadas, não seu primeiro rascunho áspero. Segundo, pese o custo cuidadosamente. Um ajuste fino é um custo de treinamento fixo pago uma vez contra um custo por chamada de um prompt longo pago para sempre, então a economia de prompts compensa apenas quando o volume de chamadas torna os tokens salvos dignos do trabalho. E lembre-se do padrão combinado: um modelo ajustado para forma, RAG para os fatos que ele não deve tentar memorizar.

JunoNa prática O trabalho é fazer upload-treinar-chamar, mas o conjunto de dados decide o resultado: alguns centenas de exemplos limpos e variados batem milhares de confusos, pois o modelo aprende o que está realmente nos dados. Reserve uma fatia de validação e pontue lá, não nos exemplos de treinamento, ou um modelo que memorizou parecerá melhor do que é. Confirme que prompting realmente falhou primeiro, pese custo de treinamento fixo contra tokens de prompt pagos para sempre, e emparelhe o modelo ajustado com RAG para que ele lide com forma enquanto a recuperação lida com fatos.

O pipeline é fazer upload, treinar, avaliar, implantar, e a engenharia vive no conjunto de dados e no conjunto de eval, não na chamada de treinamento. Duas disciplinas de divisão as carregam. Um conjunto de validação, isolado do treinamento, diz a você se o comportamento generalizou em vez de ser memorizado. Um conjunto de eval isolado separado, pontuado antes e depois, é o que prova que o ajuste fino ajudou seu alvo sem regressar habilidade geral, a verificação de esquecimento catastrófico da seção anterior tornada concreta.

# Três fatias disjuntas: treine em uma, tome decisões de ajuste em outra, julgue em uma terceira.
train_set      = examples[:8000]        # o trabalho treina nesses
validation_set = examples[8000:9000]    # observe overfitting durante a execução
eval_set       = examples[9000:]        # pontuado antes E depois para provar nenhuma regressão

# Pontue o modelo base e o ajuste fino no MESMO eval_set, depois compare.
base_score = run_eval(base_model_id, eval_set)
tuned_score = run_eval(fine_tuned_id, eval_set)
# Implante apenas se tuned_score vencer base no alvo E se sustente em verificações de habilidade geral.
# Pontuação de eval e a API de treinamento variam por provedor; a disciplina não.

Qualidade do conjunto de dados é onde overfitting e drift são ganhos ou perdidos. Um conjunto estreito ou excêntrico treina um modelo que memoriza as idiosincrasias de seu conjunto e tropeça em entradas que diferem, então a cobertura da distribuição de entrada real importa mais do que contagem, e você re-mede conforme o tráfego de produção se afasta do que você treinou. Evals obsoletos são como um modelo quietamente derivando passa em revisão e falha em usuários.

A realidade operacional para a qual você design é que cada mudança no comportamento aprendido é uma execução completa, não uma edição. Re-curar, re-treinar, re-eval, reimplantar um novo id fixado, cada vez. Esse custo recorrente, mais o risco de regressão a cada execução, é por que você mantém fatos em RAG onde eles atualizam ao vivo, reserva ajuste fino para comportamento que muda lentamente, e trata cada id ajustado como um artefato versionado que você pode reverter quando uma execução nova regride.

JunoNa prática O pipeline é fazer upload-treinar-eval-implantar, e o trabalho está nas divisões de dados, não na chamada: um conjunto de validação pega memorizando, um conjunto de eval isolado pontuado antes e depois prova nenhuma regressão. Cobertura do conjunto de dados da distribuição de entrada real é como você bate overfitting e drift, então re-meça conforme o tráfego se afasta de seus dados de treinamento. E design para o custo recorrente, cada mudança de comportamento é um retreina-eval-reimplanta completo, que é por que fatos pertencem em RAG e cada id ajustado é um artefato versionado que você pode reverter.

Esse é o último das formas de moldar o que um modelo sabe e como responde, todos os quais o deixam prevendo texto em uma mesa que você arranjou. Os próximos capítulos dão a ele a habilidade de agir: em Uso de ferramentas o modelo chama suas próprias funções, e depois as executa em um loop como um agente.