Modos de falha no Machine Learning

Microsoft Corporation	Berkman Klein Center for Internet and Society na Universidade de Harvard
Ram Shankar Siva Kumar	David O'Brien
Jeffrey Snover	Kendra Albert
	Salomé Viljoen

Novembro de 2019

Introdução & Plano de Fundo

Nos últimos dois anos, mais de 200 artigos foram escritos sobre como o Machine Learning (ML) pode falhar devido a ataques adversários aos algoritmos e dados; esse número aumenta se incorporarmos modos de falha não adversários. A onda de documentos tornou difícil para os profissionais de ML, muito menos engenheiros, advogados e formuladores de políticas, acompanhar os ataques contra e defesas dos sistemas de ML. No entanto, à medida que esses sistemas se tornam mais difundidos, a necessidade de entender como eles falham, seja pela mão de um adversário ou devido ao design inerente de um sistema, só se tornará mais urgente. A finalidade deste documento é tabular conjuntamente ambos os modos de falha em um único lugar.

• Falhas intencionais em que a falha é causada por um adversário ativo que tenta subverter o sistema para atingir seus objetivos , seja para classificar incorretamente o resultado, inferir dados de treinamento privados ou roubar o algoritmo subjacente.

• Falhas não intencionais em que a falha ocorre porque um sistema de ML produz um resultado formalmente correto, mas completamente não seguro.

Gostaríamos de destacar que há outras taxonomias e estruturas que destacam individualmente os modos de falha intencional[1]^,[2] e os modos de falha não intencionais[3]^,[4]. Nossa classificação reúne os dois modos de falha separados em um só lugar e atende às seguintes necessidades:

1. A necessidade de equipar desenvolvedores de software, respondentes de incidentes de segurança, advogados e formuladores de políticas com um vernáculo comum para falar sobre esse problema. Depois de desenvolver a versão inicial da taxonomia no ano passado, trabalhamos com equipes de segurança e ML na Microsoft, 23 parceiros externos, organização de padrões e governos para entender como os stakeholders usariam nossa estrutura. Com base neste estudo de usabilidade e nos comentários dos stakeholders, iteramos na estrutura.

   Resultados: Quando apresentados com um modo de falha de ML, frequentemente observamos que desenvolvedores de software e advogados mapeavam mentalmente os modos de falha de ML para ataques de software tradicionais, como exfiltração de dados. Portanto, em todo o artigo, tentamos destacar como os modos de falha de aprendizado de máquina são significativamente diferentes das falhas de software tradicionais de uma perspectiva de tecnologia e política.

2. A necessidade de uma plataforma comum para os engenheiros se basearem e se integrarem às práticas de desenvolvimento e segurança de software existentes. Em geral, queríamos que a taxonomia fosse mais do que uma ferramenta educacional – queremos que ela efetue resultados tangíveis de engenharia.

   Resultados: Usando essa taxonomia como uma lente, a Microsoft modificou seu processo de Ciclo de Vida de Desenvolvimento de Segurança para toda a sua organização. Especificamente, cientistas de dados e engenheiros de segurança da Microsoft agora compartilham a linguagem comum dessa taxonomia, permitindo que eles modelem de forma mais eficaz as ameaças para seus sistemas de ML antes de serem implantados em produção; Os Respondedores de Incidentes de Segurança também têm uma referência de bugs para triagem dessas ameaças totalmente novas específicas para ML, o processo padrão de triagem e resposta de vulnerabilidades usado pelo Centro de Resposta de Segurança da Microsoft e todas as equipes de produtos da Microsoft.

3. A necessidade de um vocabulário comum para descrever esses ataques entre formuladores de políticas e advogados. Acreditamos que isso para a descrição de diferentes modos de falha de aprendizado de máquina e a análise de como seus danos podem ser regulados é um primeiro passo significativo em direção a políticas informadas.

   Resultados: Essa taxonomia é escrita para um público interdisciplinar amplo, portanto, os formuladores de políticas que estão analisando as questões de uma perspectiva geral de IA/ML, bem como domínios específicos, como desinformação/assistência médica, devem achar o catálogo do modo de falha útil. Também destacamos quaisquer intervenções legais aplicáveis para lidar com os modos de falha.

Consulte também os sistemas de IA/ML de modelagem de ameaças da Microsoft e as dependências e os pivôs da barra de bugs do SDL para vulnerabilidades do Machine Learning.

