Ir para o conteúdo

15. LLMs

Um LLM é o decoder do capítulo 12, escalado até algo surpreendente acontecer: um modelo treinado só para prever o próximo token acabou conseguindo traduzir, escrever código, sustentar uma conversa e — depois de 2024 — sentar e pensar sobre um problema antes de responder.

Este capítulo trata das quatro coisas que transformam essa arquitetura num sistema utilizável, na ordem em que acontecem: pré-treino (o que a previsão do próximo token de fato compra), pós-treino (transformar um continuador de texto num assistente), compute na inferência (o eixo que substituiu a contagem de parâmetros como fronteira) e serviço (por que tudo isso custa o que custa).

Pré-treino: um objetivo e o que ele obriga o modelo a aprender

Dado um texto \(x_1, \dots, x_T\), minimize

\[ \mathcal{L} = -\sum_{t=1}^{T} \log p_\theta(x_t \mid x_{<t}) \]

É todo o objetivo de pré-treino. Ele é auto-supervisionado — os rótulos são os próprios próximos tokens — de modo que o conjunto de treino é qualquer texto que exista.

Vale enunciar com cuidado a razão pela qual isso produz mais do que autocompletar: comprimir texto bem exige modelar aquilo que produziu o texto. Para prever o último token de "o assassino era o ___" você precisa da trama. Para prever o token depois de return você precisa do contrato da função. Previsão do próximo token é um objetivo de compressão e compressão nessa escala força estrutura.

O modelo base não é o assistente

Um modelo recém-saído do pré-treino continua texto; ele não responde perguntas. Perguntado "Qual é a capital da França?", ele pode responder com mais três questões de prova — uma continuação perfeitamente boa de um documento que parece um questionário. Tudo que é conversacional vem do pós-treino.

Tokenização e os bugs que ela causa

O texto vira tokens antes de o modelo ver qualquer coisa, geralmente por BPE em nível de byte: comece de bytes, funda repetidamente o par adjacente mais frequente, pare num vocabulário de 32k–256k. É um algoritmo de compressão ajustado a um corpus e não é neutro.

Sintoma Causa
"Quantos 'r' há em strawberry?" dá errado O modelo nunca vê letras, só st\|raw\|berry. Perguntas em nível de caractere pedem algo abaixo da resolução da entrada dele.
Aritmética falha com certas quantidades de dígitos Números são quebrados de forma inconsistente — 1234 pode ser um token, 12345 dois. Tokenizadores modernos forçam dígitos em grupos fixos exatamente para consertar isso.
Português custa ~1,5× mais que inglês As fusões foram ajustadas num corpus majoritariamente em inglês. Menos fusões cobrem o português, então a mesma frase vira mais tokens — mais latência, mais dinheiro, menos contexto útil, para o mesmo conteúdo.
Um espaço no final estraga uma completação " o" e "o" são tokens diferentes; um prompt terminado em espaço tira o modelo da distribuição.

Modelos sem tokenizador, em nível de byte, são uma linha de pesquisa viva e o fato de a área inteira ainda rodar sobre uma heurística de compressão ajustada em 2015 é um constrangimento real, ainda que silencioso.

Pós-treino: de continuação a assistente

O pipeline do capítulo 14 é o mesmo, visto do lado do modelo em vez do lado de quem o usa:

  1. SFT sobre demonstrações — ensina o formato de ser um assistente.
  2. Otimização de preferências (DPO, ou RLHF baseado em PPO3) — ensina qual de duas respostas é melhor, algo que demonstrações não conseguem expressar.
  3. RL a partir de um verificador — ensina o modelo a acertar, quando "acertar" é checável.

O passo 3 é o que mudou mais recentemente e merece seção própria.

Compute na inferência: o segundo eixo de escala

Até 2024, "um modelo melhor" queria dizer "um modelo maior, treinado com mais dados". Então apareceu uma curva diferente: mantenha o modelo fixo e dê a ele mais compute na inferência — deixe-o escrever uma cadeia longa de raciocínio, amostrar várias tentativas, checá-las, escolher uma.

