A indústria de videogames tem uma base de usuários estimada em mais de 3 bilhões em todo o mundo¹. Consiste em grandes quantidades de jogadores interagindo virtualmente uns com os outros todos os dias. Infelizmente, como no mundo real, nem todos os jogadores se comunicam de maneira apropriada e respeitosa. Em um esforço para criar e manter um ambiente de jogo socialmente responsável, o AWS Professional Services foi solicitado a criar um mecanismo que detectasse linguagem imprópria (fala tóxica) nas interações de jogadores de jogos online. O resultado comercial geral foi melhorar as operações da organização, automatizando um processo manual existente e melhorando a experiência do usuário, aumentando a velocidade e a qualidade na detecção de interações inadequadas entre os jogadores, promovendo um ambiente de jogo mais limpo e saudável.

A solicitação do cliente era criar um detector de idioma inglês que classificasse trechos de voz e texto em suas próprias categorias de linguagem tóxica definidas de maneira personalizada. Eles queriam primeiro determinar se o trecho de linguagem fornecido é tóxico e, em seguida, classificar o trecho em uma categoria específica de toxicidade definida pelo cliente, como palavrões ou linguagem abusiva.

O AWS ProServe resolveu esse caso de uso por meio de um esforço conjunto entre o Generative AI Innovation Center (GAIIC) e o ProServe ML Delivery Team (MLDT). O AWS GAIIC é um grupo dentro do AWS ProServe que combina clientes com especialistas para desenvolver soluções de IA generativas para uma ampla variedade de casos de uso de negócios usando compilações de prova de conceito (PoC). Em seguida, o AWS ProServe MLDT leva a PoC à produção, dimensionando, fortalecendo e integrando a solução para o cliente.

Este caso de uso do cliente será apresentado em duas postagens separadas. Este post (Parte 1) serve como um mergulho profundo na metodologia científica. Ele explicará o processo de pensamento e a experimentação por trás da solução, incluindo o treinamento do modelo e o processo de desenvolvimento. A Parte 2 se aprofundará na solução de produção, explicando as decisões de design, fluxo de dados e ilustração do treinamento do modelo e arquitetura de implantação.

Esta postagem aborda os seguintes tópicos:

• Os desafios que o AWS ProServe teve que resolver para este caso de uso
• Contexto histórico sobre modelos de linguagem grande (LLMs) e por que essa tecnologia é perfeita para esse caso de uso
• Solução de PoC do AWS GAIIC e AWS ProServe MLDT de uma perspectiva de ciência de dados e aprendizado de máquina (ML)

desafio de dados

O principal desafio que o AWS ProServe enfrentou ao treinar um classificador de linguagem tóxica foi obter dados rotulados suficientes do cliente para treinar um modelo preciso do zero. A AWS recebeu cerca de 100 amostras de dados rotulados do cliente, muito menos do que as 1,000 amostras recomendadas para o ajuste fino de um LLM na comunidade de ciência de dados.

Como um desafio inerente adicionado, os classificadores de processamento de linguagem natural (NLP) são historicamente conhecidos por serem muito caros para treinar e requerem um grande conjunto de vocabulário, conhecido como um corpus, para produzir previsões precisas. Uma solução de NLP rigorosa e eficaz, se fornecesse quantidades suficientes de dados rotulados, seria treinar um modelo de linguagem personalizado usando os dados rotulados do cliente. O modelo seria treinado apenas com o vocabulário de jogo dos jogadores, tornando-o adequado à linguagem observada nos jogos. O cliente tinha restrições de custo e tempo que tornavam essa solução inviável. O AWS ProServe foi forçado a encontrar uma solução para treinar um classificador de toxicidade de linguagem preciso com um conjunto de dados rotulado relativamente pequeno. A solução está no que é conhecido como transferir aprendizado.

A ideia por trás do aprendizado por transferência é usar o conhecimento de um modelo pré-treinado e aplicá-lo a um problema diferente, mas relativamente semelhante. Por exemplo, se um classificador de imagem foi treinado para prever se uma imagem contém um gato, você pode usar o conhecimento que o modelo adquiriu durante seu treinamento para reconhecer outros animais como tigres. Para esse caso de uso de linguagem, o AWS ProServe precisava encontrar um classificador de linguagem previamente treinado para detectar linguagem tóxica e ajustá-la usando os dados rotulados do cliente.

