🤖 machine learning

Deep4ge: DNN Training Trajectories for Fault Detection and Diagnosis

Este artigo apresenta o Deep4ge, um conjunto de dados de referência abrangente que compreende mais de 14.000 execuções de treinamento por época de 59 programas de redes neurais profundas com falhas injetadas, projetado para apoiar a pesquisa na detecção e diagnóstico de erros sutis de implementação em sistemas de aprendizado profundo.

Autores originais: Sigma Jahan

Publicado 2026-07-15

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Sigma Jahan

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está observando um estudante tentar aprender uma nova habilidade, como malabarismo. Às vezes, eles falham não porque são preguiçosos, mas porque estão segurando as bolas do jeito errado, ou porque o quarto está muito escuro, ou porque estão tentando aprender o truque errado. No mundo da inteligência artificial, esses "estudantes" são Redes Neurais Profundas (DNNs), e quando eles falham, muitas vezes não colapsam com uma mensagem de erro barulhenta. Em vez disso, eles apenas ficam muito ruins em malabarismo, ou começam a girar em círculos, ou desistem no meio do caminho.

Este é o problema que o artigo Deep4ge aborda. Os pesquisadores perceberam que, embora tenhamos muitas ferramentas para verificar se a pontuação final de um estudante é boa, não temos uma grande biblioteca pública de "diários de treinamento" que mostrem exatamente como eles falharam durante o processo de aprendizagem. Para resolver isso, eles construíram o Deep4ge, um experimento massivo e controlado que atua como um grande laboratório de simulação para falhas de treinamento de IA.

A Grande Simulação de Treinamento de IA

A equipe começou pegando 59 trechos de código reais do Stack Overflow (um site onde programadores fazem e respondem perguntas). Eles os limparam para garantir que rodassem perfeitamente, como ajustar um carro de corrida antes de um teste drive. Então, eles jogaram um jogo de "Mad Libs" com o código.

Eles usaram 27 diferentes "operadores de mutação" — pense neles como gremlins travessos que se infiltram no código e mudam uma pequena coisa. Talvez eles troquem a velocidade de aprendizado, mudem o tipo de matemática usada ou baguncem como a IA inicia seu cérebro. Eles aplicaram esses gremlins para criar 9.845 execuções de treinamento "defeituosas". Para garantir que a comparação fosse justa, eles também executaram 4.382 versões "corretas" sem nenhum gremlin.

No total, eles observaram 14.227 diferentes sessões de treinamento. Para cada sessão individual, eles não olharam apenas para a nota final; eles registraram uma entrada de diário para cada "época" (uma rodada de aprendizado). Eles registraram 26 pistas diferentes, como o quão pesados eram os "pensamentos" (pesos) da IA, o quão rápido os sinais estavam se movendo (gradientes) e até quanto de memória de computador a IA estava usando. Isso resultou em 719.560 pontos de dados individuais, criando um mapa detalhado do que dá errado e quando.

A Grande Descoberta: Não Olhe Apenas para a Linha de Chegada

A parte mais emocionante do artigo é o que eles descobriram ao tentar usar esses dados para prever falhas. Imagine que você é um treinador tentando identificar um estudante que está com dificuldades.

Os pesquisadores testaram duas maneiras de detectar o problema:

O Método do "Exame Final": Olhando apenas para o último dia de treinamento para ver se o estudante falhou.
O Método do "Diário de Treinamento": Olhando para todo o histórico de como o estudante aprendeu, passo a passo.

Os resultados foram claros: O método do "Exame Final" não foi muito bom. Se você olhasse apenas para o último dia, um programa de computador mal conseguiria distinguir entre um estudante que estava se esforçando mas falhando, e um que estava apenas confuso. A abordagem do "Exame Final" deu uma pontuação (chamada de MCC) de cerca de 0,150 para o melhor modelo de computador.

No entanto, quando usaram o método do "Diário de Treinamento" — olhando para as tendências, os altos e baixos, e toda a jornada — o computador melhorou muito na detecção de problemas. A pontuação saltou para 0,227. É como perceber que um estudante que começa forte mas piora lentamente é diferente de um que começa devagar mas melhora. O artigo sugere que, para realmente entender por que uma IA está falhando, você tem que assistir ao filme inteiro, não apenas ao final.

O Que Eles Podem (e Não Podem) Fazer

A equipe também tentou adivinhar que tipo de erro a IA cometeu (como: "Eles erraram a velocidade de aprendizado?" ou "Eles escolheram a matemática errada?"). Eles descobriram que alguns erros são fáceis de detectar, como erros de "Peso", que o computador acertou 70% das vezes. Mas outros erros, como erros de "Ativação" (onde a IA para de pensar completamente), foram muito difíceis de diagnosticar, com o computador acertando 0% deles em alguns testes.

