LLMs

Visão geral: o que são “LLMs”

Modelos de Linguagem de Grande Porte (Large Language Models, LLMs) são modelos de aprendizado de máquina (machine learning) que geram e interpretam linguagem humana (e, com frequência, código) ao aprender padrões estatísticos a partir de corpora de texto massivos. A maioria dos LLMs modernos são redes neurais (neural networks) — especificamente modelos baseados em Transformers (Transformer-based) — que operam com tokens (tokens) (pedaços de texto) e são treinados para prever o que vem a seguir em uma sequência.

Em alto nível, um LLM aprende uma distribuição de probabilidade condicional (conditional probability distribution):

  • Dado um prefixo (contexto) x1, x2, …, xt, estimar a probabilidade do próximo token xt+1.
  • A geração é então realizada por amostragem ou seleção repetida do próximo token até que o modelo decida parar.

Esse objetivo de treinamento, enganosamente simples — previsão do próximo token (next-token prediction) — pode produzir capacidades surpreendentemente amplas: tradução, sumarização, perguntas e respostas, assistência à programação e até algumas formas de raciocínio.

LLMs se inserem na família mais ampla de Modelagem Generativa (Generative Modeling): modelos que aprendem a produzir novas amostras que se assemelham à distribuição de treinamento.

Principais blocos de construção

Tokens e tokenização (tokenization)

LLMs não “enxergam” caracteres ou palavras brutas diretamente. Eles operam sobre tokens produzidos por um tokenizador (tokenizer) (com frequência, Codificação por Pares de Bytes (Byte Pair Encoding) ou esquemas semelhantes de subpalavras). A tokenização afeta:

  • Custo e latência (mais tokens → mais computação)
  • Desempenho multilíngue
  • Tratamento de espaços em branco, pontuação e palavras raras
  • Quão bem código e dados estruturados são representados

Para um olhar mais profundo, veja Tokenização (Tokenization).

Implicação prática: uma frase “curta” em inglês e uma frase “curta” em outro idioma podem ter contagens de tokens muito diferentes, alterando tanto o custo quanto o comportamento do modelo.

Arquitetura Transformer em um parágrafo

A maioria dos LLMs é baseada na Arquitetura Transformer (Transformer Architecture). A ideia central é a autoatenção (self-attention), que permite ao modelo ponderar relações entre todos os tokens no contexto. Durante a inferência (inference), o modelo:

  1. Incorpora (embeds) tokens em vetores
  2. Aplica múltiplas camadas de atenção + transformações de alimentação direta (feed-forward)
  3. Produz logits (logits), isto é, pontuações, sobre o vocabulário para o próximo token

Transformers escalam bem com dados e computação, o que é um dos principais motivos pelos quais LLMs se tornaram dominantes.

Janelas de contexto (context windows)

Um LLM só consegue “prestar atenção” a um número fixo de tokens de cada vez: sua janela de contexto (context window). Se uma informação fica fora dessa janela, ela se torna efetivamente invisível, a menos que seja reintroduzida (por exemplo, via recuperação).

Janelas de contexto mais longas permitem melhores tarefas em nível de documento, mas introduzem trade-offs de custo, latência e, às vezes, confiabilidade. Veja Janelas de Contexto (Context Windows).

Decodificação (decoding): transformando probabilidades em texto

Depois que o modelo produz probabilidades para o próximo token, ainda é necessária uma estratégia de decodificação:

  • Decodificação gulosa (greedy decoding): sempre escolher o token de maior probabilidade
  • Amostragem (sampling) (temperatura (temperature)): adiciona aleatoriedade
  • Top-k / Top-p (núcleo (nucleus)): restringe a amostragem a um subconjunto de tokens prováveis
  • Busca em feixe (beam search) (mais comum em configurações mais antigas de sequência-para-sequência (seq2seq))

A decodificação influencia fortemente criatividade, repetitividade, factualidade e segurança. Veja Estratégias de Decodificação (Decoding Strategies).

Etapas de treinamento: de “modelo base” a “assistente”

LLMs raramente são treinados em uma única etapa. Um pipeline moderno comum tem múltiplas etapas, cada uma moldando o comportamento de formas diferentes.

Estágio 1: pré-treinamento (pretraining) (modelo fundamental (foundation model))

Pré-treinamento geralmente significa treinar em texto em grande escala (e às vezes código) com o objetivo de previsão do próximo token.