Como usar este documento

No início, reconhecemos que este é um documento vivo que evoluirá ao longo do tempo com o cenário de ameaças. Também não prescrevemos mitigações tecnológicas para esses modos de falha aqui, pois as defesas são específicas do cenário e vinculam-se ao modelo de ameaça e à arquitetura do sistema em consideração. As opções apresentadas para mitigação de ameaças são baseadas em pesquisas atuais com a expectativa de que essas defesas também evoluam ao longo do tempo.

Para engenheiros, recomendamos navegar pela visão geral de possíveis modos de falha e entrar no documento de modelagem de ameaças. Dessa forma, os engenheiros podem identificar ameaças, ataques, vulnerabilidades e usar a estrutura para planejar contramedidas quando disponível. Em seguida, encaminhamos você para a barra de bugs que mapeia essas novas vulnerabilidades na taxonomia juntamente com vulnerabilidades de software tradicionais e fornece uma classificação para cada vulnerabilidade de ML (como crítica, importante). Essa barra de bugs é facilmente integrada aos processos/guias estratégicos de resposta a incidentes existentes.

Para advogados e formuladores de políticas, este documento organiza os modos de falha de ML e apresenta uma estrutura para analisar os principais problemas relevantes para qualquer pessoa que explore as opções de política, como o trabalho feito aqui[5]^,[6]. Especificamente, categorizamos falhas e consequências de uma forma que os formuladores de políticas possam começar a estabelecer distinções entre causas, o que informará as iniciativas de políticas públicas para promover a segurança e a proteção do aprendizado de máquina (ML). Esperamos que os formuladores de políticas usem essas categorias para começar a descobrir como os regimes legais existentes podem (não) capturar adequadamente questões emergentes, quais regimes legais históricos ou soluções políticas podem ter lidado com danos semelhantes, e onde devemos ser especialmente sensíveis às questões das liberdades civis.

Estrutura do documento

Nas seções Modos de Falha Intencional e Modos de Falha Não Intencional , fornecemos uma breve definição do ataque e um exemplo ilustrativo da literatura.

Na seção Modos de Falha Intencional , fornecemos os campos adicionais:

1. O que o ataque tenta comprometer no sistema de ML – Confidencialidade, Integridade ou Disponibilidade? Definimos Confidencialidade garantindo que os componentes do sistema ML (dados, algoritmo, modelo) sejam acessíveis somente por partes autorizadas; A integridade é definida como assegurando que o sistema de ML só pode ser modificado por partes autorizadas; A disponibilidade é definida como uma garantia de que o sistema de ML está acessível a partes autorizadas. Juntos, confidencialidade, integridade e disponibilidade são chamados de tríade da CIA. Para cada modo de falha intencional, tentamos identificar qual da tríade da CIA está comprometida.

2. Quanto conhecimento é necessário para montar esse ataque – caixa preta ou caixa branca? No estilo de ataques do tipo blackbox, o invasor NÃO tem acesso direto aos dados de treinamento, nem conhecimento do algoritmo de aprendizado de máquina (ML) usado, nem acesso ao código-fonte do modelo. O invasor consulta apenas o modelo e observa a resposta. Em um ataque de estilo whitebox, o invasor tem conhecimento do algoritmo ML ou do acesso ao código-fonte do modelo.

3. Comentários sobre se o invasor está violando a noção tecnológica tradicional de acesso/autorização.

Resumo de falhas motivadas intencionalmente