Eles também testaram se suas descobertas funcionariam em diferentes tipos de "estudantes" de IA (como aqueles que processam imagens versus aqueles que processam linguagem). Descobriram que as habilidades se transferiam muito bem, mas houve uma pequena queda, especialmente para os modelos de processamento de linguagem, sugerindo que diferentes tipos de IA aprendem de maneiras ligeiramente diferentes.

Os Limites do Laboratório

É importante lembrar que isto foi uma simulação controlada. Os pesquisadores criaram as falhas eles mesmos usando suas ferramentas de "gremlin". Eles estão sugerindo que isso nos ajuda a entender problemas do mundo real, mas admitem que não provaram que esses exatos erros de "gremlin" acontecem exatamente da mesma forma no software industrial real e bagunçado. Além disso, eles olharam apenas para três tipos específicos de arquiteturas de IA (FNN, CNN e RNN) e não incluíram os modelos "Transformer", que são mais novos e populares.

A Conclusão

O Deep4ge é um presente para a comunidade científica. É uma biblioteca pública de 14.227 histórias de treinamento, completas com o "diário" de cada etapa individual. A principal lição é que, se você quiser pegar uma IA falhando cedo, não pode apenas esperar pelo relatório final. Você tem que observar o processo de treinamento se desenrolar, porque as pistas para a falha estão escondidas na jornada, não apenas no destino. Os autores lançaram todos os seus dados e ferramentas para que qualquer pessoa possa tentar construir detectores melhores, provando que, às vezes, a melhor maneira de consertar um robô quebrado é observá-lo tropeçar repetidamente.

Resumo Técnico: Deep4ge – Trajetórias de Treinamento de DNN para Detecção e Diagnóstico de Falhas

Declaração do Problema

Sistemas de aprendizado profundo frequentemente sofrem de falhas de implementação sutis que alteram o comportamento do treinamento sem produzir erros de tempo de execução explícitos. Diferente das falhas de software tradicionais, as falhas de Redes Neurais Profundas (DNN) costumam se manifestar como "sintomas silenciosos", tais como otimização instável, gradientes evanescentes/explosivos ou generalização pobre. Depurar esses problemas requer observar a evolução do treinamento ao longo do tempo, em vez de inspecionar apenas o código-fonte ou os resultados finais.

Apesar de propostas recentes para ferramentas de depuração de DNN (ex: AutoTrainer, DeepLocalize, DeepFD), a comunidade de engenharia de software carece de um conjunto de dados público e reutilizável contendo execuções de treinamento por época com históricos de falhas documentados. Estruturas de mutação existentes (ex: DeepCrime) focam primariamente na avaliação de operadores, em vez de fornecer trajetórias de treinamento abrangentes. Além disso, muitos estudos atuais dependem de falhas injetadas limitadas e específicas de cada estudo, onde os dados de treinamento correspondentes não são liberados para reavaliação sistemática.

Metodologia

Os autores apresentam o Deep4ge, um benchmark controlado projetado para preencher essa lacuna, gerando um conjunto de dados de larga escala de trajetórias de treinamento de DNN com categorias de falhas conhecidas.

1. Construção do Conjunto de Dados

Programas de Origem: Os autores coletaram 59 programas de DNN em TensorFlow/Keras do Stack Overflow. Estes foram selecionados com base na completude (contendo definição de modelo, carregamento de dados e treinamento), reparabilidade (para garantir execução determinística) e escopo arquitetural (Redes Feedforward, Convolucionais e Recorrentes).
Determinismo: Para minimizar a variabilidade não determinística, as sementes aleatórias foram fixadas nos níveis de framework e operador, e as divisões de dataset e configurações de inicialização foram padronizadas.
Injeção de Falhas: Partindo de programas de linha de base corrigidos, os autores aplicaram 27 operadores de mutação de nível de código-fonte para gerar variantes defeituosas. Esses operadores foram agrupados em sete categorias de falhas:
1. Hiperparâmetro
2. Perda (Loss)
3. Peso (inicialização/viés)
4. Camada (escolhas estruturais)
5. Otimização
6. Ativação
7. Regularização
  Nota: O conjunto de operadores combina um subconjunto de operadores do DeepCrime com novos operadores de nível de camada introduzidos neste trabalho. Operadores que modificam dados de treinamento ou controle de processo foram excluídos.