A solução foi encontrar e ajustar um LLM para classificar a linguagem tóxica. LLMs são redes neurais que foram treinadas usando um grande número de parâmetros, normalmente na ordem de bilhões, usando dados não rotulados. Antes de entrar na solução da AWS, a seção a seguir fornece uma visão geral do histórico de LLMs e seus casos de uso históricos.

Aproveitando o poder dos LLMs

Os LLMs tornaram-se recentemente o ponto focal para empresas que procuram novas aplicações de ML, desde que o ChatGPT conquistou a atenção do público por ser o aplicativo de consumidor que mais cresce na história², alcançando 100 milhões de usuários ativos até janeiro de 2023, apenas 2 meses após seu lançamento. No entanto, os LLMs não são uma nova tecnologia no espaço ML. Eles têm sido usados ​​extensivamente para executar tarefas de NLP, como análise de sentimentos, resumo de corpus, extração de palavras-chave, tradução de fala e classificação de texto.

Devido à natureza sequencial do texto, as redes neurais recorrentes (RNNs) foram o estado da arte para modelagem de NLP. Especificamente, o codificador-decodificador A arquitetura de rede foi formulada porque criou uma estrutura RNN capaz de receber uma entrada de comprimento arbitrário e gerar uma saída de comprimento arbitrário. Isso era ideal para tarefas de NLP, como tradução, em que uma frase de saída de um idioma podia ser prevista a partir de uma frase de entrada de outro idioma, geralmente com diferentes números de palavras entre a entrada e a saída. A arquitetura do transformador³ (Vaswani, 2017) foi uma melhoria revolucionária no codificador-decodificador; introduziu o conceito de atenção própria, o que permitiu que o modelo focasse sua atenção em diferentes palavras nas frases de entrada e saída. Em um codificador-decodificador típico, cada palavra é interpretada pelo modelo de maneira idêntica. Como o modelo processa sequencialmente cada palavra em uma frase de entrada, as informações semânticas no início podem ser perdidas no final da frase. O mecanismo de auto-atenção mudou isso adicionando uma camada de atenção ao bloco codificador e decodificador, para que o modelo pudesse colocar pesos diferentes em certas palavras da frase de entrada ao gerar uma determinada palavra na frase de saída. Assim nasceu a base do modelo do transformador.

A arquitetura do transformador foi a base para dois dos LLMs mais conhecidos e populares em uso atualmente, as representações de codificador bidirecional de transformadores (BERT)⁴ (Radford, 2018) e o transformador pré-treinado generativo (GPT)⁵ (Devlin 2018). Versões posteriores do modelo GPT, ou seja, GPT3 e GPT4, são o mecanismo que alimenta o aplicativo ChatGPT. A parte final da receita que torna os LLMs tão poderosos é a capacidade de destilar informações de vastos corpus de texto sem rotulagem extensa ou pré-processamento por meio de um processo chamado ULMFiT. Este método possui uma fase de pré-treinamento onde o texto geral pode ser reunido e o modelo é treinado na tarefa de prever a próxima palavra com base nas palavras anteriores; o benefício aqui é que qualquer texto de entrada usado para treinamento vem inerentemente pré-rotulado com base na ordem do texto. Os LLMs são realmente capazes de aprender com dados em escala de internet. Por exemplo, o modelo BERT original foi pré-treinado no BookCorpus e em conjuntos de dados de texto inteiros da Wikipédia em inglês.

Esse novo paradigma de modelagem deu origem a dois novos conceitos: modelos de fundação (FMs) e IA generativa. Ao contrário de treinar um modelo a partir do zero com dados específicos da tarefa, que é o caso usual para o aprendizado clássico supervisionado, os LLMs são pré-treinados para extrair conhecimento geral de um amplo conjunto de dados de texto antes de serem adaptados a tarefas ou domínios específicos com um número muito menor conjunto de dados (normalmente na ordem de centenas de amostras). O novo fluxo de trabalho de ML agora começa com um modelo pré-treinado denominado modelo de base. É importante construir sobre a base certa, e há um número crescente de opções, como o novo Amazon Titan FMs, a ser lançado pela AWS como parte do Rocha Amazônica. Esses novos modelos também são considerados generativos porque suas saídas são interpretáveis ​​por humanos e no mesmo tipo de dados que os dados de entrada. Enquanto os modelos de ML anteriores eram descritivos, como classificar imagens de gatos versus cachorros, os LLMs são generativos porque sua saída é o próximo conjunto de palavras com base nas palavras de entrada. Isso lhes permite alimentar aplicativos interativos, como o ChatGPT, que podem ser expressivos no conteúdo que geram.

