Capítulo 1.1 — Pensamento sistêmico para ML¶

🎯 Objetivo¶

Aplicar o pensamento sistêmico do Cap. 0.1 ao ciclo específico de ML. Em ML, o sistema é mais largo do que o pipeline de treino: ele inclui upstream (dados), downstream (consumidores) e o time que opera o modelo após o deploy. A maior parte dos incidentes de ML em produção nasce nas bordas, não no algoritmo.

🧠 Conceito¶

Sistemas de ML têm três acoplamentos críticos:

Dados ↔ código: mudanças em schema ou distribuição quebram pipelines.
Modelo ↔ produto: o produto define como a saída é interpretada.
Sistema ↔ organização: quem é dono do dataset, do modelo e do incidente?

Falhas costumam ser upstream (dado ruim chegando) ou downstream (uso indevido da saída), raramente no modelo em si. Por isso, um time maduro investe tanto em contratos nas fronteiras (dados, saída, ownership) quanto na arquitetura do modelo. Os contratos são determinísticos; o modelo é probabilístico (Cap. 0.6). Trocá-los de papel é o erro recorrente.

🏗️ Como isso aparece em produção¶

Time de upstream renomeia uma coluna; pipeline de features quebra silenciosamente.
Time downstream começa a interpretar score como probabilidade quando é ranking.
Compliance pede que features sensíveis sejam removidas e o modelo precisa ser retreinado.

Em todos os três casos, o algoritmo não mudou; o que mudou foi a borda do sistema. A correção é arquitetural - contrato de dados, contrato de saída, RACI explícito - não um ajuste de hiperparâmetro.

📌 Checklist¶

[ ] Há contrato de dados versionado entre upstream e pipeline?
[ ] Há contrato de saída versionado entre modelo e produto?
[ ] Há SLA de qualidade e freshness?