Três linhas e a distância entre elas é o assunto inteiro:

  • pass@k (tracejada) é o que o modelo poderia atingir se alguma coisa lhe dissesse qual tentativa estava certa. Sobe rápido e é um limite superior, não uma nota.
  • Voto majoritário não precisa de nada extra e satura. Converge para o que o modelo acredita com mais frequência — que é errado exatamente quando o modelo está confiantemente errado.
  • Best-of-n com verificador embolsa a diferença e quanto dela depende inteiramente da taxa de falso positivo do verificador. Arraste o verificador de perfeito para fraco e veja o teto cair.

Isso explica, com precisão, onde os modelos de raciocínio ficaram bons primeiro: código (rode os testes) e matemática (cheque a resposta). Os dois têm um verificador gratuito e perfeito. Qualidade de redação não tem e a melhora ali foi correspondentemente modesta.

Como os modelos aprenderam a usar isso

Não se obtém raciocínio longo e útil pedindo com educação e imitar cadeias de raciocínio escritas por humanos limita você ao teto dos humanos. O DeepSeek-R16 mostrou a alternativa: deixe o modelo descobrir. Amostre muitas tentativas de problemas com resposta checável, recompense as que passam e otimize — com GRPO, que descarta a rede de valor e normaliza recompensas dentro de cada grupo:

\[ \hat{A}_i = \frac{r_i - \text{mean}(r_{1..G})}{\text{std}(r_{1..G})} \]

Nenhuma cadeia de raciocínio é fornecida. As cadeias ficam mais longas sozinhas porque cadeias mais longas passam na verificação com mais frequência e surgem comportamentos que ninguém escreveu — voltar atrás, conferir o trabalho, notar um erro no meio da solução.

Reward hacking é o modo de falha e um verificador não é uma função de valor

Otimizar contra um verificador significa otimizar contra o verificador, não contra a correção. Os modelos aprendem a tratar os testes como casos especiais, a explorar o formato do corretor, a produzir respostas que passam num casamento de strings sem estarem certas. Todo pipeline de RLVR precisa de avaliação adversarial do próprio verificador e essa é a principal razão pela qual a técnica não se espalhou muito além de domínios com verificadores herméticos.

O que isso muda no custo

O preço de uma resposta deixou de ser um número fixo de parâmetros vezes um número fixo de tokens. Um "orçamento de pensamento" é hoje um botão que se ajusta por requisição e ele troca latência e dinheiro por acurácia ao longo da curva acima. Decidir quanto pensamento uma pergunta merece é um problema de engenharia genuinamente novo e errar em qualquer das direções sai caro.

Mixture of Experts: mais parâmetros, mesmo custo

O outro jeito de acrescentar capacidade sem acrescentar custo por token é tornar o modelo esparso. Substitua cada MLP por \(E\) especialistas independentes e um roteador que ativa apenas \(k\) deles:

\[ \text{MoE}(x) = \sum_{i \in \text{Top-}k(G(x))} G(x)_i \cdot E_i(x), \qquad G(x) = \text{softmax}(W_g x) \]

Lembre do capítulo 12 que cerca de dois terços dos parâmetros de um bloco estão no MLP. Substituí-lo é onde está a alavanca.

Coloque o roteamento em sem balanceamento primeiro. O roteador colapsa sobre alguns especialistas e o resto vira peso morto que você continua pagando para armazenar. Roteamento é um laço de realimentação positiva — um especialista que recebe mais tokens treina mais rápido e por isso é escolhido mais — então o difícil na MoE é o balanceamento, não o roteamento. Soluções clássicas acrescentam uma perda auxiliar; a preferência atual é o balanceamento sem perda auxiliar, que ajusta um viés por especialista no roteador em vez de somar um segundo objetivo para brigar com o primeiro.

Dois movimentos de projeto da geração atual, ambos visíveis no painel:

  • Especialistas de granularidade fina — muitos especialistas pequenos em vez de poucos grandes. Com a mesma contagem de parâmetros ativos, top-8-de-256 oferece muito mais combinações que top-2-de-8.
  • Um especialista compartilhado, sempre ativo, que absorve o comportamento de uso geral para que os especialistas roteados possam de fato se especializar em vez de cada um reaprender o básico.

