Como modelos aprendem representações

Um modelo é uma função ajustável

Aprendizado de máquina (ML) ajusta parâmetros usando exemplos. Entrada x, parâmetros θ e função f produzem uma saída. Uma função de perda mede distância entre saída e alvo; otimização altera θ para reduzir a perda. Treino ajusta. Inferência usa parâmetros fixos. Essa distinção impede confundir prompt com treinamento.

Em manutenção preditiva, x pode conter vibração, temperatura e corrente. O alvo é falha em 24 horas. Uma regressão logística já cria um baseline forte; uma rede neural só é necessária se relações não lineares e volume justificarem custo.

Gradiente sem misticismo

O gradiente indica a direção local de maior aumento da perda. Gradient descent caminha na direção oposta. Learning rate muito alto oscila; muito baixo demora. Batch é o subconjunto usado em uma atualização; época é uma passagem pelo conjunto.

for xb, yb in loader:
    prediction = model(xb)
    loss = criterion(prediction, yb)
    optimizer.zero_grad()
    loss.backward()
    optimizer.step()

O código esconde decisões essenciais: normalização, seed, divisão, desbalanceamento, early stopping e reprodutibilidade. Um gráfico bonito da perda de treino não prova generalização.

Redes e representações

Um neurônio artificial calcula combinação linear mais não linearidade. Camadas compõem transformações. Embedding é um vetor aprendido; proximidade representa regularidades do objetivo de treino, não verdade, causalidade ou permissão. Um embedding de documentos pode aproximar “superaquecimento” e “temperatura elevada”, mas também herdar lacunas e vieses.

Underfitting: modelo incapaz até no treino. Overfitting: memoriza treino e piora fora dele. Regularização, mais dados úteis, arquitetura adequada e early stopping ajudam, mas nenhum substitui teste representativo.

Transformer por partes

O Transformer substituiu recorrência como mecanismo central por atenção. Para cada token, projeções produzem query, key e value. Similaridades entre query e keys viram pesos; a soma ponderada dos values combina informação. Multi-head attention aprende relações diferentes. Embeddings posicionais, blocos feed-forward, conexões residuais e normalização completam a arquitetura.

Atenção não é explicação causal da resposta nem consciência. Visualizar pesos pode sugerir relações, mas não estabelece por que o sistema decidiu.

Treinamento de um LLM

Pré-treinamento autoregressivo aprende a prever o próximo token em grande corpus. Pós-treinamento usa demonstrações, preferências ou feedback para comportamento útil. RLHF, descrito no trabalho InstructGPT, é uma família de técnicas, não sinônimo de segurança. Modelos atuais podem usar variantes proprietárias; não invente detalhes ausentes do system card.

Treinar do zero raramente é racional para uma aplicação empresarial. APIs, modelos abertos, RAG e ajuste de um modelo existente cobrem a maioria dos casos. Treino próprio exige dados, compute, engenharia distribuída, avaliação e governança substanciais.

Falhas, segurança e operação

• dados duplicados inflam métricas;
• distribuição de produção diverge do teste;
• objetivo de treino é proxy imperfeito;
• artefato pode executar código não confiável ao carregar;
• checkpoints e datasets podem ter licença ou dados pessoais incompatíveis;
• dependência de GPU, driver e kernel altera reprodutibilidade.

Guarde hashes do dataset e artefato, ambiente, seed, configuração e lineage. Escaneie formatos e evite desserialização insegura. Monitore qualidade de entrada e resultado, não somente CPU/GPU.

Evals

Separe avaliação intrínseca (perda, perplexidade, métrica da tarefa) de avaliação do sistema (impacto, segurança, latência, custo). Um embedding que vence recall@k pode perder depois do reranker; um LLM forte em benchmark pode falhar em documentos da empresa.

Exercício e aceite

Treine regressão logística e uma pequena rede no mesmo conjunto. Use corte temporal, curva de aprendizado e matriz de confusão. Entregue relatório com parâmetros, variância entre seeds, latência e explicação de por que o modelo mais complexo venceu ou perdeu.

Aceite: execução reproduzível; conjunto de teste intocado; comparação justa; pelo menos um diagnóstico de overfitting; risco e condição de rollback.

Fontes primárias

• Attention Is All You Need
• Deep Learning
• Training language models to follow instructions with human feedback
• PyTorch reproducibility

Laboratório e caderno de evidências

Este caderno transforma o conceito do livro em uma decisão de engenharia auditável. O cenário é Comparar regressão, árvore e rede para manutenção preditiva. A regra é começar pelo sistema atual — regressão logística e árvore rasa — e só acrescentar complexidade quando uma avaliação previamente definida demonstrar ganho líquido.

1. Escreva o contrato da decisão

Registre em uma página: quem usa, qual decisão recebe apoio, quais entradas existem naquele instante, qual saída é permitida, qual efeito é proibido e quem responde pelo resultado. Separe sugestão, decisão e execução. Uma resposta textual pode sugerir; a API de domínio continua autorizando e registrando qualquer mudança.

Use critérios no formato dado/quando/então. Inclua caminho nominal, ausência de dados, conflito, outro tenant, dependência indisponível e tentativa adversarial. “Funciona bem” não é critério. Declare o limite de tempo, custo, dados e risco, além da condição de parada.