Hugging Face fez parceria com a AWS para democratizar FMs e torná-los fáceis de acessar e construir. Cara de Abraço criou um API de transformadores que unifica mais de 50 arquiteturas de transformadores diferentes em diferentes estruturas de ML, incluindo acesso a pesos de modelos pré-treinados em seus Hub modelo, que cresceu para mais de 200,000 modelos até o momento da redação deste post. Nas próximas seções, exploramos a prova de conceito, a solução e os FMs que foram testados e escolhidos como base para resolver esse caso de uso de classificação de fala tóxica para o cliente.

Prova de conceito do AWS GAIIC

O AWS GAIIC optou por experimentar modelos de base LLM com a arquitetura BERT para ajustar um classificador de linguagem tóxica. Um total de três modelos do hub de modelos do Hugging Face foram testados:

Todas as três arquiteturas de modelo são baseadas no BERTweet arquitetura. O BERTweet é treinado com base no Roberto procedimento pré-treinamento. O procedimento de pré-treinamento RoBERTa é resultado de um estudo de replicação do pré-treinamento BERT que avaliou os efeitos do ajuste de hiperparâmetros e do tamanho do conjunto de treinamento para melhorar a receita para treinar modelos BERT⁶ (Lu 2019). O experimento procurou encontrar um método de pré-treinamento que melhorasse os resultados de desempenho do BERT sem alterar a arquitetura subjacente. A conclusão do estudo constatou que as seguintes modificações pré-treinamento melhoraram substancialmente o desempenho do BERT:

• Treinando o modelo com lotes maiores sobre mais dados
• Removendo o próximo objetivo de previsão de sentença
• Treinando em sequências mais longas
• Alterar dinamicamente o padrão de mascaramento aplicado aos dados de treinamento

O modelo bertweet-base usa o procedimento de pré-treinamento anterior do estudo RoBERTa para pré-treinar a arquitetura BERT original usando 850 milhões de tweets em inglês. É o primeiro modelo de linguagem pública em larga escala pré-treinado para tweets em inglês.

FMs pré-treinados usando tweets foram pensados ​​para se adequar ao caso de uso por duas razões teóricas principais:

• A duração de um tweet é muito semelhante à duração de uma frase inapropriada ou tóxica encontrada em chats de jogos online
• Os tweets vêm de uma população com uma grande variedade de usuários diferentes, semelhante à população encontrada em plataformas de jogos

A AWS decidiu primeiro ajustar o BERTweet com os dados rotulados do cliente para obter uma linha de base. Em seguida, optou por ajustar dois outros FMs em bertweet-base-offensive e bertweet-base-hate que foram pré-treinados especificamente em tweets tóxicos mais relevantes para alcançar uma precisão potencialmente maior. O modelo bertweet-base-ofensivo usa o BertTweet FM base e é ainda pré-treinado em 14,100 tweets anotados que foram considerados ofensivos⁷ (Zampieri 2019). O modelo bertweet-base-hate também usa o BertTweet FM básico, mas é pré-treinado em 19,600 tweets que foram considerados discurso de ódio⁸ (Basileia 2019).

Para aprimorar ainda mais o desempenho do modelo PoC, o AWS GAIIC tomou duas decisões de design:

• Criou um fluxo de previsão de dois estágios em que o primeiro modelo atua como um classificador binário que classifica se um trecho de texto é tóxico ou não tóxico. O segundo modelo é um modelo refinado que classifica o texto com base nos tipos tóxicos definidos pelo cliente. Somente se o primeiro modelo prever o texto como tóxico, ele será passado para o segundo modelo.
• Aumentou os dados de treinamento e adicionou um subconjunto de um conjunto de dados de texto tóxico rotulado por terceiros de uma competição pública do Kaggle (Toxicidade do Jigsaw) às 100 amostras originais recebidas do cliente. Eles mapearam os rótulos do Jigsaw para os rótulos de toxicidade definidos pelo cliente associados e dividiram 80% como dados de treinamento e 20% como dados de teste para validar o modelo.

