MLaaS: Prevenindo o Roubo de Modelo de API com Autoencoders Variacionais

O Machine Learning como Serviço (MLaaS) comercializa os frutos de pesquisas caras e treinamento de modelos por meio de APIs que dão aos clientes acesso a insights do sistema. Embora o raciocínio do sistema seja inevitavelmente revelado em certa medida por meio dessas transações, a arquitetura do modelo central, os pesos que definem a utilidade do modelo e os dados de treinamento específicos que o tornaram útil são guardados com ciúme por várias razões.

Em primeiro lugar, o framework provavelmente explorou uma série de repositórios de código de software livre (FOSS) e rivais potenciais poderiam trivialmente fazer o mesmo em busca dos mesmos objetivos; em segundo lugar, em muitos casos, os pesos usados pelos modelos representam 95% ou mais da capacidade do modelo de interpretar os dados de treinamento melhor do que os modelos rivais e, argumenta-se, constituem o valor central do investimento caro, tanto em termos de horas de pesquisa quanto de treinamento de modelo em grande escala e bem equipado com GPUs de nível industrial.

Além disso, a mistura de dados proprietários e de dados públicos por trás do conjunto de dados de treinamento do modelo é uma questão potencialmente inflamável: onde os dados são “trabalho original” obtidos por meio de métodos caros, a capacidade de um usuário da API de inferir a estrutura de dados ou o conteúdo por meio de solicitações permitidas pela API pode permitir que eles essencialmente reconstruam o valor do trabalho, seja entendendo o esquema dos dados (permitindo a reprodução prática) ou reproduzindo os pesos que orquestram as características dos dados, o que potencialmente permite a reprodução de uma arquitetura “vazia” mas eficaz na qual material subsequente pode ser processado de forma útil.

Lavagem de Dados

Além disso, a forma como os dados são abstraídos no espaço latente do modelo de aprendizado de máquina durante o treinamento efetivamente “lava” os dados em funções generalizadas que tornam difícil para os detentores de direitos autorais entender se seu trabalho original foi assimilado sem permissão em um modelo.

O clima atual de laissez faire em todo o mundo com relação a essa prática provavelmente cairá sob uma regulação cada vez mais pesada nos próximos 5-10 anos. As propostas de regulamentação da UE para IA já contêm restrições sobre a proveniência dos dados e um quadro de transparência putativo que tornaria difícil para as empresas de coleta de dados contornar as regulamentações de domínio sobre a coleta de dados para fins de pesquisa. Outros governos, incluindo os EUA, agora estão comprometidos com quadros regulamentares semelhantes a longo prazo.

À medida que o campo do aprendizado de máquina evolui de uma cultura de prova de conceito para uma estrutura comercial viável, os modelos de aprendizado de máquina que forem considerados como tendo violado restrições de dados, mesmo em iterações anteriores de seus produtos, podem se encontrar expostos legalmente.

Portanto, o risco de inferir fontes de dados sobre chamadas de API não se relaciona apenas à espionagem industrial por meio de inversão de modelo e outros métodos, mas também a métodos forenses emergentes para proteção de propriedade intelectual que podem ser aplicados às empresas após o fim da “era do faroeste” da pesquisa de aprendizado de máquina.

Exfiltração Dirigida por API como Meio para Desenvolver Ataque Adversarial

Alguns quadros de aprendizado de máquina atualizam constantemente seus dados de treinamento e algoritmos, em vez de derivar um modelo definitivo e de longo prazo de um grande corpus de dados históricos (como o GPT-3, por exemplo). Isso inclui sistemas relacionados a informações de tráfego e outros setores em que os dados em tempo real são críticos para o valor contínuo de um serviço de aprendizado de máquina.

Se a lógica ou o peso do modelo pode ser “mapeado” por meio de chamadas de API sistemáticas, esses fatores podem potencialmente ser usados contra o sistema na forma de ataques adversariais, onde dados maliciosamente criados podem ser deixados no ambiente, em áreas onde o sistema-alvo provavelmente os coletará; ou por meio da infiltração das rotinas de aquisição de dados por outros métodos.

Portanto, as medidas contra a exfiltração centrada em API têm implicações também para a segurança dos modelos de aprendizado de máquina.

Prevenindo a Exfiltração Dirigida por API

Vários iniciativas de pesquisa surgiram nos últimos anos para fornecer metodologias que possam prevenir a inferência da arquitetura do modelo e dos dados de fonte específicos por meio de chamadas de API. A mais recente delas é apresentada em uma colaboração de pré-impressão entre pesquisadores do Instituto de Ciência da Índia em Bangalore e Nference, uma plataforma de software baseada em IA com sede em Cambridge, Massachusetts.

Intitulada Detecção Estatal de Ataques de Extração de Modelo, a pesquisa propõe um sistema chamado VarDetect, para o qual o código preliminar foi disponibilizado no GitHub.

Executado no lado do servidor, o VarDetect monitora continuamente as consultas do usuário a uma API, procurando por três padrões distintos de ataques de extração de modelo repetitivos. Os pesquisadores relatam que o VarDetect é o primeiro mecanismo de defesa de seu tipo a resistir a todos os três. Além disso, pode contra-atacar as contramedidas dos atacantes que se tornam conscientes de um mecanismo de defesa e que buscam derrotá-lo escondendo os padrões de ataque com pausas ou aumentando o volume de consultas para obscurecer as solicitações que estão tentando criar um mapa do modelo.

A arquitetura do VarDetect. Fonte: https://arxiv.org/pdf/2107.05166.pdf

O VarDetect usa Autoencoders Variacionais (VAEs) para efetivamente criar uma sonda avaliativa de estilo heurístico para solicitações de entrada. Ao contrário dos métodos anteriores, o sistema é treinado em dados proprietários, eliminando a necessidade de acesso a dados de atacantes, uma fraqueza das abordagens anteriores e um cenário improvável.

O modelo personalizado projetado para o projeto é derivado de três conjuntos de dados ou abordagens disponíveis publicamente: o trabalho desenvolvido em 2016 pelo Instituto Federal de Tecnologia da Suíça e Cornell Tech; adicionando ruído aos dados do “domínio do problema”, como demonstrado pela primeira vez no artigo PRADA de 2017 da Finlândia; e rastejando imagens públicas, inspirado na pesquisa ActiveThief 2020 da Índia.

Uma comparação de amostras de dados benignas e ‘malignas’ nos cinco conjuntos de dados usados no VarDetect.

As distribuições de frequência que correspondem às características do conjunto de dados a bordo serão marcadas como sinais de extração.

Os pesquisadores admitem que padrões de solicitação ordinários de usuários finais benignos podem potencialmente disparar falsos positivos no sistema, impedindo o uso normal. Portanto, esses sinais “seguros” percebidos podem subsequentemente ser adicionados ao conjunto de dados do VarDetect, tornando-se incorporados ao algoritmo por meio de um cronograma de treinamento contínuo, dependendo das preferências do sistema hospedeiro.

from benign end-users can potentially trigger false positives in the system, preventing normal usage. Therefore such perceived ‘safe’ signals may subsequently be added to the VarDetect dataset, becoming incorporated into the algorithm through a rolling training schedule, depending on the preferences of the host system.