2. Construa o pacote mínimo de evidência

Crie um conjunto pequeno, porém representativo, antes de alterar o sistema. Cada caso tem identificador estável, origem, resposta ou comportamento esperado, risco, tags e razão da inclusão. O conjunto de desenvolvimento ajuda a iterar; um holdout separado impede otimizar contra a própria prova. Dados reais exigem minimização, controle de acesso e retenção. Quando usar casos sintéticos, identifique-os e confirme que não substituem a distribuição real.

A comparação deve manter constantes as partes que não estão sendo avaliadas. Se trocar modelo e prompt ao mesmo tempo, você não saberá a causa. Registre versões, configurações, ambiente, seeds quando aplicável e data. Preserve os piores erros como artefatos, não apenas a média.

3. Desenhe a fronteira operacional

entrada validada → componente candidato → validação externa
                 → autorização/policy → resultado observável
                 → feedback curado → avaliação de regressão

Marque onde conteúdo não confiável entra, onde identidade e permissões são resolvidas, onde segredos ficam e qual componente pode produzir efeito. O modelo não é fonte de verdade nem mecanismo de autorização. Use schema, consulta ao sistema de registro, allowlists, limites e confirmação proporcional ao risco.

Para cada dependência defina timeout, retry, idempotência, fallback e circuit breaker. Retry não é padrão para efeitos: um timeout pode ocorrer depois do sucesso. Modo degradado precisa preservar segurança e deixar claro ao usuário o que perdeu.

4. Faça uma pré-mortem

As falhas prioritárias deste livro são: overfitting; seed instável; sensor novo; artefato não confiável. Para cada uma, escreva gatilho, impacto, detecção, contenção, recuperação e teste do controle. Inclua falha acidental e abuso deliberado. Se a única defesa é “o modelo provavelmente recusará”, o controle ainda não existe.

Execute tabletop: uma pessoa opera, outra injeta a falha e uma terceira observa. O operador deve diagnosticar usando dashboards, traces e runbook, sem depender do autor. Registre lacunas e transforme recorrência em teste, política, alerta ou mudança arquitetural.

5. Meça o sistema completo

O painel mínimo acompanha recall por equipamento; calibração; variância entre seeds; latência. Faça cortes por versão, tipo de tarefa, risco e população relevante. Latência fim a fim inclui fila, retrieval e ferramentas. Custo é dividido por tarefa concluída, não por chamada. Qualidade em produção usa sinais curados; clique ou concordância do usuário não prova correção.

Defina SLO e orçamento de erro quando houver operação contínua. Alertas precisam de owner e ação. Telemetria passa por redaction antes de sair do processo; prompt, documento, memória ou trace completo podem conter informação pessoal, segredo ou conteúdo malicioso.

6. Libere em degraus

A sequência segura é offline, shadow, equipe interna, canário, aumento gradual e produção. Cada degrau possui gate e rollback. Feature flag separa deploy de liberação. A reversão deste cenário é: promover o último artefato assinado que passou no holdout. Treine a reversão antes do incidente e verifique que dados derivados, filas e caches também retornam a estado compatível.

Mudança de modelo, prompt, índice, ferramenta, policy ou dataset é mudança de sistema. Rode regressão proporcional. Um fornecedor atualizar silenciosamente comportamento não remove sua obrigação de testar.

Matriz de aceite

Dimensão	Evidência exigida	Falha que bloqueia
valor	ganho sobre baseline em casos representativos	demo isolada sem comparação
correção	golden set, holdout e análise dos piores casos	métrica média sem cauda
segurança	testes negativos de identidade, dados e efeitos	policy apenas no prompt
privacidade	minimização, finalidade, retenção e exclusão	dado sensível em trace
operação	SLO, alerta, runbook e rollback exercitado	dependência sem timeout
governança	owner, versão, usos permitidos e revisão	sistema órfão

Exercício de competência

Entregue um repositório ou pacote reproduzível contendo contrato, diagrama de fronteiras, casos de avaliação, script de execução, relatório comparativo, threat model, dashboard mínimo e runbook. Introduza deliberadamente duas falhas da pré-mortem e demonstre detecção e recuperação. Outra pessoa deve conseguir repetir o resultado sem explicação oral.

A aprovação exige: baseline preservado; critérios definidos antes do resultado; pelo menos um caso em que o sistema se abstém; efeito sensível protegido fora do modelo; custos medidos; rollback testado; limitações e usos proibidos escritos. Se o candidato não superar o baseline com segurança, documentar “não adotar” é um resultado tecnicamente correto.

Perguntas de recuperação ativa

1. Qual afirmação deste sistema depende de evidência externa?
2. O que o modelo pode propor, mas jamais autorizar?
3. Qual mudança invalidaria o holdout?
4. Como detectaríamos a pior falha antes do usuário?
5. Qual é o caminho de retirada em menos de uma hora?

Relações

Use este caderno junto ao livro de evals para desenho estatístico, ao de segurança para cenários adversariais, ao de observabilidade para sinais e ao de UX para supervisão. A profundidade nasce da conexão entre decisão, implementação, medição e recuperação — não da quantidade de ferramentas citadas.