Número do cenário	Ataque	Visão geral	Viola a noção tecnológica tradicional de acesso/autorização?
1	Ataque de perturbação	O invasor modifica a consulta para obter a resposta apropriada	No
2	Ataque de envenenamento	O invasor contamina a fase de treinamento dos sistemas de ML para obter o resultado pretendido	No
3	Inversão de modelos	O invasor recupera os recursos secretos usados no modelo por meio de consultas cuidadosas	No
4	Inferência de Pertinência	O invasor pode inferir se um determinado registro de dados fazia parte do conjunto de dados de treinamento do modelo ou não	No
5	Roubo de modelos	O invasor é capaz de recuperar o modelo por meio de consultas cuidadosamente criadas	No
6	Reprogramando o sistema ML	Reutilize o sistema de ML para executar uma atividade não programada	No
7	Exemplo Adversarial no Domínio Físico	O invasor traz exemplos adversariais para o domínio físico para subverter o sistema de ML, por exemplo: impressão 3D de óculos especiais para enganar o sistema de reconhecimento facial	No
8	Provedor de ML mal-intencionado recuperando dados de treinamento	O provedor de ML mal-intencionado pode consultar o modelo usado pelo cliente e recuperar os dados de treinamento do cliente	Sim
9	Atacando a cadeia de suprimentos de aprendizado de máquina	O invasor compromete os modelos de ML enquanto estão sendo baixados para uso	Sim
10	Backdoor ML	Provavelmente, um provedor mal-intencionado de ML injetou um backdoor no algoritmo para ativá-lo com um gatilho específico.	Sim
11	Aproveitar dependências de software	O invasor usa explorações de software tradicionais, como estouro de buffer, para confundir e controlar sistemas de aprendizado de máquina	Sim

Resumo de falhas não intencionais

Cenário #	Falha	Visão geral
12	Manipulação de Recompensa	Os sistemas RL (Aprendizado de Reforço) agem de maneiras não intencionais devido à incompatibilidade entre a recompensa declarada e a verdadeira recompensa
13	Efeitos colaterais	O sistema RL perturba o ambiente enquanto tenta alcançar seu objetivo
14	Turnos de distribuição	O sistema é testado em um tipo de ambiente, mas não consegue se adaptar às alterações em outros tipos de ambiente
15	Exemplos de adversários naturais	Sem perturbações de invasor, o sistema de ML falha devido à mineração negativa dura
16	Corrupção Comum	O sistema não é capaz de lidar com corrupções comuns de imagens e perturbações, como inclinação, zoom, ou imagens ruidosas.
17	Teste incompleto	O sistema de ML não é testado nas condições realistas em que se destina a operar.

Detalhes sobre falhas motivadas intencionalmente

