Visão geral do design de funções em um ecossistema de IA

Visão geral do design de funções em um ecossistema de IA

Neste blog post, vamos explorar as funções essenciais e a arquitetura de um ecossistema de IA que visa facilitar o treinamento de modelos de IA de maneira responsável e respeitando os direitos autorais.

Funções Essenciais

Nós distinguimos entre duas funções essenciais: Proprietários de Modelos de IA (AOs) e Proprietários de Direitos Autorais (COs). Os AOs atuam como representantes dos criadores ou carregadores de modelos de IA, que constroem, treinam, mantêm e comercializam os modelos de IA. Em nossa estrutura, suas responsabilidades incluem a categorização de dados, aquisição de licenças e registro de metadados de conjuntos de dados/modelos no blockchain. Os COs são os detentores legítimos de direitos autorais de dados de treinamento com autoridade para licenciar seus dados, abrangendo criadores de conteúdo e empresas de mídia, entre outros. Seu envolvimento se estende à elaboração e assinatura bilateral de contratos de licença, garantindo a conformidade regulatória e a proteção dos direitos de propriedade intelectual.

Da mesma forma, um proprietário de modelo fundamental também é um CO do ponto de vista de um AO estendido. Nesse cenário, os conjuntos de dados utilizados no desenvolvimento do modelo fundamental são licenciados por um conjunto separado de COs, abrangendo o licenciamento de trabalhos derivados. Distinguir entre essas duas funções de CO não é imperativo dentro do IBIS, pois ele pode efetivamente rastrear dados complexos e relacionamentos de modelos.

Arquitetura

Nós imaginamos um ecossistema que capacita AOs e COs a aproveitar o efeito de rede de uma plataforma unificada para treinar e usar vários modelos e conjuntos de dados de IA. Por exemplo, um CO poderia licenciar o mesmo conjunto de dados para vários AOs e colher os benefícios de um modelo de pagamento conforme o uso para uso do conjunto de dados ou trabalho derivado dentro da mesma plataforma. Portanto, nossa estrutura proposta, IBIS (cf. Fig.2), é projetada para integrar uma rede de blockchain hospedada por um subconjunto de AOs e COs.

Enquanto AOs e COs estabelecidos e comercialmente significativos podem operar nós de blockchain, outros exigem apenas a capacidade de se conectar a um deles por meio de um agente. Em seu núcleo, a rede blockchain serve como a espinha dorsal, facilitando interações seguras e transparentes entre AOs e COs. O sistema é arquitetado para abstrair as complexidades da interação blockchain por meio de um serviço de agente, oferecendo interface de usuário, autenticação e buffer de solicitação.

O serviço de agente atua como uma ponte, conectando os AOs e COs com o blockchain, permitindo assim processos eficientes de registro e licenciamento de metadados. Além disso, a arquitetura do sistema inclui componentes dedicados para lidar com o registro de metadados do conjunto de dados, assinatura de licença bilateral e gerenciamento de metadados do modelo, cada um desempenhando um papel crucial no fluxo de trabalho geral do treinamento do modelo de IA e tratamento de direitos autorais.

Módulos Principais

O IBIS possui os seguintes seis módulos principais (marcados em verde na Fig.2):

• O Dataset Metadata Registry (DMR) mantém um registro de metadados on-chain para cada conjunto de dados raspado por AOs. Esses registros incluem detalhes como o CO do conjunto de dados e sua URL de origem.

• O License Registry registra licenças de direitos autorais que são assinadas bilateralmente pelo CO e AO correspondentes, servindo como evidência de acordos de uso de dados. Quando um conjunto de dados é licenciado, uma ligação bidirecional é estabelecida entre o registro de licença e o registro DMR do conjunto de dados. Uma única licença pode cobrir vários conjuntos de dados.

O Model Metadata Registry (MMR) armazena os metadados de um modelo depois que ele foi treinado. Esses metadados incluem o identificador do modelo, bem como os identificadores dos conjuntos de dados de treinamento e modelos de origem. Ele mantém um registro persistente dos conjuntos de dados e modelos de origem utilizados no treinamento dos modelos, estabelecendo assim a procedência dos dados.