Uma perda (loss) simplificada para uma sequência é a entropia cruzada (cross-entropy):

L = - Σ_t log pθ(xt | x< t)

Propriedades-chave do pré-treinamento:

  • Aprende gramática, estilo, padrões de conhecimento de mundo e regularidades estatísticas
  • Produz um modelo base (base model): muitas vezes poderoso, mas nem sempre confiavelmente útil ou seguro
  • O desempenho segue Leis de Pré-Treinamento e Escalonamento (Pretraining & Scaling Laws): modelos maiores + mais dados + mais computação geralmente melhoram os resultados, até certos limites

Os dados de pré-treinamento importam enormemente. Eles influenciam:

  • Cobertura de domínios (medicina, direito, programação)
  • Vieses e estereótipos
  • Recência (modelos podem ficar defasados em relação a eventos atuais)
  • Propensão a memorizar strings raras (risco de privacidade)

Estágio 1.5: pré-treinamento contínuo (continued pretraining) (adaptação ao domínio (domain adaptation))

Organizações frequentemente executam pré-treinamento contínuo em corpora específicos de domínio (por exemplo, texto jurídico, artigos biomédicos, documentação interna). Isso mantém o mesmo objetivo (previsão do próximo token), mas altera a distribuição.

Benefícios:

  • Melhora fluência e terminologia no domínio
    Riscos:
  • Pode degradar a capacidade geral se for levado longe demais
  • Pode amplificar vieses ou erros específicos do domínio

Estágio 2: ajuste fino supervisionado (supervised fine-tuning, SFT) para seguimento de instruções (instruction following)

Modelos base não são, por natureza, assistentes cooperativos. Ajuste fino supervisionado treina o modelo em pares curados de instrução–resposta:

  • Usuário pede: “Resuma isto”
  • Assistente responde com um exemplo de um bom resumo

Essa etapa está fortemente associada ao surgimento de um comportamento “conversador” e prestativo e é central para Seguimento de Instruções (Instruction Following).

Exemplo prático de um datapoint de ajuste por instruções (instruction-tuning):

{
  "instruction": "Explain the difference between precision and recall in one paragraph.",
  "response": "Precision measures how many selected items are relevant, while recall measures how many relevant items are selected..."
}

Estágio 3: otimização por preferências (preference optimization) e alinhamento (alignment) (RLHF, DPO, …)

Mesmo após SFT, modelos podem:

  • Ser verbosos quando não deveriam
  • Recusar incorretamente (ou não recusar quando deveriam)
  • Dar respostas plausíveis, mas erradas
  • Responder de formas inseguras

Para lidar com isso, muitos sistemas usam otimização baseada em preferências:

  • Humanos (ou modelos) comparam duas respostas candidatas e escolhem a melhor.
  • O modelo é treinado para aumentar a probabilidade de saídas preferidas.

Famílias comuns:

  • RLHF (Aprendizado por Reforço a partir de Feedback Humano (Reinforcement Learning from Human Feedback)): treina um modelo de recompensa, depois otimiza a política via aprendizado por reforço.
  • DPO / IPO / ORPO / KTO e métodos relacionados: otimizam preferências de forma mais direta e muitas vezes mais simples.

Veja Alinhamento (Alignment) e Métodos de Otimização por Preferências (Preference Optimization Methods).

O alinhamento melhora usabilidade e segurança, mas introduz trade-offs:

  • Recusa excessiva ou excesso de cautela
  • Menor disposição para especular (às vezes bom, às vezes não)
  • Sensibilidade à forma como o prompt é redigido

Estágio 4: mitigações de segurança (safety mitigations) e camadas de política (policy layers)

Além do treinamento, muitos sistemas de LLM em produção adicionam mitigações de segurança em camadas, como:

  • Filtros de conteúdo e classificadores
  • Prompts de sistema (system prompts) com restrições comportamentais
  • Políticas de recusa (refusal policies)
  • Controle de acesso a ferramentas (tool gating) (restringir quais ações um agente que usa ferramentas pode executar)

Veja Mitigações de Segurança (Safety Mitigations).

Estágio 5: ajuste fino (fine-tuning) específico de tarefa ou organização (opcional)