Cenário #	Classe de Ataque	Descrição	Tipo de comprometimento	Scenario
1	Ataques de perturbação	Em ataques de estilo de perturbação, o invasor modifica furtivamente a consulta para obter uma resposta desejada	Integridade	Imagem: Adiciona-se ruído a uma imagem de raio-X, o que faz com que as previsões passem de exame normal para anormal [1][Blackbox] Tradução de texto: caracteres específicos são manipulados para resultar em tradução incorreta. O ataque pode suprimir uma palavra específica ou até mesmo remover a palavra completamente[2][Blackbox e Whitebox] Fala: Pesquisadores mostraram como, dada uma forma de onda de fala, outra forma de onda pode ser exatamente replicada, transcrevendo para um texto totalmente diferente[3][Caixa branca (Whitebox), mas pode ser estendida à caixa preta (blackbox)]
2	Ataques de envenenamento	O objetivo do invasor é contaminar o modelo de computador gerado na fase de treinamento, de modo que as previsões sobre novos dados sejam modificadas na fase de teste Direcionado: em ataques de envenenamento direcionados, o invasor deseja classificar incorretamente exemplos específicos Indiscriminado: o objetivo aqui é causar efeito semelhante ao DoS, o que torna o sistema indisponível.	Integridade	Em um conjunto de dados médico onde o objetivo é prever a dosagem do medicamento anticoagulante Warfarin usando informações demográficas e outras variáveis, os pesquisadores introduziram amostras maliciosas com uma taxa de envenenamento de 8%, o que alterou a dosagem em 75,06% para metade dos pacientes[4][Blackbox] No chatbot tay, conversas futuras foram contaminadas porque uma fração das conversas passadas foram usadas para treinar o sistema por meio de comentários[5] [Blackbox]
3	Inversão de modelos	Os recursos privados usados em modelos de machine learning podem ser recuperados	Confidencialidade;	Os pesquisadores conseguiram recuperar os dados de treinamento privados usados no treinamento do algoritmo[6] Os autores foram capazes de reconstruir rostos apenas com o nome e acesso ao modelo até o ponto em que usuários do Amazon Mechanical Turk poderiam usar a foto para identificar um indivíduo em uma identificação fotográfica com 95% de precisão. Os autores também conseguiram extrair informações específicas. [Whitebox e Blackbox][12]
4	Ataque de inferência de pertencimento	O invasor pode determinar se um determinado registro de dados fazia parte do conjunto de dados de treinamento do modelo ou não	Confidencialidade	Os pesquisadores conseguiram prever o procedimento principal de um paciente(por exemplo: cirurgia pela qual o paciente passou) com base nos atributos (por exemplo: idade, sexo, hospital)[7][Caixa preta]
5	Roubo de modelo	Os invasores recriam o modelo subjacente por meio de consultas legítimas ao modelo. A funcionalidade do novo modelo é igual à do modelo subjacente.	Confidencialidade	Pesquisadores emularam com sucesso o algoritmo subjacente da Amazon, BigML. Por exemplo, no caso bigml, os pesquisadores foram capazes de recuperar o modelo usado para prever se alguém deve ter um risco de crédito bom/ruim (conjunto de dados de cartão de crédito alemão) usando 1.150 consultas e dentro de 10 minutos[8]
6	Reprogramar redes neurais profundas	Por meio de uma consulta especialmente criada de um adversário, os sistemas de machine learning podem ser reprogramados para uma tarefa que se desvia da intenção original do criador	Integridade, disponibilidade	Demonstrou como o ImageNet, um sistema usado para classificar uma das várias categorias de imagens, foi reaproveitado para contar quadrados. Os autores terminam o artigo com um cenário hipotético: um invasor envia imagens de Captcha para o classificador de visão computacional em um serviço de fotos hospedado na nuvem, com o objetivo de resolver essas imagens de Captcha para criar contas de spam[9]
7	Exemplo de adversário no domínio físico	Um exemplo de adversário é uma entrada/consulta de uma entidade mal-intencionada enviada com o único objetivo de enganar o sistema de machine learning Esses exemplos podem se manifestar no domínio físico	Integridade	Pesquisadores 3D imprimem um rifle com textura personalizada que engana o sistema de reconhecimento de imagem a pensar que é uma tartaruga[10] Pesquisadores constrói óculos de sol com um design que agora pode enganar sistemas de reconhecimento de imagens e não reconhecer mais os rostos corretamente[11]
8	Provedores de ML maliciosos que podem recuperar dados de treinamento	O provedor de ML mal-intencionado pode consultar o modelo usado pelo cliente e recuperar os dados de treinamento do cliente	Confidencialidade	Os pesquisadores mostram como um provedor mal-intencionado apresenta um algoritmo com backdoor, no qual os dados de treinamento privados são recuperados. Eles foram capazes de reconstruir rostos e textos, apenas com o modelo. [12]
9	Atacando a cadeia de suprimentos de ML[13]	Devido a recursos grandes (dados + computação) necessários para treinar algoritmos, a prática atual é reutilizar modelos treinados por grandes corporações e modificá-los ligeiramente para tarefa em questão (por exemplo: ResNet é um modelo de reconhecimento de imagem popular da Microsoft). Esses modelos são organizados em um Model Zoo (o Caffe hospeda modelos populares de reconhecimento de imagens). Neste ataque, o adversário ataca os modelos hospedados em Caffe, envenenando assim o poço para qualquer outra pessoa.	Integridade	Pesquisadores demonstram como é possível para um invasor inserir código malicioso em um dos modelos de aprendizado de máquina populares. Um desenvolvedor de ML desavisado baixa esse modelo e o usa como parte do sistema de reconhecimento de imagem em seu código [14]. Os autores mostram como, em Caffe, existe um modelo cujo hash SHA1 não corresponde ao resumo dos autores, indicando adulteração. Há 22 modelos sem nenhum hash SHA1 para verificações de integridade.
10	Aprendizado de Máquina com Backdoor	Assim como no "Atacando a Cadeia de Suprimentos do ML", neste cenário de ataque, o processo de treinamento é totalmente ou parcialmente terceirizado para uma parte mal-intencionada que deseja fornecer ao usuário um modelo treinado que contenha um backdoor. O modelo com backdoor teria um bom desempenho na maioria das entradas (incluindo entradas que o usuário final pode manter como um conjunto de validação), mas causaria classificações incorretas direcionadas ou degradaria a precisão do modelo para entradas que satisfazem alguma propriedade secreta escolhida pelo invasor, à qual nos referimos como o gatilho de backdoor.	Confidencialidade, Integridade	Pesquisadores criaram um classificador de placas de trânsito dos EUA com backdoor que identifica sinais de parada como limites de velocidade somente quando um adesivo especial é adicionado ao sinal de parada (gatilho backdoor). Eles agora estão estendendo este trabalho para sistemas de processamento de texto, em que palavras específicas são substituídas pelo sotaque do orador funcionando como o gatilho.
11	Explorar dependências de software do sistema de Aprendizado de Máquina	Nesse ataque, o invasor NÃO manipula os algoritmos. Em vez disso, explora vulnerabilidades de software tradicionais, como estouros de buffer.	Confidencialidade, integridade, disponibilidade,	Um adversário envia uma entrada corrompida para um sistema de reconhecimento de imagem que faz com que ele seja classificado incorretamente explorando um bug de software em uma das dependências.