• Os Serviços de Assinatura Multipartidária (MSS) orquestram a comunicação entre AOs e COs. Ele lida com tarefas como enviar e-mails de solicitação de licença para COs e retornar rascunhos de licença para AOs. Mais importante, aproveitando os recursos de gerenciamento de identidade e assinatura digital do blockchain, o MSS garante processos de assinatura multipartidária seguros para estabelecer licenças de direitos autorais.

• O Contract Lifecycle Management (CLM) fornece uma API unificada para interagir com várias soluções de software CLM externas que gerenciam licenças. Essa abordagem garante compatibilidade com uma variedade de soluções de software CLM, minimizando a interrupção dos fluxos de trabalho existentes dos COs.

• A Verificação de Validade da Licença (LVC) emprega contratos inteligentes para verificar a validade de uma licença com base em um conjunto de variáveis ​​de ambiente, incluindo a data atual, o local de operação da AO e quaisquer outras variáveis ​​que possam potencialmente violar os termos e condições estipulados na licença. Nossa estrutura permite a criação de contratos inteligentes LVC personalizados visando diferentes tipos de licença.

Estágios

Para o treinamento inicial do modelo, o fluxo de trabalho do nosso framework pode ser segmentado nos três estágios a seguir:

S1. Registro de conjunto de dados e verificação de licença

Essa etapa envolve a categorização de conjuntos de dados, o registro de metadados e as verificações de licença por meio de contratos inteligentes para garantir a conformidade com direitos autorais.

Especificamente, o fluxo de trabalho começa com a categorização do conjunto de dados, onde os conjuntos de dados são organizados em categorias específicas com base em seu conteúdo, fonte e uso. Essa categorização facilita a recuperação e o gerenciamento eficientes de conjuntos de dados durante todo o processo de desenvolvimento do modelo de IA. Após a categorização, o registro de metadados ocorre via DMR, registrando detalhes cruciais como descrições de dados, informações de autoria e direitos de uso em um formato estruturado.

Por fim, as verificações de licença são conduzidas por meio de contratos inteligentes LVC, utilizando processos automatizados para verificar a autenticidade e a conformidade das licenças associadas aos conjuntos de dados. Os contratos inteligentes garantem que o treinamento e o uso do modelo de IA cumpram os acordos de direitos autorais, fornecendo um fluxo de trabalho simplificado e compatível para gerenciar conjuntos de dados e suas licenças associadas.

S2. Elaboração de licenças e assinatura bilateral

Em caso de falhas nas verificações de licenças, esta etapa envolve a elaboração e assinatura bilateral das licenças, facilitadas pelo MSS e pelo CLM.

Ao identificar quaisquer licenças ausentes, expiradas ou retrabalhadas durante o estágio S1, o processo progride rapidamente para a elaboração de contratos de licença personalizados, adaptados aos conjuntos de dados exclusivos e suas aplicações pretendidas. Aproveitando os avanços recentes na tecnologia MSS, as partes interessadas embarcam em negociações bilaterais para refinar os termos desses contratos, culminando em seu acordo/contrato formal por meio de assinaturas digitais.

S3. Registro de metadados do modelo e notificação do proprietário dos direitos autorais

Nesta etapa, os modelos pós-treinamento são registrados no MMR onchain, criando uma ligação bidirecional entre os modelos e os conjuntos de dados de treinamento. As notificações podem ser enviadas aos COs conforme estipulado pelo contrato de licenciamento.

Detalhes de cada Estágio

O fluxograma na Fig.3.a ilustra como o IBIS é integrado ao treinamento de modelo de IA existente. Em seguida, discutimos os principais estágios em detalhes, e a Fig.4 descreve as interações entre os módulos do IBIS.

1) Registro de metadados do conjunto de dados e verificação de licença