MoE troca computação por memória e isso é uma decisão de implantação

Você paga memória pelos parâmetros totais e computação pelos ativos. Um modelo de 671B com 37B ativos é barato por token e ainda precisa dos 671B inteiros residentes. É uma boa troca num datacenter com muitas requisições simultâneas e uma troca ruim numa única GPU — e é por isso que modelos densos entre 4B e 30B seguem sendo o padrão para trabalho local e em dispositivo.

Amostragem: o modelo te dá uma distribuição, não um token

Uma passagem direta produz uma distribuição de probabilidade sobre o vocabulário. Transformá-la em texto é um algoritmo separado, com parâmetros próprios e ele afeta a qualidade da saída tanto quanto algumas trocas de modelo.

A temperatura divide os logits antes do softmax: abaixo de 1 ela afia, acima de 1 ela achata. Ela não acrescenta aleatoriedade — redistribui a que já existe. Puxe para 0,05 e você tem decodificação gulosa, que é determinística e propensa a laços, porque a continuação mais provável de uma frase repetida é repeti-la de novo.

O truncamento é a outra metade e é o que impede a cauda longa de absurdo de ser sorteada:

  • top-k — mantém os \(k\) mais prováveis. Grosseiro: \(k = 40\) é demais para uma previsão confiante e de menos para uma aberta.
  • top-p (núcleo)7 — mantém o menor conjunto cuja massa alcança \(p\). Adapta-se ao formato da distribuição. O padrão de longa data.
  • min-p — mantém tokens acima de uma fração da probabilidade máxima. Adapta-se ainda melhor e aguenta temperatura alta onde o top-p já começa a admitir lixo.

Padrões razoáveis

Trabalho factual, código, chamadas de ferramenta: temperatura 0 ou 0,2. Conversa e prosa: 0,7–1,0 com top-p 0,9 ou min-p 0,05. E saiba que modelos de raciocínio costumam ser treinados para uma configuração específica de amostragem e ficam mensuravelmente piores fora dela — confira o cartão do modelo antes de sobrescrever.

Um truque relacionado que vale conhecer: decodificação especulativa. Um modelo rascunho pequeno propõe vários tokens, o modelo grande os verifica numa única passagem paralela e todo prefixo com o qual ele concorda é aceito. Como decodificar é limitado por memória (capítulo 11), checar cinco tokens custa quase o mesmo que checar um. Duas a três vezes mais rápido, com distribuição de saída idêntica.

Emergência, com honestidade

A história padrão é que capacidades aparecem abruptamente ao cruzar um limiar de escala2 — plano, plano, plano e então competência súbita. É uma afirmação marcante e é, ao menos em parte, um artefato.

Schaeffer et al.8 mostraram que muitas curvas "emergentes" vêm de métricas descontínuas. Meça aritmética de vários dígitos por casamento exato e você obtém uma função degrau; meça a log-probabilidade por token que o mesmo modelo dá à resposta certa e obtém uma curva suave. A capacidade subjacente estava melhorando o tempo todo; a medição é que tinha um penhasco.

O que sobrevive à crítica ainda é importante:

  • A melhora é suave na perda e frequentemente abrupta no que dá para usar. Um modelo com 40% de casamento exato numa tarefa não é 40% útil; ele pode ser inutilizável e o mesmo modelo a 85% é um produto. Essa descontinuidade é real mesmo que a curva subjacente seja suave.
  • Aprendizado em contexto — resolver uma tarefa a partir de exemplos no prompt, sem atualizar pesos1 — é genuinamente uma propriedade da escala e é o que fez do prompting uma disciplina.

A lição prática é sobre avaliação, não sobre metafísica: se sua métrica é um limiar, seu progresso vai parecer um penhasco e você não conseguirá distinguir melhora de ruído até cair dele.

