# 0.1 — 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.** Avaliar se um problema é candidato a ML — e defender a resposta com a regra que ninguém consegue escrever, os exemplos disponíveis e uma medida de sucesso. - **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 0.2, 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 V.3 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 I.3). - **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 II.1). 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":"introducao-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. - [ ] 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. > **volte para:** #quando-nao-usar-machine-learning > _Gabarito, explicação e rubrica não vão neste arquivo. Quem corrige é o servidor, e a explicação completa é o que a segunda tentativa paga._ ::: :::exercicio {"id":"introducao-e7","tipo":"multipla-multi","objetivo":"O2","dificuldade":"dificil"} Uma rede de farmácias quer um sistema que decida, sozinho e sem revisão humana, quais receitas de medicamento controlado são fraudulentas e devem ser recusadas no balcão. A regra jurídica do que é fraude está escrita em norma. A rede tem 300 casos confirmados de fraude nos últimos cinco anos. Ninguém na reunião definiu o que seria um bom resultado. Quais dos quatro sinais de "não use ML" desta seção aparecem neste caso? (marque todos que valem) - [ ] Errar é inaceitável: a decisão recusa um medicamento no balcão e não há revisão humana no caminho. - [ ] Faltam exemplos: 300 casos em cinco anos é pouco para aprender um padrão de fraude que muda. - [ ] Ninguém consegue dizer o que é "bom": sem métrica definida antes, o projeto vai otimizar o que for fácil de medir. - [ ] A regra é escrevível: como a norma jurídica define fraude, basta programá-la. > **volte para:** #quando-nao-usar-machine-learning > _Gabarito, explicação e rubrica não vão neste arquivo. Quem corrige é o servidor, e a explicação completa é o que a segunda tentativa paga._ ::: :::exercicio {"id":"introducao-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) - [ ] No sistema aprendido, a regra vive em parâmetros ajustados a partir de exemplos. - [ ] O sistema aprendido pode degradar sem nenhuma alteração no código. - [ ] O sistema aprendido dispensa testes automatizados. - [ ] Verificar o sistema aprendido exige dados que ele nunca viu durante o treino. - [ ] O sistema programado não pode ser corrigido depois de escrito. > **volte para:** #o-que-muda-quando-a-regra-e-aprendida > _Gabarito, explicação e rubrica não vão neste arquivo. Quem corrige é o servidor, e a explicação completa é o que a segunda tentativa paga._ ::: :::exercicio {"id":"introducao-e5","tipo":"multipla","objetivo":"O1","dificuldade":"facil"} Um sistema de crédito passou a recusar pedidos que antes aprovava. Ninguém alterou uma linha de código, e o histórico do repositório confirma isso. O que esse único fato já permite afirmar? - [ ] Que a regra desse sistema não mora no código: ela foi ajustada a partir de dados, e o que mudou está fora do repositório. - [ ] Que houve um bug, porque software só muda de comportamento quando o código muda. - [ ] Que o modelo foi treinado com exemplos de menos. - [ ] Que alguém trocou a métrica de avaliação sem avisar. > **volte para:** #o-que-muda-quando-a-regra-e-aprendida > _Gabarito, explicação e rubrica não vão neste arquivo. Quem corrige é o servidor, e a explicação completa é o que a segunda tentativa paga._ ::: :::exercicio {"id":"introducao-e6","tipo":"aberta","objetivo":"O1","pontos":3,"dificuldade":"media"} Explique, para uma pessoa que programa há dez anos e nunca fez ML, o que muda quando a regra passa a ser aprendida. Use um exemplo de sistema que ela conheça, não o exemplo do capítulo. > **volte para:** #o-que-muda-quando-a-regra-e-aprendida > _Gabarito, explicação e rubrica não vão neste arquivo. Quem corrige é o servidor, e a explicação completa é o que a segunda tentativa paga._ ::: ## 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":"introducao-e4","tipo":"multipla","objetivo":"O3","dificuldade":"media"} Você terminou o capítulo de modelos lineares. Consegue explicar em voz alta o que é o erro quadrático médio e por que ele é minimizado — mas, ao abrir um arquivo vazio para ajustar uma reta a um conjunto de dados, não sabe qual é a primeira linha. Qual superfície deste livro ataca **essa** lacuna? - [ ] Reler o corpo do capítulo com mais atenção à dedução: a lacuna é de compreensão. - [ ] Fazer a etapa correspondente do `ml-zero`: a lacuna é entre o conceito e o código, e é essa a superfície que a fecha. - [ ] Responder à seção "Verificação", que cobra o nível mais alto do capítulo. - [ ] Refazer os exercícios do capítulo até acertar todos na primeira tentativa. > **volte para:** #a-ordem-que-funciona > _Gabarito, explicação e rubrica não vão neste arquivo. Quem corrige é o servidor, e a explicação completa é o que a segunda tentativa paga._ ::: :::exercicio {"id":"introducao-e8","tipo":"multipla","objetivo":"O3","dificuldade":"facil"} Das três superfícies deste livro, qual é a única que consegue te informar que você **não** entendeu alguma coisa? - [ ] O texto: relendo com atenção, a lacuna aparece. - [ ] Os exercícios: eles são corrigidos por fora, e por isso podem contrariar a sua impressão. - [ ] A construção `ml-zero`: se o código roda, o conceito está entendido. - [ ] O tutor: perguntando a ele, você descobre o que não sabe. > **volte para:** #como-este-livro-funciona > _Gabarito, explicação e rubrica não vão neste arquivo. Quem corrige é o servidor, e a explicação completa é o que a segunda tentativa paga._ ::: :::exercicio {"id":"introducao-e9","tipo":"multipla-multi","objetivo":"O3","dificuldade":"media"} Cinco estudantes descrevem como vão estudar o capítulo de árvores e ensembles. Quais descrições usam as três superfícies de forma deliberada, no sentido desta seção? (marque todas que valem) - [ ] "Vou ler os objetivos primeiro, para saber o que o capítulo promete cobrar de mim." - [ ] "Vou ler o capítulo inteiro duas vezes e só depois abrir os exercícios, para não errar à toa." - [ ] "Vou responder os exercícios antes de me sentir seguro, porque errar aqui é barato." - [ ] "Quando eu travar na etapa do `ml-zero`, volto à seção do texto que o feedback apontar." - [ ] "Vou pular a Verificação: se acertei os exercícios, o capítulo acabou." > **volte para:** #a-ordem-que-funciona > _Gabarito, explicação e rubrica não vão neste arquivo. Quem corrige é o servidor, e a explicação completa é o que a segunda tentativa paga._ ::: :::exercicio {"id":"introducao-e3","tipo":"aberta","objetivo":"O2","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. > **volte para:** #como-este-livro-funciona > _Gabarito, explicação e rubrica não vão neste arquivo. Quem corrige é o servidor, e a explicação completa é o que a segunda tentativa paga._ ::: ## Assista :::video {"id":"introducao-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. I.3–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. IV.1–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. IV.2–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?