Durante ou após o processo inicial de coleta de dados, os AOs categorizam os dados em um ou mais conjuntos de dados e registram os metadados de cada conjunto de dados no blockchain. O DMR on-chain mantém um registro de metadados para cada conjunto de dados, contendo detalhes como seu CO e URL de origem.

Os conjuntos de dados registrados no DMR não são automaticamente elegíveis para se tornarem dados de treinamento. Para aderir às leis de direitos autorais, cada conjunto de dados deve passar por uma etapa de verificação, envolvendo uma verificação da existência e validade de sua licença. Durante essa etapa, o AO extrai atributos de um conjunto de dados e consulta o registro de licenças no blockchain para uma licença correspondente. Uma vez que uma licença é encontrada, sua validade é verificada usando o contrato inteligente LVC. Apenas um conjunto de dados que passa na verificação de licença é considerado elegível para treinamento de modelo.

Após o conjunto de dados passar com sucesso na verificação de validade da licença, o atributo licenciado em seus metadados será atualizado para referenciar a licença válida. Além disso, o identificador do conjunto de dados será adicionado ao atributo datasetList da licença. Isso estabelece uma ligação bidirecional entre um conjunto de dados e sua licença correspondente.

2) Elaboração do contrato de licença e assinatura bilateral

Se as verificações de existência ou validade da licença falharem, a AO deve iniciar um estágio de elaboração e assinatura do contrato de licença para obter uma licença da CO. Este estágio começa com a AO enviando uma solicitação de licença para a CO correspondente. Esta solicitação é roteada pelo MSS, que então gera um e-mail contendo os detalhes da solicitação e um link para a CO tomar as ações necessárias.

Uma das ações envolve a elaboração de um contrato de licença com base na solicitação. A CO executa esta ação de elaboração invocando a API via CLM. Conectores que fazem interface com várias soluções de software CLM externas implementam esta API. Uma vez que o CO elabora o contrato de licença usando o software CLM, o contrato é transmitido de volta para a estrutura por meio do conector CLM e da API. Posteriormente, o CO e o AO se envolvem com o MSS para gerar um contrato de licença assinado bilateralmente. O contrato de licença assinado é então registrado no registro de licença.

3) Registro do modelo e notificação de CO

Após o treinamento de um modelo, seus metadados, compreendendo seu identificador, hiperparâmetros e os identificadores dos conjuntos de dados de treinamento, são registrados no MMR.

Retreinamento e Ajuste Fino do Modelo de IA

A arquitetura do sistema descrita acima não apenas suporta o treinamento inicial do modelo, mas também facilita o retreinamento e o ajuste fino do modelo, em que dados recém-coletados são integrados ao modelo. À medida que novos dados são raspados e coletados, o DMR continua a se expandir, enquanto novas licenças são adquiridas e armazenadas no registro de licenças, garantindo a legitimidade de novos conjuntos de dados.

No entanto, em cenários de retreinamento e ajuste fino, é possível que o modelo original precise de uma renovação de licença no momento do retreinamento ou ajuste fino, pois uma ou mais licenças de seus conjuntos de dados de treinamento podem ter se tornado inválidas. Portanto, antes de retreinar ou ajustar o modelo, um estágio adicional é necessário para verificar a elegibilidade dos dados, determinando se o modelo requer uma renovação de licença.

Além disso, comparado aos estágios no processo de treinamento inicial, surge uma divergência no estágio final em relação ao estabelecimento da procedência dos dados. O novo modelo é uma culminação do modelo original mesclado com novos conjuntos de dados. Portanto, ao registrar uma nova entrada no MMR para o modelo retreinado/ajustado, além de registrar os identificadores dos conjuntos de dados de treinamento, o AO também deve registrar o identificador do modelo original. Isso facilita a procedência dos dados e a linhagem do modelo ao longo do processo iterativo de retreinamento ou ajuste fino do modelo.

Conteúdo Relacionado

Voltar para o blog

Deixe um comentário

Os comentários precisam ser aprovados antes da publicação.