Detalhes sobre falhas não intencionais

Cenário #	Classe de Ataque	Descrição	Tipo de comprometimento	Scenario
12	Hackeamento de Recompensas	Os sistemas de aprendizagem de reforço agem de maneiras não intencionais devido a discrepâncias entre a recompensa especificada e a verdadeira recompensa pretendida.	Segurança do sistema	Um enorme corpus de exemplos de jogos na IA foi compilado aqui[1]
13	Efeitos colaterais	O sistema RL causa uma perturbação no ambiente ao tentar atingir seu objetivo	Segurança do sistema	Cenário, verbatim dos autores em [2]:"Suponha que um designer queira um agente RL (por exemplo, nosso robô de limpeza) para alcançar algum objetivo, como mover uma caixa de um lado de uma sala para a outra. Às vezes, a maneira mais eficaz de alcançar a meta envolve fazer algo não relacionado e destrutivo para o resto do ambiente, como derrubar um vaso de água que está em seu caminho. Se o agente receber recompensa apenas por mover a caixa, ele provavelmente derrubará o vaso."
14	Turnos de distribuição	O sistema é testado em um tipo de ambiente, mas não consegue se adaptar às alterações em outros tipos de ambiente	Segurança do sistema	Pesquisadores treinaram dois agentes RL de última geração, Rainbow DQN e A2C em uma simulação para evitar lava. Durante o treinamento, o agente RL foi capaz de evitar a lava com sucesso e atingir seu objetivo. Durante os testes, eles moveram ligeiramente a posição da lava, mas o agente RL não conseguiu evitá-la [3]
15	Exemplos de adversários naturais	O sistema reconhece erroneamente uma entrada que foi encontrada usando hard negative mining	Segurança do sistema	Aqui, os autores mostram como, por um processo simples de mineração negativa dura[4], é possível confundir o sistema de ML retransmitindo o exemplo.
16	Corrupção Comum	O sistema não é capaz de lidar com corrupções e interferências comuns, como inclinação, zoom ou imagens com ruído.	Segurança do sistema	Os autores[5] mostram como as corrupçãos comuns, como alterações no brilho, contraste, neblina ou ruído adicionados às imagens, têm uma queda significativa nas métricas no reconhecimento de imagens
17	Teste incompleto em condições realistas	O sistema de ML não é testado sob as condições realistas nas quais se destina a operar	Segurança do sistema	Os autores em [25] destacam que, embora os defensores geralmente sejam responsáveis pela robustez do algoritmo ML, eles perdem de vista as condições realistas. Por exemplo, eles argumentam que um sinal de parada ausente foi derrubado pelo vento (o que é considerado mais realista) do que um invasor tentando perturbar as entradas do sistema.

Reconhecimento

Gostaríamos de agradecer a Andrew Marshall, Magnus Nystrom, John Walton, John Lambert, Sharon Xia, Andi Comissoneru, Emre Kiciman, Jugal Parikh, Sharon Gillet, membros do fluxo de trabalho de Segurança de Ia e Ética em Engenharia e Pesquisa (AETHER) da Microsoft, Amar Ashar, Samuel Klein, Jonathan Zittrain, membros do Grupo de Trabalho de Segurança de Segurança de Ia na Berkman Klein por fornecer comentários úteis. Também gostaríamos de agradecer aos revisores de 23 parceiros externos, organizações padrões e organizações governamentais por moldarem a taxonomia.

Bibliografia

[1] Li, Guofu, et al. "Security Matters: A Survey on Adversarial Machine Learning". arXiv preprint arXiv:1810.07339 (2018).

