Conceitos
Dívida técnica em sistemas de ML: entrelaçamento e ciclos de feedback
Intuição
Imagine uma receita em que todos os ingredientes já foram misturados na mesma panela: se você troca só o sal, o gosto de tudo muda, e não dá para tirar um ingrediente sem alterar o resto. Agora imagine que o prato que você serve muda o que os clientes pedem amanhã, e que outros cozinheiros, sem avisar você, passaram a copiar o seu prato. Construir esse prato foi rápido e barato, mas mexer nele com segurança depois fica cada vez mais caro, como uma dívida que cresce em silêncio enquanto ninguém olha.
Como funciona
Sculley et al. usam a metáfora de dívida técnica: colocar um sistema de ML em produção é rápido e barato, mas mantê-lo é difícil e caro, porque ele herda os problemas do software tradicional e soma problemas próprios, que vivem no nível do sistema e não do código. O primeiro é o entrelaçamento: sinais são misturados dentro do modelo e isso impede isolar melhorias. Se o modelo usa as features x1 até xn e a distribuição de x1 muda, a importância e o uso das outras n-1 podem mudar, esteja o modelo treinado em lote ou adaptando online. Os autores chamam isso de princípio CACE (Changing Anything Changes Everything), que vale também para hiperparâmetros, configurações de aprendizado, métodos de amostragem, limiares de convergência e seleção de dados. A erosão de fronteiras se agrava com consumidores não declarados, que passam a usar a predição de um modelo (em tempo de execução, em arquivos ou em logs) sem registro, criando acoplamento forte e escondido: mudar o modelo, mesmo para melhorar, causa impactos não entendidos. Há também os loops de feedback: no loop direto o modelo influencia a seleção dos seus próprios dados de treino futuros; no loop oculto, dois sistemas se influenciam indiretamente pelo mundo (um escolhe produtos e outro escolhe avaliações exibidas na mesma página, e mudar um altera os cliques no outro). Isso gera dívida de análise, pois é difícil prever o comportamento do modelo antes do lançamento. Por fim, a Figura 1 do artigo mostra o código de ML como uma pequena caixa cercada por infraestrutura vasta, e os anti-padrões que a ocupam incluem glue code (num sistema maduro, talvez no máximo 5% de ML e ao menos 95% de cola), pipeline jungles na preparação de dados e caminhos de código experimentais mortos, como no caso da Knight Capital, que perdeu 465 milhões de dólares em 45 minutos, aparentemente por comportamento inesperado de código experimental obsoleto.
Na prática
O artigo não propõe um algoritmo novo, e sim mitigações e perguntas de diagnóstico: isolar modelos ou servir ensembles ajuda em parte, mas como ensembles funcionam porque os erros dos componentes são pouco correlacionados, eles próprios geram entrelaçamento forte. Para consumidores não declarados, o sistema deve ser projetado com restrições de acesso ou SLAs rígidos; para loops diretos, usa-se alguma aleatorização ou se isolam partes dos dados da influência do modelo. Os autores sugerem ainda detectar mudanças de comportamento da predição (por exemplo, com métricas por fatia), apagar código morto e premiar a cultura de remover features e reduzir complexidade. Como a dívida não tem métrica estrita e continuar rápido não prova boas práticas, eles oferecem perguntas, como a facilidade de testar uma nova abordagem em escala e se melhorar um modelo degrada outros, que valem ao decidir quando parar de empilhar features e pagar a dívida.
Use em um desenho
Pratique na escola de System Design os casos que dependem deste conceito.