Quando você precisa de comportamento consistente para uma tarefa específica, pode ajustar ainda mais usando:

  • Ajuste fino completo (full fine-tuning) (atualiza todos os pesos)
  • Métodos eficientes em parâmetros (parameter-efficient methods) como LoRA (Adaptação de Baixa Ordem (Low-Rank Adaptation))
  • Pequenos adaptadores (adapters) ou roteamento (routing)

Isso é coberto em Ajuste Fino (Fine-Tuning) e no framework de decisão mais amplo no Playbook de Ajuste Fino (Fine-Tuning Playbook).

Abordagem complementar: recuperação (retrieval) e uso de ferramentas (tool use) (frequentemente melhor do que ajuste fino)

Muitos problemas de “conhecimento” são melhor resolvidos ao dar ao modelo acesso a informações externas:

  • RAG (Geração Aumentada por Recuperação (Retrieval-Augmented Generation)): recupera documentos relevantes e, em seguida, faz o prompt do LLM com eles.
  • Uso de ferramentas / chamada de função (function calling): permite que o modelo chame APIs (busca, calculadoras, bancos de dados).

Veja Recuperação e Ferramentas (Retrieval & Tooling) e LLMs que Usam Ferramentas (Tool-Using LLMs).

Capacidades: o que LLMs conseguem fazer bem

A capacidade de um LLM é melhor entendida como um espectro. Eles não são raciocinadores perfeitos, mas são aprendizes de padrões extremamente flexíveis.

Geração e transformação de linguagem natural

Casos de uso comuns e de alta qualidade:

  • Sumarização (e-mails, relatórios, notas de reunião)
  • Reescrita (mudança de tom, melhorias de clareza)
  • Tradução (especialmente idiomas com muitos recursos)
  • Extração para formatos estruturados (JSON, tabelas — embora a confiabilidade varie)

Exemplo: extraindo dados estruturados

Prompt:
Extract the following into JSON with keys: customer_name, order_id, items.

Text:
"Hi, I'm Priya. My order #A-1042 had 2 items: a blue mug and a tea infuser."

Um modelo forte produzirá algo como:

{
  "customer_name": "Priya",
  "order_id": "A-1042",
  "items": ["blue mug", "tea infuser"]
}

Aprendizado no contexto (in-context learning) (comportamento few-shot sem atualizações de pesos)

LLMs conseguem aprender padrões a partir de exemplos no prompt — sem necessidade de atualizações de gradiente. Isso é chamado de Aprendizado no Contexto (In-Context Learning).

Exemplo: classificação com poucos exemplos (few-shot)

Classify sentiment as Positive, Negative, or Neutral.

Text: "The shipping was fast and the quality is great." -> Positive
Text: "It works, but the battery life is average." -> Neutral
Text: "Arrived broken and support never replied." -> Negative

Text: "Setup was easy and it feels well-made." ->

Geração e edição de código

LLMs podem:

  • Escrever funções a partir de especificações
  • Explicar código
  • Gerar testes
  • Refatorar
  • Ajudar na depuração (com ressalvas)

O comportamento especializado em código é discutido em Modelos de Código (Code Models).

Nota prática: saídas de código devem ser validadas com testes, linters e execução em sandbox. LLMs podem produzir código sintaticamente válido, mas semanticamente incorreto.

Raciocínio e resolução de problemas em múltiplas etapas (imperfeito, mas melhorável)

LLMs conseguem resolver muitas tarefas “semelhantes a raciocínio”, mas a confiabilidade varia com:

  • Dificuldade da tarefa
  • Método de prompting
  • Ferramentas disponíveis (calculadora, busca)
  • Cômputo em tempo de teste (test-time compute) (mais tempo de “pensar” pode ajudar)

Técnicas incluem rascunhos (scratchpads), autoconsistência (self-consistency) e prompting com busca em árvore (tree search prompting); veja Técnicas de Cadeia de Pensamento e Raciocínio (Chain-of-Thought & Reasoning Techniques) e Cômputo em Tempo de Teste (Test-Time Compute).

Nuance importante: LLMs podem produzir explicações convincentes mesmo quando a resposta está errada. Trate cadeia de pensamento como uma ferramenta para elicitar raciocínio, não como prova de correção.

Uso de ferramentas e fluxos de trabalho agentivos (agentic workflows)

Com acesso a ferramentas, um LLM pode:

  • Consultar um banco de dados
  • Chamar uma API de busca
  • Executar cálculos
  • Executar fluxos de trabalho (criar tickets, agendar reuniões)