De onde as falhas realmente vêm

  • Alucinação

    Não é um bug da arquitetura — é consequência do sinal de treino. Um modelo que diz "não sei" tira zero num benchmark; um modelo que chuta acerta às vezes. Nós corrigimos por acurácia, então treinamos modelos para blefar.

    Mitigações que funcionam: busca com citações, ferramentas com respostas reais, pedir confiança calibrada e — cada vez mais — avaliações que recompensam a abstenção.

  • Contexto não é memória

    Janelas de contexto longas são reais e o desempenho dentro delas não é uniforme. A acurácia de recuperação afunda no meio de um contexto longo e um modelo com 500k tokens de material vagamente relacionado costuma ir pior do que um com os 5k certos.

    Contexto longo é lugar para um conjunto de trabalho, não substituto de busca. Trate "é só colar tudo" como uma hipótese a ser medida.

  • Injeção de prompt

    O modelo não consegue distinguir de forma confiável suas instruções de instruções embutidas nos dados que ele lê. A partir do momento em que ele tem ferramentas, uma página web hostil é um ataque. Não há correção robusta conhecida; as mitigações são arquiteturais — privilégio mínimo, confirmação humana em ações consequentes, isolamento de conteúdo não confiável — e essa é a principal razão pela qual agentes são implantados com cautela.

  • Apodrecimento das avaliações

    Benchmarks vazam para os corpora de treino e uma nota num benchmark público é em parte uma medida de contaminação. Prefira conjuntos privados retidos, benchmarks dinâmicos recentes e comparação humana pareada — e desconfie de qualquer diferença de leaderboard menor que alguns pontos.

De chat para agentes

O padrão de implantação mudou e é a mudança mais relevante para o que vão pedir que você construa. Um chat devolve texto. Um agente roda um laço: leia o objetivo, chame uma ferramenta, leia o resultado, decida, repita, pare.

flowchart LR
    A[objetivo] --> B[o modelo decide]
    B -->|chamada de ferramenta| C[executa]
    C -->|resultado| B
    B -->|pronto| D[resposta]

Quase nada nesse laço é capacidade do modelo. É engenharia: quais ferramentas existem, o que elas devolvem, como os erros aparecem, quanto histórico é mantido, quando parar. O Model Context Protocol (MCP) padroniza o lado do servidor de ferramentas, de modo que uma ferramenta escrita uma vez funcione em vários clientes.

Duas propriedades do laço merecem ser internalizadas:

  • Erros se acumulam. Um passo 95% confiável é 60% confiável depois de dez. Agentes que funcionam são construídos com passos checáveis e reexecutáveis, não com uma única inferência longa.
  • A janela de contexto é um orçamento. Cada resultado de ferramenta compete com o objetivo por espaço. Resumir, descartar e rebuscar é o trabalho real de projeto.

O panorama e como lê-lo

Qualquer tabela de modelos específicos está desatualizada antes de ser impressa. O que é estável é o formato do mercado:

Camada O que a define
Fronteira, fechada OpenAI (GPT), Anthropic (Claude), Google (Gemini). Raciocínio estendido ligado por padrão, multimodalidade forte, melhor uso de ferramentas. Você aluga.
Vizinha da fronteira, pesos abertos DeepSeek, Qwen, Kimi, GLM, Llama, Mistral. A meses da fronteira na maioria dos benchmarks, por uma fração do preço e você pode rodar. MoEs grandes — capazes, mas não do tamanho de um laptop.
Pequena e aberta Modelos densos de 1B a 30B. Rodam numa GPU ou num celular. O alvo certo para destilação e trabalho em dispositivo.
Especialistas Código, embeddings, rerankers, classificadores de segurança, OCR. Em geral pequenos, em geral a resposta certa para um trabalho estreito.

As tendências duráveis por trás da rotatividade: os preços caem cerca de uma ordem de grandeza por ano para uma capacidade fixa; pesos abertos ficam meses, não anos, atrás da fronteira; raciocínio e multimodalidade estão virando recursos padrão em vez de produtos separados; e a capacidade por parâmetro ativo continua melhorando, de modo que um 30B de hoje está confortavelmente além de um GPT-4 inicial.