AWS GAIIC usado Amazon Sage Maker notebooks para executar seus experimentos de ajuste fino e descobriram que o modelo bertweet-base-ofensivo alcançou as melhores pontuações no conjunto de validação. A tabela a seguir resume as pontuações métricas observadas.

A partir desse ponto, o GAIIC transferiu o PoC para a equipe de entrega do AWS ProServe ML para produzir o PoC.

Solução de equipe de entrega do AWS ProServe ML

Para colocar em produção a arquitetura do modelo, o cliente solicitou à AWS ProServe ML Delivery Team (MLDT) que criasse uma solução escalável e fácil de manter. Houve alguns desafios de manutenção de uma abordagem de modelo de dois estágios:

• Os modelos exigiriam o dobro da quantidade de monitoramento do modelo, o que torna o tempo de retreinamento inconsistente. Pode haver momentos em que um modelo terá que ser treinado novamente com mais frequência do que o outro.
• Aumento dos custos de execução de dois modelos em vez de um.
• A velocidade da inferência diminui porque a inferência passa por dois modelos.

Para enfrentar esses desafios, o AWS ProServe MLDT precisou descobrir como transformar a arquitetura de modelo de dois estágios em uma arquitetura de modelo único e, ao mesmo tempo, manter a precisão da arquitetura de dois estágios.

A solução foi primeiro pedir ao cliente mais dados de treinamento e, em seguida, ajustar o modelo ofensivo de base de bertweet em todos os rótulos, incluindo amostras não tóxicas, em um modelo. A ideia era que o ajuste fino de um modelo com mais dados resultaria em resultados semelhantes aos do ajuste fino de uma arquitetura de modelo de dois estágios com menos dados. Para ajustar a arquitetura do modelo de dois estágios, o AWS ProServe MLDT atualizou o cabeçote de classificação de vários rótulos do modelo pré-treinado para incluir um nó extra para representar a classe não tóxica.

A seguir está um exemplo de código de como você ajustaria um modelo pré-treinado do hub de modelo Hugging Face usando sua plataforma de transformadores e alteraria o cabeçote de classificação multi-rótulo do modelo para prever o número desejado de classes. O AWS ProServe MLDT usou esse esquema como base para o ajuste fino. Ele pressupõe que você tenha seus dados de trem e dados de validação prontos e no formato de entrada correto.

Primeiro, os módulos Python são importados, bem como o modelo pré-treinado desejado do hub de modelo Hugging Face:

# Imports.
from transformers import ( AutoModelForSequenceClassification, AutoTokenizer, DataCollatorWithPadding, PreTrainedTokenizer, Trainer, TrainingArguments,
) # Load pretrained model from model hub into a tokenizer.
model_checkpoint = “cardiffnlp/bertweet-base-offensive”
tokenizer = AutoTokenizer.from_pretrained(checkpoint)

O modelo pré-treinado é carregado e preparado para o ajuste fino. Esta é a etapa em que o número de categorias tóxicas e todos os parâmetros do modelo são definidos:

# Load pretrained model into a sequence classifier to be fine-tuned and define the number of classes you want to classify in the num_labels parameter. model = AutoModelForSequenceClassification.from_pretrained( model_checkpoint, num_labels=[number of classes] ) # Set your training parameter arguments. The below are some key parameters that AWS ProServe MLDT tuned:
training_args = TrainingArguments( num_train_epochs=[enter input] per_device_train_batch_size=[enter input] per_device_eval_batch_size=[enter input] evaluation_strategy="epoch", logging_strategy="epoch", save_strategy="epoch", learning_rate=[enter input] load_best_model_at_end=True, metric_for_best_model=[enter input] optim=[enter input], )

O ajuste fino do modelo começa com a inserção de caminhos para os conjuntos de dados de treinamento e validação:

# Finetune the model from the model_checkpoint, tokenizer, and training_args defined assuming train and validation datasets are correctly preprocessed.
trainer = Trainer( model=model, args=training_args, train_dataset=[enter input], eval_dataset=[enter input], tokenizer=tokenizer, data_collator=data_collator, ) # Finetune model command.
trainer.train()

O AWS ProServe MLDT recebeu aproximadamente 5,000 amostras de dados rotulados, sendo 3,000 não tóxicos e 2,000 tóxicos, e ajustou todos os três modelos de base de bertweet, combinando todos os rótulos em um modelo. Eles usaram esses dados, além das 5,000 amostras do PoC, para ajustar novos modelos de um estágio usando o mesmo método de 80% de conjunto de treinamento e 20% de conjunto de teste. A tabela a seguir mostra que as pontuações de desempenho foram comparáveis ​​às do modelo de dois estágios.