Uma interação mínima no estilo “chamada de função” pode parecer com:

{
  "role": "user",
  "content": "What's the total cost if I buy 14 units at $3.75 each, plus 8% tax?"
}

Um sistema com uso de ferramentas pode fazer o modelo chamar uma calculadora e, em seguida, retornar uma resposta ancorada. Isso pode reduzir drasticamente erros aritméticos.

Extensões multimodais

Muitos sistemas modernos vão além do texto para imagens e áudio, permitindo tarefas como compreensão de documentos e geração de legendas. Conceitualmente, isso expande as “modalidades” de entrada/saída do modelo, em vez de mudar a ideia central de modelagem de sequências. Veja Modalidades (Modalities).

Aplicações práticas em sistemas reais

LLMs normalmente são implantados como componentes em produtos maiores, em vez de chatbots isolados:

  • Suporte ao cliente: redigir respostas, sumarizar tickets, sugerir próximas ações
  • Busca corporativa e assistentes de conhecimento: responder perguntas sobre documentos internos via RAG
  • Engenharia de software: geração de código, assistência em revisão, ajuda em migrações
  • Copilotos de analytics: converter linguagem natural em SQL e explicar resultados (exige sandboxing cuidadoso)
  • Fluxos de conteúdo: ideação, esboços, transformação de estilo (com supervisão editorial humana)
  • Educação: tutoria, questões de prática, feedback — exige salvaguardas fortes para evitar desinformação

Um padrão comum de arquitetura:

  1. Consulta do usuário
  2. Recuperação (top documentos relevantes)
  3. LLM gera resposta com citações
  4. Pós-processamento: checagens de segurança, formatação, logging, ganchos de avaliação

Esse padrão costuma ser mais robusto do que depender apenas de memória paramétrica.

Limitações e modos de falha

Apesar do desempenho impressionante, LLMs têm limitações fundamentais e práticas.

Alucinações (hallucinations) (factualidade não confiável)

LLMs podem gerar informações que são:

  • Incorretas
  • Fabricadas (citações falsas, comportamentos de API falsos)
  • Afirmadas com confiança excessiva

Isso não é um “bug” raro — é uma consequência natural de treinar em previsão do próximo token em vez de validação explícita de verdade.

Mitigações incluem:

  • Ancoragem por recuperação (retrieval grounding) (RAG)
  • Uso de ferramentas (busca, consultas a bancos de dados)
  • Calibração de “não sei” e políticas de recusa
  • Etapas de verificação (por exemplo, pedir que o modelo cite fontes e então validar)

Veja Alucinações (Hallucinations).

Limites de contexto e sobrecarga de informação

Mesmo com janelas de contexto longas:

  • Detalhes importantes podem ser perdidos (comportamentos de “lost in the middle”)
  • Prompts muito longos podem degradar o desempenho
  • Custos escalam com o comprimento da entrada

Implicação de design: bons pipelines de recuperação, chunking e sumarização frequentemente superam simplesmente “empurrar” mais texto para dentro do prompt.

Fragilidade a prompts e conflitos de instruções

As saídas de LLMs podem mudar significativamente com pequenas edições no prompt. Eles também podem ter dificuldade quando instruções entram em conflito (por exemplo, “seja breve” e “forneça justificativa detalhada”).

Por isso, sistemas em produção dependem de:

  • Prompts de sistema estáveis
  • Templates (templates)
  • Testes automatizados de regressão de prompts
  • Formatos de saída restritos (constrained output formats)

Veja Engenharia de Prompts (Prompting).

Vieses, toxicidade e danos representacionais (representational harms)

Como os dados de treinamento refletem a sociedade e a internet, LLMs podem reproduzir:

  • Estereótipos
  • Linguagem discriminatória
  • Desempenho desigual entre dialetos ou idiomas

O alinhamento reduz, mas não elimina, esses problemas. São necessárias avaliação rigorosa e boas práticas de datasets, especialmente em domínios de alto impacto.

Riscos de privacidade e memorização

LLMs às vezes podem memorizar sequências raras (por exemplo, partes de documentos, segredos embutidos nos dados de treinamento). Os riscos incluem:

  • Vazamento de dados sensíveis do treinamento
  • Vazamento de prompts privados de usuários (se logs forem mal geridos)
  • Injeção de contexto via prompt em tempo de inferência que exfiltra contexto oculto

