Como um LLM é realmente treinado?

Continuando a série de posts em que procuro destrinchar as entranhas de um LLM↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI →, chegamos a uma questão fundamental: como um modelo é treinado?

Bem, existe uma frase que ouvimos com frequência: “Esse modelo foi treinado com trilhões de tokens.”

É, parece simples. Mas essa frase esconde uma cadeia complexa de decisões. Treinar um LLM envolve engenharia de software, matemática, estatística, ciência de dados↳Engenharia de dados43 conteúdosResolvendo desafios de Big Data com Ciência de Dados na UberData · abr 2019Análise de dados com Python e tabelas dinâmicas com PandasData · mai 2019Ferramentas para análise de dados são cada vez mais fundamentais para auxiliar pessoas desenvolvedorasData · jun 2024Ver tudo em Data →, infraestrutura, computação distribuída e, principalmente, decisões sobre quais dados o modelo deverá aprender e quais comportamentos se deseja obter. E existe um detalhe importante: o pré-treinamento é apenas uma parte da história.

Vamos abrir a caixa-preta. Tudo começa pelos dados. Antes de existir Transformer, GPU ou função de perda, alguém precisa decidir o que será utilizado para treinar o modelo. Podem entrar páginas da Web, livros, artigos científicos, enciclopédias, código-fonte, fóruns, documentos públicos, datasets licenciados, dados proprietários e, cada vez mais, dados sintéticos.

Mas a Internet não é simplesmente um dataset pronto para treinamento. Ela contém textos excelentes, mas também spam, propaganda, duplicações, páginas geradas automaticamente, conteúdo tóxico, informações pessoais, código de baixa qualidade e uma quantidade enorme de material pouco útil para determinado objetivo.

Por isso, uma das etapas mais importantes acontece antes do treinamento: curadoria e preparação dos dados. É necessário tratar HTML↳HTML45 conteúdosA importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Como hostear seu site HTML gratuitamente com GitHub PagesDev (Back & Front) · jun 2025SQL Server – Como criar um versionamento de código das suas Stored Procedures em HTML e com comentários da alteraçãoData · nov 2020Ver tudo em Dev (Back & Front) → e elementos de navegação, problemas de encoding e Unicode, documentos corrompidos e conteúdos inadequados ao objetivo do treinamento. Depois vêm mecanismos de filtragem de qualidade e relevância, que podem utilizar heurísticas, classificadores e outros modelos para selecionar ou ponderar os documentos.

E surge uma questão interessante: quem treinou o filtro que decide o que é um bom dado? Toda filtragem incorpora escolhas e pode introduzir vieses. Filtrar demais pode eliminar justamente a diversidade necessária para que o modelo aprenda diferentes formas de linguagem, conhecimento e expressão.

Depois vem outra etapa fundamental: deduplicação. Imagine o mesmo texto publicado em 500 sites. Não temos 500 informações independentes. Temos, em grande medida, a mesma informação repetida. Podem ser identificadas duplicações exatas e quase duplicações e, dependendo do pipeline, documentos altamente semelhantes. Isso reduz desperdício computacional e pode diminuir a influência excessiva de conteúdos repetidos.

Mas ainda precisamos decidir quanto de cada tipo de dado entrará no treinamento. Quanto de código? Quanto de livros? Quanto de Web? Quanto de matemática? Quanto de ciência? Quanto de cada idioma? Essa composição, frequentemente chamada de data mixture, influencia as capacidades e características que o modelo desenvolverá.

Um modelo exposto a uma proporção elevada de código, por exemplo, pode apresentar características diferentes de outro treinado com maior participação de literatura, matemática ou conteúdo conversacional. O dataset não é apenas uma coleção de dados. É uma decisão de engenharia.

Depois chegamos à tokenização. O modelo não recebe palavras diretamente. Uma frase como: “Inteligência artificial está mudando o software” é convertida em uma sequência de tokens. Dependendo do tokenizer, uma palavra pode corresponder a um token ou ser dividida em vários pedaços. Esses tokens são então associados a representações numéricas e processados pela arquitetura do modelo.

Agora começa o pré-treinamento. Em um modelo causal, o objetivo básico é prever o próximo token a partir do contexto anterior.

Dada uma sequência como: “O gato subiu no…” o modelo produz uma distribuição sobre possíveis próximos tokens. O token observado no corpus funciona como alvo, e a diferença entre a distribuição prevista e esse alvo é medida por uma função de perda, normalmente baseada em cross-entropy. Quanto maior a probabilidade atribuída ao token correto, menor tende a ser a perda.

E aqui acontece uma das etapas fundamentais. O erro é propagado pela rede por meio de backpropagation. Os gradientes calculados são utilizados por algoritmos de otimização, como AdamW ou variantes, para atualizar os parâmetros do modelo.

Bilhões de parâmetros são ajustados repetidamente sobre enormes quantidades de tokens. É assim que, ao longo do treinamento, os parâmetros passam a representar regularidades cada vez mais complexas presentes nos dados.

Mas o processo enfrenta outro problema: modelos muito grandes não cabem em uma única GPU. O treinamento precisa ser distribuído. Podemos distribuir diferentes partes dos dados entre máquinas, dividir operações matemáticas entre GPUs e particionar a própria rede. Entram técnicas como data parallelism, tensor parallelism e pipeline parallelism, frequentemente combinadas. O treinamento se transforma, então, em um gigantesco sistema distribuído, no qual a comunicação entre GPUs pode ser tão importante quanto o próprio cálculo.

