Como um modelo aprende: treino, parâmetros e inferência
A intuição por trás de treinar e usar um modelo, sem cálculo, só o que um arquiteto precisa.
5 min de leitura
Escolha como aprender
combine como quiserDica: o vídeo é um resumo visual rápido; o áudio e o texto trazem a aula completa. Terminar o áudio ou o vídeo, ou passar no quiz, já conta a aula como concluída.
Antes de usar qualquer modelo de IA em produção, você precisa entender uma distinção fundamental: treinar um modelo e usar um modelo são duas operações completamente diferentes, com custos, atores e decisões de arquitetura opostos. Este lesson desmonta essa diferença com intuição, sem cálculo, e conecta direto ao que você vai fazer no dia a dia.
Treino: ajustar bilhões de botões até o erro cair
Imagine um painel com bilhões de botões giratórios. Cada botão é um parâmetro (também chamado de peso). O modelo começa com valores aleatórios nesses botões, ele não sabe nada. Você então alimenta exemplos: textos, imagens, pares de pergunta e resposta. Para cada exemplo, o modelo produz uma saída, você mede o quão errada ela está (isso é a função de perda), e um algoritmo chamado backpropagation gira cada botão um pouquinho na direção que reduz esse erro.
Repita isso bilhões de vezes, com trilhões de tokens de texto, em clusters de GPUs rodando semanas ou meses. No final, os parâmetros convergiram para valores que fazem o modelo produzir saídas úteis para uma enorme variedade de entradas. Esse processo é o pré-treino: caro, lento, feito por labs como Anthropic, Meta, Google, Amazon. Você não faz isso.
O resultado do treino é um arquivo (ou conjunto de arquivos) com todos esses pesos salvos. É literalmente o modelo. Tudo que o modelo 'sabe' está codificado nesses números, não em um banco de dados separado, não em regras explícitas. Só nos pesos.
Do treino à inferência: o ciclo de vida de um modelo
Treino acontece uma vez (ou raramente). Inferência acontece toda vez que sua aplicação faz uma chamada. São mundos separados.
- Dados de treino · Trillhões de tokens
- Cluster de GPUs · Semanas / meses
- Backpropagation · Ajuste de pesos
- Arquivo de pesos · (o modelo treinado)
- Dados específicos · do domínio
- Fine-tuning · Horas / dias
- Sua aplicação · (API call)
- Endpoint do modelo · (ex: Bedrock)
- Resposta gerada · (tokens de saída)
Inferência: o que você realmente faz em produção
Inferência é o ato de usar o modelo treinado para produzir uma saída a partir de uma entrada. Você envia um prompt, o modelo passa esse texto pelos pesos (agora fixos, sem ajuste) e devolve uma resposta. É uma operação de leitura nos parâmetros, não de escrita.
Do ponto de vista de custo, a diferença é brutal. Treinar um modelo grande custa dezenas de milhões de dólares em compute. Uma chamada de inferência custa frações de centavo. Por isso a divisão de responsabilidade faz sentido: labs investem no treino, você consome inferência via API.
Do ponto de vista de latência, inferência é o que determina a experiência do usuário. Cada token gerado exige uma passagem pelos pesos, modelos maiores têm mais pesos, logo mais operações por token, logo mais latência. Essa é a razão pela qual escolher o modelo certo para o caso de uso importa: um modelo de 7 bilhões de parâmetros responde muito mais rápido que um de 70 bilhões, e para muitas tarefas a qualidade é suficiente. Vamos explorar essa decisão de forma aprofundada na lição sobre Amazon Bedrock.
Na prática, quando você integra um LLM na sua aplicação, seja via AWS Bedrock, OpenAI, ou qualquer outro provedor, você está 100% do tempo fazendo inferência. O treino já aconteceu antes, longe de você.
Treino vs. Fine-tuning vs. Inferência
| Aspecto | Pré-treino | Fine-tuning | Inferência |
|---|---|---|---|
| Quem faz | Labs (Anthropic, Meta…) | Você / Lab parceiro | Você (via API) |
| Custo | Altíssimo (milhões $) | Médio (centenas–milhares $) | Baixo (frações de ¢ por chamada) |
| Frequência | Raríssima (uma vez por versão) | Ocasional (por domínio/tarefa) | Contínua (cada request) |
| Pesos mudam? | Sim, criados do zero | Sim, ajustados a partir do base | Não, apenas leitura |
| Você precisa disso? | Não | Raramente | Sempre |
Fine-tuning: quando vale e quando é desperdício
Fine-tuning é um treino adicional, mais curto, sobre um modelo já pré-treinado. Você pega os pesos existentes como ponto de partida e os ajusta com exemplos do seu domínio específico. O modelo não esquece o que aprendeu, ele especializa.
Soa tentador. Na prática, a maioria dos casos de uso não precisa de fine-tuning. Por quê? Porque modelos modernos são incrivelmente capazes via prompt. Se você quer que o modelo responda em português formal, basta dizer isso no prompt. Se quer um formato específico de saída, demonstre no prompt. A lição sobre prompting vai detalhar isso, mas o ponto aqui é: fine-tuning tem custo, complexidade de pipeline, risco de regressão, e exige dados de qualidade. Não é a primeira ferramenta a pegar.
Fine-tuning faz sentido quando: (a) você precisa de um estilo ou vocabulário muito específico que o prompt não consegue injetar de forma confiável; (b) você quer reduzir o tamanho do prompt em produção para economizar tokens; (c) você tem dados proprietários que ensinam comportamentos que o modelo base não tem. Fora desses casos, prompting bem feito, e eventualmente RAG para injetar conhecimento externo, resolve. Vamos ver RAG na lição 06.
Ligue o conceito à definição
Toque num conceito e depois na definição.
Na prática, em 95% dos projetos que já arquitetei ou revisei, a decisão certa foi: use um modelo de fundação via API (Bedrock, por exemplo), invista em prompting e RAG, e só considere fine-tuning se tiver evidência clara de que o modelo base não atende. O erro mais comum que vejo é ir direto para fine-tuning como solução para um problema de prompt mal escrito. É como trocar o motor do carro porque o motorista não sabe dirigir.
O que fixar desta lição
Dúvidas frequentes
Se os pesos não mudam na inferência, como o modelo 'aprende' com o contexto da conversa?
Ele não aprende, ele lembra, dentro da janela de contexto. O histórico da conversa é passado como parte do input a cada chamada. Os pesos continuam fixos; o que muda é o que você coloca no prompt. Isso é um ponto central da lição 03 (contexto e tokens) e da lição 12 (memória de agentes).
Fine-tuning muda os pesos permanentemente?
Sim, para aquela versão do modelo. O modelo base original não é alterado, você gera um novo artefato de pesos ajustados. Técnicas como LoRA fazem isso de forma mais eficiente, treinando apenas uma fração dos parâmetros.
Posso treinar meu próprio LLM do zero?
Tecnicamente sim. Praticamente, o custo de compute, dados e expertise coloca isso fora do alcance da esmagadora maioria das empresas. A decisão de arquitetura sensata é usar modelos de fundação existentes e customizá-los via prompt, RAG ou fine-tuning quando necessário.