Machine learning para quem já programa

Você já escreve funções. Escolhe os parâmetros, testa, corrige o if. Machine learning inverte uma parte desse ofício: a forma da função continua sendo sua, mas os números internos passam a ser procurados nos exemplos.

Isso não torna o programa menos programa. Continua havendo entrada, saída, erro e responsabilidade. O que muda é a origem dos parâmetros. Em vez de você decidir o peso de cada regra, um procedimento de treino ajusta esses pesos até o erro nos dados cair.

Quem já programa leva uma vantagem e uma armadilha. A vantagem é não misturar magia com código. A armadilha é tratar o treino como se fosse um teste unitário que passou.

O programa que você já escreve

Um filtro de spam clássico é uma lista de regras. Se o assunto contém determinada frase, se o remetente está em uma lista, se há dez links curtos, classifique como spam. Cada regra é um parâmetro escolhido à mão. Quando o remetente muda o texto, você edita o código.

O mesmo problema, em aprendizado supervisionado, recebe pares: mensagem e rótulo. Spam ou não. O modelo é uma função com milhares ou milhões de números. O treino procura números que façam a função acertar os pares. Você não escreve a lista de palavras suspeitas. Escreve a forma da função, a medida de erro e o recorte dos dados.

A comparação não é moral. Regras explícitas continuam melhores quando o domínio é estável, auditável e pequeno. Aprendizado começa a valer quando a lista de regras cresce sem fim, quando o padrão é estatístico, quando o ambiente muda mais rápido do que o time consegue editar if.

flowchart TD
  A[Exemplos rotulados] --> B[Treino]
  B --> C[Parâmetros]
  C --> D[Função]
  D --> E[Avaliação]
  E --> F{Generaliza?}
  F -->|Não| B
  F -->|Sim| G[Uso]
  classDef ouro fill:#FBF5E4,stroke:#C9A227,color:#0B1F18,stroke-width:1.4px
  classDef verde fill:#F3FAF7,stroke:#1E7A57,color:#0B1F18,stroke-width:1.4px
  classDef fim fill:#14513B,stroke:#0F3328,color:#FBFAF6,stroke-width:1.4px
  class A ouro
  class B,C,D,E,F verde
  class G fim

Supervisionado é o caso mais próximo do software

No aprendizado supervisionado, cada exemplo tem uma resposta desejada. É o análogo mais claro do teste: dado X, espero Y. Classificar e-mail, prever o preço de um imóvel, detectar se uma imagem contém um defeito — tudo isso cabe nesse molde.

Há outros regimes. Sem rótulo, o algoritmo procura estrutura: agrupamentos, compressão, fatores. Com recompensa, o sistema tenta ações ao longo do tempo. Para quem vem do software, o supervisionado é o lugar certo para começar, porque a pergunta “o que é um acerto?” já precisa estar escrita.

Essa pergunta é o requisito. Se duas pessoas discordam do rótulo — este e-mail é spam ou só é chato? — o modelo vai aprender a discordância. Dados não substituem a definição do problema. Só tornam a definição mensurável.

Treino e avaliação não são a mesma operação

No software, você não avalia a função com o mesmo caso que usou para descobrir o bug, se quiser confiar no resultado. Em aprendizado, a tentação é maior porque o “teste” parece uma métrica única: acurácia, erro médio, F1.

O conjunto de treino é o material com o qual os parâmetros são ajustados. O conjunto de avaliação é o material que o ajuste não pode ver. A separação não é etiqueta de pipeline. É a única forma de perguntar se a função serve para casos novos.

Há um terceiro recorte, o de teste final, quando você usa o conjunto de validação várias vezes para escolher modelo e hiperparâmetros. Cada escolha “olha” aquele conjunto. Ele deixa de ser um exame cego. Por isso times sérios guardam um pedaço intocado até a decisão de ir em frente.

A analogia escolar continua útil. Estudar a prova e gabaritar a mesma prova não mostra que a pessoa aprendeu a matéria. Mostra que memorizou as questões. Um modelo com 99% no treino e 70% na avaliação não está “quase pronto”. Está repetindo os exemplos.

Por que acertar no treino é uma armadilha

Funções flexíveis memorizam. Uma rede grande, uma árvore profunda, um vizinho mais próximo com memória demais: todos podem copiar o conjunto de treino. O erro cai. A métrica no notebook brilha. No dia seguinte, um cliente novo aparece e o sistema erra o óbvio.

Isso tem nome — overfitting — mas o mecanismo é simples. O procedimento de treino minimiza erro nos pontos que vê. Se a função tem liberdade demais e dados de menos, a minimização encontra um caminho que passa pelos pontos sem capturar a regularidade. É possível acertar ruído, exceção e até erro de rótulo.

O contrário também existe: a função é pobre demais para o fenômeno. Aí o erro é alto no treino e na avaliação. Não é memorização. É modelo errado ou features insuficientes.

Antes de trocar de algoritmo, olhe os dois números juntos. Erro baixo no treino e alto fora: o modelo colou. Erro alto nos dois: o modelo não cabe. Erro parecido e aceitável: você tem um candidato, não uma garantia de produção.

O que você ainda precisa escrever à mão

Machine learning não elimina desenho. Você ainda escolhe:

• a tarefa: classificar, regressão, ranquear;
• a representação: quais atributos entram, o que é vazamento do futuro, o que o sistema terá no momento da predição;
• a perda: o que conta como erro, e se errar uma classe custa mais do que errar outra;
• o recorte: quem está nos dados, de qual período, com qual viés de coleta;
• o critério de parada: quando o treino deixa de ajudar a avaliação.

Isso é engenharia. O otimizador não sabe se o atributo “pago em dia no mês que vem” vaza a resposta. Não sabe se o hospital só rotulou os casos graves. Não sabe se 90% de acurácia em uma doença rara é um modelo que chuta “sadio” em todo mundo.

Quem já escreve software reconhece o padrão: o compilador não salva um requisito errado. O treino tampouco.

Um exercício que cabe em um fim de semana

1. Pegue um problema que você resolveria com regras: atraso de pagamento, triagem de e-mail, prioridade de chamado.
2. Escreva as regras. Veja onde elas começam a ramificar.
3. Monte uma tabela de exemplos com o rótulo que um humano daria.
4. Separe treino e avaliação antes de qualquer ajuste.
5. Treine um modelo simples — regressão logística, árvore rasa — e compare com as regras no conjunto que o treino não viu.
6. Leia os erros. Não a métrica. Os erros.

Se o modelo simples não ganha das regras, talvez o problema ainda seja de definição, não de algoritmo. Se ganha no treino e perde na avaliação, você encontrou a lição deste texto sem precisar de uma rede neural.

Machine learning, nesse recorte, é um estilo de programação em que os parâmetros vêm dos dados. Continua sendo programação. Continua exigindo teste honesto. A diferença é que o teste honesto agora inclui um conjunto que o ajuste não pode colar.

O volume 3 da AI One parte exatamente daqui: o modelo clássico, a métrica em dinheiro e o erro que a acurácia esconde.

Leia também: Engenharia de requisitos: o que o pedido não diz.