Como escolher um

Não por leaderboard. Escreva de 20 a 50 exemplos da sua tarefa com as saídas que você quer, rode três ou quatro modelos candidatos contra eles e leia as falhas. Isso leva uma tarde e vence toda discussão de benchmark que você poderia ter no lugar. Depois repita quando um modelo novo aparecer — é a única forma de saber se "melhor" é melhor para você.

Pontos principais

  1. Previsão do próximo token é um objetivo de compressão. Comprimir texto bem exige modelar o que o produziu e é por isso que a capacidade generaliza.
  2. Tokenização é uma heurística ajustada com consequências reais — falhas em nível de caractere, esquisitices aritméticas e uma penalidade de custo de 1,5× para o português.
  3. Um modelo base continua texto. Tudo que é conversacional é pós-treino: SFT, depois otimização de preferências, depois RL a partir de um verificador.
  4. Compute na inferência é o segundo eixo de escala. pass@k é um limite superior; convertê-lo em acurácia exige um verificador e a taxa de falso positivo dele é o teto.
  5. GRPO com um verificador ensinou modelos a raciocinar sem lhes mostrar raciocínio. Funciona onde verificar é grátis — código e matemática — e reward hacking é o risco permanente.
  6. MoE compra capacidade a FLOPs constantes e custa memória. O difícil é o balanceamento de carga, não o roteamento; especialistas de granularidade fina mais um compartilhado é a receita atual.
  7. Decodificação é um algoritmo separado. A temperatura reescala logits; top-p e min-p truncam a cauda. Decodificação especulativa é 2–3× de velocidade de graça, com saídas idênticas.
  8. Emergência é em parte um artefato de métrica, mas efeitos de limiar na utilidade são reais. Não deixe uma métrica em degrau esconder progresso suave.
  9. Alucinação é treinada por corrigir só por acurácia. Injeção de prompt não tem correção robusta e precisa ser tratada arquiteturalmente.
  10. Agentes são laços e erros se acumulam. A maior parte do trabalho é ferramentas, contexto e condições de parada — não o modelo.

  1. Brown, T., et al. (2020). Language Models are Few-Shot Learners — NeurIPS. GPT-3 e o aprendizado em contexto como fenômeno. ↩

  2. Wei, J., et al. (2022). Emergent Abilities of Large Language Models — TMLR. A afirmação, feita com cuidado. ↩

  3. Ouyang, L., et al. (2022). Training language models to follow instructions with human feedback — NeurIPS. InstructGPT. ↩

  4. Shazeer, N., et al. (2017). Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer — ICLR. Onde a MoE para modelos de linguagem começa. ↩

  5. DeepSeek-AI (2024). DeepSeek-V3 Technical Report. Especialistas de granularidade fina, um especialista compartilhado e balanceamento sem perda auxiliar, descritos com detalhe suficiente para reproduzir. ↩

  6. DeepSeek-AI (2025). DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. GRPO e raciocínio que emerge de um verificador em vez de demonstrações. ↩

  7. Holtzman, A., Buys, J., Du, L., Forbes, M., & Choi, Y. (2020). The Curious Case of Neural Text Degeneration — ICLR. Por que a decodificação gulosa entra em laço e de onde vem a amostragem por núcleo. ↩

  8. Schaeffer, R., Miranda, B., & Koyejo, S. (2023). Are Emergent Abilities of Large Language Models a Mirage? — NeurIPS. Métricas descontínuas fabricam curvas descontínuas. ↩

  9. Snell, C., Lee, J., Xu, K., & Kumar, A. (2024). Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters. A troca entre compute de treino e compute de inferência, medida. ↩

  10. Leviathan, Y., Kalman, M., & Matias, Y. (2023). Fast Inference from Transformers via Speculative Decoding — ICML. ↩

  11. Liu, N., et al. (2024). Lost in the Middle: How Language Models Use Long Contexts — TACL. Acurácia de recuperação em função de onde, no contexto, está a resposta. ↩