# Ciência de Dados e Aprendizado de Máquina

> Um livro vivo e evolutivo para aprender fazendo — da coleta do dado ao modelo profundo
>
> v1.0.0 · fonte: https://github.com/GHDaru/machinelearning · site: https://machinelearning.ghdaru.com.br/

---

# 00 — Introdução

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-01 · [histórico](HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Explicar o que distingue Machine Learning de programação convencional, em termos de *onde mora a regra*.
- **O2.** Reconhecer quando um problema é candidato a ML — e quando não é.
- **O3.** Usar as três superfícies deste livro (texto, exercícios, construção) de forma deliberada, e não por acaso.

## O problema: a regra que ninguém consegue escrever

Programar é escrever a regra. Você sabe que um CPF válido tem 11 dígitos e um dígito verificador calculado de certo jeito, então escreve isso, e o computador executa. A regra existe na sua cabeça antes de existir no arquivo.

Agora tente escrever a regra que distingue a foto de um gato da foto de um cachorro. Você reconhece a diferença em vinte milissegundos e não consegue enunciá-la. "Orelha pontuda" falha no gato de orelha caída e no pastor alemão. "Focinho comprido" falha no boxer e no gato siamês. Cada regra que você escreve morre no primeiro contraexemplo, e a lista de exceções cresce mais rápido que a lista de regras.

**Machine Learning é o que se faz quando a regra existe mas ninguém consegue escrevê-la.** Em vez de codificar a regra, você mostra exemplos e deixa que um procedimento de otimização encontre uma regra que os explique — na esperança de que ela também explique exemplos que você ainda não viu.

Essa esperança tem nome: **generalização**. É o assunto do capítulo 01, e é o problema central de todo o resto do livro. Quase todo erro caro em ML é, no fundo, uma falha de generalização disfarçada de outra coisa.

### O que muda quando a regra é aprendida

| | Programação convencional | Machine Learning |
|---|---|---|
| Onde mora a regra | no código que você escreveu | nos parâmetros, ajustados a partir de dados |
| Como se corrige | edita-se o código | muda-se o dado, o objetivo ou o modelo |
| Como se sabe que está certo | testes: entrada conhecida → saída esperada | métricas sobre dados **que o modelo nunca viu** |
| O que dá errado | bug: o programa faz o que você escreveu, não o que você quis | o modelo aprende algo que era verdade nos seus dados e não é verdade no mundo |
| Como envelhece | envelhece quando o requisito muda | envelhece sozinho, quando o mundo muda (*drift*) |

A última linha é a que pega as equipes desprevenidas. Um sistema convencional que funcionou ontem funciona amanhã. Um modelo que funcionou ontem pode estar errado amanhã sem que uma linha de código tenha mudado — porque quem mudou foi o mundo do qual ele aprendeu. É por isso que o capítulo 16 existe.

## Quando **não** usar Machine Learning

Um livro de ML que não diz isso na primeira página está vendendo, não ensinando. Não use ML quando:

- **A regra é escrevível.** Se você consegue enunciar a regra, escreva-a. Ela será mais rápida, mais barata, auditável e não vai degradar sozinha. "Aprender" uma regra que você já sabe é engenharia ao contrário.
- **Errar é inaceitável.** Modelos erram por construção — a questão nunca é *se*, é *quanto* e *em quê*. Onde o erro é catastrófico e não há revisão humana no caminho, o custo do erro precisa ser projetado antes do modelo.
- **Você não tem exemplos.** Não há ML sem dados rotulados, medidos ou observados do fenômeno certo. Dado emprestado de outro contexto é a origem mais comum de fracasso silencioso (capítulo 02).
- **Ninguém consegue dizer o que é "bom".** Se a equipe não consegue definir a métrica antes de treinar, o projeto vai otimizar o que for fácil de medir — e isso raramente é o que importa (capítulo 04).

Os quatro casos acima são, empiricamente, mais comuns do que os projetos que de fato precisam de ML. Reconhecê-los é uma habilidade, não um obstáculo.

:::exercicio {"id":"00-e1","tipo":"multipla","objetivo":"O2","dificuldade":"facil"}
Uma equipe precisa validar se um número de cartão de crédito é sintaticamente válido antes de enviá-lo ao adquirente. Alguém propõe treinar um classificador com milhões de cartões válidos e inválidos. Qual é a melhor avaliação dessa proposta?

- [ ] Boa ideia: com dados suficientes, o modelo aprenderia a regra melhor do que um humano escreveria.
- [x] Má ideia: a regra (algoritmo de Luhn) é conhecida e escrevível — um modelo só introduziria erro onde não havia.
- [ ] Boa ideia, desde que a acurácia no teste passe de 99,9%.
- [ ] Depende do volume de cartões processados por segundo.

> **gabarito:** Má ideia: a regra é conhecida e escrevível
> **porque:** Machine Learning existe para quando a regra **não** é escrevível. A validação de cartão segue o algoritmo de Luhn, que é determinístico, exato e verificável linha a linha. Um modelo treinado para imitá-lo seria mais lento, não auditável, e — pior — erraria em algum ponto, trocando uma resposta *certa por construção* por uma *provavelmente certa*. Note que a alternativa da acurácia é uma armadilha: mesmo 99,99% seria pior que 100%, e a acurácia alta apenas esconderia que a tarefa era resolvível sem modelo nenhum.
> **volte para:** #quando-nao-usar-machine-learning
:::

:::exercicio {"id":"00-e2","tipo":"multipla-multi","objetivo":"O1","dificuldade":"media"}
Quais afirmações descrevem diferenças **estruturais** entre um sistema aprendido e um sistema programado? (marque todas que valem)

- [x] No sistema aprendido, a regra vive em parâmetros ajustados a partir de exemplos.
- [x] O sistema aprendido pode degradar sem nenhuma alteração no código.
- [ ] O sistema aprendido dispensa testes automatizados.
- [x] Verificar o sistema aprendido exige dados que ele nunca viu durante o treino.
- [ ] O sistema programado não pode ser corrigido depois de escrito.

> **gabarito:** parâmetros ajustados · degrada sem alteração de código · exige dados não vistos
> **porque:** As três corretas são exatamente as linhas da tabela de comparação: **onde mora a regra**, **como envelhece** e **como se verifica**. As duas erradas são mal-entendidos comuns e caros. Sistemas aprendidos precisam de *mais* testes automatizados, não menos — só que os testes mudam de natureza: além de "esta função retorna isto", passam a incluir "esta métrica não caiu abaixo deste limiar neste conjunto". E sistemas programados são, obviamente, corrigíveis; a diferença é *como* se corrige: editando a regra, em vez de mexer em dado, objetivo ou modelo.
> **volte para:** #o-que-muda-quando-a-regra-e-aprendida
:::

## Como este livro funciona

Este é um **livro vivo** e um **livro interativo**. As duas palavras têm significado técnico aqui.

**Vivo** quer dizer que ele declara sua própria data de validade. Cada capítulo carrega um selo de "estado da arte capturado em AAAA-MM", e cada afirmação sensível ao tempo vive sob esse selo. O [Histórico](HISTORICO.md) registra as edições e mantém um **placar de expiração**: as previsões que o livro fez, pontuadas contra a realidade. Um livro técnico que não faz isso finge ser atemporal — e envelhece mentindo.

**Interativo** quer dizer três superfícies, que se usam juntas:

| Superfície | O que é | Quando usar |
|---|---|---|
| **O texto** | os capítulos, no esqueleto v4 (objetivos → problema → fundamentos → estado da arte → prática) | para entender |
| **Os exercícios** | corrigidos no servidor, com feedback que explica o erro e devolve você à seção certa | para descobrir que você **não** entendeu |
| **A construção `ml-zero`** | um sistema de ML completo, escrito do zero, uma etapa por capítulo | para saber de verdade |

Há ainda um **tutor** (o botão 💬 no canto): um assistente que responde a partir do texto do livro, sabe em que capítulo você está e o que você já resolveu. Ele não entrega gabarito de exercício em aberto — dá a pista, não a resposta.

### A ordem que funciona

A tentação é ler tudo e praticar depois. A pesquisa sobre carga cognitiva diz o contrário, e este livro é construído para o contrário:

1. **Leia os objetivos** do capítulo. Eles são o contrato.
2. **Leia o corpo** até a seção "Mão na massa".
3. **Faça os exercícios antes de achar que entendeu.** Errar aqui é barato e informativo; errar em produção não é. O feedback do primeiro erro é deliberadamente uma pista, não a resposta — a segunda tentativa ainda é sua.
4. **Faça a etapa do `ml-zero`.** É onde o conceito vira código que roda.
5. **Volte à seção "Verificação"** e responda em voz alta. Se travar, o capítulo não terminou.

Ler sem praticar produz a sensação de competência sem a competência. É o modo de falha mais comum do estudo técnico, e o único que o leitor não consegue detectar sozinho — porque a sensação é idêntica.

:::exercicio {"id":"00-e3","tipo":"aberta","objetivo":"O3","pontos":3,"dificuldade":"media"}
Descreva um problema do seu trabalho ou da sua área de interesse que você acredita ser candidato a Machine Learning. Diga **qual regra ninguém consegue escrever**, **que exemplos existiriam** para aprender com eles, e **o que significaria "funcionar"** — em termos de uma medida, não de uma impressão.

> **rubrica:** identifica uma regra concreta que é difícil de enunciar explicitamente;
> descreve uma fonte de exemplos plausível e disponível, não hipotética;
> propõe uma medida de sucesso observável, e não um adjetivo ("bom", "preciso");
> a medida proposta tem alguma relação com a consequência no mundo, não só com o modelo
> **porque:** As três perguntas — regra, exemplos, medida — são o teste mínimo de viabilidade de um projeto de ML, e são as três que costumam ficar implícitas nas reuniões onde o projeto é aprovado. A terceira é a que mais falha: "queremos prever a evasão de clientes" não é uma medida; "queremos identificar, entre os 5% de clientes mais prováveis de sair no próximo mês, pelo menos metade dos que de fato saem" é. Note que definir a medida quase sempre expõe uma decisão de negócio que ninguém tinha tomado — e esse é o maior serviço que o exercício presta.
> **volte para:** #como-este-livro-funciona
:::

## Assista

:::video {"id":"00-v1","fonte":"youtube","ref":"Gv9_4yMHFhI","min":6,"autor":"StatQuest with Josh Starmer","titulo":"A Gentle Introduction to Machine Learning"}
Uma visão geral de seis minutos que fixa o vocabulário — treino, teste, predição — **antes** de qualquer formalismo. Vale como aquecimento: o texto acima explica *por que* ML existe; o vídeo mostra *como se parece* uma tarefa de ML na prática, com um exemplo visual único do começo ao fim.
:::

## O caminho pela frente

O livro é dividido em três partes, com uma progressão deliberada de andaime — cada parte remove um apoio que a anterior oferecia.

**Parte I — O ciclo do aprendizado supervisionado** (caps. 02–07). O núcleo. Dados, representação, avaliação, modelos lineares, otimização, ensembles. Ao final desta parte você resolve, do começo ao fim e com honestidade metodológica, a maioria dos problemas reais de ML que aparecem em empresas — que são tabulares, não são deep learning, e falham por causa de dados, não de modelo.

**Parte II — Sem rótulo, e profundo** (caps. 08–12). Agrupamento e redução de dimensionalidade; depois redes neurais construídas em NumPy, visão, sequências e a chegada dos modelos de fundação. O objetivo aqui não é competir com bibliotecas — é você ter visto o motor antes de dirigir o carro.

**Parte III — Machine Learning no mundo real** (caps. 13–17). Reforço, interpretabilidade e justiça, design de sistemas, MLOps, e a fronteira. É a parte que separa "treinei um modelo" de "opero um sistema que aprende".

Em paralelo, a trilha [`ml-zero`](trilha-ml-zero.md) constrói, etapa por etapa, um sistema completo: dado bruto → linha de base → avaliação honesta → modelo → serviço com API → monitoramento. Uma etapa por capítulo, tudo em CPU, sem chave paga (Princípio VI — custo zero é requisito, não cortesia).

## Síntese — o que levar

- ML é a resposta a **regras que existem e ninguém consegue escrever**. Onde a regra é escrevível, escreva-a.
- O problema central não é acertar nos dados que você tem; é **generalizar** para os que virão.
- Modelos envelhecem sozinhos. Isso não é defeito de implementação — é a natureza da coisa, e precisa ser projetado.
- Neste livro: leia os objetivos, leia o corpo, **erre nos exercícios**, construa a etapa, volte à verificação.

## Verificação

1. Dê um exemplo de problema em que ML é a escolha errada e explique por quê, sem usar a palavra "dados".
2. Um modelo em produção começa a errar mais, sem que nenhum código tenha mudado. Cite duas explicações possíveis e diga como você distinguiria uma da outra.
3. Por que este livro insiste que você faça os exercícios **antes** de sentir que entendeu o capítulo?

---

# 01 — Fundamentos

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-01 · [histórico](HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Explicar generalização como a diferença entre erro no que se viu e erro no que virá.
- **O2.** Diagnosticar *overfitting* e *underfitting* a partir do comportamento das curvas de erro.
- **O3.** Decompor o erro de um modelo em viés, variância e ruído — e dizer o que fazer em cada caso.
- **O4.** Justificar por que o conjunto de teste precisa ser tocado o mínimo possível.

## O problema: decorar não é aprender

Um estudante que decora a lista de exercícios resolvida vai bem na lista e mal na prova. Um modelo que decora os dados de treino vai bem no treino e mal em produção. É o mesmo fenômeno, e é o único problema deste livro — os outros capítulos são variações dele.

O nome técnico do fracasso é **overfitting**: o modelo ajustou-se não só ao padrão dos dados, mas também ao ruído deles. E ruído, por definição, não se repete.

O nome do fracasso oposto é **underfitting**: o modelo é simples demais para capturar o padrão, e erra igualmente no treino e no teste. Errar sempre é frustrante, mas é honesto — o modelo não engana ninguém sobre a própria qualidade. O overfitting é pior justamente porque **parece sucesso** enquanto está acontecendo.

O que separa os dois é a **capacidade** do modelo: quantas hipóteses diferentes ele consegue representar. Muita capacidade e poucos dados, ele decora. Pouca capacidade, ele não aprende. O trabalho é encontrar o ponto entre os dois — e, mais importante, **saber onde você está** nessa reta.

## De onde isto veio

**O aperto, e ele não nasceu na computação.** Em **1931**, um psicometrista de sobrenome **Larson** tinha um problema prático e irritante: ao ajustar uma regressão múltipla numa amostra e aplicá-la a outra, o coeficiente de correlação **encolhia**. Sempre. O artigo dele chama-se, literalmente, *"The Shrinkage of the Coefficient of Multiple Correlation"*. O aperto era esse — um número que descrevia bem os dados que o produziram e mentia sobre os próximos.

**O que se fazia antes.** Avaliava-se o modelo nos mesmos dados em que ele foi ajustado, e o resultado era tomado como estimativa da qualidade. Não por ingenuidade: dado era caro, e separar metade dele para não usar parecia desperdício.

**A virada.** Guardar dados que o modelo **não vê**. É uma ideia quase ofensiva de simples, e é a mais importante deste livro inteiro. Depois vieram as economias em cima dela: **Mosteller e Tukey (1968)** formulam o *leave-one-out*; **Stone (1974)** e **Geisser (1975)** constroem o arcabouço da validação cruzada. Note que Stone **cita explicitamente** Larson, Mosteller & Tukey e outros: o que ele traz de novo **não é a prática, é o arcabouço** que a justifica.

**A ideia reaproveitável.** **Quem avalia não pode ser quem produziu, nem usar a mesma informação.** A separação treino/teste é um caso particular de um princípio que vale muito além de modelos: o revisor precisa ser independente do autor; a prova precisa ter questões que não estavam na lista; o benchmark precisa ser secreto para medir alguma coisa. Toda vez que você vir um número bom demais, a primeira pergunta é **"quem avaliou, e com qual informação?"**.

**O nome.** *Cross-validation* é literalmente validar cruzando: cada parte dos dados serve, por sua vez, de juiz das outras.

### A curva em U — e a descoberta de que ela estava incompleta

A formulação canônica em Machine Learning do dilema viés–variância é **Geman, Bienenstock & Doursat, "Neural Networks and the Bias/Variance Dilemma"** (*Neural Computation*, 1992), que trata redes neurais como estimadores não-paramétricos e argumenta que a escolha do viés precisa casar com a estrutura do problema. Dali vem a curva em U que todo curso desenha: aumente a capacidade e o erro de teste cai, atinge um mínimo, e volta a subir.

Só que ela sobe **e depois desce de novo**. Belkin, Hsu, Ma e Mandal (*PNAS*, 2019) mostraram que, passando do ponto em que o modelo interpola perfeitamente o treino, o erro de teste **volta a cair** — o fenômeno do *double descent*, que explica por que redes enormes funcionam onde a intuição clássica previa desastre.

**A ideia reaproveitável, e é a que este capítulo mais quer que fique:** **uma "lei" empírica pode ser um artefato da faixa em que se mediu.** A curva em U não estava errada — estava **incompleta**. Era verdadeira dentro do regime de capacidade que era observável nos anos 1990. Quando o regime mudou, a lei revelou-se um trecho de uma curva maior. Guarde isso para toda regra prática que você aprender: *em que faixa isto foi medido?*

> **E o crédito, de novo.** Loog, Viering, Mey, Krijthe e Tax publicaram *"A brief prehistory of double descent"* (*PNAS*, 2020) contestando que o fenômeno tivesse sido historicamente negligenciado — a física estatística de redes neurais já o havia observado.
>
> É a terceira vez que este livro encontra o mesmo padrão. Gauss perde a prioridade dos mínimos quadrados para Legendre no [capítulo 05](capitulos/05-modelos-lineares.md); Linnainmaa perde o crédito do backpropagation para quem o popularizou, no [capítulo 18](capitulos/18-neuronio-artificial.md); e aqui, em **2019**, acontece de novo — desta vez à luz do dia, com todos os artigos indexados e acessíveis. Se ocorre hoje, com essa infraestrutura toda, não era problema de correio lento no século XIX. **Crédito segue comunicação, não descoberta** — e este é o caso contemporâneo que torna os outros dois inegáveis.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ᵐ | Geman, Bienenstock & Doursat (*Neural Computation* 4(1):1–58, 1992); Stone (*JRSS-B* 36(2):111–133, 1974); Geisser (*JASA* 70:320–328, 1975); [Belkin *et al.* (*PNAS* 116(32), 2019)](https://doi.org/10.1073/pnas.1903070116); [Loog *et al.* (*PNAS* 117(20), 2020)](https://arxiv.org/abs/2004.04328) |
| ⏳ | Larson (1931) como origem da divisão de amostra, e Mosteller & Tukey (1968) para o *leave-one-out* |
| ⏳ | Que Stone cita os antecessores e que sua contribuição é o arcabouço, não a prática — apurado, **mas o texto de Stone não foi relido diretamente, e por isso nada dele aparece entre aspas neste capítulo** |
| ❌ | A **primeira** formulação da decomposição viés–variância, anterior a 1992 — procurei e não localizei |
| 📖 | As duas ideias reaproveitáveis e a leitura do *double descent* como terceiro caso do padrão de crédito |

## Fundamentos: a hipótese que sustenta tudo

Todo Machine Learning supervisionado repousa numa hipótese que raramente é dita em voz alta:

> Os dados de treino e os dados que o modelo verá em produção vêm da **mesma distribuição**.

Se essa hipótese vale, minimizar o erro nos exemplos que você tem é uma aproximação razoável de minimizar o erro nos exemplos que virão. Isso tem nome — **minimização do risco empírico** (*Empirical Risk Minimization*, ERM) — e é o que praticamente todo algoritmo de treino faz.

Se a hipótese não vale, tudo o que vem depois é decoração. E ela **frequentemente não vale**:

- Você treinou com dados de 2024 e opera em 2026 (o mundo mudou — *drift*, cap. 16).
- Você treinou com clientes que a empresa já tinha e vai operar sobre clientes novos (viés de seleção, cap. 02).
- Você treinou com fotos bem iluminadas e vai operar no escuro (mudança de domínio, cap. 10).

Guarde isto: **a métrica de teste é uma promessa condicional.** Ela diz "se o futuro se parecer com este conjunto, o erro será aproximadamente este". Quando alguém reporta uma métrica sem dizer sob qual condição ela vale, está reportando meia informação.

### As três divisões, e por que são três

| Conjunto | Para que serve | Quantas vezes se olha |
|---|---|---|
| **Treino** | ajustar os parâmetros do modelo | o tempo todo |
| **Validação** | escolher entre modelos, ajustar hiperparâmetros, decidir quando parar | muitas vezes — é para isso que existe |
| **Teste** | estimar o erro de generalização | **o mínimo possível**, idealmente uma vez |

A razão de o teste ser separado da validação é sutil e cara de aprender na prática. Cada vez que você olha a validação e muda algo por causa do que viu, você está usando aquele conjunto para tomar uma decisão — e, aos poucos, ajustando o modelo *àquele conjunto*. Com dezenas de decisões, o número da validação vira otimista: você fez overfitting na própria medição.

O teste existe para ser a testemunha que não foi coagida. Toda vez que você o consulta e reage ao que viu, ele perde um pouco dessa qualidade. Não há alarme, não há erro na tela: o número simplesmente vai ficando menos verdadeiro.

:::exercicio {"id":"01-e1","tipo":"multipla","objetivo":"O4","dificuldade":"media"}
Uma equipe testa 40 configurações de modelo, medindo cada uma no conjunto de teste, e reporta a melhor: 94,2% de acurácia. Qual é o problema mais grave dessa prática?

- [ ] Nenhum: testar muitas configurações é justamente o que se deve fazer.
- [ ] O problema é o custo computacional de 40 treinos.
- [x] O 94,2% é otimista: escolher o máximo entre 40 medições ruidosas seleciona também a sorte, e o teste deixou de ser uma estimativa imparcial.
- [ ] O problema é que 40 configurações é pouco para explorar bem o espaço.

> **gabarito:** O 94,2% é otimista
> **porque:** Cada medição no teste carrega ruído amostral. Ao tomar o **máximo** de 40 medições ruidosas, você seleciona sistematicamente as configurações que tiveram sorte naquele conjunto específico — e a sorte não se repete. O número reportado passa a conter uma parcela de acaso que será cobrada em produção. A correção é estrutural, não estatística: comparar as 40 configurações na **validação**, escolher uma, e só então medir essa uma no teste. Note que o custo computacional (alternativa 2) é uma questão real, mas menor: dinheiro se resolve com dinheiro; uma estimativa contaminada leva a decisão errada e ninguém percebe.
> **volte para:** #as-tres-divisoes-e-por-que-sao-tres
:::

## A decomposição viés–variância

Quando um modelo erra, o erro esperado se decompõe em três parcelas — e cada uma pede uma ação diferente. Esta é provavelmente a ferramenta de diagnóstico mais útil do livro inteiro.

**Viés (*bias*)** — o erro de suposição. O modelo é sistematicamente incapaz de representar o padrão. Uma reta tentando descrever uma curva tem viés alto: não importa quantos dados você dê, ela continuará errando do mesmo jeito, na mesma direção.

**Variância** — o erro de instabilidade. O modelo é tão sensível aos dados específicos que recebeu que, treinado em outra amostra do mesmo fenômeno, produziria algo bem diferente. Variância alta é o sintoma matemático do overfitting.

**Ruído irredutível** — a parte que nenhum modelo alcança, porque o próprio fenômeno é aleatório ou porque a informação necessária não está nos dados. Perseguir essa parcela é o modo mais eficiente de desperdiçar um trimestre.

### O diagnóstico prático

O sintoma é visível nas duas curvas de erro:

| Erro no treino | Erro na validação | Diagnóstico | O que fazer |
|---|---|---|---|
| alto | alto (parecido) | **viés alto** (underfitting) | modelo mais expressivo; melhores atributos; treinar mais |
| baixo | alto (bem maior) | **variância alta** (overfitting) | mais dados; regularização; modelo mais simples |
| baixo | baixo | bom — verifique se não há vazamento | vá ao teste, **uma vez** |
| alto | baixo | quase sempre um bug | investigue a divisão dos dados antes de comemorar |

A última linha merece atenção. Erro de validação *melhor* que o de treino costuma indicar que os conjuntos não são comparáveis — uma divisão mal feita, um vazamento invertido, ou regularização forte aplicada só no treino. É um resultado bom demais, e resultados bons demais são a pista mais confiável de que algo está errado (cap. 02).

**Uma advertência sobre a decomposição.** A ideia de que mais capacidade sempre aumenta a variância é uma simplificação útil — e é *falsa* no regime das redes modernas. Modelos muito grandes, treinados muito além do ponto de interpolação, frequentemente voltam a generalizar bem, num fenômeno chamado **double descent** ([Belkin et al., 2019](https://doi.org/10.1073/pnas.1903070116), ✓). A intuição viés–variância continua sendo a melhor ferramenta de diagnóstico para o regime clássico — que é onde vive a maior parte do trabalho tabular deste livro — mas **não é uma lei universal**, e o capítulo 09 volta ao assunto.

> **Cláusula de expiração.** Escrevo em 2026 que a decomposição viés–variância é a ferramenta de diagnóstico dominante na prática tabular, e que o *double descent* é entendido como fenômeno do regime superparametrizado. Se, na próxima revisão, existir uma teoria unificada que preveja quantitativamente o comportamento de generalização nos dois regimes, esta seção precisa ser reescrita — não apenas emendada. Acompanhamento no [placar de expiração](HISTORICO.md).

:::exercicio {"id":"01-e2","tipo":"multipla","objetivo":"O2","dificuldade":"media"}
Um modelo atinge 0,98 de acurácia no treino e 0,71 na validação. Qual é o diagnóstico e a primeira ação razoável?

- [ ] Viés alto: aumentar a capacidade do modelo.
- [x] Variância alta: regularizar, simplificar o modelo ou conseguir mais dados.
- [ ] Ruído irredutível: aceitar o resultado, é o teto do problema.
- [ ] Impossível diagnosticar sem ver o erro no teste.

> **gabarito:** Variância alta
> **porque:** A assinatura é o **vão** entre treino e validação: 0,98 contra 0,71. O modelo tem capacidade de sobra — ele consegue explicar quase perfeitamente os dados que viu — mas o que aprendeu não se transfere. Isso é variância alta, ou seja, overfitting. Aumentar a capacidade (alternativa 1) pioraria; o sintoma de viés alto seria erro **alto nos dois** conjuntos, e próximos entre si. E note por que a última alternativa é errada e perigosa: você não precisa — nem deve — consultar o teste para fazer esse diagnóstico. Diagnóstico se faz na validação; o teste é a testemunha que se preserva.
> **volte para:** #o-diagnostico-pratico
:::

:::exercicio {"id":"01-e3","tipo":"completar","objetivo":"O3","dificuldade":"facil"}
Complete o termo que falta na decomposição do erro esperado de um modelo:

`erro esperado ≈ viés² + ______ + ruído irredutível`

> **gabarito:** variância|variancia
> **porque:** A decomposição clássica tem três parcelas: o **viés²** (o quanto o modelo erra sistematicamente, por não conseguir representar o padrão), a **variância** (o quanto ele oscila conforme a amostra de treino muda) e o **ruído irredutível** (o que nenhum modelo alcança). O valor prático de decorar isto não é a fórmula — é que cada parcela pede uma ação diferente: viés pede mais expressividade, variância pede mais dados ou mais restrição, e ruído pede que você pare.
> **volte para:** #a-decomposicao-vies-variancia
:::

## O vocabulário mínimo

Estes termos aparecem em todos os capítulos seguintes. Estão também no [Glossário](glossario.md).

- **Exemplo** (ou *instância*, *observação*) — uma linha: um cliente, uma foto, uma transação.
- **Atributo** (*feature*) — uma coluna: idade, pixel 37, quantidade de palavras.
- **Alvo** (*target*, *label*) — o que se quer prever. Sua presença define o aprendizado como **supervisionado**.
- **Modelo** — a função que mapeia atributos ao alvo, mais os parâmetros que a especificam.
- **Parâmetro** — o que o treino ajusta (pesos). **Hiperparâmetro** — o que você escolhe antes do treino (taxa de aprendizado, profundidade). A confusão entre os dois causa metade dos erros de metodologia.
- **Função de perda** — a medida do quanto uma predição errou; é o que a otimização minimiza.
- **Métrica** — a medida que interessa a **você**. Nem sempre é a perda; quase nunca deveria ser (cap. 04).

A distinção entre perda e métrica é a fonte de mal-entendidos mais persistente para quem está começando. A perda precisa ser diferenciável e bem-comportada para o otimizador; a métrica precisa ser interpretável e ligada à consequência no mundo. São propósitos diferentes, e otimizar a primeira esperando melhorar a segunda é uma aposta — às vezes boa, nunca automática.

## Mão na massa

A **etapa 00** do [`ml-zero`](trilha-ml-zero.md) monta o esqueleto: carregar um dataset, dividir em treino/validação/teste com *seed* fixa, e treinar a linha de base mais burra possível (prever sempre a classe majoritária).

Parece pouco. É o número mais importante do projeto: **nenhum modelo que não bate a linha de base merece existir**, e um número surpreendente de projetos em produção nunca calculou a sua.


**Notebook pronto para executar** — [`linha_de_base.ipynb`](https://github.com/GHDaru/machinelearning/blob/main/ml-zero/etapa-00/linha_de_base.ipynb) · [abrir no Colab](https://colab.research.google.com/github/GHDaru/machinelearning/blob/main/ml-zero/etapa-00/linha_de_base.ipynb)

Monta as três divisões, treina a linha de base e mostra por que **81% de acurácia pode ser um resultado péssimo** — o modelo não encontra um único positivo.

> Na sua máquina: `pip install notebook` e `jupyter notebook`, ou abra a pasta no VS Code. O notebook **não precisa do repositório clonado** — se você estiver no Colab, ele baixa sozinho os arquivos de que precisa. Como rodar a trilha inteira: [`ml-zero`](https://github.com/GHDaru/machinelearning/blob/main/ml-zero/README.md).

## Assista

:::video {"id":"01-v1","fonte":"youtube","ref":"EuBBz3bI-aA","min":7,"autor":"StatQuest with Josh Starmer","titulo":"Machine Learning Fundamentals: Bias and Variance"}
A decomposição viés–variância é um daqueles conceitos que a prosa explica e o **gráfico** fixa. O vídeo mostra ajustes sucessivos ao mesmo conjunto de pontos, e a intuição visual de "a curva balança demais quando os dados mudam" é o que faz o termo *variância* deixar de ser jargão e virar algo que você reconhece de longe num gráfico de treino.
:::

## Síntese — o que levar

- Aprender é **generalizar**, não acertar no que já se viu.
- Toda métrica de teste é uma promessa condicional: vale enquanto o futuro se parecer com o teste.
- O vão entre treino e validação é seu diagnóstico primário: vão grande = variância; erro alto nos dois = viés.
- **Validação para decidir, teste para testemunhar.** Consultar o teste repetidamente não dá erro — só torna o número mentiroso.
- Antes de qualquer modelo, calcule a linha de base trivial. É o piso contra o qual todo o resto se mede.

## Verificação

1. Explique, sem usar a palavra "overfitting", por que um modelo pode ir muito bem no treino e mal em produção.
2. Você recebe um relatório com acurácia de 0,93 no teste. Que três perguntas você faz antes de acreditar?
3. Um colega quer "usar o teste para escolher o melhor de três modelos, porque é o conjunto mais confiável". Onde está o erro do raciocínio?

---

# 19 — O Ciclo da Ciência de Dados

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-08 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Descrever as seis fases do CRISP-DM e o que cada uma entrega.
- **O2.** Justificar por que entendimento de negócio vem antes de qualquer dado.
- **O3.** Reconhecer que o ciclo é iterativo, e não uma cascata.
- **O4.** Distinguir os papéis de cientista de dados, engenheiro de dados e engenheiro de ML.

## O problema: um modelo excelente para a pergunta errada

Um varejista pede um modelo de *churn*. A equipe recebe acesso ao banco, encontra a tabela de compras, define o rótulo pelo que os dados permitem — "cliente que não compra há 90 dias" — treina, mede e entrega AUC de 0,93. O relatório é bonito. O modelo nunca foi usado.

O motivo apareceu na primeira reunião com a área de retenção: eles só conseguem agir sobre um cliente **na renovação do plano**, e a renovação acontece antes dos 90 dias de silêncio. Quando o modelo acusa risco, o cliente já foi embora. A lista chega tarde para todo mundo que poderia fazer algo com ela.

Nenhuma métrica do [capítulo 04](04-avaliacao.md) capturaria isso. O modelo é bom; o alvo é que responde a uma pergunta que ninguém tinha. E repare no mecanismo do erro: a equipe começou **pelos dados disponíveis**, e o rótulo saiu do que era fácil de calcular, não do que era possível decidir.

O CRISP-DM (*CRoss-Industry Standard Process for Data Mining*) existe para tornar esse erro difícil de cometer. Ele coloca *entendimento do negócio* como fase 1 e *modelagem* como fase 4 — e essa ordem é a lição inteira do capítulo.

## De onde isto veio

**O aperto.** Meados dos anos 1990. Mineração de dados era um mercado novo, com dinheiro entrando e nenhum acordo sobre como se trabalha. Cada projeto reinventava seu próprio processo. Dois times na mesma empresa entregavam relatórios que não se comparavam; duas empresas não conseguiam repetir o que a outra tinha feito. Não havia como saber se um resultado ruim veio do problema, dos dados ou de alguém ter pulado uma etapa — porque não existia a lista de etapas.

**O que se fazia antes.** Consultoria: cada casa trazia seu método interno, não publicado, casado com a ferramenta que vendia. E ferramenta se vendia sem método nenhum — comprava-se o *workbench*, e o cliente que descobrisse sozinho o que fazer com ele.

**A virada.** Escrever um processo **de indústria**, e não de fornecedor. Seis fases explicitamente **cíclicas**, com *entendimento do negócio* na primeira posição e *modelagem* apenas na quarta. O documento não pertence a ninguém, não exige software algum e descreve entregas, não cliques.

**A ideia reaproveitável.** **O método é o produto, não a ferramenta.** Quando um campo novo ainda não tem processo comum, o processo comum vale mais do que qualquer algoritmo: é ele que torna o resultado **auditável** (dá para perguntar em que fase a coisa desandou) e **transferível** (outra equipe consegue continuar o trabalho). Vale para muito além de mineração de dados — é a mesma razão pela qual um repositório com README, testes e CI vale mais que um repositório com código mais esperto.

**O nome.** *CRoss-Industry Standard Process for Data Mining*. O "cross-industry" não é enfeite, é a tese: o processo não pode pertencer a um setor nem a um vendedor, ou volta a ser método de consultoria.

Concebido no fim de 1996, virou projeto europeu com financiamento **ESPRIT** em 1997, tocado por um consórcio de cinco organizações: a ISL — depois absorvida pela SPSS, autora do Clementine, o primeiro *workbench* comercial de mineração, de 1994 —, a Teradata, a NCR, a Daimler-Benz e a seguradora holandesa OHRA. Foi testado em projetos reais na Mercedes-Benz e na OHRA, e a versão 1.0 saiu em 1999 ([guia CRISP-DM 1.0](https://www.kde.cs.uni-kassel.de/lehre/ws2012-13/kdd/files/CRISPWP-0800.pdf)).

Olhe outra vez para a lista do consórcio: uma **montadora** e uma **seguradora** sentadas na mesma mesa. A prova de conceito do "cross-industry" está na composição do grupo — se o mesmo processo servisse para fabricar carros e para precificar apólices, servia para o resto.

> **A restrição material gerou a forma.** O CRISP-DM não é fruto de uma boa ideia solta: é resposta a um mercado sem linguagem comum. O livro já viu isso duas vezes — no [capítulo 22](22-visualizacao-storytelling.md), Playfair inventa o gráfico de barras porque **não tinha** a série temporal que os outros gráficos exigiam; no [capítulo 18](18-neuronio-artificial.md), o neurônio de 1943 nasce sem aprendizado porque não havia como treinar coisa alguma. Falta de recurso é o que mais produz forma nova.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ᵐ | A estrutura de seis fases cíclicas e o nome por extenso, pelo guia CRISP-DM 1.0 (1999) — documento localizado e identificado, **não lido por inteiro** |
| ✓ᵐ | A cronologia (concepção no fim de 1996, ESPRIT em 1997, versão 1.0 em 1999), a composição do consórcio (ISL/SPSS, Teradata, NCR, Daimler-Benz, OHRA), os testes na Mercedes-Benz e na OHRA, e o Clementine (1994) como primeiro *workbench* comercial |
| ⏳ | O estado do mercado em meados dos anos 1990: processo ad hoc por consultoria, ferramenta vendida sem método, resultados não comparáveis nem repetíveis entre empresas |
| ⏳ | Que a presença de uma seguradora ao lado de uma montadora funcione como prova de conceito do "cross-industry" |
| 📖 | A ideia reaproveitável ("o método é o produto, não a ferramenta") e a leitura de que o processo comum é o que torna o resultado auditável e transferível |

## Fundamentos: as seis fases e o que cada uma entrega

Uma fase não termina quando o tempo acaba — termina quando ela **entrega** o artefato que a fase seguinte consome.

| # | Fase | A pergunta que ela responde | O que entrega |
|---|---|---|---|
| 1 | **Entendimento do negócio** | que decisão vai mudar, de quem, e quando? | objetivo de negócio, critério de sucesso, restrição de ação |
| 2 | **Entendimento dos dados** | o que existe, e dá para confiar? | inventário das fontes, primeiras estatísticas, problemas de qualidade |
| 3 | **Preparação dos dados** | como isto vira uma tabela treinável? | conjunto de treino/teste, atributos, rótulo definido |
| 4 | **Modelagem** | que família de modelo, com que hiperparâmetros? | modelos treinados e seus resultados técnicos |
| 5 | **Avaliação** | isto resolve o problema da fase 1? | decisão de seguir, iterar ou parar |
| 6 | **Implantação** | como isto chega a quem decide, e continua funcionando? | sistema em produção, monitoramento, plano de manutenção |

Três fases já têm capítulo próprio neste livro. A **preparação dos dados** é o assunto do [capítulo 02](02-dados.md) e do [capítulo 20](20-coleta-integracao.md). A **avaliação** técnica — matriz de confusão, métrica escolhida pelo custo do erro — é o [capítulo 04](04-avaliacao.md). A **implantação** é o [capítulo 15](15-sistemas-de-ml.md) e o [capítulo 16](16-mlops.md).

E vale separar duas coisas que o vocabulário mistura. A métrica que você calcula dentro da fase 4 responde *"o modelo aprendeu?"*. A fase 5 responde *"e daí?"* — se o ganho de AUC vira dinheiro, se a lista chega a tempo de alguém agir, se o critério escrito na fase 1 foi atingido. Um modelo pode passar na primeira e reprovar na segunda. Foi exatamente o que aconteceu com o *churn* do início do capítulo.

:::exercicio {"id":"19-e1","tipo":"multipla","objetivo":"O2","dificuldade":"media"}
Uma seguradora pede um modelo para "reduzir os sinistros de automóvel". O projeto tem seis semanas. O que o CRISP-DM manda fazer na primeira?

- [ ] Levantar as tabelas disponíveis no *data warehouse* e medir a qualidade de cada campo.
- [x] Descobrir qual decisão vai mudar por causa do modelo, quem a toma e com quanta antecedência.
- [ ] Treinar um modelo simples de linha de base, para saber se o problema tem sinal.
- [ ] Definir a métrica de avaliação e separar o conjunto de teste.

> **gabarito:** Descobrir qual decisão vai mudar, quem a toma e quando
> **porque:** "Reduzir sinistros" não é um problema de mineração de dados — é um objetivo de negócio, e dele saem alvos completamente diferentes: prever quem vai bater o carro, recusar propostas de risco, reprecificar apólices na renovação, priorizar vistoria. Cada um exige rótulo, dado e prazo distintos. Sem essa conversa você não escolhe entre eles: você herda o alvo que a tabela mais acessível permitir.
>
> A alternativa mais tentadora é a última — o [capítulo 04](04-avaliacao.md) insiste em definir a métrica **antes** de treinar, e isso está certo. Mas a métrica se escolhe pelo custo do erro, e o custo do erro é informação de negócio: quem paga um falso positivo aqui, o cliente recusado ou a seguradora? Definir métrica sem a fase 1 é escolher no chute e chamar de rigor. Inventariar tabelas é a fase 2; treinar uma linha de base é a fase 4 — as duas são trabalho útil, na hora errada.
> **volte para:** #o-problema-um-modelo-excelente-para-a-pergunta-errada
:::

:::exercicio {"id":"19-e4","tipo":"aberta","objetivo":"O2","pontos":3,"dificuldade":"media"}
**Fase 1 — Entendimento do negócio.** *Que decisão vai mudar, de quem, e quando?*

Uma barraca de limonada guarda, há um ano, o registro diário de tempo, panfletos distribuídos, preço praticado e copos vendidos. A dona quer "usar os dados para vender mais".

Escreva os **três artefatos** que a fase 1 tem de entregar antes de alguém abrir a planilha:

1. o **objetivo de negócio** (não o objetivo técnico);
2. o **critério de sucesso**, com um número ou um limiar que dê para verificar depois;
3. a **restrição de ação** — o que a dona **consegue** mudar, com que antecedência.

> **rubrica:** o objetivo de negócio é expresso em consequência para a barraca (vender mais, perder menos, comprar melhor), e não em métrica de modelo;
> o critério de sucesso é verificável — traz número, limiar ou comparação com o que se faz hoje;
> a restrição de ação nomeia o que a dona controla de fato (preço, quantidade de panfletos, quanto preparar) e o que ela não controla (o tempo);
> a resposta considera o prazo: a previsão precisa chegar antes do momento em que a decisão é tomada;
> não confunde as três coisas entre si nem pula alguma
> **porque:** As três respostas juntas decidem se o projeto tem chance. Um exemplo do que cada uma parece:
>
> **Objetivo de negócio:** "decidir quanta limonada preparar por dia, para não sobrar nem faltar". Repare que não há a palavra "modelo" — a fase 1 fala a língua de quem decide.
>
> **Critério de sucesso:** "errar a quantidade preparada em menos de 5 copos na maioria dos dias, contra os 12 copos de erro médio de hoje". Traz número e traz comparação com o que já existe: sem linha de base, "melhor" não quer dizer nada (capítulo 01).
>
> **Restrição de ação:** ela decide quanto preparar **de manhã**, antes de saber o movimento do dia. Isso muda tudo — a previsão tem de estar pronta **antes**, e só pode usar o que se sabe de manhã. Uma previsão que usa o número de panfletos efetivamente distribuídos durante o dia é inútil para decidir de manhã, por mais precisa que seja.
>
> É o mesmo erro do *churn* do começo do capítulo: o modelo acertava, e a informação chegava depois da hora de agir.
> **volte para:** #fundamentos-as-seis-fases-e-o-que-cada-uma-entrega
:::

:::exercicio {"id":"19-e5","tipo":"aberta","objetivo":"O1","pontos":3,"dificuldade":"media"}
**Fase 2 — Entendimento dos dados.** *O que existe, e dá para confiar?*

O registro da barraca tem 365 linhas e sete colunas: `data`, `dia_semana`, `temperatura`, `precipitacao`, `panfletos`, `preco`, `vendas`. Nenhum valor faltante.

Entregue as **três** coisas que a fase 2 exige:

1. o **inventário**: o que cada coluna é, e — a pergunta que separa a fase 2 da fase 3 — **quais delas você teria em mãos no momento de decidir**;
2. as **primeiras estatísticas** que você pediria antes de qualquer modelo, e o que cada uma responderia;
3. pelo menos **dois problemas de qualidade ou de confiança** que você iria procurar neste conjunto específico.

> **rubrica:** separa as colunas conhecidas ANTES da decisão das que só existem depois do dia acontecer (vendas é o alvo; panfletos e preço são decisões da dona; temperatura e precipitação dependem de previsão do tempo, não do valor observado);
> pede estatísticas descritivas concretas — faixa, média, valores distintos, contagem por categoria — e diz o que cada uma responderia;
> aponta pelo menos dois riscos reais do conjunto, entre: unidade da temperatura não declarada, preço com pouquíssimos valores distintos, período curto de um ano só, ausência de registro de dias fechados, dado possivelmente sintético;
> não trata "sem valores faltantes" como prova de qualidade;
> a resposta é sobre ESTE conjunto, não uma lista genérica de boas práticas
> **porque:** A fase 2 não é "olhar os dados": é decidir **se dá para confiar** e **o que está faltando**. Três achados que este conjunto entrega a quem procura:
>
> **A unidade da temperatura não está declarada.** A faixa vai de 15 a 103. Em Fahrenheit faz sentido; em Celsius seria impossível. Reportar um coeficiente sem saber a unidade é reportar um número sem significado.
>
> **O preço tem só dois valores distintos** em 365 dias. Uma coluna quase constante quase não informa — e, pior, os dois valores podem estar amarrados a outra coisa (fase 3 e capítulo 05 mostram que estão: o preço mais alto só aparece em julho e agosto).
>
> **"Sem valores faltantes" não é atestado de qualidade.** Pode significar que os dias fechados simplesmente não viraram linha. Um ano com exatamente 365 registros e nenhuma falha é suspeito num negócio de rua — e a ausência de buracos é, ela própria, um dado sobre como o registro foi feito.
>
> E o item 1 é o que mais reprova em projeto real: `panfletos` só é conhecido **depois** de a dona decidir quantos distribuir. Usá-lo para prever a demanda da manhã transforma o modelo numa profecia que depende de ver o futuro.
> **volte para:** #fundamentos-as-seis-fases-e-o-que-cada-uma-entrega
:::

## As setas voltam: por que isto é um ciclo, não uma cascata

O desenho do CRISP-DM tem setas entre fases vizinhas **e setas de volta**. Elas não são decoração de diagrama: são as quatro descobertas que todo projeto faz fora de ordem.

- **Fase 2 → fase 1.** Você abre os dados e descobre que a pergunta não é respondível: o campo que definiria o alvo só existe a partir de 2024, ou é preenchido à mão em 30% dos casos. A pergunta precisa mudar antes que qualquer coisa seja treinada.
- **Fase 4 → fase 3.** O laço mais frequente do ciclo. Todo erro que o modelo comete devolve trabalho para a preparação — um atributo novo, um vazamento a tapar, um recorte de amostra a corrigir.
- **Fase 5 → fase 1.** O modelo funciona e não serve: chega tarde, prevê o que ninguém pode acionar, ou o ganho não paga o custo operacional.
- **Fase 6 → tudo.** Em produção, o mundo muda debaixo do modelo — comportamento, catálogo, política de preço. É o *drift* do [capítulo 16](16-mlops.md), e é a razão de o CRISP-DM ser um círculo e não uma reta: a implantação reabre o ciclo, ela não o encerra.

A consequência prática vale a regra: **a fase 3 é a mais revisitada**, porque cada volta da modelagem cai nela. Quanto tempo isso representa, o CRISP-DM não promete — e este livro não repete a porcentagem que circula por aí sem tê-la medido.

Tratar o ciclo como cascata tem um custo específico e previsível: você descobre na semana seis o que custaria uma reunião na semana um.

:::exercicio {"id":"19-e2","tipo":"numerica","objetivo":"O3","dificuldade":"facil"}
Na fase de avaliação, a equipe descobre que rotulou como "cliente perdido" quem ficou 90 dias sem comprar — enquanto, para a área de retenção, perder um cliente é ele **não renovar o contrato**. O modelo prevê muito bem o rótulo que recebeu.

Para qual fase, de 1 a 6, o CRISP-DM manda voltar? Responda com o número.

> **gabarito:** 1
> **porque:** Definir o que conta como evento é **entendimento do negócio**, fase 1. O que quebrou não foi a construção do rótulo: foi o acordo sobre o que se está prevendo.
>
> A resposta tentadora é **3** — preparação dos dados — porque foi lá que o rótulo virou coluna, e é lá que o conserto vai ser digitado. Mas refazer o rótulo sem reabrir a conversa com a retenção só produz um segundo alvo escolhido pela equipe técnica, com a mesma chance de errar. A fase 1 é onde se pergunta *"cliente perdido é quem, para quem age?"*; a fase 3 é onde a resposta vira código. Voltar até a 1 parece o caminho mais caro e é o mais barato: a semana perdida na 1 já foi perdida, as fases 2 a 5 é que serão refeitas de graça se o alvo continuar errado.
> **volte para:** #as-setas-voltam-por-que-isto-e-um-ciclo-nao-uma-cascata
:::

## Quem faz o quê: quatro papéis sobre o mesmo ciclo

Os cargos que o mercado usa não são especializações por técnica — são **recortes do ciclo**. Ver assim explica por que um time incompleto sempre falha na mesma fase.

| Papel | Onde vive | O que entrega |
|---|---|---|
| **Analista / dono do problema** | fases 1 e 5 | o critério de sucesso e o veredito sobre se ele foi atingido |
| **Engenheiro de dados** | fases 2 e 3 | as fontes confiáveis e o pipeline que as mantém ([cap. 20](20-coleta-integracao.md)) |
| **Cientista de dados** | fases 3, 4 e 5 | atributos, modelo, e a leitura honesta do resultado |
| **Engenheiro de ML** | fases 4 e 6 | o modelo servindo em produção, monitorado ([cap. 15](15-sistemas-de-ml.md), [cap. 16](16-mlops.md)) |

Duas leituras saem da tabela. A primeira: **a fase 3 é onde os papéis se encontram** — o engenheiro entrega a fonte, o cientista constrói o atributo — e por isso é onde mais se perde trabalho quando ninguém combinou quem faz o quê.

A segunda é mais séria. Num time só de gente técnica, **a fase 1 fica sem dono**. Ninguém foi contratado para descobrir qual decisão vai mudar, e o ciclo começa pela fase 2 — que é exatamente o erro da primeira seção deste capítulo. Em time pequeno, uma pessoa ocupa vários papéis, e isso funciona; o que não funciona é uma fase sem responsável declarado.

:::exercicio {"id":"19-e3","tipo":"aberta","objetivo":"O4","pontos":3,"dificuldade":"media"}
Um time de três pessoas — um engenheiro de dados, um cientista de dados e um engenheiro de ML — vai retomar o projeto de *churn* do começo do capítulo.

Distribua as seis fases entre os três, aponte a fase que corre risco de ficar **sem dono** e diga como você resolveria isso.

> **rubrica:** atribui as fases 2 e 3 majoritariamente ao engenheiro de dados;
> atribui as fases 4 e 5 ao cientista de dados;
> atribui a fase 6 ao engenheiro de ML, com monitoramento;
> identifica a fase 1 (entendimento do negócio) como a que fica sem dono natural neste trio;
> propõe uma solução concreta — trazer a área de retenção para a fase 1, ou o cientista de dados assumir formalmente a conversa — em vez de só apontar o problema;
> justifica com a consequência: sem dono na fase 1, o time otimiza um alvo que ninguém pediu
> **porque:** O recorte por fase é direto: dados chegam pelo engenheiro de dados (2 e 3), o modelo e sua leitura são do cientista de dados (4 e 5), produção e monitoramento são do engenheiro de ML (6). A fase 3 é compartilhada, e vale dizer isso na resposta.
>
> A parte que separa uma boa resposta de uma lista é a **fase 1**. Nenhum dos três foi contratado para ela, e é justamente a fase cuja ausência produziu o fracasso original: o rótulo de 90 dias saiu do que a tabela permitia, não do que a retenção podia acionar. Uma resposta que só distribui as seis fases entre os três está reproduzindo o erro do capítulo com organograma novo. Resolver não exige contratar ninguém — exige declarar um responsável por conversar com quem age, e um critério de sucesso escrito antes da primeira consulta ao banco.
> **volte para:** #quem-faz-o-que-quatro-papeis-sobre-o-mesmo-ciclo
:::

## Síntese — o que levar

- O CRISP-DM tem **seis fases**: entendimento do negócio, entendimento dos dados, preparação, modelagem, avaliação e implantação. Cada uma termina por **entrega**, não por prazo.
- **Modelagem é a quarta.** Começar pelos dados disponíveis faz o rótulo sair do que é fácil de calcular, e não do que é possível decidir.
- A fase 5 não é a métrica de teste: é *"isto resolve o problema da fase 1?"*. Modelo pode passar na 4 e reprovar na 5.
- **As setas voltam.** Fase 4 devolve trabalho para a 3; fase 5 devolve para a 1; a implantação reabre o ciclo por causa do *drift*.
- Os cargos são **recortes do ciclo**, não especialidades técnicas — e num time só técnico a fase 1 fica sem dono.
- Nasceu de um consórcio de indústria (1996–1999, ESPRIT), com montadora e seguradora na mesma mesa, para que o processo não pertencesse a nenhum fornecedor.
- **O método é o produto, não a ferramenta.** Em campo novo, o processo comum é o que torna o resultado auditável e transferível — mais do que qualquer algoritmo.

## Verificação

1. Liste as seis fases de memória e diga, em uma frase cada, **o artefato** que cada uma entrega para a seguinte.
2. Um colega diz: "não dá para conversar com o negócio antes de olhar os dados, porque não sabemos o que é possível". O que há de certo nessa objeção, e por que ela mesmo assim não justifica começar pela fase 2?
3. Você chega a um projeto em que ninguém sabe dizer qual decisão vai mudar por causa do modelo. Que perguntas você faz, e a quem, antes de escrever a primeira linha de código?

---

# 20 — Coleta e Integração de Dados

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Extrair dados de arquivos, APIs, bancos relacionais e não relacionais.
- **O2.** Comparar data lake e data warehouse quanto a propósito e custo.
- **O3.** Aplicar ETL e explicar quando ELT é preferível.
- **O4.** Avaliar a licença e a procedência de uma base pública antes de usá-la.

## O problema: o mesmo cliente, três vezes

Uma rede de varejo pede um modelo de recompra. A equipe precisa de uma linha por cliente, e o cliente está em três lugares: no CRM (cadastro comercial), no faturamento e no aplicativo da loja. Ninguém tem a mesma chave. No CRM ele é `João Silva`; no faturamento, `SILVA, J.`; no aplicativo, só um CPF e um e-mail.

A equipe faz o que parece óbvio: junta por nome. O resultado sai em duas horas e parece bom. Semanas depois alguém descobre que 12% da base virou dois clientes diferentes, e um punhado de homônimos virou um cliente só — com o histórico de compras de duas pessoas somado. O modelo aprendeu de um mundo que não existe.

Este é o capítulo menos glamouroso do livro e um dos que mais decidem o prazo do projeto. Ele cobre as fases 2 e 3 do ciclo do [capítulo 19](19-ciclo-ciencia-de-dados.md) — entender e preparar os dados —, e o erro que previne não é de algoritmo: é acreditar que "trazer o dado" é uma tarefa de cópia. Não é. É uma tarefa de **reconciliação**, porque cada sistema tem a sua própria noção do que é um cliente, uma data e um valor ausente.

## De onde isto veio

**O aperto.** Anos 1980–90. Os dados da empresa viviam nos sistemas transacionais — o sistema do caixa, do estoque, da cobrança —, todos projetados para **registrar**, não para **perguntar**. Registrar exige gravar uma linha por vez, rápido e sem inconsistência. Perguntar exige varrer milhões de linhas de uma vez. Os dois disputavam a mesma máquina, e quando o gerente pedia o relatório do trimestre, a consulta pesada competia com a operação — e podia derrubá-la. O relatório do gerente travava a venda no caixa.

**O que se fazia antes.** Extraía-se o relatório direto do sistema de produção, em janela noturna. Funcionava enquanto a janela coubesse na noite e enquanto ninguém precisasse perguntar de dia.

**A virada.** Separar o repositório de **análise** do repositório de **operação** — e aceitar a redundância como preço da pergunta rápida. O mesmo fato passa a existir em dois lugares, com dois formatos, sob duas disciplinas diferentes. Copiar dado deixou de ser sintoma de projeto malfeito e virou decisão de arquitetura.

**A ideia reaproveitável.** **Otimizar para escrever e otimizar para ler são objetivos em conflito.** Quando os dois não cabem no mesmo lugar, duplicar com disciplina é mais barato que servir mal aos dois. O padrão reaparece longe daqui: réplica de leitura, cache, índice, view materializada, *feature store*. Todos são a mesma jogada — pagar em espaço e em sincronismo para comprar tempo de resposta.

**O nome.** **Bill Inmon** é chamado "pai do data warehouse"; *Building the Data Warehouse* é de 1992.

### O debate que não terminou

E aqui está a parte mais útil desta seção, justamente por não ter vencedor.

**Inmon** defende uma arquitetura *hub-and-spoke*: um warehouse central **normalizado**, fiel ao modelo corporativo, e *data marts* dependentes a jusante, montados a partir dele para cada área. **Ralph Kimball** defende a *bus matrix*: o warehouse **inteiro** em forma dimensional, feito de marts que se ligam por **dimensões conformadas** — a mesma dimensão "cliente", com a mesma chave e o mesmo significado, usada por todos.

Repare no que os dois **concordam**: modelagem dimensional serve, e é ela que faz o cubo do [capítulo 23](23-analise-multidimensional.md) responder rápido. A discordância é sobre **onde ela entra** — no fim do caminho ou desde a porta de entrada.

Na prática, quase todo warehouse grande é **híbrido**. E o híbrido não é o fracasso de um projeto que não escolheu lado: é o sedimento de decisões tomadas por equipes diferentes, em épocas diferentes, sob restrições diferentes — a que tinha prazo e fez o mart direto; a que herdou dez fontes e precisou de uma camada normalizada para conciliá-las. Quando você chegar a uma empresa e encontrar as duas coisas convivendo, a leitura correta não é "está errado", é "aqui houve história". Sua pergunta deve ser qual restrição produziu cada pedaço, e se ela ainda vale.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ⏳ | O aperto dos anos 1980–90: consulta analítica competindo com a carga transacional na mesma máquina, a ponto de degradar a operação |
| ⏳ | A prática anterior do relatório extraído da produção em janela noturna |
| ⏳ | A virada arquitetural — separar o repositório de análise do de operação, aceitando a redundância |
| ⏳ | Bill Inmon como "pai do data warehouse" e *Building the Data Warehouse* (1992) |
| ⏳ | O conteúdo das duas posições (Inmon *hub-and-spoke* com marts dependentes; Kimball *bus matrix* com dimensões conformadas) e o acordo dos dois quanto à utilidade da modelagem dimensional. **Apurado em fontes secundárias de qualidade desigual; nenhum dos dois livros foi aberto** |
| 📖 | A ideia reaproveitável ("otimizar para escrever e otimizar para ler são objetivos em conflito") |
| 📖 | A leitura de que o warehouse híbrido é a norma e um sedimento de restrições, não um defeito de projeto |

## Fundamentos: as fontes e a ordem da transformação

Toda coleta começa escolhendo por onde o dado sai. Cinco portas cobrem quase tudo, e cada uma falha à sua maneira.

| Fonte | Como se lê | O que costuma doer |
|---|---|---|
| **Arquivo** (CSV, Excel, JSON, Parquet) | leitura direta | esquema implícito, codificação de caracteres, tudo vira texto — exceto no Parquet, que carrega tipo e colunas |
| **API** (*Application Programming Interface*) | requisições paginadas | limite de taxa, paginação e o dado **mudando entre uma página e a seguinte** |
| **Banco relacional** | SQL, de preferência numa réplica de leitura | consultar a produção é exatamente o pecado dos anos 1980 |
| **NoSQL** (documento, chave-valor, coluna, grafo) | busca por chave; o esquema mora na aplicação | o mesmo campo com dois formatos, porque duas versões do app escreveram nele |
| **Streaming** (fila ou tópico) | consumo contínuo por *offset* | entrega "ao menos uma vez" — ou seja, **duplicata é normal**, não é bug |

Escolhida a porta, resta a pergunta de ordem: transformar antes ou depois de gravar?

**ETL** (*Extract, Transform, Load*) transforma **antes** de carregar. Nasceu numa época em que armazenamento era caro: guardava-se apenas o que já estava limpo, modelado e agregado. O preço é irreversível — o que a transformação descartou não volta. Quando a regra de negócio muda, você precisa do dado bruto que jogou fora.

**ELT** (*Extract, Load, Transform*) carrega o bruto e transforma **dentro** do repositório, quase sempre em SQL. A ordem inverteu quando o armazenamento ficou barato e o motor analítico ficou forte: passou a ser mais barato guardar tudo e derivar depois do que decidir cedo o que interessa. O ganho real é poder **re-derivar** — mudou a regra, você recalcula a partir do bruto em vez de pedir uma nova extração. O preço é honesto e precisa ser dito: você paga para armazenar dado que ninguém pediu, e sem catálogo e sem dono ninguém sabe qual das dezessete tabelas `cliente` é a boa.

:::exercicio {"id":"20-e1","tipo":"completar","objetivo":"O3","dificuldade":"facil"}
Complete a sigla que nomeia a ordem adotada quando o armazenamento ficou barato — carregar o dado bruto primeiro e transformá-lo depois, dentro do próprio repositório analítico:

`Extract → Load → Transform = ______`

> **gabarito:** ELT|elt
> **porque:** No **ETL**, a transformação acontece **antes** da carga: chega ao repositório apenas o que já foi limpo, modelado e, muitas vezes, agregado — e o que ficou de fora não volta. No **ELT**, o bruto entra primeiro e as regras viram SQL dentro do repositório. A vantagem decisiva não é desempenho, é **reversibilidade**: quando a definição de "cliente ativo" mudar (e ela muda), você recalcula a partir do bruto em vez de pedir uma extração nova a um sistema que talvez nem exista mais. Não confunda a ordem com virtude: ELT sem catálogo, sem dono e sem controle de custo produz um repositório caro que ninguém confia.
> **volte para:** #fundamentos-as-fontes-e-a-ordem-da-transformacao
:::

## Onde o dado descansa: lake, warehouse, lakehouse

Os três guardam dados, e a diferença que importa é **quando o esquema é cobrado**.

| Repositório | O que aceita | Quando cobra o esquema | Perfil de custo |
|---|---|---|---|
| **Data warehouse** | dado modelado, tabular | na **escrita** — nada entra fora do formato | caro por byte, barato por pergunta |
| **Data lake** | qualquer arquivo, inclusive semiestruturado | na **leitura** — quem consulta interpreta | barato por byte, caro por pergunta |
| **Lakehouse** | arquivos, com uma camada transacional por cima | na leitura, mas **sob contrato** (esquema versionado, transação, histórico) | promete os dois; paga-se na camada de metadados e na disciplina |

O warehouse cobra caro na entrada e devolve confiança: se a linha entrou, ela está no formato combinado. O lake cobra barato na entrada e transfere o problema para quem lê — e é exatamente por isso que um lake sem catálogo vira o pântano de que todo mundo fala: não é o volume que o mata, é a **ausência de quem responda pelo significado de cada arquivo**. O lakehouse é a tentativa de ficar com os dois: arquivos abertos e baratos, mais uma camada de tabela que garante transação, evolução de esquema e viagem no tempo. Ele não elimina a decisão — apenas move o custo para a governança.

:::exercicio {"id":"20-e2","tipo":"multipla","objetivo":"O2","dificuldade":"media"}
Uma equipe precisa de duas coisas ao mesmo tempo: guardar cinco anos de eventos brutos de clique (JSON, com o esquema mudando a cada release do aplicativo) e servir trinta relatórios fixos ao financeiro, todo dia às 7h. Qual arranjo atende melhor?

- [ ] Só warehouse: modelar os eventos de clique no esquema dimensional já na entrada.
- [x] Eventos brutos no lake (esquema na leitura) e tabelas modeladas no warehouse para os relatórios, com um catálogo ligando as duas pontas.
- [ ] Só lake: byte é barato e hoje se roda SQL direto sobre os arquivos.
- [ ] Nem um nem outro: basta uma réplica de leitura do banco transacional.

> **gabarito:** Lake para o bruto, warehouse para o relatório, catálogo ligando os dois
> **porque:** As duas necessidades têm perfis de custo **opostos**, e é isso que o exercício testa. O evento de clique tem esquema instável e valor por byte baixíssimo — exigir modelagem na escrita significaria remodelar a cada release e descartar campos novos que ninguém pediu ainda. O relatório do financeiro é o inverso: mesma pergunta, todo dia, no horário — aí compensa pagar caro na entrada para ler barato depois.
>
> Por que as outras erram: "só warehouse" transforma cada mudança do app em migração de esquema. "Só lake" ignora que barato **por byte** não é barato **por pergunta** — trinta relatórios diários varrendo JSON bruto custam mais em processamento do que a modelagem que se evitou, e o lake sem catálogo perde o significado dos arquivos em poucos meses. A réplica de leitura resolve só o problema dos anos 1980 (não derrubar a operação); ela não guarda histórico que a produção já apagou nem entrega o dado modelado.
> **volte para:** #onde-o-dado-descansa-lake-warehouse-lakehouse
:::

## Integrar é mais difícil que extrair

Extrair é engenharia; integrar é semântica. Três problemas aparecem em todo projeto.

**Uma entidade, várias chaves.** O `João Silva` do início do capítulo. Quando existe uma chave forte compartilhada (CPF, CNPJ, número do contrato), use-a e acabou. Quando não existe, o casamento é **probabilístico**: normalize o texto, compare nome, data de nascimento e endereço, calcule uma pontuação de similaridade e escolha um limiar. E esse limiar não é técnico — limiar alto deixa duplicata na base, limiar baixo funde duas pessoas. Decida com quem paga a conta do erro, e **registre a regra**, porque em seis meses ninguém lembra por que dois cadastros viraram um.

**Granularidade, e o que se perde ao agregar cedo.** O grão é o fato mais fino que a tabela guarda: um item de um pedido, ou o total do dia por loja. Agregar é irreversível — quem guardou só o total diário por loja não consegue mais responder quais produtos são comprados juntos, nem qual foi o efeito de uma promoção sobre um item. A regra prática: **guarde no grão mais fino que couber no orçamento**; agregar depois é uma consulta, desagregar depois é uma coleta nova. É o mesmo grão que o cubo do [capítulo 23](23-analise-multidimensional.md) vai fatiar.

**Idempotência e reprocessamento.** Todo pipeline roda de novo — a fonte chegou atrasada, o job caiu no meio, alguém corrigiu o arquivo de ontem. Rodar duas vezes tem de produzir o mesmo estado que rodar uma. `INSERT` puro não é idempotente: reprocessar duplica o faturamento. As duas formas baratas de conseguir isso são `MERGE` por chave de negócio e **sobrescrita da partição inteira** do período reprocessado. Sem isso, o pipeline só é confiável enquanto nunca falhar — e a fila de streaming, que entrega "ao menos uma vez", garante que ele vai falhar. Monitorar essa reexecução é assunto do [capítulo 16](16-mlops.md).

### De onde veio este dado, e quem o produziu?

É a pergunta que abre o [capítulo 02](02-dados.md), e é aqui que ela nasce — porque o vazamento mais comum de todos não vem de um erro de modelagem: vem de **juntar tabelas sem respeitar o tempo**.

Uma tabela de dimensão que é atualizada no lugar (sem histórico) carrega sempre o estado de **hoje**. Um `JOIN` sem recorte temporal cola esse estado de hoje em um fato de doze meses atrás — e o modelo passa a ver, no momento da compra, uma informação que só existiu depois dela. O sintoma é sempre o mesmo: métrica excelente no teste, desempenho medíocre em produção. Por isso a procedência não é burocracia de licença — embora a licença também importe, e nenhuma base pública deva ser usada sem ler a sua. De cada coluna que entra no seu conjunto de treino, saiba responder: **quem a produz, com que frequência, e ela é sobrescrita ou versionada?** Se você não sabe, você não sabe em que instante ela passou a valer.

:::exercicio {"id":"20-e3","tipo":"aberta","objetivo":"O4","pontos":3,"dificuldade":"dificil"}
Você monta o conjunto de treino de um modelo que prevê **inadimplência no momento da compra**. Os pedidos de 2025 estão no data warehouse; o cadastro vem de outro sistema, e a tabela `clientes` é sincronizada todas as noites **sobrescrevendo** a linha do cliente.

```sql
SELECT p.pedido_id, p.data_pedido, p.valor,
       c.score_risco, c.situacao_cadastral
FROM   pedidos p
JOIN   clientes c ON c.cliente_id = p.cliente_id
WHERE  p.data_pedido BETWEEN '2025-01-01' AND '2025-12-31';
```

O modelo treinado com essa tabela alcança desempenho muito acima do esperado. Explique o que está errado e o que você faria.

> **rubrica:** identifica que `clientes` é sobrescrita e portanto o JOIN traz o estado de **hoje** para uma linha de 2025;
> reconhece que `score_risco` e `situacao_cadastral` foram produzidos **depois** do momento da decisão que o modelo deve apoiar;
> nomeia isso como vazamento e liga o desempenho alto no teste à queda esperada em produção;
> propõe ao menos uma correção concreta — dimensão versionada com validade (início/fim), snapshot datado do cadastro, ou recomputar o atributo com corte no tempo do pedido;
> faz a pergunta de procedência sobre as colunas: quem as produz, com que frequência e se são sobrescritas
> **porque:** O `JOIN` está sintaticamente correto e semanticamente errado. O `WHERE` recorta os **pedidos** no tempo, mas nada recorta o **cadastro**: cada linha de 2025 recebe o cliente como ele está agora. Um cliente que ficou inadimplente em novembro aparece como inadimplente também na compra de janeiro — o rótulo entrou disfarçado de atributo. É o vazamento do [capítulo 02](02-dados.md) na sua forma mais comum, e ele não nasce da modelagem: nasce da integração.
>
> O desempenho "muito acima do esperado" é o sinal, e vale como regra de ofício: **resultado bom demais é hipótese de vazamento até prova em contrário** — vá conferir a origem das colunas antes de comemorar.
>
> A correção estrutural é dar tempo à dimensão: guardar cada versão do cadastro com validade (`valido_de`, `valido_ate`) e juntar com `p.data_pedido BETWEEN c.valido_de AND c.valido_ate`. Onde isso não existe, sirva-se de snapshots datados do cadastro, ou recalcule o atributo a partir de eventos anteriores à data do pedido. E note o que a correção exige: alguém precisa ter decidido **guardar história** lá atrás. Por isso a pergunta de procedência é feita na coleta, não na modelagem — na modelagem já é tarde.
> **volte para:** #de-onde-veio-este-dado-e-quem-o-produziu
:::

## Síntese — o que levar

- **Otimizar para escrever e otimizar para ler são objetivos em conflito.** O warehouse nasceu de aceitar isso e duplicar com disciplina.
- Inmon e Kimball discordam de **onde** a modelagem dimensional entra, não de que ela sirva. O warehouse híbrido é a norma, não o fracasso — leia-o como sedimento de restrições, e pergunte se cada uma ainda vale.
- Cada fonte falha à sua maneira: arquivo esconde esquema, API muda entre páginas, NoSQL guarda dois formatos no mesmo campo, streaming duplica por projeto.
- ETL transforma antes e **descarta**; ELT carrega o bruto e compra **reversibilidade** — pagando em armazenamento e em governança.
- Warehouse cobra esquema na escrita (caro por byte, barato por pergunta); lake cobra na leitura (o inverso); lakehouse tenta os dois e move o custo para a governança.
- Sem chave forte, integração é casamento probabilístico com **limiar** — e limiar é decisão de negócio, que se registra.
- **Guarde no grão mais fino que couber no orçamento.** Agregar depois é uma consulta; desagregar depois é uma coleta nova.
- Reprocessar é rotina, não exceção: `MERGE` por chave ou sobrescrita de partição, nunca `INSERT` puro.
- De cada coluna: **quem produz, quando, e é sobrescrita ou versionada?** Junção sem recorte de tempo é a fábrica número um de vazamento.

## Verificação

1. Você precisa extrair 4 milhões de registros de uma API paginada que muda ao longo do dia, e a mesma entidade também existe num banco relacional de produção. Descreva como faria cada extração e o que garantiria que as duas descrevem o mesmo instante.
2. Uma diretora pergunta por que a empresa vai pagar por um data warehouse se "já existe o lake, e ele é mais barato". Responda em termos de custo por byte e custo por pergunta, com um exemplo de cada.
3. Um colega diz que o pipeline dele está correto porque "roda todo dia sem erro há seis meses". Que três perguntas você faz antes de confiar nos dados que ele entrega?

---

# 02 — Dados

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-05 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Identificar as três fontes de vazamento de dados mais comuns e como cada uma se manifesta.
- **O2.** Projetar uma divisão treino/validação/teste que respeite a estrutura temporal e de grupo dos dados.
- **O3.** Escrever uma ficha de dataset (origem, licença, limitações conhecidas) antes de treinar.
- **O4.** Diagnosticar desbalanceamento e viés de seleção a partir da própria coleta.

## O problema: o resultado bom demais

O modelo aprende o que está nos dados — inclusive o que não deveria estar.

**Vazamento de dados** (*data leakage*) é a informação que existe no treino mas **não existirá no momento da predição**. Ele produz o resultado mais perigoso do Machine Learning: o resultado bom demais.

A assinatura é sempre a mesma, e você vai reconhecê-la depois deste capítulo:

1. Alguém reporta uma métrica excelente — 0,97 de AUC num problema que ninguém resolvia.
2. Ninguém desconfia, porque a notícia é boa e desconfiar de boa notícia é socialmente caro.
3. O modelo vai a produção.
4. O número desaba, e a investigação leva semanas.

O vazamento **não dá erro**. Não aparece em log, não quebra teste, e passa por todas as revisões de código — porque não é um bug de código. É um bug de **tempo**: uma coluna que só passa a existir depois do fato que você quer prever.

> **A heurística mais útil deste livro.** Resultado surpreendentemente bom é a pista mais confiável de que algo está errado. Antes de comemorar, procure o vazamento. Se não achar, procure de novo — e só então comemore.

## De onde isto veio

**O aperto.** Fim dos anos 2000, competições públicas de mineração de dados. Empresas e universidades passaram a publicar conjuntos de dados reais e premiar quem previsse melhor — e as competições começaram a **quebrar**, uma atrás da outra: INFORMS 2010, o desafio de rede social do IJCNN 2011, a KDD-Cup 2007 sobre o dado da Netflix. Não por trapaça: por vazamento.

O caso que virou emblema é a **KDD Cup de 2008**, de detecção de câncer em mamografia. Uma das colunas era o **identificador do paciente** — um número administrativo, sem nenhum conteúdo clínico. E ele tinha **poder preditivo enorme**.

**O que se fazia antes.** Tratava-se vazamento como descuido individual: alguém esqueceu de tirar uma coluna. Cada equipe descobria o seu, contava no corredor, e não havia vocabulário comum para o fenômeno.

**A virada.** Em 2012, Kaufman, Rosset, Perlich e Stitelman publicam *"Leakage in Data Mining: Formulation, Detection, and Avoidance"* e fazem o movimento que faltava: **transformar uma coleção de acidentes numa categoria com definição, taxonomia e método de detecção.** Vazamento deixa de ser azar e passa a ser algo que se procura de propósito.

**A ideia reaproveitável — e é a que dá título a este capítulo.** **Desempenho alto demais é sintoma, não vitória.** O identificador do paciente não sabia nada sobre câncer; sabia sobre **como o hospital organizou a fila** — que exames vinham de triagem de rotina e quais de encaminhamento suspeito. Todo vazamento é a mesma coisa dita de formas diferentes: **o modelo aprendeu o processo de coleta em vez do fenômeno.** Quando você vir um número bom demais, a pergunta não é "por que meu modelo é tão bom?", é **"o que, no jeito como esses dados foram produzidos, está me entregando a resposta?"**.

**O nome.** *Leakage* — a informação "vaza" do futuro para o passado, atravessando a fronteira temporal que deveria separar o que se sabe do que se quer prever.

### As fichas de dataset, e de onde a forma foi copiada

A **ficha de dataset** que este capítulo adota tem origem declarada, e ela não vem da computação. Gebru e coautoras propuseram os *Datasheets for Datasets* (2018; versão em *CACM*, 2021) fazendo uma analogia explícita com a **indústria eletrônica**, onde todo componente vem acompanhado de uma folha de dados descrevendo características de operação, resultados de teste e usos recomendados. A proposta é literalmente: por analogia, que todo conjunto de dados venha com a sua.

**A ideia reaproveitável.** **Importar uma forma madura de outra engenharia é mais barato que inventar uma.** A eletrônica levou décadas para padronizar o que entra numa folha de dados; Machine Learning copiou o formato pronto e ganhou o atalho. Vale olhar para os lados com mais frequência: o problema que parece novo no seu campo costuma ter uma solução estabilizada em outro.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ᵐ | [Kaufman, Rosset, Perlich & Stitelman, *ACM TKDD* 6(4), art. 15, 2012](https://dl.acm.org/doi/10.1145/2382577.2382579) — obra, autoria, ano e veículo. **PDF localizado, não lido por inteiro** |
| ✓ᵐ | [Gebru *et al.*, *Datasheets for Datasets*, arXiv:1803.09010](https://arxiv.org/abs/1803.09010), 23/03/2018; versão em *CACM* 64(12), 2021. A analogia com a eletrônica está declarada no resumo |
| ⏳ | As competições citadas como gatilho (INFORMS 2010, IJCNN 2011, KDD-Cup 2007) e o caso do *Patient ID* na KDD Cup 2008 |
| ⏳ | A explicação de **por que** o identificador previa — a organização da fila do hospital. É a leitura corrente do caso; não conferida na primária |
| ❌ | **Datasets clássicos que envelheceram mal** por viés de seleção ou por questões éticas: casos existem e são citados na literatura, mas **nenhum foi verificado nesta passada**, e por isso nenhum é nomeado aqui |
| 📖 | As duas ideias reaproveitáveis |

## Fundamentos: as três fontes de vazamento

### 1. Alvo disfarçado — a coluna que só existe depois

A mais comum e a mais constrangedora. Um atributo que, na prática, é uma versão do alvo.

| Você quer prever | A coluna traiçoeira | Por que é vazamento |
|---|---|---|
| Se o cliente vai cancelar | `motivo_cancelamento` | só é preenchida **depois** do cancelamento |
| Se a transação é fraude | `valor_estornado` | o estorno acontece **após** a fraude ser detectada |
| Se o paciente tem a doença | `medicamento_prescrito` | a prescrição vem **depois** do diagnóstico |
| Se a máquina vai falhar | `data_da_manutencao_corretiva` | a corretiva é consequência da falha |

O teste é uma pergunta só, e ela precisa ser feita **para cada coluna**:

> No instante exato em que eu preciso fazer a predição, este valor já existe e já está preenchido?

Se a resposta for "não" ou "depende", a coluna sai. Fazer essa pergunta coluna a coluna parece burocracia até a primeira vez que ela salva um projeto.

### 2. Pré-processamento antes da divisão — o vazamento silencioso

Este é sutil, quase universal entre iniciantes, e não tem sintoma visível.

```python
# ERRADO — e ninguém percebe olhando
X = normalizar(X)                              # usa média e desvio de TUDO
treino, teste = dividir(X)                     # tarde demais

# CERTO
treino, teste = dividir(X)
media, desvio = ajustar_normalizador(treino)   # aprende SÓ no treino
treino = aplicar(treino, media, desvio)
teste  = aplicar(teste,  media, desvio)        # aplica o que veio do treino
```

Na versão errada, a média usada para normalizar o treino **contém informação dos exemplos de teste**. O modelo nunca viu as linhas do teste, mas viu uma estatística delas — e isso basta para inflar a métrica.

Vale para tudo que "aprende" alguma coisa dos dados: normalização, imputação de ausentes, seleção de atributos, codificação por alvo (*target encoding*), redução de dimensionalidade. A regra é única e não tem exceção:

> **Tudo que aprende dos dados aprende só do treino.** O teste é aplicado, nunca consultado.

O efeito costuma ser pequeno — décimos de ponto. É justamente por isso que é perigoso: pequeno demais para levantar suspeita, grande o bastante para decidir qual modelo vai a produção.

### 3. Duplicata entre conjuntos — o modelo que já viu a prova

Se o mesmo exemplo, ou um quase-idêntico, aparece nos dois lados da divisão, o teste deixou de medir generalização e passou a medir memória.

Acontece mais do que se imagina:

- **Duplicatas exatas** na base (o mesmo registro importado duas vezes).
- **Quase-duplicatas**: o mesmo cliente em dois meses, a mesma notícia republicada, a mesma foto redimensionada.
- **Múltiplas linhas do mesmo sujeito**: dez transações de um cliente, cinco exames de um paciente, vinte sensores da mesma máquina.

O terceiro caso é o que mais engana, porque não parece duplicata — são linhas genuinamente diferentes. Mas se o modelo aprende a reconhecer *o cliente* em vez de *o comportamento*, ele vai bem no teste e mal com clientes novos, que é a única coisa que importa.

:::exercicio {"id":"02-e1","tipo":"multipla","objetivo":"O1","dificuldade":"media"}
Uma equipe prevê inadimplência em 30 dias. O modelo atinge 0,96 de AUC — três vezes melhor que qualquer tentativa anterior. Entre os atributos está `dias_de_atraso_atual`. Qual é a leitura mais provável?

- [ ] O modelo é excelente; `dias_de_atraso_atual` é de fato um bom preditor.
- [x] Vazamento: quem já está em atraso hoje quase por definição estará inadimplente, e essa coluna não existe no momento em que a decisão precisa ser tomada.
- [ ] Overfitting: o modelo decorou o treino.
- [ ] A AUC está alta porque a base é desbalanceada.

> **gabarito:** Vazamento
> **porque:** Aplique o teste da coluna: *no instante em que preciso decidir, este valor já existe?* Se a decisão é conceder crédito **antes** de haver qualquer atraso, então `dias_de_atraso_atual` é zero para todo mundo naquele instante — e o valor que apareceu no treino veio de um momento posterior ao que se quer prever. O modelo aprendeu "quem está atrasado vai ficar inadimplente", que é verdade e é inútil.
>
> Note por que **overfitting** é a resposta errada mais tentadora: overfitting produz treino bom e validação ruim. Aqui a validação também está ótima — porque a coluna vazada está nos dois lados. Vazamento e overfitting têm assinaturas opostas, e confundi-los manda a investigação para o lado errado.
> **volte para:** #1-alvo-disfarcado-a-coluna-que-so-existe-depois
:::

:::exercicio {"id":"02-e2","tipo":"multipla-multi","objetivo":"O1","dificuldade":"dificil"}
Quais destas práticas introduzem vazamento? (marque todas que valem)

- [x] Preencher valores ausentes com a mediana calculada sobre o dataset inteiro, antes de dividir.
- [x] Selecionar os 20 atributos mais correlacionados com o alvo usando todos os dados, e só depois dividir.
- [ ] Fixar a *seed* do embaralhamento antes de dividir.
- [x] Aplicar *target encoding* numa categórica usando as médias calculadas sobre treino e teste juntos.
- [ ] Usar validação cruzada em vez de uma única divisão.

> **gabarito:** imputação antes do split · seleção de atributos antes do split · target encoding sobre tudo
> **porque:** As três corretas são a mesma falha com três roupas: **algo aprendeu dos dados de teste antes de o teste ser usado para medir**. A mediana carrega a distribuição do teste; a seleção de atributos usa a correlação com o alvo do teste; o *target encoding* embute a média do alvo do teste dentro de uma coluna de entrada — este último é o mais grave dos três, porque injeta o próprio alvo.
>
> As duas erradas são higiene, não vazamento. Fixar a *seed* torna a divisão reprodutível, o que é exigência do Princípio II. E validação cruzada não vaza *por si só* — ela vaza se o pré-processamento for feito fora do laço, que é exatamente o mesmo erro de novo, só que repetido em cada dobra.
> **volte para:** #2-pre-processamento-antes-da-divisao-o-vazamento-silencioso
:::

## A divisão que respeita a estrutura dos dados

Embaralhar e cortar é o padrão — e está errado sempre que os dados têm estrutura. Duas estruturas importam.

### Tempo: nunca embaralhe uma série

Se você quer prever o futuro, **treine no passado e teste no futuro**. Embaralhar uma série temporal permite que o modelo treine com dados de dezembro para prever junho, o que é uma máquina do tempo que produção não terá.

```
❌ embaralhado:  [J F M A M J J A S O N D]  →  treino e teste misturados
✅ temporal:     [J F M A M J J A S] treino  [O N D] teste
```

E há um detalhe que quase todo mundo esquece: o **intervalo de guarda**. Se você prevê 30 dias à frente, os últimos 30 dias do treino contêm informação que se sobrepõe ao início do teste. Descarte-os. Perder um mês de treino é barato; descobrir em produção que a métrica era otimista, não.

### Grupo: o mesmo sujeito não pode estar nos dois lados

Se a base tem várias linhas por cliente, paciente ou máquina, a divisão é **por sujeito**, não por linha. Todas as linhas do cliente 4711 vão para o treino, ou todas vão para o teste — nunca umas em cada.

A pergunta que decide isso é: **o que vai ser novo em produção?** Se o sistema vai atender clientes que ele nunca viu, o teste precisa conter clientes que o treino nunca viu. Se ele vai atender os mesmos clientes de sempre em situações novas, aí a divisão por linha é defensável — mas essa decisão precisa ser **declarada**, não herdada do `train_test_split` padrão.

### E a estratificação

Preservar a proporção de classes nos três conjuntos. Barato, quase sempre certo, e imprescindível quando a classe positiva é rara: sem ela, o teste pode acabar com um punhado de positivos e a métrica vira loteria — o problema que o [capítulo 04](04-avaliacao.md) trata com intervalo de confiança.

**Atenção à ordem de precedência.** Quando há tempo *e* grupo *e* desbalanceamento, tempo manda. Não se estratifica uma série temporal: forçar a proporção de classes no futuro é assumir que você já sabe qual será ela — e essa é a coisa que você está tentando descobrir.

:::exercicio {"id":"02-e3","tipo":"multipla","objetivo":"O2","dificuldade":"dificil"}
Um hospital quer prever readmissão em 30 dias. A base tem 50.000 internações de 12.000 pacientes, coletadas ao longo de 4 anos. O sistema vai atender pacientes que chegam pela primeira vez. Qual divisão é a correta?

- [ ] Embaralhar as 50.000 internações e dividir 70/15/15, estratificando pelo alvo.
- [ ] Dividir por paciente, embaralhando os 12.000 e separando 70/15/15.
- [x] Dividir por tempo (treino nos primeiros anos, teste no último) **e** garantir que nenhum paciente apareça em dois conjuntos.
- [ ] Usar validação cruzada de 5 dobras sobre as internações, que é mais robusta que uma divisão única.

> **gabarito:** Dividir por tempo e por paciente, simultaneamente
> **porque:** Há **duas** estruturas aqui, e ignorar qualquer uma delas invalida a medição.
>
> **Tempo**, porque protocolos clínicos, população e prática mudam em 4 anos: treinar com 2026 para prever 2023 é uma máquina do tempo. **Paciente**, porque um mesmo paciente tem várias internações — e um modelo que aprende a reconhecer *aquele paciente* vai bem no teste e falha justamente no caso de uso declarado, que é o paciente novo.
>
> As alternativas 1 e 2 acertam uma estrutura e ignoram a outra. A alternativa 4 é a armadilha mais elegante: validação cruzada é de fato mais robusta contra ruído amostral, mas robustez não conserta viés — cinco dobras embaralhadas erradas dão uma estimativa errada com um intervalo de confiança estreito, que é pior do que uma estimativa errada e obviamente incerta.
>
> Na prática, a divisão correta custa dados: pacientes do último período que já apareciam antes precisam sair de um dos lados. Esse custo é real e vale a pena.
> **volte para:** #a-divisao-que-respeita-a-estrutura-dos-dados
:::

## A ficha de dataset

Antes de treinar, escreva uma página sobre os dados. Não é burocracia: é o único momento em que alguém olha para a origem em vez de olhar para as colunas.

A prática vem de *Datasheets for Datasets* (Gebru et al.) e este livro adota uma versão mínima, de sete perguntas:

| # | Pergunta | Por que importa |
|---|---|---|
| 1 | **Quem coletou, quando e para quê?** | dado coletado para outro fim carrega o viés daquele fim |
| 2 | **Como um exemplo entrou na base?** | é aqui que mora o viés de seleção |
| 3 | **Qual é a licença?** | uso comercial pode ser proibido, e ninguém descobre isso tarde de graça |
| 4 | **Há dado pessoal?** | se há, ou anonimiza ou não entra (Princípio V) |
| 5 | **Como o alvo foi rotulado?** | rótulo humano tem taxa de erro; rótulo automático tem a regra que o gerou |
| 6 | **O que se sabe que está errado?** | toda base tem defeitos conhecidos; não registrá-los é fingir que não existem |
| 7 | **Quando expira?** | população, comportamento e instrumentação mudam |

A pergunta 5 merece um parágrafo. Se o alvo foi rotulado por uma regra automática, **o modelo vai aprender a regra, não o fenômeno** — e o teto de desempenho dele é a qualidade daquela regra. É comum descobrir, tarde, que "fraude" na base significa "o que o sistema antigo marcou como fraude", e que o modelo novo foi treinado para imitar o velho.

## O viés de seleção: aprender com quem já está lá

O desbalanceamento é o problema fácil: uma classe é rara, e o [capítulo 04](04-avaliacao.md) já mostrou como medir sem se enganar.

O problema difícil é o **viés de seleção** — quando a forma como os exemplos entraram na base não representa a população em que o modelo vai operar.

O caso clássico e cruel: um banco quer prever inadimplência e treina com o histórico dos **clientes a quem concedeu crédito**. Mas quem recebeu crédito passou por um filtro — o modelo antigo, ou o gerente. Os dados não contêm os que foram recusados, e são exatamente esses que o novo modelo precisa avaliar. O sistema aprende sobre uma população que já foi filtrada por ele mesmo, e fica cada vez mais confiante sobre uma fatia cada vez mais estreita do mundo.

Isso tem nome — *feedback loop* — e o [capítulo 15](15-sistemas-de-ml.md) trata das consequências arquiteturais. Aqui basta o diagnóstico e o gesto mínimo: **reservar uma fração pequena de decisões aleatórias**, fora da recomendação do modelo, para manter a base honesta. Custa dinheiro. É o preço de continuar aprendendo.

:::exercicio {"id":"02-e4","tipo":"aberta","objetivo":"O3","pontos":3,"dificuldade":"media"}
Você recebeu uma base de 200.000 avaliações de produtos, rotuladas como "positiva" ou "negativa", para treinar um classificador de sentimento. O rótulo foi gerado automaticamente: avaliações de 4–5 estrelas viraram "positiva", de 1–2 estrelas viraram "negativa", e as de 3 estrelas foram descartadas.

Escreva as **três perguntas mais importantes** que você faria antes de treinar, e diga o que cada resposta mudaria na sua decisão.

> **rubrica:** questiona o rótulo automático e o teto que a regra de geração impõe;
> nota que descartar as 3 estrelas remove justamente os casos ambíguos, inflando a métrica;
> levanta ao menos uma questão de origem, licença ou representatividade da base;
> cada pergunta vem acompanhada do que a resposta mudaria — não é uma lista solta de dúvidas
> **porque:** As três mais valiosas costumam ser estas. **Primeira:** o rótulo é a estrela, não o sentimento — e as duas coisas divergem (elogio com nota baixa por causa da entrega, ironia, avaliação de 5 estrelas com reclamação no texto). O modelo terá como teto a qualidade dessa correspondência.
>
> **Segunda, e a mais fácil de deixar passar:** descartar as 3 estrelas remove exatamente os casos difíceis. O classificador vai parecer excelente no teste — que também não tem casos difíceis — e vai encontrá-los todos em produção. É desbalanceamento invertido: a base ficou mais fácil que o mundo.
>
> **Terceira:** de onde vêm as avaliações, quem escreve avaliação (quem teve experiência extrema, tipicamente), e se a licença permite o uso pretendido.
>
> O critério de "o que a resposta mudaria" é o que separa curiosidade de investigação. Uma pergunta cuja resposta não muda nada é uma pergunta que não precisava ser feita.
> **volte para:** #a-ficha-de-dataset
:::

## Mão na massa

A **etapa 02** do [`ml-zero`](../trilha-ml-zero.md) implementa o que este capítulo argumenta, em biblioteca padrão pura:

1. `detectar_vazamento_obvio` — procura colunas suspeitas de serem o alvo disfarçado, por correlação quase perfeita e por preenchimento condicionado ao alvo;
2. `dividir_por_grupo` — garante que nenhum sujeito apareça em dois conjuntos;
3. `dividir_por_tempo` — corte temporal **com intervalo de guarda**;
4. `checar_duplicatas` — exatas e quase-exatas entre conjuntos;
5. `FichaDeDataset` — as sete perguntas como estrutura executável, que falha se ficarem sem resposta.

O item 5 é o mais incomum e o mais útil: a ficha não é um documento que alguém promete escrever, é um objeto que o pipeline recusa se estiver incompleto.


**Notebook pronto para executar** — [`vazamento.ipynb`](https://github.com/GHDaru/machinelearning/blob/main/ml-zero/etapa-02/vazamento.ipynb) · [abrir no Colab](https://colab.research.google.com/github/GHDaru/machinelearning/blob/main/ml-zero/etapa-02/vazamento.ipynb)

Os três vazamentos, em execução: a coluna que sabe demais, a divisão que respeita grupos e a que respeita o tempo. Traz de brinde a razão de o exemplo ter 200 linhas e não 10 — **com poucas linhas qualquer coluna separa perfeitamente por acaso**, e o detector acusaria todas.

> Na sua máquina: `pip install notebook` e `jupyter notebook`, ou abra a pasta no VS Code. O notebook **não precisa do repositório clonado** — se você estiver no Colab, ele baixa sozinho os arquivos de que precisa. Como rodar a trilha inteira: [`ml-zero`](https://github.com/GHDaru/machinelearning/blob/main/ml-zero/README.md).

## Assista

:::video {"id":"02-v1","fonte":"youtube","ref":"fSytzGwwBVw","min":6,"autor":"StatQuest with Josh Starmer","titulo":"Machine Learning Fundamentals: Cross Validation"}
O texto acima argumenta *por que* a divisão precisa respeitar a estrutura; este vídeo mostra a **mecânica** de dividir e de rodar validação cruzada, com os blocos se movendo na tela. Vale como base concreta antes do exercício 02-e3 — e repare, enquanto assiste, que a animação assume dados sem estrutura temporal nem de grupo. É o caso mais simples, e é por isso que ele é o mais ensinado.
:::

## Síntese — o que levar

- **Resultado bom demais é pista de vazamento**, não motivo de comemoração.
- Faça a pergunta da coluna, uma por uma: *no instante da predição, este valor já existe?*
- **Tudo que aprende dos dados aprende só do treino.** Normalização, imputação, seleção, *target encoding*.
- Divisão respeita a estrutura: **tempo manda sobre grupo, que manda sobre estratificação**.
- Escreva a ficha antes de treinar. A pergunta 5 — como o alvo foi rotulado — é a que mais surpreende.
- Sua base tem o viés do filtro que a criou. Se o filtro foi o próprio sistema, o problema se agrava sozinho.

## Verificação

1. Explique a diferença entre vazamento e overfitting em termos das assinaturas que cada um deixa nas curvas de treino e validação.
2. Você tem 3 anos de transações de 5.000 lojas e quer prever venda da próxima semana. Descreva a divisão e justifique cada decisão.
3. Um colega diz: "normalizei tudo antes de dividir, mas o efeito é minúsculo, não muda nada". O que você responde?

---

# 21 — Análise Exploratória

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Calcular e interpretar medidas de tendência central e dispersão.
- **O2.** Escolher a medida adequada à distribuição — e detectar quando a média engana.
- **O3.** Formular hipóteses a partir de padrões observados, sem confirmá-las nos mesmos dados.
- **O4.** Identificar outliers e decidir, com critério declarado, o que fazer com eles.

## O problema: a rua em que ninguém ganha a média

Sete moradores de uma rua ganham entre 3 e 6 mil reais por mês. O oitavo ganha 400 mil.

A renda **média** da rua é 52 mil. O número está aritmeticamente correto e não descreve morador nenhum: não existe uma única pessoa perto dele. Um relatório que diga "renda média de R$ 52 mil" está tecnicamente certo e comunicacionalmente falso.

Antes de modelar, **olhe**. É a etapa que quase todo mundo pula e quase todo mundo lamenta ter pulado. A análise exploratória não é um relatório bonito: é a etapa em que você descobre que 30% da coluna de renda está zerada, que existem três grafias para a mesma cidade, e que o pico de vendas de março era um erro de importação. E o detalhe cruel é que **o modelo não reclama**: ele treina em cima do erro de importação, aprende o padrão errado e devolve uma métrica plausível. Quem tinha de reclamar era você, antes.

## De onde isto veio

**O aperto.** Início dos anos 1960. A estatística acadêmica havia se tornado quase sinônimo de **inferência formal**: testar, com rigor matemático, uma hipótese previamente formulada. Havia teoria elegante para a pergunta *"esse efeito é real?"* — e nenhum lugar legítimo para a etapa anterior, a de **olhar o dado antes de saber o que perguntar**.

**O que se fazia antes.** Ou se testava uma hipótese, ou não se estava fazendo estatística. Examinar os números sem hipótese na mão era, na melhor das hipóteses, uma preliminar informal que não entrava no artigo.

**A virada.** John Tukey nomeia **análise de dados** como disciplina própria — da qual a inferência é *um* componente, não o todo. É uma jogada de definição antes de ser técnica: uma vez que a exploração tem nome e estatuto, ela pode ter método. E aí vêm as ferramentas: o **boxplot**, o **stem-and-leaf**, e o hábito que atravessa tudo — preferir medidas **resistentes** a valores extremos.

**A ideia reaproveitável.** **Antes de testar a resposta, é preciso ter permissão para procurar a pergunta.** Um campo que só valoriza a etapa confirmatória fica cego para a etapa que *gera* a hipótese — e, pior, empurra essa etapa para a informalidade, onde ela acontece assim mesmo, só que sem método e sem registro. Vale muito além da estatística: teste automatizado só verifica o que alguém pensou em perguntar; nenhuma suíte verde descobre a pergunta que ninguém fez.

**O nome.** *Exploratory* opõe-se explicitamente a *confirmatory* — a dupla é dele, e **o par é o argumento**. Batizar a exploração sozinha seria dar nome a um hábito; com o par, vira divisão de trabalho: uma fase produz hipóteses, a outra as julga — e não se faz as duas com os mesmos dados.

| Quando | O quê |
|---|---|
| **1962** | ["The Future of Data Analysis"](https://www.stat.berkeley.edu/~brill/Papers/jwtencyc.pdf), nos *Annals of Mathematical Statistics* — o manifesto |
| **entre 1962 e 1977** | O material circula em cerca de três edições mimeografadas e pelas mãos dos alunos dele |
| **1977** | *Exploratory Data Analysis*, Addison-Wesley — [o livro](https://www.stat.berkeley.edu/~brill/Papers/EDASage.pdf) que virou a referência do assunto |

Repare no intervalo: **quinze anos** entre o manifesto e o livro. É o mesmo formato de 1943→1958 no [capítulo 18](18-neuronio-artificial.md) (neurônio → perceptron) e de 1927→1970 no [capítulo 24](24-series-temporais.md). **O intervalo é o conteúdo**: a ideia precisou de mais de uma década, de três rodadas de material mimeografado e de uma geração de alunos para deixar de ser heresia e virar cadeira de graduação. Tukey ainda reaparece na pré-história da validação cruzada ([capítulo 01](../01-fundamentos.md)) — a mesma intuição, aplicada a outro problema: não julgue com o dado que já foi usado para escolher.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ᵐ | O aperto do início dos anos 1960 (a estatística acadêmica identificada à inferência formal) e a virada de Tukey — análise de dados como disciplina, com boxplot, *stem-and-leaf* e resistência |
| ✓ᵐ | A cronologia 1962 (*Annals of Mathematical Statistics*) → ~3 edições mimeografadas → 1977 (Addison-Wesley), pelas duas fontes ligadas acima — **localizadas, não lidas por inteiro** |
| ⏳ | Que, antes disso, "ou se testava uma hipótese, ou não se estava fazendo estatística" |
| ⏳ | Que o par *exploratory* / *confirmatory* é dele |
| ⏳ | A participação de Tukey na pré-história da validação cruzada (Mosteller & Tukey, 1968) |
| ⏳ | O quarteto de Anscombe (1973) e os valores citados adiante — atribuição corrente; primária não consultada |
| 📖 | A ideia reaproveitável ("permissão para procurar a pergunta") e a leitura do intervalo de 15 anos como padrão recorrente deste livro |

## Fundamentos: a média mente, a mediana aguenta

Volte à rua: `3, 3, 4, 4, 5, 6, 6, 400` (em milhares). A **média** é 52,1. A **mediana** — o valor que deixa metade dos dados de cada lado — é 4,5. A diferença não é de precisão, é de natureza: a média usa o *valor* de cada ponto, então um único extremo a arrasta sem limite; a mediana usa só a *posição*, e trocar o 400 por 4 milhões a deixa em 4,5. Isso se chama **resistência**, e é a propriedade que Tukey pôs no centro do método.

O mesmo par existe para dispersão:

| Pergunta | Distribuição simétrica, sem extremos | Assimétrica ou com extremos |
|---|---|---|
| Onde é o centro? | média | **mediana** |
| Quanto varia? | desvio-padrão | **IQR** (intervalo interquartil) = Q3 − Q1 |
| Que forma tem? | histograma | histograma **e** boxplot |

O desvio-padrão eleva as diferenças ao quadrado — o que dá ao ponto extremo um voto elevado ao quadrado. O IQR é a largura da faixa que contém os 50% centrais: ignora, por construção, as duas caudas.

**Como ler um boxplot.** A caixa vai de Q1 a Q3 (é o IQR), e o traço dentro dela é a mediana. Os "bigodes" se estendem até o ponto mais distante que ainda esteja dentro de 1,5 × IQR a partir da borda da caixa; o que sobra é desenhado como ponto individual. Três leituras saem de bater o olho: **onde está o centro**, **quão espalhado** é o meio dos dados, e **se a mediana está descentrada dentro da caixa** — sinal de assimetria.

**Assimetria é a regra, não a exceção.** Renda, tempo de resposta de API, valor de compra, número de sessões por usuário: quase tudo que tem piso em zero e não tem teto forma uma **cauda longa** à direita. Nessas distribuições, média > mediana sempre, e reportar a média é reportar a cauda.

:::exercicio {"id":"21-e1","tipo":"numerica","objetivo":"O1","dificuldade":"facil"}
Os salários mensais (em milhares de reais) de sete funcionários de uma equipe são:

`3, 3, 4, 4, 5, 6, 40`

Qual é a **mediana** desse conjunto?

> **gabarito:** 4
> **porque:** Os valores já estão ordenados e são sete — ímpar. A mediana é o valor da posição central, a quarta: **4**. Não há conta a fazer; há uma posição a contar.
>
> Compare com a **média**: (3+3+4+4+5+6+40)/7 = 65/7 ≈ **9,3**. Seis dos sete funcionários ganham *menos* que a média, e nenhum ganha algo próximo dela. O salário de 40 puxa a média em mais de cinco unidades e não move a mediana em nada — se ele fosse 400, a média iria a 60,7 e a mediana continuaria 4.
>
> O erro mais comum aqui é dividir a soma por sete por reflexo, sem reparar no enunciado. O segundo é ordenar errado quando a lista vem embaralhada: mediana **exige** ordenação. Com número par de elementos, é a média dos dois centrais.
> **volte para:** #fundamentos-a-media-mente-a-mediana-aguenta
:::

## Correlação: o que ela mede e o que ela não prova

A correlação de Pearson resume, num número entre −1 e 1, o quanto duas variáveis andam juntas **em linha reta**. As duas palavras finais são a armadilha inteira: uma relação forte e curva — um U perfeito, por exemplo — pode dar correlação próxima de zero. Correlação zero não significa "não há relação"; significa "não há relação *linear*".

O argumento definitivo contra confiar no número sem ver o gráfico é o **quarteto de Anscombe** (1973): quatro conjuntos de onze pontos cada, com médias, variâncias, correlação (≈ 0,816) e reta de regressão **praticamente idênticas** — e formas completamente diferentes quando plotados. Um é uma nuvem linear honesta; outro é uma curva perfeita; outro é uma reta com um ponto fora; o último é uma coluna de pontos e um único ponto distante que sozinho cria a correlação. Mesmo resumo numérico, quatro histórias.

E depois há a frase que todo mundo sabe repetir e quase ninguém aplica na hora certa: **correlação não é causalidade**. Diante de uma correlação forte, há sempre quatro explicações concorrentes, e só uma delas é a que você quer:

1. **A causa é a que você pensou** (X causa Y).
2. **A causa é a inversa** (Y causa X) — comum em dados operacionais: clientes com mais chamados de suporte cancelam mais, ou clientes prestes a cancelar abrem mais chamados?
3. **Há um confundidor** que causa as duas — o clássico: venda de sorvete e afogamentos sobem juntos porque é verão.
4. **É coincidência amostral** — teste 200 pares de variáveis e algumas parecerão correlacionadas por acaso.

Há ainda um quinto caso, específico de quem constrói modelos: **correlação altíssima com o alvo costuma ser vazamento**, não sorte. Se uma coluna prevê o alvo quase perfeitamente, a primeira hipótese não é "achei o atributo de ouro", é "essa coluna foi preenchida *depois* do desfecho" — o [capítulo 02](02-dados.md) trata disso.

:::exercicio {"id":"21-e2","tipo":"multipla","objetivo":"O2","dificuldade":"media"}
Duas colunas de um mesmo relatório têm média, desvio-padrão e correlação entre si praticamente idênticas às de outro par de colunas. Que conclusão é legítima?

- [ ] As duas relações têm a mesma forma; os resumos numéricos determinam o gráfico.
- [x] Nenhuma: resumos iguais são compatíveis com formas radicalmente diferentes — só o gráfico decide.
- [ ] Como a correlação é a mesma, um modelo linear serve igualmente bem nos dois casos.
- [ ] Se a correlação for alta nos dois casos, ambos os pares têm relação causal.

> **gabarito:** Nenhuma conclusão sobre a forma — é preciso ver o gráfico
> **porque:** É exatamente o que o quarteto de Anscombe demonstra: quatro conjuntos com médias, variâncias, correlação e reta de regressão iguais, e gráficos que não se parecem em nada. O resumo numérico comprime; e toda compressão descarta — a questão é sempre *o quê*.
>
> A terceira alternativa é a mais sedutora e a mais perigosa, porque a correlação é de fato o que a regressão linear otimiza. Só que num dos conjuntos de Anscombe a relação é uma **curva**: a reta ajustada tem os mesmos coeficientes e está sistematicamente errada em todo ponto. Em outro, a correlação inteira é produto de **um** ponto distante — remova-o e ela desaparece.
>
> A última confunde correlação com causalidade, e a primeira inverte a direção da inferência: o gráfico determina quais resumos fazem sentido, nunca o contrário.
> **volte para:** #correlacao-o-que-ela-mede-e-o-que-ela-nao-prova
:::

> **Um conjunto para praticar isto.** [`ml-zero/dados/limonada/`](../../ml-zero/dados/limonada/README.md) traz 365 dias de venda com um caso limpo do que esta seção afirma: `preco` correlaciona **+0,513** com as vendas, e o que essa correlação mede é o mês de julho. A exploração que revela isso é uma linha — `df.groupby("preco")[["temperatura","vendas"]].mean()` — e ela precede qualquer modelo. O desdobramento está no [capítulo 05](05-modelos-lineares.md#o-caso-da-limonada).

## Faltantes, outliers e a fronteira entre explorar e confirmar

**Faltantes.** A pergunta útil nunca é "como preencho?", é **"por que falta?"**. Falta ao acaso (o sensor caiu numa terça) é um problema de imputação. Falta por mecanismo (renda alta declarada com menos frequência) enviesa qualquer preenchimento pela média. E falta com significado — um campo que só existe para quem comprou — é vazamento disfarçado de ausência. Antes de qualquer `dropna()`, conte os faltantes **por coluna e por subgrupo**: um faltante concentrado numa região, num período ou num canal é sinal de processo quebrado, não de dado ausente.

**Outliers.** Um ponto extremo é uma de três coisas, e a única forma de decidir é olhar a linha inteira:

| O que é | Exemplo | O que fazer |
|---|---|---|
| **Erro de medida** | idade = 999, preço = −1 | corrigir ou remover, registrando quantos |
| **Evento raro legítimo** | a compra de R$ 400 mil que de fato aconteceu | manter; usar medida resistente ou transformação |
| **O próprio alvo** | a transação fraudulenta, a falha do equipamento | **jamais** remover — é o que você quer prever |

A regra de 1,5 × IQR do boxplot **marca candidatos, não decide nada**. Decidir exige critério declarado por escrito: o que foi removido, por qual regra, quantas linhas, e o que acontece com o resultado se a regra mudar. "Limpei os outliers" não é descrição de método; é a ausência de uma.

**E a fronteira.** Se você olha quarenta gráficos e escolhe o padrão mais forte, você não achou o efeito mais forte: achou o **extremo do ruído** — a coincidência amostral do item 4 acima, agora garimpada de propósito. É a armadilha que a dupla de Tukey existe para prevenir. A regra prática é simples e barata: **separe uma parte dos dados antes de começar a olhar** e não a toque; explore no resto à vontade; escreva a hipótese **antes** de testá-la na parte guardada. Explorar produz candidatas; confirmar exige dado que não participou da escolha. Fazer as duas coisas no mesmo conjunto é o mesmo erro que o [capítulo 04](04-avaliacao.md) combate quando o limiar é escolhido no teste.

O produto legítimo de uma boa exploração não é uma conclusão — é uma **lista de hipóteses ordenada por quanto valeria confirmá-las**, mais uma lista de problemas de dado a consertar. Transformar essa lista em gráfico que convence é o [capítulo 22](22-visualizacao-storytelling.md).

:::exercicio {"id":"21-e3","tipo":"aberta","objetivo":"O4","pontos":3,"dificuldade":"media"}
Você explora a base de vendas de uma rede de lojas e encontra 12 pedidos (de 400 mil) com valor acima de R$ 500 mil — a mediana dos pedidos é R$ 180. O modelo a treinar prevê o valor do próximo pedido de um cliente.

Escreva o que você faz com esses 12 pedidos: **como decide** e **o que registra**.

> **rubrica:** investiga a origem de cada ponto antes de decidir, em vez de aplicar uma regra automática;
> distingue explicitamente erro de medida, evento raro legítimo e alvo de interesse;
> propõe um critério declarado e reprodutível (regra escrita, contagem de linhas afetadas), não "limpei os outliers";
> considera o efeito da decisão sobre a métrica e sobre a escolha entre média e mediana;
> menciona documentar a decisão para quem for reproduzir ou revisar
> **porque:** Doze pontos em 400 mil não se resolvem por regra: resolvem-se **olhando as doze linhas**. Elas podem ser erro de digitação (um zero a mais), venda corporativa legítima (outro processo de negócio, que talvez mereça modelo próprio) ou fraude — e cada diagnóstico leva a uma ação diferente. O boxplot marca os candidatos; quem decide é quem conhece o processo que gerou o dado.
>
> O que separa uma resposta boa de uma correta é o **registro**. "Removi outliers acima de 500 mil (12 linhas, 0,003% da base, 4,1% da receita)" é método: qualquer pessoa reproduz, e a segunda frase já mostra que apagar 12 linhas apagou 4% da receita — o que provavelmente inviabiliza a remoção. "Limpei os outliers" não é reproduzível nem auditável.
>
> Repare no efeito colateral que quase sempre escapa: se as vendas corporativas ficam, o alvo é fortemente assimétrico, e otimizar erro quadrático médio faz o modelo perseguir a cauda. A decisão sobre outliers e a escolha da métrica são a **mesma** decisão tomada duas vezes.
> **volte para:** #faltantes-outliers-e-a-fronteira-entre-explorar-e-confirmar
:::

## Síntese — o que levar

- **Sempre olhe antes de modelar.** O modelo não avisa que a coluna está zerada; ele aprende o erro e devolve uma métrica plausível.
- Média usa o **valor** de cada ponto; mediana usa a **posição**. Por isso a mediana resiste a extremos e a média não.
- Distribuição assimétrica ou com extremos: **mediana + IQR**. Simétrica e limpa: média + desvio-padrão.
- O boxplot entrega centro, dispersão e assimetria numa olhada — e a regra de 1,5 × IQR **marca candidatos, não decide**.
- Resumo numérico comprime. O quarteto de Anscombe é a prova de que estatísticas idênticas convivem com gráficos irreconhecíveis.
- Diante de uma correlação forte, enumere as quatro explicações antes de escolher a sua — e desconfie de correlação altíssima com o alvo: costuma ser vazamento. Faltante também tem **causa**, e descobri-la vale mais que preenchê-lo.
- Explorar gera hipóteses; confirmar exige dado que não participou da exploração. Separe a parte guardada **antes** de olhar.

## Verificação

1. Um relatório diz "ticket médio de R$ 340". Que três perguntas você faz antes de usar esse número numa decisão?
2. Duas colunas têm correlação de 0,9. Liste as explicações possíveis e diga, para cada uma, que evidência adicional a distinguiria das demais.
3. Você encontrou, explorando, um padrão forte num segmento de clientes. Descreva o que precisa acontecer antes de esse padrão virar uma afirmação na apresentação para a diretoria — e por que a mesma pessoa que criou o boxplot também se preocupava com validação cruzada.

---

# 22 — Visualização e Storytelling

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Escolher o tipo de gráfico adequado à pergunta e ao tipo de variável.
- **O2.** Identificar distorções visuais que induzem a conclusões erradas.
- **O3.** Construir uma narrativa de dados com começo, tensão e recomendação.
- **O4.** Adaptar a mesma análise para públicos técnico e executivo.

## O problema: quando o gráfico não muda nada

Uma análise que ninguém entende não muda decisão nenhuma — e uma análise que não muda decisão nenhuma não valeu o custo.

O [capítulo 21](21-analise-exploratoria.md) é olhar para **descobrir**: você desenha vinte gráficos feios, para si mesmo, e joga dezenove fora. Este capítulo é outra coisa: mostrar para **convencer**. O público é outro, o tempo de atenção é outro, e o erro também é outro. Lá o risco era não ver o padrão; aqui o risco é o leitor ver um padrão que não existe — e decidir com base nele. O [capítulo 25](25-do-modelo-a-decisao.md) é onde a decisão acontece de fato; este é a ponte.

Visualização é interface. Como toda interface, ela pode ser honesta ou pode enganar — inclusive sem que ninguém tenha querido enganar.

## De onde isto veio

**O aperto.** Fim do século XVIII. O comércio internacional cresce, os governos precisam acompanhá-lo, e os números existem em um único formato: **tabelas**. William Playfair — engenheiro e economista político escocês — queria algo que a tabela não dava: que um leitor apreendesse uma tendência de décadas **de relance**, sem somar coluna nenhuma.

**O que se fazia antes.** Tabela de números, lida linha a linha. Para comparar dois anos, o leitor fazia a subtração de cabeça; para ver uma tendência de trinta anos, fazia trinta.

**A virada.** Usar **posição** e **comprimento** para representar quantidade. Se a quantidade vira distância no papel, comparar deixa de ser aritmética e vira percepção. Dessa ideia saem o gráfico de linhas e o de barras — os dois nascem ali.

**A ideia reaproveitável — e é o achado deste capítulo: uma restrição de dados pode gerar uma forma nova.** O atlas de Playfair é feito de séries temporais: 34 pranchas de importação e exportação ao longo dos anos, todas em linha. Mas para a **Escócia** ele tinha os dados de **um único ano (1781)**. Sem eixo do tempo não há linha a traçar. A saída foi desenhar 34 **barras**, uma para cada sentido do comércio com 17 parceiros. Beniger & Robyn resumem: *"Playfair was driven to this invention by a lack of data"*. Ou seja: **a barra não é uma linha simplificada — é a resposta a uma pergunta que a linha não podia responder.** Guarde isso, porque é a razão de o próximo tópico existir: cada forma responde a um tipo de pergunta, e usar a forma errada é responder outra coisa.

É o mesmo padrão do [capítulo 18](18-neuronio-artificial.md) — McCulloch e Pitts fazem um neurônio **sem aprendizado** porque não havia como treinar — e do [capítulo 23](23-analise-multidimensional.md), onde o cubo OLAP pré-computa porque a consulta era lenta demais. Restrição material gera forma nova; e a forma sobrevive à restrição que a criou.

**O nome.** *The Commercial and Political Atlas*, 1786 (com uma edição preliminar privada em 1785). O próprio Playfair explicou por que insistia: *"As the knowledge of mankind increases, and transactions multiply, it becomes more and more desirable to abbreviate and facilitate the modes of conveying information."*

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ᵐ | Playfair, *The Commercial and Political Atlas* (1786; edição preliminar privada em 1785), e a invenção do gráfico de linhas e do de barras |
| ⏳ | Que antes disso o padrão fosse a tabela lida linha a linha |
| ⏳ | A citação de Beniger & Robyn (1978), *"driven to this invention by a lack of data"*, tomada de [friendly.github.io/HistDataVis](https://friendly.github.io/HistDataVis/ch05-playfair.html) — fonte secundária que cita a primária; **não conferida** em Beniger & Robyn |
| ⏳ | A frase do próprio Playfair — citada de forma consistente em várias secundárias; **não conferida** na edição de 1786 |
| 📖 | A leitura de que "uma restrição de dados pode gerar uma forma nova", e o paralelo com os capítulos 18 e 23 |

## Fundamentos: a pergunta escolhe o gráfico

Não se escolhe gráfico por gosto nem por variedade. Escolhe-se pela pergunta que ele responde.

| A pergunta | A forma | Por quê |
|---|---|---|
| **Comparação** — quem é maior? | barra | comprimento a partir de uma base comum é o que o olho compara melhor |
| **Evolução** — para onde está indo? | linha | a inclinação vira tendência, sem esforço |
| **Distribuição** — como os valores se espalham? | histograma, boxplot | mostra forma, cauda e assimetria, que a média esconde |
| **Relação** — X anda junto com Y? | dispersão | dois eixos, um ponto por observação |
| **Composição** — de que isto é feito? | barra empilhada; pizza **às vezes** | só vale quando as partes somam um todo com significado |

O **boxplot** dessa tabela é de Tukey, e é o mesmo do [capítulo 21](21-analise-exploratoria.md) — lá como ferramenta de descoberta, aqui como forma de comunicar espalhamento sem despejar a base inteira na tela.

### Por que a pizza quase sempre perde

A pizza codifica quantidade em **ângulo** (e área). A barra codifica em **comprimento**. O olho humano compara comprimentos com precisão e ângulos com dificuldade: numa pizza de seis fatias parecidas, quase ninguém acerta a ordem — e ordenar é justamente a pergunta mais comum.

A regra prática: a pizza só se sustenta com **duas ou três** categorias, quando o todo importa mais que a ordem ("dois terços da receita vêm de um produto"). Fora disso, use barra. E nunca ponha pizza em 3D com fatia destacada: a perspectiva aumenta a área das fatias da frente, ou seja, o enfeite muda o número lido.

:::exercicio {"id":"22-e1","tipo":"multipla","objetivo":"O1","dificuldade":"media"}
Você quer mostrar **como o tempo de resposta da API se espalha** entre as requisições — se há cauda longa, onde estão os piores casos. Qual forma responde a essa pergunta?

- [ ] Um gráfico de pizza com a fatia de cada faixa de tempo.
- [ ] Um gráfico de barras com o tempo **médio** de resposta por dia.
- [x] Um histograma (ou boxplot) dos tempos de resposta.
- [ ] Um gráfico de linhas do tempo médio ao longo da semana.

> **gabarito:** Histograma ou boxplot
> **porque:** A pergunta é de **distribuição** — "como os valores se espalham" —, e só histograma e boxplot mostram forma, cauda e assimetria. Latência quase sempre tem cauda longa: a média fica confortável e o percentil 99 é o que derruba o usuário.
>
> As duas alternativas com **média** (barra por dia, linha na semana) são o erro mais comum e o mais caro: elas respondem "quanto, em geral" e "para onde está indo", que são perguntas de comparação e de evolução — e a média é exatamente a estatística que apaga a cauda que você foi procurar. A pizza é a pior de todas: fatiar o tempo em faixas transforma uma variável contínua em composição, e ainda entrega a comparação ao ângulo, que o olho lê mal.
> **volte para:** #fundamentos-a-pergunta-escolhe-o-grafico
:::

## Como um gráfico mente sem dizer uma mentira

Nenhum dos truques abaixo falsifica um número. Todos mudam a conclusão.

**Eixo Y truncado.** Comece o eixo em 97 em vez de 0 e uma queda de 3% vira um despenhadeiro. O leitor não lê a escala — lê a **altura da barra**. Como o comprimento é o que codifica a quantidade, cortar a base quebra a codificação: as barras deixam de ser proporcionais ao que representam. Regra: **barra sempre parte do zero**; linha pode não partir, porque nela o que codifica é a inclinação, não o comprimento — mas o corte precisa estar visível e declarado.

**Área por raio.** Ao dobrar o valor, dobrar o raio de um círculo quadruplica a área. O leitor lê a área. Um crescimento de 2× vira 4×.

**Excesso de tinta.** Grades pesadas, sombras, gradientes, 3D, ícones decorativos: tinta que não carrega informação. Ela não só polui — ela compete com o dado pela atenção, e às vezes vence.

**Cor sem propósito.** Cor é para **destacar** (uma série importa, o resto é cinza), para **ordenar** (escala contínua clara→escura) ou para **categorizar** (poucas cores distintas). Escolher paleta arco-íris para dados ordenados inventa fronteiras que não existem. E cerca de um em cada doze homens tem alguma forma de daltonismo: **nunca use verde/vermelho como o único sinal** de bom/ruim — acrescente forma, posição ou rótulo. Um gráfico que só funciona colorido também não funciona impresso em preto e branco.

:::exercicio {"id":"22-e2","tipo":"aberta","objetivo":"O2","pontos":3,"dificuldade":"dificil"}
Um gerente leva à diretoria um gráfico de **barras** com a satisfação do cliente nos últimos quatro trimestres: 88,1 · 88,4 · 88,9 · 89,2. O eixo Y começa em **88** e termina em **89,5**. Não há nota de rodapé. O título é "Satisfação do cliente". Na tela, a última barra tem cerca de **onze vezes** a altura da primeira, e a diretoria aprova mais verba para o programa.

Julgue o gráfico: o que está errado, por que engana, e como você o refaria.

> **rubrica:** identifica o eixo Y truncado como o problema central;
> explica que em barra o comprimento codifica a quantidade, então cortar a base torna as barras não proporcionais aos valores;
> observa que a variação real é pequena (cerca de 1,1 ponto, ~1%) e que a impressão visual (~11×) não corresponde a ela;
> propõe uma correção concreta — barra a partir do zero, ou trocar por linha com o corte de escala declarado e visível;
> menciona o título como parte do problema ou da solução (rótulo em vez de conclusão), ou aponta a ausência de contexto (meta, margem de erro, série mais longa)
> **porque:** Nenhum número foi falsificado — e é isso que torna o caso instrutivo. O engano está na **codificação**. Numa barra, a quantidade é o comprimento medido a partir de uma base comum; ao começar o eixo em 88, o comprimento passa a representar "quanto excede 88", que não é a grandeza do título. Daí a distorção: 1,1 ponto de variação real vira uma diferença visual de cerca de onze vezes.
>
> A correção mínima é a base zero — e note o efeito: com o eixo do zero, as quatro barras ficam praticamente idênticas, que é a verdade do dado. Se a variação pequena for genuinamente relevante (satisfação move-se devagar), a saída honesta não é truncar em silêncio: é trocar para **linha**, onde o codificador é a inclinação, com a escala declarada, mais a meta e a série histórica para dar referência. E vale reparar no título: "Satisfação do cliente" é rótulo dos dados, não conclusão — ele delega ao gráfico distorcido o trabalho de afirmar o que o autor não escreveu. Um título que dissesse "Satisfação subiu 1,1 ponto em um ano" teria denunciado o próprio gráfico.
> **volte para:** #como-um-grafico-mente-sem-dizer-uma-mentira
:::

## O gráfico que decide

Um gráfico de exploração pode ter cinco leituras. Um gráfico de apresentação tem **uma mensagem** — e o resto é ruído a remover.

Daí a regra mais barata e mais ignorada deste capítulo: **o título é a conclusão, não o rótulo dos dados.** Troque "Vendas por região" por **"Vendas caíram 30% no Sul"**. O primeiro obriga cada pessoa da sala a descobrir sozinha o que ver, e cinco pessoas descobrem cinco coisas. O segundo diz o que você viu — e assume a responsabilidade por ter dito.

A narrativa que sustenta o gráfico tem quatro tempos:

1. **Contexto** — o que era normal até aqui.
2. **Tensão** — o que mudou, e por que isso não pode continuar.
3. **Evidência** — o gráfico, com a mensagem no título.
4. **Recomendação** — o que fazer, com o custo e o risco de não fazer.

E a mesma análise se conta de dois jeitos, sem mudar de conclusão. Para o **time técnico**: metodologia, incerteza, o que foi descartado, os dados feios. Para a **diretoria**: a recomendação primeiro, um gráfico, o custo — e o resto no apêndice, disponível para quem pedir. Mudar a ordem e o nível de detalhe é adaptação; mudar a conclusão conforme a plateia é outra coisa, e tem outro nome.

Às vezes a melhor visualização é **nenhuma**: quando a resposta é um número só ("o churn foi de 4,1%"), o gráfico só adiciona tinta.

:::exercicio {"id":"22-e3","tipo":"completar","objetivo":"O3","dificuldade":"facil"}
Complete a regra do título num gráfico de apresentação:

`O título de um gráfico que decide deve ser a ______, e não o rótulo dos dados.`

> **gabarito:** conclusão|conclusao|mensagem
> **porque:** O título é o único elemento que todo mundo na sala lê — inclusive quem não vai olhar os eixos. Gastá-lo com "Vendas por região" desperdiça a única linha garantida do slide e transfere ao público o trabalho de interpretar; "Vendas caíram 30% no Sul" entrega a leitura já feita.
>
> Há um efeito colateral útil: quando você é obrigado a escrever a conclusão no título, descobre se o gráfico realmente a sustenta. Se não sai um título afirmativo, ou o gráfico está errado, ou você ainda não sabe o que achou. É o mesmo teste do slide: se o slide tem duas mensagens, são dois slides.
> **volte para:** #o-grafico-que-decide
:::

## Síntese — o que levar

- A forma segue a **pergunta**: comparação → barra; evolução → linha; distribuição → histograma/boxplot; relação → dispersão; composição → às vezes pizza, quase sempre barra.
- A **barra de Playfair nasceu de uma falta de dados** — um só ano, sem eixo do tempo. Restrição material gera forma nova, aqui como no [18](18-neuronio-artificial.md) e no [23](23-analise-multidimensional.md).
- **Comprimento se compara melhor que ângulo.** É a razão técnica de a barra vencer a pizza quase sempre.
- **Barra parte do zero.** Eixo truncado não falsifica número nenhum e ainda assim muda a conclusão — é a distorção mais comum e a mais fácil de flagrar.
- Tinta sem informação compete com o dado. Cor tem três empregos (destacar, ordenar, categorizar) e nunca deve ser o **único** sinal — daltonismo e impressão em cinza.
- Um gráfico de apresentação tem **uma** mensagem, e ela vai no **título**. Rótulo de dados terceiriza a conclusão para a plateia.
- Explorar (cap. 21) é para você; comunicar (este) é para quem decide (cap. 25). Muda o público, muda o gráfico — não a conclusão.

## Verificação

1. Um diretor pede "um gráfico das vendas". Que perguntas você faz antes de escolher a forma — e como cada resposta muda a escolha?
2. Pegue um gráfico de um jornal ou relatório desta semana. Ele trunca algum eixo, codifica quantidade em área, ou usa cor sem propósito? O que muda na conclusão se você corrigir?
3. Reescreva três títulos de gráficos que você já viu, transformando rótulo em conclusão. Em qual deles o gráfico **não** sustentava a conclusão que você quis escrever?
4. Conte o mesmo achado duas vezes: em três minutos para a diretoria e em quinze para o time técnico. O que entra em cada uma — e o que não pode mudar entre as duas?

---

# 03 — Representação

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Explicar por que a escolha de representação limita o que qualquer modelo pode aprender.
- **O2.** Aplicar codificação adequada a variáveis categóricas de alta e baixa cardinalidade.
- **O3.** Justificar quando normalizar e quando não faz diferença nenhuma.
- **O4.** Construir atributos a partir de conhecimento de domínio e medir se eles pagaram.

## O problema: o modelo só vê o que você mostrou

Um modelo não vê o mundo: vê os números que você escolheu mostrar a ele. Essa escolha — a **representação** — determina o teto de qualquer algoritmo que venha depois. Nenhuma quantidade de otimização recupera informação que não foi codificada.

O exemplo canônico é a data. Como inteiro (`1721692800`), ela é quase inútil: o modelo teria de descobrir sozinho que o mundo se repete a cada 604 800 segundos. Decomposta em dia da semana, hora do dia e proximidade de feriado, ela frequentemente carrega a maior parte do sinal. **O dado é o mesmo.** O que mudou foi o que o modelo consegue enxergar.

É por isso que este capítulo vem antes dos modelos, e não depois. Trocar de algoritmo é barato; descobrir que a informação nunca esteve na tabela é caro.

## De onde isto veio

**O aperto.** Anos 1950, Universidade da Pensilvânia. **Zellig Harris** queria uma linguística que partisse **só do corpus** — dos textos observáveis —, sem apelar para intuição de significado nem para dicionário. A influência declarada era a teoria da informação de Shannon. O aperto: *significado* parecia ser exatamente aquilo que não se pode medir.

**O que se fazia antes.** Significado descrito por definição, introspecção ou autoridade lexicográfica. Nada disso é observável, e nada disso é computável.

**A virada.** Em **1954**, no artigo *"Distributional Structure"*, Harris mostra como induzir o sentido de palavras como *oculist*, *eye-doctor* e *lawyer* a partir da **sobreposição dos ambientes** em que ocorrem: as duas primeiras aparecem quase nos mesmos contextos, a terceira só em parte deles. Diferença de sentido vira **diferença de distribuição observável**. É a **hipótese distribucional**, e é a fundação conceitual de tudo o que hoje se chama *embedding*.

**A ideia reaproveitável — e ela vale muito além de texto.** **Representar não é descrever a coisa: é registrar a companhia que a coisa mantém.** Não existe "o vetor do cliente"; existe o vetor do cliente **em relação ao conjunto**. É isso que faz *one-hot*, TF-IDF e *embedding* pertencerem a um capítulo só: todos trocam a essência do item pela **posição dele numa coleção**. Mude a coleção e a representação muda, sem que o item tenha mudado nada.

**O nome.** A frase que carrega a ideia é de **J. R. Firth (1957)**: *"You shall know a word by the company it keeps"* — e ele a usa para um modo específico de significado, o *"meaning by collocation"*, buscando as colocações habituais em que a palavra está mais caracteristicamente incrustada.

> ### O terceiro caso, e o mais desconfortável
>
> **Harris tinha o argumento.** Dezessete páginas de definições formais e exemplos trabalhados, em 1954. **Firth tinha a frase**, três anos depois. E todo mundo cita Firth.
>
> É a terceira vez que este livro tropeça no mesmo padrão. No [capítulo 05](05-modelos-lineares.md), Gauss descobre os mínimos quadrados e Legendre leva a prioridade por ter publicado. No [capítulo 18](18-neuronio-artificial.md), Linnainmaa descreve a retropropagação e Rumelhart leva o crédito por ter popularizado. Aqui, o argumento inteiro é de um e a citação é do outro.
>
> **O que circula não é a contribuição: é a forma citável da contribuição.** Isso não é cinismo, é instrução prática — se você quer que a sua ideia seja usada, ela precisa caber numa frase que alguém consiga repetir. A frase não substitui o argumento; ela é o veículo dele.

### Cinquenta e nove anos entre a ideia e o procedimento

A hipótese distribucional é de **1954**. O **word2vec** — Mikolov, Chen, Corrado e Dean — é de **janeiro de 2013**, com a regularidade que ficou famosa: *rei − homem + mulher ≈ rainha*.

São **cinquenta e nove anos**, um dos maiores intervalos registrados neste livro — maior que os 43 de Yule → Box–Jenkins ([capítulo 24](24-series-temporais.md)) e que os 43 de Larson → Stone ([capítulo 01](../01-fundamentos.md)). No meio do caminho, a linha vetorial foi sendo construída: **1972**, Karen Spärck Jones mostra que **especificidade é estatística, não semântica** — pesa-se o termo pela raridade na coleção; **1973**, Salton e Yang multiplicam a frequência do termo por aquela fórmula e batizam o resultado de *idf*; **1975**, o modelo de espaço vetorial é formalizado no sistema SMART, em Cornell.

Repare no detalhe do TF-IDF: **ela inventou, eles nomearam.** O padrão de novo.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ | Que Harris parte do corpus sob influência declarada de Shannon, e a frase de Firth com o sentido de *meaning by collocation* — via [Brunila & LaViolette (2022), arXiv:2205.07750](https://arxiv.org/pdf/2205.07750), **lido**, que faz leitura cerrada dos dois originais |
| ✓ᵐ | Harris, *"Distributional Structure"*, *Word* 10(2–3), 1954, e o exemplo *oculist* / *eye-doctor* / *lawyer*. **O artigo original não foi aberto** (paywall) |
| ✓ᵐ | Spärck Jones (*Journal of Documentation* 28:11–21, 1972); Salton, Wong & Yang (*CACM* 18:613–620, 1975); Mikolov *et al.* ([arXiv:1301.3781](https://arxiv.org/abs/1301.3781), 16/01/2013) |
| ✓ᵐ | Suits, *"Use of Dummy Variables in Regression Equations"*, *JASA* 52:548–551, 1957 — e que o próprio Suits diz que a técnica **não era nova**; o que faltava era expor o procedimento, inclusive a restrição obrigatória |
| ⏳ | Que Salton & Yang (1973) batizaram o "idf" a partir da fórmula de Spärck Jones |
| ⏳ | Que "one-hot" vem de circuito digital, onde a única combinação legal é um bit alto — não localizei o primeiro uso datado |
| 📖 | A ideia reaproveitável, a leitura sobre a "forma citável" e a contagem dos 59 anos |

## Fundamentos: as três decisões

Toda representação responde a três perguntas, e errar qualquer uma custa mais que trocar de modelo.

### 1. Categórica: quantos valores diferentes existem?

Para **baixa cardinalidade** (cor, estado civil, região — dezenas de valores), o **one-hot** é o padrão: uma coluna por valor, com 1 na coluna correspondente e 0 nas demais.

O nome vem do circuito digital, onde a única combinação válida é ter exatamente um bit alto. Em estatística a mesma técnica é a **variável dummy**, e ela é bem mais velha: Daniel Suits a expôs em 1957 — dizendo, aliás, que já não era nova.

> **A armadilha das dummies tem 69 anos e continua sendo a primeira em que o aluno pisa.** Se você criar uma coluna para **cada** valor **e** mantiver o intercepto, as colunas somam exatamente 1 em toda linha — informação perfeitamente redundante. Numa regressão isso torna a solução indeterminada. A regra é: **omita uma categoria, ou tire o intercepto.** Nunca os dois, nunca nenhum.

Para **alta cardinalidade** (CEP, código de produto, ID de usuário — milhares de valores), one-hot explode: você ganha dez mil colunas quase vazias e um modelo que decora. As saídas são agrupar por frequência (tudo que aparece pouco vira "outros"), codificar pelo alvo — com um cuidado que o [capítulo 02](02-dados.md) já explicou —, ou aprender um **embedding**.

> **Codificação pelo alvo é vazamento esperando acontecer.** Substituir a categoria pela média do alvo naquela categoria usa a resposta como entrada. Se a média for calculada com o dado inteiro, você vazou. Calcule **só no treino**, e por dobra.

### 2. Numérica: a escala importa?

Depende inteiramente do modelo, e essa é a resposta que quase ninguém dá.

| Modelo | Normalizar muda? | Por quê |
|---|---|---|
| Regressão com gradiente | **muito** | escalas díspares deformam a paisagem e a descida ziguezagueia ([cap. 06](06-otimizacao.md)) |
| Regularização L1/L2 | **muito** | a penalidade compara coeficientes; sem escala comum, ela pune o atributo de unidade pequena |
| k-NN, k-means, SVM | **muito** | dependem de distância, e distância soma unidades diferentes |
| Árvores e ensembles | **nada** | cada corte olha **um** atributo por vez, e a ordem não muda com escala ([cap. 07](07-arvores-ensembles.md)) |

A consequência prática é útil: se o seu pipeline normaliza antes de um *random forest*, você não fez mal — fez trabalho à toa, e adicionou uma peça que pode quebrar.

### 3. Domínio: que atributo não está lá?

É aqui que o conhecimento de negócio entra, e onde o ganho costuma ser maior. Razões em vez de valores absolutos (*ticket* médio em vez de total e contagem separados), diferenças temporais (dias desde a última compra), agregações por grupo (gasto do cliente sobre a média da região dele).

**E medir se pagou.** Atributo novo se justifica por experimento, não por plausibilidade: mesma divisão, mesmo protocolo, e a diferença comparada com o ruído ([cap. 25](25-do-modelo-a-decisao.md)).

:::exercicio {"id":"03-e1","tipo":"multipla","objetivo":"O3","dificuldade":"media"}
Você treina um *random forest* para prever inadimplência. Um colega revisa o código e sugere padronizar todos os atributos numéricos (média 0, desvio 1) antes do treino, "porque é boa prática". O que acontece com o desempenho?

- [ ] Melhora, porque as árvores comparam atributos entre si.
- [ ] Piora, porque a padronização destrói a informação de escala que as árvores usam.
- [x] Fica praticamente igual — a árvore escolhe cortes dentro de um atributo por vez, e a ordem dos valores não muda.
- [ ] Melhora só se houver atributos com unidades muito diferentes.

> **gabarito:** Fica praticamente igual
> **porque:** Uma árvore avalia cortes do tipo "atributo *j* ≤ *v*". Padronizar é uma transformação **monotônica** dentro de cada atributo: ela muda os valores, mas **não muda a ordem** deles — e portanto não muda quais divisões dos exemplos são possíveis. O corte que separava os mesmos exemplos antes continua separando os mesmos depois.
>
> A segunda alternativa é o erro simétrico e vale desmontar: a árvore **não usa** escala como informação. Ela nunca compara um atributo com outro na mesma conta — é justamente essa indiferença que a torna cômoda para tabela com unidades misturadas.
>
> Lição prática: normalizar antes de uma floresta não é errado, é **inútil** — e código inútil no pipeline é código que pode quebrar, que precisa ser mantido, e que confunde quem vier depois. "Boa prática" sem a condição em que ela vale é superstição.
> **volte para:** #2-numerica-a-escala-importa
:::

:::exercicio {"id":"03-e2","tipo":"numerica","objetivo":"O2","dificuldade":"facil"}
Uma variável categórica `regiao` tem 5 valores possíveis. Você vai usá-la numa **regressão linear com intercepto**.

Quantas colunas *dummy* você deve criar para evitar a indeterminação?

> **gabarito:** 4
> **porque:** Com 5 colunas — uma por região — a soma delas dá exatamente 1 em toda linha, que é precisamente o que a coluna do intercepto já vale. Uma das colunas é combinação linear perfeita das outras mais o intercepto, e o sistema deixa de ter solução única: infinitos conjuntos de coeficientes produzem exatamente as mesmas previsões.
>
> Omitindo uma categoria, ela vira a **referência**, e cada coeficiente passa a significar "o efeito desta região **em relação à** referência". Isso não é uma perda: é o que torna o coeficiente interpretável.
>
> A regra geral é **k − 1** colunas para k categorias, quando há intercepto. Sem intercepto, use as k. E note que isso **não vale** para árvores ou para modelos regularizados, onde a redundância não impede a solução — mais um caso em que a resposta certa depende do modelo, não da variável.
> **volte para:** #1-categorica-quantos-valores-diferentes-existem
:::

## O artesanato mudou de lugar, não desapareceu

A promessa do aprendizado de representações — o contraponto moderno, formulado por Bengio, Courville e Vincent em 2013 — é **aprender** a representação em vez de fabricá-la à mão. Em texto e imagem, a promessa se cumpriu de forma espetacular: ninguém mais escreve detector de borda à mão ([cap. 10](10-visao.md)).

Mas em **dado tabular** — a maior parte do trabalho real de empresa — o artesanato continua, e continua decidindo o resultado.

**E mesmo onde a promessa se cumpriu, ela mudou o artesanato de lugar em vez de eliminá-lo.** Quem monta o corpus decide o que conta como *contexto*; quem define a janela de um *embedding* decide o que é "companhia"; quem escolhe o que entra na tabela decide o que existe. É exatamente o trabalho que Harris fazia à mão em 1954, com outra ferramenta.

:::exercicio {"id":"03-e3","tipo":"aberta","objetivo":"O4","pontos":3,"dificuldade":"media"}
Uma rede de farmácias quer prever quais clientes vão abandonar o programa de fidelidade nos próximos 90 dias. A tabela disponível tem uma linha por cliente com: `cpf`, `data_cadastro`, `cidade`, `total_gasto_historico`, `numero_de_compras`.

Proponha **três atributos novos** construídos a partir dessas colunas ou de dados que você pediria, justifique cada um pela hipótese de negócio, e descreva como mediria se eles pagaram.

> **rubrica:** propõe ao menos um atributo de **razão ou média** (ticket médio = total gasto / número de compras) em vez de usar só valores absolutos;
> propõe ao menos um atributo **temporal** (dias desde a última compra, ou frequência recente contra frequência histórica) e reconhece que a data da última compra não está na tabela e precisa ser pedida;
> justifica cada atributo por uma hipótese de negócio explícita, não por "costuma ajudar";
> descreve uma medição comparativa com protocolo — mesma divisão, mesmo modelo, com e sem os atributos;
> menciona a incerteza da comparação, ou o risco de vazamento ao construir atributo temporal
> **porque:** A resposta fraca lista transformações genéricas. A resposta forte percebe duas coisas.
>
> **Primeira:** `total_gasto_historico` e `numero_de_compras` juntos escondem o **ticket médio**, e ticket médio distingue dois clientes que a tabela crua confunde — quem gastou R\$ 5 000 em 200 compras é um cliente de rotina; quem gastou o mesmo em 3 compras é outra pessoa, com outro motivo para sair. A razão carrega informação que nenhuma das duas colunas carrega sozinha.
>
> **Segunda, e é a que separa:** a tabela **não tem a data da última compra**, e sem ela quase não há como prever abandono — recência é o sinal mais forte que existe para esse problema. Perceber a **ausência** vale mais que propor dez transformações do que está presente. É a lição de abertura do capítulo: o modelo só vê o que você mostrou, e informação que não foi coletada nenhum algoritmo recupera.
>
> Sobre a medição: comparar com e sem os atributos exige o protocolo do [capítulo 25](25-do-modelo-a-decisao.md) — mesma divisão, mesmo orçamento de busca, e a diferença confrontada com o ruído. E todo atributo temporal precisa ser calculado **na data de corte** de cada exemplo, nunca com o histórico completo, sob pena do vazamento do [capítulo 02](02-dados.md).
> **volte para:** #3-dominio-que-atributo-nao-esta-la
:::

## Síntese — o que levar

- O modelo **só vê o que você mostrou**. A representação define o teto; nenhuma otimização recupera informação não codificada.
- **Representar é registrar a companhia que a coisa mantém**, não descrever a coisa. Muda a coleção, muda a representação.
- Categórica de **baixa** cardinalidade: one-hot, com **k − 1** colunas se houver intercepto. De **alta**: agrupe, codifique pelo alvo com cuidado, ou aprenda um *embedding*.
- **Codificação pelo alvo calculada fora do treino é vazamento.**
- Normalizar importa para gradiente, regularização e distância; **não importa** para árvores.
- Atributo de domínio costuma pagar mais que troca de modelo — e se justifica por **experimento**, não por plausibilidade.
- A hipótese distribucional tem **setenta anos**; o *embedding* é a realização computacional dela.
- O *deep learning* **mudou o artesanato de lugar**, não o eliminou: alguém ainda decide o que conta como contexto.

## Verificação

1. Por que uma data como inteiro é quase inútil para a maioria dos modelos, e o que exatamente a decomposição em dia da semana e hora do dia acrescenta?
2. Você tem uma coluna com 8 000 códigos de produto distintos. Descreva duas estratégias de codificação e diga em que situação escolheria cada uma.
3. A hipótese distribucional afirma que o sentido está na companhia. Dê um exemplo, fora de texto, em que representar um item pelo contexto funciona melhor que representá-lo pelos atributos próprios.

---

# 04 — Avaliação

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-01 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

> **Capítulo-piloto do esqueleto v4.** É aqui que o formato do livro foi validado antes de ser exigido dos demais — como o cap. 04 foi o piloto do livro de Engenharia de Harness, e pela mesma razão: avaliação é o assunto em que a diferença entre "achar que entendeu" e "entender" aparece mais rápido.

## Objetivos de aprendizagem

- **O1.** Explicar por que acurácia é enganosa sob desbalanceamento de classes.
- **O2.** Calcular e interpretar precisão, revocação e F1 a partir de uma matriz de confusão.
- **O3.** Escolher a métrica adequada a partir do **custo do erro** no problema, e não por hábito.
- **O4.** Distinguir a qualidade do *ranking* (AUC) da qualidade da *decisão* (limiar), e explicar por que calibração é uma terceira coisa.
- **O5.** Reportar uma métrica com incerteza, em vez de um ponto.

## O problema: 99,7% de acurácia sem modelo nenhum

Uma operadora de cartões pede um detector de fraude. A base tem 0,3% de transações fraudulentas. A equipe treina, mede, e reporta com orgulho: **99,5% de acurácia**.

O número é verdadeiro e é inútil. Um "modelo" de uma linha — `return "não é fraude"` — atinge 99,7%. A equipe entregou algo **pior que a ausência de modelo**, e a métrica escolhida escondeu isso atrás de dois noves.

Este capítulo é sobre não deixar isso acontecer. E o mecanismo do erro não é matemático — é de processo: **a métrica foi escolhida depois do modelo**, por hábito, em vez de antes, a partir do custo do erro.

### A linha de base que você precisa bater

Antes de qualquer métrica sofisticada, calcule o que um classificador trivial atinge:

- **Classificação**: sempre a classe majoritária.
- **Regressão**: sempre a média (ou a mediana) do treino.
- **Séries temporais**: repetir o último valor observado. Essa costuma ser surpreendentemente difícil de bater.

Se o modelo não bate a linha de base, ele não tem valor — independentemente de quantos dígitos a acurácia tenha. Registre esse número no início do projeto e mantenha-o visível em todo relatório. É o gesto mais barato de higiene metodológica que existe, e o mais frequentemente pulado.

:::exercicio {"id":"04-e1","tipo":"multipla","objetivo":"O1","dificuldade":"facil"}
Numa base de detecção de fraude com 0,3% de casos positivos, um modelo atinge 99,5% de acurácia no teste. Qual leitura é correta?

- [ ] O modelo é excelente: erra menos de 1 caso em 200.
- [x] O número não diz quase nada: prever "não é fraude" para tudo já daria 99,7%.
- [ ] A acurácia não pode ser usada em problemas binários.
- [ ] O modelo é bom, mas precisaria de mais dados para confirmar.

> **gabarito:** O número não diz quase nada
> **porque:** Com 0,3% de positivos, a classe majoritária sozinha entrega 99,7% de acurácia. O modelo com 99,5% está **abaixo** do classificador que não faz nada — ele está, na prática, destruindo valor. Acurácia mede a fração de acertos totais; quando uma classe domina, ela mede sobretudo a **prevalência**, não a competência do modelo. Note que a alternativa "não pode ser usada em problemas binários" é falsa e revela outro mal-entendido: acurácia é perfeitamente válida quando as classes são equilibradas e os dois tipos de erro custam o mesmo. O problema não é a métrica; é usá-la fora da condição em que ela informa.
> **volte para:** #a-linha-de-base-que-voce-precisa-bater
:::

## De onde isto veio

Este capítulo tem um nome estranho no meio dele — **curva ROC**, "característica de operação do receptor". Receptor de quê? A resposta explica a métrica inteira.

**O aperto.** Segunda Guerra Mundial, estações de radar britânicas e americanas. Um operador olha uma tela e vê um borrão. Aquilo é um bombardeiro inimigo, um navio amigo, uma revoada de pássaros, ou ruído do próprio aparelho? Ele tem segundos para decidir, e **os dois erros matam**: deixar passar um bombardeiro custa uma cidade; disparar o alarme à toa esgota a defesa e, repetido, faz os alarmes serem ignorados.

**O que se fazia antes.** Conta-se que a qualidade do operador e do equipamento era medida por **uma taxa de acerto** — quantas detecções corretas num turno — e que daí apareceu o problema que este capítulo inteiro persegue: **um operador nervoso, que apertasse o botão em quase tudo, teria taxa de detecção excelente.** O número subiria; a defesa pioraria. (Esta narrativa é a corrente na literatura didática de detecção de sinal; não a conferimos em fonte da época — ver a tabela ao fim da seção.)

**A virada.** Perceber que detecção e falso alarme **não são dois defeitos independentes: são as duas pontas de um mesmo botão.** Segundo a versão corrente, o receptor de radar tinha um controle de **ganho** — girá-lo para cima fazia aparecer mais alvos verdadeiros *e* mais fantasmas; para baixo, limpava a tela *e* escondia bombardeiros. Não existia posição sem custo. Então pare de medir um ponto e **meça a curva inteira**: para cada posição do botão, quanto se detecta e quanto se alarma à toa. Essa curva é a característica de operação do receptor.

**A ideia reaproveitável — e é a maior deste capítulo.** **O limiar não é propriedade do modelo; é a decisão de quem assume as consequências.** No radar isso era literal: havia um botão, e girá-lo trocava um tipo de erro por outro. Um modelo entrega um *ranking*; transformá-lo em decisão exige alguém dizer quanto custa cada erro. Nenhum valor de limiar é "o certo" sem essa conversa — e quando o cientista de dados escolhe o limiar sozinho, ele não está fazendo uma escolha técnica: está tomando, calado, uma decisão que era de outra pessoa.

**O nome.** *Receiver Operating Characteristic* é literalmente a característica de operação daquele receptor de rádio. O gráfico como o usamos vem do trabalho pós-guerra em teoria da detecção de sinal (Peterson & Birdsall, 1953; Peterson *et al.*, 1954), e chega à psicologia por Tanner e Swets — de onde migra para a medicina, a meteorologia e, por fim, para cá.

> **Por que a história importa na prática.** Quem sabe que a ROC nasceu de um botão físico nunca mais confunde *"o modelo é bom"* com *"o limiar está certo"*. São duas perguntas, e só a primeira é técnica.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ⏳ | A origem no radar da Segunda Guerra e o controle de ganho ajustável pelo operador — consistente entre fontes secundárias; **nenhuma primária da época foi aberta** |
| ⏳ | Peterson & Birdsall (1953), Peterson *et al.* (1954) e a passagem por Tanner e Swets |
| ⏳ | O caso do operador com alta taxa de detecção por excesso de alarme — narrado de forma consistente na literatura didática de detecção de sinal |
| 📖 | A ideia reaproveitável ("o limiar é decisão de quem assume as consequências") e a leitura de que escolher limiar calado é tomar decisão alheia |

## Fundamentos: a matriz de confusão e o que dela deriva

Toda métrica de classificação binária nasce de quatro números:

|  | Predisse positivo | Predisse negativo |
|---|---|---|
| **É positivo** | Verdadeiro Positivo (VP) | Falso Negativo (FN) |
| **É negativo** | Falso Positivo (FP) | Verdadeiro Negativo (VN) |

A partir deles:

| Métrica | Fórmula | Pergunta que responde |
|---|---|---|
| **Acurácia** | (VP+VN)/total | de tudo, quanto acertei? |
| **Precisão** | VP/(VP+FP) | dos que **apontei** como positivos, quantos eram? |
| **Revocação** | VP/(VP+FN) | dos que **eram** positivos, quantos encontrei? |
| **F1** | média harmônica de precisão e revocação | um número quando os dois importam igualmente |
| **Especificidade** | VN/(VN+FP) | dos negativos, quantos deixei em paz? |

A distinção entre precisão e revocação é o eixo do capítulo, e a mnemônica que funciona é a das perguntas: **precisão olha para a coluna do que você apontou; revocação olha para a linha do que existia.**

E há um trade-off inescapável entre elas. Um modelo que aponta *tudo* como positivo tem revocação 1,0 e precisão péssima. Um que aponta apenas o caso de que tem certeza absoluta tem precisão alta e revocação irrisória. Mover o limiar desloca você ao longo dessa curva — nunca melhora os dois ao mesmo tempo.

### Worked example: a mesma matriz, três leituras

Um modelo de triagem médica, avaliado em 1.000 pacientes, dos quais 100 têm a doença:

|  | Predisse doente | Predisse saudável |
|---|---|---|
| **Doente** | VP = 80 | FN = 20 |
| **Saudável** | FP = 40 | VN = 860 |

- **Acurácia** = (80+860)/1000 = **0,940**
- **Precisão** = 80/(80+40) = **0,667** — de cada 3 alarmes, 1 é falso
- **Revocação** = 80/(80+20) = **0,800** — 20 doentes passaram despercebidos
- **F1** = 2·(0,667·0,800)/(0,667+0,800) = **0,727**
- **Linha de base trivial** ("todos saudáveis") = 900/1000 = **0,900**

Três leituras do mesmo modelo, e todas verdadeiras:

1. **"94% de acurácia"** — tecnicamente correto, e quase desonesto: o trivial faz 90%.
2. **"Encontra 4 de cada 5 doentes"** — a leitura da revocação. É a que importa numa triagem, porque o custo de um FN é uma doença não tratada.
3. **"Um terço dos alarmes é falso"** — a leitura da precisão. É a que determina se o serviço é operável: se cada alarme custa um exame caro, 33% de desperdício pode inviabilizar o programa.

**A métrica certa é a que responde à pergunta cujo erro custa caro.** Numa triagem, FN mata e FP custa dinheiro — então revocação manda, com precisão como restrição orçamentária. Num filtro de spam, é o inverso: o FN é um email chato na caixa de entrada, o FP é uma fatura perdida na pasta de lixo. Mesmo formalismo, prioridades opostas.

:::exercicio {"id":"04-e2","tipo":"numerica","objetivo":"O2","dificuldade":"media"}
Um classificador produziu a seguinte matriz de confusão: VP = 45, FP = 15, FN = 30, VN = 410.

Qual é a **precisão**? Responda com 2 casas decimais.

> **gabarito:** 0.75 ± 0.01
> **porque:** Precisão = VP/(VP+FP) = 45/(45+15) = 45/60 = **0,75**. O erro mais comum aqui é usar VP/(VP+FN) — isso dá 45/75 = 0,60, que é a **revocação**. A forma de nunca trocar é voltar à pergunta: precisão pergunta "dos que **apontei**, quantos eram?", então o denominador é tudo o que você apontou como positivo (VP+FP). Revocação pergunta "dos que **eram**, quantos achei?", então o denominador é tudo o que era positivo de verdade (VP+FN). Repare que este modelo tem precisão razoável e revocação de 0,60 — ele erra pouco quando fala, mas fica calado com frequência.
> **volte para:** #fundamentos-a-matriz-de-confusao-e-o-que-dela-deriva
:::

:::exercicio {"id":"04-e3","tipo":"multipla","objetivo":"O3","dificuldade":"media"}
Um sistema faz a triagem inicial de currículos, descartando candidatos antes de qualquer olhar humano. Qual métrica deve orientar a decisão de limiar, e por quê?

- [ ] Precisão: é caro entrevistar candidatos ruins.
- [x] Revocação: um candidato bom descartado nunca mais é recuperado, e ninguém fica sabendo do erro.
- [ ] Acurácia: é a métrica mais completa, pois considera as quatro células.
- [ ] F1: equilibra as duas e evita ter de escolher.

> **gabarito:** Revocação
> **porque:** A pergunta não é estatística, é de **assimetria de custo e de visibilidade**. Um falso positivo (candidato mediano que passa) custa uma entrevista — é caro, mas é detectado e corrigido pelo humano na etapa seguinte. Um falso negativo (candidato bom descartado) é invisível: ninguém no processo jamais saberá que ele existiu, o erro nunca aparece em nenhum relatório e não há mecanismo de correção. Erros invisíveis são mais perigosos que erros caros, porque não geram aprendizado. Escolher F1 aqui (alternativa 4) é a resposta mais sedutora e a mais preguiçosa: F1 assume que os dois erros pesam igual, e a premissa inteira deste caso é que **não pesam**. Escolher F1 é declarar indiferença — só que sem perceber que está declarando.
> **volte para:** #worked-example-a-mesma-matriz-tres-leituras
:::

## Ranking, decisão e calibração — três coisas diferentes

Um classificador quase sempre produz um **escore** contínuo, e só vira decisão quando você escolhe um **limiar**. Isso separa três perguntas que costumam ser confundidas numa só.

**1. O ranking é bom?** — Se eu ordenar todos os exemplos pelo escore, os positivos ficam no topo? É o que a **AUC-ROC** mede: a probabilidade de um positivo sorteado ao acaso receber escore maior que um negativo sorteado ao acaso. AUC não depende de limiar nenhum.

**2. A decisão é boa?** — Escolhido um limiar, quantos FP e FN aparecem? É aí que vivem precisão, revocação e o custo real da operação.

**3. Os escores são probabilidades honestas?** — Quando o modelo diz 0,8, isso acontece 80% das vezes? Isso é **calibração**, e é uma propriedade *independente* das duas anteriores. Um modelo pode ter AUC excelente (ordena perfeitamente) e ser péssimo calibrado (todos os escores comprimidos entre 0,4 e 0,6). Se a decisão a jusante multiplica a probabilidade por um valor monetário — preço, provisão, expectativa de perda — calibração deixa de ser refinamento e vira requisito.

**Uma armadilha específica.** Sob desbalanceamento severo, a AUC-ROC é otimista: o eixo de falsos positivos é normalizado pelo total de negativos, que é enorme, então mesmo muitos FP mal movem a curva. Para classes raras, prefira a **AUC-PR** (precisão × revocação), cuja linha de base é a própria prevalência — 0,003 no exemplo da fraude, o que deixa qualquer melhora visível em vez de diluída.

> **Cláusula de expiração.** Escrevo em 2026 que AUC-PR é a escolha padrão para classes raras e que a calibração é tratada como etapa pós-treino (Platt, isotônica). Se, na próxima revisão, os modelos de uso geral estiverem entregando escores bem calibrados sem etapa dedicada, esta seção muda de recomendação. Acompanhamento no [placar de expiração](../HISTORICO.md).

:::exercicio {"id":"04-e4","tipo":"multipla-multi","objetivo":"O4","dificuldade":"dificil"}
Um modelo tem AUC-ROC de 0,95 no teste. Quais conclusões são **legítimas** a partir só desse número? (marque todas que valem)

- [x] O modelo ordena bem: positivos tendem a receber escores maiores que negativos.
- [ ] O modelo acerta 95% das predições.
- [ ] Os escores do modelo podem ser lidos como probabilidades confiáveis.
- [x] Existe **algum** limiar com um bom compromisso entre precisão e revocação.
- [ ] O modelo terá bom desempenho mesmo se a prevalência da classe positiva mudar.

> **gabarito:** ordena bem · existe algum limiar com bom compromisso
> **porque:** AUC é uma medida de **ordenação**, e só isso. Ela não é uma taxa de acerto (0,95 de AUC não é 95% de acurácia — são grandezas diferentes), não diz nada sobre **calibração** (um modelo pode ordenar perfeitamente e ainda assim ter escores sem significado probabilístico), e não sobrevive intacta a mudanças de prevalência — quando a proporção de positivos muda, precisão e a operação real mudam junto, mesmo com a AUC-ROC estável. Esse último ponto é exatamente por que a AUC-PR é preferível para classes raras: ela é sensível à prevalência, que é o que muda no mundo. As duas corretas são as únicas que se limitam ao que a definição da AUC autoriza.
> **volte para:** #ranking-decisao-e-calibracao-tres-coisas-diferentes
:::

## Métrica é uma estimativa — reporte a incerteza

Uma acurácia de 0,94 medida em 100 exemplos e uma medida em 100.000 exemplos são o mesmo número e informações muito diferentes. A primeira tem intervalo de confiança de 95% de aproximadamente ±0,047; a segunda, de ±0,0015. Reportar as duas como "0,94" apaga a diferença que mais importa para decidir.

Duas práticas baratas resolvem quase tudo:

1. **Intervalo por *bootstrap***: reamostre o conjunto de teste com reposição algumas centenas de vezes, recalcule a métrica em cada reamostra, e reporte os percentis 2,5 e 97,5. Não exige suposição sobre a distribuição e funciona para qualquer métrica.
2. **Validação cruzada com desvio-padrão**: reporte média ± desvio entre as dobras. Um modelo com 0,84 ± 0,01 e outro com 0,86 ± 0,09 não estão empatados nem separados — estão em situações qualitativamente diferentes, e o segundo é instável.

Regra prática que vale como norma editorial deste livro: **duas métricas sem intervalos não podem ser comparadas.** "Melhorou de 0,912 para 0,918" é uma frase sem conteúdo até que se saiba se o ruído da medição é maior que 0,006.

:::exercicio {"id":"04-e5","tipo":"aberta","objetivo":"O5","pontos":3,"dificuldade":"dificil"}
Sua equipe compara dois modelos no mesmo conjunto de teste de 800 exemplos: o modelo A tem F1 = 0,812 e o modelo B, F1 = 0,829. Alguém propõe substituir A por B em produção.

Escreva a resposta que você daria: **o que falta saber** antes dessa decisão, e **como você obteria** essa informação.

> **rubrica:** questiona se a diferença de 0,017 é maior que a incerteza da medição;
> propõe um procedimento concreto para estimar essa incerteza (bootstrap, validação cruzada ou teste pareado);
> observa que os dois modelos foram medidos no mesmo conjunto, o que permite comparação pareada e reduz a variância da comparação;
> considera ao menos um fator além da métrica (custo de troca, latência, interpretabilidade, calibração, comportamento por subgrupo)
> **porque:** A diferença é de 0,017 num conjunto de 800 exemplos — plausivelmente dentro do ruído amostral. O caminho correto não é rejeitar B, é **medir a incerteza antes de decidir**: bootstrap pareado sobre o mesmo teste (reamostre os índices, recalcule as duas métricas na mesma reamostra e observe a distribuição da **diferença**) responde diretamente à pergunta certa. O detalhe do pareamento é o que separa uma resposta boa de uma correta: como os dois modelos foram avaliados nos mesmos exemplos, a comparação pareada elimina a variância comum ao conjunto e é bem mais sensível que comparar dois intervalos independentes. E a decisão de produção nunca é só da métrica — trocar modelo tem custo, e um ganho dentro do ruído não paga esse custo.
> **volte para:** #metrica-e-uma-estimativa-reporte-a-incerteza
:::

## Mão na massa

A **etapa 04** do [`ml-zero`](../trilha-ml-zero.md) implementa, em NumPy puro e sem scikit-learn:

1. `matriz_confusao(y_true, y_pred)` — os quatro números;
2. `precisao`, `revocacao`, `f1` derivadas dela;
3. `curva_pr` e `auc_pr` por varredura de limiares;
4. `bootstrap_ic(metrica, y_true, y_score, n=1000)` — o intervalo de confiança;
5. a comparação pareada entre dois modelos que o exercício 04-e5 pediu.

Implementar precisão e revocação uma vez, à mão, é o antídoto mais duradouro contra trocá-las — que é o erro mais comum do capítulo, inclusive entre praticantes experientes.

## Assista

:::video {"id":"04-v1","fonte":"youtube","ref":"4jRBRDbJemM","min":16,"autor":"StatQuest with Josh Starmer","titulo":"ROC and AUC, Clearly Explained!"}
A curva ROC é o conceito deste capítulo que menos sobrevive à explicação em prosa. O vídeo constrói a curva **ponto a ponto**, deslizando o limiar e mostrando a matriz de confusão mudar junto — e é essa animação que faz cair a ficha de que ROC não é uma métrica de um modelo, mas o retrato de *todos os limiares de uma vez*. Assista antes do exercício 04-e4.
:::

## Síntese — o que levar

- **Calcule a linha de base trivial antes de tudo** e mantenha-a em todo relatório. Modelo que não a bate não existe.
- Acurácia informa quando as classes são equilibradas e os erros custam igual. Fora disso, ela esconde.
- **Escolha a métrica pelo custo do erro, antes de treinar.** Escolher depois é escolher a que ficou bonita.
- AUC mede *ranking*; limiar produz *decisão*; calibração é uma **terceira** propriedade, exigida sempre que a probabilidade vira dinheiro.
- Métrica sem intervalo não se compara. Bootstrap pareado é barato e resolve.

## Verificação

1. Explique a diferença entre precisão e revocação para alguém de negócio, sem escrever nenhuma fórmula.
2. Em que situação um modelo com AUC de 0,99 pode ser inútil na prática? Dê um exemplo concreto.
3. Sua equipe reporta "acurácia de 97%". Que três perguntas você faz antes de aprovar o deploy?

---

# 05 — Modelos Lineares

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-05 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Derivar a regressão linear como minimização do erro quadrático.
- **O2.** Obter as equações normais da reta e calcular a inclinação e o intercepto ótimos.
- **O3.** Interpretar os coeficientes de um modelo linear — e dizer o que eles **não** significam.
- **O4.** Reconhecer as situações em que o modelo linear é a escolha certa, não a escolha simplória.

> **Este capítulo trata só de regressão linear.** A **regressão logística** — que tem "regressão" no nome e classifica — ganhou capítulo próprio: [28 — Regressão Logística](28-regressao-logistica.md). Compartilham a forma `w·x + b` e quase nada além disso: perdas diferentes, saídas em unidades diferentes, e uma tem solução fechada enquanto a outra não tem.

## O problema: o modelo que todo mundo aprende e quase ninguém respeita

O [capítulo 07](07-arvores-ensembles.md) mostrou o modelo linear perdendo feio: 0,4963 de AUC contra 0,9392 do boosting. Se você leu aquele capítulo primeiro, saiu dele com a impressão de que linear é o modelo dos iniciantes.

É a impressão errada, e este capítulo existe para corrigi-la. Naquele experimento, o dado foi **construído** com uma fronteira irregular — o terreno onde a reta não tem chance. Troque o terreno e a conclusão vira:

- com **poucos dados por atributo**, o linear frequentemente ganha, porque tem menos o que estimar errado;
- quando a decisão precisa ser **auditada**, ele é o único que entrega um número por atributo que alguém consegue defender numa reunião;
- quando a saída vira **probabilidade que multiplica dinheiro**, ele nasce razoavelmente calibrado, enquanto ensembles precisam de correção posterior (cap. 04).

E há a razão pedagógica: é no modelo linear que otimização, regularização e interpretação aparecem na forma mais limpa. Quem não entende gradiente aqui não vai entender numa rede de doze camadas.

## De onde isto veio

**O aperto.** Virada do século XVIII para o XIX, astronomia. Um cometa ou um planeta é observado várias vezes, por instrumentos diferentes, em noites diferentes — e **nenhuma das observações concorda com as outras**. A órbita verdadeira é uma só; os dados são muitos e discordantes. O astrônomo precisa de **uma** curva, e não tem critério defensável para escolhê-la.

**O que se fazia antes.** Escolhia-se a olho, descartava-se a observação que parecia pior, ou faziam-se médias de subconjuntos convenientes. Todos os caminhos tinham o mesmo defeito: **dois astrônomos competentes, com os mesmos dados, chegavam a órbitas diferentes** — e não havia como decidir quem estava certo.

**A virada.** Trocar "a melhor curva" por **uma regra explícita do que significa melhor**: aquela que torna mínima a soma dos quadrados dos desvios. A regra não é mais verdadeira que as outras — ela é **pública**. Dados os mesmos números, devolve a mesma resposta para qualquer pessoa.

**A ideia reaproveitável.** **Uma função de perda é um critério de arbitragem, não uma descoberta sobre o mundo.** Ela existe para tornar a escolha reproduzível e discutível. É por isso que a pergunta "por que erro *quadrático*, e não valor absoluto?" tem resposta honesta — conveniência matemática mais uma hipótese sobre o ruído — e não a resposta "porque é o certo". Trocar a perda é trocar o critério de arbitragem: decisão de projeto, nunca detalhe técnico.

**O nome.** *Mínimos quadrados* — *moindres carrés* — foi batizado por Legendre, e o nome é literalmente a definição do critério.

### A disputa de prioridade mais famosa da estatística

**Legendre publicou primeiro**, em **1805**, em *Nouvelles méthodes pour la détermination des orbites des comètes*, e deu ao método o nome que ficou. **Gauss publicou em 1809** (*Theoria motus corporum coelestium*) afirmando **usar o método desde 1795**.

Legendre reagiu mal, e o argumento dele é o que interessa aqui: **prioridade se estabelece por publicação**. Em 1820 atacou publicamente a reivindicação. Gauss entendia prioridade como *ser o primeiro a descobrir*, e apoiava-se em registros privados e correspondência — Olbers (1816) e Bessel (1832) publicaram notas confirmando ter visto o método com ele antes. A avaliação histórica moderna é que Gauss provavelmente **tinha** o método antes e **falhou em comunicá-lo**.

> **O espelho disto está no [capítulo 18](18-neuronio-artificial.md).** Lá, quem leva o crédito pelo backpropagation são os últimos (Rumelhart *et al.*, 1986), não o primeiro (Linnainmaa, 1970), e Schmidhuber resume: *não é o primeiro inventor que leva o crédito, é o último reinventor*. Aqui o caso é o inverso exato — o primeiro descobridor perde para o primeiro **publicador**.
>
> Juntos, os dois dizem o que nenhum diz sozinho: **crédito não segue descoberta, segue comunicação.** Vale para o seu trabalho: o experimento que você não registrou, datou e tornou reproduzível é, na prática, um experimento que não aconteceu. É a razão de este livro exigir script, *seed* e saída colada — e não é burocracia.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ᵐ | Legendre (1805) e Gauss (1809): obra, ano e conteúdo geral. Nenhuma das duas lida no original |
| ✓ᵐ | [Stigler, "Gauss and the Invention of Least Squares", *Annals of Statistics*, 1981](https://projecteuclid.org/journals/annals-of-statistics/volume-9/issue-3/Gauss-and-the-Invention-of-Least-Squares/10.1214/aos/1176345451.full) — localizado e identificado, **não lido** |
| ⏳ | As notas de Olbers (1816) e Bessel (1832), e o ataque público de Legendre em 1820 |
| ⏳ | A avaliação de que Gauss tinha o método antes mas falhou em comunicá-lo |
| 📖 | A ideia reaproveitável ("perda é critério de arbitragem") e a ligação com o capítulo 18 |

## Fundamentos: regressão linear como minimização

O modelo é uma reta (ou um plano, ou um hiperplano):

$$\hat{y} = w_1x_1 + w_2x_2 + \dots + w_dx_d + b$$

Resta escolher os $w$. O critério: minimizar a soma dos erros ao quadrado.

$$L(w, b) = \frac{1}{2n}\sum_{i=1}^{n}\left(\hat{y}_i - y_i\right)^2$$

Por que ao quadrado, e não em valor absoluto? Três razões, em ordem de honestidade:

1. **É diferenciável em todo ponto**, o que faz o otimizador funcionar sem casos especiais. O valor absoluto tem um bico em zero.
2. **Tem solução fechada.** Derivando e igualando a zero, chega-se às *equações normais* — um sistema linear que se resolve de uma vez, sem iteração.
3. **Pune o erro grande desproporcionalmente**, o que às vezes é o que você quer e às vezes não é. Se houver *outliers*, o erro quadrático os persegue — e aí o erro absoluto é a escolha certa. Esta é uma decisão de modelagem, não uma constante da natureza.

A solução fechada existe e está implementada na [etapa 05](../trilha-ml-zero.md), em 25 linhas de eliminação de Gauss. Vale conferir: **gradiente e solução fechada chegam ao mesmo lugar** — no experimento, com diferença menor que 0,05 em cada coeficiente. Isso desmistifica o gradiente, que passa a ser *um jeito* de resolver, não *o* jeito.

> Se a solução fechada existe e é exata, por que usar gradiente? Porque ela envolve inverter uma matriz $d \times d$ — inviável com muitos atributos — e porque ela **não existe** para a regressão logística ([capítulo 28](28-regressao-logistica.md)). O gradiente é a ferramenta geral; a solução fechada é o caso de sorte.

:::exercicio {"id":"05-e1","tipo":"multipla","objetivo":"O1","dificuldade":"media"}
Por que a regressão linear minimiza o erro **ao quadrado** em vez do erro absoluto?

- [ ] Porque o erro quadrático é sempre menor que o absoluto.
- [x] Porque é diferenciável em todo ponto e admite solução fechada — não porque seja intrinsecamente mais correto.
- [ ] Porque o erro absoluto não pode ser minimizado.
- [ ] Porque o quadrado elimina os erros negativos, e o valor absoluto não.

> **gabarito:** É diferenciável e admite solução fechada
> **porque:** As razões são de **conveniência matemática**, e reconhecer isso é o que separa quem usa o método de quem o repete. O quadrado é diferenciável em toda parte (o valor absoluto tem um bico em zero, que complica o otimizador) e leva às equações normais, resolvíveis de uma vez.
>
> Não é que ele seja mais correto. Ele pune erros grandes de forma desproporcional, o que na presença de *outliers* é ativamente ruim — e nesse caso o erro absoluto é a escolha certa, à custa de exigir otimização iterativa. A última alternativa erra num detalhe revelador: o valor absoluto **também** elimina o sinal do erro. Eliminar sinal não é o ponto; a diferenciabilidade é.
> **volte para:** #fundamentos-regressao-linear-como-minimizacao
:::

## Ponha a reta à mão

Antes da fórmula, o gesto. Arraste a reta até achar que está boa, e olhe o número subir e descer enquanto você mexe.

:::lab {"id":"05-l1","tipo":"regressao-linear","titulo":"Mínimos quadrados à mão","n":24,"a":1.8,"b":4,"ruido":3.2}
Cada segmento cinza é um **resíduo**: a distância vertical de um ponto até a **sua** reta. O laboratório mostra cinco medidas de erro ao mesmo tempo, e marca **uma** como a que estamos minimizando.

Três coisas para tentar, nesta ordem:

1. **Minimize no olho.** Arraste as alças até o EQM parar de cair. Anote o valor.
2. **Ligue "Mostrar os quadrados".** Agora o erro tem área: cada quadrado tem lado igual ao resíduo, e o que você está minimizando é a **soma das áreas**. Repare no que acontece quando um único ponto fica longe.
3. **Revele a reta ótima.** A distância entre a sua e a dela é o preço do olho. Depois clique em "Ajustar automaticamente" e compare os coeficientes com o que você tinha.

Uma pergunta para levar para a próxima seção: **por que existe uma reta ótima única, e como o computador a encontra sem tentar todas?**
:::

## A dedução, em cinco passos

O laboratório mostrou que existe um fundo do poço. Esta seção mostra **por que ele existe e como chegar nele por conta**, sem tentativa e erro. É a diferença entre usar a fórmula e saber de onde ela vem.

Com um atributo, a reta é $\hat{y} = ax + b$, e o critério é a soma dos quadrados dos resíduos:

$$S(a, b) = \sum_{i=1}^{n}\left(y_i - ax_i - b\right)^2$$

**Passo 1 — por que há um mínimo, e um só.** $S$ é uma soma de quadrados: é uma superfície convexa em $(a, b)$, uma tigela. Tigela tem um fundo, e só um. É a razão de o laboratório sempre convergir para a mesma reta, venha você por onde vier.

**Passo 2 — no fundo, as derivadas se anulam.** Derivando em relação a $b$:

$$\frac{\partial S}{\partial b} = -2\sum_{i=1}^{n}\left(y_i - ax_i - b\right) = 0 \;\Longrightarrow\; \sum_{i=1}^{n} r_i = 0$$

onde $r_i = y_i - ax_i - b$ é o resíduo. **A soma dos resíduos é zero.** Dividindo por $n$: $\bar{y} = a\bar{x} + b$, ou seja,

$$b = \bar{y} - a\bar{x}$$

**A reta ótima passa pelo centro de massa dos dados** — sempre, em qualquer conjunto. É um resultado que se vê no laboratório: gire a reta ótima em torno de um ponto e ele será $(\bar{x}, \bar{y})$.

**Passo 3 — a segunda condição.** Derivando em relação a $a$:

$$\frac{\partial S}{\partial a} = -2\sum_{i=1}^{n}x_i\left(y_i - ax_i - b\right) = 0 \;\Longrightarrow\; \sum_{i=1}^{n} x_i r_i = 0$$

**Os resíduos são ortogonais ao atributo.** Traduzindo: o que sobrou de erro **não tem mais nada de linear em $x$** — se tivesse, a reta ainda poderia melhorar. É o significado geométrico do ajuste, e vale para qualquer número de atributos.

**Passo 4 — resolver o sistema.** Substituindo $b = \bar{y} - a\bar{x}$ na segunda condição e reorganizando em torno das médias:

$$a = \frac{\sum_{i=1}^{n}(x_i - \bar{x})(y_i - \bar{y})}{\sum_{i=1}^{n}(x_i - \bar{x})^2} = \frac{S_{xy}}{S_{xx}}$$

Duas contas — uma soma de produtos e uma soma de quadrados — e a reta está pronta. Sem iteração, sem taxa de aprendizado, sem critério de parada.

**Passo 5 — o que a fórmula avisa.** O denominador é a variação de $x$. Se $S_{xx} = 0$, todos os $x$ são iguais, e **não existe reta**: nenhuma inclinação é melhor que outra. Não é falha numérica — é o dado não conter a informação. É o mesmo fenômeno que apareceu no caso da limonada mais adiante, onde o preço **não varia** dentro de nenhum mês.

> **Isto é a versão com um atributo do que a etapa 05 do `ml-zero` faz para $d$ atributos.** Lá as duas condições viram um sistema $d \times d$ — as **equações normais** — resolvido por eliminação de Gauss. A ideia é idêntica: derivar, igualar a zero, resolver. O que cresce é a álgebra, não o conceito.

:::exercicio {"id":"05-e7","tipo":"numerica","objetivo":"O2","dificuldade":"media"}
Quatro pontos: (1, 2), (2, 3), (3, 5) e (4, 6).

Calcule a **inclinação** $a$ da reta de mínimos quadrados, usando $a = S_{xy} / S_{xx}$. Responda com duas casas decimais.

> **gabarito:** 1.40 ± 0.02
> **porque:** As médias são x̄ = 2,5 e ȳ = 4. Os desvios em x são −1,5, −0,5, +0,5 e +1,5; em y são −2, −1, +1 e +2.
>
> S_xy = (−1,5)(−2) + (−0,5)(−1) + (0,5)(1) + (1,5)(2) = 3 + 0,5 + 0,5 + 3 = **7**
> S_xx = 2,25 + 0,25 + 0,25 + 2,25 = **5**
>
> Logo a = 7 / 5 = **1,4**, e o intercepto sai de b = ȳ − a·x̄ = 4 − 1,4 × 2,5 = **0,5**.
>
> Confira no laboratório acima que a reta ótima passa por (x̄, ȳ) = (2,5; 4): 1,4 × 2,5 + 0,5 = 4. Isso não é coincidência deste exemplo — é o passo 2 da dedução, e vale sempre.
> **volte para:** #a-deducao-em-cinco-passos
:::

## Interpretar coeficientes — e o que eles não dizem

O modelo linear é interpretável, e é por isso que ele sobrevive em crédito, seguro e saúde. Mas "interpretável" não significa "fácil de interpretar corretamente".

### O que o coeficiente diz

Aumentar $x_j$ em uma unidade muda $\hat{y}$ em $w_j$ unidades, mantendo os demais atributos constantes. É a leitura mais direta que um modelo oferece — e é o motivo de o linear sobreviver em crédito, seguro e saúde.

> Na regressão logística a leitura é outra: o coeficiente multiplica a **razão de chances**, não a saída. Está no [capítulo 28](28-regressao-logistica.md), e confundir as duas é o erro de interpretação mais comum deste livro.

### As quatro coisas que ele não diz

1. **Não diz causalidade.** "Mantendo tudo mais constante" é uma operação matemática sobre a equação ajustada, não uma intervenção no mundo. Se você mudar $x_j$ de fato, as outras variáveis mudam junto — e o modelo não sabe disso.
2. **Não é comparável entre atributos sem padronização.** Um coeficiente de 0,003 para renda em reais e 2,5 para número de filhos não diz que filhos importam mais. Compare coeficientes só depois de padronizar — e mesmo assim com cuidado.
3. **Não é confiável sob colinearidade.** Quando dois atributos são altamente correlacionados, o modelo pode dar peso alto a um e negativo ao outro, ou trocá-los completamente com uma pequena mudança nos dados. O *erro* não piora; a *interpretação* vira ruído. É o modo de falha mais traiçoeiro do modelo linear, porque a métrica não avisa.
4. **Não vale fora da faixa observada.** Extrapolar uma reta é a forma mais fácil de produzir uma previsão absurda com aparência de rigor.


## O caso da limonada

A lista acima é fácil de ler e difícil de acreditar. Esta seção existe para você **produzir** o erro antes de aceitar que ele é um erro.

O conjunto está em [`ml-zero/dados/limonada/`](../../ml-zero/dados/limonada/README.md): 365 dias de uma barraca de limonada, com o tempo que fez, quantos panfletos foram distribuídos, o preço praticado e quantos copos saíram. Sem valor faltante. O dado é sintético — e é por isso que serve: as armadilhas aparecem limpas, sem ruído para escondê-las.

Comece pelo que todo mundo faz — a matriz de correlação com a variável resposta:

| atributo | correlação com `vendas` |
|---|---|
| `temperatura` | +0,990 |
| `precipitacao` | −0,909 |
| `panfletos` | +0,805 |
| **`preco`** | **+0,513** |

Calor vende, chuva atrapalha, panfleto ajuda. E **preço mais alto vende mais.**

A última linha é onde o relatório morre. Ela sugere uma recomendação de negócio — *aumente o preço* — que é o oposto do que a barraca deve fazer. Antes de ler adiante, olhe o dado:

| preço | dias | temperatura média | vendas médias | meses em que aparece |
|---|---|---|---|---|
| 0,30 | 303 | 57,0 | 23,7 | jan–jun, set–dez |
| 0,50 | 62 | 78,8 | 33,1 | **só julho e agosto** |

O preço subiu **no verão**. `preco` não é uma alavanca de decisão: é um **termômetro disfarçado**. A correlação de +0,513 mede o calor de julho, não a disposição do freguês a pagar.

### O passo que deveria salvar, e não salva

A resposta de manual é "controle pelas outras variáveis". Ajustando tudo junto:

```
vendas = 3,192
       + 0,3692 · temperatura
       − 2,2460 · precipitacao
       + 0,0188 · panfletos
       + 2,4143 · preco          R² = 0,982
```

O coeficiente do preço continua **positivo**. Controlar pela temperatura não desfez nada — porque a temperatura média não captura *ser julho*, e o que sobrou de julho continua morando dentro de `preco`.

**Controlar por uma variável só remove o confundimento que aquela variável mede.** Se o confundidor real é "estação", e você mediu "temperatura do dia", a regressão devolve um número com aparência de rigor e sinal invertido. Nenhuma métrica avisa: o R² é 0,982.

Este é o item 1 da lista anterior — *não diz causalidade* — em números, e não em advertência.

### E o item 3, de brinde

`temperatura` e `panfletos` correlacionam **+0,798**: em dia quente, distribuíam-se mais panfletos. O coeficiente do panfleto sai em 0,0188 — ou seja, **53 panfletos para um copo a mais**. Lido como efeito da panfletagem, é falso: parte do que ele mede é simplesmente o calor daquele dia.

Colinearidade não estraga a previsão. Estraga a **leitura** — e é o modo de falha mais traiçoeiro do modelo linear, porque o erro de validação não muda.

### Reproduza

```python
import pandas as pd
df = pd.read_csv("ml-zero/dados/limonada/limonada.csv", parse_dates=["data"])

df.corr(numeric_only=True)["vendas"]            # a tabela ingênua
df.groupby("preco")[["temperatura", "vendas"]].mean()   # a revelação
df.assign(mes=df.data.dt.month).groupby("preco").mes.unique()
```

Agora tente o conserto óbvio: **isolar um período em que o preço varie sem a estação variar junto**, e ajustar só ali.

Ele não existe. Rode e veja:

```python
df.assign(mes=df.data.dt.month).groupby("mes").preco.nunique()   # tudo 1
```

**Nenhum mês do ano tem mais de um preço.** São 0,30 de janeiro a junho e de setembro a dezembro, 0,50 nos 62 dias de julho e agosto — exatamente os dois meses inteiros. Restringir a julho e agosto não isola o efeito do preço: deixa o preço **constante**, e um atributo que não varia não tem coeficiente.

O confundimento aqui é **perfeito**: preço e estação são a mesma variável, com dois nomes. Não há recorte, controle nem modelo que separe as duas — a informação não está no dado, e nenhuma técnica a inventa. Estimar efeito de preço exigiria **variar o preço de propósito** em dias comparáveis: cobrar 0,30 e 0,50 dentro do mesmo mês.

Esta é a resposta menos confortável e a mais honesta que a análise pode dar: *com estes dados, não dá — e aqui está o que precisaria ser coletado.*

:::exercicio {"id":"05-e4","tipo":"numerica","objetivo":"O3","dificuldade":"facil"}
Pelo ajuste múltiplo acima, quantos panfletos precisam ser distribuídos para vender **um copo a mais**? Responda com um número inteiro aproximado.

> **gabarito:** 53 ± 4
> **porque:** O coeficiente é 0,0188 copo por panfleto, então um copo pede 1 ÷ 0,0188 ≈ 53 panfletos.
>
> O número importa menos que o hábito: **inverter o coeficiente devolve a unidade que a decisão usa**. "0,0188" não diz nada a quem manda imprimir panfleto; "53 panfletos por copo" diz — e diz que a panfletagem provavelmente não se paga.
>
> E a ressalva vale mais que a conta: `panfletos` correlaciona +0,798 com `temperatura`, então parte desses 0,0188 é calor, não panfleto. O número real, se a barraca distribuísse panfletos sem escolher o dia, seria **menor** — pior ainda para a ideia.
> **volte para:** #e-o-item-3-de-brinde
:::

:::exercicio {"id":"05-e5","tipo":"multipla","objetivo":"O3","dificuldade":"dificil"}
Na regressão múltipla da limonada, `preco` fica com coeficiente **+2,41** mesmo com `temperatura` no modelo. Qual é a explicação correta?

- [ ] O modelo provou que subir o preço aumenta as vendas; a correlação simples estava certa.
- [ ] O coeficiente é positivo por erro numérico — com mais dados ele viraria negativo.
- [x] `preco` funciona como indicador de julho e agosto, e a temperatura do dia não captura tudo o que "ser verão" significa.
- [ ] O problema seria resolvido padronizando os atributos antes de ajustar.

> **gabarito:** `preco` funciona como indicador de julho e agosto
> **porque:** O preço de 0,50 só existe em 62 dias, todos em julho e agosto. Ele carrega a informação "é alta temporada" — férias, fluxo de rua, hábito — que a temperatura média do dia não representa inteira. O que sobra desse efeito é atribuído ao único atributo que o marca: o preço.
>
> A primeira alternativa é a leitura que vai para o slide de recomendação e custa dinheiro. A segunda inverte o diagnóstico: não é ruído, é **viés** — mais dados do mesmo tipo tornariam o coeficiente errado mais preciso, não mais correto. A quarta confunde escalas com confundimento: padronizar muda a **magnitude** dos coeficientes para que sejam comparáveis entre si, e não mexe em qual variável está roubando o efeito da outra.
>
> Controlar por uma variável só remove o confundimento que aquela variável mede.
> **volte para:** #o-passo-que-deveria-salvar-e-nao-salva
:::

## Quando o linear é a escolha certa

Não como consolo, e sim como decisão de engenharia:

| Situação | Por quê |
|---|---|
| **Poucos dados por atributo** | menos parâmetros, menos variância. Com 200 linhas e 50 colunas, o ensemble decora |
| **Necessidade de auditoria** | um número por atributo, defensável e questionável. Exigência regulatória em crédito e seguro |
| **Probabilidade que vira dinheiro** | sai razoavelmente calibrado; ensembles frequentemente não (cap. 04) |
| **Linha de base obrigatória** | é a régua contra a qual o modelo complexo precisa se justificar |
| **Latência apertada** | uma multiplicação de vetores; ordens de grandeza mais rápido que uma floresta |

O último ponto tem um corolário que vale sozinho: **sempre treine um linear primeiro**. Ele custa minutos e responde à pergunta que importa antes de qualquer outra — "quanto do sinal é simplesmente linear?". Se o modelo complexo ganha pouco dele, você acabou de descobrir que o problema é fácil e que o resto é custo de manutenção.

:::exercicio {"id":"05-e6","tipo":"aberta","objetivo":"O4","dificuldade":"media"}
A dona da barraca de limonada quer decidir **o preço do próximo verão** e pede ajuda. Você tem os 365 dias do conjunto acima e um modelo linear com R² de 0,982.

Escreva a resposta que você daria a ela — em até seis linhas, sem jargão. Diga o que o modelo serve para responder, o que ele **não** serve, e o que você precisaria para responder a pergunta que ela fez.

> **rubrica:** Reconhece que o modelo prevê bem as vendas mas não estima o efeito do preço, porque nos dados o preço mudou junto com a estação; Não usa o R² alto como argumento a favor da recomendação de preço; Diz o que faltaria — variar o preço de propósito em dias comparáveis, porque nenhum recorte dos dados atuais resolve: não há um único mês com dois preços; Mantém o modelo como útil para o que ele faz bem, como prever demanda e dimensionar estoque; Responde em linguagem que a dona da barraca entende, sem exigir vocabulário técnico
> **porque:** Esta é a pergunta que separa "treinei um modelo" de "respondi a alguém". As três leituras que o exercício cobra estão no capítulo: o coeficiente **não é causa**, o R² alto **não valida a recomendação**, e o modelo linear continua sendo a escolha certa — para **previsão de demanda**, que é outra pergunta.
>
> A resposta forte não é "não dá para saber". É separar as duas perguntas: *quantos copos vou vender amanhã, dado o tempo?* — o modelo responde bem. *Quanto vendo a mais se eu baixar o preço?* — o dado não contém a resposta, porque o preço nunca variou sem a estação variar junto. E propor o desenho que traria essa informação: alternar preço entre dias parecidos, dentro do mesmo mês — que é justamente o que nunca aconteceu nestes 365 dias.
>
> Uma resposta que recomenda subir o preço citando o coeficiente positivo está errada mesmo que bem escrita — é exatamente o relatório que o capítulo existe para impedir.
> **volte para:** #quando-o-linear-e-a-escolha-certa
:::

## Mão na massa

A **etapa 05–06** do [`ml-zero`](../trilha-ml-zero.md) implementa, em biblioteca padrão:

- `RegressaoLinear` com **os dois caminhos** — solução fechada por eliminação de Gauss e gradiente — para você conferir que chegam ao mesmo lugar;
- `Padronizador` que aprende no treino e **aplica** ao teste — o vazamento do capítulo 02 tornado difícil de cometer.

A mesma etapa serve ao [capítulo 06](06-otimizacao.md), porque são o mesmo objeto por dois ângulos: o 05 pergunta *que função o modelo representa*; o 06, *como se chega aos coeficientes*. A `RegressaoLogistica`, que também mora ali, é do [capítulo 28](28-regressao-logistica.md).


**Notebook pronto para executar** — [`regressao_limonada.ipynb`](https://github.com/GHDaru/machinelearning/blob/main/ml-zero/etapa-05/regressao_limonada.ipynb) · [abrir no Colab](https://colab.research.google.com/github/GHDaru/machinelearning/blob/main/ml-zero/etapa-05/regressao_limonada.ipynb)

O caso da limonada do começo ao fim: a correlação que sugere *aumente o preço*, a descoberta de que o preço é um termômetro disfarçado, o controle que **não conserta**, e a verificação de que nenhum mês tem dois preços — a informação não está no dado.

> Na sua máquina: `pip install notebook` e `jupyter notebook`, ou abra a pasta no VS Code. O notebook **não precisa do repositório clonado** — se você estiver no Colab, ele baixa sozinho os arquivos de que precisa. Como rodar a trilha inteira: [`ml-zero`](https://github.com/GHDaru/machinelearning/blob/main/ml-zero/README.md).

## Síntese — o que levar

- Regressão linear minimiza **erro quadrático** — por diferenciabilidade e solução fechada, não por ser intrinsecamente mais correto.
- A dedução dá **duas condições**: a soma dos resíduos é zero (a reta passa pelo centro de massa) e os resíduos são ortogonais ao atributo (não sobrou nada de linear em $x$).
- $a = S_{xy}/S_{xx}$, e o denominador avisa: **atributo que não varia não tem coeficiente**.
- Gradiente e solução fechada chegam ao mesmo lugar. O gradiente é a ferramenta **geral**; a fechada é o caso de sorte.
- Coeficiente **não** é causa, **não** é comparável sem padronização, **não** é estável sob colinearidade, e **não** vale fora da faixa observada.
- Treine sempre um linear primeiro. Ele responde "quanto do sinal é simplesmente linear?" em minutos.

## Verificação

1. Mostre, sem consultar o texto, por que a reta de mínimos quadrados passa necessariamente pelo ponto $(\bar{x}, \bar{y})$.
2. Você tem 180 linhas e 60 atributos. Que família de modelo você tenta primeiro, e por quê?
3. Dois atributos do seu modelo são quase idênticos. O erro de validação está ótimo. O que pode estar errado mesmo assim?
4. No laboratório, o que aconteceria com a reta ótima se todos os pontos tivessem o mesmo $x$? Responda pela fórmula, não pelo desenho.

---

# 28 — Regressão Logística

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-11 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Explicar por que a regressão logística é um modelo de classificação apesar do nome.
- **O2.** Interpretar um coeficiente como efeito sobre a **razão de chances**, e não sobre a probabilidade.
- **O3.** Justificar por que a perda é a entropia cruzada e por que não há solução fechada.

> Este capítulo saiu do [05 — Modelos Lineares](05-modelos-lineares.md), onde dividia espaço com a regressão linear. Compartilham a forma $w \cdot x + b$ e quase nada além disso.

## O problema: o classificador que finge ser regressão

Você quer prever se o cliente vai pagar: sim ou não. Tem os atributos, tem os rótulos 0 e 1, e tem uma regressão linear que já funciona. A tentação é imediata — ajuste a reta contra o rótulo e chame de classificador.

O resultado é ruim de um jeito específico. A reta prevê **1,7** para um cliente e **−0,4** para outro. Não são probabilidades, e nenhum arredondamento conserta: o problema não é o valor, é que a reta **não tem teto nem piso**, e a resposta que você quer tem os dois.

Pior: a perda quadrática pune o modelo por acertar com folga. Um cliente claramente bom, previsto em 1,5 quando o rótulo é 1, gera erro — e o ajuste puxa a reta para trás por causa de um caso que ele já resolveu.

O conserto não é limitar a saída na marra. É **mudar o que se modela**.

## De onde isto veio

**O aperto.** Meados do século XX, epidemiologia e bioensaio. A pergunta prática: dada uma dose, qual a **probabilidade** de o organismo responder? Havia método consolidado — o *probit*, baseado na normal acumulada —, e ele funcionava. Só que exigia tabelas, iteração pesada para a época, e entregava um coeficiente que **ninguém conseguia explicar** a um médico.

**O que se fazia antes.** Ajustava-se o probit e reportava-se o resultado na escala da normal. A pergunta "quanto muda o risco se a dose dobrar?" não tinha resposta em linguagem clínica. Alternativamente, ignorava-se tudo e ajustava-se uma reta na proporção observada — com o defeito de prever probabilidades negativas nas doses baixas.

**A virada.** Modelar não a probabilidade, mas o **logaritmo da razão de chances**:

$$\log\frac{p}{1-p} = w \cdot x + b$$

O lado esquerdo varre a reta inteira, de $-\infty$ a $+\infty$; o direito é linear. O teto e o piso deixam de ser uma restrição a impor e passam a ser **consequência da forma escolhida**.

**A ideia reaproveitável.** **Quando a saída tem fronteiras e o modelo não, transforme a saída — não restrinja o modelo.** É o mesmo movimento que aparece no logaritmo de valores positivos, no *softmax* de várias classes e na função de ligação de qualquer modelo linear generalizado. A restrição vira mudança de escala, e o maquinário linear continua valendo inteiro.

**O nome.** *Logit*, contração de *logistic unit*, cunhado por **Joseph Berkson** em 1944 — deliberadamente ecoando *probit* (*probability unit*), do método concorrente. O nome carrega a polêmica: era uma proposta de substituição, não de complemento. A palavra *logística* vem antes, da **curva logística** de **Pierre François Verhulst** (1838), estudando crescimento populacional limitado — a mesma curva em S, chegando aqui por outro caminho.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ᵐ | Berkson, "Application of the Logistic Function to Bio-Assay", *Journal of the American Statistical Association*, 1944 — obra, ano e o fato de cunhar *logit*. [DOI 10.1080/01621459.1944.10500699](https://doi.org/10.1080/01621459.1944.10500699). **Não lida** |
| ✓ᵐ | Verhulst (1838), "Notice sur la loi que la population suit dans son accroissement" — a curva logística e o nome. **Não lida** |
| ✓ᵐ | Cox, "The Regression Analysis of Binary Sequences", *Journal of the Royal Statistical Society B*, 1958 — o trabalho que consolida o modelo na forma usada hoje. [DOI 10.1111/j.2517-6161.1958.tb00292.x](https://doi.org/10.1111/j.2517-6161.1958.tb00292.x). **Não lida** |
| ⏳ | Que o *logit* foi proposto como **substituto** do *probit*, e a controvérsia entre as duas escolas |
| ⏳ | Que a motivação era interpretabilidade clínica e custo de cálculo |
| ❌ | A data em que o método passou a ser padrão em crédito e seguro — procurei e não achei fonte com data defensável |
| 📖 | A ideia reaproveitável ("transforme a saída, não restrinja o modelo") e a ligação com o *softmax* |

> **Dívida declarada.** As três fontes acima estão seladas **✓ᵐ**: sei que existem, com DOI conferido, e **não as li**. O que este capítulo afirma sobre o que elas argumentam por dentro está, portanto, apoiado em leitura secundária. É a dívida **D10** do roadmap, e se paga lendo — não suavizando o texto.

## Fundamentos: a sigmoide e o logito

Invertendo a equação da virada, chega-se à forma que se usa para prever:

$$p = \sigma(z) = \frac{1}{1 + e^{-z}}, \qquad z = w \cdot x + b$$

A **sigmoide** comprime a reta inteira em $[0, 1]$: manda $-\infty$ para 0, $0$ para $0{,}5$ e $+\infty$ para 1.

O ponto que dá nome ao modelo é a volta:

$$z = \log\frac{p}{1-p}$$

O que é linear nos atributos **não é a probabilidade** — é o **logito**, o logaritmo da razão de chances. A regressão logística é uma regressão linear *sobre o logito*, usada para classificar.

:::exercicio {"id":"28-e1","tipo":"multipla","objetivo":"O1","dificuldade":"facil"}
Numa regressão logística, o que é linear nos atributos?

- [ ] A probabilidade prevista.
- [x] O logito — o logaritmo da razão de chances.
- [ ] A classe prevista (0 ou 1).
- [ ] O erro de classificação.

> **gabarito:** O logito
> **porque:** O modelo calcula z = w·x + b (linear) e depois aplica a sigmoide para chegar à probabilidade. A sigmoide é **não linear** — é justamente ela que comprime a reta inteira no intervalo [0,1]. Portanto a probabilidade *não* é linear nos atributos; o logito é.
>
> A consequência prática aparece nos extremos. Um aumento de uma unidade num atributo muda o logito sempre na mesma quantidade, mas muda a **probabilidade** muito perto de 0,5 e quase nada perto de 0 ou de 1. Por isso "este atributo aumenta a chance em 3 pontos percentuais" é uma frase que só pode ser verdadeira num ponto específico, nunca em geral.
> **volte para:** #fundamentos-a-sigmoide-e-o-logito
:::

## Por que a perda muda, e por que a solução fechada some

O [capítulo 05](05-modelos-lineares.md#a-deducao-em-cinco-passos) deduziu a reta ótima em cinco passos, e o quarto entregou uma fórmula. Aqui o mesmo caminho **não chega ao fim** — e vale entender onde ele para.

**Primeiro, a perda.** Usar erro quadrático sobre a saída da sigmoide dá uma superfície **não convexa**: aparecem mínimos locais, e o otimizador pode parar num deles. A perda usada é a **entropia cruzada** (ou *log-loss*):

$$L = -\frac{1}{n}\sum_{i=1}^{n}\left[y_i \log p_i + (1 - y_i)\log(1 - p_i)\right]$$

Ela é convexa em $w$, e tem uma leitura direta: pune **muito** a previsão confiante e errada. Prever 0,99 para quem era 0 custa $\log(0{,}01)$ — um número grande. Prever 0,5 custa pouco em comparação. O modelo aprende a ter medo de errar com convicção, que é exatamente o comportamento que se quer de uma probabilidade que vai virar decisão.

**Segundo, o que some.** Derivando a entropia cruzada e igualando a zero, chega-se a

$$\sum_{i=1}^{n}\left(\sigma(w \cdot x_i + b) - y_i\right)x_i = 0$$

que tem a **mesma forma** da condição do capítulo 05 — resíduo ortogonal ao atributo. Só que aqui o "resíduo" contém $\sigma(\cdot)$, e $w$ está **dentro** de uma função não linear. Não há como isolar $w$: o sistema é transcendental.

É por isso que a logística **não tem** equações normais, e o gradiente deixa de ser uma alternativa elegante para virar a única saída. A frase do capítulo 05 — *"o gradiente é a ferramenta geral; a solução fechada é o caso de sorte"* — recebe aqui a sua demonstração.

:::exercicio {"id":"28-e3","tipo":"multipla","objetivo":"O3","dificuldade":"media"}
Por que a regressão logística não tem solução fechada, como a linear tem?

- [ ] Porque a entropia cruzada não é diferenciável.
- [ ] Porque o problema não é convexo, e por isso não há mínimo único.
- [x] Porque, ao anular a derivada, os pesos ficam presos dentro da sigmoide — e o sistema resultante não é linear nos pesos.
- [ ] Porque a solução fechada exigiria inverter uma matriz singular.

> **gabarito:** Os pesos ficam presos dentro da sigmoide
> **porque:** A condição de otimalidade tem a mesma forma da linear — soma de (previsto − observado) vezes o atributo, igual a zero. A diferença é que "previsto" aqui é σ(w·x + b): o peso está **dentro** de uma função não linear, e não há álgebra que o isole. O sistema é transcendental, e se resolve por iteração.
>
> As duas primeiras alternativas invertem os fatos: a entropia cruzada **é** diferenciável, e o problema **é** convexo — há mínimo único, e é justamente por isso que o gradiente funciona bem aqui. A quarta confunde com um problema numérico da regressão linear (colinearidade perfeita torna a matriz singular), que é outra história.
> **volte para:** #por-que-a-perda-muda-e-por-que-a-solucao-fechada-some
:::

## Interpretar o coeficiente: chance, não probabilidade

Aumentar $x_j$ em uma unidade multiplica a **razão de chances** por $e^{w_j}$.

Um coeficiente de 0,7 significa chance multiplicada por $e^{0{,}7} \approx 2$ — **a chance dobra**. Não a probabilidade: a chance.

A diferença é grande e é onde os relatórios erram:

| Probabilidade antes | Chance antes | Chance depois (× 2) | Probabilidade depois |
|---|---|---|---|
| 0,10 | 0,11 | 0,22 | **0,18** |
| 0,50 | 1,00 | 2,00 | **0,67** |
| 0,90 | 9,00 | 18,00 | **0,95** |

O mesmo coeficiente move a probabilidade em 8, 17 e 5 pontos percentuais, dependendo de onde se estava. Por isso "este atributo aumenta o risco em X pontos" é uma frase sem sentido fora de um ponto específico.

E tudo o que o [capítulo 05](05-modelos-lineares.md#as-quatro-coisas-que-ele-nao-diz) diz sobre o que o coeficiente **não** significa continua valendo aqui, palavra por palavra: não é causa, não é comparável sem padronização, não é estável sob colinearidade e não vale fora da faixa observada.

:::exercicio {"id":"28-e2","tipo":"multipla-multi","objetivo":"O2","dificuldade":"dificil"}
Um modelo de risco de crédito, com atributos padronizados, tem coeficiente 0,7 para `dívida_atual`. Quais leituras são **corretas**? (marque todas que valem)

- [x] Um desvio-padrão a mais de dívida multiplica a razão de chances de inadimplência por aproximadamente 2.
- [ ] Um desvio-padrão a mais de dívida aumenta a probabilidade de inadimplência em 70 pontos percentuais.
- [ ] Reduzir a dívida do cliente reduziria o risco dele na proporção do coeficiente.
- [x] Se `dívida_atual` for muito correlacionada com `renda_comprometida`, este coeficiente pode ser instável entre reamostragens.
- [ ] Como o coeficiente é o maior do modelo, dívida é a causa principal da inadimplência.

> **gabarito:** multiplica a razão de chances por ~2 · pode ser instável sob colinearidade
> **porque:** A primeira correta é a leitura literal: e^0,7 ≈ 2,01, e o efeito é sobre a **razão de chances**, não sobre a probabilidade. A segunda correta é o alerta de colinearidade — dois atributos que medem quase a mesma coisa dividem o crédito de forma arbitrária, e a divisão muda com pequenas variações nos dados sem que a métrica piore.
>
> As três erradas são os três erros clássicos, nesta ordem de frequência: confundir logito com probabilidade (70 pontos percentuais é impossível — sequer respeita o intervalo [0,1]); ler correlação como intervenção ("reduzir a dívida reduziria o risco" é uma afirmação causal que o modelo não sustenta); e tratar magnitude de coeficiente como importância causal. As três aparecem em relatórios reais, e a terceira costuma aparecer no slide de recomendação.
> **volte para:** #interpretar-o-coeficiente-chance-nao-probabilidade
:::

## Mão na massa

A **etapa 05–06** do [`ml-zero`](../trilha-ml-zero.md) traz `RegressaoLogistica` em biblioteca padrão, com regularização L1 e L2 e leitura por `razao_de_chances()`. O otimizador é o mesmo da linear — só a função de perda muda, que é o ponto da arquitetura do [capítulo 06](06-otimizacao.md).

**Notebook** — [`regressao_limonada.ipynb`](https://github.com/GHDaru/machinelearning/blob/main/ml-zero/etapa-05/regressao_limonada.ipynb) cobre a linear. Um notebook próprio para a logística está na fila; enquanto isso, o caminho é importar `RegressaoLogistica` da mesma etapa e ajustar contra um rótulo binário.

## Assista

:::video {"id":"28-v1","fonte":"youtube","ref":"yIYKR4sgzI8","min":9,"autor":"StatQuest with Josh Starmer","titulo":"StatQuest: Logistic Regression"}
O que o texto explica algebricamente — a sigmoide comprimindo a reta, o logito voltando a ser linear — o vídeo mostra **geometricamente**, com a curva em S sendo ajustada aos pontos. Se a frase "o que é linear é o logito, não a probabilidade" ainda parece um detalhe técnico, este é o material que a transforma em imagem. Assista antes do exercício 28-e2.
:::

## Síntese — o que levar

- A logística **classifica**. O nome vem de modelar o **logito** com uma regressão linear.
- Teto e piso não são impostos ao modelo: são **consequência** de transformar a saída. Quando a resposta tem fronteiras e o modelo não, mude a escala da resposta.
- A perda é **entropia cruzada**, não erro quadrático — por convexidade, e porque punir a confiança errada é o comportamento desejado.
- **Não há solução fechada**: ao anular a derivada, o peso fica preso dentro da sigmoide.
- O coeficiente multiplica a **razão de chances** por $e^{w}$. O efeito em pontos percentuais depende de onde se estava.

## Verificação

1. Explique por que a regressão logística tem "regressão" no nome, sem usar a palavra "sigmoide".
2. Um coeficiente vale 1,1. Um colega diz que o atributo "aumenta o risco em 110%". O que está errado na frase, e qual seria a correta?
3. Por que usar erro quadrático com a sigmoide é uma má ideia — e qual das duas razões (convexidade ou punição do erro confiante) você considera a mais grave?
4. Onde exatamente a dedução do capítulo 05 para de funcionar aqui?

---

# 06 — Otimização e Regularização

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-05 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Explicar o gradiente descendente como procedimento, não como fórmula.
- **O2.** Diagnosticar taxa de aprendizado alta e baixa pelo comportamento da curva de perda.
- **O3.** Comparar regularização L1 e L2 quanto ao efeito sobre os coeficientes.
- **O4.** Justificar early stopping como forma de regularização.

## O problema: a perda não desce

"Treinei e não funcionou" é o relato mais comum de quem está começando — e o menos acionável, porque não diz nada. Quase todo problema de treino tem sintoma **visível na curva de perda**, e quem sabe lê-la economiza dias.

Este capítulo é sobre duas coisas que parecem opostas e são complementares: **descer** a paisagem da perda, e **impedir** que a descida vá longe demais.

## De onde isto veio

### A descida: Cauchy, 18 de outubro de 1847

**O aperto.** Augustin-Louis Cauchy queria calcular a **órbita de um corpo celeste**. Não pelas equações diferenciais do movimento, mas pelas equações finitas que o representam, tomando como incógnitas os próprios elementos da órbita — *"Então as incógnitas são em número de seis."* Seis incógnitas, resolvidas à mão, em 1847.

**O que se fazia antes.** Eliminação sucessiva: reduzir o sistema a uma equação só. Cauchy lista por que não serve, e a lista é honesta: *"1º que, num grande número de casos, a eliminação não pode efetuar-se de maneira alguma; 2º que a equação resultante é geralmente muito complicada, mesmo quando as equações dadas são bastante simples"*.

**A virada.** Se a função nunca é negativa, **não é preciso resolvê-la — basta fazê-la decrescer**. Nas palavras dele: *"Para achar os valores de x, y, z… que verificarão a equação u = 0, bastará fazer decrescer indefinidamente a função u, até que ela se anule."* Descer contra a derivada, um passo pequeno de cada vez.

**A ideia reaproveitável.** **Trocar "resolver" por "melhorar repetidamente".** Quando a solução fechada não existe, ou existe e explode em complexidade, aceita-se um procedimento que só garante *ficar melhor a cada passo*. É a troca fundadora de quase todo o Machine Learning — e a razão de o capítulo 05 ter duas implementações: a equação normal, que resolve, e o gradiente, que melhora.

**O nome.** O artigo se chama *"Méthode générale pour la résolution des systèmes d'équations simultanées"* (C. R. Acad. Sci. Paris, 25:536–538, 1847). "Método geral" — a palavra *gradiente* não está no título.

> **Dois detalhes que mudam como você lê este capítulo.**
>
> **O primeiro:** para um sistema de várias equações, Cauchy manda minimizar a soma dos quadrados dos resíduos. Ou seja — **o capítulo 06 executa o objetivo que o [capítulo 05](05-modelos-lineares.md) inventou.** Legendre e Gauss definiram *o que* é a melhor curva; Cauchy, quarenta anos depois, deu o *como* chegar nela sem resolver nada.
>
> **O segundo, e é o melhor antídoto que este livro tem contra a reverência:** Cauchy **não prova que o método converge, e sabe disso.** Ele escreve que se limita, por ora, a indicar os princípios, propondo-se a voltar ao assunto *"num próximo Memória"*. Esse próximo memorial, ao que se sabe, **nunca existiu**. O matemático mais rigoroso do século XIX publicou um algoritmo sem garantia e não voltou. Método não nasce provado — nasce funcionando, e a prova vem depois, se vier.

### O freio: Tikhonov, ridge e LASSO

Regularização vem de outro lugar: **problemas mal-postos**. Hadamard (1923) define o que é um problema *bem-posto* — solução existe, é única e depende de forma estável dos dados. Muitos problemas inversos reais falham na terceira condição: uma perturbação minúscula na entrada muda a resposta radicalmente. Tikhonov publica sobre estabilidade desses problemas em **1943**, e o método de regularização em **1963**; **D. L. Phillips** chega a algo equivalente de forma independente em 1962 — daí a forma "Tikhonov–Phillips".

Na estatística o mesmo movimento aparece como **ridge regression** (Hoerl & Kennard, *Technometrics*, 1970), e a origem é **industrial**: Hoerl vinha da engenharia química, e o "ridge" alude às **cristas dos gráficos de superfície de resposta**. Vinte e seis anos depois, o **LASSO** (Tibshirani, *JRSS-B*, 1996) herda diretamente do *non-negative garrote* de Breiman (1995), fundindo as duas etapas do garrote numa só.

**A ideia reaproveitável do bloco inteiro:** **aceitar erro sistemático de propósito para comprar estabilidade.** Tikhonov, ridge e LASSO são o mesmo gesto — o dado não determina a resposta, então você **impõe** uma preferência externa e assume o viés que ela introduz. É por isso que regularização não é um truque de implementação: é uma declaração sobre o que você acredita antes de ver os dados.

> **A ponte com o [capítulo 07](07-arvores-ensembles.md) é Breiman, e é uma ideia só: instabilidade.** Ele classificou os métodos entre estáveis (ridge) e instáveis (seleção de subconjunto), com o garrote no meio. Do lado "encolher coeficientes" nasce o LASSO, aqui. Do lado "instabilidade é oportunidade, não defeito" nasce o *bagging*, lá. **O mesmo diagnóstico gerou dois métodos em dois capítulos** — e conhecer o diagnóstico vale mais que conhecer os dois métodos.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ | Tudo o que é atribuído a Cauchy: o problema das seis incógnitas, a crítica à eliminação, a frase "fazer decrescer indefinidamente", a minimização da soma de quadrados, e a ausência do memorial prometido — via [Lemaréchal, *Cauchy and the Gradient Method*, Documenta Mathematica, 2012](https://ems.press/content/book-chapter-files/27368?nt=1), **lido por inteiro**, que transcreve o francês original em nota |
| ✓ᵐ | Hoerl & Kennard (*Technometrics* 12(1):55–67, 1970) e Tibshirani (*JRSS-B* 58(1):267–288, 1996): obra, ano e veículo |
| ⏳ | A cronologia de Tikhonov (1943, 1963) e a contribuição independente de Phillips (1962) |
| ⏳ | Que "ridge" vem das cristas dos gráficos de superfície de resposta |
| ⏳ | Que o LASSO herda do *non-negative garrote* de Breiman (1995) |
| ❌ | **Early stopping**: procurei e não localizei atribuição primária confiável. O capítulo ensina o método sem lhe atribuir inventor |
| 📖 | As duas ideias reaproveitáveis, a ligação com o cap. 05 e a ponte com o cap. 07 |

## Fundamentos: descer, sem enxergar a paisagem

Imagine estar numa encosta, no escuro, com um único instrumento: você sente a inclinação sob os pés. O procedimento é óbvio — dê um passo na direção mais íngreme para baixo, sinta de novo, repita.

Isso é gradiente descendente, inteiro. Formalmente:

$$w \leftarrow w - \eta \, \nabla L(w)$$

O gradiente $\nabla L$ aponta na direção de **maior crescimento**; o sinal negativo desce. A taxa $\eta$ é o **tamanho do passo**.

Três decisões, e só três, definem tudo o que acontece:

**1. Quanto do dado usar por passo.**

| Variante | Exemplos por passo | Consequência |
|---|---|---|
| **Lote** (*batch*) | todos | direção precisa, passo caro, trajetória lisa |
| **Mini-batch** | 32–256 | o padrão prático; ruído suficiente para escapar de vales rasos |
| **Estocástico** | 1 | passo baratíssimo, trajetória errática |

O ruído do mini-batch não é só tolerado: ele **ajuda**. Uma trajetória perfeitamente lisa desce até o primeiro vale e para lá.

**2. O tamanho do passo.** É o hiperparâmetro que mais decide entre sucesso e fracasso, e a próxima seção trata dele.

**3. Quando parar.** Aparentemente trivial, e o assunto da seção sobre *early stopping* — onde está a lição menos óbvia do capítulo.

## Diagnóstico pela curva de perda

Registre a perda a cada época e olhe o desenho. Quatro padrões cobrem quase tudo:

| Sintoma na curva | Diagnóstico | O que fazer |
|---|---|---|
| Sobe, oscila muito, ou vira NaN | **taxa alta demais** | dividir a taxa por 10 |
| Desce, mas quase imperceptivelmente | **taxa baixa demais** | multiplicar por 3–10 |
| Desce e estabiliza num patamar | convergiu | verificar se o patamar é bom o bastante |
| Desce no treino e **sobe** na validação | **overfitting** | regularizar, parar antes, mais dados |

A quarta linha é a única que exige duas curvas. Plote sempre as duas — treino e validação, no mesmo gráfico. Uma curva sozinha esconde exatamente o problema que mais custa caro.

### Uma sutileza que quase ninguém conta

Taxa alta demais **nem sempre** produz explosão. Medimos, na [etapa 05–06](../trilha-ml-zero.md):

- Com **regressão linear** (erro quadrático) e taxa 50, a perda explode e vira infinito. O erro quadrático não tem teto.
- Com **regressão logística** e taxa **500** — dez vezes maior —, a perda **não** explode. Ela satura.

Duas razões, e ambas valem entender. A perda logística é **limitada**: quando a sigmoide satura, o logaritmo é cortado e a perda para de crescer. E num problema linearmente separável, o primeiro gradiente já aponta na direção certa — um passo gigante nessa direção **acerta** em vez de explodir.

A lição prática: **"não explodiu" não é evidência de que a taxa está boa.** Confie na curva, não na ausência de NaN.

:::exercicio {"id":"06-e1","tipo":"multipla","objetivo":"O2","dificuldade":"media"}
A curva de perda de treino desce rapidamente nas primeiras épocas e depois oscila para cima e para baixo sem estabilizar, mantendo-se num patamar alto. Qual é o diagnóstico mais provável?

- [ ] Overfitting: o modelo decorou o treino.
- [x] Taxa de aprendizado alta demais: o passo salta por cima do mínimo e fica quicando em torno dele.
- [ ] Dados insuficientes.
- [ ] O modelo é simples demais para o problema.

> **gabarito:** Taxa de aprendizado alta demais
> **porque:** A assinatura é a **oscilação sem convergência** num patamar alto. O otimizador está dando passos maiores que a distância até o mínimo: chega perto, ultrapassa, volta, ultrapassa de novo. Divida a taxa por 10 e a oscilação vira descida.
>
> Overfitting (alternativa 1) tem assinatura totalmente diferente e exige **duas** curvas para ser visto: treino continua descendo enquanto validação sobe. Se você só tem a curva de treino, não pode diagnosticar overfitting — e essa é a razão de o capítulo insistir em plotar as duas juntas. Já "modelo simples demais" produziria uma curva que desce e estabiliza cedo, sem oscilar.
> **volte para:** #diagnostico-pela-curva-de-perda
:::

## Regularização: impedir que a descida vá longe demais

Minimizar o erro no treino até o fim é decorar. Regularizar é acrescentar à perda um termo que penaliza complexidade:

$$L_{\text{total}} = L_{\text{dados}} + \lambda \cdot \Omega(w)$$

O $\lambda$ controla o quanto você prefere um modelo simples a um modelo que ajusta bem. É o botão que anda na reta viés–variância do [capítulo 01](../01-fundamentos.md): $\lambda$ alto empurra para viés, $\lambda$ baixo para variância.

### L2 encolhe todos; L1 zera alguns

| | **L2** (Ridge) | **L1** (Lasso) |
|---|---|---|
| Penalidade | $\sum w_j^2$ | $\sum \lvert w_j \rvert$ |
| Efeito nos coeficientes | encolhe **todos**, nenhum vira zero | **zera** vários |
| Também serve para | estabilizar sob colinearidade | **selecionar atributos** |
| Gradiente da penalidade | $2w_j$ — proporcional ao peso | $\text{sign}(w_j)$ — **constante** |

A última linha explica as anteriores. O gradiente de L2 é proporcional ao peso: quanto mais perto de zero, mais fraco o empurrão — e o peso se aproxima de zero sem nunca chegar. O gradiente de L1 tem **magnitude constante**: o empurrão não enfraquece perto de zero, e o peso chega lá e fica.

Medimos, num problema com 2 atributos úteis e 8 de puro ruído:

| Regularização | Coeficientes não nulos | Atributos de ruído eliminados |
|---|---|---|
| **L2** (λ = 0,05) | **10 de 10** | 0 de 8 |
| **L1** (λ = 0,05) | menos de 10 | **pelo menos 4 de 8** |

E o L1 preservou os dois coeficientes úteis. Não é sorte: ele elimina preferencialmente o que não paga o próprio custo na perda.

:::exercicio {"id":"06-e2","tipo":"multipla","objetivo":"O3","dificuldade":"media"}
Você tem 300 atributos, suspeita que a maioria é irrelevante, e precisa entregar um modelo que a equipe consiga explicar. Qual regularização escolher, e por quê?

- [ ] L2, porque é mais estável numericamente.
- [x] L1, porque zera coeficientes e produz um modelo com menos atributos — que é o requisito de explicabilidade.
- [ ] Nenhuma: com 300 atributos, regularizar descarta informação.
- [ ] As duas dão o mesmo resultado; a escolha é indiferente.

> **gabarito:** L1
> **porque:** O requisito declarado é **explicabilidade**, e um modelo com 30 coeficientes não nulos é explicável de um jeito que um modelo com 300 coeficientes pequenos não é. L1 entrega isso porque o gradiente da penalidade tem magnitude constante — o empurrão para zero não enfraquece quando o peso se aproxima de zero, então ele chega lá.
>
> L2 é de fato mais estável numericamente e melhor sob colinearidade, mas **não zera nada**: você terminaria com 300 coeficientes pequenos, tecnicamente regularizados e praticamente ilegíveis. A terceira alternativa inverte a situação: com 300 atributos e suspeita de irrelevância, regularizar é justamente o que **preserva** informação útil, ao impedir que o modelo gaste capacidade ajustando ruído.
>
> Na prática há uma quarta opção que o capítulo não cobre e vale conhecer: *elastic net*, que combina as duas penalidades e costuma se comportar melhor quando os atributos irrelevantes são correlacionados entre si.
> **volte para:** #l2-encolhe-todos-l1-zera-alguns
:::

## Early stopping: a regularização de graça

Treine, e a cada época meça a perda **na validação**. Quando ela parar de melhorar por algumas épocas seguidas, pare — e fique com os pesos do melhor momento.

Não custa nada, não tem hiperparâmetro difícil, e funciona porque o treino percorre modelos em ordem crescente de complexidade: os pesos começam pequenos e crescem. Parar cedo é escolher um ponto anterior nessa trajetória — o mesmo efeito de uma penalidade, obtido de graça.

### As duas armadilhas que descobrimos implementando

**1. "Melhorou" precisa de um limiar.** A primeira versão do nosso otimizador considerava progresso qualquer melhora, por menor que fosse. Com melhoras de $4 \times 10^{-10}$ por época, o critério **nunca** disparava. Só faz sentido continuar se a perda caiu o bastante para valer outra época — daí o parâmetro `min_delta`.

**2. Monitorar treino é medir o que o modelo decorou.** Esta é a armadilha séria, e ela só apareceu porque um teste a expôs.

Com dados **separáveis**, a perda de treino cai indefinidamente: o modelo empurra os pesos para o infinito e a perda tende a zero sem nunca estagnar. Um *early stopping* que observa treino nunca dispara — e mesmo que disparasse, estaria medindo a coisa errada.

Pior: mesmo observando validação, o critério **só tem o que detectar se houver sobreajuste possível**. No nosso experimento com dados limpos e separáveis, nem a validação estagnava — não havia ponto a partir do qual ajustar mais piorasse. Foi preciso injetar ruído e atributos inúteis para o instrumento ter função.

> **A lição geral, que vale além do early stopping.** Um instrumento de diagnóstico pressupõe que o problema exista. Testar o instrumento num cenário sem o problema não valida nada — e pode passar a falsa impressão de que ele está quebrado.

:::exercicio {"id":"06-e3","tipo":"multipla-multi","objetivo":"O4","dificuldade":"dificil"}
Quais afirmações sobre early stopping são corretas? (marque todas que valem)

- [x] Deve ser monitorado na validação, não no treino.
- [x] Funciona como regularização porque o treino percorre modelos em ordem crescente de complexidade.
- [ ] Substitui completamente L1 e L2.
- [x] Precisa de um limiar mínimo de melhora, ou pode nunca disparar.
- [ ] Só faz sentido em redes neurais.

> **gabarito:** monitorar validação · regularização por trajetória · precisa de limiar mínimo
> **porque:** As três corretas são as que a implementação da etapa 05–06 tornou concretas — e as duas últimas foram descobertas na marra, não planejadas.
>
> **Validação, não treino**: com dados separáveis a perda de treino cai indefinidamente, e o critério mediria memória.
> **Regularização por trajetória**: os pesos crescem ao longo do treino, então parar antes seleciona um modelo menos complexo — o mesmo efeito de penalizar, sem penalizar.
> **Limiar mínimo**: sem `min_delta`, uma melhora de 4e-10 conta como progresso e o critério nunca dispara.
>
> As erradas: early stopping **complementa** L1/L2 e é rotineiro usá-los juntos — ele controla *quando* parar, elas controlam *para onde* ir. E ele vale para qualquer modelo treinado iterativamente, incluindo o gradient boosting do [capítulo 07](07-arvores-ensembles.md), onde é a forma padrão de escolher o número de árvores.
> **volte para:** #early-stopping-a-regularizacao-de-graca
:::

:::exercicio {"id":"06-e4","tipo":"completar","objetivo":"O1","dificuldade":"facil"}
Complete o nome do hiperparâmetro que define o **tamanho do passo** na atualização abaixo:

`w ← w − ______ × ∇L(w)`

> **gabarito:** taxa de aprendizado|learning rate|taxa|eta|η
> **porque:** É a **taxa de aprendizado** (η), e ela é o hiperparâmetro que mais decide entre um treino que funciona e um que não funciona. Alta demais: o passo salta por cima do mínimo e a perda oscila ou explode. Baixa demais: a perda desce imperceptivelmente e o treino termina antes de chegar a lugar nenhum.
>
> Repare que ela não muda *para onde* ir — o gradiente já decidiu a direção. Ela só decide **quanto** andar naquela direção. Confundir as duas coisas é a origem da tentativa comum e inútil de "consertar a direção" mexendo na taxa.
> **volte para:** #fundamentos-descer-sem-enxergar-a-paisagem
:::

## Mão na massa

A **etapa 05–06** do [`ml-zero`](../trilha-ml-zero.md) traz o otimizador **isolado do modelo**:

```python
def descida_de_gradiente(grad, n_parametros, n_exemplos, taxa, epocas,
                         lote=None, paciencia=None, min_delta=1e-6,
                         monitorar=None, seed=0)
```

Quem decide *o que* minimizar é o modelo, que passa a função `grad`. O otimizador só sabe descer. Essa separação é a arquitetura hexagonal nascendo da dor (regra 2 da construção): ela não foi projetada de antemão — apareceu quando linear e logística precisaram do mesmo laço com perdas diferentes.

O `Historico` que ele devolve é o instrumento de diagnóstico: `divergiu()`, `estagnou()`, e a lista de perdas para plotar.


**Notebook pronto para executar** — [`regressao_limonada.ipynb`](https://github.com/GHDaru/machinelearning/blob/main/ml-zero/etapa-05/regressao_limonada.ipynb) · [abrir no Colab](https://colab.research.google.com/github/GHDaru/machinelearning/blob/main/ml-zero/etapa-05/regressao_limonada.ipynb)

É o notebook do capítulo 05 — a mesma etapa serve aos dois. Troque `solucao_fechada=True` por `False` na célula do ajuste e confira que gradiente e equações normais chegam ao mesmo lugar.

> Na sua máquina: `pip install notebook` e `jupyter notebook`, ou abra a pasta no VS Code. O notebook **não precisa do repositório clonado** — se você estiver no Colab, ele baixa sozinho os arquivos de que precisa. Como rodar a trilha inteira: [`ml-zero`](https://github.com/GHDaru/machinelearning/blob/main/ml-zero/README.md).

## Assista

:::video {"id":"06-v1","fonte":"youtube","ref":"sDv4f4s2SB8","min":24,"autor":"StatQuest with Josh Starmer","titulo":"Gradient Descent, Step-by-Step"}
Vinte e quatro minutos, e valem cada um. O vídeo faz a conta **à mão**, passo a passo, num exemplo minúsculo: calcula o gradiente, dá o passo, recalcula. É o que a fórmula `w ← w − η∇L` esconde — que ela descreve um procedimento repetitivo e concreto, não uma operação abstrata. Se o gradiente ainda parece magia, é este material que resolve.
:::

## Síntese — o que levar

- Gradiente descendente é um **procedimento**: sinta a inclinação, dê um passo, repita. Três decisões — quanto de dado por passo, tamanho do passo, quando parar.
- **Plote treino e validação juntos.** Uma curva sozinha não consegue mostrar overfitting.
- "Não explodiu" não prova que a taxa está boa: perda logística é **limitada** e satura em vez de divergir.
- **L2 encolhe todos, L1 zera alguns** — porque o gradiente de L1 tem magnitude constante perto de zero. L1 é também seleção de atributos.
- **Early stopping** é regularização de graça, mas exige monitorar **validação** e um **limiar mínimo** de melhora. E só tem o que detectar se houver sobreajuste possível.

## Verificação

1. Explique por que o ruído do mini-batch pode ajudar, em vez de atrapalhar.
2. Sua perda de treino desce bem e a de validação desce e depois sobe. Que três intervenções você tentaria, em que ordem?
3. Por que L1 zera coeficientes e L2 não? Responda pelo gradiente da penalidade, não pelo formato da curva.

---

# 07 — Árvores e Ensembles

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-05 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Explicar como uma árvore de decisão escolhe cada divisão.
- **O2.** Distinguir bagging de boosting quanto ao erro que cada um ataca.
- **O3.** Ajustar os hiperparâmetros de um modelo de boosting na ordem que importa.
- **O4.** Justificar por que boosting em dados tabulares continua competitivo com deep learning.

## O problema: a fronteira que a reta não alcança

Um sistema precisa detectar consumo anômalo de energia. A regra real, que ninguém escreveu porque ninguém a conhecia inteira, é esta:

- consumo **muito alto** fora do horário comercial é anomalia;
- consumo **muito baixo** também é — medidor quebrado, fraude por desvio;
- consumo intermediário, em qualquer horário, é normal.

Um modelo linear não consegue expressar isso. Nem com mais dados, nem com mais tempo de treino. A razão é estrutural: uma reta é monotônica em cada atributo — se "mais consumo" empurra para anomalia, ele empurra sempre, no mesmo sentido. E aqui os **dois extremos** são anomalia e o **meio** é normal.

Medimos. No dado do experimento da [etapa 07](../trilha-ml-zero.md), com o teto teórico em 0,9402 de AUC:

| Modelo | AUC | % do teto |
|---|---|---|
| **Linear** | **0,4963** | 52,8% |
| Árvore (profundidade 3) | 0,9201 | 97,9% |
| Floresta (25 árvores) | 0,9332 | 99,3% |
| Boosting (50 árvores, η=0,2) | **0,9392** | **99,9%** |

O modelo linear está em 0,4963 — **acaso**. Não é que ele vá mal; é que ele não tem como ir bem. Já uma árvore de **profundidade 3** — três perguntas encadeadas — chega a 98% do teto.

## De onde isto veio

### As árvores: Breiman fora da universidade

**O aperto.** Leo Breiman **deixou a academia em 1967** e passou treze anos como consultor, voltando a Berkeley só em **1980**. Nesse período ele modelou coisas como padrões de tráfego em autoestradas, gargalos no sistema judiciário e o nível de ozônio do dia seguinte na bacia de Los Angeles. Três características em comum, e nenhuma delas aparece num seminário de estatística: **variáveis de tipos misturados** (número, categoria, ordem), **dados faltando** por razões banais, e o resultado tendo de ser explicado a quem **não lê estatística** — um juiz, um engenheiro de tráfego, um secretário municipal.

**O que se fazia antes.** Modelos paramétricos que exigiam que o consultor jurasse a forma da relação antes de olhar o dado, e que devolviam uma equação impossível de defender numa reunião com quem decide.

**A virada.** Um modelo que **é a própria explicação**: uma sequência de perguntas binárias sobre os atributos. A árvore não aproxima uma função e depois se explica — ela **já é** o organograma da decisão. E lida com tipo misto sem esforço, porque cada corte só precisa saber comparar dentro de um atributo.

**A ideia reaproveitável.** **A restrição de quem vai usar o resultado é um requisito de projeto, não uma limitação a lamentar.** CART tem a forma que tem porque nasceu na consultoria e não no seminário. Sempre que você escolher um modelo, a pergunta "quem vai precisar defender esta decisão, e para quem?" muda a resposta — e é uma pergunta técnica, não política.

**O nome.** *Classification and Regression Trees* (Breiman, Friedman, Olshen & Stone, Wadsworth, **1984**). Em paralelo, na linha da inteligência artificial, Quinlan desenvolve o **ID3** — *Iterative Dichotomiser 3* —, herdeiro do CLS de Hunt (1966); conta-se que o gatilho foi um desafio de Donald Michie: decidir, só por atributos do tabuleiro, se um final de xadrez Rei-Torre contra Rei-Cavalo está perdido em número fixo de lances.

### O boosting: uma pergunta que virou algoritmo

Esta é a origem menos conhecida e a mais instrutiva do capítulo, porque **ninguém estava procurando boosting**.

Em **1988**, Michael Kearns e Leslie Valiant fizeram uma pergunta **teórica**: um aprendiz que só acerta um pouco mais que o acaso pode ser transformado num aprendiz arbitrariamente bom? Era uma questão sobre **limites do possível**, não um pedido de algoritmo. Em **1990**, Robert Schapire respondeu que **sim** — e a prova era **construtiva**. A construção era o método. AdaBoost, com Freund, vem em seguida.

**A ideia reaproveitável.** **Uma pergunta bem-posta sobre limites vira algoritmo.** Quando você consegue formular precisamente *"isto é possível?"*, a resposta afirmativa frequentemente já contém o *como*. Vale mais aprender isso do que decorar o AdaBoost.

> **Repare no relógio.** Em quase todo o resto deste livro, a distância entre a ideia e o procedimento utilizável é de décadas: 1943→1958 no [capítulo 18](18-neuronio-artificial.md), 1927→1970 no [24](24-series-temporais.md), 1931→1974 no [01](../01-fundamentos.md). No boosting são **sete anos** — pergunta em 1988, resposta em 1990, algoritmo em 1995.
>
> A diferença não é a época nem o computador. É que aqui **o aperto já estava formulado como uma pergunta formal precisa**. Quando a pergunta é vaga, a espera é longa; quando é exata, a resposta traz o método junto. Isso é uma dica prática sobre como gastar o seu tempo: afiar a pergunta costuma render mais que procurar a solução.

### E a ponte com o capítulo 06

Bagging — *bootstrap aggregating*, Breiman, 1996 — vem do mesmo diagnóstico que produziu o LASSO no [capítulo 06](06-otimizacao.md): **instabilidade**. Breiman classificou métodos entre estáveis e instáveis, e a árvore é o caso extremo de instável — mude poucos exemplos e a árvore inteira muda.

Do lado "instabilidade é defeito, encolha os coeficientes" saiu a regularização. Do lado **"instabilidade é insumo"** saiu o bagging: se o modelo varia muito com o dado, então **perturbe de propósito** e tire a média. Random Forests (2001) é a mesma frase dita de novo, com uma perturbação a mais. **O mesmo diagnóstico, dois métodos, dois capítulos.**

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ᵐ | Breiman deixando a academia em 1967, os treze anos de consultoria, o retorno em 1980 e os três exemplos de projeto — [memorial da Estatística de Berkeley](https://statistics.berkeley.edu/about/memoriam/memory-leo-breiman) |
| ✓ᵐ | CART (1984), *bagging* (*Machine Learning* 24:123–140, 1996), Random Forests (2001), Schapire (*Machine Learning* 5:197–227, 1990): obra, ano e veículo |
| ⏳ | A pergunta de Kearns & Valiant (1988) e sua formulação como manuscrito sobre *hypothesis boosting* |
| ⏳ | O desafio de Michie a Quinlan e o final Rei-Torre × Rei-Cavalo; a filiação do ID3 ao CLS de Hunt (1966) |
| ❌ | O **nome do projeto de consultoria específico** que gerou o CART — procurei e não achei em primária |
| 📖 | As três ideias reaproveitáveis, a leitura sobre o relógio do boosting e a ponte com o capítulo 06 |

> **Números deste capítulo.** Todos saem de [`ml-zero/etapa-07/rodar.py`](https://github.com/GHDaru/machinelearning/blob/main/ml-zero/etapa-07/rodar.py), com seed fixa. Rodar duas vezes dá o mesmo resultado (Princípio II).

> ⚠ **Honestidade sobre o experimento.** O dado foi **construído** com uma regra que é literalmente uma árvore pequena — uma interação e uma quebra. Árvores têm vantagem estrutural aqui **por construção**, e seria desonesto apresentar isso como descoberta. O experimento serve para tornar visível *por que* a vantagem existe, não para provar que ela sempre existe. A evidência de que dado tabular real tende a ter essa forma está em Grinsztajn et al. (2022), adiante.

## Fundamentos: como a árvore escolhe cada corte

Uma árvore de decisão é uma sequência de perguntas binárias. A única decisão real é: **qual pergunta fazer em cada nó?**

O procedimento é guloso e local. Em cada nó, para cada atributo, para cada corte possível, mede-se quanto o corte reduz a **impureza** — e escolhe-se o melhor. Depois repete-se nos dois filhos, sem nunca reconsiderar o corte anterior.

A impureza mais usada em classificação é o **Gini**:

$$\text{Gini}(p) = 2p(1-p)$$

onde $p$ é a proporção da classe positiva no nó. A intuição vale mais que a fórmula: é a chance de você errar se chutasse a classe sorteando pela distribuição do próprio nó. Zero quando o nó é puro (só uma classe); máximo em $p = 0{,}5$ (moeda honesta).

O **ganho** de um corte é a impureza do pai menos a média ponderada da impureza dos filhos:

$$\text{ganho} = \text{Gini}(\text{pai}) - \frac{n_e}{n}\text{Gini}(\text{esq}) - \frac{n_d}{n}\text{Gini}(\text{dir})$$

Três consequências que explicam quase todo comportamento de árvore:

1. **O corte é local e definitivo.** A árvore nunca desfaz uma decisão anterior. Por isso ela é rápida e por isso ela às vezes erra feio: um corte ruim no topo compromete tudo abaixo.
2. **Escala não importa.** Multiplicar um atributo por mil não muda a ordem dos valores, e o corte depende só da ordem. É por isso que árvores dispensam normalização — ao contrário de tudo que usa distância ou gradiente (cap. 03 e 06).
3. **Atributos inúteis são ignorados de graça.** Se nenhum corte de um atributo dá ganho, ele simplesmente não aparece na árvore. Guarde este ponto: ele volta no fim do capítulo.

:::exercicio {"id":"07-e1","tipo":"multipla","objetivo":"O1","dificuldade":"media"}
Um nó contém 100 exemplos, 50 de cada classe. Um corte candidato produz um filho com 50 exemplos (45 positivos, 5 negativos) e outro com 50 (5 positivos, 45 negativos). Qual é o ganho de Gini desse corte?

- [ ] 0,000 — o corte não ajuda, porque cada filho ainda tem as duas classes.
- [x] Aproximadamente 0,320.
- [ ] 0,500 — o corte separa metade dos exemplos.
- [ ] Não dá para calcular sem saber qual atributo foi usado.

> **gabarito:** Aproximadamente 0,320
> **porque:** Gini do pai: 2 × 0,5 × 0,5 = **0,5**. Cada filho tem p = 45/50 = 0,9, logo Gini = 2 × 0,9 × 0,1 = **0,18**. Como os dois filhos têm o mesmo tamanho, a média ponderada é 0,18. Ganho = 0,5 − 0,18 = **0,32**.
>
> A primeira alternativa é o mal-entendido que vale corrigir: um corte não precisa deixar os filhos **puros** para valer muito. Ele precisa deixá-los **mais puros que o pai** — e este corte quase resolve o problema. Já a última alternativa confunde o que a fórmula usa: o ganho depende só de **como os exemplos se distribuem** entre os filhos, nunca de qual atributo produziu a separação. Por isso a mesma conta serve para qualquer atributo, e por isso escala não importa.
> **volte para:** #fundamentos-como-a-arvore-escolhe-cada-corte
:::

## Uma árvore sozinha tem variância alta

Árvore profunda decora. Isso já era esperado do [capítulo 01](../01-fundamentos.md) — mais capacidade, mais variância. O que o capítulo 01 não mostrou é **quanto**.

Medindo a variância da predição, Var[f̂(x)], sobre 5 reamostragens *bootstrap* do treino:

| Modelo | Var[f̂(x)] |
|---|---|
| Árvore (profundidade 12) | 0,04066 |
| Floresta (12 árvores) | **0,00676** |

**Seis vezes menos.** Treine a mesma árvore profunda em amostras ligeiramente diferentes do mesmo fenômeno e ela produz previsões visivelmente diferentes para o mesmo cliente. A floresta, não.

É essa instabilidade — não a falta de acerto — que os *ensembles* atacam primeiro.

## Bagging e boosting atacam erros diferentes

Aqui está a ideia que organiza o capítulo inteiro, e a que mais rende em entrevista e em projeto:

| | **Bagging** (floresta aleatória) | **Boosting** (gradient boosting) |
|---|---|---|
| Ataca | **variância** | **viés** |
| Como treina | árvores **em paralelo**, independentes | árvores **em sequência**, cada uma corrigindo a anterior |
| Cada árvore vê | reamostragem com reposição + subconjunto de atributos | todos os dados, mas o **resíduo** do que já foi previsto |
| Árvore individual | profunda, forte, instável | rasa, fraca, estável |
| Se você adicionar árvores demais | satura (não piora) | **passa a overfitar** |
| Paraleliza | trivialmente | não (é sequencial por definição) |

### Bagging: a média de modelos descorrelacionados

Treine 25 árvores, cada uma numa reamostragem com reposição, e tire a média. Cada árvore individual é *pior* que a árvore única treinada em tudo — viu menos dados úteis. A média delas é melhor.

Isso é contraintuitivo até você ligar à decomposição: a média de $B$ estimadores independentes com variância $\sigma^2$ tem variância $\sigma^2/B$. O viés não muda — a média de modelos igualmente enviesados é igualmente enviesada. **Bagging não deixa o modelo mais esperto; deixa-o mais estável.**

E há um segundo truque, esse de Breiman (2001, ✓): sortear um **subconjunto de atributos em cada nó**. Sem isso, as árvores ficam parecidas demais (todas escolhem o mesmo atributo forte no topo) e a média melhora pouco. Estimadores só se cancelam se forem descorrelacionados — e a subamostragem força a descorrelação.

### Boosting: cada árvore corrige o erro da anterior

Comece com uma previsão constante. Calcule o **resíduo** — o quanto cada exemplo ficou errado. Ajuste uma árvore rasa a esse resíduo. Some uma fração dela à previsão. Recalcule o resíduo. Repita.

Cada árvore é deliberadamente fraca: profundidade 3, no experimento. Sozinha, ela vale 0,9201 de AUC. **Cinquenta delas, somadas com passo 0,2, chegam a 0,9392** — 99,9% do teto teórico. É viés atacado por acumulação de correções, não por capacidade individual.

A **taxa de aprendizado** η encolhe cada contribuição. Passo pequeno com muitas árvores generaliza melhor que passo grande com poucas — o mesmo fenômeno que o [capítulo 06](06-otimizacao.md) trata como regularização.

:::exercicio {"id":"07-e2","tipo":"multipla","objetivo":"O2","dificuldade":"media"}
Uma equipe treina uma floresta aleatória com 50 árvores e obtém 0,88 de AUC na validação. Aumentam para 500 árvores. O que se espera?

- [ ] A AUC vai cair, porque 500 árvores causam overfitting.
- [x] A AUC vai melhorar pouco ou nada, e depois estabilizar — mais árvores em bagging saturam, não pioram.
- [ ] A AUC vai subir proporcionalmente ao número de árvores.
- [ ] Impossível dizer sem saber a profundidade das árvores.

> **gabarito:** Vai melhorar pouco ou nada, e estabilizar
> **porque:** Em bagging, cada árvore nova é mais um termo na média. A variância da média cai com 1/B, então o ganho por árvore diminui rapidamente — de 50 para 500 você multiplica o custo por 10 para reduzir a variância residual por um fator pequeno. **Não piora**: adicionar termos a uma média não introduz overfitting, porque nenhuma árvore nova está tentando corrigir os erros das anteriores.
>
> É exatamente aqui que bagging e boosting se separam. Em **boosting**, cada árvore nova é ajustada ao resíduo — ou seja, ela persegue ativamente o que sobrou, inclusive o ruído. Por isso, em boosting, o número de árvores **é** um hiperparâmetro de regularização, e o excesso degrada a validação.
>
> Se você respondeu "vai cair", você aplicou a intuição de boosting a bagging. É o erro mais comum do capítulo, e a razão de a tabela comparativa existir.
> **volte para:** #bagging-e-boosting-atacam-erros-diferentes
:::

:::exercicio {"id":"07-e3","tipo":"multipla-multi","objetivo":"O2","dificuldade":"dificil"}
Quais afirmações sobre a floresta aleatória são corretas? (marque todas que valem)

- [x] Cada árvore individual é tipicamente pior que uma única árvore treinada em todos os dados.
- [x] Sortear atributos em cada nó existe para descorrelacionar as árvores.
- [ ] O treino é sequencial: cada árvore depende do resultado da anterior.
- [x] Normalizar os atributos não muda o resultado.
- [ ] A floresta reduz o viés do modelo em relação a uma árvore única.

> **gabarito:** cada árvore é pior · sortear atributos descorrelaciona · normalizar não muda nada
> **porque:** As três corretas são as propriedades que definem bagging. A primeira é contraintuitiva e verdadeira: cada árvore vê uma reamostragem com reposição, na qual cerca de 37% dos exemplos originais não aparecem — ela treina com menos informação. A média é melhor porque os erros individuais se cancelam parcialmente, e isso exige que eles sejam **independentes**, que é o que a segunda propriedade compra. A terceira decorre de o corte depender só da ordem dos valores, e ordem é invariante a escala.
>
> As duas erradas trocam bagging por boosting e variância por viés. Treino sequencial é boosting. E reduzir viés é boosting: a média de modelos igualmente enviesados tem o mesmo viés — não há como a floresta representar uma função que suas árvores não representam.
> **volte para:** #bagging-a-media-de-modelos-descorrelacionados
:::

## A ordem de ajuste que economiza tempo

Boosting tem muitos hiperparâmetros e eles interagem. Ajustá-los na ordem errada custa dias. A ordem que funciona:

| # | Ajuste | Por quê primeiro |
|---|---|---|
| 1 | **Profundidade** (3–8) | define que tipo de interação o modelo consegue capturar. Profundidade 1 (tocos) só captura efeitos aditivos; 3 já captura interações de três vias |
| 2 | **Taxa de aprendizado + número de árvores**, **juntos** | são um par: baixar η exige subir o número de árvores. Fixe η baixo (0,05–0,1) e deixe o *early stopping* na validação decidir quantas |
| 3 | **Subamostragem** de linhas e colunas (0,6–0,9) | injeta o ingrediente do bagging dentro do boosting: reduz variância e acelera |
| 4 | **Regularização** (mínimo por folha, penalidades) | ajuste fino; só rende depois que os três acima estão razoáveis |

O erro caro é começar pelo item 4 — mexer em regularização com profundidade errada é otimizar a decoração de uma casa cuja planta está errada.

E use **early stopping** desde o começo: em vez de escolher o número de árvores por busca, treine muitas e pare quando a validação parar de melhorar. É o hiperparâmetro que se ajusta sozinho.

:::exercicio {"id":"07-e4","tipo":"numerica","objetivo":"O3","dificuldade":"media"}
Um modelo de boosting foi treinado com taxa de aprendizado η = 0,2 e 50 árvores. Você decide reduzir a taxa para 0,05, mantendo o mesmo "caminho percorrido" pelo modelo. Aproximadamente quantas árvores serão necessárias?

> **gabarito:** 200 ± 5
> **porque:** A contribuição total é aproximadamente o produto η × número de árvores. Dividir a taxa por 4 (de 0,2 para 0,05) exige multiplicar o número de árvores por 4: 50 × 4 = **200**.
>
> A regra é aproximada de propósito, e é útil justamente por ser grosseira: ela dá o ponto de partida da busca, não o valor final. Na prática, taxa menor com mais árvores costuma terminar **um pouco melhor** que a configuração equivalente com taxa maior — passos menores exploram a paisagem com mais cuidado e o efeito regularizador é real. Por isso a receita do item 2 é fixar η baixo e deixar o early stopping decidir o número, em vez de buscar os dois numa grade.
> **volte para:** #a-ordem-de-ajuste-que-economiza-tempo
:::

## Fundamentos científicos: por que árvores ainda ganham em tabular

A afirmação "gradient boosting continua sendo a resposta padrão para dados tabulares" é forte, e neste livro ela não vale por repetição — vale por medição de terceiros, verificada.

**Grinsztajn, Oyallon & Varoquaux (2022)** ([arXiv:2207.08815](https://arxiv.org/abs/2207.08815), ✓) montaram um *benchmark* de **45 datasets tabulares** de domínios variados, comparando modelos de árvore com métodos de deep learning padrão e específicos para tabular, sob buscas extensas de hiperparâmetros. O resultado: **modelos baseados em árvore permanecem no estado da arte em dados de porte médio (~10 mil exemplos)** — e isso sem sequer contabilizar a vantagem de velocidade.

O mais útil do trabalho não é o placar, é o **diagnóstico**. Eles identificam três características do dado tabular que explicam a diferença:

1. **Atributos não informativos.** Bases tabulares reais vêm cheias de colunas irrelevantes. Árvores as ignoram de graça — nenhum corte, nenhum ganho, nenhuma presença. Redes precisam aprender a zerá-las, e nem sempre conseguem.
2. **Funções irregulares.** A relação entre atributo e alvo tem quebras, patamares e interações abruptas. Redes têm viés a favor de funções suaves; árvores não têm viés nenhum a favor de suavidade.
3. **Orientação dos eixos.** Em dados tabulares cada coluna tem significado próprio, e árvores cortam ao longo dos eixos — o que casa com a estrutura. Redes são invariantes a rotação, uma propriedade que ajuda em imagem e atrapalha aqui.

Repare que o experimento deste capítulo foi construído com exatamente as características 1 e 2 — três atributos de puro ruído e uma fronteira com quebra e interação. Ele **ilustra** o mecanismo que o paper **mede**. As duas coisas são diferentes, e confundi-las seria vender ilustração como evidência.

> **Cláusula de expiração.** Escrevo em 2026 que gradient boosting é a escolha padrão para tabular de porte médio, sustentado por Grinsztajn et al. (2022). Esta é a afirmação com maior chance de envelhecer neste livro: há trabalho ativo em arquiteturas tabulares e em modelos de fundação para tabular. O gatilho de revisão é claro: **um benchmark independente, com o mesmo rigor de busca de hiperparâmetros, mostrando vantagem consistente de um método não-árvore em dados de porte médio**. Acompanhamento no [placar de expiração](../HISTORICO.md).

:::exercicio {"id":"07-e5","tipo":"aberta","objetivo":"O4","pontos":3,"dificuldade":"dificil"}
Sua equipe tem 8.000 linhas, 40 colunas tabulares, e um prazo de duas semanas. Um colega propõe começar por uma rede neural profunda, argumentando que "deep learning é o estado da arte".

Escreva a resposta que você daria: qual sua **recomendação**, com que **evidência**, e em que **condição** você mudaria de ideia.

> **rubrica:** recomenda começar por um modelo de árvore/boosting, com linha de base antes;
> sustenta a recomendação em evidência citável, não em preferência pessoal;
> menciona ao menos um dos três mecanismos (atributos não informativos, funções irregulares, orientação dos eixos) e não apenas o placar;
> declara uma condição concreta que mudaria a recomendação, em vez de tratá-la como regra absoluta;
> considera o custo de iteração dentro do prazo, e não só a métrica final
> **porque:** A recomendação defensável é **boosting**, e o argumento tem três camadas. **Evidência**: 8.000 linhas e 40 colunas caem exatamente no regime medido por Grinsztajn et al. (2022) — porte médio, tabular —, onde modelos de árvore permanecem no estado da arte. **Mecanismo**: entre 40 colunas quase certamente há colunas irrelevantes, que árvores descartam sem custo. **Prazo**: boosting treina em minutos e tem poucos hiperparâmetros que importam, o que permite muitas iterações em duas semanas — e o número de iterações costuma decidir mais que a escolha de família de modelo.
>
> A parte que separa uma boa resposta de uma dogmática é a **condição de mudança**. Exemplos legítimos: se houver texto livre ou imagem entre as colunas, se o volume crescer uma ou duas ordens de grandeza, se houver um modelo pré-treinado do domínio para aproveitar, ou se o requisito for aprender representação transferível para outra tarefa. Uma resposta que apenas afirma "árvore sempre ganha em tabular" acerta a recomendação e erra o raciocínio — e é essa a diferença que o exercício mede.
> **volte para:** #fundamentos-cientificos-por-que-arvores-ainda-ganham-em-tabular
:::

## Mão na massa

A **etapa 07** do [`ml-zero`](../trilha-ml-zero.md) implementa os três modelos em ~250 linhas de biblioteca padrão — sem NumPy, sem scikit-learn:

1. `Arvore` — CART com Gini para classificação e erro quadrático para regressão (é a segunda que o boosting usa);
2. `Floresta` — bagging com subamostragem de atributos por nó;
3. `Boosting` — árvores sequenciais sobre o resíduo, com perda logística e taxa de aprendizado;
4. `auc` — pelo método dos postos, com empates tratados;
5. `rodar.py` — o experimento inteiro, que produz a tabela deste capítulo.

Três lições do capítulo estão escritas como **testes que falham** se deixarem de ser verdade: bagging corta a variância pela metade ou mais; a reta não alcança a fronteira irregular; e ninguém passa do teto de Bayes — passar indicaria vazamento (cap. 02).


**Notebook pronto para executar** — [`arvores_ensembles.ipynb`](https://github.com/GHDaru/machinelearning/blob/main/ml-zero/etapa-07/arvores_ensembles.ipynb) · [abrir no Colab](https://colab.research.google.com/github/GHDaru/machinelearning/blob/main/ml-zero/etapa-07/arvores_ensembles.ipynb)

Os quatro modelos treinados no mesmo dado, com a AUC de cada um. A última célula aumenta o ruído e mostra a vantagem do ensemble encolher — ela é propriedade **do terreno**, não uma constante.

> Na sua máquina: `pip install notebook` e `jupyter notebook`, ou abra a pasta no VS Code. O notebook **não precisa do repositório clonado** — se você estiver no Colab, ele baixa sozinho os arquivos de que precisa. Como rodar a trilha inteira: [`ml-zero`](https://github.com/GHDaru/machinelearning/blob/main/ml-zero/README.md).

## Assista

:::video {"id":"07-v1","fonte":"youtube","ref":"3CC4N4z3GJc","min":15,"autor":"StatQuest with Josh Starmer","titulo":"Gradient Boost Part 1: Regression Main Ideas"}
Boosting é o conceito deste capítulo que a prosa explica mal, porque ele é um processo **iterativo** — e prosa é linear. O vídeo constrói o modelo passo a passo numa tabela pequena: previsão inicial, resíduo, árvore no resíduo, nova previsão, novo resíduo. Ver a coluna de resíduos encolhendo a cada rodada é o que transforma "cada árvore corrige a anterior" de frase decorada em mecanismo entendido. Assista antes do exercício 07-e4.
:::

## Síntese — o que levar

- Árvore corta por **ganho de impureza**, de forma gulosa e local. Dispensa normalização e ignora atributo inútil de graça.
- Uma árvore profunda tem **variância alta**: no experimento, 6× a da floresta.
- **Bagging ataca variância** (paralelo, árvores fortes, satura); **boosting ataca viés** (sequencial, árvores fracas, pode overfitar).
- Ordem de ajuste do boosting: profundidade → (taxa + nº de árvores, juntos) → subamostragem → regularização. Com **early stopping** desde o começo.
- Em tabular de porte médio, **árvores continuam no estado da arte** (Grinsztajn et al., 2022) — por três mecanismos, não por magia: atributos inúteis, funções irregulares e orientação dos eixos.
- E a afirmação tem prazo. O gatilho de revisão está escrito.

## Verificação

1. Explique, sem usar a palavra "variância", por que a média de 25 árvores é melhor que a melhor árvore isolada.
2. Você aumenta o número de árvores de um modelo e a validação piora. Isso é bagging ou boosting? Como você sabe?
3. Um colega diz que normalizou os atributos e a floresta melhorou. Que explicações são possíveis?

---

# 23 — Análise Multidimensional

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Modelar um domínio em esquema estrela, distinguindo fatos de dimensões.
- **O2.** Executar operações OLAP: drill-down, roll-up, slice, dice e pivot.
- **O3.** Justificar a desnormalização deliberada de um repositório analítico.
- **O4.** Relacionar o cubo à tabela que um modelo preditivo consome.

## O problema: vendas por produto, por região, por trimestre

Você já viu SQL. Então já viu esta cena: a diretora pede "vendas por produto, por região, por trimestre" — e você escreve um `GROUP BY` com três colunas, três `JOIN` e um `SUM`. Funciona. Aí ela pergunta: "e sem a região Sul?". Depois: "e agora por categoria em vez de produto?". Depois: "e mês a mês, só no Nordeste?". Cada pergunta é uma consulta nova, escrita do zero, que varre a mesma base de novo.

O aperto é estrutural. O modelo relacional é excelente para **transação** — normalizado para escrever rápido e sem inconsistência. E é desajeitado para a **pergunta gerencial típica**, que agrega em vários eixos ao mesmo tempo e muda de eixo a cada trinta segundos de reunião. São dois objetivos opostos no mesmo banco, e o segundo sempre perde: a consulta demora, e quem perguntou já mudou de assunto.

O erro que este capítulo previne é tratar isso como problema de otimização de SQL. Não é. É problema de **modelo de dados**.

## De onde isto veio

**O aperto.** Anos 1980–90: as empresas já tinham o dado transacional em bancos relacionais e não conseguiam interrogá-lo na velocidade da conversa. O analista pedia um relatório; o relatório vinha no dia seguinte, respondendo a uma pergunta que já não era a pergunta.

**O que se fazia antes.** SQL direto sobre o transacional, com muitos `GROUP BY` encadeados — lento, e reescrito por inteiro a cada nova pergunta. O conhecimento acumulado ficava nas consultas de alguém, não no modelo.

**A virada.** Parar de tratar o dado como *tabelas* e passar a tratá-lo como **cubo**: eixos (as **dimensões** — produto, região, tempo) e **medidas** (o que se soma — receita, quantidade). Com as agregações **pré-computadas**, mudar de pergunta deixa de ser reescrever a consulta e vira **navegar**: descer o nível de detalhe, subir, fatiar, girar.

**A ideia reaproveitável.** **Trocar espaço e frescor por tempo de resposta é uma decisão de projeto, não um detalhe.** O cubo é essa troca tornada arquitetura: ele ocupa mais disco, duplica dado e responde com números de ontem — em troca de responder *agora*. É o mesmo padrão do [capítulo 22](22-visualizacao-storytelling.md), onde Playfair inventa a barra por falta de dados, e do [capítulo 18](18-neuronio-artificial.md), onde o neurônio nasce sem aprendizado porque não havia como treinar: **restrição material gera forma nova**, e a forma sobrevive à restrição que a criou.

**O nome.** *Online Analytical Processing* (OLAP) é cunhado no relatório de **1993** de **E. F. Codd, S. B. Codd e C. T. Salley**, *"Providing OLAP to User-Analysts: An IT Mandate"*, que também lista **12 regras** para o que seria um produto OLAP legítimo. Codd é o mesmo Codd do modelo relacional — o que dá ao documento uma autoridade imediata.

### O episódio que convém não omitir

E aqui entra a parte incômoda, com o cuidado que ela exige.

**A versão corrente é que** o relatório que cunhou "OLAP" foi **patrocinado pela Arbor Software**, fabricante do Essbase — um produto lançado no ano anterior —, e que as 12 regras coincidiam notavelmente com as características desse produto. **Conta-se também que** o patrocínio não estava declarado no documento, que a *Computerworld* apurou o caso, e que o artigo acabou retirado.

**Registre o estatuto disto:** é uma acusação de conduta envolvendo pessoas reais, e **a fonte primária não foi conferida** — o material da *Computerworld* da época não foi aberto para escrever este capítulo. O que existe aqui é um relato repetido de forma consistente em fontes secundárias. Por isso o selo é ⏳, e por isso o texto diz "a versão corrente é que", nunca "aconteceu que". A diferença entre essas duas formas é o capítulo inteiro em matéria de método. O que se sabe com segurança é o resto: Codd seguiu reconhecido como o pai do modelo relacional, e a categoria OLAP permaneceu — e prosperou por três décadas.

**Por que não omitir.** Porque ensina uma coisa que nenhum tutorial ensina: **categorias de tecnologia às vezes nascem de marketing, não de necessidade técnica.** Antes de aceitar que uma categoria é natural — *data lakehouse*, *feature store*, *vector database* —, pergunte de onde ela veio e quem se beneficia de ela existir. É a lição de ceticismo mais barata deste livro, e a única que você vai usar em toda contratação de ferramenta pelo resto da carreira. Note o detalhe fino: a técnica do cubo era **boa e resolvia um problema real** — o que está em causa é a *embalagem*, não a *engenharia*. As duas coisas podem ser julgadas em separado.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ᵐ | O relatório de 1993 de E. F. Codd, S. B. Codd e C. T. Salley, *"Providing OLAP to User-Analysts: An IT Mandate"*, como origem do termo OLAP e das 12 regras — **metadados conferidos, relatório não lido** |
| ⏳ | O patrocínio da Arbor Software (fabricante do Essbase, lançado no ano anterior), a coincidência entre as 12 regras e o produto, o patrocínio não declarado, a apuração da *Computerworld* e a retirada do artigo — **relato consistente em fontes secundárias; a primária não foi aberta** |
| ⏳ | Que a prática anterior fosse SQL com muitos `GROUP BY` sobre o transacional, reescrito a cada pergunta nova |
| ⏳ | A virada do cubo — dimensões, medidas, agregação pré-computada e navegação por drill-down / roll-up / slice / dice |
| 📖 | A leitura de que "trocar espaço e frescor por tempo de resposta é uma decisão de projeto", e o paralelo com os capítulos 18 e 22 (restrição material gera forma nova) |
| 📖 | A lição extraída do episódio: perguntar de onde veio a categoria antes de aceitá-la como natural — e julgar embalagem e engenharia em separado |
| 📖 | A leitura de que o cubo pré-computado perdeu terreno para a consulta direta em armazenamento colunar |

## Fundamentos: fato, dimensão e grão

O vocabulário é curto e faz todo o trabalho.

**Fato** é o que aconteceu e se mede: uma venda, um atendimento, um clique. A tabela-fato guarda as **medidas** (valor, quantidade) e as chaves que apontam para os eixos. Ela é comprida e estreita — milhões de linhas, poucas colunas.

**Dimensão** é o eixo pelo qual se corta o fato: produto, cliente, loja, tempo. A tabela-dimensão é curta e larga — poucas linhas, muitos atributos descritivos (nome, categoria, marca, região, gerente). É por ela que vêm os rótulos dos relatórios. O teste rápido: **se você somaria a coluna, é medida; se você agruparia por ela, é dimensão.**

**Grão** (granularidade) é a pergunta mais cara do projeto: *o que é uma linha da tabela-fato?* Uma venda? Um item de venda? O total de um produto por loja por dia? O grão define o teto do detalhe — **você sempre pode agregar para cima, nunca desagregar para baixo**. Escolher grão grosso porque "ninguém vai precisar do detalhe" é a decisão que se paga um ano depois, quando alguém precisa.

### Estrela e floco de neve

No **esquema estrela**, a tabela-fato fica no centro e cada dimensão é **uma única tabela desnormalizada** ao redor. A dimensão Produto carrega produto, subcategoria, categoria e departamento na mesma linha — texto repetido milhares de vezes.

No **floco de neve**, cada dimensão é normalizada em várias tabelas (Produto → Subcategoria → Categoria), sem repetição.

O floco é mais "correto" segundo a terceira forma normal. E a estrela quase sempre vence, por três razões: menos `JOIN` por consulta, um modelo que um analista de negócio consegue ler sozinho, e a percepção de que **a redundância aqui é barata** — a dimensão é pequena, e o que ela repete é texto, não a fonte da verdade. A normalização existe para proteger a **escrita** de anomalias; no repositório analítico, a escrita é uma carga controlada, feita por um processo só, em janela conhecida (ver [capítulo 20](20-coleta-integracao.md)). A anomalia que a 3NF previne simplesmente não tem por onde entrar. **Desnormalizar aqui não é relaxar o rigor: é aplicá-lo a um problema diferente.**

:::exercicio {"id":"23-e1","tipo":"multipla","objetivo":"O1","dificuldade":"media"}
Você modela as vendas de uma rede de farmácias. A base tem: `valor_do_item`, `quantidade`, `nome_do_produto`, `categoria_do_produto`, `cidade_da_loja`, `data_da_venda`, `desconto_concedido`. Qual conjunto pertence à **tabela-fato**, no grão "um item de venda"?

- [ ] `nome_do_produto`, `categoria_do_produto`, `cidade_da_loja` — são o que o relatório mostra.
- [x] `valor_do_item`, `quantidade`, `desconto_concedido` — mais as chaves para produto, loja e tempo.
- [ ] Todas as sete colunas, para evitar `JOIN` e deixar a consulta mais rápida.
- [ ] `data_da_venda` e `cidade_da_loja`, porque toda análise começa por tempo e lugar.

> **gabarito:** As medidas (`valor_do_item`, `quantidade`, `desconto_concedido`) mais as chaves de dimensão
> **porque:** Vale o teste: você **somaria** valor, quantidade e desconto — são medidas, e medida mora no fato. Você **agruparia por** nome de produto, categoria e cidade — são atributos descritivos, e atributo descritivo mora na dimensão.
>
> A primeira e a última alternativas invertem os papéis: confundem "o que aparece no relatório" com "o que é medido" — o rótulo vem da dimensão justamente para que você possa trocá-lo (produto → categoria) sem tocar no fato. A terceira é o erro mais interessante, porque tem um argumento verdadeiro dentro: `JOIN` custa, e desnormalizar acelera. Só que jogar tudo no fato multiplica o texto por **milhões** de linhas, não pelas poucas centenas da dimensão — e, pior, tira do modelo o lugar onde a hierarquia produto → categoria fica declarada. Sem esse lugar, não existe roll-up: você volta a reescrever a consulta a cada pergunta.
> **volte para:** #fundamentos-fato-dimensao-e-grao
:::

## As cinco operações

Modelado o cubo, a análise vira navegação — e são só cinco movimentos:

| Operação | O que faz | Exemplo |
|---|---|---|
| **drill-down** | desce um nível na hierarquia de uma dimensão | trimestre → mês |
| **roll-up** | sobe um nível, agregando | produto → categoria |
| **slice** | fixa **um** valor de **uma** dimensão | só o mês de março |
| **dice** | filtra **várias** dimensões por **vários** valores | março e abril, no Sul e Sudeste, em duas categorias |
| **pivot** | gira os eixos, trocando o que é linha e o que é coluna | região nas linhas ↔ região nas colunas |

Repare no que mudou em relação ao SQL do início do capítulo: as cinco operações são **fechadas** — a saída de qualquer uma é outro cubo, pronto para receber a próxima. É por isso que a reunião flui. O analista não escreve nada; ele clica, e cada clique é uma dessas cinco coisas.

### Por que muito cubo virou consulta direta

Uma nota de leitura editorial (📖), para você não sair daqui achando que precisa construir um cubo: **o cubo pré-computado perdeu bastante terreno.** Quando o armazenamento **colunar** e o processamento distribuído ficaram baratos, varrer bilhões de linhas na hora deixou de ser proibitivo — e a agregação prévia passou a custar mais do que rende, em espaço, em manutenção e em atraso do dado. O que **não** perdeu terreno é a parte que interessa: fato, dimensão, grão, hierarquia e as cinco operações continuam sendo o vocabulário da análise, mesmo quando a resposta é calculada na hora. A implementação envelheceu; o modelo, não.

:::exercicio {"id":"23-e2","tipo":"numerica","objetivo":"O2","dificuldade":"media"}
Um cubo de vendas tem três dimensões, no grão mais fino: **Produto** (40 produtos, agrupados em 8 categorias), **Região** (5 regiões) e **Tempo** (12 meses).

Partindo do cubo completo, você aplica um **slice** em Tempo = março e, em seguida, um **roll-up** de produto para categoria. Quantas células tem o cubo resultante?

> **gabarito:** 40 ± 0
> **porque:** O cubo completo tem 40 × 5 × 12 = **2 400** células. O **slice** fixa um valor de uma dimensão (março), sobrando 40 × 5 = **200**. O **roll-up** sobe Produto de 40 itens para 8 categorias: 8 × 5 = **40** células.
>
> Dois erros comuns valem a atenção. O primeiro é achar que o roll-up **descarta** dado: ele não descarta, ele **agrega** — a receita das 40 células vira a receita das 8, e a soma total continua a mesma. O segundo é confundir slice com dice: se em vez de "março" você tivesse pedido "março e abril, no Sul e no Sudeste", seria um **dice**, e o resultado seria 8 × 2 × 2 = 32. E note o que o número mostra: você saiu de 2 400 células para 40 sem escrever consulta nova — foi exatamente isso que a arquitetura comprou.
> **volte para:** #as-cinco-operacoes
:::

## Nem toda medida pode ser somada

Este é o detalhe que separa quem entendeu o modelo de quem decorou o desenho. Medidas se dividem em três tipos:

**Aditivas** — somam em **todas** as dimensões. Receita, quantidade vendida, custo. É o caso confortável, e o que todo mundo assume por padrão.

**Semi-aditivas** — somam em **algumas** dimensões e não em outras. O exemplo clássico é **estoque**: somar o estoque de um produto **ao longo das lojas** faz todo sentido (é o estoque da rede); somar o estoque **ao longo do tempo** não significa nada — janeiro tinha 100 unidades, fevereiro tinha 100 unidades, e "200" não descreve coisa nenhuma. Ao longo do tempo, o que faz sentido é o **último valor** ou a **média**. Saldo bancário e número de assinantes ativos têm exatamente o mesmo comportamento.

**Não aditivas** — não somam em dimensão nenhuma. Razões e percentuais: a margem média de duas lojas não é a soma das margens, nem a média simples delas. A regra é guardar no fato os **componentes** (receita e custo) e calcular a razão **depois** da agregação, no nível pedido.

Um painel que soma coluna semi-aditiva ao longo do tempo é um dos erros mais silenciosos do BI: ninguém vê erro de execução, o total simplesmente cresce mês a mês, e a empresa acredita ter um estoque que nunca teve.

### Do cubo ao modelo

O cubo responde "o que aconteceu"; o modelo preditivo responde "o que vai acontecer" — e os dois consomem o **mesmo** trabalho de base. A tabela que um modelo consome é, quase sempre, um cubo **achatado num grão escolhido**: uma linha por entidade-e-instante, medidas agregadas em janelas (receita nos últimos 30 dias, número de compras no trimestre) e atributos vindos das dimensões. Duas armadilhas na travessia. A primeira: **o grão do cubo vira o grão do dataset**, e um grão grosso demais impede o modelo de existir. A segunda, e mais grave: agregar sem respeitar o **corte de tempo** é o vazamento do [capítulo 02](02-dados.md) na forma mais fácil de cometer — se a janela de agregação inclui informação posterior ao instante da previsão, seu modelo tem um desempenho excelente e inútil.

:::exercicio {"id":"23-e3","tipo":"aberta","objetivo":"O3","pontos":3,"dificuldade":"dificil"}
Você propõe um esquema estrela para o repositório analítico. Um colega, DBA experiente, recusa: *"Isso viola a terceira forma normal. A categoria do produto vai estar repetida em milhares de linhas da dimensão. Se alguém renomear uma categoria, você tem anomalia de atualização. Normalize."*

Escreva a resposta que você daria a ele — reconhecendo o que ele tem de razão.

> **rubrica:** reconhece que a crítica é tecnicamente correta quanto à 3NF e que a redundância existe de fato;
> explica que a normalização protege a integridade da **escrita**, e que no repositório analítico a escrita é uma carga controlada, por um processo só, em janela conhecida — a anomalia de atualização não tem por onde entrar;
> aponta o ganho concreto da estrela: menos JOIN por consulta e um modelo legível por quem faz a pergunta;
> observa que a redundância é barata porque ocorre na **dimensão** (pequena), não no fato (milhões de linhas);
> trata o caso da renomeação de categoria como requisito a resolver no processo de carga (ou como dimensão que muda com o tempo), não como impedimento
> **porque:** A resposta fraca é "em BI a gente desnormaliza mesmo" — que é obedecer a um costume, não justificar uma decisão, e é exatamente o que o objetivo O3 cobra. A resposta forte começa **concedendo**: ele está certo sobre a 3NF, e a redundância é real.
>
> O argumento vem em seguida, e é sobre **qual problema cada regra resolve**. A 3NF é uma defesa contra anomalias de atualização em ambiente de escrita concorrente e imprevisível — o transacional. O repositório analítico não é esse ambiente: nele a escrita é um processo de carga único, versionado, testado e executado em janela conhecida ([capítulo 20](20-coleta-integracao.md)). Retirar uma defesa contra um ataque que não existe naquele perímetro não é descuido; é dimensionar a defesa ao risco.
>
> O caso da renomeação é onde a boa resposta se distingue da excelente: ele **não** é um contra-argumento, é um requisito — e um requisito interessante, porque muitas vezes você **não quer** propagar a mudança. Se um produto mudou de categoria em junho, reescrever a dimensão faz o relatório de janeiro mentir sobre janeiro. É o problema das *slowly changing dimensions*, e a resposta usual é guardar as duas versões com vigência, não normalizar. Fecha o caso a assimetria de tamanho: repetir "Medicamentos" em 800 linhas de uma dimensão custa quase nada; repeti-lo em 40 milhões de linhas do fato custaria — e por isso a estrela desnormaliza a dimensão, e só ela.
> **volte para:** #estrela-e-floco-de-neve
:::

## Síntese — o que levar

- O modelo relacional é ótimo para **transação** e desajeitado para a **pergunta gerencial**, que agrega em vários eixos ao mesmo tempo e muda a cada trinta segundos.
- **Fato** é o que se mede; **dimensão** é por onde se corta. Teste: somaria a coluna → medida; agruparia por ela → dimensão.
- O **grão** é a decisão mais cara. Agregar para cima sempre dá; desagregar para baixo, nunca.
- **Estrela** vence **floco de neve** quase sempre: menos `JOIN`, modelo legível, redundância barata porque acontece na dimensão. Desnormalizar aqui **não é relaxar o rigor** — a 3NF protege a escrita, e a escrita analítica é uma carga controlada.
- Cinco operações fechadas: **drill-down, roll-up, slice, dice, pivot**. A saída de cada uma é outro cubo, e é isso que faz a reunião fluir.
- **Nem toda medida soma.** Estoque soma entre lojas e não soma ao longo do tempo; razão não soma em lugar nenhum — guarde os componentes, calcule depois.
- **Trocar espaço e frescor por tempo de resposta é decisão de projeto.** O cubo é essa troca virada arquitetura — o mesmo padrão da barra de Playfair ([22](22-visualizacao-storytelling.md)) e do neurônio sem aprendizado ([18](18-neuronio-artificial.md)).
- O cubo **pré-computado** perdeu terreno para o colunar barato; o **vocabulário** do cubo não perdeu nada.
- A categoria "OLAP" nasceu com um episódio incômodo. **Pergunte de onde veio a categoria** antes de aceitá-la como natural — e julgue a embalagem separadamente da engenharia.

## Verificação

1. Escolha um sistema que você conhece e diga qual seria o **grão** da tabela-fato. Depois diga o que se perde ao subir um nível — e quem vai reclamar primeiro.
2. Dê um exemplo, do seu contexto, de medida **semi-aditiva**. Em quais dimensões ela soma, e o que se calcula naquela em que não soma?
3. O colega da farmácia diz que o cubo é dispensável porque "hoje o banco colunar aguenta". Em que ele tem razão, e o que continua valendo do modelo dimensional mesmo sem cubo pré-computado?
4. Você usaria as agregações do cubo como variáveis de um modelo preditivo ([capítulo 21](21-analise-exploratoria.md) antes, [capítulo 02](02-dados.md) como alerta). Que verificação você faria **antes**, para não vazar o futuro para dentro do passado?

---

# 24 — Séries Temporais

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Decompor uma série em tendência, sazonalidade e resíduo.
- **O2.** Aplicar validação com origem móvel, e explicar por que k-fold embaralhado é inválido aqui.
- **O3.** Comparar uma previsão contra a linha de base ingênua correta.
- **O4.** Reconhecer quando um problema temporal pode ser tratado como tabular.

## O problema: o futuro vaza pela divisão

Um analista prevê a demanda mensal de um centro de distribuição. Carrega cinco anos de histórico, chama `train_test_split` com `shuffle=True`, treina, mede: **erro 4%**. Excelente. Sobe para produção. No primeiro mês, erra 22%.

Nada quebrou. O experimento é que estava errado — e de um jeito invisível. Ao embaralhar, ele pôs dezembro de 2025 no treino e junho de 2025 no teste: o modelo previu junho **sabendo o que aconteceu em dezembro**. Em produção esse conhecimento não existe, porque dezembro ainda não aconteceu.

É o vazamento do [capítulo 02](02-dados.md) na sua forma mais fácil de cometer e mais difícil de perceber. A divisão aleatória — a coisa certa a fazer em quase todo o resto do livro — aqui é exatamente o defeito, e não deixa rastro: nenhum aviso, nenhuma exceção, nenhum número absurdo. Só uma métrica boa demais que ninguém questiona, porque métrica boa é o que todo mundo estava esperando. Este capítulo é sobre o que muda quando os dados têm **ordem**.

## De onde isto veio

**O aperto.** 1927. As manchas solares oscilam com regularidade aparente, e a estatística da época tem uma explicação pronta para qualquer periodicidade: existe um **ciclo determinístico oculto** na natureza, e o que borra a curva é o **erro de medição** do instrumento. **George Udny Yule** desconfia dessa divisão de trabalho. E se o ruído não estiver na medição, mas no **próprio sistema**?

**O que se fazia antes.** Análise harmônica: decompor a série em senos e cossenos, à procura dos períodos escondidos. O método pressupõe a resposta — se você procura período fixo, você acha algum.

**A virada.** Modelar o valor de hoje como **função dos valores anteriores mais uma perturbação aleatória**. É o autorregressivo. A metáfora de Yule diz tudo sem uma linha de notação: um **pêndulo que leva pancadas aleatórias** oscila — mas sem período fixo. Ele parece cíclico e não é. A regularidade não vem de um relógio escondido; vem da **inércia do próprio sistema**, que carrega para a frente cada empurrão que recebe.

**A ideia reaproveitável.** **O acaso pode estar dentro do mecanismo, não só no instrumento.** Trocar "sinal limpo + erro de leitura" por "sistema que é ele mesmo ruidoso" muda o que você procura: em vez de caçar o período verdadeiro, você estima **quanto do passado sobrevive no presente**. É uma troca de pergunta, não de técnica — e serve muito além de séries temporais. Sempre que um modelo não fecha, vale perguntar se o erro está no medidor ou na sua ideia do que está sendo medido.

**O nome.** **ARIMA** = *AutoRegressive Integrated Moving Average* — as três peças do procedimento, no acrônimo. O "AR" é Yule; o "I" é a diferenciação; o "MA" é a memória curta dos choques.

> ### Repare no relógio: 43 anos
>
> Yule publica a autorregressão em **1927**. O procedimento que qualquer pessoa consegue seguir — identificar → estimar → diagnosticar — chega em **1970**, com Box & Jenkins. **Quarenta e três anos** entre a ideia e a ferramenta.
>
> É o formato padrão deste livro: 1962→1977 no [capítulo 21](21-analise-exploratoria.md), 1943→1958 no [18](18-neuronio-artificial.md), 1931→1974 no [01](../01-fundamentos.md) — também 43 anos.
>
> Mas o [capítulo 07](07-arvores-ensembles.md) traz a exceção que explica a regra: no *boosting* foram **sete** anos. Pergunta em 1988, resposta em 1990, algoritmo em 1995. Por quê tão rápido? Porque ali o aperto já estava formulado como **pergunta formal precisa** — "um aprendiz fraco pode ser transformado num forte?" — com os dois lados definidos o bastante para alguém responder sim ou não.
>
> **O gargalo nunca é o tempo nem o computador. É a precisão da pergunta.** Yule tinha uma intuição excelente e vaga; Kearns e Valiant tinham um enunciado. Quarenta e três anos contra sete.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ⏳ | O aperto de 1927 (o ruído no sistema e não na medição), a análise harmônica como prática anterior e a metáfora do pêndulo que leva pancadas |
| ✓ᵐ | Yule, *On a Method of Investigating Periodicities in Disturbed Series, with Special Reference to Wolfer's Sunspot Numbers*, Phil. Trans. Royal Society A, **226**, 267–298 (1927) — primeira aplicação de autorregressão, com defasagem 2. **Localizado e identificado; não lido** |
| ✓ᵐ | Box & Jenkins, *Time Series Analysis: Forecasting and Control* (Holden-Day, 1970), e o acrônimo ARIMA. **Localizado e identificado; não lido** |
| 📖 | A ideia reaproveitável, e a leitura do relógio — os 43 anos, o paralelo com os capítulos 21, 18 e 01, e o contraste com os sete anos do [07](07-arvores-ensembles.md) |

## Fundamentos: o que muda quando existe tempo

Uma série é uma sequência de observações **ordenadas**, e a ordem é informação. Quatro componentes convivem em quase toda série real:

| Componente | O que é | Como se reconhece |
|---|---|---|
| **Tendência** | movimento de longo prazo | a média muda de nível ao longo do período |
| **Sazonalidade** | padrão de **período fixo e conhecido** | mês, dia da semana, hora do dia |
| **Ciclo** | oscilação de período **variável** | dura anos, não fecha em calendário |
| **Ruído** | o que sobra | sem estrutura aproveitável |

A distinção entre sazonalidade e ciclo é a herança direta de Yule, e é a mais confundida. Sazonalidade tem calendário: dezembro é dezembro. Ciclo não tem — é o pêndulo levando pancadas, e prever quando ele vira é bem mais difícil do que prever dezembro. Antes de qualquer modelo, **desenhe a série**: é o [capítulo 21](21-analise-exploratoria.md) aplicado ao tempo, e tendência, sazonalidade, quebras de nível e buracos de coleta aparecem num gráfico de linha em cinco segundos — nenhum deles aparece numa tabela de médias.

### Estacionariedade e a diferenciação

Uma série é **estacionária** quando suas propriedades estatísticas — média, variância, autocorrelação — não dependem de *quando* você olha. Os métodos clássicos exigem isso, e a razão é honesta: eles aprendem **uma** relação entre passado e presente. Se essa relação muda de ano para ano, não há o que aprender.

A ferramenta padrão é a **diferenciação**: em vez de modelar o valor, modele a **variação**. Uma série que cresce (100, 110, 121, 133) não é estacionária; a série das diferenças (10, 11, 12) já vive num nível fixo. Este é o **"I"** de ARIMA — *Integrated*, o número de vezes que foi preciso diferenciar; para sazonalidade, diferencia-se contra o mesmo período do ano anterior. Duas armadilhas: **diferenciar demais** injeta ruído que não existia, e a previsão precisa ser **desdiferenciada** de volta à escala original — esquecer esse passo produz números plausíveis na unidade errada.

### O diagnóstico da memória: ACF e PACF

A **função de autocorrelação (ACF)** mede a correlação da série com ela mesma defasada de *k* períodos. É um gráfico, e responde de graça uma pergunta cara: **quanto do passado ainda importa?** Uma ACF que cai devagar e nunca zera denuncia tendência (falta diferenciar); um pico solitário na defasagem 12, em dado mensal, é sazonalidade anual gritando. Já a **autocorrelação parcial (PACF)** remove o efeito das defasagens intermediárias — a correlação entre hoje e três dias atrás **descontando** ontem e anteontem. É ela que sugere quantos termos autorregressivos usar; a defasagem 2 de Yule saiu de um raciocínio desse tipo.

:::exercicio {"id":"24-e1","tipo":"multipla","objetivo":"O1","dificuldade":"facil"}
Você plota a série mensal de vendas de uma loja e observa: as vendas sobem de forma consistente ao longo de quatro anos, e todo dezembro é muito maior que os meses vizinhos. Qual decomposição descreve isso?

- [ ] Só sazonalidade: o pico de dezembro explica o crescimento.
- [x] Tendência (crescimento de longo prazo) mais sazonalidade anual (o pico de dezembro), mais o resíduo.
- [ ] Só ciclo: qualquer oscilação repetida é um ciclo.
- [ ] Ruído com autocorrelação, sem componente estrutural.

> **gabarito:** Tendência + sazonalidade anual + resíduo
> **porque:** São dois fenômenos independentes acontecendo juntos, e tratá-los como um só é o erro clássico. O crescimento ao longo de quatro anos é **tendência** — a média muda de nível. O pico de dezembro é **sazonalidade**, porque tem período fixo e conhecido pelo calendário: dezembro é sempre dezembro. A terceira alternativa confunde **ciclo** com **sazonalidade**, e a diferença é operacional, não terminológica: sazonalidade você prevê olhando o calendário; ciclo tem período variável e é justamente o que Yule mostrou que pode emergir de um sistema ruidoso, sem relógio nenhum por trás. Chamar dezembro de "ciclo" faz você procurar um período a estimar quando ele já está dado.
> **volte para:** #fundamentos-o-que-muda-quando-existe-tempo
:::

## A validação não pode ser aleatória

Esta é a seção mais importante do capítulo. **Embaralhar e sortear treino/teste vaza o futuro para o passado.** Não é um vazamento sutil de atributo mal construído — é o modelo lendo a resposta. E ele não se manifesta como erro: manifesta-se como uma métrica excelente que produção jamais reproduz.

**Divisão cronológica.** O treino termina numa data; o teste começa depois dela. Sempre. Se houver ajuste de hiperparâmetros, use três blocos em ordem — treino, validação, teste — e o teste é o mais recente.

**Validação com origem móvel (*walk-forward*).** Um único corte informa pouco: talvez você tenha sorteado um trimestre fácil. Então repita o corte, avançando a origem:

```
treino [========]           teste [==]
treino [==========]              teste [==]
treino [============]                 teste [==]
```

Cada rodada treina com tudo até a origem e avalia no bloco seguinte. Você ganha várias medidas, e com elas a **incerteza** que o [capítulo 04](04-avaliacao.md) exige — e não só um ponto.

**Janela expansiva ou deslizante?** A expansiva (acima) acumula todo o histórico; a **deslizante** mantém o tamanho fixo e descarta o passado remoto. Expansiva quando o processo é estável e dado é escasso; deslizante quando o regime mudou — uma pandemia, uma troca de precificação, um concorrente novo. Dado antigo de um regime morto não é dado a mais, é viés.

Um detalhe que engana gente experiente: **atributos defasados têm de respeitar o corte**. Se você calcula uma média móvel de 30 dias sobre a série inteira **antes** de dividir, cada linha do treino já contém informação do teste. Calcule as features dentro de cada dobra, nunca antes.

### A linha de base ingênua

Antes de qualquer modelo, meça o que a **previsão ingênua** entrega: *amanhã é igual a hoje*. Se houver sazonalidade, a versão honesta é a **ingênua sazonal**: *este dezembro é igual ao dezembro passado*. Ela é surpreendentemente difícil de bater — em séries com muita inércia o último valor já carrega quase tudo o que se sabe. E o incômodo desta seção é este: **muito modelo publicado não bate essa linha**, porque ninguém a calculou. Compare-se sempre à ingênua **do tipo certo**: pôr um modelo sazonal contra a ingênua simples é escolher o adversário fraco.

:::exercicio {"id":"24-e2","tipo":"numerica","objetivo":"O3","dificuldade":"media"}
Vendas mensais (em milhares):

| Mês | 2024 | 2025 |
|---|---|---|
| jan | 100 | 110 |
| fev | 120 | 126 |
| mar | 90 | 99 |

Calcule o **MAE** (erro absoluto médio) da **previsão ingênua sazonal** — cada mês de 2025 previsto pelo mesmo mês de 2024 — nos três meses de 2025. Responda com 2 casas decimais.

> **gabarito:** 8.33 ± 0.01
> **porque:** As previsões são os valores de 2024: 100, 120 e 90. Os erros absolutos são |110−100| = 10, |126−120| = 6 e |99−90| = 9. O MAE é (10 + 6 + 9)/3 = 25/3 = **8,33**.
>
> Agora o que o exercício realmente ensina: compare com a **ingênua simples** (prever o valor do mês anterior). Ela previria 110 para fevereiro (erro 16) e 126 para março (erro 27) — muito pior, porque a série tem sazonalidade forte e a ingênua simples a ignora. É por aqui que relatórios ficam desonestos sem má-fé: escolhe-se a ingênua simples como linha de base, o modelo a supera com folga, e todo mundo comemora — quando a régua correta era a sazonal, que talvez o modelo nem batesse. **A linha de base tem de ser a melhor coisa trivial disponível**, não a mais fácil de vencer.
> **volte para:** #a-linha-de-base-ingenua
:::

:::exercicio {"id":"24-e3","tipo":"aberta","objetivo":"O2","pontos":3,"dificuldade":"dificil"}
Uma colega apresenta este protocolo para prever a demanda diária de um e-commerce:

> "Peguei 3 anos de dados diários. Criei atributos defasados (venda de 1, 7 e 30 dias atrás) e a média móvel de 30 dias, tudo calculado sobre a base completa. Depois embaralhei as linhas e fiz `train_test_split` com 20% de teste, mais um k-fold de 5 dobras para ajustar os hiperparâmetros. Deu 3,1% de erro percentual. Também rodei uma validação cruzada aleatória repetida para confirmar, e o intervalo ficou estreito."

Identifique os problemas do protocolo e descreva o que você faria no lugar.

> **rubrica:** aponta que o embaralhamento quebra a ordem e permite treinar com dias posteriores ao dia previsto — vazamento do futuro para o passado;
> observa que o k-fold aleatório repete o mesmo defeito, e que rodá-lo várias vezes não corrige nada — só mede o mesmo erro com mais precisão;
> identifica o segundo vazamento, independente do primeiro: os atributos defasados e a média móvel foram calculados sobre a base inteira antes da divisão;
> propõe divisão cronológica e validação com origem móvel (walk-forward), com as features recalculadas dentro de cada dobra;
> exige comparação contra a previsão ingênua (simples ou sazonal) antes de aceitar os 3,1%
> **porque:** Há **dois** vazamentos, e quem enxerga só um entrega meia resposta. O primeiro é a ordem: embaralhar coloca no treino dias que vieram **depois** do dia previsto, e o modelo aprende a interpolar entre vizinhos temporais que, em produção, ainda não existirão. O segundo é mais silencioso e sobrevive mesmo a quem corrige o primeiro: a **média móvel calculada antes da divisão**. Cada linha do treino carrega uma estatística que já viu o período de teste. Você pode dividir cronologicamente de forma impecável e ainda assim vazar por aqui — é o mesmo mecanismo do [capítulo 02](02-dados.md), onde a normalização feita antes do split contamina o teste.
>
> O detalhe que separa a boa resposta da excelente é o intervalo estreito. Ele soa como confirmação e é o contrário: **um erro sistemático medido muitas vezes continua sendo o mesmo erro, agora com um intervalo estreito em volta de um número errado**. Precisão não é validade; repetir um protocolo inválido só o torna mais convincente. E 3,1% não significa nada até se saber quanto a previsão ingênua entrega — talvez entregue 3,0%.
> **volte para:** #a-validacao-nao-pode-ser-aleatoria
:::

## Quando o problema temporal vira tabular

Boa parte do trabalho prático não usa ARIMA. Usa-se **janelamento**: cada linha vira "os *k* valores anteriores + atributos de calendário", e o alvo é o valor seguinte. A partir daí, qualquer regressor do [capítulo 07](07-arvores-ensembles.md) serve.

A transformação é legítima e frequentemente vence os métodos clássicos — desde que **o protocolo de validação continue temporal**. É aí que mora o perigo: assim que o problema *parece* tabular, o reflexo de embaralhar volta. A tabela esconde a ordem; a ordem continua lá. E declare o **horizonte**: prever 1 passo à frente e prever 30 são problemas diferentes, com erros diferentes — um modelo excelente em 1 passo pode ser inútil em 30, e reportar só o primeiro número é omissão.

## Síntese — o que levar

- Tempo é **ordem**, e ordem é informação. Todo procedimento do livro que embaralha precisa ser reexaminado aqui.
- **Nunca embaralhe.** Divisão cronológica e validação com **origem móvel**; expansiva se o regime é estável, deslizante se mudou.
- Atributos defasados e estatísticas móveis calculam-se **dentro** de cada dobra. Vazamento por *feature* sobrevive a uma divisão cronológica correta.
- A **previsão ingênua** — do tipo certo — é o adversário obrigatório. Modelo que não a bate não tem valor.
- Um intervalo estreito em torno de um protocolo inválido é **precisão sem validade**, e é mais perigoso que um número ruim.
- Separe **sazonalidade** (período fixo, do calendário) de **ciclo** (período variável, emergente). **Estacionariedade** é pré-requisito dos métodos clássicos, e **diferenciar** é o caminho mais curto até ela — com a previsão voltando à escala original.
- A ideia de Yule que atravessa tudo: **o acaso pode estar dentro do mecanismo, não só no instrumento**.

## Verificação

1. Explique a um colega, sem usar a palavra "vazamento", por que k-fold embaralhado dá uma métrica boa e inútil numa série temporal.
2. Sua série tem sazonalidade semanal e uma quebra de nível há seis meses (mudança de preço). Você usaria janela expansiva ou deslizante, e qual previsão ingênua seria a linha de base honesta? Justifique as duas escolhas.
3. Você transformou o problema em tabular com janelas e vai usar um ensemble de árvores. Liste tudo que ainda precisa respeitar a ordem temporal — e diga em que ponto do seu código cada um desses cuidados aparece.

---

# 25 — Do Modelo à Decisão

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Comparar duas ou mais técnicas com protocolo justo e incerteza declarada.
- **O2.** Traduzir métrica estatística em consequência de negócio.
- **O3.** Apresentar resultados a um público não técnico sem perder o rigor.
- **O4.** Decidir, com critério explícito, se um modelo deve ou não ir a produção.

## O problema: o modelo está pronto, e daí?

Um analista termina o projeto com 0,91 de AUC. Apresenta. A diretora pergunta: *"Então a gente aprova ou não aprova o crédito desse cliente aqui?"*

Ele não sabe responder. E não é por incompetência técnica — é porque **falta uma informação que nunca esteve nos dados**: quanto custa cada tipo de erro.

O modelo entrega uma **ordenação**: este cliente é mais arriscado que aquele. Transformar ordenação em **ação** exige um corte, e o corte exige um preço. Enquanto ninguém disser quanto vale perder um bom cliente e quanto custa aprovar um mau, não existe resposta certa — existe apenas uma escolha, e alguém vai fazê-la de qualquer maneira.

O erro que este capítulo previne é esse: **o cientista de dados escolher o limiar sozinho, calado, achando que é uma decisão técnica.** Não é. É uma decisão de negócio disfarçada de detalhe de implementação.

## De onde isto veio

**O aperto.** Guerra, 1940–43, duas frentes independentes com o mesmo problema: *o que fazer com um número*.

Na Inglaterra, **Patrick Blackett** monta em **agosto de 1940**, no Anti-Aircraft Command, um grupo de sete cientistas — físicos, um astrônomo, um fisiologista, um matemático — apelidado **"Blackett's Circus"**. Em março de 1941 repete a receita no Coastal Command, contra os submarinos alemães. Nos Estados Unidos, o **Statistical Research Group** reúne em Columbia, no verão de 1942, gente como **Wald, Savage, Friedman e Hotelling** para decidir blindagem de bombardeiro, mistura de munição e regras de inspeção por amostragem.

**O que se fazia antes.** Decisão de comando por experiência e hierarquia. E, do lado da estatística, dois problemas tratados separadamente e **sem preço**: estimar um parâmetro e testar uma hipótese.

**A virada.** Abraham Wald mostra, em **1939**, que estimar e testar são **casos particulares de um mesmo problema: decidir**. E para isso ele precisa de algo que a estatística clássica não tinha — uma **função que diz quanto custa errar**. Erro deixa de ser categoria lógica (certo/errado) e vira **grandeza econômica**.

**A ideia reaproveitável.** **Pode ser ótimo agir como se uma classe fosse verdadeira mesmo quando a outra é mais provável.** Charles Elkan dá o exemplo perfeito: pode ser racional **não** aprovar uma transação alta de cartão *mesmo que ela seja provavelmente legítima* — porque o prejuízo da fraude rara supera o incômodo do bloqueio frequente. **Probabilidade ordena; custo decide.** Um modelo que devolve só probabilidade não terminou o trabalho.

**O nome.** *Operational research* no Reino Unido, *operations research* nos Estados Unidos — a diferença de nome guarda a diferença de origem. Já **"análise de decisão"** é cunhada só em **1966**, por **Ronald Howard**, e o detalhe é saboroso: o nome do campo nasce **dentro** de uma conferência de Pesquisa Operacional.

> ### O capítulo 04 e este são a mesma história, cortada em dois
>
> Blackett entrou em **1934** no comitê Tizard, cuja marca foi justamente **supervisionar o desenvolvimento do radar** antes da guerra. Só depois, em 1940, montou o Circus.
>
> **A mesma pessoa, no mesmo comitê, diante do mesmo problema.** Chegou o sinal — o que se faz com ele? O [capítulo 04](04-avaliacao.md) conta o lado do **botão de ganho**: onde pôr o limiar, e como a curva ROC mapeia essa troca. Este conta o lado do **comando**: quanto custa cada erro, e quem tem autoridade para dizer isso.
>
> **O limiar do capítulo 04 é a matriz de custo deste capítulo vista de perfil.**

### A matriz de custo, e o erro que atravessou décadas

Aqui está o achado mais útil — e mais desconfortável — desta seção.

O *German credit dataset*, conjunto didático clássico distribuído com uma matriz de custo oficial, tem uma matriz **economicamente incoerente**. Elkan demonstra o problema: ela mede cada célula a partir de uma linha de base diferente. Como **negar o empréstimo produz exatamente o mesmo fluxo de caixa** quer o cliente fosse bom ou mau, as duas células da linha "negar" **têm de ser iguais** — e não são.

A recomendação dele é prática e vale para o seu trabalho: **contabilize em benefício, não em custo.** Benefício tem uma linha de base natural — o estado do agente **antes** de decidir. Custo não tem, e por isso convida ao erro de comparar cada célula com uma referência diferente.

Um conjunto de dados usado em aula há décadas circula com uma matriz de custo errada. Não porque alguém foi descuidado: porque **matriz de custo é mais difícil do que parece**, e quase ninguém confere.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ | Tudo o que é atribuído a Elkan — o exemplo do cartão de crédito, a incoerência da matriz do *German credit*, e a recomendação de contabilizar em benefício — de [*The Foundations of Cost-Sensitive Learning* (IJCAI, 2001)](https://cseweb.ucsd.edu/~elkan/rescale.pdf), **lido** |
| ✓ᵐ | Blackett, o "Blackett's Circus" (agosto de 1940), o Coastal Command (março de 1941) e a participação no comitê Tizard/CSSAD desde 1934 — [perfil biográfico do INFORMS](https://www.informs.org/Explore/History-of-O.R.-Excellence/Biographical-Profiles/Blackett-Patrick-M.-S) |
| ✓ᵐ | Wald (*Annals of Mathematical Statistics* 10(4):299–326, 1939) e *Statistical Decision Functions* (1950); Savage (1954); Raiffa & Schlaifer (1961, Harvard Business School); Howard cunhando "decision analysis" em 1966. **O artigo de Wald está digitalizado sem camada de texto e não foi lido** |
| ✓ᵐ | O Statistical Research Group de Columbia (1942) e seus integrantes |
| ⏳ | O estudo da blindagem dos bombardeiros (1943) como caso canônico de viés de sobrevivência |
| ❌ | A **origem da curva de lift**: procurei inventor, data e publicação, e **não achei atribuição primária**. O que se apura é ambiente, não autoria — RFM atribuído a George Cullinan por volta de 1961 no marketing direto (⏳), e a análise por decis consolidada no *database marketing* dos anos 1980–90 (⏳) |
| 📖 | A leitura de que os capítulos 04 e 25 são uma história só, e de que o limiar é a matriz de custo vista de perfil |

## Fundamentos: comparar duas técnicas sem se enganar

Comparação justa tem três exigências, e violar qualquer uma invalida o resultado.

**1. O mesmo dado, na mesma divisão.** Se o modelo A foi avaliado numa divisão e o B em outra, você comparou as divisões, não os modelos. Fixe a *seed* e reutilize exatamente os mesmos conjuntos.

**2. O mesmo orçamento de busca.** Comparar um modelo com hiperparâmetros ajustados por cem tentativas contra outro com valores de fábrica não é comparação, é encenação. Ou os dois recebem busca, ou nenhum recebe.

**3. A mesma métrica, escolhida antes.** Escolher a métrica **depois** de ver os resultados é a forma mais comum e mais inocente de trapaça — você acaba selecionando a régua que favorece o modelo que já preferia.

### A diferença é maior que o ruído?

Modelo A dá 0,913 e modelo B dá 0,907. A é melhor?

Provavelmente **você não sabe**. Métrica calculada num conjunto de teste é uma **estimativa**, e estimativa tem incerteza — como o [capítulo 04](04-avaliacao.md) mostrou. Com 500 exemplos de teste, uma diferença de 0,006 costuma estar dentro do ruído.

O procedimento honesto é o **bootstrap pareado**: reamostre o conjunto de teste com reposição, recalcule a métrica dos **dois** modelos na mesma reamostragem, e guarde a diferença. Repita mil vezes. Se o intervalo das diferenças cruza o zero, **os modelos empataram** — e dizer isso é um resultado, não um fracasso.

O detalhe que faz o método funcionar é o *pareado*: avaliar os dois na **mesma** reamostragem cancela a variação que vem do conjunto e isola a que vem do modelo.

:::exercicio {"id":"25-e1","tipo":"multipla","objetivo":"O1","dificuldade":"media"}
Você comparou dois modelos no mesmo conjunto de teste: A deu 0,913 de AUC e B deu 0,907. O bootstrap pareado com mil reamostragens devolveu um intervalo de 95% para a diferença (A − B) de **[−0,004; +0,016]**. O que reportar?

- [ ] Que A é melhor que B, porque a estimativa pontual da diferença é positiva.
- [x] Que não há evidência de diferença entre os dois, e a escolha deve usar outro critério.
- [ ] Que B é melhor, porque o intervalo é mais largo do lado positivo.
- [ ] Que o experimento falhou e precisa de mais reamostragens.

> **gabarito:** Não há evidência de diferença; decida por outro critério
> **porque:** O intervalo **cruza o zero**, então os dados são compatíveis com A melhor, B melhor e empate. A estimativa pontual de +0,006 existe, mas não se sustenta sozinha — reportá-la como "A ganhou" é apresentar ruído como resultado.
>
> E isto é uma boa notícia disfarçada: **quando dois modelos empatam em desempenho, você fica livre para decidir por tudo o mais** — custo de inferência, facilidade de explicar a decisão a um auditor, tempo de treino, número de dependências. Um empate estatístico transfere a decisão da métrica para a engenharia, e quase sempre a engenharia tem preferência clara.
>
> A última alternativa é o erro mais comum na prática: aumentar as reamostragens **não** estreita o intervalo de forma relevante, porque a incerteza vem do **tamanho do conjunto de teste**, não do número de reamostragens. Mil já é suficiente; o que faltaria é mais dado de teste.
> **volte para:** #a-diferenca-e-maior-que-o-ruido
:::

## Da métrica ao dinheiro

Aqui o capítulo cumpre o seu nome. Toda decisão binária tem quatro resultados possíveis, e **cada um vale um número**:

| | Previu positivo | Previu negativo |
|---|---|---|
| **É positivo** | acerto — benefício de agir certo | erro — custo de deixar passar |
| **É negativo** | erro — custo do alarme falso | acerto — benefício de não agir à toa |

Preenchida a tabela, o limiar ótimo deixa de ser opinião: é o corte que **maximiza o benefício esperado**. E, seguindo Elkan, preencha-a em **benefício**, com a linha de base sendo *o que aconteceria se você não fizesse nada*.

Três avisos que economizam retrabalho:

**Os números não são seus.** Quem sabe quanto custa um falso negativo é a área de risco, a área médica, o jurídico. O seu papel é **exigir os números e registrar quem os forneceu** — porque quando o limiar for questionado, a pergunta vai ser "quem decidiu isso?".

**Custos mudam; o modelo não precisa mudar junto.** Se a matriz muda de trimestre, você recalcula o limiar sobre as mesmas probabilidades. É a maior vantagem prática de separar o modelo (que ordena) da decisão (que corta).

**Probabilidade mal calibrada estraga tudo.** O cálculo do limiar ótimo pressupõe que 0,7 signifique 70%. Ensembles costumam não cumprir isso — ver [capítulo 04](04-avaliacao.md). Calibre antes de contabilizar.

:::exercicio {"id":"25-e2","tipo":"numerica","objetivo":"O2","dificuldade":"media"}
Um modelo prevê inadimplência. Aprovar um cliente **bom** dá lucro de **R$ 200**. Aprovar um cliente **mau** dá prejuízo de **R$ 1 000**. Negar não gera lucro nem prejuízo (R$ 0), qualquer que seja o cliente.

Acima de qual **probabilidade de inadimplência** vale mais negar do que aprovar? Responda em fração, com duas casas decimais.

> **gabarito:** 0,17
> **porque:** Chame de *p* a probabilidade de o cliente ser mau. Aprovar tem valor esperado `200 × (1 − p) − 1000 × p`; negar tem valor esperado **0**. O ponto de indiferença é onde os dois se igualam: `200 − 200p − 1000p = 0`, ou seja `200 = 1200p`, então `p = 1/6 ≈ 0,1667` — **0,17** arredondado.
>
> Repare no que acabou de acontecer: o limiar **não é 0,5**. E não é por causa de desequilíbrio de classes — é porque **os erros custam preços diferentes**. Um mau cliente destrói o lucro de cinco bons, então a régua se desloca para o lado cauteloso.
>
> Este é o cálculo que responde a pergunta da diretora lá do início do capítulo. Note também que ele **não usou a AUC**: a AUC serve para escolher o modelo; a matriz de custo serve para operá-lo.
> **volte para:** #da-metrica-ao-dinheiro
:::

## Apresentar sem trair o rigor

O relatório mínimo tem seis partes, nesta ordem: **problema** (a decisão que se quer apoiar), **dados** (origem, período, tamanho, o que foi excluído e por quê), **protocolo** (divisão, busca, métrica escolhida antes), **resultado** (com incerteza), **limitações** (onde o modelo não vale) e **recomendação**.

A parte que quase todo mundo corta é a de **limitações** — e é a que constrói confiança. Um relatório que declara onde o modelo falha é levado mais a sério que um que só apresenta vitórias, porque o leitor entende que alguém procurou.

Três regras para a conversa com quem não é técnico:

- **Fale em consequência, não em métrica.** Não "AUC de 0,91", e sim "entre os 10% que o modelo mais suspeita, encontramos 6 de cada 10 fraudes do período".
- **Nunca prometa o número do teste como se fosse o de produção.** O dado de produção difere; diga isso antes que a realidade diga.
- **Traga o cenário do erro.** Quem decide precisa saber como é um dia ruim, não só o dia médio.

> **O relatório errado, em um exemplo.** Em [`ml-zero/dados/limonada/`](../../ml-zero/dados/limonada/README.md), um modelo com R² de 0,982 sustenta a recomendação "aumente o preço" — porque o preço só subiu no verão, e o coeficiente positivo sobrevive até à regressão múltipla. Das seis partes do relatório acima, a única que pegaria isso é **limitações**: é lá que se escreve "o preço nunca variou fora da alta temporada, logo este modelo não estima efeito de preço". A parte que quase todo mundo corta é a que impediria a recomendação errada. O caso está no [capítulo 05](05-modelos-lineares.md#o-caso-da-limonada).

### A decisão de não lançar

É uma decisão legítima e frequentemente a certa. Motivos suficientes para recusar um modelo que passa nas métricas:

o ganho não paga o custo de manter; o desempenho é bom no geral e **ruim num subgrupo que importa** (ver [capítulo 14](14-interpretabilidade-justica.md)); ninguém consegue explicar uma decisão individual quando for contestada; ou não há como monitorar o modelo depois de implantado (ver [capítulo 16](16-mlops.md)).

Defender essa recusa exige exatamente o mesmo aparato de defender o lançamento: números, protocolo e critério explícito. **"Não vamos lançar" com evidência é trabalho concluído**, não trabalho perdido.

:::exercicio {"id":"25-e3","tipo":"aberta","objetivo":"O4","pontos":3,"dificuldade":"media"}
Seu modelo de triagem de currículos alcança 0,89 de AUC no conjunto de teste, bem acima da triagem manual atual. Ao segmentar o resultado, você descobre que o desempenho é **0,91 para candidatos formados nas cinco universidades mais frequentes na base histórica** e **0,63 para os demais**.

Escreva a recomendação que você levaria à diretoria — incluindo o que você recomenda fazer e por quê.

> **rubrica:** identifica que a média de 0,89 esconde um desempenho ruim num subgrupo;
> reconhece que o subgrupo pior corresponde a quem já era minoria na base histórica, o que caracteriza aprendizado do processo de seleção passado e não da competência dos candidatos;
> NÃO recomenda lançar como está;
> propõe ao menos uma ação concreta — reponderar/coletar dados do subgrupo, usar o modelo só como apoio com revisão humana, ou restringir o escopo declarando a limitação;
> menciona a consequência para pessoas reais, não só a métrica
> **porque:** A resposta fraca compara 0,89 com a triagem manual e recomenda lançar. A resposta forte percebe que **a média esconde a decisão**: para 0,63 de AUC o modelo está perto do acaso, e "perto do acaso" aplicado a currículos significa descartar gente por sorteio — enquanto a empresa acredita estar usando um sistema de 0,89.
>
> O ponto mais fino, e o que separa uma boa resposta de uma excelente: o modelo provavelmente **não está errado sobre os dados** — ele aprendeu corretamente um padrão que existe no histórico. Aprendeu **quem a empresa costumava contratar**. É exatamente o vazamento do [capítulo 02](02-dados.md) em versão social: o modelo capturou o processo de coleta em vez do fenômeno. E a decisão de lançar ou não **não é técnica** — é a mesma lição da seção "De onde isto veio": alguém precisa dizer quanto custa cada erro, e aqui o custo recai sobre pessoas que não estão na sala.
> **volte para:** #a-decisao-de-nao-lancar
:::

## Síntese — o que levar

- O modelo entrega **ordenação**; a decisão exige **um corte**, e o corte exige **um preço**. Sem a matriz de custo, não existe limiar certo.
- **Probabilidade ordena, custo decide.** Pode ser ótimo agir como se a classe menos provável fosse verdadeira.
- O limiar **não é uma decisão técnica**. Quem escolhe calado está decidindo pela área de negócio sem avisar.
- Comparação justa: mesma divisão, mesmo orçamento de busca, métrica escolhida **antes**.
- Diferença sem intervalo é ruído com aparência de resultado. **Bootstrap pareado**, e empate é um achado.
- Empate em desempenho **liberta** a decisão para custo, latência e explicabilidade.
- Contabilize em **benefício**, não em custo: benefício tem linha de base natural.
- **Não lançar é uma decisão legítima**, e exige a mesma evidência de lançar.

## Verificação

1. Um colega diz que o limiar padrão é 0,5 porque "é o meio". Em que situação isso é defensável, e por que quase nunca é o caso?
2. Dois modelos empatam dentro do intervalo de confiança. Liste três critérios que você usaria para decidir, e diga qual pesaria mais no seu contexto.
3. A área de negócio se recusa a estimar o custo de um falso negativo, dizendo que "é impossível colocar preço nisso". O que você faz — e por que aceitar o silêncio é a pior opção?

---

# 18 — O Neurônio Artificial

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-08 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (mais experimentos, mais fontes verificadas) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Descrever o neurônio de McCulloch–Pitts e o que ele computa.
- **O2.** Encontrar, à mão, pesos e limiar que implementem uma função lógica dada.
- **O3.** Explicar geometricamente por que um único neurônio não resolve o XOR.
- **O4.** Situar historicamente por que essa limitação parou a área — e o que a destravou.

## O problema: pode uma máquina pensar em lógica?

Em 1943 não havia computador digital comercial, não havia "Machine Learning", e a pergunta que Warren McCulloch — neurofisiologista — e Walter Pitts — um lógico de vinte anos, autodidata, que vivia sem endereço fixo — se fizeram era outra: **a atividade do cérebro pode ser descrita como lógica?**

A resposta deles foi um modelo brutalmente simples de neurônio ([McCulloch & Pitts, 1943](https://doi.org/10.1007/BF02478259), ✓). O neurônio recebe entradas, multiplica cada uma por um **peso**, soma tudo, e dispara — devolve 1 — se a soma alcançar um **limiar**. Senão, devolve 0.

$$y = \begin{cases} 1 & \text{se } w_1x_1 + w_2x_2 + \dots \geq \theta \\ 0 & \text{se } w_1x_1 + w_2x_2 + \dots < \theta \end{cases}$$

Aqui `y` é a saída, `x` são as entradas, `w` são os pesos e `θ` (teta) é o limiar — a mesma notação do diagrama acima.

É só isso. Uma soma ponderada e uma comparação.

<img src="assets/neuronio-mp.svg" alt="Diagrama do neurônio de McCulloch–Pitts: as entradas x₁ e x₂ são multiplicadas pelos pesos w₁ e w₂, somadas no corpo do neurônio, comparadas com o limiar θ, e a saída é 1 se a soma alcançar o limiar e 0 caso contrário." width="720">

O que McCulloch e Pitts demonstraram foi que **redes desses elementos podem computar qualquer função lógica proposicional**. O argumento era filosófico antes de ser tecnológico: se o pensamento é lógica, e a lógica é computável por neurônios, então o pensamento é computável. Foi uma das ideias fundadoras da inteligência artificial, da teoria de autômatos e da cibernética — quinze anos antes de existir uma máquina que aprendesse alguma coisa.

> **Repare no que ainda não existe aqui: aprendizado.** No modelo de 1943 os pesos são **postos à mão** por quem projeta a rede. Descobrir os pesos automaticamente é o passo seguinte da história, e é o que o perceptron de Rosenblatt traz em 1958.

## De onde isto veio

**O aperto.** McCulloch era neurofisiologista e passara anos atrás de uma pergunta que a fisiologia da época não sabia formular: *que tipo de coisa o cérebro faz, do ponto de vista lógico?* Pitts tinha vinte anos, nenhum diploma, e lia lógica formal desde os doze. Nenhum dos dois queria construir uma máquina — queriam **decidir uma questão filosófica** com ferramenta matemática. O aperto era esse: havia um órgão que evidentemente processava informação, e nenhuma linguagem para descrever o que ele processava.

**O que se fazia antes.** Descrevia-se o neurônio em termos **químicos e elétricos** — potenciais, limiares de disparo, sinapses. Descrição correta e inútil para a pergunta: nenhuma quantidade de eletroquímica dizia se aquilo computava alguma coisa.

**A virada.** Jogar fora quase tudo. Nada de tempo contínuo, nada de química, nada de geometria do axônio — só *"soma o que chega, e dispara se passar de um limite"*. Com essa abstração violenta eles provaram que **redes desses elementos computam qualquer função lógica proposicional**. Se o pensamento é lógica, e a lógica cabe em neurônios, então o pensamento é computável — quinze anos antes de existir máquina que aprendesse coisa alguma.

**A ideia reaproveitável.** **Uma abstração vale pelo que ela permite provar, não pela fidelidade ao original.** O neurônio de 1943 é biologicamente errado de propósito — e é justamente por ter descartado a biologia que rendeu um teorema. Todo modelo que você vai construir neste livro faz a mesma aposta: joga fora o que não serve à pergunta. Saber **o que** foi jogado fora é o que separa usar um modelo de acreditar nele — e é a origem de boa parte do exagero sobre o que redes neurais "entendem".

**O nome.** "Neurônio artificial" é herança da motivação, não descrição do mecanismo. E é mais velho que o campo: a expressão *inteligência artificial* só apareceria treze anos depois.

| Quando | O quê |
|---|---|
| **1943** | McCulloch & Pitts publicam o neurônio lógico |
| **jul–ago de 1948** | Turing escreve, para o National Physical Laboratory, o relatório [*Intelligent Machinery*](https://weightagnostic.github.io/papers/turing1948.pdf) — onde o jogo da imitação aparece pela primeira vez, em forma restrita. O relatório **só foi publicado em 1968** |
| **1950** | Sai na *Mind* [*Computing Machinery and Intelligence*](https://doi.org/10.1093/mind/LIX.236.433), a exposição completa do que hoje se chama **teste de Turing** |
| **31 de agosto de 1955** | McCarthy, Minsky, Rochester e Shannon assinam a [proposta do projeto de Dartmouth](https://www-formal.stanford.edu/jmc/history/dartmouth/dartmouth.html) — onde **"artificial intelligence" aparece pela primeira vez** |
| **1956** | O workshop de Dartmouth acontece, e é tomado como o evento fundador do campo |

Duas coisas valem ficar: **o neurônio artificial é treze anos mais velho que o nome do campo em que vive**, e a ideia de Turing sobre máquinas pensantes é de **1948**, não de 1950 — o texto famoso é o segundo, e o primeiro passou vinte anos numa gaveta.

### A linha até 1986, e o que ela ensina sobre crédito

| Ano | Quem | O quê | Fonte |
|---|---|---|---|
| **1943** | McCulloch & Pitts | O neurônio lógico. Sem aprendizado: os pesos são projetados | [doi:10.1007/BF02478259](https://doi.org/10.1007/BF02478259) |
| **1949** | Hebb | *The Organization of Behavior*: "neurônios que disparam juntos conectam-se juntos" — a primeira ideia de como um peso poderia **mudar** com a experiência | [registro](https://psycnet.apa.org/record/1950-02200-000) |
| **1958** | Rosenblatt | O **perceptron**: a regra de aprendizado que faltava, com prova de convergência para problemas separáveis | [doi:10.1037/h0042519](https://doi.org/10.1037/h0042519) |
| **1969** | Minsky & Papert | *Perceptrons*: a demonstração de que uma camada não computa o XOR | [MIT Press](https://mitpress.mit.edu/9780262534772/perceptrons/) |
| **1970** | Linnainmaa | A **retropropagação** descrita pela primeira vez, em tese de mestrado, em finlandês, sem falar em redes neurais | — |
| **1974** | Werbos | Tese de doutorado: aplicar aquilo a redes neurais; publicações entre 1979 e 1981 | — |
| **1979/80** | Fukushima | O **neocognitron**, primeira arquitetura hierárquica convolucional — treinada **sem** backpropagation. Em japonês em 1979; em inglês em 1980 | [doi:10.1007/BF00344251](https://doi.org/10.1007/BF00344251) |
| **1986** | Rumelhart, Hinton & Williams | Popularizam o backpropagation e mostram as representações aprendidas nas camadas escondidas | [doi:10.1038/323533a0](https://doi.org/10.1038/323533a0) |

Rosenblatt provou que, **se o problema for linearmente separável**, o perceptron converge em número finito de passos. A prova é sólida e a condição é a chave — mas o entusiasmo de 1958 leu só a primeira parte, e a imprensa prometeu máquinas conscientes. Onze anos depois, *Perceptrons* demonstrou com rigor o que você vai descobrir no laboratório abaixo: uma camada não computa o XOR. **O argumento estava correto**; a leitura que se fez dele foi mais ampla do que os autores demonstraram, o financiamento migrou para a IA simbólica, e veio o **inverno da IA**.

A saída, em 1986, tem uma moral que vale além da história: **a limitação nunca foi do neurônio, era da arquitetura de uma camada só.** O [capítulo 09](09-redes-neurais.md) constrói a rede multicamada que resolve isso.

E repare em quem leva o crédito. Rumelhart, Hinton e Williams **popularizaram** o backpropagation; a descrição é de Linnainmaa, dezesseis anos antes, em finlandês, sem mencionar redes neurais. Jürgen Schmidhuber, que passou anos reivindicando a atribuição correta, resume assim: **não é o primeiro inventor que leva o crédito, é o último reinventor.**

> **O espelho disto está no [capítulo 05](05-modelos-lineares.md).** Lá, Gauss descobriu os mínimos quadrados antes e **perdeu** a prioridade para Legendre, que publicou primeiro e argumentou que prioridade se estabelece por publicação. Os dois casos, juntos, dizem o que nenhum diz sozinho: **crédito não segue descoberta, segue comunicação** — e é por isso que publicar, datar e documentar faz parte do método, não da burocracia.

> **Sobre "um italiano em 1979".** Essa memória circula, e não encontrei quem a sustente. O que existe em 1979 são as publicações de Werbos (americano) e o neocognitron de Fukushima (japonês, em inglês no ano seguinte); a prioridade de 1970 é de Linnainmaa, finlandês. Se você tiver a referência, ela entra aqui — até lá o livro registra a dúvida em vez de escolher uma versão.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ᵐ | Datas, autoria e veículo de McCulloch & Pitts (1943), Rosenblatt (1958), Fukushima (1980) e Rumelhart *et al.* (1986) — conferidos no Crossref em 2026-08-08. **Os artigos não foram lidos por inteiro** |
| ✓ᵐ | A proposta de Dartmouth (31/08/1955) e o artigo da *Mind* (1950), pelos documentos ligados acima |
| ⏳ | Que o relatório *Intelligent Machinery* (1948) só veio a público em 1968 |
| ⏳ | A biografia de Pitts (vinte anos, autodidata, sem endereço fixo) — repetida de forma consistente na literatura; não conferida em fonte primária |
| ⏳ | A cronologia de prioridade do backpropagation (Linnainmaa 1970, Werbos 1974) e a frase de Schmidhuber |
| ❌ | "Um italiano desenvolveu o backpropagation em 1979" — procurei e não achei fonte |
| 📖 | A ideia reaproveitável ("uma abstração vale pelo que permite provar") e a leitura de que o inverno veio de uma leitura ampliada de *Perceptrons* |

## Mão na massa: encontre os pesos você mesmo

Antes de ler qualquer explicação, brinque. Ajuste `w₁`, `w₂` e `θ` até a tabela-verdade fechar.

Comece pelo **E (AND)**: o neurônio deve disparar só quando as duas entradas forem 1.

:::lab {"id":"18-l1","tipo":"neuronio-mp","titulo":"Neurônio de McCulloch–Pitts","funcao":"AND"}
Cada ponto no gráfico é uma linha da tabela-verdade. **Verde** = deveria disparar; **branco/cinza** = não deveria. A reta é `w₁x₁ + w₂x₂ = θ`, e a região sombreada é onde o neurônio dispara.

Sua tarefa: mover a reta até que **todos os pontos verdes fiquem dentro da região sombreada e todos os outros fiquem fora**.

Comece pelo **E (AND)**. Depois tente **OU**, **NÃO-E** e **NÃO-OU** — todos têm solução, e cada um tem *infinitas* soluções. Deixe o **OU-EXCLUSIVO (XOR)** por último.
:::

### O que você deveria ter notado

**Primeiro:** não existe *a* resposta certa. Para o AND, `w₁=1, w₂=1, θ=2` funciona; `w₁=0,6, w₂=0,6, θ=1` também; `w₁=3, w₂=2, θ=4,5` também. Infinitas retas separam aqueles quatro pontos — e essa multiplicidade não é defeito, é a natureza do problema. É a mesma razão pela qual dois modelos treinados com sementes diferentes chegam a coeficientes diferentes e à mesma qualidade.

**Segundo:** você estava fazendo, à mão, exatamente o que o gradiente descendente do [capítulo 06](06-otimizacao.md) faz sozinho — mover a fronteira até que os erros acabem. A diferença é que você olhava a tabela inteira e ajustava por intuição; o algoritmo olha um erro por vez e ajusta por regra fixa.

**Terceiro — e este é o ponto do capítulo:** no XOR você travou em 3 de 4.

## Por que o XOR é impossível

Não é falta de habilidade nem de paciência. É geometria.

O XOR dispara em (0,1) e (1,0), e não dispara em (0,0) e (1,1). Coloque os quatro pontos num quadrado: os que devem disparar estão em **cantos opostos**, e os que não devem também.

Uma reta divide o plano em dois lados. Para resolver o XOR ela precisaria deixar dois cantos opostos de um lado e os outros dois do outro — e **nenhuma reta faz isso**. Não importa quanto você gire ou translade: qualquer reta que separe (0,1) de (0,0) e (1,1) vai deixar (1,0) do lado errado.

O nome técnico é **separabilidade linear**. AND, OR, NAND e NOR são linearmente separáveis; XOR não é. E um neurônio de McCulloch–Pitts — ou um perceptron, ou uma regressão logística — traça **exatamente uma reta**.

> É a mesma limitação que o [capítulo 07](07-arvores-ensembles.md) mediu com outro vocabulário: naquele experimento, o modelo linear ficou em 0,4963 de AUC — acaso — porque a fronteira verdadeira era não-monotônica. Aqui você vê a razão em quatro pontos, em vez de em uma tabela de resultados.

:::exercicio {"id":"18-e1","tipo":"multipla","objetivo":"O3","dificuldade":"media"}
Por que um único neurônio de McCulloch–Pitts não consegue implementar o XOR?

- [ ] Porque o XOR exige pesos negativos, e o modelo só admite pesos positivos.
- [x] Porque os casos que devem disparar estão em cantos opostos do quadrado, e nenhuma reta separa cantos opostos.
- [ ] Porque o XOR tem três entradas, e o neurônio só aceita duas.
- [ ] Porque o limiar teria de ser fracionário, o que o modelo original não permitia.

> **gabarito:** Os casos que devem disparar estão em cantos opostos
> **porque:** É geometria, não aritmética. O XOR dispara em (0,1) e (1,0) — cantos opostos do quadrado — e não dispara em (0,0) e (1,1), também opostos entre si. Uma reta divide o plano em dois lados; não existe reta que deixe dois cantos opostos de um lado e os outros dois do outro.
>
> As três alternativas erradas atribuem a limitação a restrições do **modelo** — sinal do peso, número de entradas, limiar fracionário — quando na verdade ela é uma propriedade do **problema**. Nenhuma delas ajudaria: mesmo com pesos reais, negativos e limiar contínuo, a impossibilidade permanece. É por isso que a solução, quando veio, não foi um neurônio melhor: foi **outra camada** de neurônios.
> **volte para:** #por-que-o-xor-e-impossivel
:::

:::exercicio {"id":"18-e2","tipo":"multipla","objetivo":"O4","dificuldade":"media"}
O que, historicamente, destravou a limitação demonstrada em *Perceptrons* (1969)?

- [ ] Computadores mais rápidos, que permitiram testar mais pesos.
- [ ] O abandono do modelo de neurônio de McCulloch–Pitts.
- [x] Empilhar camadas — e uma forma prática de treiná-las, o backpropagation.
- [ ] A substituição do limiar por uma função de ativação contínua.

> **gabarito:** Empilhar camadas, com backpropagation para treiná-las
> **porque:** A limitação era da **arquitetura**, não do neurônio. Com uma camada intermediária, duas fronteiras se combinam e o XOR se resolve. Isso já era sabido em 1969; o que faltava era um jeito **prático de treinar** os pesos das camadas escondidas — e é isso que o backpropagation, popularizado em 1986, entrega.
>
> A última alternativa merece atenção porque está **quase** certa e é o erro mais interessante: trocar o degrau por uma função contínua (como a sigmoide) é de fato **necessário** — sem derivada não há gradiente, e sem gradiente não há backpropagation. Mas sozinha ela não resolve nada: uma regressão logística é exatamente um neurônio com ativação contínua, e continua sem resolver o XOR. A ativação contínua é condição para o remédio, não o remédio.
> **volte para:** #a-historia-entusiasmo-inverno-e-a-saida
:::

:::exercicio {"id":"18-e3","tipo":"numerica","objetivo":"O2","dificuldade":"facil"}
Você quer construir a função **OU (OR)** com pesos `w₁ = 1` e `w₂ = 1`.

Qual é o **maior** valor inteiro de limiar `θ` que faz o neurônio funcionar corretamente?

> **gabarito:** 1
> **porque:** Some as entradas em cada linha da tabela: (0,0) → 0; (0,1) → 1; (1,0) → 1; (1,1) → 2. O OR deve disparar em todas menos na primeira. Então θ precisa ser **maior que 0** e **menor ou igual a 1** — o maior inteiro que satisfaz isso é **θ = 1**.
>
> Com θ = 2 você teria construído o **AND**, não o OR: só (1,1) alcançaria o limiar. Esse é o achado que vale levar do exercício — a mesma dupla de pesos produz funções diferentes conforme o limiar. O limiar não é um detalhe de calibração: ele é parte da função que o neurônio computa. Volte ao laboratório e confirme deslizando só o θ.
> **volte para:** #mao-na-massa-encontre-os-pesos-voce-mesmo
:::

:::exercicio {"id":"18-e4","tipo":"aberta","objetivo":"O1","pontos":3,"dificuldade":"media"}
Explique, para alguém que nunca viu redes neurais, **o que um neurônio artificial faz** — e diga em que ele se parece e em que ele **não** se parece com um neurônio biológico.

> **rubrica:** descreve a operação corretamente: soma ponderada das entradas comparada a um limiar;
> menciona que os pesos determinam a importância de cada entrada;
> aponta ao menos uma semelhança razoável com o neurônio biológico (integrar sinais, disparar ou não);
> aponta ao menos uma diferença importante (ausência de tempo, de química, de estrutura, ou o fato de ser uma simplificação deliberada);
> não trata a analogia biológica como se fosse literal
> **porque:** A operação é simples de enunciar: multiplica cada entrada pelo seu peso, soma, e dispara se a soma alcançar o limiar. O peso é "quanto essa entrada importa"; o limiar é "quão convencido preciso estar para dizer sim".
>
> A parte que separa uma boa resposta de uma decorada é a **analogia**. A semelhança é real e limitada: o neurônio biológico também integra sinais de entrada e dispara de forma tudo-ou-nada. As diferenças são enormes — o neurônio real opera no tempo, com sinais químicos, taxas de disparo, plasticidade e uma geometria que importa; o artificial é uma soma ponderada estática. McCulloch e Pitts sabiam disso: o modelo deles era uma abstração **deliberada**, feita para responder a uma pergunta lógica, não para simular biologia.
>
> Vale saber por que isso importa na prática: tratar a analogia como literal é a origem de boa parte do exagero sobre o que redes neurais "entendem". O nome é herança histórica, não descrição do mecanismo.
> **volte para:** #o-problema-pode-uma-maquina-pensar-em-logica
:::

## Mão na massa: rode o código

Além do laboratório, o capítulo tem código Python que você pode **baixar e rodar** — sem instalar nada, nem NumPy.

| O quê | Como usar |
|---|---|
| **Notebook no Colab** | [abrir direto no Google Colab](https://colab.research.google.com/github/GHDaru/machinelearning/blob/main/ml-zero/etapa-18/neuronio_mp.ipynb) — não precisa instalar nada |
| **Script** | [`ml-zero/etapa-18/neuronio.py`](https://github.com/GHDaru/machinelearning/blob/main/ml-zero/etapa-18/neuronio.py) — `python neuronio.py` |

O notebook tem três partes, e a terceira é a que fecha o capítulo:

1. **Você põe os pesos à mão** — a célula tem `w1, w2, theta = 0.0, 0.0, 0.0` e um comentário `<-- MEXA AQUI`.
2. **O perceptron acha os pesos sozinho** — a regra de Rosenblatt em oito linhas, convergindo em poucas épocas para AND, OR, NAND e NOR.
3. **O XOR por força bruta.** Em vez de argumentar, o notebook **testa 15.625 combinações** de pesos e limiar numa grade fina. O melhor resultado que aparece é **3 de 4**. Nunca 4.

Esse último ponto é o que transforma "é impossível" de afirmação em resultado. E há um detalhe no meio do caminho que vale reparar: treinando o perceptron no XOR, o número de erros por época **nem diminui** — ele oscila. O perceptron não se aproxima da solução, porque não há solução de que se aproximar. É o sintoma do impossível, não do difícil.

## Síntese — o que levar

- O neurônio de McCulloch–Pitts (1943) faz **uma soma ponderada e uma comparação com um limiar**. Nada mais.
- No modelo original **não há aprendizado**: os pesos são postos à mão. Aprender pesos é o perceptron, de 1958.
- Encontrar pesos à mão é fazer manualmente o que o gradiente faz sozinho: mover a fronteira até os erros acabarem.
- Há **infinitas** soluções para cada função separável — e **nenhuma** para o XOR, por geometria.
- A limitação era da **arquitetura de uma camada**, não do neurônio. A saída foi empilhar camadas e treiná-las com backpropagation.
- O neurônio artificial (1943) é **treze anos mais velho que o termo "inteligência artificial"** (1955) — e a ideia de Turing sobre máquinas pensantes está no relatório de **1948**, não no artigo famoso de 1950.
- O backpropagation foi descrito em **1970** (Linnainmaa), aplicado a redes em **1974** (Werbos) e popularizado em **1986**. Em ciência, o crédito vai ao último reinventor.

## Verificação

1. Sem olhar o laboratório, dê pesos e limiar que implementem o NÃO-E (NAND). Depois confira.
2. Explique a alguém, em duas frases, por que o XOR é impossível para um neurônio só.
3. Se uma segunda camada resolve o XOR, por que a área levou quase vinte anos para usá-la?
4. O termo "inteligência artificial" é de 1955 e o neurônio artificial é de 1943. O que isso diz sobre como campos científicos se formam?

---

# 09 — Redes Neurais

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Explicar o perceptron multicamadas como composição de transformações e não-linearidades.
- **O2.** Derivar backpropagation como aplicação da regra da cadeia.
- **O3.** Implementar uma rede densa em NumPy, do forward ao update.
- **O4.** Diagnosticar os modos de falha do treino: gradiente que some, que explode, e inicialização ruim.

## O problema: sabia-se qual era a rede, e não havia como treiná-la

No [capítulo 18](18-neuronio-artificial.md) você travou em 3 de 4. O XOR não sai com um neurônio só, e o motivo é geometria: uma reta não separa cantos opostos de um quadrado.

Este capítulo resolve isso — e vale dizer com prazer, porque a solução é curta: **duas retas**. Uma camada intermediária traça duas fronteiras, e a camada de saída combina as duas. O XOR fecha em 4 de 4.

Só que essa não era a parte difícil. **Depois de 1969 já se sabia que uma camada intermediária resolvia o XOR.** Qualquer um conseguia escrever à mão os pesos que fazem aquilo funcionar — você vai escrever daqui a três parágrafos. O que não existia era um jeito de **descobrir** esses pesos a partir de dados, quando eles são milhares e ninguém sabe o que cada unidade escondida deveria significar.

A regra do perceptron não servia: ela corrige pesos comparando a saída com o rótulo, e a camada escondida **não tem rótulo**. Ninguém sabe o que a terceira unidade da camada do meio deveria ter respondido. Esse é o aperto, e ele durou quase vinte anos.

**1986 não entrega a arquitetura. Entrega o procedimento.**

## De onde isto veio

**O aperto.** A arquitetura estava disponível e inerte. Havia camadas escondidas, havia demonstração de que elas resolviam o que uma camada não resolve, e não havia sinal de erro para elas. A pergunta não era *"que rede usar?"*, era *"como atribuir culpa a um peso que fica no meio do caminho?"*.

**O que se fazia antes.** Duas saídas, ambas ruins. Ficar na **camada única** com a regra do perceptron — barato, convergente, e limitado ao que é linearmente separável. Ou pôr os **pesos escondidos à mão**, projetando cada unidade intermediária como se fosse uma função lógica. Funciona em brinquedos como o XOR; não funciona em nada com mais de uma dúzia de unidades.

**A virada — e ela vem em ordem inversa à intuição.** Primeiro veio o **procedimento**: em 1986, Rumelhart, Hinton e Williams popularizam o backpropagation e mostram que as camadas escondidas aprendem representações úteis sozinhas. Só **depois** veio a licença teórica. Cybenko, em *Approximation by superpositions of a sigmoidal function* (*Math. Control Signals Systems*, 1989), e Hornik, em *Approximation capabilities of multilayer feedforward networks* (*Neural Networks* 4:251–257, 1991), provam que **uma única camada escondida aproxima qualquer função contínua — desde que haja unidades suficientes**.

Repare na ordem. A engenharia funcionou por três anos antes de a matemática dizer que ela podia funcionar. Isso é mais comum do que os livros contam, e é um bom antídoto contra a ideia de que teoria precede prática.

**A ideia reaproveitável — e é a tese deste capítulo: existência não é treinabilidade.** O teorema diz que a rede certa **está** no espaço de hipóteses. Não diz quantas unidades ela precisa. Não diz como achá-la. E não diz se o gradiente descendente chega até ela partindo de onde você inicializou. É um resultado **não construtivo**: garante que o objeto existe sem dar receita para construí-lo.

Guarde isso, porque a confusão é cara e frequente. "A rede pode representar qualquer função" é uma afirmação sobre o **conjunto de funções representáveis**. "A rede vai aprender essa função" é uma afirmação sobre o **procedimento de busca**, sobre os dados e sobre a inicialização. Os vinte anos de dificuldade que o [capítulo 26](26-treinar-redes-profundas.md) narra — gradientes que somem, gradientes que explodem, redes profundas que não treinavam — são exatamente o preço dessa distinção.

**O nome.** "Teorema da aproximação universal" é rótulo posterior: a expressão **não aparece no título de nenhum dos dois artigos**. E há um detalhe de Hornik que o rótulo popular apaga — o poder de aproximação **não vem da função de ativação escolhida**; vem da **estrutura em camadas**. Trocar sigmoide por outra não-linearidade razoável não muda o que a rede pode representar. Muda o quanto ela treina bem, que é outra conversa — a conversa deste livro inteiro.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ᵐ | Cybenko, *Approximation by superpositions of a sigmoidal function*, **Math. Control Signals Systems (1989)**; Hornik, *Approximation capabilities of multilayer feedforward networks*, **Neural Networks 4:251–257 (1991)**. **Os artigos não foram lidos por inteiro** |
| ✓ᵐ | Que a expressão "teorema da aproximação universal" **não consta do título** de nenhum dos dois artigos |
| ✓ᵐ | Rumelhart, Hinton & Williams (1986) — [doi:10.1038/323533a0](https://doi.org/10.1038/323533a0), conferido no [capítulo 18](18-neuronio-artificial.md) |
| ⏳ | Que a prática anterior era camada única com a regra do perceptron, ou pesos escondidos postos à mão |
| ⏳ | A leitura de Hornik de que a fonte do poder de aproximação é a estrutura em camadas, não a ativação |
| 📖 | Que 1986 entrega o **procedimento**, não a arquitetura — e que a licença teórica chegou **depois** da engenharia |
| 📖 | "Existência não é treinabilidade" como a ideia exportável, e os vinte anos do [capítulo 26](26-treinar-redes-profundas.md) como o preço dela |

## Fundamentos: a camada escondida, e o XOR resolvido

Volte ao laboratório do [capítulo 18](18-neuronio-artificial.md) e olhe as retas que você **conseguiu** traçar. O OU funciona. O NÃO-E funciona. O XOR, não.

Agora repare: o XOR é exatamente `(x₁ OU x₂) E (x₁ NÃO-E x₂)` — "pelo menos um, mas não os dois". Duas fronteiras que você já sabe traçar, combinadas por uma terceira que você também já sabe traçar.

É isso que a camada escondida faz. Com o mesmo neurônio de limiar do capítulo 18:

| Unidade | Pesos | Limiar | O que computa |
|---|---|---|---|
| escondida `h₁` | `w₁ = 1`, `w₂ = 1` | `θ = 1` | OU |
| escondida `h₂` | `w₁ = -1`, `w₂ = -1` | `θ = -1` | NÃO-E |
| saída `y` | `w₁ = 1`, `w₂ = 1` | `θ = 2` | E |

Confira nas quatro linhas: (0,0) → h=(0,1) → soma 1, não dispara. (0,1) → h=(1,1) → soma 2, dispara. (1,0) → idem, dispara. (1,1) → h=(1,0) → soma 1, não dispara. **4 de 4.** O que era impossível em um plano ficou trivial em dois passos, porque a camada escondida **reescreveu as entradas** — `h₁` e `h₂` são coordenadas novas, e nelas o problema virou linearmente separável.

**A arquitetura.** Um **perceptron multicamadas** (*multilayer perceptron*, MLP) é isso, generalizado: uma camada de **entrada** (os atributos), uma ou mais camadas **escondidas** e uma camada de **saída**. Cada camada faz duas coisas, sempre nesta ordem: uma transformação linear (`Wx + b`) e uma **não-linearidade** aplicada elemento a elemento. A rede inteira é a composição dessas duas peças, repetida.

A não-linearidade não é enfeite. **Duas camadas lineares empilhadas, sem ativação no meio, são uma camada linear** — o produto de duas matrizes é uma matriz. Sem a não-linearidade, você paga por profundidade e recebe uma regressão. Aliás, o caso extremo já é seu conhecido: uma camada, uma unidade, ativação sigmoide, e você tem a **regressão logística** do [capítulo 28](28-regressao-logistica.md). Um neurônio só.

:::exercicio {"id":"09-e1","tipo":"multipla","objetivo":"O1","dificuldade":"media"}
Uma rede tem duas camadas densas empilhadas, **sem nenhuma função de ativação entre elas**. O que essa rede consegue computar?

- [ ] Qualquer função contínua, pelo teorema da aproximação universal — basta ter unidades suficientes.
- [x] Exatamente o mesmo conjunto de funções que uma única camada linear.
- [ ] O XOR, porque já são duas camadas e duas fronteiras.
- [ ] O dobro de fronteiras de decisão de uma camada só, mas todas paralelas entre si.

> **gabarito:** Exatamente o mesmo que uma única camada linear
> **porque:** Aplicar `W₂(W₁x + b₁) + b₂` é aplicar `(W₂W₁)x + (W₂b₁ + b₂)`. O produto de duas matrizes é uma matriz: a composição colapsa. Você pagou o dobro de parâmetros e de tempo de treino para obter um modelo linear.
>
> As erradas todas confundem **profundidade** com **poder de representação**. O teorema exige a não-linearidade — é ela que impede o colapso; sem ativação, o teorema simplesmente não se aplica. O XOR continua impossível pelo mesmo motivo do [capítulo 18](18-neuronio-artificial.md): a função computada ainda é uma reta, e reta nenhuma separa cantos opostos. E "fronteiras paralelas" é uma imagem sedutora e falsa — não há duas fronteiras, há uma.
>
> A moral prática: **a não-linearidade é o que torna a camada uma camada.** Empilhar transformações lineares não constrói hierarquia nenhuma.
> **volte para:** #fundamentos-a-camada-escondida-e-o-xor-resolvido
:::

## Backpropagation: a regra da cadeia com reaproveitamento

Agora o problema de 1969. Os pesos da tabela acima foram postos à mão. Como descobri-los a partir de dados?

**Primeiro, o degrau tem de sair.** A função-degrau do neurônio de McCulloch–Pitts é plana em toda parte e salta num ponto: sua derivada é zero onde existe e não existe onde importa. **Sem derivada não há gradiente, e sem gradiente não há direção para onde mover o peso.** Por isso as ativações usadas em rede treinável são contínuas: sigmoide, tangente hiperbólica, ReLU. Não é preferência estética — é a condição para que a otimização do [capítulo 06](06-otimizacao.md) tenha o que ler.

**O passo para frente.** A entrada atravessa a rede camada a camada, e cada camada guarda o que calculou. No fim sai uma previsão, e a função de perda transforma previsão e rótulo num único número: o erro.

**O passo para trás.** Aqui está a ideia inteira. O erro da saída depende dos pesos da última camada — isso é fácil de derivar. Mas ele também depende dos pesos da camada anterior, *através* da última camada. É a **regra da cadeia**: a influência de um peso lá atrás sobre o erro lá na frente é o produto das influências ao longo do caminho.

Fazer isso ingenuamente seria absurdo: recalcular o caminho inteiro para cada peso, com milhões de pesos, é trabalho repetido em escala industrial. **O que torna o backpropagation viável é o reaproveitamento.** Calcula-se o erro na saída, propaga-se para trás **uma vez**, e a quantidade que chega a cada camada é reusada por todos os pesos daquela camada. O custo do passo para trás fica da mesma ordem do passo para frente — e é isso, e não a regra da cadeia em si, que é a descoberta prática.

Repare no que backpropagation **não** é: não é um algoritmo de otimização. Ele calcula o gradiente. Quem move os pesos é o gradiente descendente do [capítulo 06](06-otimizacao.md) — a mesma otimização, os mesmos passos, a mesma regularização, só que numa superfície muito maior e cheia de vales.

**A saída, para classificação multiclasse.** A última camada produz um número por classe, e o **softmax** os converte em probabilidades que somam 1: exponencia cada um e divide pela soma. A perda é a **entropia cruzada**, que pune com força a confiança errada — prever 0,99 na classe errada custa muito mais do que prever 0,5. A dupla softmax + entropia cruzada não é acaso: combinadas, o gradiente na saída se reduz a `previsão − rótulo`. Simples de derivar, estável de calcular, barato de implementar.

:::exercicio {"id":"09-e2","tipo":"numerica","objetivo":"O3","dificuldade":"facil"}
Um MLP densa tem **4 entradas**, uma camada escondida de **5 unidades** e **3 saídas**. Todas as camadas têm **viés**.

Quantos parâmetros treináveis a rede tem no total?

> **gabarito:** 43
> **porque:** Conte camada por camada. Primeira: uma matriz 4×5 = 20 pesos, mais 5 vieses (um por unidade de destino) = **25**. Segunda: 5×3 = 15 pesos, mais 3 vieses = **18**. Total **43**.
>
> A regra que vale levar: **os pesos de uma camada formam uma matriz `entradas × saídas`, e há um viés por unidade de destino** — nunca por unidade de origem. Errar isso é o bug mais comum de quem implementa a rede em NumPy pela primeira vez, e ele não aparece como erro de matemática: aparece como uma exceção de dimensão incompatível no passo para frente, ou pior, como uma soma que "funciona" por *broadcasting* e treina errado.
>
> Repare também na escala: 43 parâmetros para uma rede minúscula. Acrescente uma camada escondida de 100 unidades e você passa de mil. É por isso que o custo do passo para trás importa tanto.
> **volte para:** #backpropagation-a-regra-da-cadeia-com-reaproveitamento
:::

## Quantas camadas e quantas unidades — a decisão é empírica

O teorema diz que uma camada escondida basta. Não diz **quantas unidades** — e "unidades suficientes" pode significar um número absurdo. Na prática, redes mais profundas costumam resolver com menos unidades por camada o que uma camada rasa só resolveria com muitas. Isso é observação da prática, não consequência do teorema.

Então como se escolhe? **Empiricamente, e sob validação.** Comece pequeno, aumente até a rede conseguir *overfitar* um subconjunto pequeno dos dados — se ela não consegue decorar 50 exemplos, o problema é capacidade ou bug, não regularização. Depois regularize para trazer a generalização de volta, com as ferramentas do [capítulo 06](06-otimizacao.md). O número de camadas e de unidades é hiperparâmetro, e hiperparâmetro se escolhe com dados de validação, nunca com opinião.

E aqui a tese do capítulo cobra o preço. O teorema garante que **existe** uma configuração de pesos que resolve seu problema. Ele não garante que o seu treino vá encontrá-la — a inicialização pode ser ruim, o gradiente pode sumir antes de chegar às primeiras camadas, os dados podem ser insuficientes para distinguir aquela solução de mil outras. É exatamente por isso que empilhar mais camadas **não funcionou por quase vinte anos** depois de 1986, apesar de o teorema já estar publicado desde 1989. O [capítulo 26](26-treinar-redes-profundas.md) conta o que foi preciso para destravar.

:::exercicio {"id":"09-e3","tipo":"aberta","objetivo":"O4","pontos":3,"dificuldade":"dificil"}
Um colega justifica a escolha da arquitetura assim: *"pelo teorema da aproximação universal, uma camada escondida basta — então se o modelo não está aprendendo, é porque faltam unidades."*

Explique por que o teorema **não** sustenta essa conclusão, e liste o que mais pode estar impedindo o treino.

> **rubrica:** distingue **representabilidade** (a função está no espaço de hipóteses) de **treinabilidade** (o procedimento de busca chega até ela);
> aponta que o teorema é **não construtivo** — não diz quantas unidades, nem como achar os pesos;
> cita ao menos dois impedimentos que não são capacidade: inicialização ruim, gradiente que some ou explode, otimização presa, dados insuficientes ou mal escalados, perda ou taxa de aprendizado inadequadas;
> reconhece que "faltam unidades" é uma hipótese testável — e diz como testá-la (tentar overfitar um subconjunto pequeno);
> não afirma que o teorema está errado, apenas que ele responde a outra pergunta
> **porque:** O teorema é uma afirmação sobre o **conjunto de funções representáveis** por uma arquitetura. A frase do colega é uma afirmação sobre o **procedimento de busca**. São perguntas diferentes, e a segunda é a que atrapalha na prática.
>
> "Não construtivo" é o termo exato: garante-se que o objeto existe sem dar receita para construí-lo. O teorema não dá o número de unidades — e o número que serve pode ser proibitivo. Não dá os pesos. Não promete que o gradiente descendente, saindo da inicialização que você usou, chegue lá.
>
> Uma boa resposta enumera as suspeitas alternativas antes de mexer no tamanho: inicialização (pesos todos iguais quebram a simetria e todas as unidades aprendem a mesma coisa), gradiente que some ou explode ao atravessar camadas, taxa de aprendizado grande demais ou pequena demais, atributos em escalas muito diferentes, rótulos com ruído. E propõe o teste barato que decide entre capacidade e bug: **tente decorar 50 exemplos**. Se a rede não consegue nem isso, acrescentar unidades não vai salvar — há um defeito no caminho do gradiente.
>
> É esta a distinção que explica os vinte anos entre 1986 e as redes profundas que funcionam ([capítulo 26](26-treinar-redes-profundas.md)). O espaço de hipóteses sempre continha a solução. O que faltava era como chegar nela.
> **volte para:** #quantas-camadas-e-quantas-unidades-a-decisao-e-empirica
:::

## Síntese — o que levar

- **O XOR do [capítulo 18](18-neuronio-artificial.md) está resolvido**: uma camada escondida traça duas fronteiras (OU e NÃO-E) e a saída as combina (E). 4 de 4.
- A camada escondida não acrescenta retas: **reescreve as entradas** em coordenadas onde o problema vira linearmente separável.
- **A não-linearidade é o que torna a camada uma camada.** Sem ela, camadas empilhadas colapsam numa só transformação linear.
- Um MLP é composição de `linear → não-linearidade`, repetida. Uma unidade, sigmoide, e você tem a **regressão logística** do [capítulo 28](28-regressao-logistica.md).
- O **degrau não serve** como ativação treinável: sem derivada não há gradiente.
- **Backpropagation é a regra da cadeia com reaproveitamento.** Propaga-se o erro para trás uma vez, e cada camada reusa o que chegou — é o reaproveitamento que torna o custo viável, não a regra da cadeia em si.
- Backpropagation **calcula** o gradiente; quem move os pesos é a otimização do [capítulo 06](06-otimizacao.md).
- **Softmax + entropia cruzada** para multiclasse: o gradiente na saída vira `previsão − rótulo`.
- 1986 não entregou a arquitetura — entregou o **procedimento**. A licença teórica (1989, 1991) chegou **depois** da engenharia.
- **A ideia exportável: existência não é treinabilidade.** O teorema é não construtivo — garante que a rede certa está no espaço de hipóteses, sem dizer quantas unidades, como achá-la, ou se o gradiente chega lá.
- Camadas e unidades são **hiperparâmetros**: escolhem-se sob validação, não por teorema.

## Verificação

1. Escreva os pesos e limiares de um MLP que computa o XOR e confira as quatro linhas da tabela-verdade. Depois explique, em uma frase, o que a camada escondida fez com o espaço de entrada.
2. Explique backpropagation a alguém que conhece a regra da cadeia mas nunca viu uma rede: o que é o passo para frente, o que é o passo para trás, e onde exatamente está o reaproveitamento que torna o custo viável.
3. "Uma camada escondida basta para aproximar qualquer função contínua." Diga o que essa frase garante, o que ela não garante, e por que a diferença entre as duas coisas custou quase vinte anos à área.

---

# 26 — Treinar Redes Profundas

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Explicar por que a inicialização dos pesos determina se a rede treina.
- **O2.** Diagnosticar gradientes que somem e que explodem pelos seus sintomas.
- **O3.** Aplicar dropout, normalização em lote e aumento de dados como regularização.
- **O4.** Escolher entre SGD com momento e otimizadores adaptativos, com critério.

## O problema: a rede de vinte camadas que fica parada

Uma rede de duas camadas treina quase sozinha. Uma de vinte fica parada.

A cena é sempre a mesma. A perda desce um pouco nas primeiras épocas e estaciona. Você reduz o passo de aprendizado; nada muda. Aumenta; a perda vira `NaN`. Troca o otimizador, troca a arquitetura, coleta mais dados. Nada muda. A rede tem vinte camadas e se comporta como se tivesse três — porque, na prática, ela tem três: as outras dezessete nunca receberam sinal para ajustar coisa alguma.

Isso não é uma anedota de iniciante. **Foi o estado normal do campo até cerca de 2010.** Sabia-se empilhar camadas; não se sabia treiná-las. E o que destravou não foi mais computador nem mais dado — foi entender o que estava acontecendo entre a saída e a primeira camada.

## De onde isto veio

**O aperto — Munique, 15 de junho de 1991.** Um aluno de **graduação** da Technische Universität München entrega uma *Diplomarbeit* de 74 páginas e faz o que ninguém tinha feito: em vez de propor mais um truque, ele **mede** por que o erro não chega às camadas do fundo.

Vale ler a folha de rosto com atenção, porque ela contraria a lembrança coletiva. O autor assina **Josef Hochreiter** — não "Sepp". O *Aufgabensteller*, o orientador formal, é o **Prof. W. Brauer**. **Jürgen Schmidhuber** aparece como *Betreuer*, o supervisor de fato. E o capítulo 4 do trabalho já se chama **"Konstanter Fehlerrückfluß"** — refluxo *constante* do erro. Isto é: **a LSTM de 1997 já estava nomeada em 1991**, seis anos antes de existir. A §2.3 diz, em alemão, que o produto dos pesos "exponentiell fällt bzw. steigt": cai ou cresce exponencialmente.

**O que se fazia antes.** Culpava-se a arquitetura, os dados, o passo de aprendizado. Tratava-se sintoma. Cada equipe tinha seu conjunto de superstições sobre o que fazia uma rede profunda treinar, e nenhuma delas explicava por que o remédio funcionava aqui e falhava ali.

**A virada.** Nomear a causa. O gradiente que chega à primeira camada é um **produto** de muitos fatores, um por camada atravessada. Produto de muitos fatores menores que 1 vai a zero exponencialmente; produto de fatores maiores que 1 explode do mesmo jeito. E daí segue a frase que organiza o capítulo inteiro: **nenhum hiperparâmetro conserta uma exponencial.** Ajustar a taxa de aprendizado contra um fator 10⁻¹² é discutir o centavo de uma dívida de milhões.

**A ideia reaproveitável.** *Diagnóstico antes do remédio — e o diagnóstico dura mais que o remédio.* O texto de 1991 não resolve o problema: ele o **mede**. Trinta e cinco anos depois, o remédio já mudou quatro vezes; o diagnóstico, não. Quem aprende remédios envelhece com eles; quem aprende o diagnóstico reconhece o mesmo problema na próxima arquitetura, que ainda não foi inventada.

**O nome.** *Vanishing gradient* é rótulo inglês, posterior. O original é alemão, e é uma descrição, não um apelido.

**O limite do que este capítulo afirma.** A citação corrente do problema, na literatura, costuma ser Bengio, Simard & Frasconi (1994), em inglês. **Não conseguimos conferir se aquele artigo cita a tese de 1991.** Então o capítulo diz duas coisas e para: Hochreiter mediu o fenômeno em 1991, em alemão; e a citação que circula é de 1994. Ele **não afirma** que houve omissão de crédito — isso exigiria a leitura que não fizemos.

E há o desfecho que quebra o padrão dos capítulos [05](05-modelos-lineares.md), [18](18-neuronio-artificial.md) e [08](08-nao-supervisionado.md), onde crédito não segue descoberta e sim comunicação: **Hochreiter não foi apagado.** Ele volta em 1997 com a LSTM (*Long Short-Term Memory*), a partir do mesmo diagnóstico, e leva o crédito. Este é o caso **atenuado** do padrão: comunicar tarde, ou no idioma errado, custou a prioridade sobre o problema — não a carreira de quem o formulou.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ | A folha de rosto e a estrutura da Diplomarbeit de 74 páginas (15/06/1991, TUM): assinatura "Josef Hochreiter", Aufgabensteller **W. Brauer**, Betreuer **J. Schmidhuber**, capítulo 4 "Konstanter Fehlerrückfluß" e a §2.3 ("exponentiell fällt bzw. steigt") — [PDF](https://people.idsia.ch/~juergen/SeppHochreiter1991ThesisAdvisorSchmidhuber.pdf), **lido no original** |
| ✓ᵐ | Bengio, Simard & Frasconi (1994) como a citação corrente do problema em inglês |
| ❌ | **Se o artigo de 1994 cita a tese de 1991** — procuramos e não conseguimos conferir. É por isso que o capítulo não afirma omissão de crédito |
| ✓ᵐ | Glorot & Bengio (AISTATS 2010); Nair & Hinton (ICML 2010); Glorot, Bordes & Bengio (AISTATS 2011); Kingma & Ba (2014); Srivastava, Hinton *et al.* (JMLR 2014); Ioffe & Szegedy (2015); He, Zhang, Ren & Sun (ICCV 2015) — metadados conferidos, artigos não abertos |
| ✓ᵐ | Santurkar *et al.*, *How Does Batch Normalization Help Optimization? (No, It Is Not About Internal Covariate Shift)* — [arXiv:1805.11604](https://arxiv.org/abs/1805.11604) |
| ⏳ | "Adam" como *adaptive moment estimation*; e a anedota do caixa de banco que roda de guichê para impedir conluio, contada como origem do dropout — não conferida em fala primária |
| 📖 | A leitura de que o diagnóstico de 1991 sobreviveu a quatro gerações de remédio, e de que este é o caso **atenuado** do padrão de crédito dos capítulos 05, 08 e 18 |

## Fundamentos: o gradiente é um produto, e produtos são traiçoeiros

A retropropagação leva o erro da saída até a primeira camada aplicando a regra da cadeia, camada por camada. Cada camada atravessada **multiplica** o que passou por ela. O gradiente que chega lá embaixo não é uma soma de contribuições: é um produto de vinte fatores.

Some multiplique. A derivada da sigmoide vale no máximo 0,25, e só no ponto central — nas pontas ela é praticamente zero. Com 0,25 por camada, dez camadas dão 0,25¹⁰ ≈ 0,00000095. O erro chega à primeira camada dividido por um milhão. Ela não está aprendendo devagar: ela não está aprendendo.

O outro lado da mesma moeda é a **explosão**. Se os fatores forem maiores que 1, o produto cresce na mesma velocidade, e o sintoma é diferente e inconfundível: a perda salta, vira `inf` e depois `NaN`, tipicamente em poucas iterações. A explosão tem remédio de uma linha — o **grampo de gradiente** (*gradient clipping*): se a norma do gradiente passar de um limite, reescale-a para o limite. Isso funciona porque a direção continua boa; só o tamanho estava absurdo. **A explosão é o caso fácil, e é sintomática: ela grita.** O desaparecimento é silencioso, e por isso é o problema caro.

Tudo isto é a otimização do [capítulo 06](06-otimizacao.md) — mesma descida, mesma perda, mesmo gradiente. O que a profundidade acrescenta não é uma teoria nova; é uma **cadeia longa de multiplicações** entre o erro e o parâmetro que você quer ajustar.

:::exercicio {"id":"26-e1","tipo":"numerica","objetivo":"O2","dificuldade":"facil"}
Numa rede com sigmoide, suponha que cada camada atravessada multiplique o gradiente por **0,25** (o melhor caso da sigmoide). A partir de quantas camadas o gradiente que chega à primeira fica **abaixo de um milionésimo** (10⁻⁶) do que saiu da última?

Responda com um número inteiro de camadas.

> **gabarito:** 10 ± 0,4
> **porque:** É a conta `0,25ⁿ < 10⁻⁶`. Cada camada tira um fator 4: 0,25⁵ ≈ 0,00098 (um milésimo) e 0,25¹⁰ ≈ 0,00000095 — abaixo do milionésimo já na décima camada.
>
> O que importa não é o 10, é a **forma da curva**. Não há degradação suave: a cada cinco camadas o sinal perde três casas decimais. Por isso nenhum ajuste de taxa de aprendizado resolve — multiplicar o passo por 10 devolve uma casa de um buraco de seis. Compare com uma rede de 3 camadas (0,25³ ≈ 0,016, perfeitamente treinável) e você tem a razão de duas camadas treinarem sozinhas e vinte não treinarem de jeito nenhum.
> **volte para:** #fundamentos-o-gradiente-e-um-produto-e-produtos-sao-traicoeiros
:::

### Inicialização: por que zero não funciona e por que a variância importa

Inicializar todos os pesos com **zero** parece neutro e é fatal: todos os neurônios de uma camada calculam a mesma coisa, recebem o mesmo gradiente e se atualizam de forma idêntica para sempre. Uma camada de 512 neurônios simétricos é uma camada de 1 neurônio, com 512 vezes o custo. Quebrar a simetria é a primeira função do sorteio inicial.

Mas *qual* sorteio, e essa é a pergunta de verdade. Pesos grandes demais saturam as ativações e disparam a explosão; pequenos demais aceleram o desaparecimento. O que precisa ser preservado é a **variância do sinal** ao atravessar a camada — porque a variância do produto é o que decide se a cadeia encolhe ou cresce. Glorot & Bengio (2010) tratam disso, e repare no título: *Understanding the difficulty of training deep feedforward neural networks*. **Entender vem antes de consertar**; a fórmula de inicialização que hoje leva o nome deles é subproduto do estudo, não a tese dele.

Cinco anos depois, He *et al.* (2015) apontam a letra miúda: a dedução de Xavier supunha ativação **linear**, o que **é inválido sob ReLU** — que zera metade das entradas e, com isso, corta a variância pela metade. Daí a inicialização He, com o fator 2 que compensa exatamente essa perda. Não é um truque melhor: é a mesma conta refeita sob a hipótese certa.

:::exercicio {"id":"26-e2","tipo":"multipla","objetivo":"O1","dificuldade":"media"}
Uma equipe troca a ativação de uma rede de 30 camadas de `tanh` para `ReLU` e mantém a inicialização de Xavier/Glorot, que vinha funcionando. O treino, que antes convergia devagar, agora estagna. Qual é a explicação mais precisa?

- [ ] A ReLU é inadequada para redes muito profundas; acima de ~20 camadas só ativações saturantes funcionam.
- [x] A dedução de Xavier supõe ativação aproximadamente linear; sob ReLU, metade das entradas é zerada e a variância do sinal encolhe camada a camada — a inicialização He corrige isso com o fator 2.
- [ ] O problema é a taxa de aprendizado: ReLU exige taxa menor, e basta dividi-la por 10.
- [ ] Inicialização não interage com a ativação; as duas escolhas são independentes e o problema está em outro lugar.

> **gabarito:** Xavier supõe ativação linear — hipótese inválida sob ReLU; use a inicialização He
> **porque:** Inicialização e ativação **não são escolhas independentes**: a inicialização existe para preservar a variância do sinal, e quanto de variância sobrevive depende de qual ativação está no caminho. A ReLU zera as entradas negativas, ou seja, descarta cerca de metade do sinal — algo que a dedução de Xavier, feita no regime linear, não previa. Trinta camadas de encolhimento de variância reproduzem o desaparecimento do gradiente com outra causa imediata e a mesma matemática por trás: um produto.
>
> Sobre as erradas: **a ReLU é justamente o que viabilizou redes profundas**, não o que as impede. **Dividir a taxa por 10** não muda a variância propagada — é o clássico ajuste de hiperparâmetro contra uma exponencial. E dizer que as duas escolhas são independentes é exatamente o mal-entendido que este exercício existe para desfazer.
> **volte para:** #inicializacao-por-que-zero-nao-funciona-e-por-que-a-variancia-importa
:::

### Ativação: a sigmoide satura, a ReLU não — e o neurônio morto é o preço

A sigmoide comprime qualquer entrada no intervalo (0, 1). Longe do centro, ela é quase plana — e ativação plana significa derivada quase zero, isto é, mais um fator minúsculo no produto. A **ReLU** (*Rectified Linear Unit*) troca isso por algo grosseiro e eficaz: zera o negativo e devolve o positivo intacto. Na região ativa, sua derivada é exatamente **1**, e um fator 1 não encolhe o produto.

A história de como ela entrou é instrutiva. Nair & Hinton (2010) a apresentam **pela porta de trás**, num artigo sobre máquinas de Boltzmann restritas. E quando Glorot, Bordes & Bengio (2011) a defendem de frente, o argumento principal não é velocidade — é **esparsidade**: com metade das unidades em zero, a representação fica esparsa, e isso é apresentado como virtude, não como efeito colateral.

O preço tem nome: **neurônio morto**. Uma unidade que passa a receber só entradas negativas devolve zero, tem derivada zero e nunca mais se atualiza — está desligada em definitivo. Variantes como *Leaky* ReLU e GELU existem para manter uma inclinação pequena no lado negativo e evitar exatamente isso.

## O kit de conserto: um diagnóstico, quatro remédios, vinte e cinco anos

Aqui está a competência que este capítulo quer formar: **reconhecer o mesmo diagnóstico sob remédios que não se parecem em nada.** "O gradiente é um produto, e produtos somem ou explodem" (1991) gerou quatro famílias de solução, escritas por gente diferente, em décadas diferentes, com vocabulários diferentes — e todas atacam a mesma multiplicação.

| Remédio | Como ataca o produto | Onde está no livro |
|---|---|---|
| **LSTM** (1997) | cria um canal de memória por onde o erro passa **sem ser multiplicado** | [cap. 11](11-sequencias-linguagem.md) |
| **Inicialização** (Xavier 2010, He 2015) | escolhe a variância inicial para que o produto **não encolha nem cresça** | seção acima |
| **ReLU** (2010–2011) | derivada **1** na região ativa: o fator deixa de reduzir | seção acima |
| **Conexão residual** (2015) | acrescenta um caminho **aditivo** que atravessa o bloco intacto | [cap. 10](10-visao.md) |

A conexão residual fecha o argumento de forma quase literária: se o problema é multiplicação, some. `saída = bloco(x) + x` dá ao gradiente uma rota direta até as camadas do fundo, e foi isso que tornou rotineiro treinar redes de mais de cem camadas. Com ela, He *et al.* (2015) reportam 4,94% de erro top-5 no ImageNet — **o primeiro resultado a passar o humano reportado, de 5,1%**.

### O resto do kit: normalização, dropout e otimizadores

**Normalização.** A *batch normalization* (Ioffe & Szegedy, 2015) padroniza as ativações de cada camada usando as estatísticas do lote; a *layer normalization* faz o mesmo usando as estatísticas de **cada exemplo**, dentro da camada — o que a torna a escolha quando o lote é pequeno ou o comprimento varia, como em sequências.

**Dropout.** Srivastava, Hinton *et al.* (JMLR, 2014) desligam unidades ao acaso durante o treino. Repare que este remédio resolve **outro** problema: é regularização, combate *overfitting*, não o gradiente. A anedota do caixa de banco que roda de guichê para impedir conluio entre funcionários — usada para explicar por que impedir a coadaptação entre neurônios ajuda — circula muito e **não foi conferida em fala primária**: ⏳.

**Otimizadores.** Adam (Kingma & Ba, 2014) mantém estimativas de primeiro e segundo momentos do gradiente e adapta o passo por parâmetro. Na prática: converge rápido e **perdoa uma taxa de aprendizado mal escolhida** — o que é exatamente sua virtude e seu risco, porque esconde diagnósticos. SGD (*Stochastic Gradient Descent*) com momento, bem ajustado e com boa agenda de taxa, ainda entrega generalização igual ou melhor em visão, ao custo de exigir mais ajuste manual. Critério honesto: **Adam para começar e para iterar rápido; SGD com momento quando o último ponto percentual importa e há orçamento para ajustar.** E nenhum dos dois conserta uma exponencial.

## "Funciona" e "sabemos por quê" são duas afirmações

Este é o episódio mais didático do capítulo, e por isso tem seção própria.

Ioffe & Szegedy (2015) explicaram a *batch normalization* por um mecanismo: o **"internal covariate shift"** — a distribuição das entradas de cada camada mudaria durante o treino, e normalizar estabilizaria isso. A explicação é intuitiva, virou folclore de sala de aula e foi repetida em centenas de tutoriais.

Em 2018, Santurkar *et al.* publicam *How Does Batch Normalization Help Optimization? (No, It Is Not About Internal Covariate Shift)* e mostram que **o método funciona e a explicação não se sustenta**. A batch norm continua ajudando; a razão pela qual ajuda foi outra.

A lição vale muito além da normalização: **"funciona" e "sabemos por quê" são afirmações independentes, e a segunda pode cair sem derrubar a primeira.** É o mesmo padrão do Cauchy do [capítulo 06](06-otimizacao.md), que publicou o método do gradiente em 1847 sem prova de convergência — método correto, justificativa incompleta, décadas de uso proveitoso no meio.

A consequência prática é dura e útil: **não derive decisões de projeto de uma história de mecanismo que nunca foi testada.** Se a sua justificativa para usar um componente é a narrativa que veio no artigo, e não o efeito medido no seu problema, você está apostando na parte mais frágil da evidência.

:::exercicio {"id":"26-e3","tipo":"aberta","objetivo":"O4","pontos":3,"dificuldade":"dificil"}
Uma equipe treina uma rede densa de 40 camadas com sigmoide, inicialização uniforme pequena e SGD. A perda cai de 2,30 para 2,25 na primeira época e depois não se move por 50 épocas. A acurácia fica em nível de acaso. Em três semanas, a equipe trocou o otimizador de SGD para Adam, depois para RMSProp, testou seis taxas de aprendizado e dobrou o conjunto de dados. Nada mudou.

Diga o que você mediria **antes** de propor qualquer correção, qual é o diagnóstico mais provável e o que faria em seguida.

> **rubrica:** propõe **medir antes de corrigir** — norma do gradiente por camada, e/ou distribuição das ativações por camada, comparando o topo com o fundo da rede;
> identifica o desaparecimento do gradiente como diagnóstico mais provável, ligando-o à sigmoide (derivada ≤ 0,25) elevada a ~40 camadas;
> explica **por que a troca de otimizador não podia funcionar**: otimizador reescala o passo, não restaura sinal que chegou como 10⁻²⁰ — nenhum hiperparâmetro conserta uma exponencial;
> propõe correções que atacam o produto (ReLU, inicialização He, conexões residuais, normalização), não hiperparâmetros;
> distingue os sintomas: perda travada = gradiente sumindo; perda em `NaN` = gradiente explodindo, e aí o remédio é o grampo
> **porque:** A resposta fraca escolhe um remédio — "use ReLU", "põe batch norm" — e pode até acertar por sorte. A resposta forte faz o que a tese de 1991 fez: **mede primeiro**. Uma linha que imprime a norma do gradiente por camada encerra a discussão em minutos, e mostra a queda de várias ordens de grandeza entre a camada 40 e a camada 1.
>
> As três semanas perdidas são o conteúdo do exercício, não um detalhe do enunciado. Otimizador, taxa de aprendizado e volume de dados são todos ajustes **multiplicativos sobre um sinal que não existe**. Nenhum deles poderia funcionar, e isso era previsível antes do primeiro teste — bastava conhecer o diagnóstico.
>
> Sobre o critério de otimizador, que é o objetivo aqui: Adam é a escolha certa para iterar rápido e perdoa taxa mal escolhida; SGD com momento e boa agenda costuma generalizar igual ou melhor quando há orçamento de ajuste. Mas a pergunta "Adam ou SGD?" só é legítima **depois** que o sinal chega às camadas do fundo. Antes disso, ela é uma pergunta bem formulada sobre o problema errado.
> **volte para:** #o-kit-de-conserto-um-diagnostico-quatro-remedios-vinte-e-cinco-anos
:::

## Síntese — o que levar

- O gradiente que chega à primeira camada é um **produto** de um fator por camada. Produtos somem ou explodem exponencialmente.
- **Nenhum hiperparâmetro conserta uma exponencial.** Taxa, otimizador e volume de dados são ajustes multiplicativos sobre um sinal que já não existe.
- Os dois sintomas são opostos e inconfundíveis: **perda travada** = gradiente sumindo (silencioso, caro); **`NaN`** = gradiente explodindo (grita, e o grampo resolve).
- **Zero não inicializa nada**: mata a simetria entre neurônios. O que se escolhe de verdade é a **variância**.
- Inicialização e ativação **não são independentes**: Xavier supõe regime linear, He corrige para ReLU.
- **ReLU** troca saturação por derivada 1 — e cobra o **neurônio morto** como preço.
- **Dropout resolve outro problema** (overfitting), não o gradiente. Confundir os dois leva a aplicar o remédio errado com convicção.
- **Adam** para começar e iterar rápido; **SGD com momento** quando o último ponto percentual importa e há orçamento de ajuste.
- **A ideia exportável:** diagnóstico antes do remédio — e o diagnóstico dura mais que o remédio. Quatro gerações de solução, um único enunciado de 1991.
- **"Funciona" e "sabemos por quê" são afirmações independentes.** A batch norm é o caso-modelo: o método sobreviveu, a explicação não.

## Verificação

1. Uma rede de 25 camadas trava com a perda praticamente constante desde a primeira época. Descreva, em ordem, as **duas medições** que você faria antes de mexer em qualquer hiperparâmetro — e diga o que cada resultado possível eliminaria como causa.
2. Explique por que inicializar todos os pesos com zero impede o aprendizado, e por que a resposta "sorteie valores pequenos" está incompleta. Que quantidade a inicialização precisa preservar, e por que ela muda quando a ativação passa de `tanh` para ReLU?
3. Você usa dropout, batch norm e aumento de dados no mesmo treino. Para cada um, diga qual problema ele ataca e como você **mediria** se está ajudando neste seu caso — sem recorrer à justificativa que veio no artigo original.

---

# 10 — Visão Computacional

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Explicar convolução como imposição de invariância translacional.
- **O2.** Justificar por que compartilhar pesos reduz a necessidade de dados.
- **O3.** Aplicar transferência de aprendizado e decidir o que congelar.
- **O4.** Projetar aumentação de dados coerente com o domínio do problema.

## O problema: o mesmo gato, dez mil vezes

Uma foto de 224×224 pixels coloridos são 150 528 números. Ligue isso a uma camada densa de 128 unidades, como no [capítulo 09](09-redes-neurais.md), e você acaba de escrever 19 milhões de pesos — para uma única camada, a primeira.

O tamanho é o problema menor. O problema maior é o que essa camada **acredita**: que cada pixel é uma variável independente, sem vizinho. Embaralhe as 150 528 posições com uma permutação fixa e treine de novo — a rede densa aprende exatamente igual. Para ela, a imagem nunca foi uma imagem; foi uma lista.

A consequência aparece na conta de dados. Um gato no canto superior esquerdo e o mesmo gato no canto inferior direito ativam conjuntos de pesos **disjuntos**. Nada do que a rede aprendeu numa posição serve na outra. Ou você mostra o gato em todas as posições possíveis, ou ela aprende um detector de gato-no-canto-esquerdo. É o pior dos dois mundos: parâmetros demais e generalização de menos.

## De onde isto veio

**O aperto.** Fim dos anos 1950. David Hubel e Torsten Wiesel enfiam um eletrodo no córtex visual de um gato anestesiado, projetam pontos de luz numa tela e esperam o neurônio disparar. Ele não dispara. Passam meses assim. Conta-se que a célula finalmente respondeu quando eles trocavam o slide e **a borda da lâmina de vidro** cruzou a tela — o estímulo acidental funcionou onde o estímulo planejado falhara.

**O que se fazia antes.** Procurava-se um **detector de ponto**. A suposição era natural e estava errada: se a retina recebe a imagem como um mosaico de pontos, o córtex deveria compor a visão a partir de pontos. Estava-se procurando o pixel dentro do cérebro.

**A virada.** O córtex não detecta pontos: detecta **bordas com orientação**. Uma célula responde a uma barra inclinada a 30°, e cala diante da mesma barra a 90°. E há hierarquia — as "células simples", presas a uma posição, alimentam "células complexas", que respondem à mesma orientação **em qualquer lugar** do campo receptivo. Estrutura mais primitiva feita de partes, tolerância à posição construída em cima.

**A ideia reaproveitável.** *A primitiva certa não é a mais elementar.* O ponto é mais simples que a borda — e é a primitiva **errada**. Achar a unidade mínima da **representação** não é o mesmo trabalho que achar a unidade mínima do **sinal**, e confundir as duas é o erro de projeto mais caro que existe. É o [capítulo 03](03-representacao.md) inteiro, dito por um eletrodo.

**O nome.** "Célula simples" e "célula complexa" são deles. Em 1979/80, Kunihiko Fukushima empilha essas duas em cascata no **neocognitron** e chama as camadas de **S-cells** e **C-cells** — os nomes atravessaram da biologia para a engenharia sem tradução.

**A linha.** Hubel & Wiesel (1959) → neocognitron de Fukushima (1979/80), já com S/C-cells alternadas e treinado **sem retropropagação** (ver [capítulo 18](18-neuronio-artificial.md)) → LeCun e colegas (1989) treinam uma rede convolucional em **CEPs manuscritos do Serviço Postal dos EUA**: 7 291 imagens de 16×16, cerca de 9 760 parâmetros, **três dias numa SUN-4/260** → LeNet-5 (1998) → AlexNet (2012) → ResNet (2016).

**O intervalo, e é um dos maiores do livro.** De Hubel & Wiesel a AlexNet vão **53 anos**. Compare com os 59 do [capítulo 03](03-representacao.md), os ~80 do [capítulo 13](13-reforco.md), os 43 do [capítulo 24](24-series-temporais.md). Agora a contra-prova, que vem no [capítulo 12](12-modelos-de-fundacao.md): do Transformer (2017) a BERT e GPT (2018) passou-se **cerca de um ano**. A diferença não é a qualidade das ideias. É que em 2017 já existia **infraestrutura de reprodução compartilhada** — arXiv, código aberto, GPU comprável, benchmark comum — além da pergunta precisa. Meio século da história desta área foi, em boa parte, o tempo de construir isso.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ᵐ | Hubel & Wiesel, *Receptive fields of single neurones in the cat's striate cortex*, **J. Physiol. 148:574–591 (1959)** — obra, autoria, ano e veículo |
| ⏳ | Que a distinção entre **células simples e complexas** e a hierarquia entre elas estejam nesse artigo de 1959. A literatura a associa ao trabalho seguinte da dupla, de **1962**; não conferimos em qual dos dois ela aparece, e ✓ᵐ não autorizaria afirmar conteúdo interno de nenhum modo |
| ✓ᵐ | Fukushima, neocognitron (1979/80): S-cells e C-cells em cascata, herdando os nomes de Hubel & Wiesel |
| ✓ᵐ | LeCun et al., **Neural Computation 1:541–551 (1989)** — obra, autoria, ano e veículo |
| ⏳ | Os números internos desse artigo (7 291 imagens de 16×16, ~9 760 parâmetros, três dias numa SUN-4/260) e a origem postal do dado. **O artigo está atrás de paywall e não foi aberto**; ✓ᵐ prova que a obra existe, não o que ela mede |
| ⏳ | A anedota da **borda da lâmina de vidro** como o estímulo que finalmente fez a célula disparar — atribuição corrente, não conferida em fonte primária |
| ⏳ | Que a busca anterior era por um "detector de ponto", por suposição de que a visão se compõe a partir de pixels |
| ⏳ | Que o neocognitron foi treinado sem retropropagação |
| 📖 | A leitura de que "a primitiva certa não é a mais elementar" é a ideia exportável do episódio |
| 📖 | A leitura do intervalo de 53 anos contra o ~1 ano do [capítulo 12](12-modelos-de-fundacao.md) como evidência de que **infraestrutura de reprodução** encurta o intervalo |
| ✓ | **Tudo o que este capítulo atribui ao artigo da AlexNet** — o limite de 3 GB da GTX 580, a decisão de partir a rede em duas GPUs, os cinco a seis dias de treino, a ReLU seis vezes mais rápida que a tangente hiperbólica no CIFAR-10, e os 15,3% contra 26,2% de erro top-5 — vem do [PDF original do NIPS 2012](https://proceedings.neurips.cc/paper/4824-imagenet-classification-with-deep-convolutional-neural-networks.pdf), **lido**. As frases entre aspas na seção seguinte são transcrições literais |

## Fundamentos: o filtro que desliza e o peso que se repete

Um **filtro** (ou *kernel*) é uma matrizinha de pesos — 3×3, 5×5 — que percorre a imagem inteira. Em cada posição, multiplica-se o filtro pelo pedaço de imagem sob ele e soma-se: um número. Deslize por todas as posições e o resultado é outra imagem, o **mapa de ativação**, alto onde o padrão do filtro apareceu e baixo onde não apareceu.

Três consequências saem daí, e as três importam.

**Conectividade local.** Cada saída olha só uma janelinha — o **campo receptivo**. Isso codifica no modelo um fato sobre imagens que a rede densa ignora: pixels vizinhos se relacionam, pixels distantes quase não.

**Compartilhamento de pesos.** É o **mesmo** filtro em todas as posições. Um detector de borda vertical aprendido no canto esquerdo já vale no canto direito, de graça. Aqui está a resposta ao problema de dados: cada exemplo de treino atualiza os mesmos poucos pesos milhares de vezes, uma por posição. Menos parâmetros para estimar, mais evidência por parâmetro.

**Invariância a translação.** Deslocar o objeto desloca o mapa de ativação — não muda o que foi detectado. A rede não precisa reaprender o gato em cada canto porque, para ela, é o mesmo gato deslocado.

Repare no que isso é: uma **restrição** imposta de fora. A camada convolucional é uma camada densa proibida de fazer quase tudo o que poderia — pesos amarrados uns aos outros, conexões distantes zeradas. A restrição não é o preço do desempenho; é a **fonte** dele. Uma rede com menos liberdade e a hipótese certa embutida vence uma rede livre que precisa descobrir a hipótese a partir de dados que ninguém tem.

:::exercicio {"id":"10-e1","tipo":"numerica","objetivo":"O2","dificuldade":"facil"}
Uma imagem colorida de 224×224 tem 3 canais. Considere uma camada convolucional com **64 filtros de 3×3**, aplicada a essa entrada.

Quantos **pesos** (ignorando os vieses) essa camada tem?

> **gabarito:** 1728
> **porque:** Cada filtro cobre 3×3 posições em **cada um dos 3 canais** de entrada: `3 × 3 × 3 = 27` pesos por filtro. São 64 filtros: `27 × 64 = 1 728`.
>
> Agora a comparação, que é o ponto do exercício. Uma camada **densa** com 64 unidades sobre a mesma imagem precisaria de `224 × 224 × 3 × 64 = 9 633 792` pesos — cerca de **5 573 vezes mais**. E não é só a conta de memória: são 9,6 milhões de números a estimar a partir dos seus dados, contra 1 728.
>
> Note de onde vem a economia. Não é de olhar menos pixels — o filtro percorre a imagem toda. Vem de usar **os mesmos pesos** em todas as posições. O número de parâmetros da camada convolucional **não depende do tamanho da imagem**; o da densa é proporcional a ele.
> **volte para:** #fundamentos-o-filtro-que-desliza-e-o-peso-que-se-repete
:::

### Pooling e a hierarquia de features

O **pooling** reduz a resolução do mapa de ativação — tipicamente pegando o máximo de cada janela 2×2. Perde-se posição exata e ganha-se duas coisas: tolerância a pequenos deslocamentos e um campo receptivo que **cresce** nas camadas seguintes, porque cada unidade passa a resumir uma região maior do original.

Empilhe isso e aparece a **hierarquia de features**, que é a estrutura de Hubel e Wiesel repetida por mais andares do que a biologia mostrou: as primeiras camadas aprendem **bordas** e manchas de cor; as seguintes, **texturas** e cantos; depois, **partes** — um olho, uma roda; e no topo, **objetos**. Ninguém programou esses níveis. Eles emergem do treino, e são notavelmente parecidos entre redes treinadas em tarefas diferentes — fato que a seção de transferência vai cobrar.

## O diagrama que é um limite de memória desenhado

Em 2012, a AlexNet ganhou o ImageNet com **15,3% de erro top-5 contra 26,2% do segundo colocado**. Não foi uma melhora incremental: foi uma faixa inteira de distância, e é a data que a maioria dos cursos trata como o começo da era moderna da visão.

Três decisões carregaram o resultado, e todas as três são de engenharia, não de teoria. A ativação **ReLU** (unidade linear retificada) no lugar da tangente hiperbólica — o artigo relata atingir 25% de erro no CIFAR-10 **seis vezes mais rápido**. O *dropout* contra sobreajuste. E o treino em **GPU** (unidade de processamento gráfico), que levou "between five and six days to train on two GTX 580 3GB GPUs".

Agora o detalhe que fecha o capítulo. Todo curso reproduz o diagrama da AlexNet em **duas colunas paralelas** e o discute como decisão de arquitetura. O artigo diz o que ele é, em duas frases: *"A single GTX 580 GPU has only 3GB of memory, which limits the maximum size of the networks that can be trained on it. (…) Therefore we spread the net across two GPUs."*

📖 **O diagrama mais reproduzido da visão computacional é um limite de 3 gigabytes desenhado.** É o caso mais literal deste livro de restrição material gerando forma nova — ao lado de Playfair inventando o gráfico de barras porque não tinha os dados de série temporal ([capítulo 22](22-visualizacao-storytelling.md)) e do cubo OLAP pré-computando agregados porque a consulta era lenta demais ([capítulo 23](23-analise-multidimensional.md)). A forma sobrevive à restrição que a gerou, e a geração seguinte a estuda como se fosse princípio.

Quatro anos depois, a **ResNet** ataca outro problema — e a formulação dele é mais instrutiva que a solução. Empilhando mais camadas, a acurácia **de treino** piorava. Treino, não teste: isso **descarta sobreajuste** como explicação, porque um modelo que sobreajusta vai bem no treino por definição. O nome disso é **degradação**, e a resposta foram as conexões residuais: 152 camadas, 3,57% de erro. É o [capítulo 26](26-treinar-redes-profundas.md) aparecendo dentro deste.

:::exercicio {"id":"10-e2","tipo":"multipla","objetivo":"O1","dificuldade":"media"}
Uma equipe empilha camadas numa rede convolucional: 20, depois 34, depois 56 camadas. O erro **no conjunto de treino** piora a cada aumento. Qual é a leitura correta?

- [ ] A rede está sobreajustando: profundidade demais para os dados disponíveis.
- [x] Não é sobreajuste — sobreajuste melhoraria o erro de treino. É um problema de otimização: a rede mais profunda não consegue nem aprender o que a rasa aprendeu.
- [ ] Faltou aumentação de dados; com mais variação artificial o erro de treino cairia.
- [ ] O campo receptivo ficou grande demais e a rede perdeu a estrutura local.

> **gabarito:** Não é sobreajuste — o erro de **treino** piorou
> **porque:** O sinal decisivo está em qual erro piorou. Um modelo que sobreajusta decora o treino: seu erro de treino **cai**, e é o de teste que sobe. Aqui os dois pioram — então o modelo nem chegou a decorar. O problema é anterior à generalização: é **otimização**.
>
> E há um argumento de construção que fecha a questão: uma rede de 56 camadas poderia, em princípio, copiar a de 20 e deixar as 36 restantes como identidade — logo, ela **nunca deveria ser pior**. Se é, o método de treino não está achando essa solução. Foi exatamente esse raciocínio que produziu as conexões residuais.
>
> Sobre as outras: **aumentação** ataca generalização, não erro de treino (se algo, dificulta o treino). E **campo receptivo grande** não é uma patologia que faz o erro de treino subir monotonicamente com a profundidade.
> **volte para:** #o-diagrama-que-e-um-limite-de-memoria-desenhado
:::

## Transferência de aprendizado: o que quase todo projeto real faz

Aqui está a parte prática, e ela contraria a imagem que se faz da área. **A maioria esmagadora dos projetos de visão em empresa não treina rede nenhuma do zero.** Pega uma rede já treinada em milhões de imagens, joga fora a última camada, põe uma cabeça nova com as suas classes e treina só ela.

Funciona por causa da hierarquia. Bordas, texturas e cantos **não são específicos do ImageNet** — são específicos de imagens. Uma borda numa chapa de raio X é a mesma borda de uma foto de cachorro. Só as camadas do topo, que montam objetos, é que são particulares da tarefa original — e são justamente as que você substitui.

O critério de **o que congelar** é curto e serve na prática:

| Situação | O que fazer |
|---|---|
| Poucos dados (centenas), domínio parecido com fotos naturais | Congele o corpo inteiro; treine só a cabeça |
| Dados moderados (milhares), domínio parecido | Cabeça primeiro; depois descongele as últimas camadas com taxa de aprendizado baixa |
| Domínio muito diferente (satélite, microscopia, radar) | Descongele mais fundo — as features de alto nível não servem, as de baixo ainda servem |
| Muitos dados (centenas de milhares) e domínio próprio | Aí sim treinar do zero pode compensar |

O erro típico é descongelar tudo com a taxa de aprendizado padrão: os gradientes grandes da cabeça recém-inicializada, ainda aleatória, destroem features boas que levaram semanas de GPU para existir. Treine a cabeça primeiro; só então libere o corpo, e devagar.

**Aumentação de dados** entra pelo mesmo motivo — poucos exemplos. Você gera variações artificiais que **preservam o rótulo**: recortes, pequenas rotações, mudanças de brilho. A regra é uma só e é sobre o seu domínio, não sobre a biblioteca: *a transformação preserva o rótulo aqui?* Espelhar horizontalmente uma foto de gato dá um gato. Espelhar um dígito manuscrito ou um caractere destrói o rótulo. Girar 180° uma célula ao microscópio é inofensivo; girar 180° uma radiografia de tórax produz uma imagem que não existe na clínica — e treinar com ela gasta capacidade em invariâncias falsas.

Uma nota de estado da arte: desde 2020 os **Vision Transformers (ViT)** disputam esse espaço, tratando a imagem como sequência de retalhos em vez de impor convolução ([capítulo 11](11-sequencias-linguagem.md)). Eles trocam a hipótese embutida por dados e escala. Para o projeto com 800 imagens, porém, a decisão prática não muda: transferir continua sendo o caminho, mude só de que modelo.

:::exercicio {"id":"10-e3","tipo":"aberta","objetivo":"O3","pontos":3,"dificuldade":"dificil"}
Uma indústria quer classificar peças metálicas em "com trinca" / "sem trinca" a partir de fotos da linha de produção. Há **800 imagens rotuladas** por um inspetor experiente — 640 sem trinca, 160 com. Novas fotos custam caro para rotular. A câmera é fixa, a peça sempre entra na mesma orientação.

Treinar do zero ou transferir? Decida, justifique e diga o que você congelaria e que aumentações usaria.

> **rubrica:** decide por transferência e sustenta a decisão com a ordem de grandeza dos dados (800 exemplos contra os milhões que o pré-treino já viu);
> justifica com a hierarquia de features — bordas e texturas são genéricas a imagens, e trinca é essencialmente um padrão de textura/borda;
> propõe congelar o corpo e treinar só a cabeça primeiro, com descongelamento parcial e taxa baixa depois, se houver folga;
> escolhe aumentações que preservam o rótulo neste domínio e justifica pelo menos uma exclusão à luz da câmera fixa e da orientação constante;
> reconhece o desbalanceamento 640/160 e propõe tratamento (peso de classe ou métrica adequada), sem se guiar por acurácia
> **porque:** Com 800 imagens, treinar do zero é estimar milhões de parâmetros a partir de quase nada — e o resultado previsível é uma rede que decora as 800. A rede pré-treinada chega sabendo bordas, texturas e cantos, que é **exatamente** o vocabulário de uma trinca. Você está treinando um classificador sobre features prontas, não uma rede.
>
> Congele o corpo, treine só a cabeça. Se sobrar dado e paciência, descongele as últimas camadas com taxa de aprendizado uma ou duas ordens de grandeza menor. Descongelar tudo de saída é o modo clássico de destruir o que se veio buscar.
>
> Nas aumentações, o enunciado é uma armadilha útil: **a câmera é fixa e a orientação é constante**. Rotações grandes e espelhamentos geram imagens que a linha nunca vai produzir — capacidade gasta em invariância que ninguém pediu. O que faz sentido é o que **de fato varia na linha**: brilho e contraste (a iluminação oscila), pequenas translações e rotações de poucos graus (a peça assenta um pouco torta), ruído leve. Aumentação boa é modelagem da variação real do processo, não uma lista de transformações copiada de um tutorial.
>
> Por fim, 640/160 é 80/20: um modelo que responde "sem trinca" sempre acerta 80%. Acurácia aqui não mede nada — vale revocação da classe rara, e o [capítulo 04](04-avaliacao.md) trata do resto.
> **volte para:** #transferencia-de-aprendizado-o-que-quase-todo-projeto-real-faz
:::

## Síntese — o que levar

- Rede densa sobre imagem falha duas vezes: **parâmetros demais** e **estrutura espacial jogada fora**. Para ela, a imagem é uma lista.
- A convolução impõe três coisas de uma vez: **conectividade local**, **compartilhamento de pesos** e **invariância a translação**.
- **A ideia exportável:** a primitiva certa não é a mais elementar. Hubel e Wiesel procuravam o ponto e o córtex respondia a bordas — achar a unidade mínima da **representação**, não a do sinal, é o trabalho de projeto.
- Compartilhar pesos é o que resolve a fome de dados: o número de parâmetros **não depende do tamanho da imagem**, e cada exemplo atualiza os mesmos pesos milhares de vezes.
- **Restringir o modelo é a fonte do desempenho**, não o preço dele.
- A **hierarquia** (bordas → texturas → partes → objetos) emerge do treino e é genérica — é ela que torna a transferência possível.
- **Degradação ≠ sobreajuste.** Se o erro de **treino** piora com a profundidade, o problema é otimização.
- O diagrama de duas colunas da AlexNet é **um limite de 3 GB desenhado**. Restrição material vira forma, e a forma sobrevive à restrição.
- **Transfira por padrão.** Congele o corpo, treine a cabeça, descongele devagar. Treinar do zero é a exceção, não a regra.
- **Aumentação é modelagem do domínio**, não lista de transformações: só entra o que preserva o rótulo e o que de fato varia no processo real.
- Da percepção ao problema em 53 anos; do Transformer ao BERT em cerca de um. A diferença foi **infraestrutura de reprodução compartilhada**.

## Verificação

1. Explique, sem fórmula, por que a convolução **impõe** invariância translacional em vez de aprendê-la — e diga que preço se paga por essa imposição quando a posição absoluta do objeto importa para a tarefa.
2. Uma colega afirma: "com poucos dados, uso menos parâmetros; por isso a convolução ajuda". A frase está certa pelo motivo errado. Corrija-a, explicando o que o compartilhamento de pesos faz com a **evidência por parâmetro**.
3. Escolha um problema de imagem do seu contexto. Diga o que você congelaria numa rede pré-treinada e por quê, e liste três aumentações que você **descartaria** — justificando cada descarte pelo domínio, não pela biblioteca.

---

# 11 — Sequências e Linguagem

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Explicar por que dados sequenciais quebram a premissa de independência.
- **O2.** Descrever a limitação de memória das redes recorrentes.
- **O3.** Explicar o mecanismo de atenção como consulta ponderada por relevância.
- **O4.** Justificar por que a arquitetura Transformer substituiu a recorrência na prática.

## O problema: a ordem é informação — e a memória se dissolve

"O cachorro mordeu o homem" e "o homem mordeu o cachorro" têm exatamente os mesmos atributos. Contadas as palavras, as duas frases são idênticas. Significam coisas opostas.

Isso quebra a premissa que sustentava todos os modelos até aqui: a de que cada exemplo é uma linha independente numa tabela, e que a ordem das colunas não carrega informação. Em texto, áudio e série temporal, **a ordem é o dado**. O exemplo não é a palavra: é a palavra *no lugar onde ela está*, condicionada a tudo que veio antes.

O segundo problema aparece assim que você tenta resolver o primeiro. Suponha uma rede que lê a frase palavra por palavra e vai atualizando um resumo interno do que já leu. Agora dê a ela esta frase: *"A conta que a auditoria contratada pelo conselho no ano passado revisou está **errada**."* Para concordar "conta" com "errada", a rede precisa lembrar de uma palavra vista onze posições atrás. Ela não lembra. E o motivo não é falta de capacidade — é o diagnóstico do [capítulo 26](26-treinar-redes-profundas.md), o gradiente que morre ao atravessar muitas camadas, aparecendo aqui numa dimensão diferente.

**É o mesmo problema, na dimensão tempo.** Cada passo da sequência é uma camada a mais no caminho de volta do erro.

## De onde isto veio

**O aperto.** Uma rede recorrente precisa lembrar de algo visto muitos passos atrás, e o gradiente morre no caminho até lá. O erro é multiplicado por um fator a cada passo que retrocede; multiplicações repetidas produzem uma exponencial, e exponencial só faz duas coisas — explode ou some. Some, na maioria das vezes.

**O que se fazia antes.** Janela fixa: olhar as *n* palavras anteriores e mais nada (os n-gramas), ou uma rede recorrente que, na prática, só enxergava o passado recente. Nos dois casos a memória tinha um teto, e o teto era baixo.

**A virada.** Se o erro morre por ser **multiplicado** a cada passo, então construa um caminho por onde ele **não seja multiplicado**. É isso que a *Long Short-Term Memory* (LSTM) faz, apresentada em 1997: um canal de refluxo constante do erro, guarnecido por **comportas** que decidem o que escrever, o que apagar e o que ler. As comportas são a parte visível; o canal é a parte que resolve.

**A ideia reaproveitável.** *A solução veio do formato da falha, não da tarefa.* Ninguém desenhou a LSTM pensando em linguagem — desenhou-se **contra uma exponencial**. O nome da tarefa é acidente; o formato do defeito é o que orienta a arquitetura. E há prova documental do que se estava perseguindo: o capítulo 4 da tese de Sepp Hochreiter, de **1991**, já se chamava *"Konstanter Fehlerrückfluß"* — refluxo **constante** do erro. **Seis anos** entre nomear o problema e conseguir comportá-lo. Se você guardar uma frase deste capítulo, guarde esta: **um defeito bem nomeado é meio método**.

**O nome.** *Long Short-Term Memory* é memória de **curto prazo que dura muito** — não uma terceira espécie de memória. O oximoro é o argumento inteiro: a rede continua tendo apenas memória de trabalho; o que mudou é quanto tempo ela sobrevive.

**O segundo aperto: traduzir.** Em 2014, Sutskever, Vinyals e Le publicam o *sequence to sequence* (seq2seq): uma rede **codificadora** lê a frase de origem inteira e a comprime num vetor; uma rede **decodificadora** lê esse vetor e produz a frase de destino. Funciona — e os próprios autores apontam, como uma das contribuições técnicas principais do trabalho, um truque que hoje soa constrangedor: **inverter a ordem das palavras da frase de origem**. Invertida, a primeira palavra da entrada fica perto da primeira palavra da saída, e o gradiente tem menos passos a atravessar.

É restrição virando forma, como em tantos outros capítulos — só que desta vez a forma é **gambiarra confessa**. E gambiarra confessa é um sintoma valioso: quando o truque que mais ajuda é encurtar a distância, a distância é o problema.

**A virada, segunda parte.** Ainda em 2014, Bahdanau, Cho e Bengio nomeiam esse problema com todas as letras — e este é o detalhe mais bonito da história: **o resumo do artigo não contém a palavra "attention"**. O diagnóstico declarado é que *"the use of a **fixed-length vector** is a bottleneck"*, e a proposta é deixar o modelo *"(soft-)search for parts of a source sentence that are relevant"*. No artigo, o modelo se chama **RNNsearch** e o vocabulário é o de **alinhamento**, não o de atenção. O nome que pegou teria vindo de Bengio, em revisão — atribuição corrente, não confirmada.

**A terceira virada, e o que ela de fato removeu.** Em 2017, Vaswani e colegas propõem uma arquitetura *"based solely on attention mechanisms, **dispensing with recurrence and convolutions entirely**"*. O motivo declarado é operacional, não representacional: ser *"more parallelizable and requiring significantly less time to train"* — com 41,8 BLEU obtidos em *"3.5 days on eight GPUs"*.

📖 **A leitura que fecha.** O que "Attention Is All You Need" eliminou foi a **recorrência** — não a convolução, e muito menos a atenção. A atenção já existia desde 2014, mas como **acessório de uma rede recorrente**; 2017 **remove o hospedeiro** e mantém o acessório. E o ganho anunciado não é de expressividade: é de **paralelismo**. A recorrência obriga a processar um passo por vez, porque o passo *t* depende do resultado do passo *t−1*; a GPU quer todos os passos ao mesmo tempo. É restrição material gerando forma nova outra vez — a mesma mecânica da AlexNet no [capítulo 10](10-visao.md) e do Playfair no [capítulo 22](22-visualizacao-storytelling.md).

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ | O gradiente que some ao longo dos passos é o mesmo diagnóstico do [capítulo 26](26-treinar-redes-profundas.md), aplicado à dimensão tempo |
| ✓ | O capítulo 4 da tese de Hochreiter (**1991**) intitula-se *"Konstanter Fehlerrückfluß"* — o problema estava nomeado seis anos antes da LSTM |
| ✓ᵃ | Bahdanau, Cho & Bengio, *Neural Machine Translation by Jointly Learning to Align and Translate*, [arXiv:1409.0473](https://arxiv.org/abs/1409.0473), 01/09/2014 — o resumo **não contém** a palavra "attention"; fala em *fixed-length vector* como gargalo, em *(soft-)search* e no modelo **RNNsearch** |
| ✓ᵃ | Vaswani et al., *Attention Is All You Need*, [arXiv:1706.03762](https://arxiv.org/abs/1706.03762), 12/06/2017 — *"dispensing with recurrence and convolutions entirely"*, *"more parallelizable"*, 41,8 BLEU em *"3.5 days on eight GPUs"* |
| ⏳ | A LSTM (1997) como resposta direta ao refluxo constante do erro; a janela fixa (n-gramas) e a RNN de memória curta como o que se fazia antes; o oximoro do nome |
| ⏳ | Seq2seq (Sutskever, Vinyals & Le, NIPS 2014): a inversão da ordem das palavras da origem apontada pelos autores como contribuição técnica principal |
| ⏳ | A atribuição do nome "attention" a Bengio — relato de terceiros, não confirmado em primária |
| 📖 | *A solução veio do formato da falha, não da tarefa* — e o corolário: um defeito bem nomeado é meio método |
| 📖 | A leitura de que 2017 removeu a **recorrência**, não a atenção, e de que o ganho é de paralelismo, não de representação |

> **Legenda adicional:** **✓ᵃ** = o **resumo** do artigo foi lido literalmente e sustenta a citação; o corpo do artigo não foi lido nesta edição. É mais forte que ✓ᵐ (só metadados) e mais fraco que ✓ (fonte lida).

## Fundamentos: a recorrência, o estado oculto e o gradiente que some no tempo

Uma **rede neural recorrente** (*Recurrent Neural Network*, RNN) tem uma ideia só: processe um elemento por vez e carregue um **estado oculto** — um vetor que funciona como resumo do que já foi lido. A cada passo, a rede recebe *o elemento atual* e *o estado anterior*, e produz *um novo estado*. Os pesos são os mesmos em todos os passos: é uma função aplicada repetidamente, não uma rede por posição.

O estado oculto é a memória, e é aí que está tanto a virtude quanto o defeito. A virtude: a rede aceita sequências de qualquer comprimento sem mudar de tamanho. O defeito: **tudo o que ela sabe do passado tem de caber naquele vetor**, e cada passo novo sobrescreve um pouco do que havia.

Para treinar, o erro precisa voltar por todos os passos até a informação que causou o problema. Cada passo aplica um fator; retroceder *k* passos multiplica *k* fatores. Fatores menores que 1 encolhem exponencialmente — em vinte passos, o sinal já é ruído numérico. Na prática, isso significa que a rede **aprende as dependências curtas e nunca chega a aprender as longas**: não é que ela erre a concordância distante, é que ela nunca recebe sinal suficiente para tentar.

### Comportas: o que a LSTM e a GRU acrescentam

A LSTM parte de um estado que atravessa os passos **sendo somado, não multiplicado** — é o caminho por onde o erro reflui sem encolher. Em volta dele há três decisões, todas aprendidas e todas contínuas (não são chaves liga-desliga, são torneiras):

- **Esquecer** — quanto do estado antigo mantenho?
- **Escrever** — quanto do que acabei de ver entra no estado?
- **Ler** — quanto do estado eu exponho como saída deste passo?

A **GRU** (*Gated Recurrent Unit*) é a mesma ideia com menos peças: funde esquecer e escrever numa comporta só e dispensa a separação entre estado interno e saída. Menos parâmetros, treino mais rápido, comportamento parecido na maioria das tarefas. A escolha entre as duas quase nunca é o que decide um projeto — o que decide é se você precisa de recorrência.

:::exercicio {"id":"11-e1","tipo":"multipla","objetivo":"O2","dificuldade":"media"}
Uma RNN simples é treinada para classificar avaliações de produto e vai bem em textos curtos, mas erra sistematicamente quando a negação aparece no começo de um parágrafo longo ("Não recomendo… *[80 palavras]* …o acabamento é bonito"). Qual é o diagnóstico correto?

- [ ] A rede tem poucos parâmetros; basta aumentar o tamanho do estado oculto.
- [x] O gradiente encolhe exponencialmente ao retroceder muitos passos, então a rede nunca recebe sinal para aprender a dependência longa.
- [ ] A rede está em *overfitting* nos textos curtos e precisa de mais regularização.
- [ ] Textos longos violam a premissa de independência; textos curtos não.

> **gabarito:** O gradiente encolhe exponencialmente com a distância em passos
> **porque:** Retroceder *k* passos multiplica *k* fatores. Com fatores abaixo de 1, o produto tende a zero rápido — e um gradiente que chega em zero não é um gradiente pequeno, é ausência de instrução. A rede **não aprende** aquela dependência; não é que a aprenda mal.
>
> Sobre as erradas: **aumentar o estado oculto** dá mais espaço de memória, mas o problema não é espaço, é o caminho do erro até lá — mais capacidade sem caminho não vira aprendizado. **Regularização** ataca variância, e aqui o modelo não está decorando os curtos: está cego para os longos. E a **premissa de independência** é violada em *qualquer* comprimento — ela é o que define o problema sequencial, não um efeito do tamanho do texto.
>
> A correção histórica foi arquitetural: um caminho em que o estado é somado em vez de multiplicado (LSTM/GRU) e, depois, o acesso direto de qualquer posição a qualquer posição (atenção).
> **volte para:** #fundamentos-a-recorrencia-o-estado-oculto-e-o-gradiente-que-some-no-tempo
:::

## Do gargalo à atenção: seq2seq e o vetor de tamanho fixo

O seq2seq colocou o problema num formato limpo: **codificador** lê a entrada e produz um vetor; **decodificador** lê o vetor e produz a saída. Isso permitiu, pela primeira vez, mapear uma sequência de tamanho *n* numa sequência de tamanho *m* sem alinhamento manual.

E expôs um gargalo com nome próprio. Frase de 5 palavras e frase de 50 palavras produzem **o mesmo vetor de tamanho fixo**. Traduzir passa a ser um exercício de compressão com taxa infinita: tudo o que a origem diz precisa caber num vetor que não cresce. Quanto mais longa a frase, pior a tradução — e o remédio dos autores (inverter a origem) trata a distância, não a compressão.

A **atenção** troca a compressão por **acesso**. Em vez de exigir um resumo único, o codificador guarda **um vetor por posição da entrada** e, a cada palavra que vai gerar, o decodificador pergunta: *de quais posições da origem eu preciso agora?* A resposta é um conjunto de pesos que somam 1 — quase toda a massa em duas ou três posições, quase nada no resto — e a entrada usada naquele passo é a **média ponderada** por esses pesos.

Três palavras descrevem o mecanismo, e valem para tudo o que vem depois: a **consulta** (o que estou procurando agora), as **chaves** (o que cada posição oferece) e os **valores** (o que cada posição entrega quando é escolhida). Compare consulta com todas as chaves, transforme as semelhanças em pesos, some os valores ponderados. É uma busca **suave**: nada é escolhido, tudo é misturado em proporção à relevância — e é justamente por ser suave que ela é derivável, e portanto treinável junto com o resto.

Repare no que foi ganho de graça: o caminho entre a posição 1 da entrada e a posição 50 da saída deixou de ter 50 passos. Tem **um**.

## O Transformer: remover o hospedeiro

Se a atenção já dá acesso direto a qualquer posição, para que serve a recorrência? A resposta de 2017 foi: para nada — e ela custa caro.

A **autoatenção** (*self-attention*) aplica o mesmo mecanismo dentro de uma única sequência: cada posição consulta todas as outras posições da mesma frase, inclusive a si mesma. É assim que "errada" encontra "conta" onze palavras atrás sem atravessar onze passos.

Três peças completam a arquitetura:

- **Cabeças múltiplas** (*multi-head*). Vários mecanismos de atenção em paralelo, cada um com sua própria projeção de consultas, chaves e valores. Uma média ponderada só produz **uma** mistura; várias cabeças permitem que uma posição atenda simultaneamente a relações diferentes — concordância numa cabeça, referência do pronome noutra — sem que uma apague a outra.
- **Codificação posicional**. Aqui está a conta a pagar: sem recorrência, **nada no modelo sabe a ordem**. A autoatenção enxerga um conjunto, não uma sequência — troque as palavras de lugar e ela devolve os mesmos resultados, permutados. Como a ordem *é* o problema do capítulo, a posição precisa ser reinjetada explicitamente, somada à representação de cada elemento. A recorrência codificava a ordem de graça, no próprio formato; o Transformer paga por ela.
- **Paralelismo**. A recorrência é sequencial por definição: o passo *t* espera o *t−1*. A autoatenção calcula todas as comparações de uma vez, como uma multiplicação de matrizes — exatamente a operação em que a GPU é boa. Não é que o Transformer aprenda o que a LSTM não aprendia: é que ele **cabe no hardware**, e por isso pôde ser treinado em dados e tamanhos que a recorrência nunca alcançaria. É a mesma lição do [capítulo 10](10-visao.md): a restrição material escolhe a arquitetura vencedora.

**E o preço.** Se cada posição compara-se com todas, o número de comparações cresce com o **quadrado** do comprimento da sequência. Dobrar o texto quadruplica o custo da atenção. Esse é o limite estrutural que organiza boa parte da pesquisa desde então — e a razão de "janela de contexto" ser uma métrica comercial no [capítulo 12](12-modelos-de-fundacao.md), e não um detalhe técnico.

:::exercicio {"id":"11-e2","tipo":"numerica","objetivo":"O4","dificuldade":"facil"}
Numa camada de autoatenção, cada posição da sequência é comparada com todas as posições. Se o comprimento da sequência passa de **512** para **4096** elementos, por qual fator o número de comparações da atenção é multiplicado?

Responda com um número inteiro.

> **gabarito:** 64 ± 0
> **porque:** O número de comparações é o comprimento ao quadrado. A sequência ficou 8 vezes maior (4096 ÷ 512 = 8), e 8² = **64**. Não é o custo que fica 8 vezes maior — é 64.
>
> É por isso que "aumentamos a janela de contexto de 8 mil para 128 mil" nunca é uma mudança barata: o fator de comprimento é 16, e o de comparações, 256. Também é por isso que o comprimento máximo aparece como característica de produto, com preço. A atenção comprou **caminho curto** (uma posição alcança qualquer outra em um passo) e pagou em **custo quadrático** — a recorrência fazia o negócio inverso: custo linear no comprimento, caminho longo demais para o gradiente sobreviver.
> **volte para:** #o-transformer-remover-o-hospedeiro
:::

## Tokenização: o texto vira número antes de qualquer coisa

Nada disso opera sobre letras. Antes de qualquer arquitetura, o texto é cortado em **tokens** — pedaços do tamanho de uma palavra curta, um prefixo, um sufixo — e cada token vira um índice, que vira um vetor (o *embedding* do [capítulo 03](03-representacao.md), onde a hipótese distribucional de Harris, de 1954, já dizia que o significado de uma palavra está na companhia que ela mantém).

A escolha do corte é uma decisão de representação com consequências que ninguém revisita depois. Cortar em palavras inteiras produz vocabulário gigante e nenhuma resposta para a palavra nunca vista. Cortar em caracteres resolve isso e alonga a sequência — e comprimento, na seção anterior, tem preço quadrático. Os esquemas de **subpalavra** ficam no meio: palavras comuns viram um token só, palavras raras se decompõem em pedaços conhecidos.

Duas consequências práticas que voltam para morder: idiomas mal representados no vocabulário gastam **mais tokens para dizer a mesma coisa** — e, como se cobra por token e o custo cresce com o comprimento, a mesma frase sai mais cara em português que em inglês. E tarefas que dependem de olhar dentro da palavra (contar letras, rimar, soletrar) são difíceis não por falta de inteligência do modelo, mas porque **a letra não é uma unidade que ele enxerga**.

:::exercicio {"id":"11-e3","tipo":"aberta","objetivo":"O3","pontos":3,"dificuldade":"dificil"}
Um colega diz: *"Atenção é só uma forma de dar mais memória ao modelo — no fundo é uma LSTM melhorzinha."* Explique por que essa leitura está errada, usando (a) o que a atenção substitui, (b) o que ela custa e (c) o que o artigo de 2017 de fato removeu.

> **rubrica:** identifica que a atenção substitui **compressão** (um vetor de tamanho fixo resumindo tudo) por **acesso ponderado** a todas as posições preservadas;
> descreve o mecanismo como consulta × chaves → pesos que somam 1 → média ponderada dos valores, isto é, busca suave e derivável;
> aponta que o caminho entre duas posições distantes passa de muitos passos para um, o que é uma mudança de topologia do gradiente, não de tamanho de memória;
> reconhece o custo: comparações quadráticas no comprimento, contra custo linear da recorrência;
> afirma corretamente que 2017 removeu a **recorrência** (o hospedeiro), mantendo a atenção que já existia desde 2014, e que o motivo declarado foi paralelismo/tempo de treino
> **porque:** A resposta fraca trata memória e atenção como quantidades da mesma grandeza — "mais memória" — e conclui que a diferença é de grau. A diferença é de **espécie**. A LSTM mantém um resumo e decide o que preservar dele a cada passo: é compressão com política de descarte. A atenção **não resume**: guarda todas as posições e escolhe, a cada consulta, quanto de cada uma usar. Uma esquece por construção; a outra nunca esqueceu nada e paga por isso.
>
> A prova de que não é uma LSTM melhorzinha está na cronologia: entre 2014 e 2017 a atenção **conviveu** com a recorrência, como acessório. Se fosse a mesma coisa em versão melhor, não haveria por que somar as duas. O que 2017 fez foi retirar a parte antiga — e o argumento apresentado foi operacional, não representacional: *"more parallelizable and requiring significantly less time to train"*.
>
> Uma resposta excelente nota o que o negócio custou: caminho curto de gradiente em troca de custo quadrático no comprimento, mais a necessidade de reinjetar a ordem via codificação posicional, porque sem recorrência a arquitetura enxerga um conjunto e não uma sequência.
> **volte para:** #do-gargalo-a-atencao-seq2seq-e-o-vetor-de-tamanho-fixo
:::

## Síntese — o que levar

- **A ordem é informação.** O exemplo não é o elemento: é o elemento *na posição em que está*. Isso quebra a premissa de independência que sustentava os capítulos anteriores.
- A RNN carrega um **estado oculto** — memória de tamanho fixo que é sobrescrita a cada passo.
- O gradiente que some no tempo é o **mesmo diagnóstico** do [capítulo 26](26-treinar-redes-profundas.md): cada passo é uma camada a mais no caminho de volta do erro.
- **A ideia exportável:** *a solução veio do formato da falha, não da tarefa*. A LSTM foi desenhada contra uma exponencial, não contra a linguagem. Um defeito bem nomeado é meio método — e o nome ("refluxo constante do erro") veio **seis anos** antes da arquitetura.
- **LSTM e GRU** somam um caminho por onde o erro reflui sem encolher, com comportas contínuas para esquecer, escrever e ler. Aliviam o teto de memória; não o eliminam.
- **Seq2seq** transformou tradução em codificar → decodificar, e revelou o gargalo do **vetor de tamanho fixo**. O truque de inverter a frase de origem é gambiarra confessa — e sintoma de que o problema era distância.
- **Atenção = acesso, não compressão.** Consulta, chaves e valores; pesos que somam 1; média ponderada. O caminho entre duas posições distantes passa a ter **um** passo.
- **O Transformer removeu a recorrência, não a atenção.** A atenção existia desde 2014 como acessório de uma RNN; 2017 tirou o hospedeiro. O motivo declarado foi **paralelismo** — a mesma restrição material que decidiu a visão computacional no [capítulo 10](10-visao.md).
- **Sem recorrência, ninguém sabe a ordem**: por isso a codificação posicional existe. A recorrência codificava ordem de graça; aqui se paga por ela.
- O preço da atenção é **quadrático no comprimento**. Dobrar o texto quadruplica o custo — e é daí que vem o preço da janela de contexto no [capítulo 12](12-modelos-de-fundacao.md).
- **Tokenização é uma decisão de representação**, não um detalhe de pré-processamento: define o vocabulário, o comprimento da sequência, o custo por frase e o que o modelo simplesmente não consegue enxergar.

## Verificação

1. Explique, com um exemplo do seu próprio domínio (não de texto), por que tratar os registros como independentes destrói informação — e o que exatamente se perde ao embaralhar a ordem.
2. Descreva a limitação de memória de uma RNN e diga por que ela **não** se resolve aumentando o tamanho do estado oculto. Em seguida, explique o que a atenção muda nesse quadro: o que ela substitui e o que ela cobra.
3. Um colega propõe voltar a usar uma LSTM num projeto novo "porque consome menos". Que argumentos a favor e contra você apresenta, e qual característica do problema decidiria a escolha?

---

# 12 — Modelos de Fundação

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).
>
> ⏳ **Cláusula de expiração — leia antes de continuar.** Este é o capítulo que envelhece mais rápido do livro. O estado da arte aqui foi **capturado em 2026-08**; nomes de modelos, tamanhos, preços e recordes de *benchmark* mudam em meses, e por isso **este capítulo não cita nenhum**. Confira a data do cabeçalho antes de confiar em qualquer número que encontrar — inclusive nos que estão aqui. O que se pretende durável são as **distinções estruturais**: pré-treino contra adaptação, conhecimento nos pesos contra conhecimento recuperável.

## Objetivos de aprendizagem

- **O1.** Distinguir pré-treino, fine-tuning e uso via prompt quanto a custo e a dado necessário.
- **O2.** Usar embeddings para busca semântica e medir a melhora sobre a busca por termos.
- **O3.** Explicar RAG como decisão de arquitetura, e não como técnica de prompt.
- **O4.** Escolher entre fine-tuning e recuperação a partir da natureza do problema.

## O problema: cada tarefa de linguagem recomeçava do zero

Em 2018 havia uma assimetria constrangedora entre duas áreas vizinhas.

Em **visão computacional**, ninguém treinava do zero havia anos. Pegava-se uma rede já treinada num corpus grande de imagens e adaptava-se ao problema de casa. Em **processamento de linguagem**, não: **cada tarefa recomeçava do zero**. Classificar sentimento, extrair entidades, responder pergunta — cada uma exigia sua própria arquitetura, seu próprio corpus rotulado, seu próprio treino do início.

O gargalo não era a arquitetura nem a máquina. Era o **rótulo**. Rotular texto custa hora de gente, e a mesma empresa que tinha milhões de documentos tinha oitocentos exemplos rotulados — quando tinha.

## De onde isto veio

**O aperto.** Visão reaproveitava tudo; linguagem não reaproveitava quase nada. ✓ᵃ

**O que se fazia antes.** Reaproveitava-se **a camada de entrada**. Embeddings estáticos — um vetor fixo por palavra, aprendido em corpus grande — entravam como *feature*, e **todo o resto** era treinado por tarefa. Era transferência de vocabulário, não de modelo. ⏳

**A virada.** Transferir **o modelo inteiro**, não só a camada de entrada. Pré-treinar em texto cru, sem rótulo, e depois ajustar o mesmo modelo à tarefa. ✓ᵃ

**A ideia reaproveitável.** *Quando o dado rotulado é o gargalo, mude o que se reaproveita — não o algoritmo.* O salto de 2018 não veio de um otimizador melhor nem de uma camada nova: veio de trocar a **unidade de reuso**, da palavra para o modelo. Vale fora daqui: diante de escassez de rótulo, a primeira pergunta útil não é "que modelo uso?", é "o que já foi aprendido que eu posso não reaprender?". 📖

**Duas peças concretas.** **ULMFiT** (Howard & Ruder, [arXiv:1801.06146](https://arxiv.org/abs/1801.06146), 18/01/2018) mostra o tamanho do ganho: **com 100 exemplos rotulados, iguala o desempenho de treinar do zero com 10 000**. ✓ᵃ E **BERT** (2018) traz o objetivo de máscara — esconder palavras e pedir que o modelo as recupere. Esse objetivo é a **tarefa Cloze**, criada por Wilson Taylor em **1953** como medida de legibilidade de texto jornalístico. ⏳ Uma régua de redação virou função de perda **65 anos depois** — mais um caso do padrão que este livro persegue: o intervalo entre a ideia e o procedimento.

**As leis de escala.** Kaplan e colegas ([arXiv:2001.08361](https://arxiv.org/abs/2001.08361), 23/01/2020) mostram que a perda cai como **lei de potência** em tamanho de modelo, dado e computação, *"spanning more than seven orders of magnitude"* — e que **largura e profundidade têm efeito mínimo**. ✓ᵃ

> **A leitura deste livro (📖).** Isto é o **oposto** do [capítulo 10](10-visao.md). Lá, trinta anos de progresso vieram de arquitetura: convolução, *pooling*, conexão residual. A lei de escala diz que, passado certo ponto, **arquitetura é detalhe**. Duas verdades em capítulos vizinhos, e a segunda não apaga a primeira: ela vale **num regime** — o regime em que há computação e corpus para gastar. Fora dele, arquitetura continua decidindo.

### O nome, e a crítica que veio junto

O termo *foundation model* nasce de um relatório de **114 autores** do Stanford CRFM (Bommasani et al., [arXiv:2108.07258](https://arxiv.org/abs/2108.07258), 16/08/2021). ✓ᵃ Os autores explicam a escolha: chamam-nos assim *"to underscore their critically central yet **incomplete** character"* — centrais, e ainda assim incompletos. E o próprio resumo já traz a autocrítica: o paradigma *"incentivizes **homogenization**"*, e os defeitos do modelo-base *"are inherited by all adapted models downstream"*.

A objeção mais citada ao termo é atribuída a **Meredith Whittaker**: renomearam algo que já tinha nome — são modelos de linguagem grandes, e "fundação" embute uma promessa de solidez que o objeto não sustenta. **⏳ — a atribuição circula na imprensa especializada; não foi conferida em fala primária.**

> **A leitura deste livro (📖).** É a lição do caso OLAP, no [capítulo 23](23-analise-multidimensional.md): **quem batiza uma categoria decide o que ela herda de história e de crítica**. A diferença — e ela é a favor deste caso — é que aqui os autores **declararam a limitação no próprio resumo**, o oposto do relatório patrocinado de 1993.

**O intervalo, e por que ele é a contra-prova do livro.** Transformer em **2017**; BERT e GPT em **2018**. Cerca de **um ano**. Compare com 53 anos no [capítulo 10](10-visao.md), 59 no [capítulo 03](03-representacao.md), cerca de 80 no [capítulo 13](13-reforco.md). O [capítulo 07](07-arvores-ensembles.md) já apontava a primeira condição para o intervalo encurtar: **a precisão da pergunta**. Este caso acrescenta a segunda: **infraestrutura de reprodução compartilhada** — arXiv, código aberto, GPU comprável, benchmark comum. Com as duas presentes, o intervalo cai de décadas para meses. 📖

**Procedência das afirmações desta seção** (`✓ᵃ` = página do artigo aberta e **resumo lido**; o corpo, não):

| Selo | Afirmação |
|---|---|
| ✓ᵃ | O aperto de 2018: visão já não treinava do zero, linguagem recomeçava a cada tarefa; a virada é transferir o modelo inteiro |
| ✓ᵃ | ULMFiT (Howard & Ruder, arXiv:1801.06146, 18/01/2018): 100 exemplos rotulados igualam treino do zero com 10 000 |
| ✓ᵃ | Kaplan et al. (arXiv:2001.08361, 23/01/2020): perda em lei de potência, *"spanning more than seven orders of magnitude"*; largura e profundidade com efeito mínimo |
| ✓ᵃ | Lewis et al. (arXiv:2005.11401, 22/05/2020): *"their ability to access and precisely manipulate knowledge is still limited"*; separação entre memória paramétrica e não-paramétrica |
| ✓ᵃ | Bommasani et al. (arXiv:2108.07258, 16/08/2021, 114 autores): *"critically central yet incomplete"*, *"incentivizes homogenization"*, defeitos *"inherited by all adapted models downstream"* |
| ✓ᵐ | BERT (2018) e o objetivo de máscara |
| ⏳ | A origem do objetivo de máscara na tarefa Cloze de Wilson Taylor (1953) |
| ⏳ | Embeddings estáticos como prática dominante de transferência antes de 2018 |
| ⏳ | A objeção de Meredith Whittaker ao termo *foundation model* — imprensa especializada, sem fala primária conferida |
| 📖 | A leitura de que as leis de escala contradizem o capítulo 10 **dentro de um regime**, sem anulá-lo |
| 📖 | A leitura de que quem batiza a categoria decide o que ela herda — paralelo com o caso OLAP do capítulo 23 |
| 📖 | A leitura do intervalo de ~1 ano como contra-prova: precisão da pergunta **mais** infraestrutura de reprodução compartilhada |

## Fundamentos: pré-treino auto-supervisionado e a palavra que muda de sentido

**Auto-supervisionado** é a palavra que resolve o gargalo do rótulo, e ela é mais simples do que parece: o rótulo é **extraído do próprio dado**. Esconda uma palavra e peça a palavra de volta; corte a frase e peça a continuação. Ninguém anotou nada, e ainda assim existe resposta certa para comparar. É supervisão sem anotador — e é isso que permite treinar em corpus da ordem da internet, onde rotular à mão seria impensável.

O que sai desse treino é uma **representação contextual**. A diferença em relação ao embedding estático do [capítulo 03](03-representacao.md) é direta: no estático, *manga* tem **um** vetor, média confusa da fruta e da peça de roupa. No contextual, o vetor de *manga* é calculado **na frase em que a palavra aparece** — e "a manga estava madura" e "a manga da camisa rasgou" produzem vetores distantes. A mesma palavra deixa de ter um significado só.

Isso muda o que a busca semântica consegue fazer. Busca por termos acha documentos que **repetem a palavra**; busca por embedding acha documentos que **falam da mesma coisa** com outras palavras — e é o ganho que o [capítulo 04](04-avaliacao.md) exige que você **meça**, não presuma, contra a linha de base por termos.

:::exercicio {"id":"12-e1","tipo":"multipla","objetivo":"O2","dificuldade":"media"}
Uma equipe indexou 30 mil chamados de suporte com **embeddings estáticos** (um vetor fixo por palavra, somados por documento) para fazer busca semântica. A busca por "**manga quebrada na esteira**" devolve receitas de suco de fruta. Qual é o diagnóstico mais preciso?

- [ ] O índice é pequeno demais: com 30 mil documentos não há sinal suficiente para busca vetorial.
- [x] O embedding estático dá **um único vetor por palavra**, misturando os sentidos; sem contexto, "manga" carrega fruta e peça de roupa ao mesmo tempo.
- [ ] A busca vetorial não serve para termos técnicos — o caso pede busca por palavra-chave.
- [ ] Falta normalizar os vetores antes de calcular a similaridade do cosseno.

> **gabarito:** O embedding estático colapsa os sentidos da palavra num vetor só
> **porque:** O vetor estático é aprendido **antes** de existir a frase: ele é a média de todos os contextos em que a palavra apareceu no corpus de treino. Se o corpus tinha mais fruta que vestuário, "manga" fica perto de fruta e leva o documento inteiro junto. A representação contextual resolve isso por construção — o vetor é calculado **com a frase**, e as duas mangas ficam longe uma da outra.
>
> Sobre as erradas: **tamanho do índice** não é o problema — a mesma consulta erraria com 30 milhões de documentos, porque o erro está na representação, não na quantidade. **Voltar para palavra-chave** troca um problema por outro: a busca por termos não erraria a manga, mas perderia o chamado que diz "correia partida" sem usar nenhuma das suas palavras. E **normalizar** muda a escala da similaridade, não o sentido colapsado dentro do vetor.
> **volte para:** #fundamentos-pre-treino-auto-supervisionado-e-a-palavra-que-muda-de-sentido
:::

## Adaptar: as três portas, e o que cada uma custa

Com o modelo pré-treinado na mão, há três formas de chegar à sua tarefa — e elas diferem sobretudo em **dado necessário** e **custo**.

**Fine-tuning completo.** Continua o treino, ajustando **todos** os pesos com os seus exemplos. É o mais poderoso e o mais caro: exige máquina, exige tempo e produz uma cópia inteira do modelo para cada tarefa. É onde o número do ULMFiT importa — com transferência, a ordem de grandeza de rótulos necessários cai drasticamente.

**Adaptação eficiente.** Em vez de mexer em tudo, congela-se o modelo e treina-se um punhado pequeno de parâmetros novos — **adaptadores**, e a família **LoRA** (*Low-Rank Adaptation*) é a mais difundida. Mesmo efeito prático na maioria dos casos, com uma fração do custo e um artefato pequeno por tarefa, em vez de um modelo inteiro. Fica registrado o nome; o detalhe é assunto de outro ciclo.

**Prompting e in-context learning.** Nenhum peso muda. A tarefa é **descrita** no texto de entrada, às vezes com alguns exemplos ali mesmo, e o modelo responde. Custo de treino zero, latência e custo por chamada não-zero, e nenhuma garantia de estabilidade: a mesma instrução reescrita produz resultado diferente. É a porta certa para começar — e a errada para prometer consistência sem medir.

A regra de bolso é a ordem inversa do custo: **tente prompt, depois adaptação eficiente, e só então fine-tuning completo** — e a cada degrau exija a evidência de que o anterior não bastava.

:::exercicio {"id":"12-e2","tipo":"numerica","objetivo":"O1","dificuldade":"facil"}
No artigo do ULMFiT (2018), o modelo transferido atinge, **com 100 exemplos rotulados**, o mesmo desempenho de um modelo treinado do zero com **10 000** exemplos.

Por qual fator a quantidade de rótulos necessária foi dividida? Responda com um número inteiro.

> **gabarito:** 100 ± 0
> **porque:** 10 000 ÷ 100 = **100**. Duas ordens de grandeza.
>
> O que interessa não é a divisão, é o que ela reorganiza no seu projeto. Rótulo é o insumo caro: ele custa hora de especialista, não hora de máquina. Um fator de 100 significa que a diferença entre "inviável" e "uma semana de anotação" pode ser apenas **escolher transferir em vez de treinar do zero**. É por isso que a primeira pergunta de um projeto com pouco dado rotulado não é qual algoritmo usar — é o que já foi aprendido que você pode não reaprender.
>
> Cuidado com o exagero simétrico: o fator vale para as tarefas e o corpus daquele artigo, não é uma constante da natureza. Meça o seu.
> **volte para:** #adaptar-as-tres-portas-e-o-que-cada-uma-custa
:::

## Conhecimento nos pesos e conhecimento recuperável

O modelo guarda fatos nos pesos. O artigo de RAG (Lewis et al., [arXiv:2005.11401](https://arxiv.org/abs/2005.11401), 22/05/2020) diagnostica o limite disso com precisão: *"their ability to access and precisely manipulate knowledge is still limited"*. ✓ᵃ A proposta separa duas memórias — a **paramétrica**, que está nos pesos, e a **não-paramétrica**, que está num índice consultável na hora da pergunta.

> **A leitura deste livro (📖).** É a LSTM repetida 23 anos depois. No [capítulo 11](11-sequencias-linguagem.md), a memória embutida na rede recorrente não dava conta e a solução foi construir um **canal explícito** para a informação atravessar. Aqui é o mesmo movimento, uma escala acima: **quando a memória embutida falha, construa um canal externo.**

É por isso que **RAG é decisão de arquitetura, não técnica de prompt**. Adotar RAG significa passar a manter um índice, uma política de atualização, um recuperador que pode errar e uma etapa a mais na latência. Nada disso cabe num campo de texto.

**Quando usar recuperação em vez de fine-tuning.** Três sinais, e qualquer um deles já basta: o conhecimento **muda** — política de preços que troca toda semana, catálogo, jurisprudência; a resposta precisa **citar a fonte**, porque alguém vai auditar; ou o volume de conhecimento é grande e o custo de retreinar a cada mudança é proibitivo. Fine-tuning ensina **comportamento** — formato, tom, um jeito de responder. Recuperação fornece **fato**. Confundir os dois é o erro mais caro deste capítulo: quem faz fine-tuning para "ensinar a política nova" paga o treino e ainda fica com a política de ontem congelada nos pesos.

**Alucinação, e por que ela não é um defeito de fabricação.** O modelo foi treinado para **continuar texto de forma plausível** — não para dizer a verdade. Uma citação inventada com autor, ano e página é, do ponto de vista do objetivo de treino, um sucesso: é exatamente o texto que viria a seguir. Recuperação ataca o problema pela raiz certa, ao trocar "lembre-se do fato" por "leia este trecho e responda a partir dele", mas **não o elimina**: se o recuperador trouxer o documento errado, o modelo responderá com convicção idêntica.

:::exercicio {"id":"12-e3","tipo":"aberta","objetivo":"O4","pontos":3,"dificuldade":"dificil"}
Uma operadora de saúde quer um assistente interno que responda dúvidas sobre **cobertura de procedimentos**. As regras mudam **toda semana** por decisão de comitê, existem cerca de 4 mil páginas de normas vigentes, e **toda resposta precisa apontar a norma que a sustenta**, porque a auditoria confere por amostragem.

A liderança técnica propôs "fazer fine-tuning do modelo nas normas". Julgue a proposta e diga o que você faria — incluindo o que mediria para saber se funcionou.

> **rubrica:** identifica que o conhecimento muda toda semana, o que torna qualquer conhecimento congelado nos pesos obsoleto entre treinos;
> reconhece a exigência de citar a fonte como incompatível com conhecimento paramétrico, que não devolve procedência;
> recomenda recuperação (RAG) como arquitetura principal, e não como ajuste de prompt;
> separa os dois papéis — recuperação fornece fato, fine-tuning (ou prompt) ajusta formato e tom da resposta;
> propõe medir as duas etapas separadamente: qualidade do recuperador (o trecho certo apareceu entre os recuperados?) e qualidade da resposta (ela é sustentada pelo trecho citado?);
> menciona ao menos um modo de falha residual — recuperador traz documento errado, norma revogada ainda no índice, resposta convicta sobre trecho inadequado
> **porque:** A proposta erra na natureza do problema, não no tamanho. Fine-tuning **congela** o que ensinou: no dia seguinte ao treino a norma muda e o modelo continua confiante na versão antiga — e agora o erro está espalhado pelos pesos, onde não se corrige com um `UPDATE`. Com regra semanal, o ciclo de retreino nunca alcança o ciclo do comitê.
>
> O segundo requisito é ainda mais decisivo e costuma passar despercebido: **auditoria exige procedência**. Conhecimento nos pesos não devolve fonte — ele devolve texto plausível, e uma norma inventada com número e artigo é exatamente o tipo de saída que o objetivo de treino premia. Recuperação devolve **o trecho**, e a citação deixa de ser promessa e passa a ser um ponteiro verificável.
>
> A resposta forte separa os papéis: **recuperação para o fato, adaptação (ou simplesmente prompt) para o formato**. E ela mede as duas metades separadamente — porque um sistema que responde mal pode estar recuperando o trecho errado ou raciocinando mal sobre o trecho certo, e essas duas falhas se consertam em lugares opostos. Sem essa separação, a equipe vai passar meses ajustando prompt para consertar um problema de índice.
>
> Modo de falha que quase ninguém escreve na proposta e todo mundo encontra em produção: **a norma revogada continua no índice**. O recuperador a traz, o modelo a cita, a auditoria acha. A política de expurgo do índice é parte do sistema, não tarefa de manutenção.
> **volte para:** #conhecimento-nos-pesos-e-conhecimento-recuperavel
:::

## Limites: custo, viés herdado e a dificuldade de avaliar

**Custo.** Pré-treinar é um projeto de infraestrutura, não de equipe de dados — e é por isso que a esmagadora maioria dos usuários consome modelos de terceiros. Isso tem consequência: a homogeneização que o próprio relatório de Stanford aponta significa que **o mesmo punhado de modelos-base sustenta milhares de aplicações**, e um defeito lá aparece em todas — *"inherited by all adapted models downstream"*.

**Viés herdado do corpus.** O modelo aprendeu a continuar o texto que existe, com as associações que existem nele. Nenhuma etapa do pré-treino filtra isso, e o fine-tuning por cima raramente remove — costuma apenas encobrir na superfície testada. O tratamento sério é assunto do [capítulo 14](14-interpretabilidade-justica.md).

**Avaliar é o problema aberto.** Aqui não há matriz de confusão esperando: a saída é texto livre, muitas respostas diferentes são aceitáveis, e o "gabarito" muitas vezes é um julgamento. O [capítulo 04](04-avaliacao.md) continua valendo, e sua exigência central vale mais ainda: **defina a linha de base e meça contra ela**. Rubrica escrita antes de olhar as respostas, conjunto de casos fixo, e desconfiança explícita quando o avaliador é outro modelo — o júri automático herda os mesmos vieses do julgado, e concorda consigo mesmo com facilidade suspeita.

## Síntese — o que levar

- Em 2018 o gargalo de linguagem era **rótulo**, não arquitetura: cada tarefa recomeçava do zero.
- **A ideia exportável:** quando o dado rotulado é o gargalo, mude **o que se reaproveita**, não o algoritmo. A unidade de reuso passou da palavra para o modelo.
- **Auto-supervisionado** = o rótulo sai do próprio dado. É o que destrava treinar em corpus sem anotador.
- Embedding **contextual** dá vetores diferentes à mesma palavra em frases diferentes; o estático dá um só, e é aí que a busca semântica quebra.
- As **leis de escala** dizem que, passado certo ponto, arquitetura é detalhe — o oposto do [capítulo 10](10-visao.md). As duas verdades convivem, cada uma no seu regime.
- Três portas, em ordem crescente de custo: **prompt → adaptação eficiente (LoRA) → fine-tuning completo**. Suba um degrau só com evidência de que o anterior não bastou.
- **Fine-tuning ensina comportamento; recuperação fornece fato.** Confundir isso é o erro caro deste capítulo.
- **RAG é decisão de arquitetura**: traz índice, política de atualização e um recuperador que também erra.
- **Alucinação não é bug**: o modelo foi treinado para continuar texto plausível, não para dizer a verdade.
- O nome *foundation model* foi escolhido para marcar o caráter **central e incompleto** — e a crítica veio no próprio resumo que cunhou o termo.
- **Um ano** entre Transformer e BERT/GPT. Pergunta precisa **mais** infraestrutura de reprodução compartilhada encurtam o intervalo de décadas para meses.

## Verificação

1. Explique a diferença entre pré-treino, fine-tuning e uso via prompt em termos de **quem paga o quê**: quanto dado rotulado, quanto tempo de máquina e quanto custo por uso cada um exige. Dê um caso do seu trabalho para cada um.
2. Descreva um sistema de busca que você usa hoje e diga como mediria se trocar busca por termos por busca com embeddings melhorou alguma coisa — qual é a linha de base, qual é o conjunto de consultas e qual número decide.
3. Um colega diz que "RAG é só colocar os documentos no prompt". Aponte três compromissos de arquitetura que essa frase esconde, e diga qual deles costuma aparecer primeiro em produção.

---

# 08 — Aprendizado Não Supervisionado

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Explicar por que avaliar agrupamento é qualitativamente mais difícil que avaliar classificação.
- **O2.** Aplicar k-means e reconhecer as premissas geométricas que ele impõe.
- **O3.** Usar PCA para redução de dimensionalidade e dizer o que se perde.
- **O4.** Escolher o número de grupos com um critério declarado, e não pelo gráfico que ficou bonito.

## O problema: não há erro a minimizar

Todos os capítulos anteriores tinham um gabarito: havia um alvo, havia um erro, e o erro dizia se você estava melhorando. Aqui não há nada disso. Sem rótulo, **não existe erro a minimizar** — existe um critério a *inventar*. Você decide o que significa "grupo bom", e só então há o que otimizar. A escolha não vem dos dados: vem de você.

A consequência é desconfortável. Quase sempre é possível encontrar grupos: rode k-means com k=4 em ruído puro e ele devolve quatro grupos, com fronteiras nítidas e centros bem definidos. O algoritmo nunca diz "não há estrutura aqui". A pergunta honesta, portanto, nunca é *"existem grupos?"* — é **"estes grupos significam alguma coisa fora deste conjunto de dados?"**. O erro que este capítulo previne é o mais barato de cometer em toda a análise de dados: **olhar para os grupos, achar que fazem sentido, e apresentar isso como descoberta.**

## De onde isto veio

**O aperto.** O detalhe que reorganiza tudo: os problemas originais **não eram "clustering"**. Eram quatro apertos em quatro campos que não conversavam entre si — **amostragem estratificada** (como dividir uma população em estratos para amostrar melhor), **momento de inércia de um sólido** (como partir um corpo heterogêneo), **compressão de voz** (como representar um sinal com poucos níveis) e **taxonomia biológica** (como classificar organismos). O mesmo procedimento foi inventado quatro vezes porque quatro pessoas tinham problemas diferentes com a mesma forma matemática.

**O que se fazia antes.** Classificar por julgamento do especialista. Na biologia, isso tinha nome: a classificação valia pela **autoridade do taxonomista** que a assinava.

**A virada.** Fixar um critério explícito de homogeneidade e **alternar duas minimizações parciais** — cada uma trivial quando a outra está congelada. Dados os centros, atribuir cada ponto ao mais próximo é imediato; dadas as atribuições, recalcular o melhor centro é uma média. O problema conjunto é duro; os dois parciais são fáceis.

**A ideia reaproveitável.** **Quando o problema conjunto é intratável, congele metade e resolva a outra — depois inverta.** Bock mostra que o k-means é um caso de *otimização alternada*, e essa mesma forma reaparece em EM, fuzzy c-means e k-medoids. **Não é um algoritmo, é um padrão** — e você vai reconhecê-lo em qualquer lugar onde duas incógnitas se determinam mutuamente.

**O nome.** "k-means" foi cunhado por **MacQueen (1967)** — para um algoritmo **diferente** do que hoje leva o nome: o sequencial de passagem única, não o *batch* que todo mundo roda.

### Seis pretendentes, e quem levou o nome

| Ano | Quem | O que fez |
|---|---|---|
| 1950/51 | **Dalenius** | A primeira formulação do problema, em amostragem estratificada — anterior a todos os que se costuma citar |
| 1956 | **Steinhaus** | Primeiro a propor o k-means multidimensional (versão contínua), por motivação **mecânica**: partir um sólido heterogêneo minimizando momentos de inércia. Publicado em francês |
| 1957 | **Lloyd** | Critério contínuo em **uma** dimensão, quantização de voz nos Bell Labs. Publicado só em **1982** — 25 anos depois |
| 1962 | **Sebestyen** | Já propusera o mesmo procedimento que MacQueen apresentaria cinco anos depois |
| 1965 | **Forgy** | Primeiro a propor o k-means discreto. Bock registra que **o resumo da palestra não menciona explicitamente o algoritmo**: o conteúdo é conhecido apenas por descrição de terceiros |
| 1967 | **MacQueen** | Cunha o nome — para outro algoritmo |

**A leitura deste livro.** Os capítulos [05](05-modelos-lineares.md) (Gauss × Legendre) e [18](18-neuronio-artificial.md) (Linnainmaa × Rumelhart) contam a mesma história com **dois** pretendentes. Aqui há **seis**, em quatro campos isolados, e o nome vencedor foi cunhado para um algoritmo diferente. Os três casos, juntos, fecham a tríade e dizem o que nenhum diz sozinho: **não vence quem descobre, nem quem publica primeiro, nem sequer quem descreve o método que virou padrão. Vence quem escreve a palavra que pega.**

**Do lado hierárquico**, o aperto era político-científico. **Sokal & Sneath**, em *Principles of Numerical Taxonomy* (1963), motivaram a pesquisa mundial em clustering ao tirar a classificação das mãos da autoridade e torná-la **reproduzível a partir de caracteres medidos**. O objetivo não era achar grupos: era acabar com a discussão sobre quem tinha o direito de defini-los. **Do lado da redução de dimensionalidade**, dois problemas diferentes, 32 anos, a mesma decomposição: **Pearson (1901)** chegou por geometria — a reta ou o plano de melhor ajuste a uma nuvem de pontos; **Hotelling (1933)** chegou por álgebra, com motivação psicométrica, e é dele o nome "componentes principais".

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ | Toda a cadeia do k-means — Dalenius, Steinhaus, Lloyd, Forgy, Sebestyen, MacQueen, o nome cunhado para outro algoritmo, o resumo de Forgy sem o algoritmo, e a leitura de k-means como otimização alternada — de Bock, *"Origins and extensions of the k-means algorithm"* (JEHPS, 2008), **lido por inteiro** |
| ✓ | Sokal & Sneath, *Principles of Numerical Taxonomy* (1963), como motivador da pesquisa mundial em clustering |
| ✓ᵐ | A publicação tardia de Lloyd (1957 → 1982) |
| ✓ᵐ | Pearson (1901) e Hotelling (1933) como as duas formulações de componentes principais, e o nome vindo de Hotelling |
| ⏳ | Que antes disso se classificava por julgamento do especialista, com a autoridade do taxonomista valendo como critério |
| 📖 | A tríade com os capítulos 05 e 18, e a leitura de que vence quem escreve a palavra que pega |

## Fundamentos: inventar o critério, depois alternar

O k-means declara o critério antes de tudo: **a soma das distâncias quadradas de cada ponto ao centro do seu grupo** (a *inércia*). Grupo bom = grupo compacto. Escolhido isso, o algoritmo é a alternância descrita acima — sorteie k centros, atribua, recalcule, repita até parar de mudar. Três consequências que ninguém avisa:

**Ele sempre converge, e quase nunca para o ótimo.** A inércia cai a cada passo, então o algoritmo para — num mínimo **local**, que depende do sorteio inicial. Rodar de novo com outra semente pode dar outra resposta; por isso as bibliotecas rodam várias inicializações e ficam com a melhor. Duas partições diferentes do mesmo dado não são bug: são a natureza do método.

**Ele só enxerga grupos esféricos e de tamanho parecido.** Isso está no *critério*, não no código. Minimizar distância quadrada ao centro premia bolas compactas; um grupo alongado será cortado ao meio, e um grupo grande será dividido para "pagar" a fusão de dois pequenos. Nenhum valor de k conserta isso.

**Distância depende de escala.** Uma coluna em reais e outra em anos não são comparáveis: quem tem números maiores domina a distância e decide os grupos sozinha. **Normalizar não é higiene, é parte da definição do critério** — ver [capítulo 03](03-representacao.md).

### Quando você não quer fixar k: o dendrograma

O agrupamento hierárquico inverte a pergunta. Em vez de escolher k antes, ele constrói **toda** a hierarquia: começa com cada ponto sozinho e funde os dois grupos mais próximos, até sobrar um. O resultado é o **dendrograma** — uma árvore em que a altura de cada fusão é a distância em que ela ocorreu. Você decide o k **depois**, cortando a árvore na altura que quiser, e vê a estrutura em todas as escalas ao mesmo tempo.

O preço: a fusão é irreversível (um erro no início se propaga até o fim) e o custo cresce rápido com o número de pontos. E há uma escolha escondida que muda tudo — o que significa "distância entre dois **grupos**": o par mais próximo, o mais distante, a média. Trocar essa definição troca a árvore.

### PCA: variância como critério, e o que se perde

A análise de componentes principais (PCA) resolve o problema de Pearson: achar as direções em que os dados mais variam e reescrevê-los nelas, em ordem. Ficar com as primeiras é reduzir a dimensionalidade — menos colunas, quase a mesma dispersão.

O que se perde tem três nomes. **Variância**, e você sabe quanto: é o número que a biblioteca informa. **Interpretabilidade** — cada componente é uma mistura de todas as variáveis originais, e "0,4 × renda − 0,3 × idade + …" não é um conceito que se leve a uma reunião. E o mais traiçoeiro: **variância não é o mesmo que informação útil**. A direção que mais varia pode ser justamente a que menos separa o que importa; PCA não sabe qual é o seu problema, porque ninguém contou a ele. PCA é uma decisão de **representação**, e vale para ela tudo o que o [capítulo 03](03-representacao.md) diz — inclusive a sensibilidade à escala.

:::exercicio {"id":"08-e1","tipo":"multipla","objetivo":"O2","dificuldade":"media"}
Seus dados têm dois grupos visíveis: um alongado, em forma de arco, com 800 pontos, e outro pequeno e denso, com 60 pontos. Você roda k-means com k=2 e o resultado corta o arco ao meio, juntando uma das metades ao grupo pequeno. Qual é o diagnóstico correto?

- [ ] O algoritmo convergiu para um mínimo local; basta rodar com mais inicializações.
- [ ] O k está errado; com k=3 ou k=4 o arco é recuperado corretamente.
- [x] A limitação está no critério: minimizar distância ao centro premia grupos esféricos e de tamanho parecido, então nenhuma inicialização ou k conserta a partição.
- [ ] Os dados precisam ser normalizados antes; a escala é a causa do corte.

> **gabarito:** A limitação está no critério, não na execução
> **porque:** A inércia — soma das distâncias quadradas ao centro — é minimizada por **bolas compactas**. Um arco tem pontos longe do próprio centro, então cortá-lo ao meio de fato **reduz** a inércia: o algoritmo não falhou, ele acertou o alvo errado.
>
> As três alternativas erradas confundem execução com critério. Mais inicializações encontram mínimos locais melhores **do mesmo critério** — e o critério é o problema. Mais grupos fatiam o arco em pedaços mais esféricos, o que pode "funcionar" visualmente, mas aí você deixou de recuperar a estrutura e passou a aproximá-la por pedaços. E normalizar corrige distorção de **unidades**; aqui as unidades podem estar perfeitas e o resultado ser o mesmo, porque o problema é a **forma**. A saída real é trocar de critério — densidade, ou hierárquico com a ligação adequada — e não afinar o k-means.
> **volte para:** #fundamentos-inventar-o-criterio-depois-alternar
:::

## Regras de associação — e a lenda que quebrou

Regras de associação nasceram de um aperto comercial concreto: o que os itens de uma cesta de compras dizem uns sobre os outros (**Agrawal, Imieliński & Swami**, SIGMOD 1993; o algoritmo **Apriori** vem no ano seguinte, com Agrawal & Srikant, VLDB 1994). Uma regra `{A} → {B}` tem três números, e o terceiro é o que importa:

- **suporte** — em que fração das cestas A e B aparecem juntos. Mede se a regra é frequente o bastante para ligar.
- **confiança** — entre as cestas que têm A, em quantas aparece B. Parece a métrica principal. Não é.
- **lift** — a confiança **dividida** pela frequência de B em geral. Responde a pergunta certa: *ter A muda a chance de ter B?* Lift 1 significa **nenhuma relação**.

A armadilha é confiança alta com lift 1. Se 60% de todas as cestas têm pão, uma regra `{leite} → {pão}` com 60% de confiança parece forte e não descobriu nada: pão está em 60% das cestas *de qualquer maneira*. Confiança alta mede a **popularidade de B**, não a relação entre os dois. É a versão de mercearia da linha de base do [capítulo 04](04-avaliacao.md).

### Cerveja e fraldas: verdadeira até a descoberta, inventada a partir da ação

Todo curso conta esta história. Vale separar o que se sustenta do que não se sustenta — a fratura está num ponto exato. **O estudo existe.** Junho de 1992, **Thomas Blischok** (NCR/Teradata) para a **Osco Drug**: cerca de 1,2 milhão de cestas, cerca de 25 lojas (⏳). **A correlação foi achada**: cerveja e fraldas juntas entre 17h e 19h (⏳).

**A parte que todo mundo ensina é falsa.** "Puseram a cerveja ao lado das fraldas e as vendas subiram" — isto não aconteceu. Power, que entrevistou o autor do estudo, afirma que a Osco **não** explorou a relação movendo produtos, e Blischok confirma que **nunca fizeram nada com ela** (❌). Um participante ainda registra que o líder da equipe, ao falar com prospects, **não distinguia entre as afinidades testadas e as hipóteses** (⏳). A lenda nasceu no discurso de vendas, e isso está documentado.

Não conserte a lenda: **olhe para a fratura**. Ela é o exemplo mais barato de três coisas que o mercado trata como uma só — **correlação achada ≠ decisão tomada ≠ efeito medido**. O estudo produziu a primeira; a segunda nunca ocorreu; a terceira, portanto, não existe — e é justamente ela que todo mundo repete como resultado. É o mesmo padrão do [capítulo 23](23-analise-multidimensional.md), onde a categoria "OLAP" também foi fabricada pelo marketing: a técnica era boa, a embalagem é que não se sustenta.

| Selo | Afirmação |
|---|---|
| ✓ᵐ | A existência e a autoria da apuração de Power, *"Ask Dan!"*, [DSSResources (2002)](https://dssresources.com/newsletters/66.php) — página localizada e identificada. **A entrevista não foi lida por inteiro**, e por isso nada dela aparece aqui entre aspas |
| ⏳ | Data, empresas, volume de cestas e a janela das 17h–19h, conforme relatados nessa entrevista |
| ⏳ | Que o rearranjo de gôndola **não aconteceu** — a negativa é sustentada pela apuração de Power, mas **por fonte secundária**. `❌` seria dizer que não achamos fonte; aqui há fonte, e ela nega. A distinção importa: **não é o mesmo desconhecer e ter apurado que não** |
| ✓ᵐ | Agrawal, Imieliński & Swami (SIGMOD 1993) e Apriori (Agrawal & Srikant, VLDB 1994) |

:::exercicio {"id":"08-e2","tipo":"numerica","objetivo":"O1","dificuldade":"media"}
De **1 000** cestas de um supermercado: **600** contêm pão, **500** contêm leite e **300** contêm os dois.

Calcule o **lift** da regra `{leite} → {pão}`. Responda com duas casas decimais.

> **gabarito:** 1.00 ± 0.01
> **porque:** A confiança é `300 / 500 = 0,60` — parece uma regra forte. Mas o suporte de pão sozinho é `600 / 1000 = 0,60`, e o lift é `0,60 / 0,60 = 1,00`: **exatamente nenhuma relação**.
>
> É a armadilha inteira num número. Saber que alguém levou leite **não muda em nada** a chance de ter levado pão: uma regra com confiança alta e lift 1 é uma descoberta sobre o item mais vendido da loja, disfarçada de descoberta sobre a relação entre dois itens. Guarde a leitura: lift > 1 é associação positiva, lift < 1 é associação **negativa** (um item afasta o outro — às vezes o achado mais útil), lift ≈ 1 é independência. E note que é o mesmo problema da seção anterior em outra roupa: sem gabarito, a métrica que parece óbvia é a errada, e vale a que se compara com uma **linha de base**.
> **volte para:** #regras-de-associacao-e-a-lenda-que-quebrou
:::

## Validar sem gabarito

Aqui está a dificuldade que separa este capítulo de todos os anteriores. Na classificação, a validação é externa: existe uma resposta certa que você não usou para treinar. No agrupamento, os candidatos a métrica são **internos** — calculados sobre os mesmos dados, com a mesma noção de distância que produziu os grupos. Eles medem se a partição é coerente com o critério, não se ela é **verdadeira**. Duas ferramentas, e o que cada uma não faz:

**Silhueta.** Para cada ponto, compara a distância média aos vizinhos do próprio grupo com a distância média ao grupo mais próximo. Perto de 1, bem alocado; perto de 0, na fronteira; negativo, provavelmente no grupo errado. É útil e tem um limite duro: premia a mesma geometria compacta que o k-means persegue. Silhueta alta com clusters esféricos não é confirmação independente — é o critério se elogiando.

**Método do cotovelo.** Plote a inércia contra k e procure onde a curva "dobra". Funciona quando a dobra é óbvia; na maioria dos dados reais ela não é, e "o cotovelo é aqui" vira leitura pessoal do gráfico — que muda de analista para analista e, pior, muda depois de você já ter uma hipótese.

**E o alerta principal:** *"os clusters fazem sentido"* é a forma mais fácil de se enganar em análise de dados. Você reconhece histórias em grupos aleatórios com uma facilidade constrangedora — dê nomes a quatro grupos de ruído e o quarto vira "os clientes de alto potencial ainda não ativados". O antídoto é declarar o critério **antes** e testá-lo fora: os grupos se mantêm numa amostra separada? Eles predizem alguma variável que **não** entrou no agrupamento (churn, receita futura, retorno de campanha)? Um critério externo vale mais que cotovelo e silhueta somados, porque é o único que pode dar errado.

:::exercicio {"id":"08-e3","tipo":"aberta","objetivo":"O4","pontos":3,"dificuldade":"media"}
Uma analista segmenta 40 mil clientes com k-means. Ela testou k de 2 a 10, escolheu **k=5** porque "foi onde os grupos ficaram mais interpretáveis", nomeou os cinco segmentos, e a diretoria aprovou uma campanha diferente para cada um.

Escreva a crítica que você faria e o que proporia em seguida.

> **rubrica:** identifica que "mais interpretável" é um critério posterior e subjetivo, escolhido depois de ver o resultado;
> menciona que o k-means sempre devolve k grupos, inclusive sem estrutura real nos dados;
> aponta ao menos uma verificação de estabilidade (reamostrar/dividir os dados, trocar a semente, comparar partições);
> propõe ao menos um critério externo — uma variável que não entrou no agrupamento e que os grupos deveriam predizer;
> não se limita a sugerir "usar silhueta" como se isso resolvesse
> **porque:** A resposta fraca troca um critério interno por outro: "use silhueta em vez de interpretabilidade". Mas silhueta mede a mesma compacidade que o k-means otimizou — ela pode confirmar uma partição de puro ruído, porque nunca foi projetada para dizer se a estrutura existe.
>
> A resposta forte percebe **duas** coisas. Primeiro, que o critério foi escolhido depois de ver o resultado — o mesmo pecado do [capítulo 25](25-do-modelo-a-decisao.md), escolher a régua depois de conhecer os números, aqui agravado porque não há gabarito para desmentir ninguém. Segundo, que ninguém fez a pergunta decisiva: **os grupos sobrevivem fora deste conjunto de dados?** Divida a base, agrupe as duas metades separadamente e veja se as partições concordam; ou verifique se os segmentos predizem algo que não entrou no modelo. E há o teste que fecha o argumento, barato e humilhante: rode o mesmo procedimento em dados **embaralhados**. Se os cinco grupos continuarem nomeáveis, o que a analista descobriu foi a própria capacidade de contar histórias.
> **volte para:** #validar-sem-gabarito
:::

## Síntese — o que levar

- Sem rótulo **não há erro a minimizar**: há um critério a inventar. Quem escolhe o critério decide o resultado, e a escolha não está nos dados.
- **O algoritmo nunca diz "não há grupos".** A pergunta é se os grupos existem fora deste conjunto de dados.
- **Congele metade, resolva a outra, inverta.** O k-means é um caso de otimização alternada — o padrão vale para EM, fuzzy c-means, k-medoids e para qualquer problema com duas incógnitas que se determinam mutuamente.
- k-means só enxerga grupos **esféricos e de tamanho parecido**, e isso está no critério, não no código. Nenhum k nem nenhuma semente conserta forma errada. E **distância depende de escala**: normalizar faz parte da definição do critério, não da faxina.
- PCA troca colunas por variância — e perde interpretabilidade e, às vezes, exatamente a direção que importava.
- Em regras de associação, **confiança alta sem lift alto é a popularidade do item disfarçada de descoberta**.
- Métricas internas (silhueta, cotovelo) medem coerência com o critério, não verdade. **Critério externo vale mais que as duas somadas**, porque é o único que pode dar errado.
- "Os clusters fazem sentido" não é evidência. Teste em dados embaralhados antes de acreditar em você mesmo.
- Da tríade 05–08–18: crédito não segue descoberta nem publicação. **Vence quem escreve a palavra que pega.**

## Verificação

1. Um colega diz que agrupamento é "classificação sem rótulo, só um pouco mais difícil". Explique por que a diferença é de natureza, e não de grau.
2. Você reduziu 200 colunas a 10 componentes principais que retêm 95% da variância, e o modelo seguinte piorou. Como isso é possível, se você "quase não perdeu informação"?
3. Sua diretoria quer saber quantos segmentos de cliente existem. Descreva o critério que você declararia **antes** de rodar qualquer algoritmo, e como você defenderia esse número se ele fosse contestado.

---

# 13 — Aprendizado por Reforço

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Formular um problema como processo de decisão de Markov.
- **O2.** Explicar o dilema exploração–explotação com um exemplo concreto.
- **O3.** Descrever a diferença entre aprender valor e aprender política.
- **O4.** Reconhecer quando reforço é a formulação certa — e quando é overkill.

## O problema: ganhou a partida — qual das 60 jogadas foi boa?

Em todos os capítulos anteriores havia gabarito. Cada exemplo trazia a resposta certa ao lado da pergunta, e o trabalho era encurtar a distância entre as duas.

Aqui não há gabarito. Há **consequência** — e ela chega **tarde** e **agregada**.

Você jogou uma partida de 60 lances e ganhou. O sinal que o mundo devolveu foi um único bit, no fim de tudo: *ganhou*. Qual dos 60 lances mereceu o crédito? O lance 7 foi brilhante e o 43 quase pôs tudo a perder, mas os dois receberam exatamente a mesma notícia no fim.

Isso tem nome: **atribuição de crédito temporal**. E o que faz dele um problema difícil, e não apenas um problema chato, é que **não existe supervisor para resolvê-lo**. Ninguém vai olhar o lance 7 e dizer "esse foi bom". Se a resposta existe, o agente terá de produzi-la sozinho.

## De onde isto veio

**O aperto.** Um sinal escasso, atrasado e coletivo, sem ninguém para desmembrá-lo. Duas tradições chegaram perto e nenhuma fechou. A **psicologia animal** descrevia o fenômeno com precisão, mas descrição não é procedimento: dizer que o animal repete o que deu certo não diz *como* calcular o que deu certo. O **controle ótimo** tinha o procedimento — mas **exigia o modelo do mundo**, isto é, saber de antemão para onde cada ação leva e quanto ela paga. Quem tem esse modelo já resolveu metade do problema; quem não tem, e é a regra fora do laboratório, ficava sem método.

**O que se fazia antes.** Esperar o fim. Jogar a partida inteira, ver o placar e distribuir crédito para trás. Funciona e é honesto — só é lentíssimo, porque nada se aprende enquanto o episódio corre, e porque episódios longos diluem qualquer sinal.

**A virada.** Aprender a partir da **discrepância entre duas previsões sucessivas** — sem esperar o resultado final e sem modelo do mundo. Se a minha previsão de agora e a minha previsão de daqui a um passo discordam, essa discordância já é informação utilizável **imediatamente**. É a **diferença temporal**.

**A ideia reaproveitável.** *Não é preciso saber a resposta certa para aprender: basta que a previsão de amanhã seja melhor informada que a de hoje.* O alvo do aprendizado passa a ser **uma versão ligeiramente menos ignorante de si mesmo**. Isso se chama *bootstrapping*, e é exatamente o que separa este capítulo de todo o resto do livro — em todos os outros, havia um gabarito externo puxando o modelo. Aqui, o puxão vem de dentro.

**A cronologia, e o maior intervalo do livro.** Edward Thorndike descreve o *trial-and-error* seletivo — tentar alternativas e escolher comparando consequências — na tese de **1898**, formulado como "lei do efeito" em **1911**. Richard Bellman publica *Dynamic Programming* em **1957**, junto com a "maldição da dimensionalidade" que limita o método. Richard Sutton formaliza os métodos de diferença temporal em **1988**. Christopher Watkins apresenta o **Q-learning** na tese de **1989**, descrevendo-o como um método incremental para programação dinâmica. Depois vem a prática: **TD-Gammon** (Tesauro, 1992) aprendendo gamão por auto-jogo puro; o **DQN** da Atari (arXiv 2013, *Nature* em 26/02/2015); o **AlphaGo** (*Nature*, janeiro de 2016).

De Thorndike (1898) a Watkins (1989) são **cerca de 80 anos** — o maior intervalo registrado neste livro. Compare: 59 anos no [capítulo 03](03-representacao.md) (Harris → word2vec), 43 anos no [capítulo 24](24-series-temporais.md) (Yule → Box-Jenkins) e apenas 7 no boosting do [capítulo 07](07-arvores-ensembles.md). O padrão é consistente e vale como diagnóstico: **o intervalo encurta quando o aperto já está escrito como pergunta formal precisa**. Thorndike tinha um fenômeno observado; o boosting tinha uma pergunta com resposta sim/não. Oitenta anos foi o preço de transformar observação em enunciado.

### A lenda do nome "dynamic programming" — a fonte é autêntica, a cronologia não fecha

Bellman conta, na própria autobiografia (*Eye of the Hurricane*, 1984, p. 159), transcrita por Stuart Dreyfus em *Operations Research* (2002) com autorização do editor, que passou **o outono de 1950** na RAND e que sua primeira tarefa foi achar um nome para processos de decisão multiestágio. Havia em Washington, escreve ele, "um cavalheiro chamado Wilson", Secretário de Defesa, com "medo e ódio patológicos da palavra **pesquisa**". A RAND trabalhava para a Força Aérea; Bellman sentiu que precisava blindar Wilson do fato de que se fazia matemática ali. Escolheu **"programming"** por planejamento e **"dynamic"** porque é impossível usar a palavra em sentido pejorativo — "era algo a que nem um congressista poderia objetar".

A história é ótima. E ela **não pode ser verdadeira como contada**, por duas datas:

1. **Charles E. Wilson só assumiu como Secretário de Defesa em 28 de janeiro de 1953.** Em 1950 o cargo era de Louis Johnson e depois George Marshall.
2. **O primeiro artigo de Bellman com o termo é de 1952** — *PNAS* 38(8), 716–719, comunicado por von Neumann em 5 de junho de 1952 —, portanto **anterior à posse de Wilson**.

Há ainda uma versão concorrente: Harold Kushner relata que Bellman lhe disse estar tentando fazer sombra ao *linear programming* de George Dantzig acrescentando "dynamic".

**Note o que este capítulo não está dizendo.** Não está dizendo que a lenda é falsa nem que Bellman foi desonesto. Está dizendo o seguinte, que é diferente: *Bellman contou esta história, nestas palavras, na própria autobiografia — e a cronologia não fecha*. A memória autobiográfica de um cientista famoso, escrita **34 anos depois**, é **fonte secundária sobre si mesmo**. Ele não estava mentindo; estava lembrando, e lembrança comprime décadas.

Este é o caso mais limpo do livro para separar duas perguntas que o leitor apressado funde numa só: **"a fonte é autêntica?"** e **"a afirmação é verdadeira?"**. São exatamente as perguntas que os selos ✓ e ⏳ codificam na tabela abaixo — e por isso as duas linhas do episódio Wilson **divergem de selo**. A divergência não é um defeito da tabela: é o conteúdo.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ | A citação de Bellman sobre Wilson, "programming", "dynamic" e o congressista — de Dreyfus, *Richard Bellman on the Birth of Dynamic Programming*, **Operations Research 50(1), 2002**, que transcreve *Eye of the Hurricane* (1984, p. 159) com autorização do editor. **Lida** |
| ✓ᵐ | Charles E. Wilson empossado Secretário de Defesa em **28/01/1953**; em 1950 o cargo era de Louis Johnson / George Marshall |
| ✓ᵐ | O primeiro artigo de Bellman com o termo: *PNAS* **38(8), 716–719 (1952)**, comunicado por von Neumann em 05/06/1952 |
| ✓ᵐ | Bellman, *Dynamic Programming* (1957) e a "maldição da dimensionalidade"; Sutton, *Learning to Predict by the Methods of Temporal Differences*, **Machine Learning 3, 9–44 (1988)**; Watkins, *Learning from Delayed Rewards*, tese, Cambridge (1989); DQN em *Nature* (26/02/2015); AlphaGo em *Nature* 529 (jan. 2016) |
| ⏳ | Thorndike, lei do efeito — tese de 1898, formulação de 1911 — como origem do *trial-and-error* seletivo |
| ⏳ | A versão concorrente de Kushner: Bellman teria acrescentado "dynamic" para fazer sombra ao *linear programming* de Dantzig |
| 📖 | A leitura de que o intervalo Thorndike→Q-learning é o maior do livro, e de que o intervalo encurta quando o aperto já está escrito como pergunta formal |
| 📖 | A leitura do episódio Wilson como o caso-modelo da distinção entre fonte autêntica e afirmação verdadeira |

## Fundamentos: o MDP, o desconto e o alvo que se move

Cinco peças, e o problema inteiro cabe nelas. O **agente** decide; o **ambiente** responde; o **estado** é o que o agente sabe no instante em que decide; a **ação** é o que ele faz; a **recompensa** é o número que volta. Quando o estado atual carrega tudo o que importa do passado — isto é, quando o futuro só depende de *onde você está*, não de *como chegou lá* — essa formulação se chama **processo de decisão de Markov (MDP)**. Formular um problema como MDP é o primeiro trabalho real, e é onde a maioria dos projetos já erra: estado mal definido não se conserta com mais treino.

Duas coisas se pode aprender. A **política** responde "o que fazer aqui?" — é um mapa de estado para ação. A **função de valor** responde "quanto vale estar aqui?" — é uma previsão de recompensa futura acumulada. Métodos de valor aprendem a previsão e agem sendo gulosos sobre ela; métodos de política ajustam o comportamento diretamente, sem passar pela previsão. As duas famílias resolvem o mesmo problema por portas opostas.

**O desconto (γ).** Recompensa futura vale menos que recompensa agora, e multiplica-se cada passo por um fator γ entre 0 e 1. Isso existe por dois motivos, um matemático e um honesto: sem desconto, a soma de recompensas de um processo sem fim não converge; e, com desconto, o agente pesa o futuro do jeito que qualquer decisor sensato pesa — com desconfiança crescente, porque previsão distante é previsão pior. γ perto de 0 produz um agente imediatista; γ perto de 1, um agente paciente e mais difícil de treinar.

:::exercicio {"id":"13-e1","tipo":"numerica","objetivo":"O1","dificuldade":"facil"}
Um agente executa três passos e recebe as recompensas **3**, **0** e **10**, nessa ordem. Com fator de desconto **γ = 0,9**, qual é o retorno descontado visto do instante inicial?

Responda com uma casa decimal.

> **gabarito:** 11,1 ± 0,05
> **porque:** O retorno é a soma das recompensas, cada uma multiplicada por γ elevado ao número de passos de espera: `3 + 0,9 × 0 + 0,81 × 10 = 3 + 0 + 8,1 = 11,1`.
>
> O que interessa aqui não é a conta, é o **8,1**. A recompensa de 10 existe e é real, mas vista de hoje ela vale 8,1 — e essa diferença de 1,9 é o preço da espera. Baixe γ para 0,5 e a mesma recompensa passa a valer 2,5: o agente deixa de perseguir o prêmio do fim e vira imediatista. γ **não é um detalhe de implementação**: é onde você declara quanta paciência o agente tem, e trocá-lo muda o comportamento ótimo, não só a velocidade do treino.
> **volte para:** #fundamentos-o-mdp-o-desconto-e-o-alvo-que-se-move
:::

### Explorar ou explotar — o dilema é o cerne, não um detalhe

O agente só conhece o valor de uma ação se a experimentar. Mas cada experimento custa: enquanto testa o desconhecido, ele deixa de colher o melhor que já conhece. Explorar demais é jogar dinheiro fora aprendendo o que não precisava; explorar de menos é ficar preso à primeira coisa razoável que funcionou.

A receita mais simples é a **ε-gulosa**: com probabilidade ε escolha uma ação ao acaso, no resto do tempo escolha a melhor conhecida — e reduza ε ao longo do treino. É rudimentar e ainda assim é o suficiente para a maioria dos casos.

Repare que **este dilema não existe em nenhum outro capítulo do livro**. No aprendizado supervisionado, os dados chegam prontos e o modelo não influencia o que verá em seguida. Aqui, **o comportamento do agente determina os dados do agente**. É por isso que o alvo se move: a distribuição de treino é uma função do que se aprendeu até agora — condição bem diferente da otimização de superfície estável do [capítulo 06](06-otimizacao.md).

### Q-learning e a atualização por diferença temporal

O **Q-learning** mantém uma estimativa `Q(estado, ação)`: quanto vale tomar aquela ação naquele estado. A cada passo, o agente compara duas previsões — a que tinha antes de agir e a que tem depois de ver a recompensa e o novo estado. A diferença entre elas é o **erro de diferença temporal**, e a estimativa se move um pouco naquela direção. Nada espera o fim do episódio.

Em uma frase, a distinção que confunde todo mundo: **on-policy** aprende sobre a política que está de fato executando (inclusive suas explorações atrapalhadas); **off-policy** — o caso do Q-learning — aprende sobre a política ótima *enquanto* se comporta de outro jeito, o que permite aprender com experiência velha ou de terceiros.

:::exercicio {"id":"13-e2","tipo":"multipla","objetivo":"O2","dificuldade":"media"}
Um sistema de recomendação foi treinado por reforço e, após duas semanas, converge para exibir sempre os mesmos 40 itens — os que renderam mais cliques no começo. O catálogo tem 12 mil itens. Qual é o diagnóstico mais provável?

- [ ] O fator de desconto γ está alto demais, tornando o agente paciente em excesso.
- [x] Explotação em excesso: o agente parou de experimentar e ficou preso ao que funcionou primeiro, sem nunca medir os outros 11 960 itens.
- [ ] A recompensa está mal calibrada e precisa ser normalizada entre 0 e 1.
- [ ] O problema é o *bootstrapping*: previsões que se alimentam de previsões sempre colapsam.

> **gabarito:** Explotação em excesso — o agente parou de explorar
> **porque:** O agente está agindo de forma **ótima segundo o que conhece** — e o que ele conhece são os itens que teve a sorte de mostrar cedo. Sobre os outros 11 960 ele não tem estimativa nenhuma, e uma estimativa que nunca é atualizada nunca vira competitiva. É o círculo vicioso característico: só se aprende o valor do que se experimenta, e só se experimenta o que já parece valioso.
>
> Sobre as erradas: **γ alto** deixa o agente mais paciente, não mais repetitivo — se algo, ele o faria buscar recompensas distantes. **Normalizar a recompensa** muda a escala dos números, não a decisão de experimentar ou não. E **bootstrapping** não colapsa por definição; é o mecanismo central que faz o Q-learning funcionar sem esperar o fim do episódio.
>
> A correção prática costuma ser simples e desconfortável: garantir um piso de exploração (ε que não vai a zero) e aceitar pagar por ele — porque o custo de explorar é visível no painel e o custo de não explorar não é.
> **volte para:** #explorar-ou-explotar-o-dilema-e-o-cerne-nao-um-detalhe
:::

## Quando a tabela não cabe: o que a rede acrescenta

O Q-learning tabular guarda um número por par (estado, ação). Isso funciona enquanto der para listar os estados. Numa tela de vídeo game de 84×84 pixels, não dá — e a tabela também tem um defeito mais profundo que o tamanho: ela **não generaliza**. Duas telas quase idênticas ocupam duas células sem relação nenhuma, e a experiência ganha numa não ajuda em nada na outra.

O **DQN** (*Deep Q-Network*) substitui a tabela por uma rede neural que recebe o estado e devolve os valores das ações. O ganho não é memória: é **generalização entre estados parecidos** — a mesma virtude que a rede tem no [capítulo 09](09-redes-neurais.md), aplicada a uma previsão de valor em vez de a um rótulo. Foi isso que fez o mesmo algoritmo, sem ajuste por jogo, aprender dezenas de jogos de Atari a partir dos pixels.

O preço é instabilidade. Quando o alvo do aprendizado é produzido pela própria rede que está sendo treinada, o treino pode divergir com facilidade — e boa parte da engenharia do DQN existe só para segurar isso.

## Por que reforço é a última ferramenta a considerar

Esta é a seção mais útil deste capítulo na vida prática, e ela vai contra o marketing.

**Reforço precisa de simulador ou de interação barata em enorme quantidade.** Os resultados célebres vêm de domínios onde se pode jogar milhões de partidas de graça. Se cada tentativa do seu agente custa um cliente irritado, uma máquina parada ou um paciente exposto, você não tem esse orçamento.

**É caro em amostras.** Ordens de grandeza mais caro que aprendizado supervisionado para a mesma tarefa, quando a tarefa admite as duas formulações.

**É instável para treinar.** Duas execuções com a mesma configuração e sementes diferentes podem terminar em lugares diferentes. Isso transforma depuração em trabalho de paciência.

**E a maioria dos problemas de empresa é supervisionado disfarçado.** O teste é direto: *as minhas decisões mudam o que eu vou observar depois?* Se não mudam, não há problema sequencial — há um problema de previsão seguido de uma regra de decisão, e o [capítulo 25](25-do-modelo-a-decisao.md) resolve isso melhor, mais barato e com muito mais controle. Bellman e Wald, aliás, são a mesma família: decidir sob incerteza com uma função que precifica.

**E existe *reward hacking*.** O agente otimiza **a recompensa que você escreveu**, não a que você pretendia. Se o número recompensa cliques, ele produzirá cliques — inclusive por caminhos que ninguém quis. Especificar recompensa é escrever um contrato com um advogado literal e incansável, e é aí que mora o modo de falha característico da formulação. Onde reforço tem funcionado fora dos jogos é justamente onde a recompensa é a parte difícil e recebeu tratamento sério — o **RLHF** dos modelos de linguagem, no [capítulo 12](12-modelos-de-fundacao.md).

:::exercicio {"id":"13-e3","tipo":"aberta","objetivo":"O4","pontos":3,"dificuldade":"dificil"}
Uma transportadora quer "usar aprendizado por reforço para otimizar a roteirização das entregas do dia". Há histórico de 4 anos de rotas executadas, com tempos reais. Não existe simulador. Cada rota mal planejada custa horas extras e atraso com o cliente.

Julgue: este problema merece reforço, ou é supervisionado (ou otimização) disfarçado? Justifique e proponha o que fazer.

> **rubrica:** aplica o teste da influência — pergunta se a decisão de hoje muda o que será observado amanhã;
> identifica a ausência de simulador e o custo alto por tentativa como impedimento prático, não como detalhe;
> reconhece que há 4 anos de dados rotulados por tempo real, o que sustenta um modelo supervisionado de previsão de tempo de percurso;
> separa as duas metades — prever tempos (supervisionado) e escolher a rota (otimização combinatória sobre as previsões);
> NÃO recomenda reforço como primeira escolha, e diz sob que condição ele voltaria à mesa (existência de simulador validado, ou interação barata)
> **porque:** A resposta fraca aceita o enunciado do cliente e discute qual algoritmo de reforço usar. A resposta forte percebe que o problema já vem **com gabarito**: quatro anos de rotas executadas com tempos reais são exemplos rotulados. Prever o tempo de um trecho é supervisionado clássico; escolher a melhor rota dadas as previsões é otimização de roteirização, um campo com décadas de solvers maduros.
>
> O critério que decide não é o tamanho do problema, é a **influência**: as entregas de hoje mudam a distribuição do trânsito de amanhã? Praticamente não. Sem influência, não há problema sequencial a resolver — há previsão mais decisão, exatamente a separação do [capítulo 25](25-do-modelo-a-decisao.md).
>
> E há o argumento material, que costuma encerrar a conversa antes do argumento teórico: **sem simulador, o agente aprende explorando na operação real**, e explorar aqui significa despachar rotas ruins de propósito para descobrir que são ruins. Alguém vai pagar essa conta em horas extras. Reforço volta à mesa no dia em que existir um simulador de trânsito validado — e então o trabalho difícil passa a ser mostrar que o simulador se parece com a rua.
> **volte para:** #por-que-reforco-e-a-ultima-ferramenta-a-considerar
:::

## Síntese — o que levar

- O sinal chega **tarde e agregado**; o problema é **atribuição de crédito temporal**, e não há supervisor para resolvê-lo.
- A virada foi aprender da **discrepância entre duas previsões sucessivas**, sem esperar o fim e sem modelo do mundo.
- **A ideia exportável:** não é preciso saber a resposta certa para aprender — basta que a previsão de amanhã seja mais informada que a de hoje. O alvo é uma versão menos ignorante de si mesmo.
- **MDP** = estado, ação, recompensa, transição. Estado mal definido não se conserta com mais treino.
- **γ** declara quanta paciência o agente tem; muda o comportamento ótimo, não só a velocidade.
- **Valor** responde "quanto vale estar aqui"; **política** responde "o que fazer aqui". Portas opostas para o mesmo problema.
- Explorar × explotar é o **cerne**, não um detalhe: aqui o comportamento do agente determina os dados do agente.
- A rede (DQN) acrescenta **generalização entre estados**, não memória — e cobra instabilidade por isso.
- **Reforço é a última ferramenta a considerar.** Sem simulador ou interação barata, quase sempre é supervisionado disfarçado.
- *Reward hacking* não é anedota: o agente otimiza a recompensa **escrita**, não a pretendida.
- **Fonte autêntica ≠ afirmação verdadeira.** O próprio Bellman é o caso-modelo.

## Verificação

1. Descreva um problema do seu trabalho como MDP: quem é o agente, o que é o estado, quais são as ações e qual é a recompensa. Em seguida, diga qual das quatro peças foi mais difícil de definir — e por quê essa dificuldade é um sinal sobre o problema, não sobre você.
2. Explique a diferença entre aprender uma função de valor e aprender uma política diretamente, e dê uma situação concreta em que você preferiria cada uma.
3. Um colega propõe reforço para ajustar preços em tempo real num *e-commerce*. Que três perguntas você faz antes de concordar — e qual resposta faria você recusar a formulação?

---

# 27 — IA Simbólica, Fuzzy e Evolutiva

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Distinguir os paradigmas simbólico, conexionista, evolutivo e estatístico.
- **O2.** Representar conhecimento em regras e explicar o encadeamento da inferência.
- **O3.** Modelar incerteza linguística com conjuntos nebulosos.
- **O4.** Aplicar um algoritmo genético a um problema de otimização e reconhecer seus limites.

## O problema: nem todo problema de IA é um problema de aprendizado

Uma equipe precisa decidir se um lote de produção segue ou para. Tem **41 lotes rotulados** de histórico, um regulador que exige justificativa por escrito para cada reprovação, e três engenheiros que fazem essa chamada há vinte anos sem errar feio.

A equipe faz o que aprendeu a fazer: treina um ensemble. Sai 0,88 de AUC na validação cruzada — em 41 exemplos, um número que não significa quase nada. Ninguém consegue explicar uma decisão individual. O regulador recusa. E os vinte anos de experiência dos três engenheiros, que era o ativo mais valioso da sala, não entrou em lugar nenhum.

O erro não foi técnico. Foi de **enquadramento**: supor que "usar IA" significa "ajustar um modelo a dados". Havia conhecimento, e ele estava na cabeça de gente; havia um predicado vago ("a peça está muito fora do padrão") esperando ser modelado; havia uma estrutura causal conhecida do processo. Três coisas que aprendizado supervisionado não usa — e que quatro tradições da IA foram construídas justamente para usar.

Este capítulo é o panorama dessas quatro tradições. Cada uma nasceu de um aperto que dado nenhum resolve: **provar um teorema sem busca cega** · **decidir com um predicado vago** — "a água está quente" não tem limiar · **otimizar uma forma física sem derivada** · **raciocinar sob incerteza sem explodir a tabela conjunta**. 📖

## De onde isto veio

São quatro linhagens, quatro apertos, quatro viradas. Vale ler as quatro mini-histórias antes de olhar para o que elas têm em comum — porque o que elas têm em comum é a lição do capítulo, e ela não aparece se você ler só uma.

**1. A simbólica — provar teorema sem busca cega.** Allen Newell, **John Clifford Shaw** e Herbert Simon, meados dos anos 1950. O terceiro nome quase sempre some das citações, e some porque Shaw era o programador; registre-o. O aperto: uma prova de lógica é uma sequência de aplicações de regras, e o número de sequências possíveis explode antes do quinto passo. **A virada** foi escrever o problema como *estado, operadores e uma heurística que poda* — buscar guiado em vez de buscar tudo. O **Logic Theorist** provou 38 dos 52 primeiros teoremas do capítulo 2 do *Principia Mathematica* e, para o teorema **2.85**, achou uma prova **mais curta** que a de Whitehead e Russell ⏳. Foi demonstrado em Dartmouth, no verão de 1956 ✓ᵐ. Conta-se que o *Journal of Symbolic Logic* teria recusado publicar um artigo coautorado por um programa ⏳ — anedota excelente e fonte fraca, exatamente o tipo de coisa que este capítulo pede para você tratar com ceticismo.

Depois vieram os sistemas especialistas de verdade: **DENDRAL** (Stanford, a partir de 1965), que inferia estrutura química a partir de espectro de massa, e **MYCIN** (Shortliffe, 1972–76), que diagnosticava infecção bacteriana **no nível de um especialista humano** e **nunca foi usado clinicamente** ⏳. O mercado de máquinas LISP evaporou em **1987** ⏳.

> **A ideia reaproveitável do colapso, e ela é dura.** O que matou aquele mercado **não foi a IA falhar** — foi o hardware genérico alcançar o especializado. Workstations comuns passaram a rodar LISP mais barato que máquinas feitas para isso. A aposta perdida foi de **arquitetura**, não de método. Toda vez que você amarra um resultado técnico a um substrato especializado, está fazendo essa mesma aposta. 📖

**2. A fuzzy — decidir com predicado vago.** Lotfi Zadeh, "Fuzzy Sets", *Information and Control* **8**, 338–353, **1965** ✓ᵐ. O aperto é de uma banalidade desconcertante: "a água está quente" é uma frase que qualquer pessoa entende e que nenhum limiar reproduz. A 49 °C está quente e a 50 °C também; não existe o grau em que a água *vira* quente. **A virada** foi abandonar a pergunta "pertence ou não pertence?" e substituí-la por "pertence **quanto**?". O nome foi uma escolha ruim, e Zadeh sabia: *fuzzy* é pejorativo em inglês, e a palavra custou uma década de recepção ⏳. A partir de **1968** começam a chegar cartas do Japão; em **1987**, o metrô de **Sendai**, linha Namboku, entra em operação com controle fuzzy de aceleração e frenagem ⏳.

**3. A evolutiva — otimizar forma física sem derivada.** Três origens independentes, três continentes, cerca de **25 anos sem que soubessem umas das outras** ⏳: os *genetic algorithms* de **Holland** em Ann Arbor (1962; livro *Adaptation in Natural and Artificial Systems*, 1975), o *evolutionary programming* de **Fogel** em San Diego (1962; livro em 1966) e as *evolution strategies* de **Bienert, Rechenberg e Schwefel** na TU Berlin (por volta de 1965). O aperto de Rechenberg é o mais concreto do capítulo: encontrar a forma de **mínimo arrasto** em túnel de vento. Não há função para derivar — há uma peça de metal e um medidor. **A virada** foi tratar variação aleatória mais seleção como um método de busca, e não como uma metáfora biológica.

**4. As bayesianas — raciocinar sob incerteza sem explodir a tabela conjunta.** Judea Pearl, "Bayesian Networks: A Model of Self-Activated Memory for Evidential Reasoning", relatório técnico **CSD-850017** da UCLA, apresentado na Cognitive Science Society em **abril de 1985** ✓ᵐ — é ali que o termo aparece. Livro em 1988; Prêmio Turing em 2011. O aperto: a distribuição conjunta de *n* variáveis binárias exige 2ⁿ − 1 números. Com 30 variáveis, mais de um bilhão. **A virada** foi perceber que quase todos esses números são redundantes, porque a maioria das variáveis é **condicionalmente independente** das demais — e que essa independência pode ser *desenhada*, como um grafo. Em 1985, falar de probabilidade dentro da IA era estar **fora do mainstream** ⏳.

**A ideia reaproveitável, e é uma só para as quatro.** **A representação escolhida decide qual busca é possível.** Nenhuma das quatro tradições inventou um otimizador melhor. Cada uma inventou uma **forma de escrever o problema** que tornou a busca tratável: estado-e-operador tornou a prova buscável; o grau de pertinência tornou o predicado vago computável; a população tornou o espaço sem gradiente percorrível; o grafo de independências tornou a inferência probabilística viável. É a lição do [capítulo 03](03-representacao.md) vista de outro ângulo — lá, a representação decide o que o modelo consegue aprender; aqui, decide o que o algoritmo consegue procurar. 📖

> ### A rejeição tem geografia
>
> Duas das quatro histórias terminam com a mesma forma. A lógica fuzzy foi hostilizada no Ocidente — em boa parte **por causa da palavra** — e adotada industrialmente no Japão. Pearl estava fora do mainstream da IA em 1985 e recebeu o Turing 22 anos depois. Ambos venceram **por fora**.
>
> **A comunidade que rejeita uma ideia raramente é a que a reabilita.** Isso não é consolo para quem tem uma ideia rejeitada; é uma instrução de busca. Se o seu método não anda, a pergunta útil talvez não seja "como convenço esta sala?", e sim "qual é a sala em que este método é obviamente útil?".
>
> **Repare no relógio: 22 anos e um oceano.** De Zadeh (1965) a Sendai (1987) foram 22 anos **e uma mudança de continente**. Compare com os 43 anos do [capítulo 24](24-series-temporais.md), os 59 do [03](03-representacao.md) e os cerca de 80 do [13](13-reforco.md). O atraso aqui é curto para o padrão do livro — o que custou tempo não foi formular a ideia nem construir a ferramenta, foi **encontrar quem quisesse ouvir**. 📖

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ⏳ | Logic Theorist: 38 dos 52 primeiros teoremas do capítulo 2 do *Principia Mathematica*, e a prova mais curta para o teorema 2.85 |
| ✓ᵐ | A demonstração do Logic Theorist em Dartmouth, verão de 1956 |
| ⏳ | A recusa atribuída ao *Journal of Symbolic Logic* a um artigo coautorado por um programa |
| ⏳ | DENDRAL em Stanford a partir de 1965; MYCIN (Shortliffe, 1972–76) no nível de especialista e nunca usado clinicamente |
| ⏳ | O colapso de 1987 do mercado de máquinas LISP diante de workstations genéricas |
| ✓ᵐ | Zadeh, *Fuzzy Sets*, **Information and Control** 8, 338–353 (1965). **Metadados conferidos; não lido** |
| ⏳ | O nome *fuzzy* como escolha ruim e a década de recepção perdida; a frase de Zadeh sobre o conselho editorial (só em fontes secundárias) |
| ⏳ | As cartas do Japão a partir de 1968 e o metrô de Sendai (linha Namboku) com controle fuzzy em operação em 1987 |
| ⏳ | As três origens independentes da computação evolutiva e os ~25 anos de desconhecimento mútuo — Holland (1962/1975), Fogel (1962/1966), Bienert–Rechenberg–Schwefel (~1965) |
| ✓ᵐ | Pearl, *Bayesian Networks…*, UCLA TR CSD-850017, Cognitive Science Society, abril de 1985; livro em 1988; Turing em 2011. **Metadados conferidos; não lido** |
| ⏳ | Probabilidade como posição fora do mainstream da IA em 1985 |
| 📖 | A ideia reaproveitável geral; a leitura do colapso de 1987 como aposta de arquitetura; "a rejeição tem geografia"; a comparação de relógios |

## Simbólica: a base de conhecimento e o motor de inferência

A arquitetura é uma separação, e é essa separação que dá o nome ao paradigma. De um lado, a **base de conhecimento**: fatos e regras do tipo *SE — ENTÃO*, escritas em linguagem que uma pessoa lê. De outro, o **motor de inferência**: um procedimento genérico, sem nenhum compromisso com o domínio, que combina as regras.

Duas direções de encadeamento:

| Direção | Como funciona | Quando serve |
|---|---|---|
| **Para a frente** (*forward chaining*) | parte dos fatos conhecidos e dispara toda regra cuja condição foi satisfeita, gerando fatos novos | monitoramento, alarme, configuração — chega um dado, o que ele implica? |
| **Para trás** (*backward chaining*) | parte de uma hipótese e procura as regras que a sustentam, perguntando pelo que falta | diagnóstico — quero saber se é isto, o que preciso medir? |

O encadeamento para trás dá de graça a coisa que o resto do livro custa caro para obter: a **explicação**. O rastro de regras que sustentou a conclusão *é* a justificativa, na mesma linguagem em que o especialista fala. Compare com o esforço do [capítulo 14](14-interpretabilidade-justica.md) para extrair explicação aproximada de um modelo que não a produz.

E aqui está o gargalo que derrubou a promessa comercial da década de 1980: **a aquisição do conhecimento**. Escrever a base exige um engenheiro de conhecimento entrevistando um especialista — e o especialista decide bem sem conseguir enunciar as regras que usa. O motor era a parte fácil. Enquanto isso, este era o paradigma dominante da IA: as tradições deste capítulo ocuparam justamente o vazio deixado pelo inverno conexionista do [capítulo 18](18-neuronio-artificial.md).

:::exercicio {"id":"27-e1","tipo":"multipla","objetivo":"O2","dificuldade":"media"}
Sua empresa quer transformar em sistema especialista o conhecimento de três engenheiros veteranos que aprovam ou reprovam lotes de produção. Onde está o gargalo real do projeto?

- [ ] Na velocidade do motor de inferência, que precisará percorrer milhares de regras a cada consulta.
- [x] Na aquisição do conhecimento: os engenheiros decidem bem sem conseguir enunciar as regras que usam.
- [ ] Na falta de exemplos rotulados suficientes para treinar a base de regras.
- [ ] Na ausência de uma linguagem formal capaz de representar regras SE — ENTÃO.

> **gabarito:** Na aquisição do conhecimento — extrair do especialista as regras que ele aplica sem verbalizar
> **porque:** O motor de inferência é **genérico e resolvido**: o mesmo procedimento serve para diagnóstico médico e para controle de caldeira, e milhares de regras não são um problema computacional relevante. A linguagem de regras também existe desde os anos 1970. O que trava é humano — a competência de um especialista é em boa parte tácita, e o trabalho de destilá-la em regras explícitas é lento, caro e precisa ser refeito quando o processo muda.
>
> A terceira alternativa captura o mal-entendido mais comum de quem chega ao assunto vindo de aprendizado de máquina: **a base de regras não é treinada, é escrita**. É exatamente por isso que este paradigma funciona com 41 lotes de histórico — ele não usa os 41 para aprender a regra, usa-os para **testar** a regra que uma pessoa escreveu.
> **volte para:** #simbolica-a-base-de-conhecimento-e-o-motor-de-inferencia
:::

## Fuzzy: o grau entre o sim e o não

Num conjunto clássico, a pertinência é 0 ou 1: o elemento está dentro ou está fora. Num **conjunto fuzzy**, a pertinência é um número **entre 0 e 1** — 46 °C pertence ao conjunto "água quente" com grau 0,8, e ao conjunto "água morna" com grau 0,3. Os graus não precisam somar 1, e essa é a primeira pista de que **isto não é probabilidade**.

A distinção vale ser dita com todas as letras, porque quase todo mundo confunde: probabilidade mede **incerteza sobre um fato nítido** (não sei se a água está acima de 50 °C, e depois de medir saberei); pertinência mede **vagueza do próprio predicado** (sei exatamente que são 46 °C, e "quente" continua sendo uma questão de grau). Medir mais elimina a incerteza; não elimina a vagueza.

Sobre isso se constrói a **variável linguística**: "temperatura" deixa de ser um número e passa a ser uma variável cujos valores são *fria*, *morna*, *quente*, *muito quente* — cada um definido por uma função de pertinência, tipicamente triangular ou trapezoidal. E daí sai o **controlador fuzzy**, em três passos: **fuzzificar** (o sensor lê 46 °C → graus de pertinência em cada termo), **avaliar as regras** (*SE a temperatura é quente E a variação é pequena, ENTÃO reduza a potência um pouco*, com todas as regras disparando parcialmente, cada uma com a força do seu grau), e **defuzzificar** (agregar as saídas parciais num único número — a potência a aplicar).

O ganho de engenharia é que as regras são escritas na linguagem do operador da máquina, não na do teórico de controle. Foi isso que a linha Namboku pôs para andar: um controle de frenagem que o técnico de manutenção consegue ler.

:::exercicio {"id":"27-e2","tipo":"numerica","objetivo":"O3","dificuldade":"media"}
O termo linguístico **"água quente"** é definido por uma função de pertinência **triangular**: pertinência **0** em 30 °C, **1** em 50 °C e **0** em 70 °C, com variação linear entre esses pontos.

Qual é o grau de pertinência de uma leitura de **44 °C** ao conjunto "água quente"? Responda com duas casas decimais.

> **gabarito:** 0,70
> **porque:** 44 °C está no ramo **ascendente** do triângulo, entre 30 °C (grau 0) e 50 °C (grau 1). A interpolação linear é `(44 − 30) / (50 − 30) = 14 / 20 = 0,70`.
>
> Dois pontos que o cálculo torna concretos. Primeiro: **não há limiar**. A 43 °C o grau seria 0,65, a 45 °C seria 0,75 — nada "vira" quente em lugar nenhum, que era exatamente o aperto de Zadeh. Segundo: esse 0,70 **não é uma probabilidade de 70%** de a água estar quente. A temperatura é conhecida com certeza; o que é parcial é a aplicação da palavra. A mesma leitura de 44 °C pode ter grau 0,45 em "morna" ao mesmo tempo, e a soma passar de 1 sem que nada esteja errado.
> **volte para:** #fuzzy-o-grau-entre-o-sim-e-o-nao
:::

## Evolutiva: buscar onde não existe gradiente

Um algoritmo genético mantém uma **população** de soluções candidatas, cada uma codificada como uma sequência. A cada geração: avalia cada candidata com uma **função de aptidão**, **seleciona** as melhores com alguma aleatoriedade, gera filhas por **cruzamento** (combinar pedaços de duas candidatas) e **mutação** (perturbar uma), e repete. Não há derivada em lugar nenhum — só avaliação, comparação e variação.

Isso delimita bem quando vale a pena. **Vale** quando o espaço de busca não tem gradiente utilizável: variáveis discretas, problemas combinatórios (roteamento, escalonamento, seleção de atributos), funções com muitos ótimos locais, ou uma função de aptidão que é uma **caixa-preta** — um simulador, um jogo, ou, como em Rechenberg, um túnel de vento com uma peça de metal dentro. **Não vale** quando existe gradiente: se você pode derivar, derive; o [capítulo 06](06-otimizacao.md) faz em minutos o que uma população levaria horas para tatear.

Os dois custos a declarar antes de começar: o algoritmo genético **não dá garantia de ótimo** e é **caro em número de avaliações** — se cada avaliação é um ensaio físico ou uma simulação de dez minutos, a conta é o projeto inteiro. E ele traz um punhado de hiperparâmetros próprios (tamanho da população, taxa de mutação, pressão de seleção) que precisam ser ajustados por fora, o que é irônico: um método de busca que exige uma busca para ser configurado.

## Bayesianas: a incerteza com estrutura

Uma **rede bayesiana** tem duas peças: um **grafo dirigido acíclico**, em que cada nó é uma variável e cada seta é uma dependência direta, e uma **tabela de probabilidade condicional** por nó, dizendo a distribuição daquela variável dados os valores de seus pais. Só isso. As independências que o grafo declara são o que dispensa os outros bilhões de números da tabela conjunta.

O que essa estrutura permite, e uma rede neural do [capítulo 09](09-redes-neurais.md) não permite:

- **Inferência em qualquer direção.** A mesma rede que calcula "dada a doença, qual a chance deste sintoma?" responde "dado o sintoma, qual a chance da doença?". Uma rede neural treinada de entrada para saída faz um caminho só; para inverter, você treina outra.
- **Raciocínio sobre intervenção.** É diferente *observar* que o barômetro caiu e *forçar* o ponteiro do barômetro com a mão. O grafo distingue as duas coisas; um modelo que só aprendeu correlação, não.
- **Funcionar com variável faltando.** Não observou três das dez variáveis? A inferência simplesmente marginaliza sobre elas. Não é imputação, é a resposta correta dado o que se sabe.
- **Explicação estrutural.** O caminho de influência no grafo é a justificativa, e ela é a mesma que o especialista do domínio desenharia num quadro branco.

O preço: alguém precisa **escrever o grafo** — e voltamos ao gargalo da aquisição de conhecimento. Estruturas podem ser aprendidas de dados, mas isso exige muito mais dado do que a situação típica em que a rede bayesiana é a escolha certa.

## Por que estas tradições ainda importam

Três razões, e nenhuma delas é nostalgia.

**Interpretabilidade por construção.** Regras, graus de pertinência e grafos causais são legíveis porque foram **escritos para ser lidos** — a explicação não é extraída depois, ela é o próprio objeto. Onde há regulador, auditoria ou responsabilidade civil, isso muda o cálculo do projeto inteiro ([capítulo 14](14-interpretabilidade-justica.md)).

**Funcionamento com pouco dado.** Um sistema de regras, um controlador fuzzy e uma rede bayesiana com estrutura desenhada por especialista funcionam com **zero** exemplos de treino — e usam o histórico disponível para o que ele de fato serve nesse regime: **testar**, não estimar. Aqueles 41 lotes do início do capítulo não davam para aprender; davam muito bem para avaliar.

**A fusão com aprendizado.** A direção mais viva hoje é **neuro-simbólica**: rede neural onde há dado e percepção, estrutura simbólica onde há regra e restrição — o modelo aprendido propõe, o componente simbólico verifica e recusa o que viola a regra. É também o padrão que ancora modelos de linguagem em ferramentas formais. 📖

:::exercicio {"id":"27-e3","tipo":"aberta","objetivo":"O1","pontos":3,"dificuldade":"dificil"}
Um hospital pede um sistema de apoio ao diagnóstico para uma doença rara. Há **60 casos confirmados** em dez anos de prontuários, um consenso clínico publicado que descreve quais fatores causam quais sintomas, e uma exigência do comitê de ética: **toda recomendação precisa vir acompanhada da justificativa clínica**.

Um colega propõe treinar uma rede neural com os 60 casos. Escreva a recomendação que você levaria à reunião, dizendo o que usar e por quê.

> **rubrica:** reconhece que 60 exemplos são insuficientes para treinar uma rede neural com qualquer confiança, e que a métrica obtida nesse regime seria ela própria pouco confiável;
> identifica que existe conhecimento estruturado disponível (o consenso clínico) que a rede neural não teria como usar;
> recomenda uma rede bayesiana com estrutura elicitada dos especialistas, ou um sistema baseado em regras, e não a rede neural;
> justifica pela explicabilidade por construção — o caminho no grafo ou o rastro de regras É a justificativa clínica exigida;
> menciona ao menos um uso legítimo dos 60 casos, como avaliar o sistema ou estimar tabelas de probabilidade condicional
> **porque:** A resposta fraca discute qual arquitetura de rede caberia em 60 exemplos. A resposta certa percebe que **a pergunta não é sobre arquitetura, é sobre onde está a informação**: ela está no consenso clínico publicado, não nos prontuários — e rede neural não tem por onde receber conhecimento que não venha em forma de exemplo.
>
> É a ideia reaproveitável do capítulo aplicada a uma decisão de projeto: **a representação escolhida decide qual busca é possível**. Escolher a rede neural é escolher procurar padrão em 60 pontos; escolher o grafo é escolher procurar a probabilidade que falta dentro de uma estrutura que já se sabe correta. E há o detalhe que fecha o caso: a exigência do comitê de ética **não é um requisito adicional a satisfazer depois**, é uma restrição sobre a representação. Numa rede bayesiana a justificativa sai de graça; numa rede neural ela seria uma aproximação construída à parte, defendida diante de gente que decide sobre a vida de pacientes.
>
> Um cuidado que a boa resposta menciona: os 60 casos não são inúteis. Servem para estimar algumas tabelas de probabilidade condicional e, sobretudo, para **avaliar** o sistema — o mesmo dado que é escasso demais para treinar pode ser suficiente para reprovar.
> **volte para:** #bayesianas-a-incerteza-com-estrutura
:::

## Síntese — o que levar

- **A representação escolhida decide qual busca é possível.** Nenhuma das quatro tradições inventou um otimizador melhor; cada uma inventou uma forma de **escrever o problema**. É o [capítulo 03](03-representacao.md) visto do lado da busca.
- **Nem todo problema de IA é problema de aprendizado.** Quando a informação está na cabeça de um especialista, num consenso publicado ou numa estrutura causal conhecida, aprendizado supervisionado não tem por onde recebê-la.
- **Simbólica**: base de conhecimento separada do motor de inferência; encadeamento para a frente para monitorar, para trás para diagnosticar. Explicação de graça, e o gargalo é a **aquisição**.
- **Fuzzy**: pertinência entre 0 e 1 modela **vagueza**, não incerteza — e as duas não se confundem. Medir mais elimina incerteza; não elimina vagueza.
- **Evolutiva**: população, seleção, cruzamento, mutação e aptidão. Vale sem gradiente e em espaço combinatório; **não vale** quando você pode derivar.
- **Bayesiana**: grafo dirigido acíclico mais tabelas condicionais. Dá inferência em qualquer direção, raciocínio sobre intervenção e tolerância a variável faltando — coisas que uma rede neural não entrega.
- **A rejeição tem geografia.** A comunidade que rejeita uma ideia raramente é a que a reabilita. Se o método não anda, procure a sala certa antes de trocar o método.
- **Aposta de arquitetura não é aposta de método.** O colapso de 1987 não mediu a qualidade da IA simbólica; mediu a durabilidade de um hardware especializado.

## Verificação

1. Um colega afirma que "IA simbólica é IA antiga". Dê dois cenários concretos do seu contexto em que a escolha simbólica seria tecnicamente superior — e diga qual característica do cenário determina isso.
2. Explique, sem usar a palavra "probabilidade", a diferença entre dizer que uma leitura tem pertinência 0,7 ao conjunto "quente" e dizer que há 70% de chance de a água estar quente. Que decisão prática muda conforme a interpretação?
3. Você tem um problema de escalonamento com 40 tarefas e um simulador que leva 8 segundos por avaliação. Um algoritmo genético é candidato razoável? Estime a ordem de grandeza do custo, diga o que você mediria antes de decidir e qual linha de base o algoritmo precisaria bater.

---

# 14 — Interpretabilidade e Justiça

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Distinguir modelo interpretável de explicação post-hoc.
- **O2.** Aplicar e criticar SHAP como atribuição de importância.
- **O3.** Comparar três definições formais de justiça e mostrar que são incompatíveis entre si.
- **O4.** Medir desempenho por subgrupo e decidir o que fazer com a diferença encontrada.

## O problema: explicar a decisão, e responder pela diferença

Quando um modelo nega um crédito, alguém precisa dizer por quê. Quando ele erra mais para um grupo de pessoas do que para outro, alguém precisa responder por isso. Os dois problemas se encontram no mesmo lugar: **explicação é o instrumento com que se descobre a diferença**, e a diferença é o que obriga a explicar.

Só que o resultado mais importante desta área não é técnico no sentido usual — é uma **impossibilidade**. As definições razoáveis de "justo" não podem ser satisfeitas ao mesmo tempo, exceto em casos degenerados. O erro que este capítulo previne é acreditar que existe um ajuste técnico que resolve. Não existe. Existe uma **escolha**, e alguém vai fazê-la — calado ou declarado.

## De onde isto veio

**O aperto.** Em 2016, um instrumento de avaliação de risco de reincidência usado em decisões judiciais reais nos Estados Unidos é acusado de viés racial. Acusação e defesa apresentam **evidência estatística correta** e chegam a **conclusões opostas**. Não é o caso comum, em que um lado errou a conta: os dois números estão certos.

**O que se fazia antes.** "Justiça" era tratada como qualidade única e não formalizada. Discutia-se se o modelo era justo — não **em qual sentido**.

**A virada.** Formalizar as definições rivais e **provar que são mutuamente incompatíveis** sempre que a prevalência do evento difere entre os grupos. A pergunta deixa de ser retórica e passa a ser aritmética.

**A ideia reaproveitável.** **Quando dois lados discordam com dados corretos, o desacordo é de definição, não de fato.** A pergunta útil não é "quem está certo?", é **"qual restrição cada um está impondo, e qual eu escolho pagar?"**. Vale muito além de justiça algorítmica: sempre que uma discussão trava com todos os números conferidos, procure a definição escondida.

**O nome.** De um lado, *calibração* — ou *test fairness*, vocabulário da psicometria, onde um teste é justo se o escore significa a mesma coisa para todo mundo. Do outro, *equilíbrio de taxas de erro*, vocabulário de quem olha a matriz de confusão. Dois campos, dois nomes, e a colisão entre eles é boa parte da confusão.

### O que cada um disse — e o que o teorema disse

**(a) O que a reportagem afirmou.** Angwin, Larson, Mattu e Kirchner publicam *Machine Bias* em **23 de maio de 2016**. Dois números sustentam a peça: entre réus que **não** reincidiram, **44,9%** dos negros contra **23,5%** dos brancos haviam sido rotulados de risco mais alto; entre os que **reincidiram**, **47,7%** dos brancos contra **28,0%** dos negros haviam sido rotulados de risco mais baixo. Isso é desequilíbrio de taxas de erro, e é real.

**(b) O que a empresa respondeu.** Em **julho de 2016**, a Northpointe publicou uma réplica técnica — Dieterich, Mendoza & Brennan, *COMPAS Risk Scales: Demonstrating Accuracy Equity and Predictive Parity* — sustentando que o instrumento satisfaz **paridade preditiva**. E aqui o capítulo para: **este livro não leu esse documento** (o PDF devolve 404). Existência e autoria estão confirmadas em material acadêmico; o argumento em si, não. Por isso o texto não o caracteriza em primeira mão — e você deve desconfiar de qualquer resumo que o caracterize sem apontar a página.

**(c) O que o teorema estabeleceu.** Este ponto, sim, está fechado. Alexandra Chouldechova ([arXiv:1610.07524](https://arxiv.org/abs/1610.07524)) define um escore como *test-fair* (bem calibrado) quando ele reflete a **mesma probabilidade de reincidência independentemente do grupo**, e daí deriva a relação entre taxa de falso positivo, prevalência, valor preditivo positivo e taxa de falso negativo. A conclusão, nas palavras dela: *"when the recidivism prevalence differs between two groups, a test-fair score S<sub>c</sub> cannot have equal false positive and negative rates across those groups."* No próprio dado a prevalência difere — **51% contra 39%** — e portanto *"some level of imbalance in the error rates must exist"*. Não é acusação nem defesa: é álgebra de três linhas.

Cinco meses depois da reportagem, Kleinberg, Mullainathan & Raghavan chegam ao mesmo muro por outro caminho ([arXiv:1609.05807](https://arxiv.org/abs/1609.05807), 19/09/2016): *"we prove that except in highly constrained special cases, there is no method that can satisfy these three conditions simultaneously."*

> ### A cronologia é o conteúdo
>
> **23 de maio → julho → 19 de setembro → 24 de outubro de 2016.** Cinco meses entre uma reportagem e **dois teoremas independentes**.
>
> E o desfecho é o que se perde na repetição da história: **os dois lados estavam certos dentro da própria definição**. O que o teorema acrescenta não é um vencedor — é a prova de que **não pode haver um**, a menos que se mude a prevalência ou se abra mão de um critério. 📖

### O outro fio: uma fórmula de 1953 esperando um problema

O lado da explicação tem história mais curta e intervalo maior. **LIME** aparece em **16/02/2016** (Ribeiro, Singh & Guestrin, *"Why Should I Trust You?"*); **SHAP**, em **22/05/2017** (Lundberg & Lee) — e o resumo declara a contribuição não como invenção, mas como **unificação**: *"The new class unifies six existing methods"*. A fórmula por trás dele é de **Lloyd S. Shapley**, *"A Value for n-Person Games"*, de **1953**.

> **O intervalo mais limpo do livro: 1953 → 2017, sessenta e quatro anos — e a fórmula não mudou.**
>
> O que mudou foi passar a existir um objeto cujas partes se pudessem tratar como jogadores de uma coalizão: um modelo treinado, com atributos que entram e saem. **A matemática esperou o problema, não o contrário.** Emparelha com Taylor 1953 → BERT 2018 no [capítulo 12](12-modelos-de-fundacao.md) — e o ano de origem é o mesmo nos dois casos. 📖

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ | Chouldechova, *Fair prediction with disparate impact* ([arXiv:1610.07524](https://arxiv.org/abs/1610.07524), 24/10/2016) — a definição de *test fairness*, a relação entre as taxas, as prevalências de 51% e 39% e as duas citações entre aspas. **Lido** |
| ✓ᵐ | Angwin, Larson, Mattu & Kirchner, *Machine Bias* (ProPublica, 23/05/2016) — os quatro percentuais (44,9 / 23,5 / 47,7 / 28,0): página aberta e números devolvidos **literalmente, mas por extrator automático**. Também ✓ᵐ: Shapley, *"A Value for n-Person Games"*, *Annals of Mathematics Studies* 28, Princeton UP, 1953, pp. 307–317; e o fato de Timnit Gebru assinar **Datasheets** (ver [capítulo 02](02-dados.md)) e **Model Cards**, ambos de 2018 |
| ✓ᵐ | Que Dieterich, Mendoza & Brennan publicaram *COMPAS Risk Scales* (Northpointe, julho de 2016) — existência e autoria confirmadas em material acadêmico |
| ❌ | **O conteúdo desse documento**: o PDF devolve 404 e não foi aberto. Por isso este capítulo afirma apenas que a réplica existe e sustenta paridade preditiva, e **não caracteriza o argumento da empresa em primeira mão** |
| ✓ᵃ | Kleinberg, Mullainathan & Raghavan ([arXiv:1609.05807](https://arxiv.org/abs/1609.05807), v1 19/09/2016); LIME ([arXiv:1602.04938](https://arxiv.org/abs/1602.04938), v1 16/02/2016); SHAP ([arXiv:1705.07874](https://arxiv.org/abs/1705.07874), v1 22/05/2017), incluindo a frase sobre unificar seis métodos; Model Cards — Mitchell, Wu, Zaldivar, Barnes, Vasserman, Hutchinson, Spitzer, Raji e Gebru ([arXiv:1810.03993](https://arxiv.org/abs/1810.03993), v1 05/10/2018). Em todos, a citação vem do **resumo** |
| 📖 | A leitura de que a cronologia é o conteúdo; o paralelo Shapley→SHAP com Taylor→BERT; e a formulação "o desacordo é de definição, não de fato" |

> **Legenda adicional:** **✓ᵃ** = o **resumo** do artigo foi lido literalmente e sustenta a citação; o corpo, não. É mais forte que ✓ᵐ e mais fraco que ✓.

## Fundamentos: o que é explicar um modelo

Duas perguntas diferentes se escondem sob a mesma palavra. **Global**: *como este modelo funciona, no geral?* — quais atributos usa, em que direção, com que peso; serve para auditar. **Local**: *por que este caso recebeu esta saída?* — serve para responder à pessoa que teve o crédito negado, e é o que a regulação normalmente exige. A assimetria prática é grande: times produzem explicação global com facilidade e são cobrados por explicação local.

### Interpretável por construção, ou explicado depois

**Interpretável por construção** é o modelo cuja estrutura já é a explicação: uma regressão linear com poucos atributos, uma árvore rasa, um sistema de regras (ver [capítulo 27](27-ia-simbolica-fuzzy-evolutiva.md)). Você lê o modelo e sabe o que ele faz. **Explicação post-hoc** é o que se faz quando o modelo é um ensemble de mil árvores ou uma rede profunda: treina-se um **segundo** objeto, simples, para descrever o comportamento do primeiro. Daí o alerta que sustenta metade deste capítulo.

> **Uma explicação post-hoc é uma aproximação do modelo — não a razão pela qual o modelo decidiu.**

O modelo não tem "razões": tem pesos. A explicação é uma narrativa ajustada para se parecer com o comportamento dele naquela vizinhança. Pode ser útil, defensável e ainda assim **não** ser o que aconteceu por dentro. Tratá-la como motivação da decisão — num relatório, numa auditoria, em juízo — é trocar o modelo pelo retrato dele. Quando a decisão for de alto risco e a exigência de justificar for real, considere pagar o preço do modelo interpretável por construção: a perda de desempenho costuma ser menor do que o time supõe, e às vezes some dentro do intervalo de confiança (ver [capítulo 25](25-do-modelo-a-decisao.md)).

### LIME e SHAP, sem fórmula

**LIME** faz o óbvio, e o óbvio funciona: pega o caso que você quer explicar, gera variações dele em volta, pergunta ao modelo o que ele responde para cada variação e ajusta um modelo simples **só naquela vizinhança**. O resultado responde *"perto deste caso, o modelo se comporta assim"* — nada além disso.

**SHAP** vem da teoria dos jogos cooperativos. Imagine a previsão como o prêmio de uma partida e cada atributo como um jogador que entra na coalizão: a contribuição de um jogador é o quanto ele acrescenta ao prêmio, **em média sobre todas as ordens possíveis de entrada**. Isso dá à atribuição uma propriedade rara — as contribuições **somam exatamente** o desvio entre a previsão daquele caso e a previsão média. Nada some, nada aparece do nada. Mas a atribuição **não é causal no mundo** ("renda contribuiu −0,4" não diz o que aconteceria se a renda mudasse), **não é a razão interna** do modelo, e **não é estável de graça**: atributos correlacionados dividem crédito de formas que dependem da implementação.

:::exercicio {"id":"14-e1","tipo":"multipla","objetivo":"O1","dificuldade":"facil"}
Um banco usa um ensemble de árvores para decidir crédito e gera, para cada negativa, uma explicação SHAP com os três atributos de maior contribuição. O jurídico pergunta se essa explicação pode ser apresentada como a motivação da decisão. Qual leitura é correta?

- [ ] Sim: SHAP tem base na teoria dos jogos, então a atribuição é causal e mostra o que causou a negativa.
- [x] Não: a explicação post-hoc descreve como o modelo se comporta perto daquele caso — é aproximação, não a razão interna da decisão.
- [ ] Sim, desde que as contribuições somem o desvio em relação à previsão média, o que SHAP garante.
- [ ] A pergunta não se aplica: bastaria trocar por um modelo interpretável por construção, que já dispensa a análise por subgrupo.

> **gabarito:** É uma aproximação do comportamento do modelo, não a razão da decisão
> **porque:** A explicação post-hoc é um **segundo objeto**, ajustado para imitar o primeiro numa vizinhança. Pode ser fiel e útil sem ser o que ocorreu por dentro do ensemble; apresentá-la como motivação troca o modelo pelo retrato dele. A primeira alternativa confunde duas causalidades: SHAP é causal **dentro do jogo** que ele define, não no mundo.
>
> A terceira captura o erro mais sedutor — a soma exata é propriedade real e desejável, mas **coerência aritmética não é veracidade explicativa**: uma decomposição pode fechar a conta perfeitamente e ainda descrever mal o mecanismo. A quarta erra em dobro: modelo interpretável por construção resolve a explicação, **não** a justiça — regras visíveis podem produzir taxas de erro muito diferentes entre grupos, e você só descobre medindo.
> **volte para:** #interpretavel-por-construcao-ou-explicado-depois
:::

## Três definições de justiça que não cabem juntas

Cada uma é razoável, cada uma tem defensores sérios, e cada uma exige coisa diferente. Repare que a primeira nem olha o desfecho, e as outras duas olham.

| Definição | Exige que… | Quem ela protege |
|---|---|---|
| **Paridade demográfica** | a proporção de decisões positivas seja igual entre os grupos | quem é sub-representado no resultado, independentemente do desfecho |
| **Igualdade de oportunidade** | entre quem **de fato** é positivo, a taxa de acerto seja igual entre os grupos | quem merecia a decisão favorável e não a teve |
| **Calibração** (*test fairness*) | o mesmo escore signifique a mesma probabilidade em qualquer grupo | quem lê o escore e age sobre ele — e quem seria mal servido por um escore que "vale menos" no seu grupo |

### A álgebra de três linhas

A relação de Chouldechova amarra quatro grandezas: **taxa de falso positivo**, **prevalência**, **valor preditivo positivo** e **taxa de falso negativo**. Fixadas três, a quarta está determinada. Não é tendência empírica — é identidade.

A consequência é a frase citada acima: com prevalência diferente entre os grupos, um escore calibrado **não pode** ter taxas de falso positivo e de falso negativo iguais entre eles. E prevalência quase sempre difere, por razões que nada têm a ver com o modelo — inclusive porque o dado histórico registra um processo social, não a verdade sobre as pessoas (ver [capítulo 02](02-dados.md) e [capítulo 12](12-modelos-de-fundacao.md)). Daí a formulação prática: **exigir as três definições ao mesmo tempo é exigir que a prevalência seja igual.** Se ela não for, você pediu algo aritmeticamente impossível — e alguém vai entregar um relatório dizendo que conseguiu.

:::exercicio {"id":"14-e2","tipo":"numerica","objetivo":"O4","dificuldade":"media"}
Um escore de risco foi avaliado separadamente em dois grupos, com mil pessoas cada. A tabela traz as quatro células da matriz de confusão de cada um:

| Grupo | Positivo real, previsto positivo | Positivo real, previsto negativo | Negativo real, previsto positivo | Negativo real, previsto negativo |
|---|---|---|---|---|
| **A** (prevalência 40%) | 280 | 120 | 120 | 480 |
| **B** (prevalência 60%) | 420 | 180 | 180 | 220 |

Calcule a **taxa de falso positivo do grupo B**. Responda em fração, com duas casas decimais.

> **gabarito:** 0,45 ± 0,01
> **porque:** A taxa de falso positivo se calcula **sobre os negativos reais**, nunca sobre o total. No grupo B há 180 + 220 = **400** negativos reais, dos quais 180 foram previstos positivos: 180 / 400 = **0,45**. O erro mais comum é dividir por 1 000 e obter 0,18 — isso mede outra coisa.
>
> Agora faça as outras contas, porque é aqui que o capítulo se fecha. Falso positivo no grupo A: 120 / 600 = **0,20**. Valor preditivo positivo: 280 / 400 = **0,70** no A e 420 / 600 = **0,70** no B — **idênticos**. Taxa de falso negativo: 120 / 400 = **0,30** no A e 180 / 600 = **0,30** no B — **também idênticos**.
>
> Ou seja: este escore trata os dois grupos igualmente em duas definições e ainda assim **erra para cima mais que o dobro** no grupo B. Nada foi sabotado, nenhum atributo sensível precisou entrar no modelo. A única diferença entre os grupos é a **prevalência**, e ela sozinha basta. É o teorema, agora em números que você conferiu com uma divisão.
> **volte para:** #a-algebra-de-tres-linhas
:::

## Quando o teorema diz que você tem de escolher

Provado que não dá para ter tudo, o trabalho muda de natureza: passa a ser de **procedimento**, em quatro partes.

**1. Declarar a escolha.** Escreva qual critério o sistema otimiza, qual foi abandonado e por quê — "priorizamos igualdade de oportunidade porque o custo do falso negativo recai sobre quem já tem menos acesso, e aceitamos taxas de falso positivo desiguais". Escolha calada não deixa de ser escolha; deixa apenas de ser auditável.

**2. Medir por subgrupo, sempre.** A média esconde a decisão. Reporte a **matriz de confusão inteira por subgrupo** (ver [capítulo 04](04-avaliacao.md)), não uma métrica agregada. Três cuidados: declare os subgrupos **antes** de olhar os resultados, para não caçar o recorte conveniente; verifique se cada um tem gente suficiente para a estimativa significar algo; e lembre que ausência de diferença medida num subgrupo pequeno é ausência de medida, não ausência de diferença.

**3. Envolver quem paga a conta.** A escolha entre critérios distribui erro entre pessoas, e quem decide raramente é quem recebe. Levar a decisão a quem sofre a consequência não é gentileza: é a única forma de descobrir qual erro dói mais — informação que não está no conjunto de dados.

**4. Registrar.** Um **Model Card** documenta o modelo como um datasheet documenta o dado: uso pretendido, uso desaconselhado, **desempenho desagregado por subgrupo** e considerações éticas. O elo com o [capítulo 02](02-dados.md) não é analogia — é a **mesma autora**: Timnit Gebru assina os dois, no mesmo ano. Documentar o dado e documentar o modelo são um projeto só.

E há uma quinta saída, legítima: **não lançar**. Desempenho bom no agregado e ruim num subgrupo que importa é motivo suficiente, e defender a recusa exige o mesmo aparato de defender o lançamento — ver [capítulo 25](25-do-modelo-a-decisao.md).

:::exercicio {"id":"14-e3","tipo":"aberta","objetivo":"O3","pontos":3,"dificuldade":"dificil"}
Um plano de saúde vai usar um escore para selecionar pacientes crônicos que entram num programa de acompanhamento intensivo — as vagas são limitadas e o programa reduz internações. A prevalência de complicação grave é **maior no grupo X** do que no grupo Y, por razões conhecidas de acesso histórico a atendimento.

A diretoria pede que o escore seja, ao mesmo tempo, **calibrado** (o mesmo escore significa a mesma probabilidade nos dois grupos) e **igualitário em oportunidade** (mesma taxa de acerto entre quem de fato vai complicar). Escreva a resposta que você levaria à diretoria: explique por que o pedido é impossível como está, escolha **um** dos dois critérios, e diga **quem paga a conta** da sua escolha.

> **rubrica:** explica que os dois critérios não podem valer juntos porque a prevalência difere, e que isso é identidade aritmética, não limitação de engenharia;
> nomeia corretamente o que cada critério exige;
> escolhe explicitamente um critério em vez de propor um meio-termo vago;
> identifica de forma concreta quem sofre o erro resultante — qual grupo, qual tipo de erro, qual consequência clínica;
> propõe ao menos uma ação de procedimento (registrar a escolha, reportar por subgrupo, ouvir os afetados, atacar a prevalência na origem);
> NÃO afirma que existe uma resposta tecnicamente correta
> **porque:** A resposta fraca promete "buscar um equilíbrio" e pede mais dados. Mais dados não removem a incompatibilidade: ela decorre da diferença de prevalência, não do tamanho da amostra.
>
> A resposta forte faz três movimentos. Devolve o pedido — as duas exigências juntas equivalem a exigir prevalências iguais. Escolhe, e nomeia o preço: priorizar **igualdade de oportunidade** tende a levar mais gente do grupo X ao programa, aumentando o falso positivo lá e consumindo vagas que outros pacientes teriam; priorizar **calibração** preserva o significado do escore para quem o lê, ao custo de taxas de erro piores num dos grupos. E diz **quem paga** em pessoas e desfechos — pacientes que complicam sem entrar no programa, ou pacientes que ocupam vaga sem precisar — não em métrica. O que separa a boa da excelente é reparar que a prevalência diferente **é ela mesma resíduo de um acesso desigual anterior**: otimizar sobre ela é herdar o problema, e a ação mais valiosa pode estar fora do modelo.
> **volte para:** #quando-o-teorema-diz-que-voce-tem-de-escolher
:::

## Síntese — o que levar

- **Quando dois lados discordam com dados corretos, o desacordo é de definição, não de fato.** Procure a definição escondida antes de procurar o erro de conta.
- Interpretabilidade tem duas perguntas: **global** (como funciona) e **local** (por que este caso). A regulação cobra a local; os times entregam a global.
- **Explicação post-hoc é aproximação, não motivação.** SHAP soma exato — e soma exata é **coerência**, não veracidade, nem causalidade no mundo.
- Paridade demográfica, igualdade de oportunidade e calibração são **critérios rivais**. Exigir os três é exigir prevalências iguais.
- Com prevalências diferentes, **algum desequilíbrio de taxas de erro tem de existir**. É identidade, não descuido.
- A média esconde a decisão: reporte a **matriz de confusão por subgrupo**, com os subgrupos declarados antes de olhar o resultado.
- Escolha declarada é auditável; escolha calada é a mesma escolha, sem responsável. E **não lançar** continua sendo uma saída.
- **A matemática esperou o problema** — Shapley 1953, SHAP 2017, fórmula intacta.

## Verificação

1. Um colega mostra uma explicação SHAP de uma negativa de crédito e conclui: "foi a renda que causou a recusa". Reescreva a frase de modo tecnicamente defensável, e diga o que se perde na versão original.
2. Sua auditoria mostra que o modelo é bem calibrado nos dois grupos e que a taxa de falso positivo é o dobro em um deles. Um gestor pede que você "corrija o modelo até que as duas coisas fiquem iguais". O que você responde, e o que oferece no lugar?
3. Você precisa escolher entre um ensemble com desempenho superior e um modelo de regras ligeiramente pior, num domínio em que cada decisão negativa pode ser contestada individualmente. Que critérios usaria, e em que condição a escolha se inverteria?

---

# 15 — Sistemas de ML

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Descrever os componentes de um sistema de ML além do modelo.
- **O2.** Identificar as formas de dívida técnica específicas de sistemas que aprendem.
- **O3.** Projetar o contrato entre treino e inferência para evitar training-serving skew.
- **O4.** Decidir entre predição em lote e em tempo real a partir do requisito, não do gosto.

## O problema: o modelo funciona, o sistema apodrece

O modelo entrou em produção e acertou. Seis meses depois, o mesmo time não consegue mais mexer nele.

Trocar um atributo de entrada exige reajustar o modelo inteiro, e ninguém sabe dizer o que vai acontecer. Um script sem dono junta três tabelas todo dia às 4h. Existe um arquivo de configuração com centenas de linhas que nunca passou por revisão. E um segundo modelo, de outro time, lê a saída do primeiro — o primeiro time descobriu isso por acaso.

Nada disso é bug. Nada disso aparece num teste. E, principalmente, **nada disso tem uma linha no orçamento** — porque cada item desses é caro sem ter nome. O erro que este capítulo previne é tratar **o modelo como se fosse o sistema**: ele é uma peça pequena de uma máquina grande, e os modos de falha caros moram fora dele.

## De onde isto veio

**O aperto.** Entre 2014 e 2015, dentro do Google, sistemas de Machine Learning (ML) em produção acumulavam um custo de manutenção que **nenhum vocabulário de engenharia existente nomeava**. Todo mundo sentia; ninguém conseguia escrever numa planilha.

**O que se fazia antes.** Tratava-se o modelo como o sistema. A "cola" entre os componentes era invisível — não por ser pequena, mas **porque não tinha nome**.

**A virada.** Não foi inventar uma técnica. Foi **importar um vocabulário pronto de outro campo** — o de *dívida técnica*, da engenharia de software — e usá-lo para tornar o custo legível a quem decide orçamento. Um time de dez autores publicou o diagnóstico no NIPS 2015, e o vocabulário pegou.

**A ideia reaproveitável.** **Um problema que não tem nome não entra no orçamento.** Antes de inventar solução, verifique se o que falta é a *palavra*. Custo sem nome não é priorizado, não é medido e não é defendido em reunião — ele apenas cresce, e depois alguém leva a culpa por "lentidão do time".

**O nome.** *Technical debt* é de **Ward Cunningham**, num addendum aos anais da **OOPSLA '92**: *"Shipping first time code is like going into debt."* Entregar código na primeira versão é como contrair uma dívida — útil, desde que se pague antes que os juros comam o time.

> ### A leitura que fecha (📖)
>
> A figura 1 do artigo de 2015 é o par da AlexNet do [capítulo 10](10-visao.md). **Duas imagens que atravessaram um campo inteiro**: uma é um limite de 3 GB desenhado; a outra é uma caixa preta pequena no meio de treze retângulos. **Nenhuma das duas é um resultado — as duas são argumentos visuais**, e é por isso que sobreviveram. Um resultado é superado pelo resultado seguinte; um argumento visual só cai quando o argumento deixa de valer.

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ | Tudo o que é atribuído a Sculley, Holt, Golovin, Davydov, Phillips, Ebner, Chaudhary, Young, Crespo e Dennison — figura 1, princípio CACE, dívida de configuração, *pipeline jungles* e os trechos citados entre aspas — de [*Hidden Technical Debt in Machine Learning Systems* (NIPS, 2015)](https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems), **lido por inteiro** |
| ✓ | O aperto (2014–15, dentro do Google) e a ausência de vocabulário para o custo de manutenção |
| ✓ | A metáfora do *plumbing* (encanamento) **não é dos autores**: no artigo ela é creditada a **Lin e Ryaboy**. O crédito some em quase toda repetição da metáfora — registre-o quando repetir |
| ✓ᵐ | *Technical debt*, de **Ward Cunningham**, addendum aos anais da **OOPSLA '92**, e a frase *"Shipping first time code is like going into debt."* |
| ⏳ | *Feature store* como termo público em *"Meet Michelangelo: Uber's Machine Learning Platform"*, **setembro de 2017**, descrita como camada compartilhada que garante consistência entre offline e online — fonte é blog corporativo, **não aberto em primeira mão** |
| ⏳ | A formulação canônica de *train/serve skew* em *Rules of Machine Learning*, de **Martin Zinkevich** (Google), regras **#29 a #37** — com a #32 como receita central: reutilizar o código entre treino e serviço |
| 📖 | A leitura de que a virada foi importar vocabulário, e de que a figura 1 e a AlexNet são o par de imagens-argumento do campo |

## Fundamentos: o que é o sistema, além do modelo

A frase que o artigo repete, e que vale decorar: *"only a tiny fraction of the code in many ML systems is actually devoted to learning or prediction"* — apenas uma fração minúscula do código é de fato aprendizado ou predição. A legenda da figura 1 diz o resto: *"The required surrounding infrastructure is vast and complex."*

O que ocupa o espaço restante, componente a componente:

| Componente | O que faz | Onde falha |
|---|---|---|
| **Coleta** | trazer o dado de onde ele nasce (ver [cap. 20](20-coleta-integracao.md)) | fonte muda de esquema sem avisar |
| **Validação de dados** | recusar o que está fora do contrato | não existe, e o lixo entra calado |
| **Extração de atributos** | transformar dado bruto em entrada do modelo | calculado de um jeito no treino, de outro no serviço |
| **Infraestrutura de serviço** | responder à chamada | latência, versão errada em produção |
| **Monitoramento** | perceber que algo mudou | mede a máquina, não a predição |
| **Gerenciamento de processos** | orquestrar quem roda quando | dependências implícitas entre jobs |

Os autores chamam esse entorno, **citando Lin e Ryaboy**, de *plumbing* — encanamento. É uma boa palavra: encanamento só é notado quando vaza.

### Por que dependências de dados são piores que dependências de código

Esta é a afirmação mais útil do artigo, e a que mais gente ignora: **dependências de dados custam mais que dependências de código**.

A razão é seca. Para dependência de código existe ferramenta — o compilador acusa, o *linker* quebra, o teste falha. **Para dependência de dados não há compilador.** Você consome um sinal produzido por outro time, aquele time muda a definição do sinal, e nada quebra: o modelo simplesmente piora, devagar, e ninguém liga uma coisa à outra. E há o efeito que dá nome ao princípio mais citado do artigo:

> *"No inputs are ever really independent. We refer to this here as the CACE principle: Changing Anything Changes Everything."*

Nenhuma entrada é realmente independente: mudar qualquer coisa muda tudo. E o princípio **não se limita aos sinais de entrada** — vale para hiperparâmetros, configurações de aprendizado, métodos de amostragem, limiares de convergência e seleção de dados. Remover um atributo aparentemente inútil não devolve o modelo anterior menos aquele atributo: devolve **outro modelo**.

:::exercicio {"id":"15-e1","tipo":"multipla","objetivo":"O1","dificuldade":"facil"}
Você vai apresentar a arquitetura do sistema de recomendação da empresa. Qual descrição é fiel ao que um sistema de ML em produção é?

- [ ] O modelo é o sistema; coleta, serviço e monitoramento são detalhes de implantação.
- [x] O código de aprendizado é uma fração pequena do total; a maior parte é coleta, validação, extração de atributos, serviço, monitoramento e orquestração.
- [ ] O sistema é metade modelo e metade infraestrutura, em partes equilibradas.
- [ ] A infraestrutura só cresce depois que o modelo fica grande demais para uma máquina.

> **gabarito:** O código de aprendizado é uma fração pequena; o resto é infraestrutura
> **porque:** É exatamente o argumento da figura 1 de Sculley et al. (2015) — a caixa preta pequena no meio de treze retângulos — e do corpo do artigo: *"only a tiny fraction of the code in many ML systems is actually devoted to learning or prediction"*.
>
> A primeira alternativa é o erro que o capítulo inteiro combate, e é o mais comum: quem trata o modelo como o sistema não orça o resto, e o resto chega mesmo assim. A terceira erra a proporção — não é meio a meio, é uma fração minúscula. A quarta inverte a causa: o encanamento não aparece porque o modelo cresceu, ele existe desde o primeiro dia em produção; o que muda com o tempo é só a visibilidade do custo.
> **volte para:** #fundamentos-o-que-e-o-sistema-alem-do-modelo
:::

## As dívidas que têm nome

Nomear é o serviço que o artigo presta. Cada item abaixo é um custo que você já pagou sem saber chamar.

**Glue code.** O código que existe só para fazer um pacote de propósito geral caber no seu problema: adaptadores, conversões de formato, empacotamentos. É a maior parte do que se escreve em volta de uma biblioteca de ML, e não faz nada de ML.

**Pipeline jungle.** Caso particular de *glue code*, no lado dos dados. Os autores a descrevem como *"a jungle of scrapes, joins, and sampling steps"* — uma selva de raspagens, junções e amostragens que cresce por acréscimo, um sinal novo de cada vez. E o diagnóstico é organizacional, não técnico: *"symptomatic of integration issues that may have a root cause in overly separated 'research' and 'engineering' roles."* A selva é sintoma de papéis de pesquisa e engenharia separados demais. Quem for consertar a selva reescrevendo scripts, e não a divisão de trabalho, vai fazer uma selva nova.

**Modelos em cascata e o correction cascade.** Você tem um modelo que funciona. Precisa dele para um problema ligeiramente diferente, e o caminho barato é aprender uma correção por cima da saída dele. Depois outra correção por cima da correção. Cada camada acrescenta dependência e prende o sistema a um mínimo local: melhorar o modelo de baixo agora **piora** os de cima, que foram treinados para corrigir os defeitos antigos dele.

**Consumidores não declarados.** A sua saída está num arquivo, num tópico, numa tabela. Alguém a lê — e você não sabe quem. Isso transforma qualquer mudança sua num incidente de outra pessoa, e é a dívida mais silenciosa da lista: ela só aparece no dia em que você melhora alguma coisa.

**Dívida de configuração.** A que quase todo time subestima. O artigo é direto: *"In a mature system which is being actively developed, the number of lines of configuration can far exceed the number of lines of the traditional code."* Num sistema maduro em desenvolvimento ativo, as linhas de configuração podem superar em muito as de código. E ele traz os exemplos datados, do tipo *"o atributo A foi registrado incorretamente de 14/09 a 17/09"* — o tipo de detalhe que vive num arquivo de configuração e decide o resultado do treino. Dos seis princípios de boa configuração que o artigo lista, o último é o que mais dói e o mais fácil de adotar: *"Configurations should undergo a full code review and be checked into a repository."*

## Reduzir a dívida: versionar, contratar, apagar

Três movimentos, em ordem de retorno por esforço.

**1. Versione o dado e a configuração como você versiona código.** Configuração revisada e no repositório é a recomendação literal do artigo. Dado versionado é o que permite responder à pergunta que sempre aparece depois de um incidente: *com qual dado exatamente este modelo foi treinado?* Sem versão, essa pergunta não tem resposta — só opinião.

**2. Escreva contratos de entrada.** Um contrato declara, para cada atributo, o tipo, a faixa aceitável, a taxa de nulos tolerada e quem é o dono. O que o contrato compra é o compilador que não existe: com ele, uma mudança silenciosa na fonte vira **falha ruidosa** na sua fronteira, e não uma degradação lenta seis semanas depois. É o mesmo assunto de qualidade e vazamento do [capítulo 02](02-dados.md), agora escrito como código executável.

**3. Apague código morto.** Atributo que não é mais usado, ramo experimental que nunca saiu, modelo que ninguém consulta. Cada um deles é superfície para o CACE agir e para um consumidor não declarado aparecer. Apagar é a única forma de pagamento de dívida que não cria dívida nova.

### O contrato entre treino e serviço

O *train/serve skew* é a fronteira mais cara do sistema: o mesmo atributo calculado de dois jeitos — um no treino, em lote, com a tabela inteira disponível; outro no serviço, sob latência, com o que chegou na requisição.

A formulação canônica está nas *Rules of Machine Learning*, de Martin Zinkevich, regras #29 a #37 (⏳). A regra #32 é a receita inteira, e é curta: **reutilize o código entre treino e serviço.** Não "escreva os dois com cuidado", não "documente a fórmula" — reutilize o mesmo código, de modo que a divergência se torne impossível em vez de improvável.

A *feature store* é a versão de plataforma dessa ideia: uma camada compartilhada que serve o mesmo atributo ao treino e à inferência. O termo aparece publicamente em setembro de 2017, na descrição do Michelangelo, plataforma de ML do Uber (⏳). O custo é que ela é mais uma peça de encanamento para manter — e o CACE também vale para ela.

:::exercicio {"id":"15-e2","tipo":"multipla-multi","objetivo":"O3","dificuldade":"media"}
Sua equipe calcula `media_de_compras_90d` num job Spark noturno para treinar, e reimplementa o mesmo atributo em Java no serviço de inferência. Quais medidas atacam de fato o *train/serve skew*? Marque todas que valem.

- [x] Extrair o cálculo do atributo para um único componente usado pelos dois caminhos.
- [x] Registrar em produção os atributos servidos e comparar sua distribuição com a do treino.
- [x] Declarar um contrato para o atributo (tipo, faixa, nulos) e verificá-lo nos dois lados.
- [ ] Aumentar a frequência do job noturno para de hora em hora.
- [ ] Retreinar o modelo com mais dados até que ele fique robusto à diferença.

> **gabarito:** unificar o código; monitorar as distribuições servida e de treino; contratar o atributo
> **porque:** As três corretas atacam a **causa** (duas implementações da mesma definição) ou garantem que a divergência apareça cedo. A primeira é a regra #32 na letra: reutilizar o código torna a divergência impossível, e não apenas improvável.
>
> As duas erradas são as tentações reais. Aumentar a frequência do job trata **frescor**, que é outro problema: a média de hora em hora continua sendo calculada por um código diferente do código do serviço, então o desvio persiste — só chega mais rápido. E retreinar com mais dados não corrige nada, porque o modelo continua sendo treinado com a versão *do treino* do atributo; mais dado só torna o modelo mais confiante sobre uma entrada que ele nunca verá em produção.
> **volte para:** #o-contrato-entre-treino-e-servico
:::

:::exercicio {"id":"15-e3","tipo":"aberta","objetivo":"O2","pontos":3,"dificuldade":"dificil"}
Um sistema de previsão de demanda funciona assim: um job diário raspa três bancos internos e uma planilha do time comercial, junta tudo e amostra os últimos 18 meses. Sobre a saída do modelo de demanda, um segundo modelo aplica uma correção sazonal, e um terceiro corrige a correção para as lojas do Nordeste. O time de precificação lê a tabela final — o time de demanda descobriu isso no mês passado. O comportamento do sistema é regido por um arquivo `params.yaml` de 600 linhas que fica na máquina do analista sênior.

Liste as dívidas ocultas deste sistema, **usando os nomes do capítulo**, e diga por onde você começaria a pagar — justificando a ordem.

> **rubrica:** identifica a pipeline jungle (raspagens + junções + amostragem crescendo por acréscimo);
> identifica a cascata de correções e explica que melhorar o modelo de base agora piora as camadas acima;
> identifica os consumidores não declarados (o time de precificação) e o risco que isso cria para qualquer mudança;
> identifica a dívida de configuração (600 linhas fora do repositório, sem revisão, sem versão);
> menciona a dependência de dados frágil da planilha do comercial e a ausência de contrato/validação;
> propõe uma ordem de pagamento com justificativa — e não apenas uma lista
> **porque:** A resposta fraca lista problemas genéricos ("falta documentação", "o código está bagunçado"). A resposta forte usa os nomes, porque **é o nome que faz o item entrar no orçamento** — a ideia reaproveitável deste capítulo.
>
> A ordem mais defensável começa pelo mais barato com maior redução de risco: **pôr o `params.yaml` no repositório, sob revisão**, é uma tarde de trabalho e elimina o ponto único de falha na máquina de uma pessoa. Em seguida, **declarar o contrato de entrada** — sobretudo o da planilha do comercial, que é a dependência de dados sem dono e sem compilador para acusá-la. Só então mexer na cascata, que é caro e exige negociar com quem depende dela. E, antes de qualquer mudança na saída, **descobrir e declarar os consumidores**: o time de precificação já é um; provavelmente não é o único.
>
> Repare que a resposta certa é organizacional tanto quanto técnica — a selva de pipelines é, no diagnóstico dos próprios autores, sintoma de papéis de pesquisa e engenharia separados demais.
> **volte para:** #as-dividas-que-tem-nome
:::

## Síntese — o que levar

- O código de aprendizado é uma **fração pequena** do sistema. O resto é encanamento — e encanamento só é notado quando vaza.
- **Um problema que não tem nome não entra no orçamento.** Às vezes o que falta não é solução: é a palavra.
- **Dependências de dados são piores que dependências de código**, porque não existe compilador que as acuse. Quem substitui o compilador é o **contrato de entrada**.
- **CACE:** mudar qualquer coisa muda tudo — inclusive hiperparâmetro, amostragem e limiar de convergência. Não existe mudança local num sistema que aprende.
- *Glue code*, *pipeline jungle*, cascata de correções, consumidores não declarados e configuração: cinco custos que você já paga — agora com nome. E **configuração é código**: revisão e repositório, sempre.
- Contra *train/serve skew*, **reutilize o código** entre treino e serviço. Documentar a fórmula duas vezes não é contrato.
- Apagar código morto é a única forma de pagar dívida sem criar dívida nova.
- A operação contínua desse sistema — o que monitorar, quando retreinar, como implantar — é o [capítulo 16](16-mlops.md), a sequência direta deste. A decisão de **não lançar** está no [capítulo 25](25-do-modelo-a-decisao.md).

## Verificação

1. Desenhe, para um sistema que você conhece, os componentes além do modelo. Qual deles não existe hoje — e o que essa ausência já custou?
2. Um colega propõe remover um atributo "que não faz diferença" e diz que o resto do modelo fica igual. Por que o CACE contradiz isso, e o que você pediria antes de aprovar?
3. Escolha um atributo do seu sistema e descreva como ele é calculado no treino e no serviço. Se as duas descrições não citarem o mesmo código, qual é o seu plano — e por que "conferir com cuidado" não é um plano?

---

# 16 — MLOps

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).

## Objetivos de aprendizagem

- **O1.** Versionar dado, código e modelo de forma que um resultado seja reproduzível meses depois.
- **O2.** Implantar um modelo atrás de uma API com contrato e validação de entrada.
- **O3.** Distinguir drift de covariáveis de drift de conceito e detectar cada um.
- **O4.** Projetar um plano de rollback antes do deploy, e não durante o incidente.

## O problema: aprovado na validação, reprovado em produção

O modelo passou na validação. Foi para produção. Três semanas depois, o desempenho medido no mundo real é bem pior que o do relatório — e ninguém consegue explicar.

A tentação é reabrir o modelo. É quase sempre o lugar errado de procurar. **A causa costuma não estar no modelo**: está em dois intervalos que ninguém mediu. O intervalo entre **treinar e servir** — onde o atributo calculado de um jeito no notebook é calculado de outro jeito na API, o mesmo vazamento do [capítulo 02](02-dados.md) reaparecendo com outro nome. E o intervalo entre **servir hoje e servir daqui a três meses** — onde o mundo muda e o modelo não sabe disso.

Este capítulo é a sequência direta do [capítulo 15](15-sistemas-de-ml.md): lá, o diagnóstico de que o sistema é maior que o modelo; aqui, o procedimento para operá-lo.

## De onde isto veio

**O aperto.** Times de ML entregando modelos como quem entrega um relatório — a mão, um arquivo por vez — e descobrindo que o artefato entregue apodrece sozinho. 📖

**O que se fazia antes.** Entrega manual; retreino por calendário ou, na prática, por reclamação: alguém do negócio nota que "está estranho" e o time retreina. ⏳

**A virada.** Aplicar entrega contínua a um artefato que muda em **três eixos**, não em um: **código**, **modelo** e **dado**. É a tese declarada de Sato, Wider & Windheuser em *"Continuous Delivery for Machine Learning"* (martinfowler.com, 2019) ✓ᵐ — e a razão de o pipeline de entrega contínua tradicional não bastar. Um pipeline que só reage a commit não vê dois dos três eixos.

**A ideia reaproveitável.** **O que muda sozinho precisa ser testado sozinho.** Software comum se degrada quando alguém edita; **modelo se degrada quando ninguém edita.** A inversão é o coração do capítulo: se a degradação não é disparada por uma ação humana, nenhum gatilho humano vai detectá-la. 📖

### O nome que ninguém cunhou

Aqui está o achado mais desconfortável do capítulo — e ele é sobre o próprio nome da disciplina.

A versão repetida em dezenas de fontes de indústria é que **"MLOps foi cunhado no artigo de 2015 de Sculley et al."**. Extraímos o texto integral do artigo e buscamos: **a palavra "MLOps" não aparece nenhuma vez.** Também não aparecem "feature store" nem "training/serving skew". Selo **✓** — é uma **verificação negativa** feita sobre o texto primário, e verificação negativa é das mais fortes que existem: não depende de interpretação, só de leitura.

A filiação a DevOps, essa sim, está documentada: *"The first devopsdays was held in Ghent, Belgium in 2009"*, com **Patrick Debois** listado como fundador na página oficial ✓ᵃ. Já a história de a abreviação "#devops" ter nascido da necessidade de caber numa hashtag de Twitter é ⏳ — consistente entre fontes secundárias, sem primária.

> **A leitura (📖):** este é o **sexto caso** do padrão *"crédito segue o vocabulário"* que atravessa o livro — e o mais extremo. Nos cinco anteriores (Gauss × Legendre no cap. [05](05-modelos-lineares.md), Linnainmaa × Rumelhart no [18](18-neuronio-artificial.md), Harris × Firth no [03](03-representacao.md), o *double descent* no [01](../01-fundamentos.md) e o k-means com seis pretendentes no [08](08-nao-supervisionado.md)), o crédito foi para a pessoa errada.
>
> **Aqui o campo não tinha um autor para o nome e fabricou um retroativamente**, escolhendo o artigo mais citado da vizinhança. E a atribuição sobreviveu apesar de ser **falsificável em trinta segundos** por quem tivesse o PDF aberto e uma busca de texto.

**Concept drift tem nome desde 1986.** Schlimmer & Granger publicam naquele ano dois trabalhos: *"Beyond Incremental Processing: Tracking Concept Drift"* (AAAI-86 — o termo está no título) e *"Incremental learning from noisy data"* (*Machine Learning* 1(3):317–354). O survey que organizou o campo é o de Gama, Žliobaitė, Bifet, Pechenizkiy & Bouchachia (*ACM Computing Surveys* 46(4), art. 44, 2014) ✓ᵐ. **De 1986 a 2014: vinte e oito anos entre o nome e a síntese.**

**E o procedimento veio rápido.** *The ML Test Score* — Breck, Cai, Nielsen, Salib & **Sculley**, IEEE Big Data 2017 — traz **28 testes e necessidades de monitoramento** pontuados ✓ᵐ. Repare no subtítulo: *"…and Technical Debt Reduction"*. É explicitamente a continuação do [capítulo 15](15-sistemas-de-ml.md): mesmo autor sênior, dois anos depois, transformando o diagnóstico em checklist. **Diagnóstico (2015) → procedimento (2017): dois anos.** Compare com as décadas do resto do livro — quando o diagnóstico é preciso *e* já existe infraestrutura, o procedimento chega rápido. É o mesmo fio dos capítulos [07](07-arvores-ensembles.md) e [12](12-modelos-de-fundacao.md).

**Procedência das afirmações desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ | "MLOps", "feature store" e "training/serving skew" **não aparecem** no artigo de Sculley et al. (2015) — texto integral extraído e buscado |
| ✓ᵃ | O primeiro devopsdays em Ghent, Bélgica, 2009, e Patrick Debois como fundador — página oficial do evento |
| ✓ᵐ | Sato, Wider & Windheuser, *Continuous Delivery for Machine Learning* (martinfowler.com, 2019), e a tese dos três eixos |
| ✓ᵐ | Breck, Cai, Nielsen, Salib & Sculley, *The ML Test Score* (IEEE Big Data, 2017), com 28 testes e necessidades de monitoramento |
| ✓ᵐ | Gama, Žliobaitė, Bifet, Pechenizkiy & Bouchachia, *ACM Computing Surveys* 46(4), art. 44, 2014 |
| ⏳ | Schlimmer & Granger (1986) como cunho de *concept drift* — **nenhum dos dois trabalhos foi aberto**; o título do AAAI-86 é a evidência mais forte obtida |
| ⏳ | A origem da hashtag "#devops" no limite de caracteres do Twitter |
| 📖 | A leitura do "sexto caso" do padrão *crédito segue o vocabulário*, e a inversão "modelo se degrada quando ninguém edita" |

## Fundamentos: versionar, registrar, servir

**Versionar o quê.** Reproduzir um resultado meses depois exige cinco coisas, não uma: **código**, **dado**, **modelo**, **configuração** (hiperparâmetros, limiar, regras de negócio) e **ambiente** (versões de biblioteca). Faltando qualquer uma, o número do relatório não volta. Dado costuma ser versionado por *hash* de conteúdo, não por cópia — o que se guarda é a impressão digital que prova qual dado foi usado.

**Registro de modelos e linhagem.** Um registro de modelos responde a três perguntas em segundos: qual versão está em produção, **de qual dado e de qual código ela saiu**, e quem a promoveu. A pergunta da linhagem é a que salva auditoria e incidente. Um modelo sem linhagem é um binário anônimo: você pode desligá-lo, mas não pode explicá-lo.

**Servir.** Três formas, escolhidas pelo requisito e não pelo gosto:

| Forma | Quando serve | Latência típica |
|---|---|---|
| **Batch** | a decisão pode esperar horas; predições calculadas em lote e guardadas | minutos a horas |
| **Online** | a decisão é pedida na hora, por requisição | milissegundos |
| **Streaming** | a decisão acompanha um fluxo contínuo de eventos | segundos |

A escolha manda no resto da arquitetura. Batch tolera atributo caro; online não — se calcular o atributo custa 800 ms, o modelo online já perdeu, por mais preciso que seja.

:::exercicio {"id":"16-e1","tipo":"multipla","objetivo":"O1","dificuldade":"media"}
Um auditor pergunta: *"este modelo em produção foi treinado com quais dados?"*. O time tem o código no Git, o modelo salvo em disco e os notebooks de treino. O que falta para responder com segurança?

- [ ] Nada: basta rodar o notebook de novo e olhar o resultado.
- [x] O registro da linhagem — qual versão do dado e qual commit produziram **aquele** artefato em produção.
- [ ] Um conjunto de teste maior, para reavaliar o modelo hoje.
- [ ] A documentação do modelo escrita pelo time.

> **gabarito:** Falta a linhagem: dado e commit amarrados ao artefato em produção
> **porque:** Rodar o notebook de novo **produz outro modelo**, não recupera o que está servindo — as bibliotecas mudaram, o dado provavelmente cresceu e a seed pode não ter sido fixada. Reavaliar hoje responde "ele ainda é bom?", que é outra pergunta. E documentação escrita à mão descreve a intenção, não o fato: ela não prova nada, porque nada a obriga a estar sincronizada.
>
> A única resposta verificável amarra o artefato ao **hash do dado** e ao **commit** que o geraram, registrados no momento do treino. Reprodutibilidade não é uma qualidade do time; é um dado que se grava.
> **volte para:** #fundamentos-versionar-registrar-servir
:::

## Monitorar em três camadas

Monitoramento de ML não é um painel: são **três** painéis, com donos e tempos diferentes.

1. **Saúde do serviço** — taxa de erro, latência, disponibilidade. Quebra em segundos e é a camada que todo time já sabe montar.
2. **Qualidade do dado de entrada** — esquema, faixas, proporção de nulos, cardinalidade de categóricas. Quebra em horas e é a que mais pega falha real, porque a maior parte dos incidentes de ML é um campo que mudou de unidade ou passou a chegar vazio (ver [capítulo 20](20-coleta-integracao.md)).
3. **Desempenho do modelo** — a métrica do [capítulo 04](04-avaliacao.md). E aqui está a dificuldade central: **ela só pode ser calculada quando o rótulo chega**, o que pode levar semanas ou meses.

**Os três tipos de drift.** *Drift de dados* (ou de covariáveis): a distribuição da **entrada** muda — chegam clientes de outro perfil. *Drift de conceito*: a relação entre entrada e saída muda — o mesmo perfil de cliente passa a se comportar de outro jeito. *Drift de rótulo*: a distribuição da **saída** muda — a fraude que era 0,3% da base virou 2%.

O drift é exatamente a quebra da hipótese que o [capítulo 01](../01-fundamentos.md) coloca na fundação: treino e produção vindo da mesma distribuição. Nada no modelo protege contra isso, porque a hipótese é anterior ao modelo.

**Detectar sem rótulo.** Enquanto o rótulo não chega, sobra o que não depende dele: comparar a **distribuição da entrada** de hoje com a de referência (a janela de treino), atributo a atributo, e comparar a **distribuição da saída** — o histograma das probabilidades previstas. Se o modelo começa a prever positivo com o dobro da frequência de antes, algo mudou, mesmo que ninguém ainda saiba se ele está certo. É um alarme, não um veredito: drift de entrada **não implica** queda de desempenho, e queda de desempenho pode acontecer sem drift visível na entrada.

:::exercicio {"id":"16-e2","tipo":"aberta","objetivo":"O3","pontos":3,"dificuldade":"dificil"}
Você opera um modelo que prevê, na assinatura do contrato, se um cliente vai ficar inadimplente. O **rótulo verdadeiro só existe 90 dias depois** — é o prazo para a primeira parcela vencer e o atraso ser confirmado.

Descreva como você monitora esse modelo **durante os 90 dias**, e o que faria disparar uma investigação antes do rótulo chegar.

> **rubrica:** reconhece explicitamente que a métrica de desempenho não pode ser calculada no intervalo, e não propõe calculá-la;
> propõe monitorar a distribuição das **entradas** contra a janela de referência do treino;
> propõe monitorar a distribuição das **saídas** (probabilidades previstas ou taxa de positivos);
> cita ao menos um sinal proxy ou parcial (sinais precoces de atraso, cancelamentos, reclamações, taxa de aprovação por segmento);
> reconhece que esses sinais são alarme e não veredito, e diz o que faria em seguida (investigar, segurar promoção, comparar com o campeão anterior)
> **porque:** A resposta fraca diz "acompanho a acurácia semanalmente" — impossível, porque **não há rótulo para comparar**. Essa é a armadilha do exercício e o erro real mais comum de painel de ML: exibir uma métrica de desempenho que, nos primeiros 90 dias, está sendo calculada sobre um recorte enviesado (só os casos que já venceram, que são justamente os contratos mais antigos).
>
> A resposta forte separa o que se pode medir agora do que só se poderá medir depois. Entrada e saída são observáveis imediatamente; o rótulo, não. E a resposta excelente acrescenta o passo seguinte: quando o rótulo enfim chega, ele chega **atrasado e em blocos**, então a avaliação precisa ser feita por coorte de entrada — os contratos de março avaliados juntos — e não pela data em que o rótulo apareceu. Misturar as duas datas é reinventar o vazamento temporal do [capítulo 02](02-dados.md) dentro do próprio monitoramento.
> **volte para:** #monitorar-em-tres-camadas
:::

## Retreinar e implantar sem quebrar

**Retreino por gatilho ou por calendário?** Por gatilho — quando o monitoramento acusa drift ou queda de métrica — é a resposta certa quando existe monitoramento confiável e o rótulo chega em tempo útil. Por calendário é o padrão honesto quando não existe: um retreino mensal é uma aposta, mas é melhor que esperar a reclamação. Os dois exigem a mesma coisa: **o retreino precisa ser um pipeline que roda sozinho**, não um notebook que alguém reabre.

E vale a regra que o [capítulo 25](25-do-modelo-a-decisao.md) impõe: **retreinar não é a única resposta**. Se o que mudou foi o custo do erro, recalcule o limiar; o modelo pode continuar o mesmo.

**Implantação segura.** Três instrumentos, do mais barato ao mais caro:

- **Sombra**: o modelo novo recebe o tráfego real e responde, mas **a resposta é descartada** — serve só para comparar com a do modelo atual. Risco zero para o usuário.
- **Canário**: uma fatia pequena do tráfego real vai para o novo. Aqui o usuário já é afetado, então há critério de parada definido **antes**.
- **Reverter**: voltar à versão anterior em minutos, sem retreinar nada. Só é possível se a versão anterior continua registrada e servível.

O plano de rollback é o item que quase todo time escreve durante o incidente, quando já é tarde. **Escreva antes**: qual métrica dispara a volta, qual é o limite, quem tem autoridade para acionar e quanto tempo leva. Um plano que depende de retreinar não é plano de rollback — é um segundo incidente.

:::exercicio {"id":"16-e3","tipo":"multipla-multi","objetivo":"O4","dificuldade":"media"}
Você vai promover uma nova versão de um modelo de recomendação. Quais práticas reduzem o risco **antes** de o usuário ser afetado?

- [x] Rodar o modelo novo em sombra, comparando as respostas com as do atual sem entregá-las a ninguém.
- [x] Manter a versão anterior registrada e servível, para reverter sem retreinar.
- [x] Definir, antes do deploy, a métrica e o limite que disparam a volta atrás.
- [ ] Substituir a versão antiga assim que o modelo novo vencer no conjunto de teste.
- [ ] Aumentar o tráfego do canário rapidamente, para colher resultado estatístico antes.

> **gabarito:** sombra, versão anterior servível e critério de parada escrito antes
> **porque:** As duas alternativas erradas são as tentações reais. Vencer no conjunto de teste diz que o modelo é melhor **naquele dado**; produção tem tráfego, latência e distribuição que o teste não tem — é justamente o intervalo entre treinar e servir que abre este capítulo. E acelerar o canário para "ter significância logo" inverte a lógica do canário: ele existe para **limitar o dano**, não para produzir resultado rápido; quem acelera troca a proteção pela pressa.
>
> Repare que a sombra é a única das três práticas certas que dá evidência **com risco zero**, porque a resposta do modelo novo nunca chega ao usuário. É o instrumento mais subutilizado da lista.
> **volte para:** #retreinar-e-implantar-sem-quebrar
:::

## Síntese — o que levar

- A falha em produção quase nunca está no modelo. Está entre **treinar e servir**, e entre **servir hoje e servir em três meses**.
- **O que muda sozinho precisa ser testado sozinho.** Software se degrada quando alguém edita; modelo se degrada quando **ninguém** edita.
- A aplicação muda em **três eixos** — código, modelo e dado. Pipeline que só reage a commit enxerga um terço do problema.
- Reprodutibilidade exige **cinco** versionamentos: código, dado, modelo, configuração e ambiente.
- Linhagem é a pergunta que salva auditoria: **de qual dado e de qual código saiu este artefato?**
- Monitore em **três camadas**: serviço, dado de entrada, desempenho. A terceira só existe quando o rótulo chega.
- Sem rótulo, monitore **distribuição de entrada e de saída**. Isso é alarme, não veredito.
- Drift de dados ≠ drift de conceito ≠ drift de rótulo. O que muda é diferente, e a resposta também.
- **Escreva o plano de rollback antes do deploy.** Sombra, canário e reverter — nessa ordem de custo.
- E o nome da disciplina não foi cunhado onde todo mundo diz. Atribuição repetida não é atribuição verificada.

## Verificação

1. Um colega propõe versionar apenas o código e o modelo, porque "o dado é grande demais". Que pergunta ele deixa de conseguir responder — e como o *hash* de conteúdo resolve isso sem copiar o dado?
2. O painel mostra drift claro na distribuição de duas entradas, mas a métrica de desempenho medida sobre os rótulos que já chegaram está estável. Retreinar ou não? Justifique usando a diferença entre drift de covariáveis e drift de conceito.
3. Descreva o plano de rollback do último sistema em que você trabalhou — métrica de disparo, limite, responsável e tempo de execução. Se algum dos quatro não existir, diga o que aconteceria no incidente.

---

# 17 — Fronteira e Expiração

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-10 · [histórico](../HISTORICO.md)
>
> **Nível: essencial.** Corpo escrito e prática funcionando; o aprofundamento (experimento próprio, todas as fontes conferidas, cláusula de expiração) vem em ciclo próprio — ver [níveis de maturidade](../GUIA-EDITORIAL.md#niveis-de-maturidade).
>
> **Capítulo não-método** ([ADR 0004](../../adr/0004-escopo-da-primeira-versao.md)): não ensina um procedimento com inventor e data, e por isso é um dos dois que não trazem a seção "De onde isto veio". O que ele traz no lugar é o placar do próprio livro.

## Objetivos de aprendizagem

- **O1.** Identificar as questões abertas relevantes para a prática, e não só para a pesquisa.
- **O2.** Avaliar criticamente uma alegação de estado da arte.
- **O3.** Aplicar a cláusula de expiração ao próprio conhecimento do leitor.

## O problema: um livro técnico que finge ser atemporal envelhece mentindo

Se cada capítulo declara a data em que fotografou o estado da arte, alguém precisa manter o placar — anotar o que foi previsto, o que se confirmou e o que se refutou.

É também o capítulo que faz a pergunta desconfortável: **o que, do que você acabou de ler, tem prazo de validade curto?** A resposta honesta tem duas metades. Os fundamentos — generalização, viés e variância, o custo do erro, a separação entre quem produz e quem avalia — envelhecem devagar; alguns têm quase um século e continuam de pé. **Quase todo o resto envelhece rápido**, e o capítulo [12](12-modelos-de-fundacao.md) envelhece enquanto você lê.

## O que os especialistas erraram — e como o erro chega até você

A primeira lição deste capítulo não é "especialistas erram". Isso todo mundo já sabe, e saber disso não muda nada.

A lição é mais fina, e vem de conferir três previsões célebres da história da IA. **As três chegam ao presente distorcidas — e de três maneiras diferentes.**

### Uma com a data errada

Herbert Simon escreveu que, tecnologicamente, máquinas seriam capazes, **dentro de vinte anos**, de fazer qualquer trabalho que um homem faça.

A frase é real. **A citação corrente é que está errada:** ela costuma ser atribuída a *The Shape of Automation*, de **1965**, e o original é *The New Science of Management Decision*, de **1960** — o livro de 1965 reimprime o capítulo. Cinco anos de diferença, repetidos por décadas.

### Uma com autoria contestada pelo próprio citado

A previsão de que "de três a oito anos teremos uma máquina com a inteligência geral de um ser humano médio" é atribuída a Marvin Minsky, e foi publicada na revista *Life* de **20 de novembro de 1970**, em reportagem de Brad Darrach.

**Minsky contestou o conteúdo do artigo.** E aqui este livro precisa parar: a negativa documentada chega por terceiros, e a revista de 1970 não foi aberta. **Não podemos dizer "ele disse" nem "ele não disse".** O que se pode afirmar é que a frase foi publicada naquele artigo, e que há registro de contestação.

### Uma com o autor trocado

A história mais repetida das três: *Minsky teria mandado um aluno resolver visão computacional num verão*.

O documento existe, e é o **MIT AI Memo 100, "The Summer Vision Project", de 7 de julho de 1966** — assinado por **Seymour Papert**, não por Minsky, e propondo trabalho para um grupo, não para um aluno solitário. **O nome trocado, o número de pessoas inflado, e a ambição exagerada** — a versão popular erra nos três.

> ### A lição, e ela é melhor do que "especialistas erram"
>
> **Não é o conteúdo da previsão que apodrece primeiro — é a procedência.** A data escorrega, o autor troca, o contexto some, e o que sobra é uma frase boa demais para o slide.
>
> É o mesmo padrão que o [capítulo 08](08-nao-supervisionado.md) encontrou em "cerveja e fraldas", que o [13](13-reforco.md) encontrou na origem do nome *dynamic programming*, e que o [23](23-analise-multidimensional.md) encontrou no batismo do OLAP. **Quando um detalhe é bom demais para o slide, ele foi otimizado para o slide.**
>
> Por isso o placar deste livro registra, para cada afirmação datada, **onde ela foi publicada e por quem** — é isso que se perde antes do resto.

**Procedência desta seção:**

| Selo | Afirmação |
|---|---|
| ✓ᵃ | A frase de Simon e a correção da fonte de 1965 para *The New Science of Management Decision* (1960, p. 38) — via verificação que exibe a página do original |
| ✓ᵐ | O **MIT AI Memo 100**, *The Summer Vision Project*, 07/07/1966, assinado por **Seymour Papert** — obra, autoria e data. **O PDF não abriu** (o repositório devolveu erro) |
| ⏳ | Que a previsão de "três a oito anos" foi publicada na *Life* de 20/11/1970, em reportagem de Brad Darrach, **e** que Minsky contestou o artigo — a negativa chega por fonte de segunda mão, e a revista **não foi aberta** |
| ⏳ | Que a versão popular da lenda do "verão da visão" atribui o memorando a Minsky e a um aluno só |
| 📖 | A leitura de que a **procedência apodrece antes do conteúdo**, e a ligação com os caps. 08, 13 e 23 |

:::exercicio {"id":"17-e1","tipo":"multipla","objetivo":"O2","dificuldade":"media"}
Você lê num post: *"Estudos mostram que modelos de linguagem já superam médicos em diagnóstico."* Qual é a **primeira** pergunta a fazer?

- [ ] Qual modelo foi usado, e em qual versão?
- [ ] Quantos médicos participaram do estudo?
- [x] Qual estudo, publicado onde e quando — e o post está descrevendo o que o estudo mediu?
- [ ] O post é de uma fonte confiável?

> **gabarito:** Qual estudo, onde, quando — e o post descreve o que ele mediu?
> **porque:** As três alternativas erradas são boas perguntas **e vêm depois**. Sem localizar a fonte, você não tem o que perguntar: pode não haver estudo; pode haver um estudo que mediu outra coisa (concordância com um gabarito escrito, num conjunto de casos selecionados, sem exame físico nem histórico); ou pode haver um estudo real cuja conclusão o post ampliou.
>
> Repare que a alternativa "a fonte é confiável?" é a mais sedutora e a menos útil. **Confiabilidade da fonte é um atalho para não ir à fonte** — e é exatamente o atalho que fez a previsão de Simon circular por décadas com a data errada, e o memorando de Papert virar uma história sobre Minsky.
>
> A ordem certa é: **existe o estudo → o que ele mediu → sob que condição → o post está dizendo isso?** Quase toda alegação de estado da arte morre no segundo passo.
> **volte para:** #o-que-os-especialistas-erraram-e-como-o-erro-chega-ate-voce
:::

## O que envelhece rápido, e o que não envelhece

| Envelhece devagar | Envelhece rápido |
|---|---|
| generalização e a hipótese de mesma distribuição ([01](../01-fundamentos.md)) | qual arquitetura é o estado da arte |
| o custo do erro e o limiar como decisão de negócio ([04](04-avaliacao.md), [25](25-do-modelo-a-decisao.md)) | números de desempenho em benchmark |
| vazamento e as divisões que respeitam a estrutura ([02](02-dados.md)) | qual biblioteca usar |
| a representação como teto do que se pode aprender ([03](03-representacao.md)) | o tamanho de modelo considerado grande |
| a incompatibilidade entre definições de justiça ([14](14-interpretabilidade-justica.md)) | o que um modelo de fundação consegue fazer ([12](12-modelos-de-fundacao.md)) |
| o diagnóstico do gradiente como produto ([26](26-treinar-redes-profundas.md)) | qual o remédio da vez para treinar profundo |

Há uma regularidade nessa tabela, e ela é útil: **o que envelhece devagar é diagnóstico; o que envelhece rápido é remédio.** É a lição que o capítulo 26 tira de Hochreiter — o texto de 1991 mediu o problema e não o resolveu, e trinta e cinco anos depois o remédio mudou quatro vezes enquanto o diagnóstico ficou de pé.

Aplique isso ao que você acabou de estudar. **Se você aprendeu a reconhecer o aperto, você aprendeu a parte durável.** Se aprendeu só o procedimento, aprendeu a parte com prazo.

:::exercicio {"id":"17-e2","tipo":"aberta","objetivo":"O3","pontos":3,"dificuldade":"media"}
Escolha **um** capítulo deste livro que você leu. Escreva o que nele você espera que **ainda seja verdade em 2036**, o que espera que **esteja obsoleto**, e — a parte que importa — **qual observação futura faria você mudar de ideia** sobre cada um.

> **rubrica:** identifica ao menos um elemento durável e justifica pela natureza dele (diagnóstico, restrição estrutural, propriedade matemática), não por gosto;
> identifica ao menos um elemento com prazo e diz por que (depende de hardware, de escala, de biblioteca, de convenção da comunidade);
> propõe uma **observação falsificável** para cada previsão — algo que, se acontecesse, mostraria que a previsão estava errada;
> não trata "fundamentos duram" como slogan, mas aplica ao conteúdo concreto do capítulo escolhido
> **porque:** A resposta fraca repete a tabela acima com outras palavras. A resposta forte faz a parte difícil: **dizer o que a refutaria.**
>
> É a diferença entre uma previsão e um palpite. "A convolução vai continuar sendo usada" não é previsão — não há como errar. "Em 2036, arquiteturas com viés espacial embutido ainda vencerão transformadores puros em conjuntos de imagens abaixo de dez mil exemplos" é uma previsão: tem prazo, tem condição, e alguém pode conferir.
>
> E note o que você está fazendo ao responder: exatamente o que este livro faz consigo mesmo no [registro de expiração](../HISTORICO.md). Uma previsão sem critério de refutação não é humildade — é vagueza com aparência de prudência.
> **volte para:** #o-que-envelhece-rapido-e-o-que-nao-envelhece
:::

## O placar deste livro

O [histórico](../HISTORICO.md) mantém o registro de expiração: cada previsão que o livro faz entra com data, e sai com 🟢 confirmada, 🔴 refutada ou 🟡 em curso.

Isso tem um custo que vale nomear. **Um livro que registra as próprias previsões vai ser pego errando** — e é essa a intenção. O placar não existe para o livro parecer sábio; existe para que o leitor possa medir quanta confiança dar a ele. Um capítulo cujas previsões anteriores foram refutadas merece mais desconfiança que um que acertou, e sem o placar não há como saber qual é qual.

A dívida atual está declarada no [roadmap](../../ROADMAP.md), e a maior delas é honesta o bastante para aparecer aqui: **boa parte das fontes históricas deste livro está selada ✓ᵐ**, o que significa que conferimos que a obra existe e não que a lemos por inteiro. O ciclo de aprofundamento existe para pagar isso, uma fonte por vez.

:::exercicio {"id":"17-e3","tipo":"multipla","objetivo":"O1","dificuldade":"media"}
Um capítulo declara: *"Estado da arte capturado em 2026-08."* O que exatamente essa data promete?

- [ ] Que todas as informações do capítulo eram verdadeiras em agosto de 2026.
- [x] Que a seção de estado da arte foi conferida naquela data — e nada sobre quando os fatos históricos ocorreram.
- [ ] Que o capítulo será revisado em agosto de 2027.
- [ ] Que os experimentos foram executados naquele mês.

> **gabarito:** Que a seção de estado da arte foi conferida naquela data
> **porque:** Este livro distingue **três datas diferentes**, e confundi-las é o erro que o selo existe para prevenir: a data do **evento** (um fato histórico — 1943 não muda nunca), a data da **captura** (quando fotografamos o que era consenso), e a data do **experimento** (quando um número foi medido, e com qual versão de biblioteca).
>
> A primeira alternativa é a mais tentadora e a mais errada: a data de captura **não** valida o capítulo inteiro. Uma afirmação histórica com selo ⏳ continua ⏳ em qualquer data — a captura não conserta procedência.
>
> A terceira confunde captura com compromisso de revisão; a quarta, captura com execução. Num capítulo com experimento próprio, as duas datas coexistem e são declaradas separadamente, justamente porque um número medido com uma versão de biblioteca não é o mesmo número medido com outra.
> **volte para:** #o-placar-deste-livro
:::

## Síntese — o que levar

- Um livro técnico que finge ser atemporal **envelhece mentindo**. Declarar a data é o mínimo; manter o placar é o resto.
- **Não é o conteúdo da previsão que apodrece primeiro — é a procedência.** Data escorrega, autor troca, contexto some.
- As três previsões famosas da IA conferidas aqui chegam distorcidas de **três maneiras diferentes**: data errada, autoria contestada, autor trocado.
- **O que envelhece devagar é diagnóstico; o que envelhece rápido é remédio.** Quem aprendeu a reconhecer o aperto aprendeu a parte durável.
- Uma previsão sem **critério de refutação** não é humildade: é vagueza com aparência de prudência.
- Avaliar alegação de estado da arte, na ordem: **existe o estudo → o que mediu → sob que condição → é isso que estão dizendo?**
- Este livro tem dívida declarada, e a maior é que muita fonte está ✓ᵐ — conferimos que existe, não lemos por inteiro.

## Verificação

1. Pegue uma afirmação de qualquer capítulo deste livro e classifique-a: envelhece devagar ou rápido? O que exatamente a faria expirar?
2. Uma alegação de estado da arte cita um benchmark que você não conhece. Descreva os três passos que você daria antes de aceitá-la — e diga qual deles quase todo mundo pula.
3. Este livro erra em algum lugar. Onde você apostaria que está o erro, e por quê? (A pergunta é séria: se você não consegue apontar um candidato, provavelmente leu confiando demais.)

---

# Trilha — Análise Preditiva

> **Trilha de disciplina** — a ordem de leitura do livro para um curso específico.
>
> O número do capítulo é um **identificador estável**, não uma ordem. Um mesmo capítulo pode aparecer em mais de uma trilha, e capítulos de números distantes podem ser vizinhos aqui. É isso que permite ao livro cobrir três disciplinas sem se repetir.

**Disciplina:** Análise Preditiva · **Curso:** Engenharia de Software · **Professor:** Gilsiley Henrique Darú

Esta trilha assume que o estudante **já cursou Ciência de Dados** e traz a preparação de dados na bagagem. Ela vai da transformação de dados em informação até a entrega de um modelo preditivo defendido com evidência.

A ementa da disciplina tem três unidades; a trilha as segue.


## Unidade I — Transformação de Dados em Informação

*Dados, informação e conhecimento. SGBDs relacionais e NoSQL. Extração de conhecimento. ETL. Metodologia de pesquisa para análise de dados.*

| # | Capítulo | Por que aqui |
|---|---|---|
| 1 | [19 — O Ciclo da Ciência de Dados](../capitulos/19-ciclo-ciencia-de-dados.md) | CRISP-DM dá o mapa: por que a modelagem é a quarta fase |
| 2 | [20 — Coleta e Integração](../capitulos/20-coleta-integracao.md) | Arquivos, APIs, SQL e NoSQL, data lake × warehouse, ETL e ELT |
| 3 | [02 — Qualidade e Vazamento](../capitulos/02-dados.md) | O dado que chega está sujo, e o vazamento não dá erro |

**Ao final da unidade** o estudante monta um dataset a partir de fontes heterogêneas, com ficha de procedência, e sabe por que a divisão treino/teste precisa respeitar tempo e grupo.

## Unidade II — Análise Multidimensional de Dados

*Técnicas e ferramentas para análise multidimensional. Construção de repositório de dados.*

| # | Capítulo | Por que aqui |
|---|---|---|
| 4 | [23 — Análise Multidimensional](../capitulos/23-analise-multidimensional.md) | Fato e dimensão, esquema estrela, OLAP, granularidade |
| 5 | [21 — Análise Exploratória](../capitulos/21-analise-exploratoria.md) | Olhar antes de modelar: descritiva, dispersão, outliers |
| 6 | [22 — Visualização e Storytelling](../capitulos/22-visualizacao-storytelling.md) | O gráfico que decide — e os que enganam sem intenção |

**Ao final da unidade** o estudante constrói um repositório analítico e extrai dele uma leitura defensável do que já aconteceu.

## Unidade III — Análise Preditiva de Dados

*Técnicas de análise preditiva aplicadas aos dados do módulo II. Experimentar ao menos duas técnicas, comparar e apresentar os resultados.*

| # | Capítulo | Por que aqui |
|---|---|---|
| 7 | [04 — Avaliação](../capitulos/04-avaliacao.md) | **Antes de treinar**: escolher a métrica pelo custo do erro |
| 8 | [03 — Representação](../capitulos/03-representacao.md) | O modelo só vê o que você codificou |
| 9 | [05 — Modelos Lineares](../capitulos/05-modelos-lineares.md) | A primeira técnica, interpretável e auditável |
| 10 | [28 — Regressão Logística](../capitulos/28-regressao-logistica.md) | O mesmo maquinário para classificar: o que é linear é o logito |
| 11 | [07 — Árvores e Ensembles](../capitulos/07-arvores-ensembles.md) | A segunda técnica, e a que costuma ganhar em tabular |
| 12 | [24 — Séries Temporais](../capitulos/24-series-temporais.md) | Se o problema tiver tempo, ele muda de regras |
| 13 | [25 — Do Modelo à Decisão](../capitulos/25-do-modelo-a-decisao.md) | Comparar com honestidade e apresentar o resultado |

**Ao final da unidade** o estudante entrega a avaliação N3 da ementa: **duas técnicas comparadas com protocolo justo, incerteza declarada, e uma recomendação defendida** — inclusive a recomendação de não usar o modelo.

## Leitura de apoio (opcional)

- [00 — Introdução](../00-introducao.md) e [01 — Fundamentos](../01-fundamentos.md) — se o estudante nunca viu ML, começam aqui.
- [06 — Otimização](../capitulos/06-otimizacao.md) — para quem quiser entender o que o `fit()` faz por dentro.
- [14 — Interpretabilidade](../capitulos/14-interpretabilidade-justica.md) — quando a decisão precisa ser explicada a quem ela afeta.

## Prática

A construção [`ml-zero`](../trilha-ml-zero.md) acompanha esta trilha nas etapas **00** (linha de base), **02** (vazamento e divisões), **05–06** (lineares) e **07** (ensembles) — todas em Python puro, sem download e sem GPU.

---

# Trilha — Aprendizagem de Máquina

> **Trilha de disciplina** — a ordem de leitura do livro para um curso específico.
>
> O número do capítulo é um **identificador estável**, não uma ordem. Um mesmo capítulo pode aparecer em mais de uma trilha, e capítulos de números distantes podem ser vizinhos aqui. É isso que permite ao livro cobrir três disciplinas sem se repetir.

**Disciplina:** Aprendizagem de Máquina · **Curso:** Engenharia de Software · **Professor:** Gilsiley Henrique Darú

Esta trilha assume que o estudante **já cursou Análise Preditiva** e conhece o supervisionado clássico. Por isso ela vai **direto para as redes** e trata os modelos clássicos como revisão rápida.

A ementa tem seis unidades; a trilha as segue, redistribuindo a carga para o que a disciplina de fato aprofunda.


## Unidade 01 — Introdução à Aprendizagem de Máquina *(4h)*

| # | Capítulo | Por que aqui |
|---|---|---|
| 1 | [00 — Introdução](../00-introducao.md) | Quando ML é a resposta, e — mais importante — quando **não** é |
| 2 | [01 — Fundamentos](../01-fundamentos.md) | Generalização, viés e variância: o problema que nunca sai de cena |

## Unidade 02 — Machine Learning e Deep Learning *(8h)*

*Modelos baseados em símbolo, conexionistas, evolutivos, estatísticos e híbridos.*

| # | Capítulo | Por que aqui |
|---|---|---|
| 3 | [27 — IA Simbólica, Fuzzy e Evolutiva](../capitulos/27-ia-simbolica-fuzzy-evolutiva.md) | Os paradigmas que **não** aprendem de dados — e onde ainda ganham |
| 4 | [18 — O Neurônio Artificial](../capitulos/18-neuronio-artificial.md) | O conexionismo começa aqui: McCulloch–Pitts, perceptron, e o XOR **no laboratório interativo** |

> A aula do capítulo 18 tem um objeto manipulável: o estudante põe os pesos à mão e vê a reta se mover. O XOR é descoberto, não contado.

## Unidade 03 — Aprendizado Supervisionado *(20h)*

*Modelos preditivos. Classificação. Regressão. Algoritmos clássicos **e redes neurais**.*

| # | Capítulo | Peso na disciplina |
|---|---|---|
| 5 | [04 — Avaliação](../capitulos/04-avaliacao.md) | revisão rápida — já visto em Análise Preditiva |
| 6 | [05 — Modelos Lineares](../capitulos/05-modelos-lineares.md) e [28 — Regressão Logística](../capitulos/28-regressao-logistica.md) | revisão rápida — o 28 é pré-requisito real do capítulo 09: um neurônio com sigmoide **é** uma regressão logística |
| 7 | [07 — Árvores e Ensembles](../capitulos/07-arvores-ensembles.md) | revisão rápida (retomado na Unidade 06) |
| 8 | [06 — Otimização e Regularização](../capitulos/06-otimizacao.md) | **aprofundar** — é a base do treino de redes |
| 9 | [09 — Redes Multicamadas](../capitulos/09-redes-neurais.md) | **núcleo** — a camada escondida e o backpropagation |
| 10 | [26 — Treinar Redes Profundas](../capitulos/26-treinar-redes-profundas.md) | **núcleo** — o que faz uma rede de 20 camadas convergir |

## Unidade 04 — Aprendizado Não Supervisionado *(16h)*

*Modelos descritivos. Clusterização. Associação. Sumarização. Algoritmos clássicos e redes neurais.*

| # | Capítulo |
|---|---|
| 11 | [08 — Aprendizado Não Supervisionado](../capitulos/08-nao-supervisionado.md) |
| 12 | [03 — Representação](../capitulos/03-representacao.md) — redução de dimensionalidade e embeddings |

## Unidade 05 — Aprendizado por Reforço *(16h)*

*MDPs. Q-learning. Deep Q-networks.*

| # | Capítulo |
|---|---|
| 13 | [13 — Aprendizado por Reforço](../capitulos/13-reforco.md) |

## Unidade 06 — Ensembles e Modelos Generativos *(16h)*

*ML com ensembles. Modelos generativos com LLMs.*

| # | Capítulo | Por que aqui |
|---|---|---|
| 14 | [07 — Árvores e Ensembles](../capitulos/07-arvores-ensembles.md) | agora **aprofundado**: bagging × boosting e o que cada um ataca |
| 15 | [10 — Visão Computacional](../capitulos/10-visao.md) | convolução e transferência de aprendizado |
| 16 | [11 — Sequências e Linguagem](../capitulos/11-sequencias-linguagem.md) | de RNN ao Transformer: como se chega aos LLMs |
| 17 | [12 — Modelos de Fundação e Generativos](../capitulos/12-modelos-de-fundacao.md) | LLMs, embeddings, fine-tuning e RAG |

## Leitura de apoio (opcional)

- [16 — MLOps](../capitulos/16-mlops.md) e [15 — Sistemas de ML](../capitulos/15-sistemas-de-ml.md) — para quem for levar um modelo a produção.
- [14 — Interpretabilidade e Justiça](../capitulos/14-interpretabilidade-justica.md) — obrigatório se a aplicação decidir sobre pessoas.
- [17 — Fronteira e Expiração](../capitulos/17-fronteira.md) — a unidade "tendências da área" da ementa.

## Prática

A construção [`ml-zero`](../trilha-ml-zero.md) atende esta trilha nas etapas **05–06** (o otimizador que treina redes), **07** (ensembles) e, quando prontas, **09** (rede em NumPy), **10** (convolução) e **11** (atenção).

---

# Trilha — Ciência de Dados

> **Trilha de disciplina** — a ordem de leitura do livro para um curso específico.
>
> O número do capítulo é um **identificador estável**, não uma ordem. Um mesmo capítulo pode aparecer em mais de uma trilha, e capítulos de números distantes podem ser vizinhos aqui. É isso que permite ao livro cobrir três disciplinas sem se repetir.

**Disciplina:** Ciência de Dados · **Curso:** Engenharia de Software · **Professor:** —

Esta trilha cobre a **base** — a disciplina que antecede Análise Preditiva e Aprendizagem de Máquina. Serve a dois públicos: quem está cursando, e quem já cursou e precisa revisar antes das disciplinas seguintes.

Se você chegou aqui vindo de Análise Preditiva ou de Aprendizagem de Máquina e alguma coisa não fez sentido, provavelmente o que faltou está nesta trilha.


## Fundamentos e ciclo

| # | Capítulo | Cobre |
|---|---|---|
| 1 | [19 — O Ciclo da Ciência de Dados](../capitulos/19-ciclo-ciencia-de-dados.md) | CRISP-DM, papéis, relação entre Ciência de Dados, IA e Estatística |
| 2 | [00 — Introdução](../00-introducao.md) | quando ML é a resposta e quando não é |

## Coleta e integração

| # | Capítulo | Cobre |
|---|---|---|
| 3 | [20 — Coleta e Integração](../capitulos/20-coleta-integracao.md) | formatos, APIs, scraping, SQL e NoSQL, data lake e warehouse, bases públicas |

## Limpeza e pré-processamento

| # | Capítulo | Cobre |
|---|---|---|
| 4 | [02 — Qualidade e Vazamento](../capitulos/02-dados.md) | nulos, duplicatas, ficha de dataset, viés de seleção, e o vazamento |
| 5 | [03 — Representação](../capitulos/03-representacao.md) | codificação, normalização, padronização, engenharia de atributos |

## Visualização e comunicação

| # | Capítulo | Cobre |
|---|---|---|
| 6 | [21 — Análise Exploratória](../capitulos/21-analise-exploratoria.md) | estatística descritiva, dispersão, correlação, outliers |
| 7 | [22 — Visualização e Storytelling](../capitulos/22-visualizacao-storytelling.md) | escolha do gráfico, distorções visuais, narrativa de dados |

## Uma primeira passada por modelagem

| # | Capítulo | Cobre |
|---|---|---|
| 8 | [01 — Fundamentos](../01-fundamentos.md) | generalização, viés e variância |
| 9 | [04 — Avaliação](../capitulos/04-avaliacao.md) | métricas, e por que acurácia engana |
| 10 | [05 — Modelos Lineares](../capitulos/05-modelos-lineares.md) | o primeiro modelo, interpretável — com o laboratório de mínimos quadrados |

## Prática

Etapas **00** e **02** do [`ml-zero`](../trilha-ml-zero.md) — linha de base, divisões honestas e a ficha de dataset como portão executável. Ambas em Python puro, sem instalar nada além do pytest.

---

# Trilha `ml-zero` — a construção prática

> Documento de **referência**: o mapa das etapas e as regras da construção. O passo a passo de cada etapa (tutorial) vive em [`ml-zero/`](../ml-zero/README.md).

## O que é

Um sistema de Machine Learning completo, construído do zero, **uma etapa por capítulo**: do dado bruto ao modelo servido por API e monitorado.

No vocabulário do 4C/ID, as etapas são as *learning tasks* — tarefas inteiras, não fragmentos. Os capítulos são a informação de apoio; os exercícios são o treino de parte. É por isso que a etapa vem depois do capítulo, e não como apêndice dele: só a tarefa inteira ensina a coordenar o que as partes ensinaram isoladamente.

## As cinco regras da construção

Da [constituição](../.specify/memory/constitution.md), seção "Restrições da construção":

1. **Do zero antes da biblioteca.** Todo algoritmo central é implementado uma vez em NumPy, com o mínimo para funcionar, *antes* de aparecer a chamada de uma linha do scikit-learn ou do PyTorch. Você precisa ver o motor antes de dirigir o carro. Depois de ver, dirigir é legítimo — e a etapa seguinte usa a biblioteca sem culpa.
2. **Arquitetura por refatoração.** Cada porta (dados, modelo, avaliação, serviço) nasce da **dor** da etapa correspondente. Nunca estrutura antecipada: uma abstração criada antes da segunda implementação é adivinhação.
3. **Anti-apodrecimento.** Dependências mínimas e fixadas; etapas autocontidas e executáveis; erros didáticos deliberados **comentados como tal** no código — para que ninguém copie um antipadrão achando que é padrão.
4. **Reprodutibilidade.** *Seed* fixa, versões declaradas, dataset obtido por script versionado. Rodar duas vezes dá o mesmo número — ou o texto explica por que não dá.
5. **Serviço desde cedo.** O modelo vira endpoint (Python + FastAPI) já nas primeiras etapas. Um modelo que não serve ninguém é um exercício, não um sistema.

E, atravessando tudo, o Princípio VI: **custo zero é requisito**. Toda etapa roda em CPU, numa máquina modesta ou num *notebook* gratuito. Onde a GPU mudaria o resultado, o texto diz isso e oferece o caminho barato.

## O mapa das etapas

| Etapa | Capítulo | O que se constrói | A dor que ela resolve |
|---|---|---|---|
| **00** | 01 | Carregar dados, dividir com seed fixa, treinar a linha de base trivial | "não sei contra o que comparar" |
| **01** | 04 | Métricas do zero: matriz de confusão, precisão, revocação, F1, AUC-PR, bootstrap | "a acurácia parecia boa" |
| **02** | 02 | Pipeline de dados com detecção de vazamento e split por grupo/tempo | "o resultado estava bom demais" |
| **03** | 03 | Codificação de categóricas, escalas, atributos de domínio | "o modelo não enxerga o que importa" |
| **04** | 04 | Comparação pareada com intervalo de confiança | "melhorou de 0,912 para 0,918" |
| **05–06** | 05, 28 e 06 | Linear e logística + o otimizador isolado, à mão | "chamei `fit()` e não sei o que aconteceu" · "a perda não desce" |
| **07** | 07 | Árvore, bagging e boosting; o experimento tabular do capítulo | "por que boosting ganha aqui?" |
| **08** | 08 | k-means e PCA, com o critério de escolha de k declarado | "achei grupos, e daí?" |
| **09** | 09 | Rede densa em NumPy: forward, backprop, update | "backprop é mágica" |
| **10** | 10 | Convolução e transferência de aprendizado, em CPU | "não tenho GPU" |
| **11** | 11 | Atenção implementada à mão sobre uma tarefa mínima | "atenção é uma fórmula que eu decorei" |
| **12** | 12 | Embeddings e busca semântica — contra a linha de base por termos deste próprio livro | "RAG resolve tudo?" |
| **13** | 13 | Q-learning tabular num ambiente mínimo | "recompensa é só uma variável?" |
| **14** | 14 | Explicação de decisão e métricas por subgrupo | "por que o modelo negou?" |
| **15** | 16 | Serviço FastAPI com contrato, validação de entrada e versão de modelo | "funcionava no notebook" |
| **16** | 16 | Telemetria de predições e detecção de drift | "quando eu ia saber que quebrou?" |

## O andaime, e como ele diminui

O *fading* do 4C/ID é explícito na trilha:

- **Etapas 00–04**: o código vem quase pronto; você completa lacunas marcadas e explica o que aconteceu. *Completion problems*, no sentido de Sweller.
- **Etapas 05–09**: você implementa o algoritmo, com a assinatura das funções e os testes dados. Os testes são o andaime que resta.
- **Etapas 10–16**: você recebe o requisito e o critério de aceite. O desenho é seu.

Se em algum ponto a etapa parecer fácil demais, ela provavelmente está — pule para a próxima. Se parecer impossível, o capítulo correspondente não terminou; volte a ele. Essa é a leitura correta do desconforto, e é deliberada.

## Estado atual

| Etapa | Estado |
|---|---|
| 00 — dado e linha de base | ✅ pronta e testada (17 testes) |
| 02 — pipeline de dados e vazamento | ✅ pronta e testada (28 testes) |
| 05–06 — lineares e o otimizador | ✅ pronta e testada (22 testes) |
| 07 — árvore, floresta e boosting | ✅ pronta e testada (21 testes) |
| 01, 03, 04, 08–16 | 🚧 entram pelo ciclo spec-driven, uma etapa por spec |

Cada etapa nova é uma spec (Princípio VII), com plano, tarefas e verificação — e o capítulo correspondente só sai do estado de esqueleto quando sua etapa roda.

## Como rodar

```bash
cd ml-zero
python -m venv .venv && source .venv/bin/activate   # Windows: .venv\\Scripts\\activate
pip install -r requirements.txt
python -m pytest -q          # todas as etapas: os testes são o gabarito
python etapa-00/rodar.py     # a etapa 00, do começo ao fim
```

Sem internet, sem chave, sem GPU. Se algum comando acima pedir qualquer uma das três, é bug — [abra uma issue](https://github.com/GHDaru/machinelearning/issues).

---

# Banco de Exercícios — sintaxe, tipos e como a correção funciona

> Documento de **referência** (Diátaxis). O *porquê* está na constituição (Princípio VIII); o *como escrever bem* está no [Guia Editorial §4](GUIA-EDITORIAL.md). Aqui está a mecânica.

## Por que a correção mora no servidor

A página que você lê **não conhece a resposta certa**. Quando você clica em "Responder", a resposta viaja até o backend do livro, que corrige, explica e devolve o feedback.

Três razões, nesta ordem:

1. **Feedback melhor.** O servidor sabe quantas vezes você já tentou. Na primeira tentativa errada ele explica o conceito e devolve você à seção certa; só na segunda revela a resposta esperada. Um gabarito embutido no HTML não consegue esperar.
2. **A avaliação por rubrica só existe lá.** Respostas abertas são avaliadas contra critérios escritos pelo autor — isso exige um modelo, e um modelo exige um servidor.
3. **O erro é o sinal mais valioso deste projeto.** Saber qual exercício erra mais, e com que resposta, é o que corrige o livro. Exercício com taxa de acerto muito baixa é sintoma de texto mal escrito — e entra na fila de revisão (Guia §10).

O livro é aberto: quem quiser ver o gabarito acha no repositório. Não estamos escondendo — estamos evitando que a resposta esteja a um `Ctrl+U` de distância no momento em que você deveria estar pensando.

**Sem backend configurado**, o exercício continua legível e diz isso honestamente. O livro nunca finge ter corrigido.

## Onde os exercícios vivem

**Dentro do Markdown do capítulo**, junto do conteúdo que eles testam — não num arquivo separado. Isso garante que exercício e texto envelheçam juntos.

O motor faz dois recortes do mesmo bloco:

| Consumidor | O que recebe |
|---|---|
| `publicar/build.mjs` → a página | enunciado + alternativas, **sem** marcação de correta, **sem** feedback |
| `publicar/exercicios.mjs` → `banco.json` → o backend | tudo, inclusive gabarito, feedback e rubrica |

A fonte única da sintaxe é [`publicar/interativos.mjs`](../publicar/interativos.mjs).

## Sintaxe

Um bloco começa com `:::exercicio` seguido de atributos JSON e termina com `:::`.

```markdown
:::exercicio {"id":"04-e1","tipo":"multipla","objetivo":"O2","dificuldade":"media"}
Numa base de detecção de fraude com 0,3% de casos positivos, um modelo atinge
99,5% de acurácia. Qual leitura é correta?

- [ ] O modelo é excelente: erra menos de 1 em 200.
- [x] O número não diz nada: prever "não é fraude" sempre já daria 99,7%.
- [ ] A acurácia é inválida para problemas binários.

> **gabarito:** O número não diz nada
> **porque:** Com 0,3% de positivos, a classe majoritária sozinha entrega 99,7% de
> acurácia — o modelo com 99,5% está **abaixo** do classificador que não faz nada.
> Acurácia mede acertos totais e, quando uma classe domina, ela mede sobretudo a
> prevalência. Para esse caso, olhe precisão e revocação da classe rara.
> **volte para:** #a-linha-de-base-que-voce-precisa-bater
:::
```

### Atributos

| Atributo | Obrigatório | O que é |
|---|---|---|
| `id` | sim | único no livro inteiro. Convenção: `NN-eK` (capítulo, exercício). Duplicata quebra o build. |
| `tipo` | sim | `multipla`, `multipla-multi`, `numerica`, `completar`, `aberta` |
| `objetivo` | sim | o `O1`/`O2`… declarado na seção Objetivos do capítulo. O build confere que existe. |
| `pontos` | não | peso (default 1) |
| `dificuldade` | não | `facil`, `media`, `dificil` (default `media`) |
| `versoes` | não | quando o gabarito depende de versão: `{"scikit-learn":"1.5"}` (Princípio IV) |

### Metadados do rodapé

Linhas de citação `> **chave:** valor`, aceitando continuação em múltiplas linhas.

| Chave | Quando | O que faz |
|---|---|---|
| `gabarito` | numérica, completar | a resposta esperada |
| `porque` | **sempre** | o feedback explicativo. Sem ele o build falha. |
| `volte para` | recomendado | âncora da seção que resolve a dúvida (`#slug-do-titulo`) |
| `rubrica` | aberta | critérios separados por `;` ou um por linha; mínimo 2 |

## Os cinco tipos

### `multipla` — escolha uma

Exatamente uma alternativa marcada com `[x]`. Mínimo duas alternativas.

### `multipla-multi` — escolha todas que valem

Uma ou mais corretas. Marcar um subconjunto das corretas (sem marcar nenhuma errada) conta como **parcial** — o leitor vê "◐ parcialmente" e é convidado a completar.

### `numerica` — responda com um número

O gabarito aceita tolerância explícita:

```markdown
> **gabarito:** 0.80 ± 0.01
```

Sem tolerância declarada, exige-se o valor exato. A resposta é lida de forma tolerante a formato: `0,80`, `0.80` e `80%` chegam ao mesmo lugar. Fora da tolerância mas dentro do dobro dela (ou de 10%, quando a tolerância é zero), o resultado é **parcial** — o leitor errou a conta, não o conceito.

### `completar` — complete a lacuna

*Completion problem* no sentido de Sweller: o andaime está posto, falta a peça. Alternativas aceitas separadas por `|`. A comparação ignora caixa, acentos e espaços extras.

```markdown
:::exercicio {"id":"06-e2","tipo":"completar","objetivo":"O3"}
Complete o termo que impede os pesos de crescerem sem limite:

`perda_total = perda_de_dados + λ · ______(w)`

> **gabarito:** regularização|regularizacao|penalidade
> **porque:** O segundo termo penaliza a complexidade do modelo...
:::
```

### `aberta` — responda com suas palavras

Avaliada pelo modelo **contra a rubrica escrita pelo autor** — nunca contra "o que o modelo acha que é uma boa resposta". O leitor recebe a lista de critérios com ✔ e ○, e um comentário curto.

```markdown
:::exercicio {"id":"01-e3","tipo":"aberta","objetivo":"O4","pontos":3}
Explique, para uma pessoa de produto, por que um modelo com 99% de acurácia
no teste pode falhar no primeiro mês em produção.

> **rubrica:** distingue distribuição de treino e de produção;
> menciona ao menos um mecanismo concreto (drift, vazamento, viés de seleção);
> não atribui a falha a "pouco dado" sem justificar;
> propõe uma forma de detectar o problema antes do usuário
> **porque:** O ponto central é que a métrica de teste só vale sob a hipótese de
> que produção se parece com o teste...
:::
```

Sem modelo configurado, a rota devolve uma avaliação honesta-vazia: diz que não avaliou, e lembra os critérios. **Nunca inventa uma nota.**

## Vídeos

```markdown
:::video {"id":"04-v1","fonte":"youtube","ref":"4jRBRDbJemM","min":16,"autor":"StatQuest","titulo":"ROC and AUC, clearly explained"}
Resolve a intuição **geométrica** da curva ROC — o texto trata do trade-off
algebricamente, e ver o limiar deslizando faz a moeda cair.
:::
```

| Atributo | Obrigatório | O que é |
|---|---|---|
| `id` | sim | único; convenção `NN-vK` |
| `fonte` | não | `youtube` (default) ou `vimeo` |
| `ref` | sim | o identificador do vídeo na fonte |
| `autor` | sim | crédito de quem produziu |
| `titulo` | não | título exibido (default: o `id`) |
| `min` | não | duração aproximada |

O corpo do bloco é a **justificativa obrigatória**: o que este vídeo resolve que o texto não resolve. Vídeo sem justificativa não compila.

O player é uma **fachada**: nada é pedido ao servidor de origem antes do clique do leitor.

## Laboratórios

A terceira superfície: exercício pergunta e corrige, vídeo mostra, **laboratório deixa manipular**.

```markdown
:::lab {"id":"18-l1","tipo":"neuronio-mp","titulo":"Neurônio de McCulloch–Pitts","funcao":"AND"}
O que manipular aqui ensina — e o que o leitor deve **descobrir sozinho**.
:::
```

| Atributo | Obrigatório | O que é |
|---|---|---|
| `id` | sim | único no livro; convenção `NN-lK` |
| `tipo` | sim | qual widget carregar (ver tabela abaixo) |
| `titulo` | não | exibido no cabeçalho |
| *demais* | — | passados ao widget como configuração inicial |

O corpo do bloco é a **introdução obrigatória**. Laboratório sem ela não compila.

### Widgets disponíveis

| `tipo` | O que faz | Configuração |
|---|---|---|
| `neuronio-mp` | Neurônio de McCulloch–Pitts: pesos e limiar à mão, reta de decisão desenhada em tempo real sobre a tabela-verdade | `funcao`: `AND`, `OR`, `NAND`, `NOR`, `XOR` |

Novos widgets entram em `publicar/tema/laboratorios.js`, registrados no objeto `TIPOS` do fim do arquivo.

### Por que laboratório não precisa de backend

Não há resposta a esconder: o gabarito é o comportamento do objeto. Isso o torna a superfície **mais robusta** do livro — funciona offline, funciona sem servidor, e continua funcionando quando tudo o mais falha.

## Progresso do leitor

- Identidade **anônima**, gerada pelo navegador — a mesma do chat. Sem cadastro, sem email.
- Espelhada em `localStorage`, para a barra de progresso funcionar mesmo offline.
- `GET /progresso?session_id=…` devolve o que aquela sessão resolveu.
- `DELETE /session/{id}` apaga tudo — conversas, tentativas e vídeos. Direito ao esquecimento, sem pedido, sem formulário.

## Gate de qualidade

```bash
cd publicar
node exercicios.mjs --verificar   # valida sem escrever nada (é o gate da CI)
node exercicios.mjs               # gera chat-companion/backend/banco.json
```

O gate falha quando:

- falta `id`, `tipo`, `objetivo`, enunciado ou `porque`;
- o `objetivo` não existe entre os declarados no capítulo;
- múltipla escolha não tem exatamente uma correta;
- numérica tem gabarito ilegível;
- aberta tem menos de 2 critérios;
- há `id` de exercício ou de vídeo duplicado;
- vídeo sem `ref`, sem `autor` ou sem justificativa.

Nenhum desses é aviso. Todos são erro de build — porque um exercício quebrado é pior que exercício nenhum.

---

# Videoteca

> Curadoria de vídeos por capítulo. A **fonte** de cada vídeo é o bloco `:::video` do capítulo que ele serve — é lá que ele vive, junto do texto que complementa. Esta página reúne a política e um índice **mantido à mão**; quem adiciona um vídeo atualiza os dois lugares. (Gerar o índice a partir do `banco.json` é melhoria devida: enquanto não for, ele pode ficar atrasado, e dizer isso é mais honesto do que fingir automação.)

## A política de curadoria

Um vídeo entra por aquilo que **o texto não faz bem**: geometria animada, uma derivação no ritmo do quadro, o som de alguém pensando em voz alta. Se o vídeo apenas repete o capítulo, ele não entra — repetição não é reforço, é ruído.

Cada vídeo declara:

| Campo | Por quê |
|---|---|
| **Autor** | Crédito. Curadoria sem atribuição é apropriação |
| **Duração** | O leitor decide se cabe agora. Vídeo sem duração declarada é um compromisso em branco |
| **O que resolve** | Obrigatório. Se você não consegue escrever esta frase, o vídeo não deveria entrar |

Regras adicionais, do [Guia Editorial §5](GUIA-EDITORIAL.md):

- **Gratuito e estável.** Vídeo atrás de paywall não entra — custo zero é requisito (Princípio VI).
- **Reconferido a cada janela trimestral.** Link morto é dívida do livro, não do leitor.
- **Fachada por padrão.** O player só pede o vídeo ao servidor de origem **depois** do clique. Antes disso, nenhuma requisição sai do seu navegador para terceiros.

## Índice

| Capítulo | Vídeo | Autor | Duração |
|---|---|---|---|
| 00 — Introdução | A Gentle Introduction to Machine Learning | StatQuest with Josh Starmer | ~6 min |
| 01 — Fundamentos | Machine Learning Fundamentals: Bias and Variance | StatQuest with Josh Starmer | ~7 min |
| 02 — Dados | Machine Learning Fundamentals: Cross Validation | StatQuest with Josh Starmer | ~6 min |
| 04 — Avaliação | ROC and AUC, Clearly Explained! | StatQuest with Josh Starmer | ~16 min |
| 05 — Modelos Lineares | StatQuest: Logistic Regression | StatQuest with Josh Starmer | ~9 min |
| 06 — Otimização | Gradient Descent, Step-by-Step | StatQuest with Josh Starmer | ~24 min |
| 07 — Árvores e Ensembles | Gradient Boost Part 1: Regression Main Ideas | StatQuest with Josh Starmer | ~15 min |

> Os capítulos-esqueleto ainda não têm vídeo — cada um recebe o seu quando sua spec for implementada (mínimo 1 por capítulo, Princípio VIII.1). Sugestões de vídeo são bem-vindas pelo próprio companion do livro (botão 💬 → Sugerir).

## Quando não há vídeo: o laboratório

A constituição (1.1.0) aceita um **laboratório interativo** no lugar do vídeo quando não houver material verificável para o tema. A ordem de preferência é essa mesma: vídeo se existir e for conferível; laboratório se o assunto for manipulável; nunca uma referência inventada para preencher cota.

| Capítulo | Laboratório | O que o leitor descobre |
|---|---|---|
| 18 — O Neurônio Artificial | Neurônio de McCulloch–Pitts | que o XOR é impossível com um neurônio só — travando em 3 de 4 |

## Marcar como assistido

Cada vídeo tem uma caixa "marcar como assistido". Ela alimenta a barra de progresso do capítulo e o seu registro anônimo de progresso — o mesmo que guarda os exercícios resolvidos. Como todo o resto: sem cadastro, e apagável a qualquer momento em uma ação.

---

# Bibliografia

> Referências do livro, por capítulo, **com status de validação**. O status não é decoração: o Princípio I exige que toda citação científica esteja conferida contra a fonte primária antes de sustentar uma afirmação no corpo do texto.

## Legenda de status

| Símbolo | Significado |
|---|---|
| ✓ | **Verificado** — identificador (DOI/arXiv), autoria e ano conferidos na fonte primária, com a data da conferência registrada |
| ⏳ | **A conferir** — a referência está na fila; **não pode** sustentar afirmação no corpo até virar ✓ |
| ⚠ | **Contestada** — o resultado citado é disputado na literatura; o texto deve dizer isso |

Uma referência ⏳ pode aparecer numa lista de leitura, nunca como evidência de uma afirmação. Essa distinção é o que separa uma bibliografia de uma lista de coisas que parecem certas.

> **Esta legenda e a dos capítulos respondem a perguntas diferentes.** Aqui a pergunta é *"esta referência pode sustentar uma afirmação?"* (Princípio I). Na seção "De onde isto veio" de cada capítulo, a pergunta é mais fina — *"o que exatamente eu conferi desta obra?"* — e a legenda tem cinco selos (✓ · ✓ᵐ · ⏳ · ❌ · 📖), definidos no Princípio X.
>
> A tradução entre as duas é estrita, e sempre na direção conservadora: **um ✓ desta página conferido só por DOI/identificador vale como ✓ᵐ no capítulo.** Metadado prova que a obra existe, quem assina e quando saiu; não prova o que ela afirma por dentro. Onde a nota de verificação abaixo diz "(Crossref)", foi isso — e só isso — que se conferiu.

> **Por que tantos ⏳ nesta edição.** Este livro nasceu em 2026-08 com a maquinaria pronta e o conteúdo em construção. As referências marcadas ⏳ são as que os capítulos-esqueleto vão precisar; elas entram no fluxo de verificação (skill `academic-research`) junto com a spec do capítulo correspondente. Publicar a lista antes de conferi-la é honesto; usá-la antes de conferi-la não seria.

---

## Método pedagógico (transversal — Princípio III)

- ✓ **Sweller, J. (1988).** Cognitive Load During Problem Solving: Effects on Learning. *Cognitive Science*, 12(2), 257–285. [doi:10.1207/s15516709cog1202_4](https://doi.org/10.1207/s15516709cog1202_4) — *verificado em 2026-08-01.* Origem do princípio de *worked examples* antes de exercício, que define o formato da seção "Pratique".
- ✓ **van Merriënboer, J. J. G., Clark, R. E., & de Croock, M. B. M. (2002).** Blueprints for complex learning: The 4C/ID-model. *ETR&D*, 50, 39–64. [doi:10.1007/BF02504993](https://doi.org/10.1007/BF02504993) — *verificado em 2026-08-01.* Fundamenta a relação entre a trilha `ml-zero` (tarefas inteiras) e os capítulos (informação de apoio).
- ✓ **Procida, D.** Diátaxis: A systematic framework for technical documentation authoring. [diataxis.fr](https://diataxis.fr/) — *verificado em 2026-08-01.* A regra de "um tipo de texto por seção".
- ⏳ **Wiggins, G., & McTighe, J. (2005).** *Understanding by Design*, 2ª ed. ASCD. — Backward Design; conferir edição e ISBN.

## Capítulo 01 — Fundamentos

- ✓ **Belkin, M., Hsu, D., Ma, S., & Mandal, S. (2019).** Reconciling modern machine-learning practice and the classical bias–variance trade-off. *PNAS*, 116(32), 15849–15854. [doi:10.1073/pnas.1903070116](https://doi.org/10.1073/pnas.1903070116) — *verificado em 2026-08-01.* Sustenta a advertência de que a intuição viés–variância não é lei universal no regime superparametrizado (*double descent*).
- ⏳ **Vapnik, V. (1999).** *The Nature of Statistical Learning Theory*. Springer. — Base formal da minimização do risco empírico.
- ⏳ **Hastie, T., Tibshirani, R., & Friedman, J. (2009).** *The Elements of Statistical Learning*, 2ª ed. Springer. — Referência canônica da decomposição viés–variância.

## Capítulo 02 — Dados

- ✓ **Gebru, T., Morgenstern, J., Vecchione, B., Wortman Vaughan, J., Wallach, H., Daumé III, H., & Crawford, K. (2021).** Datasheets for Datasets. *Communications of the ACM*, 64(12), 86–92. [doi:10.1145/3458723](https://doi.org/10.1145/3458723) — *verificado em 2026-08-05.* Origem da prática de ficha de dataset; o capítulo 02 adota uma versão mínima de sete perguntas e a torna executável (`FichaDeDataset`).
- ⏳ **Kaufman, S., Rosset, S., Perlich, C., & Stitelman, O. (2012).** Leakage in Data Mining: Formulation, Detection, and Avoidance. *ACM TKDD*. — A formulação de referência do vazamento. **Prioridade**: sustentaria a taxonomia das três fontes, hoje apresentada como síntese própria.

## Capítulo 04 — Avaliação

- ⏳ **Saito, T., & Rehmsmeier, M. (2015).** The Precision-Recall Plot Is More Informative than the ROC Plot When Evaluating Binary Classifiers on Imbalanced Datasets. *PLOS ONE*. — Sustenta a recomendação de AUC-PR para classes raras. **Prioridade de verificação**: esta referência sustenta uma recomendação já publicada no capítulo-piloto.
- ⏳ **Niculescu-Mizil, A., & Caruana, R. (2005).** Predicting Good Probabilities with Supervised Learning. *ICML*. — Calibração como propriedade independente do ranking.
- ⏳ **Efron, B., & Tibshirani, R. (1993).** *An Introduction to the Bootstrap*. Chapman & Hall. — O intervalo de confiança recomendado na seção de incerteza.

## Capítulo 07 — Árvores e Ensembles

- ✓ **Breiman, L. (2001).** Random Forests. *Machine Learning*, 45, 5–32. [doi:10.1023/A:1010933404324](https://doi.org/10.1023/A:1010933404324) — *verificado em 2026-08-05.* Sustenta a afirmação de que a subamostragem de atributos existe para descorrelacionar as árvores, e não apenas para acelerar.
- ✓ **Grinsztajn, L., Oyallon, E., & Varoquaux, G. (2022).** Why do tree-based models still outperform deep learning on tabular data? *NeurIPS 2022, Datasets and Benchmarks Track*. [arXiv:2207.08815](https://arxiv.org/abs/2207.08815) — *verificado em 2026-08-05.* Benchmark de 45 datasets; sustenta que modelos de árvore permanecem no estado da arte em tabular de porte médio (~10 mil exemplos) e identifica os três mecanismos (atributos não informativos, funções irregulares, orientação dos eixos).
- ⏳ **Chen, T., & Guestrin, C. (2016).** XGBoost: A Scalable Tree Boosting System. *KDD*. — Boosting moderno; entra quando o capítulo 16 tratar da biblioteca de produção.
- ⏳ **Friedman, J. (2001).** Greedy Function Approximation: A Gradient Boosting Machine. *Annals of Statistics*. — A formulação original do gradient boosting.

## Capítulo 18 — O Neurônio Artificial

- ✓ **McCulloch, W. S., & Pitts, W. (1943).** A logical calculus of the ideas immanent in nervous activity. *Bulletin of Mathematical Biophysics*, 5, 115–133. [doi:10.1007/BF02478259](https://doi.org/10.1007/BF02478259) — *verificado em 2026-08-08.* O modelo de neurônio que o capítulo 18 e o laboratório implementam.
- ✓ **Rosenblatt, F. (1958).** The perceptron: A probabilistic model for information storage and organization in the brain. *Psychological Review*, 65(6), 386–408. [doi:10.1037/h0042519](https://doi.org/10.1037/h0042519) — *verificado em 2026-08-08 (Crossref).* A regra de aprendizado que o `Perceptron` da etapa 18 implementa, e a prova de convergência para problemas separáveis.
- ⏳ **Minsky, M., & Papert, S. (1969).** *Perceptrons*. MIT Press. — A demonstração da limitação do XOR. Livro sem DOI; conferir edição e ISBN na fonte da editora.
- ⏳ **Hebb, D. O. (1949).** *The Organization of Behavior*. Wiley. — "Neurônios que disparam juntos, conectam-se juntos."
- ✓ **Fukushima, K. (1980).** Neocognitron: A self-organizing neural network model for a mechanism of pattern recognition unaffected by shift in position. *Biological Cybernetics*, 36, 193–202. [doi:10.1007/BF00344251](https://doi.org/10.1007/BF00344251) — *verificado em 2026-08-08 (Crossref).* **Atenção à data:** o DOI registra **1980** (versão em inglês); a publicação japonesa original é de 1979. O capítulo 18 traz as duas datas por isso.
- ⏳ **Linnainmaa, S. (1970).** *Alqoritmin kumulatiivinen pyöristysvirhe…* Dissertação de mestrado, Univ. de Helsinque. — A prioridade do modo reverso da diferenciação automática. Sem DOI e em finlandês; o capítulo 18 a cita **como nota de cronologia**, não como evidência de afirmação técnica.
- ⏳ **Werbos, P. (1974).** *Beyond Regression*. Tese de doutorado, Harvard. — A primeira aplicação do método a redes neurais.

## Capítulos 09–11 — Redes, visão e sequências

- ✓ **Rumelhart, D. E., Hinton, G. E., & Williams, R. J. (1986).** Learning representations by back-propagating errors. *Nature*, 323, 533–536. [doi:10.1038/323533a0](https://doi.org/10.1038/323533a0) — *verificado em 2026-08-08 (Crossref).* O trabalho que **popularizou** o backpropagation; a nota de prioridade do capítulo 18 se apoia nele.
- ⏳ **He, K. et al. (2016).** Deep Residual Learning for Image Recognition. *CVPR*.
- ⏳ **Vaswani, A. et al. (2017).** Attention Is All You Need. *NeurIPS*.

## Capítulo 12 — Modelos de fundação

- ⏳ **Lewis, P. et al. (2020).** Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. *NeurIPS*.
- ⏳ **Bommasani, R. et al. (2021).** On the Opportunities and Risks of Foundation Models.

## Capítulo 14 — Interpretabilidade e justiça

- ⏳ **Lundberg, S., & Lee, S.-I. (2017).** A Unified Approach to Interpreting Model Predictions. *NeurIPS*. — SHAP.
- ⏳ **Ribeiro, M. T., Singh, S., & Guestrin, C. (2016).** "Why Should I Trust You?": Explaining the Predictions of Any Classifier. *KDD*. — LIME.
- ⏳ **Kleinberg, J., Mullainathan, S., & Raghavan, M. (2017).** Inherent Trade-Offs in the Fair Determination of Risk Scores. *ITCS*. — O teorema de impossibilidade citado no capítulo.
- ⏳ **Mitchell, M. et al. (2019).** Model Cards for Model Reporting. *FAT\**.

## Capítulos 15–16 — Sistemas e MLOps

- ✓ **Sculley, D. et al. (2015).** Hidden Technical Debt in Machine Learning Systems. *NIPS 2015*, 2503–2511. [papers.nips.cc/paper/5656](https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems) — *verificado em 2026-08-01.* O diagnóstico de que o modelo é a fração pequena do sistema.
- ⏳ **Breck, E. et al. (2017).** The ML Test Score: A Rubric for ML Production Readiness. *IEEE Big Data*.
- ⏳ **Gama, J. et al. (2014).** A Survey on Concept Drift Adaptation. *ACM Computing Surveys*.

---

## Como adicionar uma referência

1. Localize a fonte primária (editora, arXiv, DOI). Não aceite o resumo de terceiros como confirmação.
2. Confira **autoria, ano, veículo e identificador** — os quatro, não apenas o título.
3. Registre aqui com o status ✓ e **a data da conferência**.
4. Só então use a referência para sustentar uma afirmação no corpo.

O fluxo completo está na skill [`academic-research`](../.claude/skills/academic-research/SKILL.md). A razão de tanto rigor é medida: modelos de linguagem fabricam citações plausíveis com frequência alta, e uma referência inventada num livro técnico contamina tudo o que ela sustenta.

---

# Glossário

> Espelho do mapa de siglas do motor de publicação (`publicar/build.mjs`). Ao introduzir uma sigla nova, adicione-a **nos dois lugares** — e confira a expansão na fonte (Princípio I). No site, passar o mouse sobre qualquer sigla revela a expansão em qualquer ocorrência.

## Termos fundamentais

| Termo | O que é |
|---|---|
| **Exemplo** (instância, observação) | Uma linha dos dados: um cliente, uma foto, uma transação |
| **Atributo** (*feature*) | Uma coluna: idade, pixel 37, contagem de palavras |
| **Alvo** (*target*, *label*) | O que se quer prever. Sua presença define o aprendizado como supervisionado |
| **Parâmetro** | O que o **treino** ajusta (pesos, vieses) |
| **Hiperparâmetro** | O que **você** escolhe antes do treino (taxa de aprendizado, profundidade, regularização) |
| **Função de perda** | O que a otimização minimiza; precisa ser bem-comportada para o otimizador |
| **Métrica** | O que interessa a você; precisa ser interpretável e ligada à consequência |
| **Generalização** | Desempenho sobre exemplos **não vistos** durante o treino. O problema central do livro |
| **Overfitting** | O modelo ajustou-se ao ruído dos dados de treino; vai bem no treino e mal fora |
| **Underfitting** | O modelo é simples demais para o padrão; erra parecido no treino e no teste |
| **Viés** (*bias*) | Erro sistemático de suposição — o modelo não consegue representar o padrão |
| **Variância** | Instabilidade — o modelo muda muito conforme a amostra de treino muda |
| **Vazamento** (*leakage*) | Informação disponível no treino que não existirá no momento da predição |
| **Drift** | Mudança na distribuição dos dados ao longo do tempo, degradando o modelo sem alterar o código |
| **Calibração** | Os escores do modelo lidos como probabilidades honestas: quando diz 0,8, acontece 80% das vezes |
| **Linha de base** (*baseline*) | O desempenho do classificador trivial. Piso contra o qual todo modelo se mede |

## Siglas

| Sigla | Por extenso | Onde aparece |
|---|---|---|
| **ML** | Machine Learning | transversal |
| **IID** | Independent and Identically Distributed | 01, 11 |
| **ERM** | Empirical Risk Minimization | 01 |
| **PAC** | Probably Approximately Correct | 01 |
| **MSE / MAE / RMSE / MAPE** | Mean Squared / Absolute / Root Mean Squared / Absolute Percentage Error | 04, 05 |
| **AUC / ROC** | Area Under the Curve / Receiver Operating Characteristic | 04 |
| **SGD** | Stochastic Gradient Descent | 06, 09 |
| **PCA** | Principal Component Analysis | 08 |
| **KNN** | K-Nearest Neighbors | 03, 08 |
| **SVM** | Support Vector Machine | 05 |
| **MLP** | Multi-Layer Perceptron | 09 |
| **CNN** | Convolutional Neural Network | 10 |
| **RNN / LSTM / GRU** | Recurrent Neural Network / Long Short-Term Memory / Gated Recurrent Unit | 11 |
| **NLP** | Natural Language Processing | 11, 12 |
| **LLM** | Large Language Model | 12 |
| **RAG** | Retrieval-Augmented Generation | 12 |
| **BERT / GPT** | Bidirectional Encoder Representations from Transformers / Generative Pre-trained Transformer | 11, 12 |
| **RL / MDP / PPO / RLHF / DQN** | Reinforcement Learning / Markov Decision Process / Proximal Policy Optimization / RL from Human Feedback / Deep Q-Network | 13 |
| **SHAP / LIME** | SHapley Additive exPlanations / Local Interpretable Model-agnostic Explanations | 14 |
| **MLOps** | Machine Learning Operations | 15, 16 |
| **ETL** | Extract, Transform, Load | 02, 15 |
| **API / SDK / CLI** | Application Programming Interface / Software Development Kit / Command-Line Interface | 15, 16 |
| **CPU / GPU / TPU** | Central / Graphics / Tensor Processing Unit | 09, 10 |
| **LGPD** | Lei Geral de Proteção de Dados | 02, 14 |
| **NLL / KL / ELBO** | Negative Log-Likelihood / Kullback-Leibler / Evidence Lower Bound | 06, 08 |
| **IQR** | Interquartile Range — intervalo interquartil (Q3 − Q1) | 21 |

## Acrescentados na edição 1.0

- **ARIMA** — *AutoRegressive Integrated Moving Average*. Família de modelos de série temporal com três peças: autorregressivo (o passado prevê o presente), integrado (diferenciar para estabilizar) e média móvel (o erro passado também informa). Capítulo 24.
- **ACF / PACF** — *Autocorrelation / Partial Autocorrelation Function*. Funções de autocorrelação e autocorrelação parcial — as ferramentas de diagnóstico que dizem quantas defasagens o modelo precisa. Capítulo 24.
- **OLAP** — *Online Analytical Processing*. Análise multidimensional sobre cubos: dimensões, medidas e agregação pré-computada. Contrasta com OLTP, o processamento transacional. Capítulo 23.
- **OLTP** — *Online Transaction Processing*. O sistema otimizado para registrar, não para perguntar. A tensão entre ele e a análise é a origem do data warehouse. Capítulo 20.
- **ELT** — *Extract, Load, Transform*. Inversão do ETL: carrega-se primeiro e transforma-se depois, viável quando armazenamento ficou barato. Capítulo 20.
- **EDA** — *Exploratory Data Analysis*. Análise exploratória de dados — a tradição que Tukey nomeou em 1962 e sistematizou em 1977. Capítulo 21.
- **CRISP-DM** — *CRoss-Industry Standard Process for Data Mining*. O ciclo de seis fases publicado em 1999. 'Cross-industry' é a tese: o processo não pertence a um setor nem a um fornecedor. Capítulo 19.
- **CART** — *Classification and Regression Trees*. As árvores de Breiman, Friedman, Olshen e Stone (1984), nascidas da consultoria e não do seminário. Capítulo 07.
- **TF-IDF** — *Term Frequency – Inverse Document Frequency*. Peso que combina a frequência do termo no documento com a raridade dele na coleção. Spärck Jones inventou o IDF em 1972; Salton e Yang o nomearam. Capítulo 03.

---

# Guia Editorial — regras operacionais do livro

> Versão operacional das orientações pedagógicas. A lei está na [constituição](../.specify/memory/constitution.md); este guia é o que se consulta **enquanto escreve**.

## 1. O framework pedagógico em quatro linhas

| Framework | O que dita no livro |
|---|---|
| **Backward Design** | Todo capítulo se projeta de trás para frente: objetivos → evidências (exercícios/verificação) → só então o conteúdo |
| **4C/ID** | Etapas do `ml-zero` = tarefas inteiras; capítulos = informação de apoio; boxes no código = just-in-time; exercícios = treino de parte |
| **Diátaxis** | Quatro tipos de texto, nunca misturados na mesma seção: capítulo=explanation, `ml-zero`=tutorial, banco/fichas=reference, receitas=how-to |
| **Carga Cognitiva** | Worked example antes do exercício; exercícios são "complete", não "crie do zero"; andaime diminui capítulo a capítulo; uma ideia nova por vez |

## 2. Esqueleto v5 de capítulo (obrigatório)

O v5 é o v4 **mais a seção histórica** que o Princípio X tornou obrigatória. O v4, por sua vez, era o esqueleto v3 do livro de Engenharia de Harness mais as duas seções de interatividade. A ordem não é decorativa: ela é o Backward Design tornado sumário.

1. **Objetivos de aprendizagem** — 3–5, verbos de Bloom (explicar, comparar, implementar, avaliar), numerados `**O1.**`, `**O2.**`… Os identificadores são reais: cada exercício aponta para um deles, e o build falha se apontar para um que não existe.
2. **O problema** — por que este assunto existe. Comece pelo erro que alguém comete sem ele.
3. **De onde isto veio** — a história do método, em cinco elementos: **o aperto** (quem estava preso, em quê, quando) · **o que se fazia antes** · **a virada** (a ideia que destravou, sem notação) · **a ideia reaproveitável** (o padrão que serve fora deste método) · **o nome**. Fecha com a **tabela de selos** (✓ / ✓ᵐ / ⏳ / ❌ / 📖). Ver §2.4 e o Princípio X.
4. **Fundamentos** — a intuição, depois a matemática, depois o código. Nunca a fórmula sozinha.
5. **Fundamentos científicos** — 2–4 papers *traduzidos para decisões* ("o resultado X significa que, na prática, você deve Y"); ponteiro para `bibliografia.md`.
6. **O estado da arte** — o que é consenso hoje, o que está em disputa, e a **cláusula de expiração** do capítulo.
7. **Mão na massa** — a etapa correspondente do `ml-zero`, com o experimento que gera os números citados.
8. **Pratique** — os exercícios (mínimo 3). Ver §4.
9. **Assista** — os vídeos curados (mínimo 1) **ou** o laboratório. Ver §5 e §2.3.
10. **Síntese + "o que levar"** — leitura executiva e as ideias exportáveis para o trabalho do leitor.
11. **Verificação** — 2–3 perguntas abertas que testam exatamente os objetivos do item 1.

A posição do item 3 é a regra, não sugestão: **depois** do problema e **antes** da intuição. Antes do problema, a história não tem a que se agarrar; depois da fórmula, o leitor já pulou.

### 2.1 Cabeçalho obrigatório

```markdown
# 04 — Avaliação

> **Estado da arte capturado em 2026-08** · última revisão 2026-08-01 · [histórico](../HISTORICO.md)
```

O selo diz ao leitor se a seção "estado da arte" está fresca — o que a data de um evento citado no corpo não faz.

## 2.2 Níveis de maturidade

Todo capítulo declara seu nível no cabeçalho, logo abaixo da data. O leitor sempre sabe o que está lendo.

| Nível | Garante | Selo no cabeçalho |
|---|---|---|
| **esqueleto** | objetivos e problema | ⚠ aviso em destaque |
| **essencial** | corpo ensinável, ≥2 exercícios, síntese, verificação | nota discreta |
| **completo** | os sete itens do portão (§9) | sem aviso |

**Por que existe.** O livro serve a disciplinas em andamento: um capítulo que existe de forma honesta vale mais ao estudante do que um capítulo ausente. Mas cobertura sem rigor é o que este projeto recusa — então o nível é **declarado**, nunca silencioso. Baixar o rigor sem avisar seria fraude; declarar cria a dívida visível que o roadmap cobra.

**Como promover.** `esqueleto → essencial` é um ciclo de escrita; `essencial → completo` é um ciclo de aprofundamento (experimento próprio, fontes ✓, cláusula de expiração, revisão developmental). Cada promoção é uma spec.

## 2.3 Laboratórios interativos

A terceira superfície do livro, ao lado de exercício e vídeo:

| Superfície | O que faz | Precisa de backend? |
|---|---|---|
| **Exercício** | pergunta e corrige, com feedback que explica | **sim** |
| **Vídeo** | mostra o que a prosa não mostra | não |
| **Laboratório** | **deixa manipular** | **não** |

Um laboratório roda inteiro no navegador. Não há gabarito a esconder — o gabarito é o comportamento do próprio objeto. Isso o torna a superfície mais robusta do livro: funciona mesmo com o backend fora do ar.

**Regras de autoria:**

- O bloco declara **o que manipular ali ensina** e, sobretudo, **o que o leitor deve descobrir sozinho**. Um laboratório que explica antes de deixar brincar desperdiça o próprio mecanismo.
- Ponha o laboratório **antes** da explicação, não depois. A descoberta vem primeiro; o texto confirma e nomeia.
- Prefira laboratórios em que **o fracasso ensine**. O melhor exemplo do livro é o XOR no capítulo 18: o leitor trava em 3 de 4 e descobre a impossibilidade com as próprias mãos — o que nenhuma frase entrega.
- Quando não houver vídeo verificável para um tema, **o laboratório cumpre a cota de mídia**. Inventar uma referência para preencher cota é violação do Princípio I.

Sintaxe em [`BANCO-DE-EXERCICIOS.md`](BANCO-DE-EXERCICIOS.md); os widgets vivem em `publicar/tema/laboratorios.js`.

## 2.4 "De onde isto veio" — como se escreve

Materializa o **Princípio X**. Portão do nível `essencial`, para todo capítulo de método.

**Os cinco elementos, nesta ordem.** O aperto (quem, em quê, quando — gente e data, não "os pesquisadores") · o que se fazia antes (contra o quê o método compete) · a virada (a ideia que destravou, **em linguagem natural, sem notação**) · **a ideia reaproveitável** · o nome, se tiver origem.

**O quarto elemento é a razão de a seção existir.** Todo artifício técnico declara a ideia reaproveitável que há por trás dele: artifício sem ideia é truque, e truque não se transfere. Se você não consegue escrever esse parágrafo, ou ainda não entendeu o método, ou ele não merece capítulo.

**A tabela de selos fecha a seção.** Uma linha por afirmação histórica:

| Selo | Significa | Erro que ele previne |
|---|---|---|
| ✓ | fonte **aberta e lida** | — |
| ✓ᵐ | só os **metadados** conferidos (autor, obra, ano, DOI) | confundir *"existe e é este artigo"* com *"eu li e diz isso"* |
| ⏳ | **atribuição corrente**, não confirmada em primária | repetir o que "todo mundo diz" como se fosse conferido |
| ❌ | procurei e **não achei** | preencher a lacuna com suposição plausível |
| 📖 | **leitura editorial** deste livro | vender interpretação como fato histórico |

Conferir um DOI dá **✓ᵐ**, nunca ✓. Diferente da legenda de [`bibliografia.md`](bibliografia.md), que responde a outra pergunta ("esta referência pode sustentar uma afirmação?"): lá um ✓ conferido só por identificador equivale a ✓ᵐ aqui.

**❌ é permitido e às vezes é o melhor que há.** Exemplo real, no capítulo 18: a atribuição do backpropagation a "um italiano em 1979" não foi confirmada — o capítulo diz que procurou e não achou, e lista o que existe (Linnainmaa 1970, Werbos 1974, Fukushima 1979/80). Lacuna admitida em voz alta vale mais que suposição com cara de fato.

**Três proibições.** Gênio solitário (história ruim e geralmente falsa: métodos nascem de instituições, encomendas, prazos e restrições materiais — e é isso que ensina) · curiosidade decorativa (se o parágrafo sai sem o leitor perder compreensão ou julgamento, é enfeite) · misturar registro ("a literatura atribui a X" ≠ "X publicou em 19NN", e as duas não podem parecer iguais no texto).

**Pesquise de uma vez, não capítulo a capítulo.** A pesquisa histórica vai numa sessão própria, com nota em `estudos/` e **fila de verificação** ao final, ordenada por dúvida fechada por unidade de esforço. As histórias se conectam, e quem descobre a conexão depois já publicou os dois lados sem ela.

**Duas armadilhas.** *Resumo de busca não é fonte* — nem para confirmar nem para desmentir; um resumo pode abreviar o original a ponto de um fato **correto** parecer errado, e corrigir a partir dele introduz o erro que você achava estar consertando. *Ler a fonte também serve para achar o que você não sabia que estava lá* — as melhores histórias estão no parágrafo que ninguém resumiu.

**O teste:** o leitor termina a seção **querendo continuar**. Um livro técnico compete com a tentação de pular para a fórmula; a história é o que dá ao leitor um motivo para não pular.

## 3. Regras de escrita permanentes

- **Evidência por experimento**: toda afirmação empírica cita o script que a produziu (`ml-zero/etapa-04/experimento.py`), com dataset, *seed* e versão da biblioteca. Sem isso, é intuição — e se escreve como intuição.
- **Nenhum número sem procedência.** Nem "cerca de 90%", nem "costuma dobrar". Ou mede, ou cita, ou não afirma.
- **Intuição → matemática → código**, nessa ordem. Uma fórmula que aparece antes da intuição é carga cognitiva pura.
- **Uma ideia nova por seção.** Se a seção precisa de duas, são duas seções.
- Termos técnicos consagrados sem tradução forçada (*overfitting*, *embedding*, *batch*, *drift*); traduzidos quando a prática já traduziu (viés, variância, acurácia).
- Tabelas para fatos enumeráveis; explicação vive na prosa, não nas células.
- Cada componente descrito deve, quando possível, declarar sua **cláusula de expiração**.

## 4. Como se escreve um exercício

A sintaxe completa está em [`BANCO-DE-EXERCICIOS.md`](BANCO-DE-EXERCICIOS.md). As regras editoriais:

- **Todo exercício rastreia até um objetivo** (`"objetivo":"O2"`). Sem isso, o build falha.
- **O feedback (`> **porque:**`) é obrigatório e explica o conceito** — não apenas nomeia a resposta certa. Escreva-o pensando em quem errou, não em quem acertou.
- **`> **volte para:**` aponta a âncora da seção** que resolve a dúvida. É o gesto mais útil do livro.
- **Errar é parte do ciclo**: o gabarito só é revelado na segunda tentativa. Escreva o enunciado sabendo que o leitor vai tentar de novo.
- **Distratores plausíveis.** Uma alternativa errada que ninguém marcaria não ensina nada. As melhores são as que capturam um mal-entendido real e comum.
- Ordem de dificuldade dentro do capítulo: reconhecimento → aplicação → julgamento.
- Exercício de código é sempre **completion problem** (Sweller): complete a lacuna, não escreva do zero. Criar do zero é trabalho da etapa do `ml-zero`.

## 5. Como se escolhe um vídeo

- **Um vídeo entra por aquilo que o texto não faz bem.** Geometria animada, som, ritmo de derivação no quadro. Se o vídeo só repete o capítulo, ele não entra.
- Declare **autor, duração e o que ele resolve**. O campo de justificativa é obrigatório.
- Prefira material estável e gratuito. Vídeo atrás de paywall não entra (Princípio VI).
- **Reconfira os links na janela de revisão.** Vídeo morto é dívida do livro vivo, não do leitor.
- A carga do player só é pedida ao servidor de origem **depois do clique** do leitor — privacidade por padrão.

## 6. Datação, histórico e expiração

1. Todo capítulo declara a data de captura no cabeçalho.
2. Distinguem-se três datas: do **evento** (imutável), da **captura** (quando fotografamos) e do **experimento** (quando o número foi medido, com a versão da biblioteca).
3. Toda edição atualiza [`HISTORICO.md`](HISTORICO.md): changelog, snapshot por capítulo e o **registro de expiração** (🔵 aberta / 🟡 em curso / 🟢 confirmada / 🔴 refutada), com a versão do modelo de IA usada.

Regra de escrita associada: quando uma afirmação for sensível ao tempo ("hoje", "ainda não", "o consenso de 2026"), ela está implicitamente sob a data de captura do cabeçalho. Evite absolutos atemporais ("nunca", "sempre") a menos que sejam do tipo que não expira.

## 7. Revisão em duas camadas

Antes do copyedit de superfície, um passo de **revisão *developmental***: re-ver estrutura e sentido. O argumento fecha? A ordem serve ao leitor? Há redundância ou lacuna? Os exercícios testam mesmo os objetivos declarados, ou testam o que foi fácil de perguntar?

"Escrever é reescrever." Nenhum trecho novo é publicado sem esse passo — é portão de qualidade da constituição (Princípio IX), não sugestão.

## 8. Siglas e glossário (política)

- **Toda sigla é apresentada por extenso na 1ª ocorrência** de um capítulo — "Support Vector Machine (SVM)" — e dali em diante o texto pode usar só a sigla.
- O motor reforça isso: envolve automaticamente cada sigla conhecida em `<abbr>`, de modo que passar o mouse revela o significado em qualquer ocorrência, sem poluir o texto-fonte. O mapa vive em `publicar/build.mjs` e é espelhado em [`glossario.md`](glossario.md).
- Ao introduzir uma sigla nova, adicione-a **nos dois lugares** e confira a expansão na fonte (Princípio I).

## 9. Fluxo repetível para um contribuidor

1. **Abrir o tema** — pesquisa dupla (científica + indústria), verificada por busca cruzada; registrar lacunas.
2. **Definir os objetivos primeiro** (Backward Design) e, logo em seguida, **os exercícios** — antes de escrever o corpo. Se você não consegue escrever o exercício, o objetivo está vago.
3. **Reunir a evidência** — rodar o experimento no `ml-zero`; anotar seed, versões e números.
4. **Escrever** — no esqueleto v5, um tipo de texto por seção (Diátaxis).
5. **Revisar (developmental)** — §7.
6. **Verificar fontes** — nenhuma URL/DOI inventado; não-confirmado marcado `⏳`; sincronizar `bibliografia.md`.
7. **Gate de build** — `npm run build` (em `publicar/`) verde: link-check e gate de exercícios.
8. **Datar** — selo no capítulo, entrada no `HISTORICO.md` com a versão do modelo de IA, entrada no `CHANGELOG.md`.

## 10. Cadência do livro vivo

- **Janela trimestral**: reconferir vídeos, reexecutar os experimentos com as versões correntes das bibliotecas, atualizar o placar de expiração e as datas de revisão.
- **Gatilho extraordinário**: qualquer evento que invalide uma "Leitura executiva" (um resultado replicado que derruba uma recomendação, uma biblioteca central descontinuada, um dataset retirado) dispara revisão pontual do capítulo afetado, sem esperar a janela.
- **Gatilho por telemetria**: exercício com taxa de acerto muito baixa e volume relevante é sinal de que **o texto** está mal escrito, não de que o leitor é fraco. Ele entra na fila de revisão.

---

# Histórico — o livro vivo

> Este livro declara sua própria data de validade. Aqui ficam as **edições datadas**, o **snapshot por capítulo** e o **registro de expiração** — o placar das previsões que o livro fez, pontuadas contra a realidade.
>
> Toda edição registra também a **versão do modelo de IA** usada. Saídas de modelo de linguagem são não-determinísticas; sem esse registro, o resultado não é reproduzível nem auditável (Princípio IV).


## Edição 1.1 — 2026-08-11 · o livro em uso, e o que o uso quebrou

Primeira edição publicada **enquanto uma turma usa o livro**. Quase tudo aqui nasceu de pedido do autor em preparação de aula, e três achados vieram de **usar** em vez de revisar.

**No conteúdo**

- **Capítulo 05** ganhou o laboratório `05-l1` (mínimos quadrados à mão, com os quadrados do erro desenhados) e a seção **"A dedução, em cinco passos"**, do critério às equações normais.
- **Capítulo 28 — Regressão Logística** nasceu, separado do 05 ([ADR 0009](../adr/0009-separar-linear-e-logistica.md)). Antes eram 30 linhas; agora tem história com selos, a dedução de por que a solução fechada some, e três exercícios.
- **O caso da limonada** entrou no capítulo 05, com o conjunto de 365 dias que o autor trouxe da disciplina. Ele demonstra, com número, que **controlar por uma variável não desfaz confundimento** quando o confundidor não foi medido direito.
- **Notebooks** em cinco etapas do `ml-zero`, executáveis na máquina do aluno e no Colab.
- Exercícios: **91 → 96**.

**O que o uso derrubou, e nenhum gate pegava**

1. **Uma frase minha estava errada.** O capítulo 05 mandava "refazer o ajuste só com julho e agosto, onde o preço varia sem a estação variar junto". Não varia: **nenhum mês do ano tem mais de um preço**. Descoberto ao escrever a célula do notebook que faria isso. A correção deixou a lição mais forte — o confundimento é perfeito, e a resposta honesta passou a ser *"com estes dados não dá"*.
2. **O banner de consentimento estava quebrado em todas as páginas** desde sempre: uma variável `tx` sombreava a função `tx()` de tradução. Como a telemetria de navegação exige consentimento, **nenhum registro jamais foi gravado**. Build verde, testes verdes, links certos — só apareceu ao dirigir a página num navegador de verdade.
3. **O `og:image` apontava para o endereço prestes a ser aposentado.** Toda partilha em rede social viraria um retângulo vazio depois da migração, sem que nada acusasse.

**Na infraestrutura**

- O livro saiu do GitHub Pages para **domínio próprio**, com backend vivo: os **96 exercícios corrigem no servidor**, com revelação progressiva. ADRs [0006](../adr/0006-publicacao-vercel-railway-dominio.md) e [0007](../adr/0007-builder-declarado-na-railway.md).
- **Identificação por turma** ([ADR 0008](../adr/0008-identificacao-por-turma.md)): o anonimato segue sendo o padrão, e o aluno pode optar por sair dele com um comando no chat.

**Modelo de IA usado nesta edição:** Claude (Anthropic), em sessão conduzida pelo autor.

> **A lição da edição.** As três falhas acima têm a mesma forma: **saída tecnicamente válida, comportamento errado**. Nenhum gate mecânico as pegaria, porque nenhum gate olha para o que o leitor vê. O que as achou foi *usar* — escrever o notebook, abrir o navegador, ler o HTML publicado.

## Edições

### Edição 1.0 — 2026-08-10 · A primeira versão completa (spec 006)

**Os 28 capítulos existem, e nenhum finge ser mais do que é.**

O livro saiu de 8 capítulos com corpo para **28, todos no nível `essencial`** e todos dizendo isso ao leitor no próprio cabeçalho. Os exercícios foram de 31 para **91**. As duas disciplinas que o autor ministra têm material em todos os tópicos da ementa.

**Modelo de IA usado:** Claude (Anthropic), via Claude Code, sessão de 2026-08-10.

**O que mudou de método, e é o que importa.** A emenda 1.2.0 criou o **Princípio X** — nenhum método cai do céu —, e a 1.3.0 acrescentou o selo `✓ᵃ`. Mas a decisão que mais mudou o resultado foi mecânica: **o gate no build**. Um capítulo de método em nível `essencial` sem a seção histórica e sem tabela de selos **não compila**, e o alfabeto de selos é lido da própria constituição, falhando em qualquer símbolo desconhecido.

O gate reordenou o plano sozinho. O [ADR 0004](../adr/0004-escopo-da-primeira-versao.md) mandava escrever os capítulos novos antes de consertar os antigos; declarar o nível dos capítulos com corpo deixou o build vermelho na hora, e nada novo pôde ser publicado antes de a dívida velha ser paga. **É a diferença entre dívida registrada e dívida cobrada.**

**A pesquisa histórica em sessão única pagou o que prometia.** Cinco passadas produziram ligações que a pesquisa capítulo a capítulo teria perdido — e uma delas reescreveu a tese central. O livro vinha dizendo "crédito segue comunicação"; o k-means corrigiu para **crédito segue o vocabulário**. Com seis pretendentes em quatro campos que não conversavam, e o nome cunhado por MacQueen **para um algoritmo diferente**, não vence quem descobre nem quem publica: vence quem **nomeia**. O caso do MLOps fechou o argumento pelo extremo oposto — ali o campo não tinha um autor para o nome e **fabricou um retroativamente**.

**Três lendas foram testadas com instrução de não forçá-las a fechar. As três quebraram.** "Cerveja e fraldas" é verdadeira até a descoberta e inventada a partir da ação. A origem do nome *dynamic programming* tem citação autêntica de Bellman e cronologia impossível. E "MLOps foi cunhado por Sculley *et al.*" caiu por **verificação negativa no texto primário** — a palavra não aparece uma vez sequer.

**A auditoria adversarial reprovou o livro, e foi o melhor dinheiro gasto.** Em contexto fresco, com instrução de *derrubar* em vez de revisar, ela achou seis defeitos altos que nenhum gate pegaria: um **prenome inventado**, duas seções sem lastro na nota de pesquisa, um selo inflado, três capítulos reivindicando "o maior intervalo do livro", um erro de data e uma seção narrando como fato o que a tabela marcava como dúvida. Todos corrigidos; o [relatório](../estudos/2026-08-10-auditoria-adversarial.md) fica registrado. **Pedir "revise" produz elogio; pedir "tente derrubar" produz achado.**

**A dívida que fica, declarada.** A maior é a **D10**: em vários capítulos, uma fonte selada `✓ᵐ` sustenta no corpo uma afirmação sobre o que a obra argumenta por dentro. Havia duas saídas — ler as fontes, ou pôr hedge em cada frase. A escolha registrada é **ler**, no ciclo de aprofundamento, porque hedge mascara o problema com linguagem. A fila de verificação das notas de pesquisa, ordenada por dúvida fechada por unidade de esforço, é o plano de pagamento.

**O que esta edição deliberadamente não fez:** nenhum capítulo foi promovido a `completo`; nenhum experimento próprio novo entrou no `ml-zero`; e o backend continua sem publicar, o que mantém os exercícios dormentes e os laboratórios funcionando.


### Edição 0.6 — 2026-08-10 · Emenda 1.2.0: nenhum método cai do céu

Uma emenda à constituição, e a mais consequente até aqui para *como os capítulos são escritos*.

**O novo Princípio X.** Todo método deste livro foi inventado por **alguém**, preso num problema concreto, numa data, com meios limitados. Um capítulo que dá o método sem essa história entrega um procedimento — e procedimento se decora. Passa a ser obrigatória, em todo capítulo de método a partir do nível `essencial`, a seção **"De onde isto veio"**: o aperto · o que se fazia antes · a virada · **a ideia reaproveitável** · o nome.

O quarto elemento é o que justifica a seção. **Todo artifício técnico declara a ideia reaproveitável que há por trás dele** — artifício sem ideia é truque, e truque não se transfere. Quem sabe *que problema forçou o método a existir* reconhece o mesmo tipo de aperto anos depois, noutro contexto; quem só executa o procedimento tem uma habilidade que expira com a prova.

**Selos de proveniência por afirmação histórica** (✓ · ✓ᵐ · ⏳ · ❌ · 📖). História é o terreno mais fácil do livro para inventar, porque **história inventada soa bem** — uma data errada e uma atribuição plausível passam por qualquer revisão apressada. Inventar história é pior do que omiti-la, justamente porque convence.

**Modelo de IA usado:** Claude (Anthropic), via Claude Code, sessão de 2026-08-10.

**De onde veio a distinção ✓ / ✓ᵐ.** Ela não é preciosismo de escrivão: nasceu de um caso desta obra, três dias atrás. Ao conferir o DOI do neocognitron para o capítulo 18, o registro do Crossref devolveu **1980** — e o capítulo dizia 1979. O DOI provava que o artigo existe, quem assina e quando saiu; não provava nada sobre o que ele afirma por dentro. São duas perguntas diferentes, e um selo só não distinguia as duas. Agora conferir identificador dá **✓ᵐ**; ✓ exige ter aberto o texto.

**Uma dívida criada de propósito.** A emenda torna 8 capítulos não-conformes no instante em que é ratificada — nenhum dos que têm corpo traz a seção, porque todos são anteriores a ela. Isso está registrado como **D8** no roadmap, com o retrofit em **C8**, e nenhum deles sobe de nível sem pagá-la. Emendar a lei e declarar retroativamente que tudo já estava conforme seria o oposto do que o princípio pede.

### Edição 0.5.1 — 2026-08-08 · O capítulo 18 ganha história, imagem e código executável (sem spec)

Uma rodada curta e inteira dedicada a um capítulo só — o 18 —, a pedido de quem dá a aula. Nada de escopo novo: profundidade no que já existia.

**O que entrou:**

- **Histórico com as fontes reais.** A linha do tempo 1943–1986 deixou de citar de memória: cada marco leva DOI ou link verificável. McCulloch & Pitts ([doi:10.1007/BF02478259](https://doi.org/10.1007/BF02478259)), Rosenblatt ([doi:10.1037/h0042519](https://doi.org/10.1037/h0042519)), Fukushima ([doi:10.1007/BF00344251](https://doi.org/10.1007/BF00344251)), Rumelhart–Hinton–Williams ([doi:10.1038/323533a0](https://doi.org/10.1038/323533a0)).
- **A imagem do neurônio.** Diagrama próprio (SVG, tema claro/escuro, descrito para leitor de tela): entradas → pesos → soma → comparação com o limiar → saída.
- **Duas notas de contexto.** *Quando a IA ainda não se chamava assim*: o relatório de Turing de 1948, o artigo na *Mind* de 1950 e a proposta de Dartmouth de **31 de agosto de 1955**, que cunhou o termo. E a nota sobre **a prioridade do backpropagation**.
- **Código para baixar e rodar.** `ml-zero/etapa-18/neuronio.py` e um caderno pronto para o Colab. O `NeuronioMP` **não tem `fit`** — a ausência é o conteúdo: em 1943 não havia aprendizado. O `Perceptron`, ao lado, tem.

**Modelo de IA usado:** Claude (Anthropic), via Claude Code, sessão de 2026-08-08.

**A nota que não fechou, e por que ela ficou assim.** O pedido incluía checar uma lembrança: que o backpropagation teria sido desenvolvido por *um italiano, em 1979*. A busca não confirmou. O que existe, e está no capítulo com fonte: **Seppo Linnainmaa** (finlandês, 1970) publicou o modo reverso da diferenciação automática — a matemática do algoritmo; **Paul Werbos** (americano) o aplicou a redes na tese de 1974, com publicações no fim dos anos 1970; **Kunihiko Fukushima** (japonês) publicou o Neocognitron em **1979**. Nenhum italiano apareceu. O capítulo diz exatamente isso — inclusive que não achamos —, porque inventar uma atribuição plausível é o erro que o Princípio I existe para impedir. Se a lembrança tiver fonte, ela entra e esta nota é corrigida.

**Uma dívida de processo desta edição.** Ela foi feita a pedido direto, sem passar pelo ciclo `spec → plan → tasks` que o Princípio VII exige para a raia plena — um capítulo revisado, código novo e um blueprint de deploy não são raia leve. A versão original deste registro dizia "spec 006", uma spec que nunca existiu; a correção está aqui em vez de apagada, porque um livro que mantém placar das próprias previsões não pode maquiar o próprio histórico.

**O que o `NeuronioMP` sem `fit` ensina.** Um estudante que baixa o arquivo procura o método de treino e não encontra. Essa frustração de trinta segundos ensina o recorte histórico melhor que o parágrafo que o antecede: o modelo de 1943 é um circuito, não um aprendiz. Rosenblatt levou **quinze anos** para dar-lhe uma regra de aprendizado, e ela está no arquivo ao lado, para comparação direta.

### Edição 0.5 — 2026-08-08 · Novo escopo: três disciplinas, trilhas e o primeiro laboratório (spec 005)

A mudança mais profunda desde a fundação. O livro deixou de ser sobre Machine Learning e passou a ser **Ciência de Dados e Aprendizado de Máquina**, para servir a três disciplinas reais de Engenharia de Software.

**O que entrou:**

- **Novo escopo e novo título.** De 18 para **28 capítulos**, em cinco partes: Ciência de Dados, Análise Preditiva, Redes e Deep Learning, Além do Supervisionado, e No Mundo Real.
- **Trilhas de disciplina.** Três páginas que ordenam os capítulos por curso, mapeadas unidade a unidade das ementas. O número do capítulo virou **identificador estável**; a ordem vive nas trilhas. É isso que permite um capítulo servir a duas disciplinas com pesos diferentes.
- **Capítulo 18 — O Neurônio Artificial**, nível `essencial`: McCulloch–Pitts, o perceptron, o inverno da IA, e o XOR.
- **Laboratórios interativos** — a terceira superfície do livro. O primeiro é o neurônio de McCulloch–Pitts: o estudante põe os pesos à mão, vê a reta de decisão se mover sobre a tabela-verdade, e **descobre sozinho** que o XOR é impossível.
- **Nove capítulos-esqueleto novos** cobrindo o que faltava das ementas: ciclo CRISP-DM, coleta e integração, análise exploratória, visualização e storytelling, análise multidimensional, séries temporais, do modelo à decisão, treinar redes profundas, e IA simbólica/fuzzy/evolutiva.
- **Constituição emendada para 1.1.0**: níveis de maturidade (`esqueleto` / `essencial` / `completo`), laboratório reconhecido como mídia, e o portão de exercícios passando a valer na promoção a `completo`.

**Modelo de IA usado:** Claude (Anthropic), via Claude Code, sessão de 2026-08-08.

**A decisão de método.** Servir a disciplinas em curso exige **cobertura antes de profundidade** — e cobertura sem rigor é o que este projeto recusa. A conciliação foi declarar o nível de cada capítulo **ao leitor**, no próprio cabeçalho. Baixar o rigor em silêncio seria fraude; declarar cria a dívida visível que o roadmap cobra.

**Por que o laboratório importa.** O XOR é o caso em que o formato se justifica sozinho: nenhuma frase entrega o que travar em 3 de 4 entrega. O leitor tenta, tenta de novo, e **descobre** a impossibilidade — que é exatamente como Minsky e Papert a apresentaram em 1969. E, por rodar no navegador, o laboratório funciona mesmo com o backend fora do ar: é a superfície mais robusta do livro.

### Edição 0.4 — 2026-08-05 · Lineares e otimização: três achados que vieram de testes que falharam (spec 004)

**O que entrou:**

- **Capítulo 05 — Modelos Lineares** (3 exercícios, 1 vídeo): erro quadrático por conveniência e não por virtude, o logito como o que de fato é linear, as quatro coisas que um coeficiente **não** diz, e quando o linear é a escolha certa — reparando a impressão que o capítulo 07 deixa.
- **Capítulo 06 — Otimização e Regularização** (4 exercícios, 1 vídeo): gradiente como procedimento, diagnóstico pela curva de perda, L1 × L2 explicado pelo gradiente da penalidade, e early stopping.
- **Etapa 05–06 do `ml-zero`**: `Padronizador`, `RegressaoLinear` com solução fechada **e** gradiente, `RegressaoLogistica` com L1/L2, e o otimizador isolado do modelo. 22 testes.

**Modelo de IA usado:** Claude (Anthropic), via Claude Code, sessão de 2026-08-05.

**Os três achados.** Todos vieram de testes que falharam, e todos entraram no texto porque são úteis ao leitor:

1. **Perda logística é limitada.** Taxa 500 na logística **não** diverge — satura. Erro quadrático a taxa 50 explode. "Não explodiu" não prova que a taxa está boa.
2. **Early stopping monitorando treino nunca dispara em dado separável**, porque a perda de treino cai indefinidamente. O critério precisa observar validação — e a primeira versão da nossa implementação estava errada.
3. **Um instrumento de diagnóstico pressupõe que o problema exista.** Testar early stopping em dado limpo e separável não valida nada: não há ponto a partir do qual ajustar mais piore.

**Decisão registrada:** NumPy foi **adiado** para a etapa 09. O plano da spec 001 o previa a partir da 05; biblioteca padrão bastou, e adicionar dependência sem que o algoritmo exija é a estrutura antecipada que a regra 2 da construção proíbe.

### Edição 0.3 — 2026-08-05 · Árvores e ensembles: o que bagging e boosting realmente atacam (spec 003)

**O que entrou:**

- **Capítulo 07 — Árvores e Ensembles**, com 5 exercícios e 1 vídeo: como a árvore escolhe cada corte, por que uma árvore sozinha tem variância alta, a distinção entre bagging (variância) e boosting (viés), a ordem de ajuste de hiperparâmetros que economiza tempo, e a evidência sobre tabular × deep learning.
- **Etapa 07 do `ml-zero`**: `Arvore` (Gini + MSE), `Floresta`, `Boosting` e `auc` por postos, em ~250 linhas de biblioteca padrão. Mais `linear.py` como régua declarada. 21 testes.
- **Breiman (2001)** e **Grinsztajn, Oyallon & Varoquaux (2022)** conferidos e promovidos a ✓.
- **Nota de estudo** sobre a medição que mudou o desenho do experimento.

**Modelo de IA usado:** Claude (Anthropic), via Claude Code, sessão de 2026-08-05.

**O achado do caminho.** A primeira versão do experimento reusou o dado da etapa 00 e os quatro modelos terminaram empilhados entre 0,55 e 0,57 de AUC. Em vez de mexer no código, medimos o teto: o classificador de Bayes daquele dado alcança **0,5895** — o boosting já estava em 96% do máximo possível. Os modelos estavam certos; o instrumento é que não media. A etapa 07 passou a gerar o próprio dado, e a etapa 00 **não foi tocada** — sua lição depende daquele dado e já está publicada.

**Nota de honestidade.** O dado da etapa 07 foi construído com uma regra que favorece árvores por construção, e o capítulo diz isso em destaque, antes de qualquer número. A ilustração mostra o mecanismo; a evidência de que dado tabular real tem essa forma é do paper, não nossa.

### Edição 0.2 — 2026-08-05 · Dados: o vazamento e as divisões que respeitam a estrutura (spec 002)

O primeiro capítulo de conteúdo depois da fundação, e não por acaso: **vazamento de dados é o erro mais caro e mais silencioso de Machine Learning**.

**O que entrou:**

- **Capítulo 02 — Dados**, no esqueleto v4: as três fontes de vazamento (alvo disfarçado, pré-processamento antes da divisão, duplicata entre conjuntos), a divisão que respeita tempo e grupo, a ficha de dataset em sete perguntas e o viés de seleção. 4 exercícios e 1 vídeo.
- **Etapa 02 do `ml-zero`**: detector de vazamento com dois sinais independentes, divisão por grupo, divisão por tempo com intervalo de guarda, checagem de duplicatas e a `FichaDeDataset` como **portão executável** — o pipeline recusa dataset com ficha incompleta ou com dado pessoal declarado. 28 testes.
- **Carregador de módulos por etapa** (`ml-zero/tests/conftest.py`): etapas autocontidas têm arquivos homônimos, e `sys.path` cru fazia a primeira importação vencer silenciosamente.
- **Gebru et al. (2021)** conferido na fonte e promovido a ✓.

**Modelo de IA usado:** Claude (Anthropic), via Claude Code, sessão de 2026-08-05.

**Nota de método:** a lição central do capítulo — "embaralhar por linha vaza o sujeito" — é uma **asserção executável** na suíte de testes, não apenas uma frase no texto. É o Princípio II levado ao limite: o argumento do livro falha o build se deixar de ser verdade.

### Edição 0.1 — 2026-08-01 · Fundação: maquinaria, estrutura e a camada interativa (spec 001)

O repositório nasce com a máquina inteira funcionando e o conteúdo em construção — deliberadamente nessa ordem, para que nenhum capítulo seja escrito fora do formato que o livro exige de si mesmo.

**O que entrou:**

- **Governança** — constituição de 9 princípios, fundindo a didática e o ciclo spec-driven do livro de Engenharia de Harness com o processo de desenvolvimento do Maestro (raias, DoD verificável, skills-primeiro, ADR, gate de CHANGELOG).
- **Estrutura do livro** — 18 capítulos em 3 partes, mais o aparato. Todos com objetivos de aprendizagem declarados (Backward Design: os objetivos vêm antes do corpo).
- **Capítulos escritos** — `00 Introdução`, `01 Fundamentos` e `04 Avaliação` (o piloto do esqueleto v4). Os demais são esqueletos com objetivos e problema definidos.
- **Camada interativa** — exercícios em 5 tipos (múltipla, múltipla-multi, numérica, completar, aberta por rubrica) corrigidos **no servidor**, com feedback explicativo e revelação de gabarito só na 2ª tentativa; vídeos curados com player de fachada (nada é pedido a terceiros antes do clique).
- **Backend** — tutor com busca no texto do livro, correção de exercícios, progresso anônimo e telemetria consentida. 23 testes verdes.
- **Motor de publicação** — Markdown → site navegável, com gate de links internos e gate do banco de exercícios.

**Modelo de IA usado:** Claude (Anthropic), via Claude Code, sessão de 2026-08-01. Autoria, curadoria e responsabilidade humanas — ver [Autor](autor.md).

**O que ficou de fora, e por quê:** os 15 capítulos-esqueleto não têm corpo, exercícios nem vídeos. Escrevê-los agora, fora do ciclo spec-driven, violaria o Princípio VII — cada um entra por sua própria spec, com sua rodada de pesquisa verificada. A bibliografia reflete isso: 5 referências ✓ e as demais ⏳, honestamente marcadas.

## Snapshot por capítulo

> **Níveis** (constituição 1.1.0): `esqueleto` = objetivos e problema · `essencial` = corpo ensinável e prática · `completo` = o portão dos sete itens.
>
> Os capítulos 19–27, criados na edição 0.5, estão todos em `esqueleto`. O 18 está em `essencial`.

| Capítulo | Estado | Captura | Exercícios | Vídeos |
|---|---|---|---|---|
| 00 — Introdução | completo | 2026-08 | 3 | 1 |
| 01 — Fundamentos | completo | 2026-08 | 3 | 1 |
| 02 — Qualidade e Vazamento | completo | 2026-08 | 4 | 1 |
| 03 — Representação | esqueleto | — | 0 | 0 |
| 04 — Avaliação | completo (piloto v4) | 2026-08 | 5 | 1 |
| 05 — Modelos Lineares | completo | 2026-08 | 3 | 1 |
| 06 — Otimização | completo | 2026-08 | 4 | 1 |
| 07 — Árvores e Ensembles | completo | 2026-08 | 5 | 1 |
| 08 — Não Supervisionado | esqueleto | — | 0 | 0 |
| 09 — Redes Neurais | esqueleto | — | 0 | 0 |
| 10 — Visão | esqueleto | — | 0 | 0 |
| 11 — Sequências e Linguagem | esqueleto | — | 0 | 0 |
| 12 — Modelos de Fundação | esqueleto | — | 0 | 0 |
| 13 — Reforço | esqueleto | — | 0 | 0 |
| 14 — Interpretabilidade e Justiça | esqueleto | — | 0 | 0 |
| 15 — Sistemas de ML | esqueleto | — | 0 | 0 |
| 16 — MLOps | esqueleto | — | 0 | 0 |
| 17 — Fronteira | esqueleto | — | 0 | 0 |
| **18 — O Neurônio Artificial** | **essencial** | 2026-08 | 4 | 1 laboratório |
| 19 — Ciclo da Ciência de Dados | esqueleto | — | 0 | 0 |
| 20 — Coleta e Integração | esqueleto | — | 0 | 0 |
| 21 — Análise Exploratória | esqueleto | — | 0 | 0 |
| 22 — Visualização e Storytelling | esqueleto | — | 0 | 0 |
| 23 — Análise Multidimensional | esqueleto | — | 0 | 0 |
| 24 — Séries Temporais | esqueleto | — | 0 | 0 |
| 25 — Do Modelo à Decisão | esqueleto | — | 0 | 0 |
| 26 — Treinar Redes Profundas | esqueleto | — | 0 | 0 |
| 27 — IA Simbólica, Fuzzy e Evolutiva | esqueleto | — | 0 | 0 |

## Registro de expiração — o placar das previsões

Cada capítulo declara uma **cláusula de expiração**: o que, ali, tem prazo. Aqui elas são acompanhadas.

| # | Cláusula | Capítulo | Declarada em | Estado | Evidência |
|---|---|---|---|---|---|
| E1 | A decomposição viés–variância continua sendo a ferramenta de diagnóstico dominante na prática tabular; *double descent* é entendido como fenômeno do regime superparametrizado. Se surgir teoria unificada que preveja os dois regimes quantitativamente, a seção é reescrita. | 01 | 2026-08 | 🔵 aberta | — |
| E2 | AUC-PR é a escolha padrão para classes raras; calibração é etapa pós-treino dedicada. Se modelos de uso geral passarem a entregar escores bem calibrados sem etapa dedicada, a recomendação muda. | 04 | 2026-08 | 🔵 aberta | — |

| E3 | Gradient boosting é a escolha padrão para tabular de porte médio (Grinsztajn et al., 2022). **Gatilho de revisão**: um benchmark independente, com igual rigor de busca de hiperparâmetros, mostrando vantagem consistente de método não-árvore nesse regime. | 07 | 2026-08 | 🔵 aberta | — |

**Legenda:** 🔵 aberta (ainda em pé, sem evidência de mudança) · 🟡 em curso (há sinais, mas não conclusivos) · 🟢 confirmada (o previsto aconteceu) · 🔴 refutada (o livro errou — e isso é a notícia mais importante de uma edição)

## Cadência

- **Janela trimestral** (próxima: **2026-11**): reconferir vídeos, reexecutar os experimentos com as versões correntes das bibliotecas, atualizar o placar acima e as datas de revisão.
- **Gatilho extraordinário**: qualquer evento que invalide uma "Síntese — o que levar" dispara revisão pontual do capítulo afetado, sem esperar a janela.
- **Gatilho por telemetria**: exercício com taxa de acerto baixa e volume relevante é sinal de texto mal escrito. Ele entra na fila de revisão — ver [Uso do livro](apendice-uso.md).

---

# Apêndice — Uso do livro

> Como este livro mede a si mesmo, o que ele coleta, o que ele **não** coleta, e como você apaga tudo.

## O que é coletado

| Dado | Quando | Para quê |
|---|---|---|
| Página visitada (o *slug*) | só **depois** do seu consentimento explícito | saber quais capítulos são lidos e quais são abandonados |
| Tentativa de exercício (qual exercício, qual resposta, se acertou) | ao clicar em "Responder" | **o sinal mais valioso do projeto** — ver abaixo |
| Vídeo marcado como assistido | ao marcar a caixa | montar seu progresso |
| Conversas com o tutor | ao usar o chat | manter o fio da conversa e melhorar o livro |
| Objetivo declarado ("quero aprender X para Y") | se você escrever um | o tutor conectar as respostas ao seu objetivo |

## O que **não** é coletado

- **Nenhum cadastro.** Sem nome, sem email, sem senha, sem login social.
- **Nenhum identificador pessoal.** Sua identidade aqui é um número aleatório que o **seu navegador** gerou e guardou localmente. Ninguém, inclusive o autor, consegue ligá-lo a uma pessoa.
- **Nenhum rastreador de terceiros.** Não há analytics externo, pixel, nem cookie de publicidade. Os vídeos só contatam o servidor de origem **depois** de você clicar em "Carregar o vídeo".

## Por que as tentativas de exercício importam tanto

Quando muita gente erra o mesmo exercício, a hipótese padrão deste projeto **não** é que os leitores são fracos: é que **o texto está mal escrito**.

Um exercício com taxa de acerto baixa e volume relevante entra automaticamente na fila de revisão do capítulo (Guia Editorial §10). É o mecanismo mais direto que este livro tem de melhorar com o uso — e é a razão de a correção acontecer no servidor, e não na sua página.

A projeção pública abaixo mostra os agregados. Sem sessões, sem horários, sem respostas individuais.

<div data-viz="uso-livro"></div>

> Se o quadro acima estiver vazio, o backend do livro vivo não está configurado nesta publicação — o site funciona como livro estático, e nada é coletado.

## A exceção: identificação por turma

Tudo acima descreve o padrão, e o padrão é o anonimato. Há **uma** forma de deixar de ser anônimo, e ela depende de você digitar um comando:

```
/turma AP2026-2 123456
```

Se a sua disciplina usa este livro para acompanhar prática, esse comando associa **esta sessão** ao código da turma e à sua matrícula. A partir daí, **o professor daquela turma** passa a ver:

| Ele vê | Ele **não** vê |
|---|---|
| quais exercícios você resolveu | o texto das suas respostas |
| quantas tentativas levou em cada um | suas conversas com o tutor |
| quantos acertou de primeira | o que você leu, e quando |

Digite `/turma` sozinho para ler isso dentro do próprio chat antes de decidir, e `/turma sair` para desfazer a qualquer momento. Enquanto você não digitar, **nada muda** — quem chegou aqui pelo Google continua anônimo.

Duas coisas ditas com todas as letras:

- **A identificação é declarada, não verificada.** Não há login: você digita a matrícula que quiser. Isso é deliberado — o preço de não exigir cadastro — e é a razão de este mecanismo servir para *acompanhar prática*, não para lançar nota sozinho.
- **Apagar a sessão apaga também o vínculo.** Não fica nome para trás.

O desenho, as alternativas recusadas e as dívidas estão no [ADR 0008](../adr/0008-identificacao-por-turma.md).

## Como apagar tudo

Uma ação, sem formulário e sem justificativa: **abra o companion (💬) → "Apagar meus dados"**.

Isso remove, na mesma operação: suas conversas, suas tentativas de exercício, seus vídeos marcados e seu objetivo declarado. Tecnicamente é um `DELETE /session/{id}`, e o banco apaga em cascata — não há cópia guardada "para estatística".

O agregado público já contabilizado não é revertido, porque ele não contém nada seu: é uma contagem por página, sem vínculo com sessão alguma.

## Onde isso está no código

| O quê | Onde |
|---|---|
| Coleta e consentimento | [`chat-companion/backend/app.py`](../chat-companion/backend/app.py) |
| Persistência e apagamento em cascata | [`chat-companion/backend/store.py`](../chat-companion/backend/store.py) |
| Projeção pública (o que sai daqui) | rota `GET /telemetry/publico` |

A regra que o código obedece está no Princípio V da [constituição](../.specify/memory/constitution.md): o progresso é do leitor — anônimo, exportável, apagável.

---

# Autor e método

## Quem escreve

**Gilsiley Henrique Darú** — edição, direção e orquestração. [LinkedIn](https://www.linkedin.com/in/gilsiley-dar%C3%BA/)

## Divulgação de autoria (transparência)

Este livro é **co-escrito com um agente de IA (Claude, da Anthropic)** operando sob **autoria, curadoria e responsabilidade humanas**.

A divisão é explícita:

| Quem | O quê |
|---|---|
| **Humano** | Define o escopo, decide, verifica as fontes, responde pelo conteúdo |
| **Agente de IA** | Executa pesquisa, redação e o ciclo spec-kit, sob a constituição do projeto |

Seguindo o consenso das políticas editoriais e científicas (ICMJE, COPE, *Nature*, *Science*), **a IA não é listada como autora** — não pode ser responsabilizada pelo conteúdo — e seu uso é divulgado aqui e, edição por edição, no [Histórico](HISTORICO.md), **com a versão do modelo usada**.

O motivo do registro por versão é técnico, não cerimonial: saídas de modelo de linguagem são não-determinísticas. Sem saber qual modelo produziu qual edição, ninguém — inclusive o autor — consegue auditar depois de onde veio uma afirmação.

## As salvaguardas

O risco conhecido de escrever com um modelo de linguagem é a **fabricação plausível**: referências que não existem, números que soam certos, resultados que ninguém mediu. A resposta deste projeto está na constituição e é verificável no repositório:

1. **Nenhuma afirmação empírica sem experimento reproduzível ou citação ✓** (Princípio I). A [bibliografia](bibliografia.md) marca explicitamente o que ainda não foi conferido, e o que está ⏳ não pode sustentar afirmação no corpo.
2. **Nenhum resultado copiado sem reexecução** (Princípio II), salvo citação datada e explícita.
3. **Todo número tem um script que o regenera**, em CPU e sem chave paga.
4. **Ciclo spec-driven** (Princípio VII): cada melhoria tem spec, plano com Constitution Check, tarefas e verificação — rastreável no `specs/`.

A IA amplia o alcance da pesquisa e a velocidade da estruturação. O julgamento, a verificação e a assinatura são humanos.

## O método, em uma frase

Escrever de trás para frente (objetivos antes do texto), praticar antes de achar que entendeu (exercícios corrigidos no servidor), construir para saber de verdade (`ml-zero`), e datar tudo porque tudo expira.