Validação de Mutação: Os autores empregaram o "critério de eliminação" do DeepCrime, que se baseia em significância estatística (Cohen's $d \ge 0.5$ , $p < 0.05$ ) entre as distribuições de acurácia das redes originais e mutantes ao longo de 15 retreinamentos. Mutantes não estatisticamente distinguíveis do original foram descartados. Os escores de mutação resultantes foram 0,85 (FNN), 0,87 (CNN) e 0,83 (RNN).

2. Extração de Características

Para cada execução de treinamento (tanto correta quanto defeituosa), o sistema registra dados em cada época. Cada execução registra:

4 Métricas de Avaliação: Perda (loss) e acurácia de treinamento e validação.
26 Características Dinâmicas:
- Pesos: Contagem de pesos grandes, flags de média/desvio padrão inalterados, contagem de NaN.
- Tendências: Gap, oscilação, diminuição e aumento na acurácia/perda.
- Ativações: ReLU morrendo (dying ReLU), saturação, média e desvio padrão.
- Gradientes: Flags de vanishing/exploding, contagem de NaN, média, desvio padrão, mínimo, máximo, mediana, normas de camada por camada e estatísticas por peso.
- Hardware: Taxa de aprendizado, uso de CPU, pico de memória da GPU e uso de memória do sistema.

3. Tarefas do Benchmark

O conjunto de dados suporta três tarefas principais:

Detecção de Falhas Binária: Classificar uma execução como defeituosa ou correta.
Diagnóstico de Falhas Multiclasse: Atribuir uma das sete categorias de falhas a uma execução defeituosa.
Predição Precoce de Falhas: Predizer falhas a partir de execuções parciais de treinamento (subconjuntos de época única ou de trajetória).

Principais Contribuições

Dataset Deep4ge: Um conjunto de dados rotulado compreendendo 14.227 execuções de treinamento (9.845 defeituosas, 4.382 bases corretas) abrangendo 719.560 registros de épocas. Os dados cobrem 59 programas únicos do Stack Overflow através de três famílias de arquitetura e sete categorias de falhas.
Framework de Código Aberto: Um framework de injeção de falhas que aplica transformações baseadas em AST, registra características por época e inclui scripts de validação. O framework permite que profissionais regenerem o dataset ou o estendam com novas transformações.
Baselines de Prova de Conceito: Os autores fornecem métricas de desempenho de baseline para detecção e diagnóstico de falhas usando modelos de Regressão Logística e Random Forest, comparando características de "época final" contra características de "trajetória" completa.

Resultados e Descobertas

Os autores avaliaram o desempenho de detecção e diagnóstico usando validação cruzada de 5 dobras (5-fold) sensível a grupos (agrupando por programa de origem para evitar vazamento de dados).

Trajetória vs. Época Final: Usar trajetórias de treinamento completas supera significativamente o uso de apenas características da época final.
- Para Detecção de Falhas, o Random Forest (RF) usando características de trajetória alcançou um Coeficiente de Correlação de Matthews (MCC) de 0,227, comparado a 0,150 para características da época final.
- Para Diagnóstico de Falhas, o RF Macro-F1 melhorou de 0,355 (época final) para 0,381 (trajetória), com o MCC subindo de 0,346 para 0,401.
Desempenho por Categoria de Falha: O desempenho de diagnóstico varia por categoria. Falhas relacionadas a Pesos foram as mais fáceis de diagnosticar (F1 = 0,700), seguidas por Hiperparâmetro e Perda. Falhas de Otimização e Ativação foram as mais difíceis (F1 = 0,075 e 0,000, respectivamente). Matrizes de confusão indicam que falhas de Ativação são frequentemente classificadas erroneamente como Otimização, e falhas de Otimização como Camada.
Transferência entre Arquiteturas: Modelos treinados em duas famílias de arquitetura e testados na terceira mostraram uma queda pequena, mas não nula, no desempenho (MCC caiu de 0,227 para ~0,20), sugerindo que, embora algumas características sejam transferíveis, outras permanecem específicas da arquitetura.
Detecção Precoce: A detecção de época única (usando características da época $k$ ) rendeu um desempenho inferior (MCC 0,14–0,19) em comparação aos modelos de trajetória completa, indicando que observar a evolução do treinamento é necessário para uma detecção robusta.

Significância e Alegações

O artigo afirma que o Deep4ge é o primeiro conjunto de dados público que vincula programas DNN adaptados com categorias de falhas derivadas de mutação e trajetórias de treinamento por época correspondentes. Sua significância reside em:

Padronização: Fornecer um benchmark controlado que suporta a reavaliação e comparação sistemática de técnicas de detecção e diagnóstico de falhas.
Mudança Metodológica: Permitir pesquisas que foquem na dinâmica de treinamento (trajetórias) em vez de análise estática de código ou resultados finais.
Reprodutibilidade: Oferecer um artefato de código aberto versionado (CC BY 4.0 para dados, MIT para código) que permite à comunidade replicar resultados, estender a taxonomia de falhas e testar novas arquiteturas.

Os autores mantêm um escopo modesto, reconhecendo que o dataset é limitado às arquiteturas FNN, CNN e RNN em TensorFlow/Keras (excluindo Transformers) e que programas do Stack Overflow podem não refletir totalmente as práticas industriais. Eles não alegam que as falhas derivadas de mutação representam perfeitamente as falhas que ocorrem naturalmente na indústria, mas sim que o dataset serve como um recurso fundamental para estudar comportamentos de falhas durante o tempo de treinamento.