Também precisamos lidar com precisão numérica. Utilizar alta precisão em todas as operações seria extremamente caro. Por isso, formatos como FP16 e BF16 são utilizados em diferentes partes do treinamento para reduzir consumo de memória e acelerar cálculos, enquanto determinados estados e operações podem utilizar precisões diferentes. Isso exige monitoramento de estabilidade numérica, gradientes, memória e outros sinais de problemas durante a execução.

Existe uma regra prática: um treinamento gigantesco não pode depender de que nada dê errado. GPUs falham. Máquinas falham. Redes falham. Processos podem falhar. Por isso, checkpoints são armazenados regularmente para permitir a recuperação do treinamento a partir de estados anteriores. Durante o processo, são acompanhadas métricas como training loss, validation loss, perplexity, throughput e utilização dos recursos computacionais.

Mas existe uma armadilha: uma loss menor não significa necessariamente um modelo melhor em todos os aspectos. O modelo pode melhorar sua capacidade de prever determinados dados e, simultaneamente, apresentar problemas em capacidades ou comportamentos importantes. Por isso, são necessárias avaliações independentes.

E surge outro problema crítico: data contamination. Imagine que uma questão de um benchmark tenha aparecido no material utilizado no treinamento. O modelo pode responder corretamente porque teve contato anterior com aquela informação. Parece inteligência. Pode ser simplesmente memorização. Por isso, construir bons conjuntos de avaliação e reduzir o risco de contaminação é tão importante quanto construir bons conjuntos de treinamento.

Também precisamos decidir quanto de computação utilizar e como equilibrar parâmetros, dados e capacidade computacional. As chamadas scaling laws ajudaram a demonstrar relações sistemáticas entre esses fatores e transformaram o treinamento de grandes modelos também em um problema de otimização de recursos: dado determinado orçamento computacional, onde é melhor investi-lo? Mais parâmetros? Mais dados? Dados melhores? Mais treinamento? Dependendo da escala, essa decisão pode representar milhões de dólares.

Depois do pré-treinamento, temos o chamado base model. E aqui existe outro equívoco comum: um base model não é necessariamente um bom chatbot.

Ele foi treinado principalmente para modelar regularidades dos dados e prever tokens. Pode possuir capacidades extraordinárias, mas não foi necessariamente otimizado para seguir instruções, conversar com usuários ou obedecer às preferências que esperamos de um assistente.

Então podem entrar outras etapas. No Supervised Fine-Tuning (SFT), o modelo é ajustado utilizando exemplos de instruções e respostas consideradas adequadas.

Depois podem ser utilizadas técnicas de preference tuning, nas quais respostas são comparadas segundo preferências humanas ou critérios definidos por modelos avaliadores.

Dependendo do sistema, podem entrar técnicas como RLHF, DPO, rejection sampling ou RLVR. Elas não constituem uma sequência obrigatória. São estratégias diferentes que podem ser utilizadas para modificar, avaliar ou reforçar determinados comportamentos do modelo.

Existe uma distinção importante: alignment não significa necessariamente verdade. Podemos tornar um modelo mais útil, obediente ou alinhado a determinadas preferências sem garantir que suas respostas sejam factualmente corretas.

Finalmente, temos uma etapa que deveria receber muito mais atenção: red teaming e avaliação de segurança. Tentamos encontrar comportamentos indesejados, jailbreaks, problemas de privacidade, geração de conteúdo perigoso, vieses, alucinações e outras formas de falha.

Quando o modelo faz parte de um sistema que utiliza ferramentas, também precisamos avaliar riscos como uso indevido dessas ferramentas, manipulação de instruções e prompt injection. E depois avaliamos novamente. Matemática. Programação. Raciocínio. Conhecimento. Idiomas. Factualidade. Segurança. Robustez. Uso de ferramentas. E, principalmente, desempenho em condições próximas das situações reais de utilização. Porque benchmarks são úteis, mas nunca representam completamente o mundo real.

E temos uma última coisa importante. O desenvolvimento de um LLM não necessariamente termina quando ele chega à produção. Monitoramento, avaliação e coleta de novos dados podem continuar. Novos problemas podem ser identificados e, dependendo da estratégia adotada, podem levar a novos ciclos de treinamento, ajuste ou lançamento de versões posteriores.

No final, quando alguém diz: “Esse modelo foi treinado com 10 trilhões de tokens.”, essa frase esconde uma cadeia gigantesca de decisões: dados → preparação → filtragem → deduplicação → composição → tokenização → pré-treinamento → otimização distribuída → checkpoints → avaliação → SFT → alinhamento → red teaming → avaliação final.

E mesmo essa cadeia é uma simplificação. Diferentes laboratórios utilizam arquiteturas, datasets, objetivos, técnicas de treinamento e pipelines de avaliação diferentes.

Um LLM, portanto, não é apenas uma rede neural. É o resultado da combinação de: dados + arquitetura + algoritmos + computação + otimização + avaliação + alinhamento.

Por isso, dois modelos com arquiteturas semelhantes podem apresentar comportamentos muito diferentes. Portanto, a qualidade de um LLM começa muito antes da primeira GPU começar a calcular. Começa na escolha do que será ensinado.