Mitigações:

  • Governança e filtragem de dados
  • Políticas de retenção mínima
  • Red teaming (red teaming) para vazamento
  • Injeção de contexto e permissões de ferramentas cuidadosamente delimitadas

Segurança: injeção de prompt (prompt injection) e uso indevido de ferramentas

Quando LLMs são conectados a ferramentas, o modelo de ameaça (threat model) muda. Atacantes podem:

  • Esconder instruções maliciosas em documentos recuperados (“injeção indireta de prompt (indirect prompt injection)”)
  • Enganar o modelo para chamar ferramentas com parâmetros inseguros
  • Exfiltrar contexto sensível via saídas de ferramentas

Sistemas robustos com uso de ferramentas exigem:

  • Esquemas estritos e validação
  • Permissões de ferramentas sob o princípio do menor privilégio (least privilege)
  • Checagens de política separadas fora do modelo

Veja LLMs que Usam Ferramentas (Tool-Using LLMs).

Raciocínio não é garantido (e “explicações” podem ser performáticas)

LLMs frequentemente resolvem problemas por casamento de padrões (pattern matching) em vez de raciocínio formal. Eles podem:

  • Cometer erros lógicos sutis
  • Falhar em problemas construídos de forma adversarial
  • Produzir provas plausíveis, porém incorretas

Para raciocínio de alto impacto, use:

  • Solvers externos (SAT/SMT, provadores de teoremas (theorem provers))
  • Ferramentas de computação verificada (verified computation tools)
  • Testes unitários e execução para código
  • Estratégias de múltiplas amostras (multiple-sample strategies) e heurísticas de verificação

Avaliação é difícil e pode ser manipulada

Benchmarks (benchmarks) padrão podem não refletir desempenho no mundo real. Modelos também podem sobreajustar (overfit) a conjuntos de teste populares (direta ou indiretamente).

Programas fortes de avaliação incluem:

  • Suites de testes offline (offline test suites) específicas da tarefa
  • Revisão humana para tarefas com nuances
  • Monitoramento contínuo (continuous monitoring) em produção
  • Testes adversariais (adversarial testing) (“red teaming”)

Ecossistemas abertos vs fechados (trade-offs práticos)

Escolher entre modelos de pesos abertos (open-weight models) e modelos proprietários via API (API-based proprietary models) envolve trade-offs em:

  • Custo e escalabilidade
  • Customização (ajuste fino, restrições de implantação)
  • Privacidade e conformidade
  • Latência e disponibilidade
  • Controles de segurança e governança

Veja Modelos Abertos vs Fechados (Open vs Closed Models).

Boas práticas: usando LLMs de forma eficaz

  1. Comece com prompting e recuperação antes de ajuste fino
    Muitos problemas são problemas de “conhecimento e contexto”, não problemas de “pesos”. Use o Playbook de Ajuste Fino (Fine-Tuning Playbook) para escolher uma abordagem.

  2. Ancore o modelo quando correção for importante
    Use RAG, citações, chamadas de ferramenta e etapas explícitas de verificação.

  3. Restrinja saídas para confiabilidade
    Prefira formatos estruturados (schemas JSON), decodificação determinística quando apropriado e pós-validadores.

  4. Projete para falhas
    Adicione fallback: fazer perguntas de esclarecimento, oferecer “não sei”, escalar para humanos ou retornar trechos recuperados em vez de afirmações sintetizadas.

  5. Trate segurança como uma propriedade do sistema
    Use Mitigações de Segurança (Safety Mitigations), controle de acesso, logging e monitoramento de abuso — não dependa apenas do modelo.

Para onde o campo está indo (alto nível)

Tendências atuais de P&D (R&D) incluem:

  • Melhor modelagem de contexto longo e integração com recuperação
  • Agentes que usam ferramentas (tool-using agents) mais confiáveis, com verificação e planejamento
  • Otimização por preferências aprimorada e supervisão escalável (scalable oversight) (Alinhamento (Alignment))
  • Estratégias de inferência em tempo de teste mais fortes (Cômputo em Tempo de Teste (Test-Time Compute))
  • Avaliações mais robustas alinhadas a implantações reais

LLMs são melhor compreendidos não como “bancos de dados de fatos” ou “seres pensantes”, mas como poderosos modelos probabilísticos de sequência que podem ser transformados — por meio de etapas de treinamento e design de sistema — em assistentes úteis e, muitas vezes, altamente capazes.