[2] Chakraborty, Anirban, et al. "Ataques e defesas adversários: uma pesquisa". arXiv preprint arXiv:1810.00069 (2018).

[3] Ortega, Pedro e Vishal Maini. "Criação de inteligência artificial segura: especificação, robustez e garantia." Blog de Pesquisa de Segurança do DeepMind (2018).

[4] Amodei, Dario, et al. "Problemas concretos na segurança da IA". arXiv preprint arXiv:1606.06565 (2016).

[5] Shankar Siva Kumar, Ram, et al. "Law and Adversarial Machine Learning". arXiv preprint arXiv:1810.10731 (2018).

[6] Calo, Ryan, et al. "Enganar um robô é considerado hacking?". Artigo de Pesquisa da Faculdade de Direito da Universidade de Washington 2018-05 (2018).

[7] Paschali, Magdalini, et al. "Generalizability vs. Robustness: Adversarial Examples for Medical Imaging." pré-impressão arXiv arXiv:1804.00504 (2018).

[8] Ebrahimi, Javid, Daniel Lowd e Dejing Dou. "Sobre exemplos adversários para tradução automática por redes neurais a nível de caracteres." arXiv preprint arXiv:1806.09030 (2018)

[9] Carlini, Nicholas e David Wagner. "Exemplos de adversários de áudio: ataques direcionados à fala em texto." arXiv preprint arXiv:1801.01944 (2018).

[10] Jagielski, Matthew, et al. "Manipulando o aprendizado de máquina: ataques de envenenamento e contramedidas para aprendizado de regressão". arXiv preprint arXiv:1804.00308 (2018)

[11] [https://blogs.microsoft.com/blog/2016/03/25/learning-tays-introduction/]

[12] Fredrikson M, Jha S, Ristenpart T. 2015. Ataques de inversão de modelo que exploram informações de confiança e contramedidas básicas

[13] Shokri R, Stronati M, Song C, Shmatikov V. 2017. Ataques de inferência de pertencimento contra modelos de aprendizado de máquina. No Proc. do IEEE Symp. 2017 sobre Segurança e Privacidade (SP), San Jose, CA, 22 a 24 de maio de 2017, pp. 3 a 18. Nova Iorque, NY: IEEE.

[14] Tramèr, Florian, et al. "Roubando modelos de machine learning por meio de APIs de previsão". Simpósio de Segurança USENIX. 2016.

[15] Elsayed, Gamaleldin F., Ian Goodfellow e Jascha Sohl-Dickstein. "Reprogramação adversária de redes neurais." arXiv preprint arXiv:1806.11146 (2018).

[16] Athalye, Anish e Ilya Sutskever. Sintetizando exemplos adversariais robustos. arXiv preprint arXiv:1707.07397(2017)

[17] Sharif, Mahmood, et al. "Redes generativas adversárias: ataques de rede neural no reconhecimento facial de última geração". arXiv preprint arXiv:1801.00349 (2017).

[19] Xiao, Qixue, et al. "Riscos de segurança em implementações de aprendizado profundo". arXiv preprint arXiv:1711.11008 (2017).

[20] Gu, Tianyu, Brendan Dolan-Gavitt e Siddharth Garg. "Badnets: identificando vulnerabilidades na cadeia de fornecimento do modelo de machine learning." arXiv preprint arXiv:1708.06733 (2017)

[21] [https://www.wired.com/story/machine-learning-backdoors/]

[22] [https://docs.google.com/spreadsheets/d/e/2PACX-1vRPiprOaC3HsCf5Tuum8bRfzYUiKLRqJmbOoC-32JorNdfyTiRRsR7Ea5eWtvsWzuxo8bjOxCG84dAg/pubhtml]

[23] Amodei, Dario, et al. "Problemas concretos na segurança da IA". arXiv preprint arXiv:1606.06565 (2016).

[24] Leike, Jan, et al. "Gridworlds de segurança de Inteligência Artificial". arXiv preprint arXiv:1711.09883 (2017).

[25] Gilmer, Justin, et al. "Estabelecendo as regras do jogo para pesquisa sobre exemplos adversariais". arXiv preprint arXiv:1807.06732 (2018).

[26] Hendrycks, Dan e Thomas Dietterich. "A robustez da rede neural de benchmarking para corrupçãos e perturbações comuns." arXiv preprint arXiv:1903.12261 (2019).