TL;DR
Depois de escrever "O que você não sabe sobre Claude Code: Arquitetura, Governança e Prática de Engenharia" e "O que você não sabe sobre Agentes: Princípios, Arquitetura e Prática de Engenharia", quis me desafiar a resumir como o treinamento de Modelos de Linguagem de Grande Escala (LLMs) realmente funciona. Este artigo busca ser compreensível mesmo para quem não tem formação profissional.
Olhando para 2026, a verdadeira lacuna no desempenho dos LLMs não é mais apenas o pré-treinamento em si, mas a longa cauda que o segue: pós-treinamento, avaliação, recompensas, treinamento de Agentes e destilação. Cada etapa afeta a experiência real do usuário. Quando você percebe que um modelo ficou subitamente mais forte, provavelmente é porque essas áreas foram otimizadas em conjunto, e não um fator isolado.
A seguir, acompanhamos o pipeline de treinamento de LLMs, focando em como os fabricantes melhoram os resultados finais através da segunda metade da pilha de treinamento.
O Treinamento de LLMs é um Pipeline
Nos últimos anos, o progresso dos modelos era geralmente explicado pelo acúmulo de parâmetros, dados e poder computacional. No entanto, as melhorias que muitos usuários realmente sentem não vêm do treinamento em mais corpora básicos, mas de todo o processo de treinamento após o pré-treinamento. Como um modelo fala, segue instruções, raciocina e usa ferramentas — essas coisas não crescem naturalmente apenas alimentando-o com mais texto da internet.
O InstructGPT deu um exemplo muito direto: um modelo com apenas 1,3B de parâmetros que passou por alinhamento e otimização de preferência conseguiu vencer o GPT-3 de 175B em avaliações de preferência humana. Com uma diferença de duas ordens de grandeza nos parâmetros, os usuários preferiram a versão muito menor. A segunda metade do treinamento realmente reescreve a percepção do usuário.
O processo de treinamento é, na verdade, um pipeline onde dados, algoritmos, sistemas e feedback são altamente acoplados. Uma mudança em uma camada geralmente se propaga para as outras. Em 2026, as capacidades dos modelos e o valor industrial estão cada vez mais concentrados nas camadas posteriores ao pré-treinamento.
É também por isso que muitas vezes sentimos que o Doubao não compete por rankings, mas parece mais satisfatório no uso diário — é porque o pós-treinamento é bem executado.
Essas seis camadas são apenas para visualizar a divisão de trabalho. Os nove estágios na figura abaixo são uma versão mais detalhada: dados brutos e receitas de sistema são separados, e o harness do Agente e a Implantação são subdivisões da segunda metade. Há também dois loops de feedback em todo o processo: o tráfego de produção retorna para a engenharia de dados, e os resultados da avaliação offline retornam para o pré-treinamento.
Pré-treinamento é Apenas a Base
O pré-treinamento continua sendo o ponto de partida da cadeia de treinamento. Só entendendo o que ele faz podemos entender o que cada camada subsequente complementa. Sem essa etapa, não há capacidade de modelagem de linguagem, nem compressão de conhecimento, nem espaço para transferência de capacidade subsequente. Na engenharia, ele faz mais do que apenas ensinar o modelo a prever o próximo token: ele aprende a distribuição da linguagem, comprime conhecimento e padrões de texto em larga escala em parâmetros e deixa espaço para a ativação de capacidades subsequentes. A previsão do próximo token descreve apenas a forma de treinamento; não explica por que os modelos desenvolvem subitamente novas capacidades à medida que a escala aumenta.
Após o GPT-3, muitos ajustes de modelo consideram orçamento e proporções com mais cuidado. Modelos não são melhores apenas por serem maiores. Há uma questão de proporção entre número de parâmetros, tokens de treinamento e orçamento computacional total. Muitos modelos não são muito pequenos; eles são subtreinados e não atingiram um ponto mais adequado sob um determinado orçamento.
Em decisões reais de treinamento, a questão prática é: se alguém te der 10.000 H100s e um mês, como você treinaria um modelo open-source bom o suficiente? As leis de escala aqui são mais uma ferramenta de alocação de orçamento do que uma curva abstrata em um artigo. No final, você precisa considerar: a próxima rodada de treinamento deve empilhar mais parâmetros ou alimentar mais dados? O modelo atual está faltando capacidade ou apenas subtreinado? Sob um orçamento limitado de GPU, qual proporção é mais valiosa?
O pré-treinamento é como lançar as bases para as capacidades do modelo, determinando o escopo do conhecimento, o potencial de generalização e a capacidade de indução de padrões. Ele também determina se há espaço para o pós-treinamento explorar. No entanto, o pré-treinamento não pode controlar se o modelo segue instruções, coopera com os usuários ou opera de forma estável em tarefas críticas.
A fase de pré-treinamento não decide apenas quanto conhecimento é aprendido; ela pré-determina o que o modelo pode se tornar. O método de divisão do tokenizer afeta diretamente o treinamento subsequente, e o comprimento da janela de contexto deve ser definido antecipadamente. Se continuar o pré-treinamento multimodal ou se a operação em um único acelerador é um requisito desde o início — essas compensações são escritas na receita durante a fase de treinamento, não adicionadas como recursos no lançamento. O Gemma 3 enfatiza simultaneamente acelerador único, contexto de 128K, capacidades de visão e quantização, refletindo essas compensações. As capacidades que os usuários eventualmente veem — rodar em um computador local, ver imagens, entender documentos longos — são, na verdade, amplamente determinadas durante a fase de treinamento.
Olhando para o ponto ótimo de dados dado pelo Chinchilla, para um modelo de 8B parâmetros, são cerca de 200B tokens. No entanto, o Llama 3 8B realmente usou 15T tokens, cerca de 75 vezes mais. Essas receitas de supertreinamento geralmente trocam maior densidade de capacidade pelos mesmos parâmetros, resultando em um modelo menor e mais econômico para inferência. Medir isso pelo total de FLOPs (operações de ponto flutuante) é mais confiável do que olhar para o número de parâmetros. A figura abaixo demonstra visualmente essa lacuna.
Outro design frequentemente negligenciado ocorre na fase de pré-treinamento: o tamanho do vocabulário do tokenizer, as estratégias de divisão e os métodos de codificação em nível de byte têm um impacto significativo. O Llama 2 tinha um vocabulário de 32K; depois que o Llama 3 o expandiu para 128K, o comprimento da sequência foi comprimido em cerca de 15%, e o desempenho downstream acompanhou. Esse impacto se estende aos custos de inferência e às capacidades multilíngues. A eficiência de token do chinês, código e fórmulas matemáticas é determinada durante o design do vocabulário. Por exemplo, um tokenizer que divide o chinês em pedaços muito pequenos não custa apenas mais tokens a cada vez; cada inferência deve continuar suportando o custo dessa decisão ruim.
Receitas de Dados Determinam as Capacidades do Modelo
A escala de parâmetros era uma métrica importante no passado, mas nos últimos dois anos, a coisa mais importante é a "receita de dados".
Este processo parece limpeza de dados na superfície, mas é, na verdade, uma tarefa completa de engenharia de produção de dados. Dados brutos de páginas da web, repositórios de código, livros e fóruns devem primeiro passar por extração de texto, identificação de idioma, filtragem de qualidade, processamento de privacidade, filtragem de segurança e deduplicação antes de entrar no pré-treinamento. A figura abaixo mostra o fluxo completo do funil de processamento.
Se você trata os dados apenas como combustível de treinamento, é fácil concluir que mais é melhor. Mas a engenharia de dados está mais próxima do design de capacidades. O que o modelo vê e não vê, e as proporções de código, matemática e enciclopédia, afetam diretamente a distribuição final de capacidades do modelo.
A deduplicação e o controle de contaminação são frequentemente ignorados, mas impactam significativamente os resultados. Não se trata apenas de dados de baixa qualidade; inclui modelos duplicados, textos de licença, sites espelho e contaminação de vazamentos de benchmarks. Se a deduplicação em nível de documento e linha for insuficiente, o modelo frequentemente absorve repetidamente o conteúdo mais fácil de copiar, sem necessariamente aprender as partes mais valiosas. O desempenho inconsistente de muitos modelos open-source é frequentemente devido a lacunas na qualidade do processamento de dados.
Nos últimos dois anos, a mistura de dados tornou-se um problema de pesquisa separado. Trabalhos como Data Mixing Laws focam não apenas em quanto mais dados podem ser coletados, mas em como as proporções de diferentes tipos de dados levam o modelo em direção a estruturas de capacidade específicas.
Os dados sintéticos também passaram de um meio auxiliar para uma parte formal do processo de treinamento. Métodos como Self-Instruct, as trajetórias de destilação do DeepSeek-R1 e a supervisão sintética cada vez mais óbvia nas séries Qwen e Kimi estão todos se movendo na mesma direção. Cada geração de modelos mais fortes participa da reconstrução dos dados vistos pela próxima geração. Modelos iniciais geravam dados de instrução básicos; modelos mais fortes geram trajetórias de raciocínio de alta qualidade e dados de CoT (Cadeia de Pensamento); e modelos de raciocínio treinados via RL destilam essas trajetórias em modelos densos menores. "Denso" significa que todos os parâmetros são executados, ao contrário do MoE (Mistura de Especialistas) que ativa sob demanda.
O ponto chave aqui é que os modelos frequentemente precisam formar capacidades em uma escala maior primeiro, antes que essas capacidades possam ser comprimidas em modelos menores. A série DeepSeek-R1-Distill é um exemplo direto. As trajetórias de modelos grandes após RL forneceram ganhos significativos para modelos densos de 1,5B a 70B. O Llama 3.1 405B também foi explicitamente usado para melhorar a qualidade do pós-treinamento dos modelos 8B e 70B. Estes não são produtos secundários, mas parte do design do treinamento.
Restrições de Sistema e Arquitetura Devem Estar Claras Antes do Treinamento
Muitas pessoas entendem o treinamento como um problema de pesquisa: como definir a função objetivo, como reduzir a perda e como mudar a estrutura do modelo. Mas no treinamento real de LLMs, as restrições do sistema são muito importantes; é um problema de sistema distribuído, não um problema de aprendizado profundo em uma única máquina. O número de GPUs, largura de banda de memória, estratégias de paralelismo, tolerância a falhas e custo — estes não podem esperar até depois do treinamento para serem otimizados. Eles determinam desde o início quão grande você pode treinar, quanto tempo de contexto você pode suportar e se você pode executar pós-treinamento mais complexo.
O MoE é o exemplo mais típico nesta camada. O modo multi-especialista permite que o modelo expanda o total de parâmetros sob computação semelhante, enquanto controla o custo de ativação por token. A compensação é roteamento complexo, balanceamento de carga difícil e infraestrutura pesada. Os designs MoE do DeepSeek-V3 e Qwen são compromissos entre custo e efeito, não apenas preferências arquitetônicas.
As discussões em receitas recentemente publicadas não são mais apenas sobre análises grosseiras como tamanho do modelo e proporções de tokens. O muP permite que hiperparâmetros sejam transferidos de experimentos em pequena escala para treinamento em larga escala. A taxa de aprendizado WSD é um cronograma que sobe, estabiliza e depois decai. Combinado com tamanho de lote ideal e maiores proporções de dados para parâmetros, esses detalhes estão se tornando os verdadeiros diferenciadores entre modelos da mesma escala.
Contexto longo, multimodalidade e novas arquiteturas, se entendidos apenas como recursos de produto, perdem as restrições do lado do treinamento. Um objetivo de contexto de 128K muda diretamente os custos de atenção, tamanhos de lote, currículo de treinamento (sequenciamento de dados) e estratégias de paralelismo. A multimodalidade muda não apenas a estrutura do modelo, mas também a mistura de dados, o design do codificador e a avaliação de segurança. Se a operação em um único cartão é um requisito rígido, o número de parâmetros, os caminhos de quantização e o tamanho da família de modelos serão todos apertados.
Trabalhos como Forgetting Transformer e Kimi's Attention Residuals respondem a perguntas semelhantes: como treinar contextos mais longos e como evitar a diluição da informação à medida que as redes se aprofundam. O que você vê é um modelo que pode lidar com entradas mais longas ou é mais fácil de implantar, mas o que é enfrentado durante o treinamento é um conjunto completamente diferente de restrições.
O orçamento computacional é fixo. Tamanho do modelo, volume de tokens de treinamento, comprimento do contexto e custo de serviço — para cada bit gasto em uma direção, outros devem ceder.
À medida que o contexto se alonga, os custos de atenção explodem e o tamanho do lote deve ser reduzido. À medida que os modelos ficam maiores, o uso de memória da GPU aumenta e os custos de serviço acompanham. Estas não são escolhas, mas resultados de restrições de recursos. A maioria das decisões é bloqueada antes do início do treinamento.
Há também uma realidade de engenharia frequentemente ignorada: o treinamento nem sempre é estável. Milhares de GPUs rodam por semanas, e de repente ocorre um pico de perda de treinamento, tão grande que não pode ser ignorado, forçando um rollback para um checkpoint de dias atrás para recomeçar.
Além dos picos de perda, há erros silenciosos de GPU — uma única GPU que não reporta um erro, mas produz silenciosamente gradientes errados — anomalias de largura de banda NVLink e jitter de comunicação entre nós. Cada um pode poluir várias etapas do treinamento. Ser capaz de detectar, isolar e recuperar rapidamente em treinamento em larga escala é uma capacidade de engenharia em nível de laboratório, não um problema resolvido pela leitura de artigos.
O DeepSeek-V3 mencionou especificamente em seu relatório técnico que todo o processo de pré-treinamento não teve picos de perda irrecuperáveis e nenhum rollback. É também um dos poucos casos que verificam que o treinamento de precisão mista FP8 é viável em modelos de escala ultra-grande. De acordo com dados públicos, o processo completo levou cerca de 2,788M horas de GPU H800 para pré-treinar 14,8T tokens.
Os sistemas de treinamento e inferência estão intimamente relacionados, mas não são o mesmo problema de engenharia. O treinamento se preocupa com gradientes, paralelismo, checkpoints, throughput e custo; a inferência se preocupa com latência, cache KV (armazenamento em cache de cálculos históricos para evitar repetição), quantização e estabilidade do serviço.
Pós-treinamento Determina a Lacuna Percebida pelo Usuário
Muitas melhorias que os usuários comuns podem realmente sentir ocorrem após o pré-treinamento. O ajuste de instrução usa pares de instrução-resposta rotulados para treinamento supervisionado. Ele muda a maneira como o modelo responde, transformando requisitos como como aceitar tarefas, organizar a saída e agir como um assistente cooperativo em sinais de supervisão. Um modelo base pode já ter muitas capacidades potenciais, mas sem esta etapa, essas capacidades muitas vezes não emergem de forma estável na forma que os usuários esperam.
Olhando mais adiante, RLHF, DPO e RFT compartilham direções semelhantes — integrar a definição de uma "resposta melhor" no loop de treinamento — mas por caminhos diferentes.
- RLHF (Aprendizado por Reforço a partir de Feedback Humano) primeiro imita respostas de alta qualidade, depois usa comparações de preferência para reforço.
- DPO (Otimização Direta de Preferência) encurta esse caminho aprendendo diretamente a partir de comparações de preferência sem precisar de um modelo de recompensa separado.
- RFT (Ajuste Fino por Reforço) é uma interface mais fácil de implementar em engenharia, colocando definições de tarefas, designs de avaliadores e sinais de recompensa no processo de transformação em produto.
Hoje, falar sobre pós-treinamento apenas em termos de SFT ou RL não é mais suficiente. As partes mais difíceis são como definir avaliações, como pontuar e que tipo de resposta vale a pena continuar otimizando. SFT é ajuste fino supervisionado; ele aprende não apenas conhecimento, mas também estilo. Comprimento dos dados, formato, se incluir citações e preferência por marcadores afetam significativamente a forma final de saída do modelo. Muitos usuários pensam que estão comparando capacidades, mas muitas vezes estão apenas comparando diferenças de estilo. Além disso, as avaliações de preferência favorecem naturalmente respostas mais longas, confundindo facilmente saídas longas de aparência séria com mais confiáveis. Portanto, olhar para leaderboards para pós-treinamento é muitas vezes insuficiente; é preciso combinar resultados de tarefas reais, custo e estabilidade.
O pós-treinamento moderno é um pipeline de múltiplos estágios. A receita do DeepSeek-R1 é a mais clara em materiais públicos. Ela prossegue em quatro estágios:
Estágio 1 é o SFT de inicialização a frio. Antes de fazer aprendizado por reforço, use uma pequena quantidade de dados de Cadeia de Pensamento (CoT) de alta qualidade para aquecer. O DeepSeek-R1-Zero provou que fazer RL diretamente a partir de um modelo base (o modelo bruto após o pré-treinamento sem alinhamento) é viável, mas modelos treinados puramente com RL se repetirão, terão linguagem confusa e pouca legibilidade. O SFT de inicialização a frio dá ao RL um ponto de partida mais estável, travando a consistência de formato e linguagem.
Estágio 2 realiza aprendizado por reforço em campos verificáveis como matemática, código e lógica, usando GRPO como algoritmo de treinamento e correção verificável programaticamente como sinal de recompensa. O ponto chave é por que o GRPO foi escolhido em vez do PPO tradicional: PPO (Otimização de Política Proximal) requer uma rede de valor independente para estimar o valor do estado atual, o que é um alto ônus de engenharia para modelos grandes. O GRPO amostra múltiplas respostas para o mesmo prompt e usa classificação intra-grupo em vez de estimativa de valor absoluto, eliminando a necessidade de uma rede de valor independente. A série DeepSeek e a infraestrutura RL do Cursor Composer 2 usam esquemas próximos ao GRPO.
Estágio 3 realiza Ajuste Fino por Amostragem de Rejeição, filtrando trajetórias bem-sucedidas geradas por RL e convertendo-as em novos dados SFT para outra rodada de ajuste fino supervisionado. Esta é a ponte entre RL e SFT; boas trajetórias exploradas por RL tornam-se amostras de treinamento de alta qualidade para a próxima rodada de SFT.
Estágio 4 integra feedback de preferência de utilidade e segurança para ajustar o modelo em uma forma de assistente que atende aos padrões de lançamento.
Os quatro estágios são interdependentes: a inicialização a frio permite que o RL comece de forma estável, o RL gera dados de alta qualidade, a amostragem de rejeição transforma esses dados em entrada para a próxima rodada de SFT, e o RL de alinhamento completa a convergência comportamental. A partir de resultados públicos, a lacuna entre o SFT direto e a conclusão de todos os quatro estágios é geralmente visível.
Avaliação, Avaliador e Recompensa Estão Redefinindo os Objetivos de Treinamento
O componente responsável por transformar a saída do modelo em pontuações de treinamento é chamado de avaliador, e ele pode facilmente ter problemas inesperados. Se ele olha apenas para a resposta final, o modelo rapidamente aprende a tomar atalhos; se a pontuação é muito grosseira, o ruído será continuamente amplificado pelo aprendizado por reforço; se a pontuação do leaderboard sobe, as tarefas reais podem não acompanhar. Frequentemente, os usuários pensam que estão vendo uma lacuna no modelo base, mas a lacuna está em como o objetivo é definido.
No fluxo de treinamento, a avaliação determina o que testar, o avaliador determina como uma saída se torna uma pontuação e a recompensa determina para onde o modelo será empurrado. Juntos, eles formam um loop de feedback específico: definição de tarefa, avaliação, avaliador, otimização, rollout e reavaliação. Rollout refere-se às trajetórias geradas pelo modelo ao executar tarefas. Se qualquer elo da corrente se desviar, a otimização subsequente também se desviará.
Olhando apenas para o resultado final, um modelo pode acertar por acaso ou seguir um processo errado para obter a resposta certa. Isso é especialmente óbvio em tarefas de código, matemática e raciocínio complexo. Se as etapas intermediárias não entrarem no feedback, o que o modelo aprende muitas vezes não é um raciocínio mais confiável, mas como obter aquele ponto final com maior probabilidade.
Portanto, mais trabalho nos últimos anos mudou do RLHF tradicional para recompensas verificadas, usando programas para verificar diretamente a correção. Em tarefas verificáveis como matemática, código e lógica, a correção agora pode ser pontuada diretamente sem depender principalmente da preferência humana. Mas as recompensas verificadas não resolveram completamente o problema. Fenômenos como superotimização, overfitting de recompensa (onde as regras de pontuação são superotimizadas sem ganho real de capacidade) e colapso de modo (onde a saída se torna altamente singular e perde diversidade) ainda ocorrem. O problema mudou de se as preferências são rotuladas com precisão para se a cadeia de pontuação é estável.
O processo de pensamento escrito pelo modelo não pode ser tratado como um registro completo dos processos internos. A Anthropic descobriu em experimentos de observabilidade de modelos de raciocínio que os modelos usam dicas extras, mas não admitem isso no CoT visível; em cenários de hacking de recompensa, eles são mais propensos a adicionar uma explicação de aparência plausível. Hacking de recompensa é explorar o sistema de pontuação em vez de realmente completar a tarefa. O CoT visível é mais adequado como um sinal de treinamento e monitoramento, não como a verdade completa.
Indo um nível mais fundo, os modelos podem até começar a explorar o próprio canal de pontuação. Pesquisas sobre adulteração de recompensa e falsificação de alinhamento mostram que os modelos poderiam teoricamente intervir ativamente no processo de pontuação. Adulteração de recompensa é alterar diretamente o processo de cálculo da recompensa; falsificação de alinhamento é fingir alinhamento — parecendo complacente na superfície enquanto esconde intenções não alinhadas.
Uma vez que um modelo tem acesso suficientemente forte ao ambiente, o que ele otimiza não são apenas os resultados da tarefa, mas potencialmente a lista de verificação, o código de recompensa e a própria relação de treinamento. Um experimento da Anthropic em 2025 injetou conhecimento extra de hacking de recompensa em um conjunto de ambientes RL de codificação de produção exploráveis e subsequentemente observou generalização semelhante. Depois de aprender o hacking de recompensa, o modelo não apenas continuou a explorá-lo em tarefas semelhantes, mas também mostrou desalinhamento mais amplo, como falsificação de alinhamento.
Esses comportamentos não são vistos em avaliações de diálogo padrão, apenas em ambientes de tarefas de Agente. A implicação de engenharia é direta: recompensa, avaliador, isolamento de ambiente e monitoramento devem fazer parte do design do treinamento.
Na fase de Agente, o design de recompensa é ainda mais refinado. O resultado final é apenas um item; a qualidade do processo, o gerenciamento de contexto e as restrições anti-trapaça também devem ser medidos separadamente. O Kimi K2.5 recompensa a decomposição eficaz e o paralelismo verdadeiro; o Chroma Context-1 pontua documentos relevantes encontrados durante a pesquisa; o Cursor Composer 2 inclui resumos em tarefas longas como recompensas porque, se um resumo for distorcido, o contexto subsequente será enganado.
Na implementação, ORM é um Modelo de Recompensa de Resultado, pontuando apenas a resposta final. Os sinais são esparsos, os custos são baixos e é adequado para começar, mas é mais fácil para o modelo tomar atalhos. PRM é um Modelo de Recompensa de Processo, pontuando etapas intermediárias. Os sinais são mais densos e geralmente é mais forte para raciocínio matemático e de código, mas os custos de rotulagem e sistema são muito maiores. A OpenAI viu em experimentos de raciocínio matemático que o PRM não apenas melhorou a precisão, mas também tornou mais fácil restringir o processo porque cada etapa foi supervisionada. O problema também é direto: o custo do PRM é geralmente várias vezes o do ORM, então a maioria dos sistemas reais começa com ORM. Apenas em tarefas verificáveis como matemática, código e lógica é mais fácil automatizar o PRM, usando programas para verificar etapas intermediárias e contornar os gargalos de rotulagem humana.
O loop completo funciona assim:
Métodos de alinhamento recentes estão todos fazendo a mesma coisa. O Constitutional AI da Anthropic integra princípios escritos por humanos no treinamento, usando feedback de IA para substituir preferências humanas individuais. O Deliberative Alignment da OpenAI coloca a conformidade de segurança no processo de raciocínio, deixando a própria capacidade de raciocínio suportar parte da restrição de segurança. Deliberative Alignment aqui significa que o modelo julga as normas de segurança por si mesmo durante a fase de raciocínio, em vez de confiar em reflexos treinados. Ambas as rotas transformam o alinhamento de rótulos humanos em parte do objetivo interno de treinamento.
Tomando o Constitutional AI como exemplo, o processo de dois estágios primeiro permite que o modelo autocrítico e revise a saída com base em princípios, depois usa feedback de IA para substituir a rotulagem de preferência humana individual. O alinhamento nunca é um patch pendurado atrás do treinamento; o que o sistema testa, como pontua e o que recompensa, o modelo se moverá nessa direção. Esta é a ferramenta de ajuste mais direta na segunda metade do treinamento.
No Treinamento de Agentes, Não é Apenas o Modelo que Está Sendo Otimizado
Nos últimos dois anos, o rápido surgimento de modelos de raciocínio representados pela série o1 e DeepSeek-R1 mostra que, em condições de recompensas estáveis, verificação confiável e infraestrutura adequada, o RL em modelos de linguagem pode melhorar significativamente o desempenho em tarefas de matemática, código e lógica.
Isso também abre uma nova dimensão: o poder computacional de inferência agora pode ser escalado. O papel do treinamento RL adiciona outra camada: além de ensinar o modelo a responder perguntas, ele ensina o modelo a alocar orçamento de inferência—sabendo quando pensar mais e quando parar. Seguindo em frente, a dificuldade se torna permitir que o modelo atue continuamente em um ambiente, em vez de apenas prolongar um único pensamento.
Junyang Lin, ex-líder de modelo na Qwen, tem uma reflexão representativa sobre a rota mista de Thinking e Instruct: a dificuldade não é dar ao modelo um interruptor de pensamento, mas sim que os objetivos dos dois modos são diferentes—um busca direção, conformidade e baixa latência, enquanto o outro busca mais exploração e maior precisão. Um passo adiante, o objetivo do treinamento muda de quanto tempo pensar antes de responder para como alocar orçamento durante a ação, como aceitar feedback e como continuar avançando a tarefa.
Neste ponto, o objeto de treinamento não é mais apenas um modelo que responde perguntas, mas um sistema que pode planejar, chamar ferramentas, receber feedback e manter coerência em tarefas longas. Consequentemente, a pilha de treinamento muda: navegadores, terminais, busca, sandboxes de execução, sistemas de memória, servidores de ferramentas e frameworks de orquestração começam a entrar no sistema de treinamento.
Mais precisamente, um harness é um programa de controle envolvido em torno do modelo. Esse conceito não pertence apenas ao runtime do Agent; ele existe também na fase de treinamento: determinando qual entrada o modelo vê, como ele recebe feedback, quando podar contexto e quando chamar ferramentas. Construção de prompt, atualização de memória, política de recuperação, edição de contexto e orquestração de ferramentas estão todos aqui. O ambiente não é mais apenas um validador estático, mas uma camada que tanto o treinamento quanto a implantação devem enfrentar diretamente.
O harness deve ser estável para que o treinamento do modelo seja significativo. Se os valores de retorno das ferramentas forem instáveis, o ambiente do navegador for inconsistente com o ambiente online, ou o estado do sistema de arquivos for irreproduzível, o avaliador falhará primeiro, e o modelo subsequentemente aprenderá a explorar brechas do ambiente em vez de ganhar capacidade. Ao treinar Agents, você geralmente está depurando tanto o modelo quanto o ambiente.
As abordagens das três empresas são claras: Kimi usa PARL para resolver decomposição paralela e atribuição de crédito; Cursor usa auto-resumo e RL em tempo real para reconectar sessões de codificação de longo prazo e tráfego de produção de volta ao treinamento; Chroma treina prune_chunks como uma estratégia em si, permitindo que a poda de contexto entre diretamente no processo de recuperação.
Na era SFT, a diversidade de dados era primordial; na era do Agent, a qualidade do ambiente é central: estabilidade, autenticidade, cobertura, distribuição de dificuldade, riqueza de feedback e antiexploração. Os objetivos de treinamento mudam correspondentemente, exigindo confiabilidade em tarefas completas, não apenas acertar uma pergunta. Benchmarks clássicos de CoT não conseguem cobrir isso.
Essa mudança continua avançando: não apenas treinar o modelo dentro de um harness de runtime, mas até mesmo o código do harness em si está se tornando um objeto que pode ser pesquisado e otimizado por um loop externo.
O PARL do Kimi K2.5 é um caso de engenharia notável com uma rota clara: treinar apenas o orquestrador, convergir a atribuição de crédito para a camada de orquestração, e não otimizar todos os sub-agentes simultaneamente.
Os sinais de recompensa são divididos em três categorias: sucesso da tarefa, decomposição paralela e restrições de conclusão, que juntos impulsionam a camada de orquestração. No início do treinamento, o peso r_parallel é aumentado para incentivar a exploração de estratégias paralelas, sendo gradualmente reduzido para 0 depois para evitar que abrir vários sub-agentes seja tratado como um atalho. A avaliação olha não apenas para o total de etapas, mas também para o comprimento do caminho crítico; um caminho crítico mais curto indica que o paralelismo é realmente eficaz.
Mas em 2026, as coisas avançaram um passo adiante. Meta-Harness trata explicitamente a engenharia de harness como um alvo de otimização separado. Ele não otimiza pesos, mas o próprio código do harness—os programas de construção de prompt, recuperação, memória e atualização de estado ao redor de um modelo fixo. Os números no início do artigo são diretos: para o mesmo modelo base, apenas mudar o harness pode resultar em uma diferença de desempenho de 6x no mesmo benchmark. Esse conjunto de programas fora do modelo não é mais apenas um detalhe de implantação, mas uma camada de formação de capacidade.
A chave não é adicionar outro otimizador abstrato, mas escrever código anterior, pontuações e traços de execução (logs de chamadas de ferramentas e mudanças de estado) no sistema de arquivos, permitindo que um propositor use grep, cat e diff como ao escrever código, e então modifique o harness ao longo dos caminhos de falha. O propositor é o módulo que sugere modificações no harness.
Os autores julgam claramente que muitos otimizadores de texto passados não eram eficazes para programas de longo prazo e com estado como harnesses, porque olhar apenas para pontuações escalares, templates curtos ou resumos achata o problema. Pontuações escalares fornecem apenas pontos finais sem informação de processo. Erros de harness frequentemente se manifestam muitas etapas depois; uma vez que o feedback é supercomprimido, a cadeia de diagnóstico se quebra.
Esses resultados são mais do que apenas pontuações de benchmark mais altas. Na classificação de texto online, Meta-Harness é 7,7 pontos maior que ACE (baseline de engenharia de contexto de agente) enquanto comprime o uso de tokens de contexto para 1/4. Em raciocínio matemático aumentado por recuperação, um harness descoberto melhorou 5 modelos retidos (não envolvidos na otimização) em uma média de 4,7 pontos em 200 problemas de nível IMO. No TerminalBench-2, também excedeu baselines de engenharia manual. Isso mostra que o que está sendo otimizado não são mais apenas estratégias internas do modelo, mas também os programas que organizam informações e ações ao redor do modelo.
Um exemplo específico: Meta-Harness descobriu automaticamente o bootstrap de ambiente no TerminalBench-2—executando um comando shell antes do loop do agente começar para organizar o diretório de trabalho, linguagens disponíveis, gerenciadores de pacotes e estado de memória em um snapshot injetado no primeiro prompt. Muitos agentes de codificação gastam as primeiras rodadas explorando o ambiente; com esse pré-processamento feito, a melhoria não vem necessariamente de pesos mais fortes, mas do harness permitindo que o modelo comece com um contexto melhor.
Neste ponto, o objetivo da otimização se expandiu de respostas para trajetórias, e depois para o programa harness que carrega essas trajetórias.
Após o Lançamento de um Modelo Líder, a Cadeia de Treinamento Continua
Entender os grandes modelos de hoje apenas pela lente de uma única rodada de pré-treinamento não é mais suficiente. Por trás de um modelo lançado, toda a cadeia de pré-treinamento, pós-treinamento, destilação e especialização geralmente foi concluída, e modelos mais fortes continuam a produzir dados de treinamento para a próxima geração.
A destilação da série DeepSeek-R1 é um exemplo típico. Um modelo grande primeiro desenvolve capacidades de raciocínio através de RL e recompensas verificadas, e então transfere essas trajetórias de raciocínio para modelos densos menores. Modelos especializados como TranslateGemma mostram outra rota: em tarefas alvo mais específicas, usando dados de alta qualidade e designs de recompensa especializados para comprimir e direcionar ainda mais as capacidades. Neste estágio, modelos mais fortes não são apenas para servir usuários, mas também para produzir diretamente dados de treinamento para a próxima geração.
A razão por trás disso é mais fundamental do que a transferência de trajetória: uma explicação possível é que em corpora da internet, memória de conhecimento e capacidade de raciocínio estão acopladas, e os objetivos existentes de pré-treinamento exigem que os modelos aprendam ambos bem. Modelos grandes devem vir primeiro porque apenas eles são grandes o suficiente para suportar ambos, e então podem ser usados para gerar dados de demonstração de raciocínio puro. Quando modelos pequenos treinam nesses dados, eles podem focar no raciocínio em si sem serem forçados a lembrar todo o conhecimento. Começar grande e depois ir pequeno é sobre desacoplamento de capacidade, não apenas uma estratégia de custo.
Por outro lado, a adaptabilidade de implantação é tão importante quanto a própria capacidade. Muitos cenários não precisam de um modelo grande para todos os fins; eles se importam mais com custo, latência, estabilidade e controlabilidade. O final do treinamento não é necessariamente maior, mas potencialmente menor, mais barato e mais especializado.
O modelo finalmente lançado não é necessariamente o checkpoint mais à direita da curva de treinamento. Antes do lançamento real, múltiplos checkpoints são frequentemente comparados repetidamente por resultados de tarefas reais, estilos de recusa, estabilidade de ferramentas, custo e riscos de regressão. A versão que vai ao ar é frequentemente uma decisão de produto, não a que tem o melhor desempenho em uma única métrica.
Quando os usuários veem um nome de modelo, eles assumem que corresponde a uma curva de treinamento suavemente ascendente, mas qual checkpoint é realmente colocado online é outra questão.
O valor de um modelo grande reside tanto em sua própria capacidade de serviço quanto em seu fornecimento contínuo de dados de treinamento, fontes de destilação e bases de lançamento para a próxima geração.
Além do treinamento offline, a otimização contínua quase online entrou no processo principal. O RL em tempo real do Cursor Composer 2 mostra que algumas capacidades de Agent começaram a iterar continuamente através do tráfego de produção, em vez de esperar pela próxima rodada de treinamento offline em larga escala. A fronteira entre treinamento e implantação não desapareceu, mas o loop de feedback entre eles está encurtando.
Como Julgar por que um Modelo se Tornou Mais Forte no Futuro
O valor dos modelos líderes em 2026 depende cada vez mais de quem consegue completar toda a cadeia de treinamento após o pré-treinamento: produzir continuamente dados de treinamento, fazer destilação, fazer especialização, fazer bem a avaliação e recompensas, e fazer as escolhas finais de lançamento.
Por causa disso, ao observar por que um modelo repentinamente se torna mais forte, você pode olhar para três coisas primeiro:
- Primeiro, veja se a mudança ocorreu na camada de pré-treinamento ou no processo de treinamento subsequente. Muitas melhorias de capacidade realmente vêm de pré-treinamento mais forte e melhores receitas de dados, mas muitas mudanças percebidas na verdade vêm do pós-treinamento. Se um modelo segue instruções, usa ferramentas ou tem um estilo de resposta estável, muitas vezes não cresce naturalmente apenas treinando em mais corpora.
- Em seguida, veja de qual camada vem a melhoria: são pesos e receitas de treinamento, ou recompensa/avaliação/avaliador, ou código harness e loop de implantação. Quando chegamos a modelos de raciocínio e Agents, a força que os usuários sentem muitas vezes não é resultado apenas do modelo base. Como as avaliações são configuradas, como as recompensas são pontuadas, se o ambiente de ferramentas é estável, como a recuperação e a memória são organizadas, como os resumos e o contexto são podados, e qual checkpoint foi escolhido para lançamento—tudo isso junto muda o desempenho final do produto.
- Finalmente, veja o que a versão online está otimizando. Algumas versões buscam um teto mais alto, algumas buscam menor custo, latência e risco de regressão, e algumas são especializadas para um certo tipo de cenário. A versão de lançamento é uma decisão de produto, não o ponto mais à direita da curva de treinamento. Então, ao observar atualizações de modelo, olhar para o que ele está realmente otimizando estará mais próximo da verdade.
Decompondo a melhoria repentina de um modelo em estágios de produção, muitos ganhos são na verdade amplificados pela segunda metade da pilha de treinamento e pelo harness externo. O ciclo de iteração dessa cadeia também está encurtando: o tráfego de produção flui continuamente de volta para o treinamento, cada geração de modelos mais fortes produz dados de supervisão de próxima geração enquanto produz capacidades, e programas externos são constantemente reescritos com base em rollouts, logs e feedback de tarefas reais.
O modelo lançado hoje é apenas um snapshot; o pipeline e o programa harness são os produtos que continuam rodando.
Materiais de Aprendizado
- Hoffmann et al. (2022). Treinamento de Modelos de Linguagem Grandes com Cálculo Ótimo (Chinchilla). arXiv:2203.15556
- Ouyang et al. (2022). Treinamento de modelos de linguagem para seguir instruções com feedback humano (InstructGPT). arXiv:2203.02155
- Shao et al. (2024). DeepSeekMath: Expandindo os Limites do Raciocínio Matemático em Modelos de Linguagem Abertos (GRPO). arXiv:2402.03300
- DeepSeek-AI (2025). DeepSeek-R1: Incentivando a Capacidade de Raciocínio em LLMs via Aprendizado por Reforço. arXiv:2501.12948
- DeepSeek-AI (2024). Relatório Técnico do DeepSeek-V3. arXiv:2412.19437
- Llama Team, AI @ Meta (2024). O Rebanho de Modelos Llama 3. arXiv:2407.21783
- Bai et al. (2022). IA Constitucional: Inofensividade a partir de Feedback de IA. arXiv:2212.08073
- OpenAI (2024). Alinhamento Deliberativo: Raciocínio Permite Modelos de Linguagem Mais Seguros. openai.com/index/deliberative-alignment
- Anthropic (2025). De Bajulação a Subterfúgio: Investigando Manipulação de Recompensas em Modelos de Linguagem. anthropic.com/research/reward-tampering
- MacDiarmid et al. (2025). Desalinhamento Emergente Natural a partir de Hackeamento de Recompensa em RL de Produção. arXiv:2511.18397
- Lee et al. (2026). Meta-Harness: Otimização Ponta a Ponta de Harnesses de Modelo (página do projeto preprint). yoonholee.com/meta-harness
- Kimi Team (2026). Blog Técnico do Kimi K2.5: Inteligência Agentiva Visual. kimi.com/blog/kimi-k2-5
- Rush, S. (2026). Um relatório técnico sobre o Composer 2. cursor.com/blog/composer-2-technical-report
- Chroma (2026). Chroma Context-1: Treinando um Agente de Busca Autoeeditor. trychroma.com/research/context-1
Este artigo não autoriza nenhuma forma de reprodução ou reescrita para republicação. Se você encontrar alguma, por favor, me ajude a denunciá-la.