A abordagem do modelo de um estágio forneceu melhorias de custo e manutenção, diminuindo a precisão em apenas 3%. Depois de avaliar as compensações, o cliente optou pelo AWS ProServe MLDT para produzir o modelo de um estágio.

Ao ajustar um modelo com mais dados rotulados, o AWS ProServe MLDT foi capaz de fornecer uma solução que atendeu ao limite do cliente para precisão do modelo, além de atender às suas solicitações de facilidade de manutenção, reduzindo custos e aumentando a robustez.

Conclusão

Um grande cliente de jogos estava procurando uma maneira de detectar linguagem tóxica em seus canais de comunicação para promover um ambiente de jogo socialmente responsável. O AWS GAIIC criou uma PoC de um detector de linguagem tóxica ajustando um LLM para detectar linguagem tóxica. O AWS ProServe MLDT atualizou o fluxo de treinamento do modelo de uma abordagem de dois estágios para uma abordagem de um estágio e colocou em produção o LLM para o cliente a ser usado em escala.

Nesta postagem, a AWS demonstra a eficácia e a praticidade de ajustar um LLM para resolver esse caso de uso do cliente, compartilha o contexto sobre a história dos modelos de fundação e LLMs e apresenta o fluxo de trabalho entre o AWS Generative AI Innovation Center e o AWS ProServe ML Equipe de Entrega. Na próxima postagem desta série, vamos nos aprofundar em como o AWS ProServe MLDT produziu o modelo de um estágio resultante usando o SageMaker.

Se você estiver interessado em trabalhar com a AWS para criar uma solução de IA generativa, entre em contato com o GAIIC. Eles avaliarão seu caso de uso, criarão uma prova de conceito baseada em IA generativa e terão opções para estender a colaboração com a AWS para implementar a PoC resultante na produção.

Referências

1. Dados demográficos dos jogadores: fatos e estatísticas sobre o hobby mais popular do mundo
2. ChatGPT estabelece recorde para base de usuários de crescimento mais rápido – nota do analista
3. Vaswani et al., “Atenção é tudo que você precisa”
4. Radford et al., “Melhorando a compreensão da linguagem por meio do pré-treinamento generativo”
5. Devlin et al., “BERT: Pré-treinamento de transformadores bidirecionais profundos para compreensão da linguagem”
6. Yinhan Liu et al., “RoBERTa: uma abordagem de pré-treinamento BERT robustamente otimizada”
7. Marcos Zampieri et al., “SemEval-2019 Tarefa 6: Identificação e Categorização da Linguagem Ofensiva nas Mídias Sociais (OffensEval)”
8. Valerio Basile et al., “SemEval-2019 Tarefa 5: Detecção multilíngue de discurso de ódio contra imigrantes e mulheres no Twitter”

Sobre os autores

James Poquiz é cientista de dados da AWS Professional Services com sede em Orange County, Califórnia. Ele é bacharel em Ciência da Computação pela University of California, Irvine e tem vários anos de experiência trabalhando no domínio de dados, tendo desempenhado muitas funções diferentes. Hoje ele trabalha na implementação e implantação de soluções escalonáveis ​​de ML para obter resultados de negócios para clientes da AWS.

Homem Han é gerente sênior de ciência de dados e aprendizado de máquina da AWS Professional Services com sede em San Diego, CA. Ele é PhD em Engenharia pela Northwestern University e tem vários anos de experiência como consultor de gestão, assessorando clientes em manufatura, serviços financeiros e energia. Hoje, ele trabalha com entusiasmo com clientes-chave de vários setores da indústria para desenvolver e implementar soluções de ML e GenAI na AWS.

Safa Tinaztepe é um cientista de dados full-stack com AWS Professional Services. Ele é bacharel em ciência da computação pela Emory University e tem interesses em MLOps, sistemas distribuídos e web3.

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
• PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
• PlatãoESG. Automotivo / EVs, Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
• BlockOffsets. Modernizando a Propriedade de Compensação Ambiental. Acesse aqui.
• Fonte: https://aws.amazon.com/blogs/machine-learning/aws-performs-fine-tuning-on-a-large-language-model-llm-to-classify-toxic-speech-for-a-large-gaming-company/